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

Re: rebuilding the archive in a dirty chroot: results


Let me quote the full mail from Lucas first, for those of us not reading
debian-devel. Summary of our packages follow.

On 25/01/2008, Lucas Nussbaum wrote:
> Hi,
> I've done two rebuilds of sid on i386.
> - one in a perfectly clean chroot, as I usually do
> - one in a chroot, where as many build-dependancies as impossible were
>   installed (take the Sources file, extract the build-deps for all
>   packages, and install as many packages as possible) (the chroot is
>   named bdfh -- build daemon from hell)
> It is important that packages build in the same way (same binary
> packages generated) in both cases, because:
> - some maintainers still don't build in clean chroot
> - buildds don't necessarly cleanup all build-deps after build,
>   so you don't know in which environment your packages are being
>   built
> Then I compared the results, and I started crying. ;)
> 236 packages built fine in the clean chroot, but failed to build in
> the dirty chroot.  In some cases, it's caused by automake1.4 being
> installed, and not being removed by sbuild.
> 35 packages failed in both the clean and the dirty chroot, but with
> different reasons, apparently (I have a script that tries to "guess"
> the reason for a failed build, but it's far from being 100% reliable)
> 938 packages produced different binary packages according to debdiff.
> Of those, 477 produced different Depends line (caused by some features
> not being explicitely enabled, but not being explicitely disabled,
> usually).
> All the results are available from
>   http://people.debian.org/~lucas/logs/2008/01/22/bdfh/
> failed.txt: list of packages that failed to build
> failed-ddlist.txt: same, dd-list'ed
> debdiffs.txt: list of packages that produces different binaries
> debdiffs-ddlist.txt: same, dd-list'ed
> logs/: logs for all the builds. For each package, you get two log files:
>   one ending with sid32-bdfh.buildlog (build in the dirty chroot)
>   one ending with sid32.buildlog (build in the clean chroot)
> debdiffs/: debdiff output
> Of course, the list includes some false positives, but they are
> difficult to identify without going through all the debdiff outputs
> and build logs manually.
> I'm not really sure of what we should do about those problems. The
> easiest way to fix them is to use source-only uploads (to avoid
> packages built on broken maintainer machines), and a better sbuild
> that can use lvm snapshots so that it can start all builds with a
> clean environment.

debdiff (Depends changes):
boson: python2.4 -> python2.5
desmume: (null) -> libzzip-0-13
donkey-bolonkey: libxxf86dga1 -> libxcursor1
fillets-ng: (null) -> libfribidi0
lordsawar: (null) -> libggzdmod6, libggzmod4
mines.app: libobjc2 -> libobjc-lf2
oolite: (null) -> libobjc-lf2
prboom: (null) -> libpng12-0
stepbill: libobjc2 -> libobjc-lf2
supertuxkart: (null) -> libvorbisfile3

debdiff (Installed-Size differs):

I guess those might be due to slightly different PDF documents, various
header glitches, stuff depending on a timestamp or whatever. I don't see
how to distinguish between them without looking at the generated

jugglemaster: WxWidgets mess, at first glance. [1]
warzone2100: False positive. [2]

 1. http://people.debian.org/~lucas/logs/2008/01/22/bdfh/logs/jugglemaster_0.4-1_sid32-bdfh.buildlog
 2. http://people.debian.org/~lucas/logs/2008/01/22/bdfh/logs/warzone2100_2.1.0~0.svn3330-1_sid32-bdfh.buildlog


Cyril Brulebois

Attachment: pgpoBCBpl3xro.pgp
Description: PGP signature

Reply to: