Re: OpenJDK-7 on kFreeBSD (feedback)
On Wed, May 16, 2012 at 07:18:21AM +0200, Christoph Egger wrote:
> Hi all!
> Christoph Egger <email@example.com> writes:
> > Christoph Egger <firstname.lastname@example.org> writes:
> >> Robert Millan <email@example.com> writes:
> >>> 2012/5/12 Damien Raude-Morvan <firstname.lastname@example.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
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.
.''`. 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