[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On Wed, Feb 11, 2004 at 08:59:49PM +0000, Martin Michlmayr - Debian Project Leader wrote:

> Maintaining a buildd system for 11 architectures is a fairly complex
> task, especially with architectures that require many machines to keep
> up since it's likely that some machines will break.  There have been

Having 10 machines can mean, 10 machines can fail. Having 1 machine, means
only one machine can fail. Whereas the first seems to introduce higher
possibility oof failures, it also means that there is a redundancy because
10 machines - one fail -> 10% of CPU time fails
1 machine - one fail -> 100% of CPU time fails

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... ;)

> various discussions about problems in the past, some have been fixed,
> other problems came up.  Your mail basically says "fix this", without
> actually saying what is wrong; just accusing various people based on
> second hand knowledge.

Hrm, not exactly as I understood his original mail. 
One part of his complain was that Ryan was some sort of unresponsive,
although there were several postings on debian-mips requesting the building
of qt-x11-free, but nothing happened. *This* is some sort of unacceptable.
When people (i.e. normal maintainers/users) are forced to solve buildd
problems by hand, we don't need any buildds at all (over-emphasized), but
only a bunch of machines were DDs can login and build their packages
themselves. Of course this is nonsense.
So, the question was, how can that situation can be avoided in the future. 
In prior discussions there was always mentioned that Ryan and James are
quite busy with other tasks. Therefore the request to move this kind of
"non-important" work (compared to securing d.o-machines) to other people. 

> Number of out of dates holding up testing:
>     i386 (8), hppa (65), ia64 (66), sparc (83), powerpc (92), s390 (92),
>     m68k (100), alpha (111), arm (161), mipsel (184), mips (200)

For m68k the number could have been lower, as you know... ;-)

> ===
> [...] 
> mipsel
> ======
> [...] 
> mips
> ====
> debian-mips).  I can only say that I suggested building XFree86 (as
> per the request of the maintainer who wanted feedback for his
> experimental package) on this machine which had been offered as a
> buildd and was told that it didn't have enough disk space.  Whether

Oh, that's me.... 8-)
Well, but I told you as well, that the machine had *currently* not that much
disk space, but is being worked on that. *Most* packages don't require 3-5
GB of disk space to build. 
And shortely after I told you that there wouldn't be that much space, it was
available and could have been used. I also setup an account for Branden, but
he never used it. (I think the compromise came inbetween and he wasn't able
to login to crest where I stored the login information for him. In the
meanwhile, I'm excluded from login to crest, so I can't give away accounts
away that easy anymore... *sigh* but the machines are still available for
DDs that need access to some MIPS machines) 

> the machine would have been useful as a buildd is therefore
> questionable, but I cannot tell for sure without knowing details of

Well, you surely know the german saying "Kleinvieh macht auch Mist".
Therefore, at that time it would have been very useful. 

> the machine.  However, Ryan has mentioned before that he needs a fast
> mips box, and not another slow one.  Which almost brings me to the
> current situation.
> Just to conclude what happened after the last flamewar.  The problem
> with mips back then was that the fastest mips buildd (sgi.spamo.org)
> had hardware problems.  The owner thought it was a disk problem, so I
> told him Debian can buy new disks; he volunteered to get new ones
> himself.  He did, but as it turns out it was a different problem which
> he promptly fixed by using a component from his spare machine.  mips
> was working again without any problems after this.

Hmmm, there was an offer to one of my subscribed Irix Mailing lists for some
SGI machines to give away for free on a certain day in Oberhausen (Germany).
> (In the meantime, to make the problem worse, casals.d.o needs a new
> kernel and cannot be used as buildd in the meantime.  This should
> hopefully be fixed soon, though.)

Erm, why can't a machine be used as a buildd *and* for DDs to port/debug
their packages? Crest does both, sometimes with 2-4 builds in parallel to
the buildd. 

> So, while mips has been problematic for a while due to unfortunate
> circumstance, it's on the best way of getting fixed again.

m68k had bad luck shortly before mips last autumn. That was the reason why I
offered the mips machines.

> In summary, the currently problematic architectures are being worked
> on.

But it seems as only Ryan, James and you are know of that. For all others it
seems as nothing would happen. It would nice to have those information
better communicated to other people. If someone give me some info, I can
publicate it on www.buildd.net, but apparently I need some input for doing

We (m68k port) know from experience that when a buildd is down, the
maintainers of the stuck packages will come and ask sooner or later what's
happened to their packages. 
Therefore I setup a possibility to automatically display the status on
www.buildd.net for each buildd. But that service is living from
participating buildd admins. Currently only m68k (completely), ia64 and hppa
are participating. 
I plan for the future to automatically detect the status of the buildd
(running, NO-DAEMON-PLEASE, ...) as well and not only the machine itself.
In the meanwhile the buildd admin have to mail me a reason when a machine is
down for a longer time. 

> It should be noted, though, that most recent "cannot get
> wanna-build access" and other discussions are not about these
> currently problematic architectures, but about m68k - which, as you

Partly true. 
m68k could have a smaller backlog when adding to w-b would be faster/easier.
But adding buildds for other archs would be nice as well to work around
current problems (like a broken machine/dead disk)... 

> can see in the statistics above, is doing pretty well with the 10 (!)
> buildds they already have.  Two more are currently being build by Ingo
> Juergensmann, and they'll probably be added once they become
> available.  As pointed out in Ingo Juergensmann's message in this
> thread, some m68k systems are also needed for d-i work.  I suggest
> that Goswin's two boxes which have not been added to wanna-build
> should be used for d-i work (especially given that Goswin expressed
> interested in doing d-i m68k work int he past), and the two machines
> Ingo is working on will become part of the w-b infrastructure when
> they're ready.

Yeah, I expect the Debian-bought 060 card for tomorrow, btw. 
But to decide what machines are used for d-i work and which as a buildd is
quite difficult. Without Goswins help as a human-buildd we wouldn't have
that small backlog currently. As soon as the new buildds are up and running,
he could start d-i work again. But then again, it doesn't make much sense to
setup new buildds when you have to wait some weeks until they can get w-b
That is a problem that needs to get fixed - and that needs some sort of
communication as well. I tried to contact James on IRC when I saw him being
active, but got no response. Wouter asked him as well, iirc, so the whole
problem with the wrong key would have been solvable very quick when he
would have been responsive. *sigh*
> Anyway, I am in contact with Ryan, James and others to get arm, mips
> and mipsel addressed asap.

I would wish that we can establish a way to interact with each other in a
productive way for the sake of the project. Maybe a new mailing list for all
buildd admins (and related persons such as buildd hosters) would be nice
where announcements like the move of w-b to newraff are publicated in

Ciao...              // 
      Ingo         \X/

Reply to: