Re: Debian needs more buildds. It has offers. They aren't being accepted.
Martin Michlmayr - Debian Project Leader <leader@debian.org> writes:
> * Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> [2004-02-12 03:08]:
> > > 10 machines tend to have more failures by number, but that don't result in
> > > bringing down the whole port. Well, you know that of course... nothing new
> > > here... ;)
> >
> > Same goes for admins. 1 admin can be sick or busy working on
> > security. With 10 admins most certainly one will allways have some
> > spare time, not be sick, be in a good mood.
>
> The big question is whether having many people per arch actually
> scales. As you know, I'm not a buildd admin myself so I'm speaking
For m68k it works pretty well.
> based on 2nd hand knowledge, but I have heard one argument for few
> admins which I found pretty convincing. In many cases, FTBFS are the
> same across different architectures (e.g. missing build-depends). If
> there is one person who deals with 5 architectures, then he'll see the
> problem on all arches, report it once and know that it has been
> reported. If there are 10 people, everyone has to look at the BTS to
I look at the BTS (reportbug does that nicely) and
http://www.buildd.net/
or more direct:
http://www.buildd.net/cgi/package_status?all_pkg=<PACKAGE>&searchtype=go
It shows the wanna-build state of the package for all archs. I doubt
any admin can remember all the FTBFS packages over a few days without
rechecking or at least looking up the bug numbers for them.
I'm also working on a little patch that informs the admin before
building a package that has X build failures for other archs
already. Same procedure as building a package that previosuly
failed. That should be usefull for the slower archs to not waste time
on building totally broken packages.
> find out whether it has been reported already, therefore wasting time.
> Still, redundancy is certainly good, and I have e.g. seen buildd
> maintainers take over other arches while someone is on holidays.
>
> > Martin please do ask Ryan to look into his no_auto_build list and
> > similar to see if his buildds are excluding qt-x11-free. Or if the
>
> no_auto_build in /etc/sbuild.conf is empty on both remake and repeat
> if this is where this is defined.
Actually I ment buildd.conf (from my buildd):
# list of packages which shouldn't be picked up by buildd
@no_auto_build = qw(glibc egcs egcs1.0 lesstif mercury perl texmacs
octave jade prc-tools rscheme moonlight quantlib openh323
gcc-2.95 gcc-2.96 gcc-3.0 gcc-3.1 gcc-3.2 gcc-3.3
centericq perl);
# If there's nothing else to do, we may want to build these...
@weak_no_auto_build = qw(quantlib-python libooc-x11 maxima xfree86 ace
acl2 aplu s-fsf atlas axiom cernlib galeon
galeon-snapshot gcc-2.95 gcc-3.2 gcc-snapshot
g cl gclcvs ghc-cvs ghc6 gwydion-dylan hdf5
kdebase koffice lapack lyx mico mozill a
mozilla-firebird mozilla-snapshot openh323
pwlib qt-embedded qt-embedded-free qt-x11
sbcl scalapack vtk wxwindows2.4);
Of cause the list varies between archs and taste. Thats what Wouter
configured here (or what was preconfigured in the deb).
MfG
Goswin
Reply to: