Re: OpenJDK build attempts on the testing security infrastructure
[sorry for not replying earler. please CC the package maintainer address, I don't read debian-java
on a daily basis]
Florian Weimer schrieb:
> Here are the results of building some OpenJDK packages on the security
> buildd infrastructure (with the test suites disabled).
thanks for doing this.
> First, for openjdk-6 6b11-6+lenny1, we have:
>
> Successes: amd64, armel, i386, ia64, mips, mipsel, powerpc, sparc
> Failures: alpha, s390
>
> The s390 failure may be due to too little RAM allocated to the instance
> (on lxdebian.bfinv.de).
tried to work around this prentending to have at least some amount of RAM (packages in
experimental); the buildds may swap, but hopefully succeed. unfortunately it's the openjdk build
system implementing these 'constraints'. The experimental buildd doesn't show this failure, but
chokes on insufficiant disk space. hurray!
> The alpha failure is:
>
> gcc-4.3 -O3 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -D_LITTLE_ENDIAN -g -D_alpha_ -DARCH='"alpha"' -DLINUX -DRELEASE='"1.6.0_0"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -D_LP64=1 -I. -I/build/buildd/openjdk-6-6b11/openjdk/control/build/linux-alpha/tmp/java/java.lang.management/management/CClassHeaders -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/javavm/include -I../../../src/solaris/javavm/include -I../../../src/share/native/sun/management -I../../../src/share/native/common -I../../../src/solaris/native/common -I../../../src/share/native/java/lang/management -I../../../src/solaris/native/java/lang/management -c -o /build/buildd/openjdk-6-6b11/openjdk/control/build/linux-alpha/tmp/java/java.lang.management/management/obj64/UnixOperatingSystem_md.o ../../../src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
> In file included from /usr/include/sys/procfs.h:31,
> from ../../../src/solaris/native/com/sun/management/UnixOperatingSystem_md.c:52:
> /usr/include/sys/user.h:27:22: error: asm/page.h: No such file or directory
> In file included from ../../../src/solaris/native/com/sun/management/UnixOperatingSystem_md.c:52:
> /usr/include/sys/procfs.h:32:21: error: asm/elf.h: No such file or directory
> In file included from ../../../src/solaris/native/com/sun/management/UnixOperatingSystem_md.c:52:
> /usr/include/sys/procfs.h:76: error: expected specifier-qualifier-list before 'elf_gregset_t'
>
> The alpha buildd needed more that five hours to reach that point.
the alpha build succeeds on the experimental buildd.
> Build times are generally acceptable, with the exception of armel,
> which needed almost 45 hours.
you could reduce this by some hours by using openjdk-6 itself as the staging system. I didn't try
this yet, so I can't give the exact figures.
> The picture for cacao-oj6 6b11-2+lenny1 is like this:
>
> Successes: amd64, armel, i386, s390
> Failures: powerpc
>
> The powerpc failure is due to a cyclic build dependency, IOW we simply
> could not test the build.
powerpc can be configured to use gcj as a stage1 system as well. I think build time is not critical
on powerpc, so you may prefer this.
> armel is at about 19 hours, so almost acceptable. However, in
> practice, this likely adds to the 45 hours of openjdk-6, resulting in
> 64 hours of total build time, which is totally out of question.
> Otherwise, the build times are fine.
this calculation is only true if you have to fix something in both the zero port and the cacao port
(or the jdk). If you have to fix something in the hotspot runtime only, it is safe to announce
changes once amd64, i386 and sparc are built. assuming you have to buildds this is 45h (or less if
using openjdk as the staging system).
> The package tried to build on mipsel, blocking the buildd for extended
> periods of times. This has to be fixed.
I don't have results for mips* myself. the experimental buildds didn't try to build the packages yet.
> Consequently, it would seem attractive to trade cacao-oj6 for openjdk-6
> on ARM.
besides the better test results for openjdk-6.
> I'm not sure what to do about the alpha and s390 build issues.
me neither. alpha is attractive because it's the only available runtime/development env. on this
platform (and who knows if we will have another release for alpha ...).
For Ubuntu I did go on with the b12 code drop and the current icedtea updates, which show comparable
results on i386, amd64, sparc, ia64, powerpc. Alpha doesn't seem to be a problem as shown on the
experimental buildd, but I can't say much about s390, mips, mipsel and armel (both for openjdk and
cacao). I won't have the time during the next three or four weeks to further work on these packages
for a probable upload to unstable. But it's not just me in the maintainer team, so if somebody else
wants to push this, please go ahead. Looking at the bts you'll see that most issues reported for the
Debian packages are resolved in the experimental packages.
Matthias
Reply to: