Julien Cristau a écrit , Le 04/07/2013 17:29: > On Thu, Jul 4, 2013 at 08:02:22 +0200, Gilles Filippini wrote: > >> Adam D. Barratt a écrit , Le 03/07/2013 23:17: >>> Control: tags -1 + moreinfo wheezy >>> >>> On Tue, 2013-07-02 at 23:15 +0200, Gilles Filippini wrote: >>>> Please consider accepting this pu which fixes RC bug #714393 in sikuli-ide. >>> >>> I'm slightly confused by the fix, but happy to believe I'm missing >>> something obvious... >>> >>> ++LD_LIBRARY_PATH=/usr/lib/@DEB_HOST_MULTIARCH@/jni:$LD_LIBRARY_PATH >>> LC_NUMERIC=C exec /usr/bin/java -cp >>> "/usr/share/java/jna.jar:/usr/share/java/asm3.jar:/usr/share/java/asm3-commons.jar:/usr/share/java/antlr3-runtime.jar:/usr/share/java/libconstantine-java.jar:/usr/share/java/jython.jar:/usr/share/java/commons-cli.jar:/usr/share/java/JXGrabKey.jar:/usr/share/java/json_simple.jar:/usr/share/java/swing-layout.jar:/usr/share/java/swingx-core.jar:/usr/share/java/forms.jar:/usr/share/java/mac_widgets.jar:/usr/share/java/junit.jar:/usr/share/sikuli/sikuli-ide.jar:/usr/share/java/sikuli-script.jar" >>> -Dsikuli.console=true -Dsikuli.debug=0 -Xms64M -Xmx512M >>> -Dfile.encoding=UTF-8 -Dpython.home=/usr/share/jython >>> -Dpython.path="/usr/share/sikuli/Lib" -Dpython.cachedir=$HOME/.jython-cache >>> org.sikuli.ide.SikuliIDE "$@" >>> [...] >>> --- sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/rules 2013-07-02 >>> 22:29:53.000000000 +0200 >>> +++ sikuli-1.0~x~rc3.tesseract3-dfsg1/debian/rules 2013-07-02 >>> 22:54:40.000000000 +0200 >>> @@ -50,5 +50,6 @@ >>> >>> mkdir -p debian/sikuli-ide/usr/bin >>> install sikuli-ide/target/linux/Sikuli-IDE/sikuli-ide.sh >>> debian/sikuli-ide/usr/bin/sikuli-ide >>> + sed -i "s/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/" >>> debian/sikuli-ide/usr/bin/sikuli-ide >>> >>> sikuli-ide is an architecture:all package, so only built as part of the >>> maintainer upload. The path to which it points, otoh, is in an >>> architecture-dependent package (and an architecture-dependent path); >>> this means that the two paths will only match for users installing >>> libsikuli-script-jni on the same architecture as the arch:all package >>> was built on. >> >> Oops! Indeed, you're right. Thanks for noticing it. >> >> This path should be resolved at run-time, then, using dpkg-architecture. >> But it implies depending on dpkg-dev :/ What do you think? Is there >> another way to compute these triplets path? >> > If the script needs to be arch-dependent, then it needs to be part of an > arch-dependent package. But I don't get why you need to add this path > to LD_LIBRARY_PATH. java should already know to look there, and > I'd have though nothing else would be loading a jni?
Obviously sun-java6 doesn't know where to find the jni library, hence bug #714393, which is actually more a sun-java6 bug then. Well, another way to fix it would be to depend on default-jre only and explicitly use its java binary (/usr/lib/jvm/default-java/bin/java) instead of the one configured by update-alternatives. Would it be acceptable? Thanks, _g.
signature.asc
Description: OpenPGP digital signature
