On Sun, 2009-10-25 at 15:00 +0100, Frans Pop wrote: > On Sunday 25 October 2009, Ian Campbell wrote: > > I was unable to reproduce in an uptodate i386 sid chroot. I'm not sure > > which environment these builds occur, maybe it's a testing thing? > > No, daily images get build in a sid environment.
Thanks. I still cannot reproduce so I am somewhat clutching at straws. I compared the logs for a local (successful) i386 run of the daily-build script vs. the logs from http://people.debian.org/~joeyh/d-i/build-logs.html I've been concentrating on the netboot-gtk log and the differences are really rather small up until the failure point. The output from apt and/or dpkg differs a little -- I wonder if the build environment is not completely up to date and has a buggy (or just slightly differing in behaviour) version of one or the other? Seems unlikely to have effected so many build servers though (seemingly admin'd by several different people). FWIW I'm running apt 0.7.24 and dpkg 1.15.4.1. The "Object: " and "Objects: " lines printed by "library reduction pass 1" seem to be the same in both the failed and local successful builds, although the ordering is different. The symbol _nss_files_parse_sgent is provided by /lib/libc.so.6 and required by /lib/libnss_files.so.2. Both libraries are part of libc. Comparing a manual "make build_netboot-gtk" with the daily-build logs (either my local ones or the build server ones), I see this which seems odd: cp -a `find ./tmp/netboot-gtk/tree/extraudebs-tmp/lib -name '*.so.*'` ./tmp/netboot-gtk/udeblibs +find: `./tmp/netboot-gtk/tree/extraudebs-tmp/lib': No such file or directory +cp: missing destination file operand after `./tmp/netboot-gtk/udeblibs' +Try `cp --help' for more information. +make[2]: [stamps/tree-netboot-gtk-stamp] Error 1 (ignored) Immediately before this the extraudebs-tmp directory is created by installing a bunch of stuff into it: dpkg --force-overwrite --log=/dev/null --root=./tmp/netboot-gtk/tree/extraudebs-tmp --unpack \ udebs/cdebconf-newt-entropy.udeb udebs/cdebconf-text-entropy.udeb udebs/cdebconf-gtk-entropy.udeb Selecting previously deselected package cdebconf-newt-entropy. (Reading database ... 0 files and directories currently installed.) Unpacking cdebconf-newt-entropy (from .../cdebconf-newt-entropy.udeb) ... Selecting previously deselected package cdebconf-text-entropy. Unpacking cdebconf-text-entropy (from .../cdebconf-text-entropy.udeb) ... Selecting previously deselected package cdebconf-gtk-entropy. Unpacking cdebconf-gtk-entropy (from .../cdebconf-gtk-entropy.udeb) ... which does sort of suggest a dpkg issue, or perhaps corrupted udebs? Sorry that I can't provide any more concrete ideas what might be going on. Perhaps it would be useful if mklibs printed a bit more detail about where and why a symbol is thought to be required if an error occurs? The current version of http://people.debian.org/~joeyh/d-i/build-logs.html seems to suggest even bigger issues though, every arch "failed to download summary log" Ian. -- Ian Campbell You'll wish that you had done some of the hard things when they were easier to do.
signature.asc
Description: This is a digitally signed message part
