Created attachment 12953 [details]
odb containing a report that fails

Confirmed using the attached example:

An error message popup, containing:


[jni_uno bridge error] UNO calling Java method execute: non-UNO exception occurred: java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
java stack trace:
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
	at org.pentaho.reporting.libraries.base.boot.AbstractBoot.<clinit>(AbstractBoot.java:55)
	at org.libreoffice.report.pentaho.PentahoReportEngine.<init>(PentahoReportEngine.java:34)
	at org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory.createReportJob(SOReportJobFactory.java:352)
	at org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory.execute(SOReportJobFactory.java:236)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.LogFactory
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:471)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
	at java.base/java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:899)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 4 more
 /home/iurt/rpmbuild/BUILD/libreoffice-7.2.2.2/bridges/source/jni_uno/jni_uno2java.cxx:785

CC: (none) => fri

CCing Nicolas who did the update.
Does it work on Cauldron?

CC: (none) => mageia

No idea, I've never used that one, and I don't have enough space left for another OS (well, keeping some spare for the MGA-9 alfa's to come).

@Herman Viaene
Not sure if helps, but did you install

libreoffice-base & libreoffice-postgresql ?

Both have been installed. Without libreoffice-base I wouldn't be able to open an odb at all, and i'm experimenting a little with the postgres connection, so I make sure it is installed if not by default.
And I have an annoying question: if the rpm's provide by LibreOffice install OK, why do you (well Mageia crew in geneeral) bother with trying to provide specific Mageia-oriented rpm's with all risks involved as demonstrated by this issue!!!!

(In reply to Herman Viaene from comment #6)
> And I have an annoying question: if the rpm's provide by LibreOffice install
> OK, why do you (well Mageia crew in geneeral) bother with trying to provide
> specific Mageia-oriented rpm's with all risks involved as demonstrated by
> this issue!!!!

I only can answer as user, but for me the 32 bit support is one important thing that upstream libreoffice no longer provides.

Still is valid for the 7.2.5.2 currently in Updates-Testing.

java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory

you still have the same backtrace ?

is apache-commons-logging installed ?

@Nicolas
On both questions in Comments 9 and 10 : yes.

Well it opens smoothly for me.
I can see 3 tables (employees, ...)

Keywords: (none) => NEEDINFO

Created attachment 13085 [details]
screenshot of error

Test:
1) open the odb Herman provided
2) in left pane click Reports
3) in bottom pane double click the Query
-> Error popup

Checked on a clean Plasma net install, retaining /home, just a week ago. Libreoffice updated about a half hour ago. I have everything installed as from the installer as far as Libreoffice, Apache, and java are concerned, with no extras added in that I can recall. The only non-Mageia package installed is Google Earth Pro. I just rebooted with a new systemd.

This is the first time I remember even opening Libreoffice Base, so I am a complete novice in this area.

I see the problem too, though rather than double-clicking I highlighted the desired report and used the "open database object" icon in the toolbar at the top of the page. If I set the button in the bottom pane to "document" before trying to open the document I see a readable preview in that pane.

My popup is as follows:

[jni_uno bridge error] UNO calling Java method execute: non-UNO exception occurred: java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
java stack trace:
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
	at org.pentaho.reporting.libraries.base.boot.AbstractBoot.<clinit>(AbstractBoot.java:55)
	at org.libreoffice.report.pentaho.PentahoReportEngine.<init>(PentahoReportEngine.java:34)
	at org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory.createReportJob(SOReportJobFactory.java:352)
	at org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory.execute(SOReportJobFactory.java:236)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.LogFactory
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:476)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
	at java.base/java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:904)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 4 more
 /home/iurt/rpmbuild/BUILD/libreoffice-7.2.5.2/bridges/source/jni_uno/jni_uno2java.cxx:785

CC: (none) => andrewsfarm

Hum this happens on Fedora too.
Our LO being based on them, it could make sense to report that issue there.

Now that is strange. Because the LO site provides rpm's, this implies that the Fedora people rebuild their rpm's and not use the ones from LO.
I have a Fedora installation somewhere around (if I didn't delete it). If I find it, I'll test that as well.

(In reply to Thierry Vignaud from comment #12)
> Well it opens smoothly for me.
> I can see 3 tables (employees, ...)

But does it create reports?

It was asked whether cauldron worked in comment 3. I seldom install libreoffice on the cauldron machines I use for packaging. So I did urpmi libreoffice-base and let it pull dependencies as it needed. When asked to choose one of libreoffice-x11 or libreoffice-kf5 I picked kf5.

I tested using a test database using the tasks template and put in a couple of rows of data. On cauldron I was not even able to select the "Use wizard to create report" link as it was greyed out so I could not get to the point of the error on mga8.

When I tested on mga8 earlier I had created a new test database using the tasks template as above. When I clicked 'use wizard to create report' (which was not greyed out) it opened the wizard, I selected all the fields available and hit >> to add them to the report, hit finish - and it blew up. 

There are java related things in the error displayed so it could as well be a java problem as a libreoffice problem. But a few lines that stuck out in the error follow.

The error header said "The document "Tasks" could not be opened."

Two lines that stuck out because they mention "fail" or "unknown source" are:

org.libreoffice.report.ReportExecutionException: Failed to load style-mapper

at org.jfree.report.flow.SinglePassReportProcessor.processReport(Unknown Source)

A third one that stuck out because of a path that included /home/iurt is:

/home/iurt/rpmbuild/BUILD/libreoffice-7.0.4.2/dbaccess/source/core/dataaccess/documentcontainer.cxx:538

There is no iurt user on this laptop.

@Mike
The "Failed to load style-mapper" is something I encountered while developing my application at a given time, but that happened more than a year ago. I came to resolve it searching asklibreoffice, i.e. the forum of LO, but I forgot what the solution was.

Yes i see the /iurt/ part as well, and I have no such folder. Comment 3 and 13.

Mike Rambo mentioned choosing the -kf5 package, and that made me think... That has caused another issue, could it be a problem here? My install is Plasma, so the -kf5 package was installed by default.

So, I tried installing the -x11 package and then removing the -kf5 package, and tried Herman's example again.

Unfortunately, it didn't make any difference. :-(

@ Mike Rambo: I can open the "task" to create a report, and the wizard. It's the existing report itself that won't open.

Can confirm this bug on my system on LXQt. Screenshot attached.

System: Mageia 8, x86_64, LXQt, Intel CPU, nVidia GPU using nvidia-current proprietary driver.

$ uname -a
Linux marte 5.15.11-desktop-3.mga8 #1 SMP Sat Dec 25 10:44:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -qa | grep libreoffice | sort
libreoffice-base-7.2.5.2-1.mga8
libreoffice-calc-7.2.5.2-1.mga8
libreoffice-core-7.2.5.2-1.mga8
libreoffice-data-7.2.5.2-1.mga8
libreoffice-draw-7.2.5.2-1.mga8
libreoffice-emailmerge-7.2.5.2-1.mga8
libreoffice-graphicfilter-7.2.5.2-1.mga8
libreoffice-gtk3-7.2.5.2-1.mga8
libreoffice-help-en-7.2.5.2-1.mga8
libreoffice-help-pt-7.2.5.2-1.mga8
libreoffice-impress-7.2.5.2-1.mga8
libreoffice-kf5-7.2.5.2-1.mga8
libreoffice-langpack-en-7.2.5.2-1.mga8
libreoffice-langpack-pt-7.2.5.2-1.mga8
libreoffice-math-7.2.5.2-1.mga8
libreoffice-ogltrans-7.2.5.2-1.mga8
libreoffice-opensymbol-fonts-7.2.5.2-1.mga8
libreoffice-pdfimport-7.2.5.2-1.mga8
libreoffice-pyuno-7.2.5.2-1.mga8
libreoffice-ure-7.2.5.2-1.mga8
libreoffice-ure-common-7.2.5.2-1.mga8
libreoffice-wiki-publisher-7.2.5.2-1.mga8
libreoffice-writer-7.2.5.2-1.mga8
libreoffice-x11-7.2.5.2-1.mga8
libreoffice-xsltfilter-7.2.5.2-1.mga8
$ java --version
openjdk 11.0.13 2021-10-19 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.13+8-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.13+8-LTS, mixed mode, sharing)

CC: (none) => mageia

Humm actually it works on Fedora with libreoffice-base-7.2.5.2-1.fc35.x86_64.
Maybe it's a bug in our Java stack?

I would say our apache-commons-logging would need some fixing

Source RPM: libreoffice-7.2.5.2-1.mga8 => libreoffice-7.2.5.2-1.mga8 apache-commons-logging

You can work around this bug by going to Tools->Options->LibreOffice->Advanced, clicking on the Class Path button, clicking on the Add Archive button, and choosing the archive /usr/share/java/apache-commons-logging.jar.

You then get back to bug 28672.

CC: (none) => mageia

@Martin and Thierry
The strange thing is that this problem popped up with the LO versions 7.2.X. On my desktop (where I do the development of the Base application) I've kept the 7.1.5.2 version, otherwise fully updated, and there all is OK. I haven't a clue whether this version had a dependency on apache-commons-logging or not.

(In reply to Thierry Vignaud from comment #22)
> Humm actually it works on Fedora with libreoffice-base-7.2.5.2-1.fc35.x86_64.
> Maybe it's a bug in our Java stack?

impossible #joking

i need to take a deeper look on our java stack then.

Thank you for this useful information.

i just updated apache-commons-logging into cauldron.

Can someone test as soon as available ?

didn't built. I will resync the javastack. ( can take several days of work ).

Thanks for digging into it, Nicolas.
Maybe concentrate on mga8 (testing) first anyway.
-That is where our users are ;)

From the libreoffice Changelog:

021-04-09  Stephan Bergmann  <sbergman@redhat.com>  [b721a1cecb6ea0013be8402350110822e50b4415]

        external/jfreereport: Get rid of apache-commons-logging

        ...using Java 1.4 java.util.logging.Logger instead.  The two patch files are
        taken from
        <https://src.fedoraproject.org/rpms/pentaho-reporting-flow-engine/c/7db2dc0aaa9219edc794b535084a17fb408f284a>
        "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging"
        and
        <https://src.fedoraproject.org/rpms/liblayout/c/675bcd0243d31593d7b047017108b71adfe748c3>
        "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging",
        respectively

2021-04-11  Stephan Bergmann  <sbergman@redhat.com>  [6de0b1710adfba82c96b75a5da6f52633a54c692]

        Get rid of apache-commons-logging

        ...using Java 1.4 java.util.logging.Logger instead also for the last remaining
        uses in reportbuilder.

        (The mention in swext/mediawiki/src/THIRDPARTYLICENSEREADME.html was presumably
        a leftover from 4b6ceed4a4a9b152905a8b1712ffb9bd61373c16 "swext: Wiki Publisher 
        does not use those apache-commons libraries".) 

and

2021-04-13  Stephan Bergmann  <sbergman@redhat.com>  [5c1d67fbace131dfcf2042d10986b78c766d743d]

        external/jfreereport: Get rid of remaining apache-commons-logging

        ...similar to b721a1cecb6ea0013be8402350110822e50b4415 "external/jfreereport:   
        Get rid of apache-commons-logging", but where the external tarballs contain
        copies of commons-logging-api-1.0.4.jar to compile against, so
        6de0b1710adfba82c96b75a5da6f52633a54c692 "Get rid of apache-commons-logging" did
        not affect them at build- but only at run-time.

        The sources of the seven new patch files (and which have further been adapted as
        necessary) are taken from
        <https://src.fedoraproject.org/rpms/libbase/blob/4a8cd85e49a0a00d0e0f865a3c841e3f1858a04b>
        "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging",
        <https://src.fedoraproject.org/rpms/libfonts/c/c7f7d4ed67b9ca701152732cbdac547db3ada5f4>
        "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging",
        <https://src.fedoraproject.org/rpms/libformula/c/feb5be4b393f13b131623339a5868c6b381b2507>
        "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging",
        <https://src.fedoraproject.org/rpms/libloader/c/53eeb19460f2ab934cdf4c7c7c73fd681141216c>
        "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging",
        <https://src.fedoraproject.org/rpms/librepository/c/9fa7021dfe7dcc76e32c40f99f74c3745013c501>
        "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging",
        <https://src.fedoraproject.org/rpms/libserializer/c/027e1a16f7171f7ac5f9da4683d1e1b63794bb06>
        "Related: rhbz#1895921 replace apache-commons-logging with java.util.logging",
        and
        <https://src.fedoraproject.org/rpms/pentaho-libxml/c/74538ea7cdd0845f8e6dff748f8d4abfe080dbe4>
        "add missing patch".

Applying those patches to our Java packages fixes this bug, though still leaves bug 28672.

Annoyingly the referenced rhbz ticket is not public, so we can't learn why they did this. It was also upstreamed into LibreOffice without any explanation: https://www.mail-archive.com/libreoffice@lists.freedesktop.org/msg283498.html

Note this is really a LibreOffice bug. They have incorporated Fedora's patches to remove the use of apache-commons-logging, which is all well and good when using the bundled libraries, but results in this bug when LibreOffice is built with the --with-system-libs option on a system that uses vanilla pentaho-reporting libraries.

Using the workaround from comment 24 is a valid alternative to patching our system libraries.

(In reply to Martin Whitaker from comment #31)
> Using the workaround from comment 24 is a valid alternative to patching our
> system libraries.

We would need to automate that.
Or find out why it's needed.

(In reply to Thierry Vignaud from comment #32)
> Or find out why it's needed.

Previously LibreOffice would have added the apache-commons-logging jar to its class path because it used it directly. Now it doesn't.

Having said that, in light of the continuing security issues with log4j, it might be better to eliminate the use of apache-commons-logging wherever we can.

Created attachment 13099 [details]
Set of patches to eliminate use of apache-commons-logging from affected Java libraries

In case you want to fix this bug by removing the use of apache-commons-logging from the unbundled Java libraries, here are the set of patches I used. These are taken from Fedora and rebased/fixed against the newer versions of the libraries we have in Mageia 8.

Created attachment 13148 [details]
Trace when running the report

Hello,
I hit a similar problem trying to run a report with a csv file.
In cauldron, after the workaround of comment 24, I get also an error, here I join the stacktrace.

CC: (none) => yves.brungard_mageia

Just remind that this is still valid with current ibreoffice-7.3.2.2-1.mga8
And the workaround of comment#24 not works

Summary: Mageia's LibreOffice 7.2.x cannot run a report from an odb file => Mageia's LibreOffice >= 7.2.x cannot run a report from an odb file
Source RPM: libreoffice-7.2.5.2-1.mga8 apache-commons-logging => ibreoffice-7.3.2.2-1.mga8 apache-commons-logging

can you write a complete way to reproduce ? 

i don't have a crash opening the file from comment #2 with an up to date mageia 8

@Nicolas
The crash does not occur at opening the file, it occurs when running the report that's defined in it.

@Nicolas, see comment 13 for how to reproduce. See my comments from 30 to 35 for root cause analysis and a way to fix it.

https://bugs.documentfoundation.org/show_bug.cgi?id=148841

Yeah, that's OpenSUSE running into the same problem with an own build of their rpm's, only 6 months after I reported the problem here. To the contrary of Fedora which has (had???) not this issue.

For clarity removing NEEDINFO, questions seem answered.

Keywords: NEEDINFO => (none)

(In reply to Herman Viaene from comment #42)
> Yeah, that's OpenSUSE running into the same problem with an own build of
> their rpm's, only 6 months after I reported the problem here. To the
> contrary of Fedora which has (had???) not this issue.

with Martin infos, i think this will be soon a nonbug :-)

src.rpms:

- libformula-1.1.6-12.2.mga8
- librepository-1.1.6-14.1.mga8
- libserializer-1.1.6-14.1.mga8
- pentaho-libxml-1.1.6-13.1.mga8
- libloader-1.1.6-12.2.mga8
- libbase-1.1.6-13.1.mga8
- libfonts-1.1.6-13.mga8
- liblayout-0.2.10-12.1.mga8
- pentaho-reporting-flow-engine-0.9.4-15.1.mga8



With all this it still crashes but with a new error:

$ libreoffice
mai 02, 2022 8:48:41 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFOS: LibSerializer 1.1.6.${build.id} started.
mai 02, 2022 8:48:41 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFOS: LibBase 1.1.6.${build.id} started.
mai 02, 2022 8:48:41 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFOS: LibLoader 1.1.6.${build.id} started.
mai 02, 2022 8:48:41 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFOS: LibRepository 1.1.6.${build.id} started.
mai 02, 2022 8:48:42 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFOS: LibFonts 1.1.6.${build.id} started.
mai 02, 2022 8:48:42 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFOS: LibLayout null started.
mai 02, 2022 8:48:42 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFOS: LibFormula 1.1.6.${build.id} started.
mai 02, 2022 8:48:42 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFOS: LibXML 1.1.6.${build.id} started.
mai 02, 2022 8:48:42 PM org.pentaho.reporting.libraries.base.boot.PackageManager loadModule
AVERTISSEMENT: Exception while loading module: org.pentaho.reporting.libraries.base.boot.DefaultModuleInfo={ModuleClass=org.jfree.report.modules.gui.swing.common.SwingCommonModule} : java.lang.NullPointerException
mai 02, 2022 8:48:42 PM org.pentaho.reporting.libraries.base.boot.PackageManager loadModule
AVERTISSEMENT: Exception while loading module: org.pentaho.reporting.libraries.base.boot.DefaultModuleInfo={ModuleClass=org.jfree.report.modules.gui.swing.html.SwingHtmlModule} : java.lang.NullPointerException
mai 02, 2022 8:48:42 PM org.pentaho.reporting.libraries.base.boot.PackageManager loadModule
AVERTISSEMENT: Exception while loading module: org.pentaho.reporting.libraries.base.boot.DefaultModuleInfo={ModuleClass=org.jfree.report.modules.gui.swing.pdf.SwingPdfModule} : java.lang.NullPointerException
mai 02, 2022 8:48:42 PM org.pentaho.reporting.libraries.base.boot.PackageManager loadModule
AVERTISSEMENT: Exception while loading module: org.pentaho.reporting.libraries.base.boot.DefaultModuleInfo={ModuleClass=org.jfree.report.modules.gui.swing.preview.SwingPreviewModule} : java.lang.NullPointerException
mai 02, 2022 8:48:42 PM org.pentaho.reporting.libraries.base.boot.PackageManager loadModule
AVERTISSEMENT: Exception while loading module: org.pentaho.reporting.libraries.base.boot.DefaultModuleInfo={ModuleClass=org.jfree.report.modules.gui.swing.printing.SwingPrintingModule} : java.lang.NullPointerException
mai 02, 2022 8:48:42 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFOS: Pentaho Reporting Flow-Engine null started.
mai 02, 2022 8:48:42 PM org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory execute
GRAVE: ReportProcessing failed: org.libreoffice.report.ReportExecutionException: Failed to load style-mapper

@Nicolas, yes, you'll also need to backport the fix from bug 28672.

yes perfect :-)


Please try with new rpms seems to work here :-)


src.rpms:

- libformula-1.1.6-12.2.mga8
- librepository-1.1.6-14.1.mga8
- libserializer-1.1.6-14.1.mga8
- pentaho-libxml-1.1.6-13.1.mga8
- libloader-1.1.6-12.3.mga8
- libbase-1.1.6-13.1.mga8
- libfonts-1.1.6-13.mga8
- liblayout-0.2.10-12.1.mga8
- pentaho-reporting-flow-engine-0.9.4-15.1.mga8

Installed
pentaho-reporting-flow-engine-0.9.4-15.1.mga8.noarch mar. 03 mai 2022 09:13:32
libserializer-1.1.6-14.1.mga8.noarch          mar. 03 mai 2022 09:13:32
liblayout-0.2.10-12.1.mga8.noarch             mar. 03 mai 2022 09:13:32
libformula-1.1.6-12.2.mga8.noarch             mar. 03 mai 2022 09:13:32
pentaho-libxml-1.1.6-13.1.mga8.noarch         mar. 03 mai 2022 09:13:31
librepository-1.1.6-14.1.mga8.noarch          mar. 03 mai 2022 09:13:31
libloader-1.1.6-12.3.mga8.noarch              mar. 03 mai 2022 09:13:31
libbase-1.1.6-13.1.mga8.noarch                mar. 03 mai 2022 09:13:31
Now, I can generate the report in the example from Herman
OK
mga 8 - x86_64

thank you:


Here is the final package list 


src.rpms:

- libformula-1.1.6-12.2.mga8
- librepository-1.1.6-14.1.mga8
- libserializer-1.1.6-14.1.mga8
- pentaho-libxml-1.1.6-13.1.mga8
- libloader-1.1.6-12.3.mga8
- libbase-1.1.6-13.1.mga8
- libfonts-1.1.6-13.1.mga8
- liblayout-0.2.10-12.1.mga8
- pentaho-reporting-flow-engine-0.9.4-15.1.mga8

MGA8-64 Plasma on Lenovo B50 in Dutch
No installation issues.
First reproduced the error with the current installation from the Mageia repos, then applied the rpm's listed above and YYYYYEEEESSSSSS, that got rid of the issue.
Hoping I'll never see this ugly thing again.

Whiteboard: (none) => MGA8-64-OK

Then let's send this one along! Validating. I don't see anything of an advisory...

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

advisory:

Libreoffice provided in mageia 8 had a broken java library resulting in a broken libreoffice base.

This update fixes this and make libreoffice base usuable again.

src.rpms:

- libformula-1.1.6-12.2.mga8
- librepository-1.1.6-14.1.mga8
- libserializer-1.1.6-14.1.mga8
- pentaho-libxml-1.1.6-13.1.mga8
- libloader-1.1.6-12.3.mga8
- libbase-1.1.6-13.1.mga8
- libfonts-1.1.6-13.1.mga8
- liblayout-0.2.10-12.1.mga8
- pentaho-reporting-flow-engine-0.9.4-15.1.mga8

(In reply to Nicolas Lécureuil from comment #52)
> advisory:
> 
> Libreoffice provided in mageia 8 had a broken java library resulting in a
> broken libreoffice base.
> 
> This update fixes this and make libreoffice base usuable again.
> 
> src.rpms:
> 
> - libformula-1.1.6-12.2.mga8
> - librepository-1.1.6-14.1.mga8
> - libserializer-1.1.6-14.1.mga8
> - pentaho-libxml-1.1.6-13.1.mga8
> - libloader-1.1.6-12.3.mga8
> - libbase-1.1.6-13.1.mga8
> - libfonts-1.1.6-13.1.mga8
> - liblayout-0.2.10-12.1.mga8
> - pentaho-reporting-flow-engine-0.9.4-15.1.mga8

Why still not arrive to updates ?

urpmq -pi pentaho-reporting-flow-engine
Name        : pentaho-reporting-flow-engine
Epoch       : 1
Version     : 0.9.4
Release     : 14.mga8
Group       : System/Libraries
Size        : 438675                       Architecture: noarch
Source RPM  : pentaho-reporting-flow-engine-0.9.4-14.mga8.src.rpm
URL         : http://reporting.pentaho.org/
Summary     : Pentaho Flow Reporting Engine
Description :
Pentaho Reporting Flow Engine is a free Java report library, formerly
known as 'JFreeReport'

rpm -q pentaho-reporting-flow-engine
pentaho-reporting-flow-engine-0.9.4-14.mga8

Which mirror?
# urpmq -i pentaho-reporting-flow-engine|grep ^Source|sort -uV
Source RPM  : pentaho-reporting-flow-engine-0.9.4-14.mga8.src.rpm
Source RPM  : pentaho-reporting-flow-engine-0.9.4-15.1.mga8.src.rpm
# urpmq --list-url|grep 'Core Updates Testing'
Core Updates Testing (distrib5) http://mirrors.kernel.org/mageia/distrib/8/x86_64/media/core/updates_testing

CC: (none) => davidwhodgins

Advisory committed to svn.

Keywords: (none) => advisory

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2022-0063.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED

(In reply to Dave Hodgins from comment #54)
> Which mirror?
> # urpmq -i pentaho-reporting-flow-engine|grep ^Source|sort -uV
> Source RPM  : pentaho-reporting-flow-engine-0.9.4-14.mga8.src.rpm
> Source RPM  : pentaho-reporting-flow-engine-0.9.4-15.1.mga8.src.rpm
> # urpmq --list-url|grep 'Core Updates Testing'
> Core Updates Testing (distrib5)
> http://mirrors.kernel.org/mageia/distrib/8/x86_64/media/core/updates_testing

https://mirror.math.princeton.edu/

But now it is, thanks

Since that version LO 7.3.6.2  which was OK, all subsequent versions of the LO in Mageia had this problem all over again (the latest M9beta included).
I mentioned that in bug 31021, but that didn't have the impact I expected, so trying here again.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Please open a new bug referring to this bug. This bug has already been used to
push an update. Re-closing.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

(In reply to Herman Viaene from comment #58)
> Since that version LO 7.3.6.2  which was OK, all subsequent versions of the
> LO in Mageia had this problem all over again (the latest M9beta included).

I can't reproduce that, using libreoffice-base-7.4.5.1-1.mga8 and following the instructions in comment 13.

@Dave
Bug 31021 not good enough???

@Martin
The last line in Comment 13 should read: "...double click the report".

@Herman, the report is named Query_Assignments. Double clicking that opens a new window displaying the report.

You are seeing the error on Mageia 8, not cauldron?

@Martin
I looked a bit more in detail to the report, and it is not OK in libreoffice-base-7.4.5.1-1.mga8.
At least it doesn't crash, but the report shows all lines on one page, while it should be 3 pages with a break on the deptname.
I tested the same file emp.odb on my "production" desktop running the rmp's provided by LO (giving 3 pages with expected breaks) and my testing laptop Acer Aspire 5253 with the libreoffice-base-7.4.5.1-1.mga8.
For M9 see bug 31021.

(In reply to Herman Viaene from comment #61)
> @Dave
> Bug 31021 not good enough???

In comment 58, this bug was reopened making it show up again in
http://madb.mageia.org/tools/updates

When I was going through the list of validated updates, adding the advisories
to svn, I noticed it. As the advisory has already been added to svn and used
to push the update from this bug, I reclosed this bug and added comment 59.

bug 31021 looks fine for m9. Either mark it as mga8too or open a new bug for
the current m8 version of libreoffice.