Re: Debian needs more buildds. It has offers. They aren't being accepted.
Nathanael Nerode <neroden@twcny.rr.com> writes:
> Michael Banck:
> >IMHO, buildds are important, but keeping them current is not nearly as
> >important as you want to believe. It's not like "OMG, a buildd went
> >down, stop the presses!!!1!". And it's not a sport either ("If we've had
> >three more buildd for arch foo, we'd be up from 97.3% to at least 98.5%,
> >but *you* block the future of mankind")
>
> Actually, the interesting thing is that it isn't the total percentage that
> matters. It's the 'keystone' packages at the bottom of dependency chains,
> the ones which prevent large numbers of other packages from building and/or
> getting into sarge -- these have a knock-on effect causing delays far, far
> longer than the delay for the package itself.
>
> Apparently the buildds don't have a system for realizing automatically that
> these need to be expedited. Worse, apparently the buildd admins don't have a
> system for realizing manually that they need to be expedited. :-P
The priority of the package is used to determine the place in the
needs-build. Essential and required packages should be build real
fast. Problems can arise with the long dependency chains in the extra
or optional packages though.
> Since I couldn't think of an automated system (I know, I know), I've been
> working on the, uh, manual system, you could say?
The "simple" solution is for wanna-build to learn about Build-Depends
and Depends. The problem is, for it to work automatic, wanna-build
would have to decide if a sources Build-Depends are not only available
but also installable, which is a rather complex task. Wanna-build would
also have to see if a Build-Depends could be available at all or if
its e.g. a typo. Otherwise typos in the Build-Depends would stay stuck
in wanna-build. But every maintainer should notice when none of the
buildds builds his package. I don't see that as a problem.
A middle ground would be for wanna-build to check the build-depends
and put at least those direct dependencies into Dep-Wait states.
Another option would be to have an external program, run right after
quinn-diff, check out the needs-build queue and add Dep-Wait to sources
it can detect as waiting.
> Single points of failure are also a nasty nasty problem; when the lone mipsel
> buildd goes down, it puts mipsel way behind very quickly.
>
> --
> Incidentally, www.buildd.net provides a beautiful status page for each
> architecture showing essentially exactly what problems exist. Well, when the
> appropriate buildd people are participating. It's fairly new, so I don't
> expect immediate participation, but it's so sweet that I hope everyone
> participates pretty soon. :-)
Actually the pages are older, the location was changed and the
heartbeat is a very new feature.
MfG
Goswin
Reply to: