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?
Cheers, Julien
signature.asc
Description: Digital signature
