Some of the comments and questions in this thread suggest gaps in understanding of the autobuilders, which I think warrant an answer. Hopefully this doesn't lead to more flames and recriminations...
On Wed, Dec 20, 2006 at 05:03:35PM +0100, Pierre Habouzit wrote: > Aurelien mailed debian-arm, went to #debian-arm, had no response. He > then warn about his intention [1] to run qemu-based autobuilders to fill > the gap due to broken arm buildds. He did that on the open, and got ... > zero answers. So first of all, neither the debian-arm list, nor the #debian-arm channel, nor his blog are a communication medium that's guaranteed to reach the arm buildd maintainer *or* the buildd local admins. For the former, you want [EMAIL PROTECTED]; for the latter, there is no list of contacts other than the buildd maintainer, since these may change semi-frequently and most buildd changes need to be coordinated with the buildd maintainer anyway. Now, many people will probably object, pointing out that [EMAIL PROTECTED] is widely regarded as a blackhole. I'm sorry, I can't offer any particular insight into the mail answering policies of the buildd maintainers; but it's not reasonable to not contact the one party responsible for the buildds about your plans just because you don't think you'll get a response, and then claim you've taken all appropriate measures to communicate with people before going ahead. > So, why : > * does aurelien initiative causes troubles ? If the packages he uploads have already been built (but not uploaded) by the autobuilders, the packages in the archive will not correspond to the public build logs, which reduces the utility of buildd.debian.org as a debugging tool. It will also leave the buildd maintainer with errors when he does upload the autobuilt packages and ftp-master rejects them as duplicates. If he only uploads packages that haven't been built by the autobuilders, or failed to build on the autobuilders, we still have the problem that there is no single party who can account for the configuration of all the buildds that were used for uploading packages, because there has been no coordination -- so building these packages on rogue autobuilders is a poor predictor of whether the autobuilders will be able to build them again later when a security update is needed. Indeed, in the case of Aurelien's buildds, we have the additional variable of using emulated arm systems -- I don't know what ARM instruction set qemu emulates, and I don't know who else among the ARM porters knows, maybe it's been discussed and maybe it hasn't, but it's definitely another variable that contributes to these buildds being a poor predictor for the official autobuilders. (Thankfully, he doesn't mention any use of distcc+cross-compiling here -- having a cross-compiler that does fp math differently than a native compiler does because of arm's fp pecularities would be yet another twist we don't need...) Uploading packages like this is an expedient fix that does nothing to help, and possibly quite a bit to hinder, long-term support for etch. We want to fix autobuilder problems, not cover them up. > * do someone found the time to blacklist everybody except elmo, > whereas no one found the time to fix the arm build daemons ? What "fixing" are you talking about? Who has been informed of problems with the build daemons, and when? The only hidden buildd breakage I've been made aware of is the broken libtasn1-3 install on netwinder; this was mentioned to me only after Aurelien's buildds started up, and I passed this information on to the local admin immediately (which is Bdale, btw; given that Aurelien has identified himself as an ARM porter "for the release", I would hope he knows this already?). If there are specific instances of broken buildd chroots on ARM, feel free to Cc: debian-release in case James is swamped. The release team would always rather know if there are problems with buildds, and I can pass word on to local admins in case the problem is something they can fix. On Thu, Dec 21, 2006 at 11:39:13AM +0100, Aurelien Jarno wrote: > All started with this email: > http://lists.debian.org/debian-arm/2006/08/msg00151.html > ARM was *in danger*, a lot of stuff (java, xulrunner, mono, ...) were > not working correctly. People worked hard to fix that, but it was very > difficult to get packages depending on fixed stuff to get requeued. Also > a lot of "arch-specific compile errors" were actually due to build > daemon problems. Yes, let's be clear here: ARM was in danger because of a large number of packages that were *not buildable*, not just because they weren't built. The call for help was in identifying the reasons for the build failures so that the underlying problems could be fixed, *not* for hand-building packages and ignoring the implications for security support. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
