On Wed, May 16, 2012 at 07:18:21AM +0200, Christoph Egger wrote:
Hi all!
Christoph Egger<christoph@debian.org> writes:
Christoph Egger<christoph@debian.org> writes:
Robert Millan<rmh@debian.org> writes:
2012/5/12 Damien Raude-Morvan<drazzib@debian.org>:
Also it might be worth trying with a chroot hosted on kfreebsd 8.1.
I tried exactly that and on my stable system openjdk-7 fails exactly as
on the buildds in the usntable chroot. Will now try if I can get it
running with a 8.3 kernel and check what happens there (keeping the rest
on stable, chroot on unstable).
It's still failing on this mostly-squeeze-but-8.3-kernel system. I'll
try and upgrade piece-after-piece to wheezy and see where it starts to
work.
Changing kernels did not fix this problem in any way. What did make
openjdk-7 compile was switching from stable's sbuild/schroot to
wheezy's. I thnk it's rather strange that this does have any effect but
did indeed work. Adding Roger as sbuild/schroot maintainer into cc maybe
he has some insight on what did notably change between the stable (or
rather buildd) version and unstable that might have an impact.
Some ideas for checking:
1) Run dpkg-buildpackage by hand to eliminate sbuild as the problem:
For both the old and new versions of schroot (example, assuming a
session-managed chroot on amd64):
SESS=$(schroot -b -c unstable-kfreebsd-amd64-sbuild -n testopenjdk)
schroot -u root -c $SESS -- apt-get build-dep openjdk-7
schroot -c $SESS -- apt-get source openjdk-7
schroot -c $SESS -d openjdk-7-$ver -- dpkg-buildpackage -us -uc
schroot -e -c $SESS
You can also run schroot with "-v --debug=notice" to see if there
is any difference in the user environment when running
dpkg-buildpackage.
2) sbuild just runs dpkg-buildpackage, but it's possible that the
environment has subtly changed; the buildd version of sbuild is
very dated now, and there have been a few changes. It's mainly
relating to build-deps though, e.g. we use the "apt" resolver
by default rather than "internal". "apt" is a better resolver,
and should behave 100% identically to internal, but it's possible
if you're depending on e.g. a virtual package, you might get
different concrete packages installed, which could affect your
build. Another case where this differs is that internal can't
handle multiarch build-deps at all, and never will.
sbuild logs a complete list of everything installed by it, so
definitely worth looking at that.
Regards,
Roger