[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OpenJDK-7 on kFreeBSD (feedback)



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

-- 
  .''`.  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


Reply to: