help needed with LibreOffice Java bridge on s390x/ppc64el

[Rene Engelhard]

Hi,

forgot to edit $SUBJECT. This is just ppc64el for now.

(While s390x also has broken bridges --without-java doesn't seem to help
here unfortunately :/)

Regards,

Rene

Hi,
since LibreOffice 7.6 (which added some more  tests which were manual
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=ppc64el&ver=4%3A7.6.2-3&stamp=1697981409&raw=0
See the discussion upstream in
"new bridgetest failures in 7.6 on ppc64le "
and continued in October
https://lists.freedesktop.org/archives/libreoffice/2023-October/thread.html
especially
https://lists.freedesktop.org/archives/libreoffice/2023-October/091058.html and
https://lists.freedesktop.org/archives/libreoffice/2023-October/091059.html
after which unfortunately noting important happened. (And I don't see a
patch either at Fedora git nor submitted upstream to fix this.)
This is probably architecture-specific since the other architectures
*do* work.
Can you have a look at it, too?
(The workaround would be --without-java which I verified to work, but
this opens a can of worms. Not only disabling some (built-in) features
like the Report Builder but especially since there is Java-based
extensions (_all!) which then get into trouble dependency-wise/LO will
be blocked from migrating to testing maybe...)
Regards,
Rene

[Rene Engelhard]

Hi,

since LibreOffice 7.6 (which added some more tests which were manual
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=ppc64el&ver=4%3A7.6.2-3&stamp=1697981409&raw=0
[...]
These tests seem to be passing for 7.6.2 on openSUSE on ppc64el [1].

Interesting.

However, on openSUSE,
we're explicitly building with OpenJDK 8 while Debian builds with OpenJDK 17 [2] which might
explain the different test results.

Which is no option here...


Regards,


Rene

[René Engelhard]

Hi,

Hello!

Post by Rene Engelhard

we're explicitly building with OpenJDK 8 while Debian builds
with OpenJDK 17 [2] which might explain the different test results.

Which is no option here...

It may not be an option, but it might give you a pointer how to fix the
actual bug, even with OpenJDK 17.

No, given the discussion on the upstream list that's definitely beyond my skills and needs to be done by a porter.

Regards

René

[Rene Engelhard]

Hi,

Post by René Engelhard

Hello!

Post by Rene Engelhard

we're explicitly building with OpenJDK 8 while Debian builds
with OpenJDK 17 [2] which might explain the different test results.

Which is no option here...

It may not be an option, but it might give you a pointer how to fix the
actual bug, even with OpenJDK 17.

No, given the discussion on the upstream list that's definitely beyond my skills and needs to be done by a porter.

besides that (on platti):

 % make check
S=/home/rene/libreoffice-7.6.2 && I=$S/instdir && W=$S/workdir &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"
$I/program/uno.bin -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.CppTestObject
-env:LO_BUILD_LIB_DIR=file://$W/LinkTarget/Library
-env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file://$W/UnoApiTarget/bridgetest.rdb &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"
$I/program/uno.bin -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.JavaTestObject noCurrentContext
-env:LO_BUILD_LIB_DIR=file://$W/LinkTarget/Library
-env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file://$W/UnoApiTarget/bridgetest.rdb
exception occurred: Could not create Java implementation loader at
./stoc/source/javaloader/javaloader.cxx:551

Post by René Engelhard
error: Could not create Java implementation loader at

./stoc/source/javaloader/javaloader.cxx:551

Post by René Engelhard
dying...make: ***

[/home/rene/libreoffice-7.6.2/testtools/CustomTarget_uno_test.mk:32:
/home/rene/libreoffice-7.6.2/workdir/CustomTarget/testtools/uno_test.done]
Error 1


Tried setting the JDK explicitely (all on platti):

8: see above

11: fails in the original way

17: not tested expllicitely, it is the default

21: fails in the original way


Regards


René

[Rene Engelhard]

Hi,

(The workaround would be --without-java which I verified to work on
zelenka (see aboe), but this opens a can of worms. Not only disabling
some (built-in) features like the Report Builder but especially since
there is Java-based extensions (_all!) which then get into trouble
dependency-wise/LO will be blocked from migrating to testing maybe...)

Since I didn't get any real answer I needed to do that now. It's live
now in sid.

It now also makes natbrailles autopkgtest fail[1] since that one of
course wants ure-java which is Out-of-sync and probably should be
decrufted somewhen:

$ rmadison -s unstable ure-java
ure-java | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x
ure-java | 4:7.6.4~rc1-1 | unstable | amd64, arm64, armel, i386

Regards,

Rene