On 22.05.2015 21:26, Felix Natter wrote: [...] > Ok, so I don't need to do anything to keep jffi 1.2 from entering > testing? No, this package is completely broken in sid. See https://packages.qa.debian.org/j/jffi.html It is not considered for testing migration. > >> https://buildd.debian.org/status/package.php?p=jffi&suite=unstable > > => #786553 Thanks! > > But, thinking about it twice, I think we must file a bug against jruby, > as the combination of jruby 1.5 and jffi 1.2 seems to cause this: > > Caused by: java.lang.IncompatibleClassChangeError: Found class > com.kenai.jffi.InvocationBuffer, but interface was expected > at com.kenai.jaffl.provider.jffi.AsmRuntime.marshal(AsmRuntime.java:169) > at org.jruby.ext.posix.LinuxLibC$jaffl$0.__xstat64$raw(Unknown Source) > at org.jruby.ext.posix.LinuxLibC$jaffl$0.__xstat64(Unknown Source) > at org.jruby.ext.posix.LinuxPOSIX.stat(LinuxPOSIX.java:109) > at org.jruby.ext.posix.LazyPOSIX.stat(LazyPOSIX.java:227) > at org.gradle.internal.nativeplatform.filesystem.LibCStat.getUnixMode(LibCStat.java:41) > at > org.gradle.internal.nativeplatform.filesystem.GenericFileSystem.getUnixMode(GenericFileSystem.java:62) > > --> I think we need to upgrade jruby (quite outdated in sid, > i.e. 1.5->1.7) [1] or make gradle not use jruby filesystem > functionality (i.e. a gradle upgrade could fix this). > > Do you agree? There is an ongoing effort from Tim and Miguel. They try to get a more recent version of jruby into Debian. As usual this requires updating tons of dependencies and jffi is one of them. So I think no further action is required. Just saw your e-mail. Yes, upgrading bnd is also part of the fun. :) Cheers, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature