Re: Debian needs more buildds. It has offers. They aren't being accepted.

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

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