Re: Explications needed...
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
$port@buildd.debian.org; 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
$port@buildd.debian.org 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.
vorlon@debian.org http://www.debian.org/
Reply to: