Description of problem: A bunch of mingw packages have been folded back into their native package specfiles to reduce the maint burden. Everything appeared to be fairly easy but I recently became aware of a flaw with locale handling. Essentially we have a pattern %meson_install %find_lang %{name} %mingw_ninja_install %mingw_find_lang %{name} Conceptually the first %find_lang call should only find the native locale files, since we've not run '%mingw_ninja_install' yet to install the mingw files. In practice though, the native %{name}.lang file, ends up containing both the native local file paths, and both sets of mingw local file paths. What happens is that /usr/lib/rpm/mingw-find-lang.sh secretly re-runs /usr/lib/rpm/find-lang.sh, and so clobbers the %{name}.lang file we created prior to installing the mingw bits. I think the /usr/lib/rpm/mingw-find-lang.sh script needs to take action to prevent this clobbering eg it should do this: test -f $2.lang && mv $2.lang $2-native.lang /usr/lib/rpm/find-lang.sh $* test -f $2-native.lang && mv $2-native.lang $2.lang Right now, I'm having to apply a workaround myself in theu specs %find_lang %{name} mv %{name}.lang %{name}-native.lang %files -f %{name}-native.lang but it will be quite error prone to expect all maintainers to remember to preserve the output of their %find_lang call, and updates the %files section to reference it. So I think we should fix mingw-find-lang.sh to not clobber things Version-Release number of selected component (if applicable): mingw-filesystem-base-141-1.fc37.noarch How reproducible: Always Steps to Reproduce: 1. Run %meson_install %find_lang %{name} %mingw_ninja_install %mingw_find_lang %{name} 2. Look at %{name}.lang Actual results: %{name}.lang contains native and both mingw sets of locales Expected results: %{name}.lang only contains native locale files Additional info:
Is test -f $2.lang && mv $2.lang $2-native.lang /usr/lib/rpm/find-lang.sh $* test -f $2-native.lang && mv $2-native.lang $2.lang really sufficient? find-lang.sh will itself pick up mingw translations, so mingw-find-lang.sh shoud actually filter out the mingw prefixes from any existing $2.lang - though this only works if the native find_lang.sh is run before the mingw-find-lang.sh. Or find_lang.sh should accept a --prefix option to only return the results within that prefix.
It is sufficient provided you invoke %find_lang *BEFORE* %mingw_ninja_install, which is the way I've got all my spec files arranged, because I've fully separated the mingw phase from the native phase, in %install so the whole mingw build can be disabled in RHEL branches.
One could do test -f $2.lang && grep -v mingw32 $2.lang > $2-native.lang /usr/lib/rpm/find-lang.sh $* test -f $2-native.lang && mv $2-native.lang $2.lang This way, the order would not matter.
Yes, that would be OK with me.
FEDORA-2022-e1b443388c has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e1b443388c
FEDORA-2022-71012ec845 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-71012ec845
FEDORA-2022-71012ec845 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-71012ec845` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-71012ec845 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-e1b443388c has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-e1b443388c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e1b443388c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-71012ec845 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-e1b443388c has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.