Re: rebuilding the archive in a dirty chroot: results
Cyril Brulebois wrote:
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 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,
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)
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:
http://www.opengroupware.org/en/devs/thirdparty/libFoundation/index.html
http://svn.opengroupware.org/viewcvs/trunk/libFoundation/?root=ThirdParty
http://www.geocities.com/SiliconValley/Monitor/7464/libFoundation/
http://libfoundation.cvs.sourceforge.net/libfoundation/libFoundation/
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
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
Reply to: