Re: openjdk-6 build failure on m68k - problem with fork="true" ant javac target
The same problem found with ant javac targets exist with ant java targets with fork="true" this simple ant task makes ant quit directly after running the class.on m68k. I suspect i am observing a bug in libgcj with fork and not in ant itself. I have tested using the testcase found in my previous mail with following jvms on debian m68k with various results: Someone know a jvm working on debian m68k sid that i have not tested? /usr/bin/gij-4.3 and /usr/lib/jvm/java-gcj/jre/bin/java bug present with fork="true" java version "1.5.0" gij (GNU libgcj) version 4.3.2 /etc/alternatives/kaffe-system/bin/java segfaults ant exit with failure. java full version "kaffe-1.4.2" kaffe VM "1.1.8" /usr/bin/java-sablevm throws java/lang/IllegalMonitorStateException and then exit with failue. SableVM version 1.13 Have a great day! Xerxes 8 nov 2008 kl. 22.34 skrev Xerxes Rånby: I have spotted a problem with ant javac target on debian m68k. ant javac targets with fork="true" on m68k makes the whole ant build exit directly after the javac task ends. This screws the openjdk6 build on m68k since the langtools classes and bootstrap files are not fully built. I have created a testcase to reproduce this bug that can be downloaded from: http://labb.zafena.se/m68k-ant/antforktruetest.tar.gz This ant bug is present on the m68k buildd machines and can be spotted in the m68k openjdk6 buildd log by looking for the missing BUILD SUCCESSFUL after all ant builds. The first ant build in openjdk6 is run directly after sanity check is done. search for make[3]: Entering directory `/build/buildd/openjdk-6-6b11/openjdk- ecj/langtools/make' to see the ant bug in action in the m68k buildd log : http:// buildd.debian.org/fetch.cgi? pkg=openjdk-6;ver=6b11-9;arch=m68k;stamp=1223969321 I have stored my ant -diagnostics log here for reference: http://labb.zafena.se/m68k-ant/ant-diagnostics.m68k.log = Output from testcase on m68k: [EMAIL PROTECTED]:~/antforktruetest$ ant Buildfile: build.xml build: [echo] running testcase to see if ant javac work, javac task with fork='true' makes ant exit after compile on debian m68k without running all remaining tasks and targets [mkdir] Created dir: /home/xerxes/antforktruetest/destforkfalse [mkdir] Created dir: /home/xerxes/antforktruetest/destforktrue [echo] removing compiled classfiles if they exist or else they will hide the bug [echo] compiling hello world using javac task with fork='false' [javac] Compiling 1 source file to /home/xerxes/antforktruetest/ destforkfalse [echo] compiling hello world using javac task with fork='true' [javac] Compiling 1 source file to /home/xerxes/antforktruetest/ destforktrue [EMAIL PROTECTED]:~/antforktruetest$ echo $? 0 [EMAIL PROTECTED]:~/antforktruetest$ ls destforktrue HelloWorld.class [EMAIL PROTECTED]:~/antforktruetest$ cd destforktrue [EMAIL PROTECTED]:~/antforktruetest/destforktrue$ java HelloWorld Hello World! [EMAIL PROTECTED]:~/antforktruetest/destforktrue$ It is quite tricky to spot that ant have failed here since the classes are compiled with javac (works fine with java too) and ant exited with success yet ant have not run all its tasks! Compare with the output below to see that ant is broken. = Expected output from testcase (here run successfully on a ubuntu x86 installation): [EMAIL PROTECTED]:~/antforktruetest$ ant Buildfile: build.xml build: [echo] running testcase to see if ant javac work, javac task with fork='true' makes ant exit after compile on debian m68k without running all remaining tasks and targets [mkdir] Created dir: /home/xerxes/antforktruetest/destforkfalse [mkdir] Created dir: /home/xerxes/antforktruetest/destforktrue [echo] removing compiled classfiles if they exist or else they will hide the bug [echo] compiling hello world using javac task with fork='false' [javac] Compiling 1 source file to /home/xerxes/antforktruetest/ destforkfalse [echo] compiling hello world using javac task with fork='true' [javac] Compiling 1 source file to /home/xerxes/antforktruetest/ destforktrue [echo] success working ant with javac tasks! BUILD SUCCESSFUL Total time: 9 seconds [EMAIL PROTECTED]:~/antforktruetest$ = Cheers Xerxes 15 sep 2008 kl. 12.19 skrev Xerxes Rånby: On my machine i hit another build error a bit further: see the attached log My icedtea6 build is configured with ./configure --with-jar=gjar-4.3 For some reason JAVAC_CMD is unset when compiling the classlist for the openjdk-ecj bootstrap part. [EMAIL PROTECTED]:~/zero/icedtea6$ hg tip changeset: 1040:c46e727121a8 tag: tip user:[EMAIL PROTECTED] date:Sat Sep 13 09:32:12 2008 +0200 summary: 2008-09-12 Matthi
Re: Replacing stuff on d-i initrd
Hi, > > Anyway, now that I have wised up to the fact that the etch install kernels > > are > > still at 2.6.18 (how backwards is that ...) I'm quite confident that all > > that's > > needed to fix the SCSI problems is my old 2.6.18 patch (back in 2.6.18, I > > could > > still fudge the SCSI midlevel timers). I seem to have done a version for > > 2.6.21 > > but not 2.6.18 - will do that ASAP. > > There was an etch 2.6.24, but m68k never built it (or much of anything else > for etch). Tried to cross-build 2.6.18 as is currently in the archive (2.6.18.dfsg.1-12), without much success. I assume you built the etch-m68k kernels from that source? Do all the patches up to 12-extra get applied? I noticed two problems, one of which must have happened while I tried to feed my patches upstream: m68k-atari-scsi.patch and m68k-atari-scsi2.patch were supposed to be applied on top of each other instead of exclusive. m68k-atari-scsi2.patch fails to apply in this situation so Christian must have backed out the first one. Now the first one is the one that unmarks the Atari SCSI driver as broken - backing it out would result in the SCSI driver not getting built. The other one is with the IDE code - from the 2.6.18.dfsg.1-12 source, I would expect to get loads of ide_release_lock: bug messages, plus the IDE interrupt handler is registered twice. The di kernels appear to have both SCSI and a warning-free IDE driver, so what am I doing wrong here? > That's once of the reasons I want some form of lenny: etch, how old is that? > ;) > > Maybe next week. Should we focus on testing the sid installer then? Anything you would like me to help with lenny? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
