Hi. 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): --------------------------------- desmume donkey-bolonkey fillets-ng-data fillets-ng lordsawar netpanzer powermanga sabre supertuxkart xbat xtux 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 binaries. FTBFS: ------ 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 Cheers, -- Cyril Brulebois
Attachment:
pgpGlN60Jv8ZS.pgp
Description: PGP signature