Dear maintainer(s),

With a recent upload of libapache-poi-java the autopkgtest of octave-io
fails in testing when that autopkgtest is run with the binary packages
of libapache-poi-java from unstable. It passes when run with only
packages from testing. In tabular form:

                        pass            fail
libapache-poi-java     from testing    4.0.1-4
octave-io              from testing    2.6.4-1
all others             from testing    from testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of
libapache-poi-java to testing [1]. Due to the nature of this issue, I
filed this bug report against both packages. Can you please investigate
the situation and reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libapache-poi-java

https://ci.debian.net/data/autopkgtest/testing/amd64/o/octave-io/22169972/log.gz

Testing default interface for XLSX...
warning: xlsopen: no'.xlsx' spreadsheet I/O support with available
interfaces.
warning: xlsopen: no'.xlsx' spreadsheet I/O support with available
interfaces.
error: assert (size (d) == [1001, 2]) failed
error: called from
     assert at line 107 column 11
     testhelper at line 14 column 5
autopkgtest [15:22:44]: test xlsx-default

Hi,

Le samedi 28 mai 2022 à 21:28 +0200, Paul Gevers a écrit :
4.0.1-4 is the upgrade to xmlbeans 4.0.0.

Attached is a minimal test case that reproduces what octave-io does in
its autopkgtest.

Before running it, you should put the following file in your current
directory:

https://salsa.debian.org/pkg-octave-team/octave-io/-/blob/debian/latest/debian/tests/test.xlsx

The example can be run with:

java -cp /usr/share/java/poi.jar:/usr/share/java/poi-ooxml.jar:/usr/share/java/commons-compress.jar:/usr/share/java/commons-collections4.jar:/usr/share/java/xmlbeans.jar bug1012016.java

This example works fine with libapache-poi-java 4.0.1-3 and
libxmlbeans-java 3.0.2-1. But it crashes with libapache-poi-java 4.0.1-
4 and libxmlbeans-java 4.0.0-1 (currently in unstable).

The relevant part seems to be:

Caused by: java.lang.ClassNotFoundException: org.apache.xmlbeans.metadata.system.s036263A03D2D3FD117889707DB51207A.TypeSystemHolder
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
        ... 31 more

My Java skills are limited so I cannot make further debugging. Could
some Java expert chime in?

P.S.: Why was libapache-poi-java 4.0.1-4 allowed to migrate to testing?
Autopkgtest regressions are supposed to be blockers for testing
migration.

Cheers,

Hi Sébastien,

Because the octave-io test regressed in testing.

https://ci.debian.net/data/autopkgtest/testing/amd64/o/octave-io/22226297/log.gz
has
Get:307 http://deb.debian.org/debian testing/main amd64 libxmlbeans-java
all 4.0.0-1 [2,071 kB]
Get:308 http://deb.debian.org/debian testing/main amd64
libapache-poi-java all 4.0.1-3 [10.5 MB]

It's probably because libxmlbeans wasn't blocked from migrating. So
indeed, it's not libapachage-poi-java that breaks octave-io.

Paul

Le mardi 07 juin 2022 à 16:45 +0200, Sébastien Villemot a écrit :

I’m reassigning this issue to libapache-poi-java. octave-io’s upstream
thinks that the problem comes from an incorrect combination of versions
between libapache-poi-java and xmlbeans. That seems confirmed by the
minimal test case that I attached to my previous email (which used to
work but no longer does, without any indication that the API used
therein is deprecated).

Control: retitle -1 libapache-poi-java needs updates for newer xmlbeans

So, let's give this bug a (hopefully) better title such that it's
potentially a bit clearer during RC bug triaging for bookworm. Would the
new upstream version solve the issue?

Paul

Le mercredi 28 décembre 2022 à 22:46 +0100, Paul Gevers a écrit :

My minimal test case works fine if I combine the latest Apache POI
(5.2.3) with the latest XMLBeans (5.1.1).

So it seems that upgrading these two packages to newer versions in
Debian would fix the problem (just upgrading Apache POI to the latest
version is not enough, because that version requires a newer XMLBeans
than the one currently in Debian).

However, I don’t know if it is realistic to expect this to happen for
Bookworm, given the stage we’re at in the freeze. I am not familiar
enough with this ecosystem to NMU, and the maintainers have been
unresponsive so far.

Alternatively, I could try to patch octave-io so that it no longer uses
libapache-poi-java for reading XLSX files. That is an inferior
solution, because that will remove an important functionality from the
package, but I may not have the choice.

Le mardi 31 janvier 2023 à 18:09 +0100, Sébastien Villemot a écrit :

I ended up implementing this “solution” in octave-io 2.4.6-3. So in
effect it no longer relies on libapache-poi-java + libxmlbeans-java for
reading XLSX files (fortunately octave-io has another, less efficient,
backend for reading XLSX files).

As a consequence, downgrading the severity of this bug.

Le mercredi 01 mars 2023 à 17:58 +0100, Sébastien Villemot a écrit :

Sorry, I meant octave-io 2.6.4-3

when upgrading to debian bookworm I found a problem that is probably
related to this bugreport here and I got no idea on how to workaround.
I created this minimal testcase:

cat >problem.java <<EOF
public class problem {
    public static void main(String[] args) throws Exception {
        System.out.println("debugpoint 1");
        new org.apache.poi.hssf.usermodel.HSSFWorkbook();
        System.out.println("debugpoint 2");
        new org.apache.poi.xssf.usermodel.XSSFWorkbook();
        System.out.println("debugpoint 3");
    }
}
EOF

export CLASSPATH="/usr/share/java/poi-ooxml.jar:/usr/share/java/commons-collections4.jar:/usr/share/java/commons-compress.jar:."

javac problem.java && java problem


now you get this output:

debugpoint 1
debugpoint 2
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/xmlbeans/metadata/system/s036263A03D2D3FD117889707DB51207A/TypeSystemHolder
        at org.openxmlformats.schemas.spreadsheetml.x2006.main.CTWorkbook$Factory.getTypeLoader(Unknown Source)
        at org.openxmlformats.schemas.spreadsheetml.x2006.main.CTWorkbook$Factory.newInstance(Unknown Source)
        at org.apache.poi.xssf.usermodel.XSSFWorkbook.onWorkbookCreate(XSSFWorkbook.java:460)
        at org.apache.poi.xssf.usermodel.XSSFWorkbook.<init>(XSSFWorkbook.java:263)
        at org.apache.poi.xssf.usermodel.XSSFWorkbook.<init>(XSSFWorkbook.java:257)
        at org.apache.poi.xssf.usermodel.XSSFWorkbook.<init>(XSSFWorkbook.java:245)
        at problem.main(problem.java:6)
Caused by: java.lang.ClassNotFoundException: org.apache.xmlbeans.metadata.system.s036263A03D2D3FD117889707DB51207A.TypeSystemHolder
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
        ... 7 more



it does not reach debugpoint 3.

does anybody know how I can workaround here?
The complete XSSFWorkbook system in apachepoi is not working.


cu
Erik

Hi all,

I am a Java developer and I faced the same problem after upgrading
debian from bullseye to bookworm.

I compared the file /usr/share/java/poi-ooxml-schemas-4.0.1.jar between
bullseye, bookworm and those from the maven central repo. The version of
bookworm contains a very reduced amount of files.

So I tested the reproducer problem.java from Erik with the corresponding
jar from bullseye and the test was OK.

I assume, that there has been a problem in creating the
poi-ooxml-schemas-4.0.1.jar for bookworm. Could a maintainer please fix
this file?

Thank you and best regards
Florian Paul

Dear maintainers,

the file /usr/share/java/poi-ooxml-schemas-4.0.1.jar is broken for the
bookworm release. With this broken file the apache poi library is
currently not usable. Is there a chance that this file is getting fixed
soon? How can I help, as it is pretty important for my use?

Thank you and best regards
Florian Paul

as already reported, the filesize of poi-ooxml-schemas-4.0.1.jar is
obviously a problem:


Debian GNU/Linux 10 (buster):
libapache-poi-java 4.0.1-1
root@xxx:/usr/share/java#
-rw-r--r-- 1 root root 1757334 Jan 21  2019 poi-ooxml-4.0.1.jar
-rw-r--r-- 1 root root 7855345 Jan 21  2019 poi-ooxml-schemas-4.0.1.jar


Debian GNU/Linux 12 (bookworm):
libapache-poi-java 4.0.1-4
root@yyy:/usr/share/java#
-rw-r--r-- 1 root root 1757319 16. Mai 2022 poi-ooxml-4.0.1.jar
-rw-r--r-- 1 root root   99850 16. Mai 2022 poi-ooxml-schemas-4.0.1.jar



for a workaround, i have replaced these two files by their old
versions. I also had to replace xmlbeans-4.0.0 by xmlbeans-3.0.2. Then
it worked.

this means it is not enough to replace poi-ooxml-schemas-4.0.1 but also
poi-ooxml-4.0.1 and xmlbeans... maybe this helps anybody - at least to
work around.


cu
Erik