Description of problem: I made an application in Libreoffice Base with LO6 in Mageia 7. This application runs correctly in LO7.0.2.2 on PCLinuxOs and LO4.0.4.2 on Win 10. In Mageia 8 with LO7.0.4.2, the odb opens correctly, the tables show OK, but running a report throws an error "Failed to load style-mapper" Version-Release number of selected component (if applicable): Mageia 8 , Libreoffice 7.0.4.2 How reproducible: I made a small odb that reproduces the issue, I'll will upload it Steps to Reproduce: 1.Open the emp.odb 2.Run the only report defined in it
Created attachment 12543 [details] LibreOffice application demonstrating the erroro
Sorry, mistake in second line, should read I made an application in Libreoffice Base with LO6 in Mageia 7. This application runs correctly in LO 7.0.2.2 on PCLinuxOs and LO 7.0.4.2 on Win 10.
Created attachment 12544 [details] The error dialogue on trying to run the report Thanks for the report, Herman. Would it be possible for you to post a sample screenshot (without showing anything sensitive) of what what it looks like when it works. [I used flameshot for mine, it allows in-line addition of text + other things]
CC: (none) => lewyssmith
And thank you for the trouble of providing the example DB + report.
Summary: Problem running report in Libreoffice base => Problem running report in Libreoffice base 7.0.4.2-5, which works on other LO 7.0.2.2 & 7.0.4.2Source RPM: (none) => libreoffice-7.0.4.2-5.mga8.src.rpmStatus: NEW => NEEDINFO
Created attachment 12545 [details] Report output on LO 6.4.7.0 from emp.odb
BTW: the output is an .odt file. Would that be usefull to attach that one as well???
(In reply to Herman Viaene from comment #6) > BTW: the output is an .odt file. Would that be usefull to attach that one as > well??? I think not. Thanks for the how-it-should-look screenshot. Assigning this to Thierry who seems to be the main LibreOffice maintainer.
Assignee: bugsquad => thierry.vignaudStatus: NEEDINFO => NEWCC: lewyssmith => (none)
I installed the current 7.1.4.2 version from LO itself, and there this problem does not occur (anymore). I've tested this because I needed thids version to overcome an instability issue in LO versions 7.0.4 and 7.0.6. BTW; that test is on a M7 installation because I hope to shortly be allowed to get rid of it.
Does it work better with libreoffice-core-7.2.2.2-1.mga8 from updates?
Keywords: (none) => NEEDINFO
No, it has the same error. BTW, the 7.2.2.2 version from LO itself worked OK. I had to remove that one before installing the Mageia version. And BTW 2: the installation from updates using MCC forced the installation of the de-language pack. This is a Dutch installation, so I had to select manually the nl-language pack, and after installtion I could the remove the de.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=29731
This was broken by the libloader-1.1.6-remove-antcontrib-support.patch. Fedora have fixed their version of this patch: https://src.fedoraproject.org/rpms/libloader/c/e929271d69b478aef710c143f45f0962d72a456c?branch=rawhide I've tested it locally on a Mageia 8 system and it fixes the fault.
Keywords: NEEDINFO => (none)Assignee: thierry.vignaud => javaCC: (none) => mageiaSource RPM: libreoffice-7.0.4.2-5.mga8.src.rpm => libloader-1.1.6-12.mga8.src.rpm
As usual, you rocks man :-) !
CC: (none) => thierry.vignaud
huhu, the patch that broke it in Fedora came from us :-) : https://src.fedoraproject.org/rpms/libloader/c/03aa2d95b67cc00c26e22648e765310cfc75dadb?branch=rawhide
Source RPM: libloader-1.1.6-12.mga8.src.rpm => -1.1.6-12.mga8.src.rpm
Nicolas, can you fix libloader in both cauldron & mga8? Sadly https://src.fedoraproject.org/rpms/libloader/c/e929271d69b478aef710c143f45f0962d72a456c?branch=rawhide cannot be backported right away as we've 1.1.6 whereas Fedora has 1.1.3
Source RPM: -1.1.6-12.mga8.src.rpm => libloader-1.1.6-12.mga8.src.rpmCC: (none) => mageia
i think i had been a little too aggressiv when i removed antcontrib support. Can someone test the new rpm in cauldron first ?
Note for anyone testing this - you will need to use the workaround described in bug 29556 comment 24 until that bug is also fixed.
As bug#29556 is solved, i think this bug also need to be closed
Thus closing
Status: NEW => RESOLVEDCC: (none) => friResolution: (none) => FIXED