Re: requalification of arm as etch release architecture
+++ Riku Voipio [05-10-10 12:56 +0300]:
> On Sun, Oct 09, 2005 at 12:45:09PM -0400, Joey Hess wrote:
> This needs to be obviously fixed. I have a machine that can be probably
> relocated for this purpose, I just need to find a spot to host it.
We have numerous offers of spots. Black networks and Bytemark are both ISPs
that have offered to host machines (in the UK). Is your machine faster than
the current kit? This is important, as it seems that (for buildd, as opposed
to developer access box) fewer fast boxes are strongly favoured by the
admins/release team over hordes of slower ones.
I gather that Nokia is interested in providing hardware and admin and
probably have good connectivity too. Can you coordinate with Jesus Climent
to make that happen?
>
> I added myself, altough I'm catching up myself as well.
Cool - I thought you should be on the list. Now you have to go to
buildd.debian.org and fix some build-failures...
> > - Not having enough users listed;
>
> This shouldn't be a problem, if we can just find them. Many vendors
> seem to ship their arm stuff with debian. I think we need to get in
> touch with them, to get actual hardware sold with debian officially
> supported..
I'm quite sure we have a lot more than 50, but we do need to actually show
it. Get the word out... An awful lot aren't running exactly Debian though,
just something based on debian.
> > - Not having info on who's supporting toolchain stuff etc;
>
> I believe codesourcery is supporting gcc and glibc upstream.
True, although they are working towards a different ABI from the one Debian
is using which could become a problem in the medium term. Potential ABI
changes is somethine else we need to discuss further in another thread.
> > - Only being up-to-date for a very poor 94% of the archive currently
> > and only having built a likewise poor 91% of the archive.
> > (And thus probably being next in line after m68k, which has just
> > started being ignored for testing propigation). A lot of this comes
> > down to build failures, eg perl currently fails to build on arm,
> > which is really painful for the release team.
>
> Unfortunatly buildd maintainer is not communicating such issues
> forward..
We are supposed to look ourselves and pro-actively fix things. But yes, I
hadn't really appreciated that we had a problem either till recently. So
henceforth more of us should be keeping an eye on the status and fixing
issues/helping maintainers fix issues. There is a really good status page
that I only have the URL for at home...
> > - Requiring a lot more than two buildds to stay as current;
> > - Not having sufficient buildd redundancy for when the next netwinder
> > does a halt and catch fire.
>
> Current buildd's are quite old. If we can get hold of faster arm systems
> with more ram it should be easier. Also, if I have understood correctly,
> the objection of more than two buildd's comes from the maintainence
> overhead.
It is not just maintainance (although that is an issue). There is also the
time it takes for a large security update, or otherwise important build
(e.g. holding up a transition) (kernel, X, glibc) to get built. Having more
buildds makes no difference to how long this takes. The security and release
people want to see this quantum as small as possible, so faster is better.
In the medium term I expect the difference in speed between arm and faster
arches to get wider rather than narrower so I think we may need to have arm
buildds using distcc farming out compiles to faster hardware. It's something
the armeb guys are playing with at the moment. It adds complexity but should
keep the build quantum down (if it works reliably).
Wookey
--
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Reply to: