Bug#764630: RFS: javatools 0.48 [RC]
On 30.12.2014 19:19, tony mancill wrote: [...] > Uploaded to unstable. Markus, would you be willing to file the unblock > request for this bug? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774255 Done. Thanks for the upload tony! signature.asc Description: OpenPGP digital signature
Bug#764630: RFS: javatools 0.48 [RC]
On 12/29/2014 02:15 PM, Markus Koschany wrote:
> On Sun, 21. Dec 09:57 tony mancill wrote:
>> On 12/15/2014 12:06 AM, Mathieu Malaterre wrote:
>>> On Sun, Dec 14, 2014 at 6:50 PM, Markus Koschany wrote:
>>> [...]
Actually what was the reasoning behind the choice to use a custom shell
script like jarwrapper instead of jexec to register executable jars with
binfmt-misc? This question also came up in the bug report.
>>>
>>> Here is my guess:
>>> `jexec` only works with openjdk installed. At one point debian had
>>> multiple java implementation (sun, kaffe...). These days only two
>>> really remains, so maybe an easier solution would be to have a
>>> `gcj-exec` provided by `gcj-jdk` to mimic openjdk package. Which means
>>> it would be much easier to handle the LD_LIBRARY_PATH issue within the
>>> `gcj-exec` executable.
>>>
>>> jarwrapper is only really needed with a custom jre installation...
>>
>> That sounds reasonable to me, although it can be hard in practice to
>> keep things functional for users running non-Debian JRE packages. Which
>> is not to say that we shouldn't generally discourage jarwrapper...
>
> I think before we create another solution like gcj-exec, it is easier to
> maintain the current implementation of jarwrapper. I agree that gcj's
> handling of LD_LIBRARY_PATH and Multiarch could be improved but in my
> opinion there are other aspects about gcj which deserve even more
> attention. Most modern Java applications just don't work with it.
>
> I suggest to upload the fix for #764630 now. I just saw tony's email
> from the 21th. The current state on master is final. I haven't planned
> any further changes to jarwrapper. Please go ahead.
Uploaded to unstable. Markus, would you be willing to file the unblock
request for this bug? Attached are the debdiffs for the upload I
performed. As the author of this change, you're in the best position to
discuss specifics with the Release Team if there are any questions.
If you'd rather not, please let me know and I'll do it. I think we want
this change for jessie, if that's still possible.
Thank you,
tony
diff -Nru javatools-0.47/debian/changelog javatools-0.48/debian/changelog
--- javatools-0.47/debian/changelog 2014-09-10 13:42:21.0 -0700
+++ javatools-0.48/debian/changelog 2014-12-11 22:44:41.0 -0800
@@ -1,3 +1,16 @@
+javatools (0.48) unstable; urgency=medium
+
+ * Team upload.
+ * jarwrapper: Add MULTIARCH_LIBRARY_PATH variables for 32bit and 64bit arches
+which contain all known multiarch jni library paths and use this as
+value for -Djava.library.path depending on the JVM that is used to
+launch the application. Add an additional check for the GIJ bytecode
+interpreter and let it handle the library path by itself.
+This ensures that all JVM will find the corresponding libraries correctly.
+(Closes: #764630)
+
+ -- Markus Koschany Fri, 05 Dec 2014 10:38:23 +0100
+
javatools (0.47) unstable; urgency=medium
* Team upload.
diff -Nru javatools-0.47/jarwrapper javatools-0.48/jarwrapper
--- javatools-0.47/jarwrapper 2014-09-10 12:33:53.0 -0700
+++ javatools-0.48/jarwrapper 2014-12-11 22:44:41.0 -0800
@@ -19,7 +19,7 @@
JAVAOPTS="$(perl -0nE 's{\r?\n\s}{}gsm; print $1 if m{^Debian-Java-Parameters:\s*([^\r\n]+)}m;' "$TEMP/META-INF/MANIFEST.MF")"
rm -rf "$TEMP"
-for i in $NEW_JAVA_HOMES; do
+for i in $NEW_JAVA_HOMES; do
if [ -x "$i/bin/java" ]; then
JAVA="$i/bin/java"
JAVA_HOME="$i"
@@ -33,9 +33,25 @@
JAVA=java
fi
+MULTIARCH_LIBRARY_PATH_32BIT="/usr/lib/jni:/usr/lib/arm-linux-gnueabi/jni:/usr/lib/arm-linux-gnueabihf/jni:/usr/lib/i386-gnu/jni:/usr/lib/i386-linux-gnu/jni:/usr/lib/i386-kfreebsd-gnu/jni:/usr/lib/mips-linux-gnu/jni:/usr/lib/mipsel-linux-gnu/jni:/usr/lib/powerpc-linux-gnu/jni:/usr/lib/powerpc-linux-gnuspe/jni:/usr/lib/sparc-linux-gnu/jni:/usr/lib/x86_64-linux-gnux32/jni:/usr/lib/hppa-linux-gnu/jni:/usr/lib/sh4-linux-gnu/jni:/usr/lib/m68k-linux-gnu/jni"
+
+MULTIARCH_LIBRARY_PATH_64BIT="/usr/lib/jni:/usr/lib/alpha-linux-gnu/jni:/usr/lib/x86_64-linux-gnu/jni:/usr/lib/aarch64-linux-gnu/jni:/usr/lib/x86_64-kfreebsd-gnu/jni:/usr/lib/powerpc64-linux-gnu/jni:/usr/lib/powerpc64le-linux-gnu/jni:/usr/lib/s390x-linux-gnu/jni:/usr/lib/sparc64-linux-gnu/jni"
+
if which "$JAVA" >/dev/null 2>&1; then
- export LD_LIBRARY_PATH=/usr/lib/jni
- exec $JAVA $JAVAOPTS -Djava.library.path=/usr/lib/jni -jar "$JAR" "$@"
+if java --version 2>&1 | grep "GNU libgcj" > /dev/null; then
+# Let GNU gij handle the library path by itself
+export LD_LIBRARY_PATH=/usr/lib/jni
+exec $JAVA $JAVAOPTS -jar "$JAR" "$@"
+fi
+if java -d32 2>&1 | grep "does not support" > /dev/null; then
+# 64bit
+export LD_LIBRARY_PATH=$MULTIARCH_LIBRARY_PATH_64BIT
+exec $JAVA $JAVAOPTS -Djava.library.path=$MULTIARCH_LIBRARY_PATH_64BIT -jar "$JAR" "$@"
+else
+# 32bit
+export LD_LIBRARY_PATH=$MULTIARCH_LI
Bug#764630: RFS: javatools 0.48 [RC]
On Sun, 21. Dec 09:57 tony mancill wrote: > On 12/15/2014 12:06 AM, Mathieu Malaterre wrote: > > On Sun, Dec 14, 2014 at 6:50 PM, Markus Koschany wrote: > > [...] > >> Actually what was the reasoning behind the choice to use a custom shell > >> script like jarwrapper instead of jexec to register executable jars with > >> binfmt-misc? This question also came up in the bug report. > > > > Here is my guess: > > `jexec` only works with openjdk installed. At one point debian had > > multiple java implementation (sun, kaffe...). These days only two > > really remains, so maybe an easier solution would be to have a > > `gcj-exec` provided by `gcj-jdk` to mimic openjdk package. Which means > > it would be much easier to handle the LD_LIBRARY_PATH issue within the > > `gcj-exec` executable. > > > > jarwrapper is only really needed with a custom jre installation... > > That sounds reasonable to me, although it can be hard in practice to > keep things functional for users running non-Debian JRE packages. Which > is not to say that we shouldn't generally discourage jarwrapper... I think before we create another solution like gcj-exec, it is easier to maintain the current implementation of jarwrapper. I agree that gcj's handling of LD_LIBRARY_PATH and Multiarch could be improved but in my opinion there are other aspects about gcj which deserve even more attention. Most modern Java applications just don't work with it. I suggest to upload the fix for #764630 now. I just saw tony's email from the 21th. The current state on master is final. I haven't planned any further changes to jarwrapper. Please go ahead. Regards, Markus signature.asc Description: Digital signature
Bug#764630: RFS: javatools 0.48 [RC]
On 12/14/2014 09:50 AM, Markus Koschany wrote: > On 12.12.2014 07:05, tony mancill wrote: > [...] >> Any concerns from the team? This is kind of a brute force approach, but >> seems reasonable. My question is: >> >> Do we feel confident that this the lists below are representative for >> for jessie? >> >>> MULTIARCH_LIBRARY_PATH_32BIT="/usr/lib/jni:/usr/lib/arm-linux-gnueabi/jni:/usr/lib/arm-linux-gnueabihf/jni:/usr/lib/i386-gnu/jni:/usr/lib/i386-linux-gnu/jni:/usr/lib/x86_64-kfreebsd-gnu/jni:/usr/lib/i386-kfreebsd-gnu/jni:/usr/lib/mips-linux-gnu/jni:/usr/lib/mipsel-linux-gnu/jni:/usr/lib/powerpc-linux-gnu/jni:/usr/lib/powerpc-linux-gnuspe/jni:/usr/lib/sparc-linux-gnu/jni:/usr/lib/x86_64-linux-gnux32/jni:/usr/lib/hppa-linux-gnu/jni:/usr/lib/sh4-linux-gnu/jni:/usr/lib/m68k-linux-gnu/jni" >>> >>> MULTIARCH_LIBRARY_PATH_64BIT="/usr/lib/jni:/usr/lib/alpha-linux-gnu/jni:/usr/lib/x86_64-linux-gnu/jni:/usr/lib/aarch64-linux-gnu/jni:/usr/lib/x86_64-kfreebsd-gnu/jni:/usr/lib/powerpc64-linux-gnu/jni:/usr/lib/powerpc64le-linux-gnu/jni:/usr/lib/s390x-linux-gnu/jni:/usr/lib/sparc64-linux-gnu/jni" >> > > Hi, > > since nobody seems to have any comments, let me chime in here. The list > above is complete and contains all possible 32bit and 64bit multiarch > paths. There was one mistake with kfreebsd-64 but this one has been > already fixed two days ago. As you rightfully wrote above, this is some > kind of brute force approach but I'm confident that it covers all > possible scenarios. Now the code checks what kind of JVM is used and > adds the respective MULTIARCH_LIBRARY_PATH to -Djava.library.path. > Actually I would prefer that all JREs would handle that by themselves > but it seems so far only OpenJDK is capable of doing it. > >> Or should jarwrapper honor MULTIARCH_LIBRARY_PATH (or >> JARWRAPPER_MULTIARCH_LIBRARY_PATH, or similar) in the environment? Just >> in case we missed something or something else comes along. If present, >> perhaps this could be added after /usr/lib/jni, and before the other >> components of the path. > > > The downside of this approach is that we need to add new multiarch paths > to jarwrapper whenever a new architecture gets introduced to Debian. > However I think this is manageable. The purpose of jarwrapper is to set > up binfmt-misc to run executable jar files. I feel that no further user > or maintainer interaction should be necessary in addition to that. It > should just work (TM). So in my opinion it would be better if it did not > honor any additional environment variables and simply did its job. [trimming the portion of the email regarding policy - we'll return to that post-jessie] I'll buy the statement that it should "just work." Regarding an upload, I noticed that there are a few subsequent changes/fixes pushed to the packaging repo since December 5th. They don't require any updates to debian/changelog, since they're all related to this bug. Is there any work or testing still in progress? Any concerns with an upload for the state of the package as of 94c25581? Thank you, tony signature.asc Description: OpenPGP digital signature
Bug#764630: RFS: javatools 0.48 [RC]
On Sun, Dec 14, 2014 at 6:50 PM, Markus Koschany wrote: [...] > Actually what was the reasoning behind the choice to use a custom shell > script like jarwrapper instead of jexec to register executable jars with > binfmt-misc? This question also came up in the bug report. Here is my guess: `jexec` only works with openjdk installed. At one point debian had multiple java implementation (sun, kaffe...). These days only two really remains, so maybe an easier solution would be to have a `gcj-exec` provided by `gcj-jdk` to mimic openjdk package. Which means it would be much easier to handle the LD_LIBRARY_PATH issue within the `gcj-exec` executable. jarwrapper is only really needed with a custom jre installation... 2cts -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764630: RFS: javatools 0.48 [RC]
On 12.12.2014 07:05, tony mancill wrote: [...] > Any concerns from the team? This is kind of a brute force approach, but > seems reasonable. My question is: > > Do we feel confident that this the lists below are representative for > for jessie? > >> MULTIARCH_LIBRARY_PATH_32BIT="/usr/lib/jni:/usr/lib/arm-linux-gnueabi/jni:/usr/lib/arm-linux-gnueabihf/jni:/usr/lib/i386-gnu/jni:/usr/lib/i386-linux-gnu/jni:/usr/lib/x86_64-kfreebsd-gnu/jni:/usr/lib/i386-kfreebsd-gnu/jni:/usr/lib/mips-linux-gnu/jni:/usr/lib/mipsel-linux-gnu/jni:/usr/lib/powerpc-linux-gnu/jni:/usr/lib/powerpc-linux-gnuspe/jni:/usr/lib/sparc-linux-gnu/jni:/usr/lib/x86_64-linux-gnux32/jni:/usr/lib/hppa-linux-gnu/jni:/usr/lib/sh4-linux-gnu/jni:/usr/lib/m68k-linux-gnu/jni" >> >> MULTIARCH_LIBRARY_PATH_64BIT="/usr/lib/jni:/usr/lib/alpha-linux-gnu/jni:/usr/lib/x86_64-linux-gnu/jni:/usr/lib/aarch64-linux-gnu/jni:/usr/lib/x86_64-kfreebsd-gnu/jni:/usr/lib/powerpc64-linux-gnu/jni:/usr/lib/powerpc64le-linux-gnu/jni:/usr/lib/s390x-linux-gnu/jni:/usr/lib/sparc64-linux-gnu/jni" > Hi, since nobody seems to have any comments, let me chime in here. The list above is complete and contains all possible 32bit and 64bit multiarch paths. There was one mistake with kfreebsd-64 but this one has been already fixed two days ago. As you rightfully wrote above, this is some kind of brute force approach but I'm confident that it covers all possible scenarios. Now the code checks what kind of JVM is used and adds the respective MULTIARCH_LIBRARY_PATH to -Djava.library.path. Actually I would prefer that all JREs would handle that by themselves but it seems so far only OpenJDK is capable of doing it. > Or should jarwrapper honor MULTIARCH_LIBRARY_PATH (or > JARWRAPPER_MULTIARCH_LIBRARY_PATH, or similar) in the environment? Just > in case we missed something or something else comes along. If present, > perhaps this could be added after /usr/lib/jni, and before the other > components of the path. The downside of this approach is that we need to add new multiarch paths to jarwrapper whenever a new architecture gets introduced to Debian. However I think this is manageable. The purpose of jarwrapper is to set up binfmt-misc to run executable jar files. I feel that no further user or maintainer interaction should be necessary in addition to that. It should just work (TM). So in my opinion it would be better if it did not honor any additional environment variables and simply did its job. > Markus, thank you for working on this. You're welcome. Perhaps this is the right opportunity to raise some questions about javatools and the current Java policy in general. The trigger for this bug report was the dicomscope package which includes arch:all and arch:any components namely jni libraries. According to the current Java policy this is not a violation. The bug reporter suggested [1] to change ยง2.4 of the Java policy From: [...] These dynamic libraries *should* be shipped in a separate architecture-specific package named libXXX[version]-jni. [...] to: [...] These dynamic libraries *must* be shipped in a separate architecture-specific package named libXXX[version]-jni. [...] What is the team's stance on this issue? Actually what was the reasoning behind the choice to use a custom shell script like jarwrapper instead of jexec to register executable jars with binfmt-misc? This question also came up in the bug report. Cheers, Markus [1] https://bugs.debian.org/764630#65 signature.asc Description: OpenPGP digital signature
