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.
Attachment:
signature.asc
Description: This is a digitally signed message part