Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1012016: libapache-poi-java breaks octave-io autopkgtest: assert (size (d) == [1001, 2]) failed
8 views
Skip to first unread message
Paul Gevers
May 28, 2022, 3:40:04 PM5/28/22
to
Source: libapache-poi-java, octave-io
Control: found -1 libapache-poi-java/4.0.1-4
Control: found -1 octave-io/2.6.4-1
Severity: serious
Tags: sid bookworm
User: debi...@lists.debian.org
Usertags: breaks needs-update
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
Control: found -1 libapache-poi-java/4.0.1-4
Control: found -1 octave-io/2.6.4-1
Severity: serious
Tags: sid bookworm
User: debi...@lists.debian.org
Usertags: breaks needs-update
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
Sébastien Villemot
Jun 7, 2022, 10:50:05 AM6/7/22
to
Hi,
Le samedi 28 mai 2022 à 21:28 +0200, Paul Gevers a écrit :
> Source: libapache-poi-java, octave-io
> Control: found -1 libapache-poi-java/4.0.1-4
> Control: found -1 octave-io/2.6.4-1
> Severity: serious
> Tags: sid bookworm
> User: debi...@lists.debian.org
> Usertags: breaks needs-update
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,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
Le samedi 28 mai 2022 à 21:28 +0200, Paul Gevers a écrit :
> Source: libapache-poi-java, octave-io
> Control: found -1 libapache-poi-java/4.0.1-4
> Control: found -1 octave-io/2.6.4-1
> Severity: serious
> Tags: sid bookworm
> User: debi...@lists.debian.org
> Usertags: breaks needs-update
> 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.
First note that the only change between libapache-poi-java 4.0.1-3 and
> 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.
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,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
Paul Gevers
Jun 7, 2022, 1:10:04 PM6/7/22
to
Hi Sébastien,
On 07-06-2022 16:45, Sébastien Villemot wrote:
> 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.
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
On 07-06-2022 16:45, Sébastien Villemot wrote:
> 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.
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
Paul Gevers
Dec 28, 2022, 5:00:04 PM12/28/22
to
Control: retitle -1 libapache-poi-java needs updates for newer xmlbeans
On Fri, 24 Jun 2022 09:54:32 +0200 =?ISO-8859-1?Q?S=E9bastien?= Villemot
<seba...@debian.org> wrote:
> 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).
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
On Fri, 24 Jun 2022 09:54:32 +0200 =?ISO-8859-1?Q?S=E9bastien?= Villemot
<seba...@debian.org> wrote:
> 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).
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
Sébastien Villemot
Jan 31, 2023, 12:20:05 PM1/31/23
to
(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.
Sébastien Villemot
Mar 1, 2023, 12:10:04 PM3/1/23
to
Control: severity -1 important
Le mardi 31 janvier 2023 à 18:09 +0100, Sébastien Villemot a écrit :
> 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.
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 mardi 31 janvier 2023 à 18:09 +0100, Sébastien Villemot a écrit :
> 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.
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.
Erik Thiele
Sep 20, 2023, 3:50:05 AM9/20/23
to
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
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
deb...@f58.de
Oct 22, 2023, 1:40:05 PM10/22/23
to
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
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
deb...@f58.de
Oct 30, 2023, 3:50:04 PM10/30/23
to
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?
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?
Erik Thiele
Nov 9, 2023, 5:00:06 AM11/9/23
to
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
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
0 new messages