Dear developers, [My post involve only technical issues which are orthogonal to the current GR which addresses the non-technical issues.] On Thu, Jan 25, 2007 at 01:23:35AM +0000, James Troup wrote: > Why restrictions on binary uploads? > =================================== > > So there are several reasons why these restrictions have been put in > place: > > (o) reproducibility > > It's vitally important that packages in our archive can be rebuilt on > our buildds and not require a custom environment or source > modifications or other special treatment. When they can't, scaled > across as many packages and architectures as we have, it makes the job > of the security team nearly impossible. Fortunately, db.debian.org includes the sbuild package which allow to perform build in the same way as buildd do. Aurelien Jarno used sbuild. Where are the evidence any of those builds were broken ? > The best (and IMO, only) pragmatic way of doing this is to actually > have built them on a real buildd. Unfortunately the set of buildd machines tend to change during a stable release life. Thus we need more garanties than "it build on _that_ buildd". In the past this has been an issue when s390 buildd has been upgraded to s390x. So it is smarter to spread builds over a larger set of hardware to be able to anticipate such issues before a release. > (o) logging > > The build logs at buildd.debian.org are invaluable in trying to debug > problematic builds. Byhand builds and other unofficial builds often > don't send an associated log to buildd.debian.org. Building with sbuild automatically send a log to be published on <buildd.debian.org>. See for example on I posted: <http://buildd.debian.org/fetch.cgi?pkg=bmpx;ver=0.36.0-1;arch=m68k;stamp=1166441322> (I am the developer who proposed a patch for debuild to create the .build log file automatically, so I certainly know about the value of logfiles. I would be quite happy if buildd.debian.org allowed to upload them). > (o) build effort coordination > > There's a reason the buildd suite is called 'wanna-build'. The core > of it, both when Roman first wrote it all those years ago and now, is > the sensible and efficient coordination of builds amongst multiple > build daemons. Having a random additional build daemon that's not > part of the 'wanna-build' system breaks this and all the advantages it > brings. Actually there is an easy way to avoid breaking wanna-build: The wanna-build state is available e.g. from buildd.net: <http://unstable.buildd.net/buildd/m68k_Needs-Build_queueorder.html> <http://unstable.buildd.net/buildd/m68k_Building.html> etc. So it is quite simple to check if a package is marked as Building in wanna-build before building and uploading it. Personnally I also send an email to debian-68k and a buildd admin register my build. > (o) emulated/cross-compiled buildd-ing considered potentially harmful The only way to know is to try, which I did. <http://people.Debian.org/~ballombe/misc/gnumeric_on_aranym.png> I never hit any issue with my distcc/crosscc cross-compiling setup. With aranym, I hit some issues with the FPU emulation but they did not affect the packages: Octave build fine but the test-suite displayed problem inside the emulator, however the test-suite run on the same binary on real hardware did not, so the package was correctly built. Whether they should be used is the choice and responsibility of the porters, a duty some buildd admins have relinquished at Vancouver. So in summary it is possible to do broken binary-only upload as well as broken sourceful upload, but it is possible to do correct sourceful upload as well as correct binary-only upload. The solution in both cases is to draft guidelines and policies instead of disabling them. Cheers, -- Bill. <ballombe@debian.org> Imagine a large blue swirl here.
Attachment:
signature.asc
Description: Digital signature