On Sun, 09 Apr 2017 08:13:00 +0000 Niels Thykier <ni...@thykier.net> wrote: [...] > Any update on this? This bug is one of the last ~60 RC bugs in key > packages for the stretch release. :)
Hi, I had a look at this issue. If we introduce the symlink libjnidispatch.so -> libjnidispatch.system.so in /usr/lib/$MULTIARCH we could indeed work around this bug which however exists because a) Netbeans had to be patched to use Debian's system JNA files instead of the embedded ones (see the netbeans-platform-nojnabinaries.patch), and b) because of the fix for LP #1065253 [1]. This issue could be resolved by changing the libary name to jnidispatch.system in Netbeans. However I don't understand why we had to change the name in the first place. According to the Ubuntu bug the bug submitter tried to build a local Jenkins plugin but our system JNA library and the custom local project didn't work well together. He also came up with the correct solution for his problem: to pass -DargLine="-Djna.nosys=true" to Maven. In my opinion LP #1065253 is not a bug because Debian's system JNA works as expected and for custom projects you just have to set -Djna.nosys=true. We can't provide multiple versions of JNA due to the usual reasons (code duplication, security impact). Ways to resolve this bug a) Revert the fix for LP #1065253 b) Reassign to Netbeans and rename the library name in netbeans-platform-nojnabinaries.patch I tend to implement option a) because I think Debian should not diverge from upstream in this case and user's should adjust their custom projects as needed if Debian's system version is not compatible. Regards, Markus [1] https://bugs.launchpad.net/ubuntu/+source/libjna-java/+bug/1065253
signature.asc
Description: OpenPGP digital signature
