Since RPM 4.20 landed in Rawhide, libreoffice fails to build with: RPM build errors: Installed (but unpackaged) file(s) found: /usr/lib64/libreoffice/share/autotext/nn/standard.bau This is visible in https://koschei.fedoraproject.org/package/libreoffice and it blocks the Python 3.13 rebuild planned for next week. The package that owns the file in the last successful build is libreoffice-langpack-nn-1:24.2.3.2-2.fc41.x86_64 -- and it is generated by a macro in the spec. I suspect something is behaving differently now with the new RPM version wrt the macro, but I have not tried to debug what is going on.
Created attachment 2036081 [details] Diff of `rpmspec --undefine 'dist' -P libreoffice.spec` on f40 and rawhide
The relevant parsed %files section seems identical on f40 and rawhide: ====================================================== %files langpack-nn /usr/lib64/libreoffice/program/resource/nn /usr/lib64/libreoffice/share/registry/res/registry_nn.xcd /usr/lib64/libreoffice/share/template/nn /usr/lib64/libreoffice/share/registry/Langpack-nn.xcd /usr/lib64/libreoffice/share/registry/res/fcfg_langpack_nn.xcd /usr/lib64/libreoffice/share/wizards/resources_nn.properties /usr/lib64/libreoffice/share/autotext/nn ====================================================== That should include /usr/lib64/libreoffice/share/autotext/nn/standard.bau, so the "Installed (but unpackaged) file(s) found" error does not make sense to me. Reassigning to rpm.
Created attachment 2036129 [details] Diff of parsed libreoffice.spec between rpm 4.19 and git master Thanks for the report. That diff seems very very wrong, but it's also nothing like what I see here (although looking at rpm git master). Attached what I see, and basically the only strange thing there is .. this: -/usr/lib64/libreoffice/share/autotext/nn + Why just that line should go missing, I have absolutely no idea. Looks like I have another murder mystery to solve today...
*Thankfully* that spec diff is reproducable for me locally just by parsing the spec, so it can be bisected. If it dependended on building LO, this would be a painful exercise... Off to bisect now.
In the end didn't even need to bisect, just eyeball 'git log rpmio/macro.c' for a bit. The /usr/lib64/libreoffice/share/autotext/nn difference is caused by the fix to this bug, incidentally reported by yourself: https://github.com/rpm-software-management/rpm/issues/3056 So most likely libreoffice.spec is relying on the buggy behavior in this one case: AFAICS %langpack -nn is the only thing using this particular combination of flags: "-F -H -Y -M -T", other similar are additionally supplying -X (and -A). I've no idea what these swithes do, but this patch to libreoffice.spec: -%langpack -l nn -n Nynorsk -F -H -Y -M -T +%langpack -l nn -n Nynorsk -F -H -Y -M -T -X ...results in this diff in the parsed spec: --- /tmp/nn1.spec 2024-06-03 09:39:15.972958163 +0300 +++ /tmp/nn2.spec 2024-06-03 09:39:22.954031427 +0300 @@ -2876,7 +2876,7 @@ /usr/lib64/libreoffice/share/registry/res/fcfg_langpack_nn.xcd /usr/lib64/libreoffice/share/wizards/resources_nn.properties - +/usr/lib64/libreoffice/share/autotext/nn So I think we have our smoking gun, the %langpack -l nn invocation is just missing -X for whatever reason, and this was previously masked by the rpm bug leaking local macros. And, looking at the earlier invocations of the %langpack, guess what we have on just the line above: %langpack -l nl -n Dutch -F -H -Y -M -A -T -X -X %langpack -l nn -n Nynorsk -F -H -Y -M -T This looks like an editing mistake, appending ' -X' to several lines in a row with 'j' and '.' in vi, and getting the sequence wrong on that one line. And, this will result exactly in the behavior seen: in rpm < 4.20 the double -X will carry over to the next invocation unintentionally, in >= 4.20 it gets mopped up as it should. So, happy end: bizarre looking bug had a simple logical explanation, and is actually a fix and not a regression. Reassigning to libreoffice.
Thanks!
FEDORA-2024-1bfbfaae06 (libreoffice-24.2.3.2-3.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-1bfbfaae06
FEDORA-2024-1bfbfaae06 (libreoffice-24.2.3.2-3.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.