On Wed, May 16, 2012 at 07:18:21AM +0200, Christoph Egger wrote: > Hi all! > > Christoph Egger <[email protected]> writes: > > Christoph Egger <[email protected]> writes: > >> Robert Millan <[email protected]> writes: > >>> 2012/5/12 Damien Raude-Morvan <[email protected]>: > >>> 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 -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
