Your message dated Sat, 01 Nov 2008 14:50:16 +0000 with message-id <[EMAIL PROTECTED]> and subject line re: imagej: java bytecode / java runtime version mismatch has caused the Debian Bug report #503777, regarding imagej: java bytecode / java runtime version mismatch to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 503777: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503777 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems
--- Begin Message ---Package: imagej Version: 1.41n-1 Severity: serious User: [EMAIL PROTECTED] Usertags: jbc-mismatch This package builds with openjdk-6 or cacao-oj6, which is not the default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac creates java bytecode for version 50, which cannot be used by older jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6 must not depend on java-runtime{,1,2,5}{,-headless}, but only on java-runtime6{,-headless} or any of the non-virtual packages providing a java6 runtime. It is preferred to build the bytecode so that it runs on older jvms. This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks setting ANT_OPTS to -Dant.build.javac.source=1.[45]. You usually can check for the java byte code with file(1), currently broken in testing/unstable, or use javap -verbose (a script checking the command line args (check-class-version) can be found at http://people.debian.org/~doko/tmp/. Both .class and .jar files found in the binary packages need to be checked. Note: this report may be a false positive, if all bytecode files have version 49 or less.
--- End Message ---
--- Begin Message --- This also seems to be a false positive, the highest class version in ij,jar (checked with the binary in lenny, the binary in sid and a fresh build of the sid version on a machine with openjdk as the default jdk) is 49 so presumablly the build process is already controlling the versions.
--- End Message ---
