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

Re: arm release issues



On Mon, Aug 28, 2006 at 08:13:06PM +0200, Andreas Barth wrote:
> we (the release team) noticed that arm has had some autobuilding and porting
> problems in the past few weeks. According to the most recent britney runs,
> the current numbers of uncompiled binaries are these:
>     110 mips
>     116 sparc
>     222 ia64
>     229 m68k
>     267 hppa
>     277 arm
> 
> hppa and ia64 are only temporarily bad, but arm has shown these problems for
> some time now. One of the most troublesome packages is xulrunner, as
> quite a few packages (build-)depend on it. It is yet unknown what the problem
> is, if e.g. a longer build timeout might help, or what else is required.
> 
> We want to ask you to help working on packages that are out-of-date on arm,
> especially tracking down arch-specific compile errors. To allow *us* to
> continue with the release preparations, we decided to configure the testing
> migration script to ignore missing binaries on arm for now.
> 
> As the release is getting nearer, we would like to see this situation resolved
> within the next three weeks, or we will have serious issues with either the
> timely release of Debian at all, or with the integration of arm into it.

Well xulrunner seems to have an issue with javac based on this last part
of the build log:

Compiling Java interface classes
find _javagen -name "*.java" > java.files
/usr/lib/jvm/java-gcj/bin/javac -source 1.4 -classpath . -d . -sourcepath _javagen @java.files
Exception in thread "main" java.lang.NoClassDefFoundError: org.eclipse.jdt.core.compiler.IProblem
   <<No stacktrace available>>
make[3]: *** [org/mozilla/xpcom/.class_done] Error 1
make[3]: Leaving directory `/build/buildd/xulrunner-1.8.0.5/extensions/java/xpcom/interfaces'
make[2]: *** [tier_99] Error 2
make[2]: Leaving directory `/build/buildd/xulrunner-1.8.0.5'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/build/buildd/xulrunner-1.8.0.5'
make: *** [build-stamp] Error 2

I seem to recall a bunch of java problems on arm in the past with
packages having to use a different java compiler on arm compared to
what was used on other architectures.  I don't remember if that was
ever fixed.  I think it was jikes that was broken, and gcj that worked
for the particular packages.

--
Len Sorensen



Reply to: