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

Re: rebuilding the archive in a dirty chroot: results

Cyril Brulebois wrote:

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:

I've done two rebuilds of sid on i386.

- 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)

Then I compared the results, and I started crying. ;)

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,

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)

looking at the log[1], it seems the linking is improperly done:

dpkg-shlibdeps: warning: debian/oolite/usr/lib/GNUstep/System/Applications/oolite.app/oolite shouldn't be linked with libobjc.so.lf2 (it uses none of its symbols).

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):
oolite: (null) -> libobjc-lf2

I am confused about this since the description of the package says is a fork of the Objective C library:

libFoundation fork of the Objective-C runtime library
Library needed to run Objective-C applications which use libFoundation.

Oolite works without issues on my system and I never had this library installed.

Also, it seems that the upstream version is frozen in time and is not/poorly maintained:


I don't even know from where was the 2.95.3r115 release got from (no tags realted to 2.95.3).

I believe this is an issue with the library itself or library packaging which leads to a wrong build. Could someone contradict me and tell me the real fix?

If not, maybe oolite should Build-conflict with this lib?

[1] http://people.debian.org/~lucas/logs/2008/01/22/bdfh/logs/oolite_1.65-6_sid32-bdfh.buildlog
"Imagination is more important than knowledge" A.Einstein

Reply to: