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

rebuilding the archive in a dirty chroot: results


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

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

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.
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |

Reply to: