Bug#754755: [rt.cpan.org #98683] libinline-java-perl: FTBFS on mips: test suite issues

[gregor herrmann]

On Tue, 02 Aug 2016 13:53:06 +0000, Daniel Knezevic wrote:

> Tests are still failing in version 0.58 during build.
> 
> I have found out that the tests are failing when Inline::Java uses JNI extensions
> (PERL_INLINE_JAVA_JNI is set to 1), but the tests pass when Inline::Java run JVM in
> the default client/server mode (PERL_INLINE_JAVA_JNI is unset).
> 
> --- debian/rules_orig   2016-08-02 12:16:34.206089692 +0000
> +++ debian/rules        2016-08-02 12:16:46.476196564 +0000
> @@ -49,9 +49,6 @@
> 
>  export JAVA_HOME=/usr/lib/jvm/default-java
> 
> -# Have testsuite use JNI
> -export PERL_INLINE_JAVA_JNI=1
> -
>  # Put aside upstream cruft during build
>  DEB_UPSTREAM_CRUFT_MOVE = t/t13.txt
> 
> It may be some mips/mipsel specific issue, because the build succeeds on mips64el.
> We are still investigating, any tip will be useful.
> 
> Can we use Inline::Java without JNI extension for mips/mipsel?

Thanks for your findings!

I think the idea to drop PERL_INLINE_JAVA_JNI solves only half of the
problem; it doesn't use the JNI extension during the tests but it
still builds them.
In order not to build them on architectures where they apparently
don't work, we probably shouldn't build them in the first place.

I've come up with the following patch now (committed in git but not
yet uploaded in the hope of getting more eyeballs to look at it):

#v+
--- a/debian/rules
+++ b/debian/rules
@@ -49,8 +49,15 @@ CDBS_DEPENDS_$(pkg) = $(deps)

 export JAVA_HOME=/usr/lib/jvm/default-java

+DEB_HOST_ARCH = $(shell dpkg-architecture -qDEB_HOST_ARCH)
+NO_JNI_ARCH = hppa hurd-i386 mips mipsel
+ifeq (,$(filter $(DEB_HOST_ARCH), $(NO_JNI_ARCH)))
 # Have testsuite use JNI
 export PERL_INLINE_JAVA_JNI=1
+else
+# Don't build JNI extension
+DEB_MAKEMAKER_USER_FLAGS = BUILD_JNI=0
+endif

 # Put aside upstream cruft during build
 DEB_UPSTREAM_CRUFT_MOVE = t/t13.txt
@@ -58,6 +65,7 @@ DEB_UPSTREAM_CRUFT_MOVE = t/t13.txt
 # Have testsuite use the C locale's decimal point
 DEB_MAKE_CHECK_TARGET += LC_NUMERIC=C

+ifeq (,$(filter $(DEB_HOST_ARCH), $(NO_JNI_ARCH)))
 binary-post-install/$(pkg)::
        chrpath -d $(cdbs_curdestdir)$(perlpath)/auto/Inline/Java/JNI/JNI.so

@@ -67,3 +75,4 @@ binary-post-install/$(pkg)::
                $(cdbs_curdestdir)$(perlpath)/Inline/Java/*.jar
        dh_link usr/share/$(pkg)/InlineJavaServer.jar $(perlpath)/Inline/Java/InlineJavaServer.jar \
                usr/share/$(pkg)/InlineJavaUser.jar $(perlpath)/Inline/Java/InlineJavaUser.jar
+endif
#v-

This seems to work for both cases; what's not so nice is that in the
case of the NO_JNI_ARCH we get a hint from lintian:

X: libinline-java-perl: package-contains-no-arch-dependent-files

and indeed everything ends up in /usr/share/perl5 despite the package
saying it's arch:any.


Alternatives:
- just remove PERL_INLINE_JAVA_JNI and ignore the fact that the JNI
  stuff might be broken on some architectures
- don't build it on all architectures (and make the package arch:all)


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: JBO: Frauen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: Digital Signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20160910/67657c82/attachment-0001.sig>