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

Re: status of buildds?



* Ian Lynagh <igloo@earth.li> [2005-03-16 02:42]:
> I believe the wanna-build admins don't want builds that have neither
> been suitably tested (such as the build that accompanies the source in
> the maintainer's upload) nor built by one of the official buildds to be
> uploaded.
> 
> The main reason, AIUI, is that such builds tend to result in a higher
> proportion of broken packages, partly because the people doing such
> builds tend to be less up on problems in the tool chain for the arch.
> 
> That said, I don't believe I've seen a public, first-hand statement to
> that effect. I think such a statement would be very useful to clear up
> the confusion on the subject.

I suppose I was CCed to provide that statement?  I'm pretty sure the
problems have been expressed in public before (even if not first-hand,
but neither is this message ;).  I can probably find links to
lists.d.o if I'd take the time to search but I hope the following
explanation is sufficient.  (If not, let me know.)

One problem, as you say above, is that random people building packages
are more likely to break things because they don't know about
architecture specific problems.  In some cases (e.g. mipsel and
libraries [1]), the build will be "successful" but the package is
still broken.  The mips buildd maintainer knows what to look for in
the logs, but most people are not aware of this.  While you can
document some of these issues, many of them are transient and change
constantly (e.g. toolchain problems).

More importantly, the problem with non-official buildds building and
uploading packages is that we are not sure whether the official buildd
would be able to build the package.  However, it is crucial that they
are able to, because guess which machine is used when we need to make
a security update?  It wouldn't be good to find out when making a
security upload that the package actually doesn't compile on our
buildds.  (Yes, there are some people who will "fix" a build problem
by making changes to their environment and then uploading a binary.)
A recent example is the mipsel build of Perl which failed on the
official buildds because their kernel was out of date.  A "fix"
would've been to just ask some random Debian developer with a mipsel
box to build and upload it, but this won't help in the long run.  The
real fix is to upgrade the kernel or add a mipsel buildd which runs a
modern kernel (the latter was done). [2]

Anyway, I don't think either of these apply to the S/390 example which
was discussed but your question was of a more general nature.


[1] For example, compare #294435 (a serious FTBFS bug) with the
"successful" buildd log in
http://buildd.debian.org/fetch.php?&pkg=papaya&ver=0.97.20031122-4&arch=mipsel&stamp=1107583458&file=log&as=raw
[2] Compare the two buildd logs from
http://buildd.debian.org/build.php?&pkg=perl&ver=5.8.4-8&arch=mipsel&file=log
-- 
Martin Michlmayr
leader@debian.org



Reply to: