Dear Craig,
> As you said, people have looked at this problem and not found a workable
> solution.
Personally I never did spend any effort into fixing this, partially
probably also because it doesn't affect any ports that I use or
maintain.
> It may be a _long_ time before a “proper” solution is implemented.
You don't need a 100% perfect solution, but something that works.
What buildbot setup could do, is check which variants are required for
a particular port. It could then perhaps install
p5.28-dbd-mysql +mariadb
explicitly, which could at least work for direct dependencies; getting
it to work correctly in a recursive way would be a bigger challenge.
Again, by far the easiest solution would be to fix ports in a way that
no port requires a non-default variant to be active. You didn't yet
answer my question: what prevents the dependencies of MythTV to change
their default variants, so that your ports would work out of the box?
> In the meantime, reporting these as failed builds *actively misinforms* users.
This has been the case for years already.
> When you say there will be the same problem “on a different page”, I don’t
> know what you mean.
One of the project ideas is to make buildbot logs and summaries more
useful, directly from the buildbot views:
https://trac.macports.org/ticket/55978
While we could internally waste weeks doing ugly workarounds to make
some ports artificially look pretty, I'm not going to ask developers
of buildbot to implement workarounds to allow cheating and report the
same build as both broken and successful at the same time. If you
don't want your port to be reported as broken, fix either the port(s),
the base, or the buildbot configuration.
An example of a buildbot configuration fix (that didn't actually take
a lot of time to do) is that we no longer build obsolete ports (we
used to do that in the past and got zillions of errors, in particular
when modifying the graveyard ports).
> And if we can implement a workaround, why can’t we share it with this other
> page?
Because I don't want to implement "build is both working and broken at
the same time" functionality in buildbot.
> Why would we have different pages reporting the same information?
It's not exactly the same. We are already reporting that "your" ports
are broken, in both buildbot and on the GitHub interface (when you
browse the commits). It's just that finding a particular port in the
buildbot is currently almost a mission impossible, so as a consequence
nobody knows which ports are broken and which ones work, except if you
check your own commits immediately a few hours after doing the commit,
or read the archives of build failures sent by buildbot. The
improvements on the buildbot site are meant to make the buildbot's
interface itself useful (which it currently isn't, except for checking
the last few builds), while the standalone app would provide a
plethora of other information (installation statistics, which ports
are outdated, which ones are broken, which websites are broken, ...),
just collected on one single place.
> > My argument is that we need to fix ports and base to avoid those
> > failures, not to explain them away.
>
> I don’t disagree. I guess I’m not as optimistic that this will be done
> quickly.
It needs someone to push for a fix, someone to come up with a decend
idea for the fix, and someone to actually implement it (it could be
the same person). If you take the first two tasks on you, even if you
don't know how to code in the base yourself, there's a high chance
that you'll get help with the last part. If nobody is pushing nor
suggesting what to do, this will likely not be done as fast.
I'm just arguing that if we get a student working on the web app, I
would prefer if he or she would perhaps spend time adding novel
functionality, which could even be allowing user comments on each port
(which you could use to explain why the port appears to be broken)
rather than on something that should be fixed elsewhere. (I wouldn't
mind the student spending time fixing that particular bug in buildbot
configuration or in base if comfortable with the code, but I would
definitely not want to demand from the student to fix this issue as
part of the project. I'm pretty sure that we'll have plenty more
serious problems that nobody is even aware of yet. And if it would be
easy to fix in the web app, we'll gladly accept any patches.)
Mojca
