RFS: new upstream version (3.0.10) of jnr-posix
Next on the list of Jruby dependencies is an updated version (3.0.10) of the jnr-posix library. The current version in the archive is out-of-date (1.1.8) and requires libconstantine-java which conflicts with any package that requires libjnr-constants-java. I’ve renamed this and converted the build system to maven-debian-helper. Included also is a rename of the source package (but retaining all history of the previous package) in order to be consistent with the growing library of jnr packages. I had meant to push this only to a new repo called jnr-posix, but accidentally also pushed to the existing repo, libjnr-posix-java. Sorry. Tim. smime.p7s Description: S/MIME cryptographic signature
Re: RFS: jnr-ffi, jnr-enxio and jnr-unixsocket
On 04/06/2015 02:15 PM, Miguel Landaeta wrote: > On Mon, 6 Apr 2015 20:28:23 +, Tim Potter wrote: >> >> Hi everyone. I have some more Jruby dependencies that are ready for >> upload to experimental. Now that jffi is in experimental I would like >> to have someone take a look at the jnr-ffi, jnr-enxio and jnr-unixsocket >> packages which are available in the usual location. > > Hi Tim, > > I'll check jnr-ffi. > > Cheers, Hi Tim, I'll take care of jnr-enxio and jnr-unixsocket. For jnr-enxio, I just posted a request for license clarification. One of the source files carries an explicit LGPL 3 license, but I think it might have been missed when the license was changed to Apache 2.0. Once I hear back, I should be ready to upload (after updating d/copyright). Cheers, tony [1] https://github.com/jnr/jnr-enxio/issues/8 signature.asc Description: OpenPGP digital signature
Re: RFS: jnr-ffi, jnr-enxio and jnr-unixsocket
On Mon, 6 Apr 2015 20:28:23 +, Tim Potter wrote: > > Hi everyone. I have some more Jruby dependencies that are ready for > upload to experimental. Now that jffi is in experimental I would like > to have someone take a look at the jnr-ffi, jnr-enxio and jnr-unixsocket > packages which are available in the usual location. Hi Tim, I'll check jnr-ffi. Cheers, -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche signature.asc Description: Digital signature
RFS: jnr-ffi, jnr-enxio and jnr-unixsocket
Hi everyone. I have some more Jruby dependencies that are ready for upload to experimental. Now that jffi is in experimental I would like to have someone take a look at the jnr-ffi, jnr-enxio and jnr-unixsocket packages which are available in the usual location. I’ve just added javadoc for each of them and they should be ready to go now. Regards, Tim. smime.p7s Description: S/MIME cryptographic signature
Re: RFS: jffi-1.2.7 and jenkins-1.565.3-4
Le 06/04/2015 16:15, tony mancill a écrit : > I'm wondering it would be less confusing/overall work if we go ahead and > ship an empty jffi-native.jar in /usj + maven artifacts in the > libjffi-java (arch:all) package, which in turn depends on the -jni package. > > Or put another way, do folks think there is a downside to doing that? > It could bypass a potentially confusing step for package maintainers > that depend on jffi, and it doesn't cost much to put them in. That's a good strategy too, especially if there are many projects depending on the jffi-native artifact. It really depend on how the artifacts are used. If foo depends on foo-native and all projects simply depend on foo, then removing the foo-native dependency from foo is slightly better (one less empty file installed by the package). If most projects depend on foo *and* foo-native then having an empty foo-native artifact is easier for the packagers (one less ignore rule). Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55229b28.6020...@apache.org
Re: RFS: jffi-1.2.7 and jenkins-1.565.3-4
On 04/06/2015 05:33 AM, Potter, Tim (Cloud Services) wrote: > On 6 Apr 2015, at 7:26 pm, Emmanuel Bourg wrote: >> >> Le 06/04/2015 11:11, Potter, Tim (Cloud Services) a écrit : >> >>> Path to dependency: >>> 1) com.github.jnr:jnr-ffi:jar:1.0.10 >>> 2) com.github.jnr:jffi:jar:native:1.2.7 >>> >>> Is there some magic required to get Maven to look in >>> /usr/lib/x86_64-linux-gnu/jni (or wherever) for the native JAR file? >> >> Here the jffi:jar:native dependency in the jnr-ffi pom should be >> removed. It's just a matter or adding an ignore rule in the >> debian/maven.ignoreRules files of the package bundling jnr-ffi. > > Thanks Emmanuel! I added a rule (after figuring out the native classifier > needs to be specified otherwise it ignores the JAR file as well) and it > builds correctly now: > > com.github.jnr jffi jar * native * Hi Emmanuel, hi Tim: I'm wondering it would be less confusing/overall work if we go ahead and ship an empty jffi-native.jar in /usj + maven artifacts in the libjffi-java (arch:all) package, which in turn depends on the -jni package. Or put another way, do folks think there is a downside to doing that? It could bypass a potentially confusing step for package maintainers that depend on jffi, and it doesn't cost much to put them in. Thank you, tony signature.asc Description: OpenPGP digital signature
Re: RFS: jffi-1.2.7 and jenkins-1.565.3-4
On 6 Apr 2015, at 7:26 pm, Emmanuel Bourg wrote: > > Le 06/04/2015 11:11, Potter, Tim (Cloud Services) a écrit : > >> Path to dependency: >> 1) com.github.jnr:jnr-ffi:jar:1.0.10 >> 2) com.github.jnr:jffi:jar:native:1.2.7 >> >> Is there some magic required to get Maven to look in >> /usr/lib/x86_64-linux-gnu/jni (or wherever) for the native JAR file? > > Here the jffi:jar:native dependency in the jnr-ffi pom should be > removed. It's just a matter or adding an ignore rule in the > debian/maven.ignoreRules files of the package bundling jnr-ffi. Thanks Emmanuel! I added a rule (after figuring out the native classifier needs to be specified otherwise it ignores the JAR file as well) and it builds correctly now: com.github.jnr jffi jar * native * Thanks! Tim. smime.p7s Description: S/MIME cryptographic signature
Re: RFS: jffi-1.2.7 and jenkins-1.565.3-4
Le 06/04/2015 11:11, Potter, Tim (Cloud Services) a écrit : > Path to dependency: > 1) com.github.jnr:jnr-ffi:jar:1.0.10 > 2) com.github.jnr:jffi:jar:native:1.2.7 > > Is there some magic required to get Maven to look in > /usr/lib/x86_64-linux-gnu/jni (or wherever) for the native JAR file? Here the jffi:jar:native dependency in the jnr-ffi pom should be removed. It's just a matter or adding an ignore rule in the debian/maven.ignoreRules files of the package bundling jnr-ffi. Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55225141.9060...@apache.org
Re: RFS: jffi-1.2.7 and jenkins-1.565.3-4
On 5 Apr 2015, at 4:47 pm, Potter, Tim (Cloud Services) wrote: > > On 5 Apr 2015, at 12:44 am, tony mancill wrote: >> >> The fact that 1.0.2-11 had shipped a JAR in /usr/lib/jni/ had me >> confused, but as Emmanuel pointed out, this needs to be multi-arch aware. >> >> Tim, do you have a (simple?) run-time test I can use to validate the >> package after moving the contents of the -native.jar to /usr/lib/jni/ ? > > Hi Tony. Thanks for the upload, and for the fix. I was using as my fix the > building (and associated unit test running) of the various other jnr-* > packages that jffi is a rdependency for: jnr-ffi, jnr-enxio and > jnr-unixsocket. > > I’ll tweak my Jenkins jobs to pull jffi from experimental and re-run the > builds to tests. Hi Tony. I tried building the jnr-ffi package today with the new multi-arch version of jffi but it failed with a familiar Maven error: [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) com.github.jnr:jffi:jar:native:1.2.7 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.github.jnr -DartifactId=jffi -Dversion=1.2.7 -Dclassifier=native -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=com.github.jnr -DartifactId=jffi -Dversion=1.2.7 -Dclassifier=native -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.github.jnr:jnr-ffi:jar:1.0.10 2) com.github.jnr:jffi:jar:native:1.2.7 Is there some magic required to get Maven to look in /usr/lib/x86_64-linux-gnu/jni (or wherever) for the native JAR file? Tim. smime.p7s Description: S/MIME cryptographic signature
