Bug 2151985 - %mingw_find_lang clobbers previous %find_lang results
Summary: %mingw_find_lang clobbers previous %find_lang results
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mingw-filesystem
Version: 37
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 2148781 2148783 2178627
TreeView+ depends on / blocked
 
Reported: 2022-12-08 19:06 UTC by Daniel Berrangé
Modified: 2023-03-15 13:25 UTC (History)
5 users (show)

Fixed In Version: mingw-filesystem-143-1.fc37 mingw-filesystem-133-3.fc36
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-12-18 01:40:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Daniel Berrangé 2022-12-08 19:06:14 UTC
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:

Comment 1 Sandro Mani 2022-12-08 19:31:55 UTC
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.

Comment 2 Daniel Berrangé 2022-12-09 08:14:53 UTC
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.

Comment 3 Sandro Mani 2022-12-09 08:23:36 UTC
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.

Comment 4 Daniel Berrangé 2022-12-09 08:45:33 UTC
Yes, that would be OK with me.

Comment 5 Fedora Update System 2022-12-09 11:51:36 UTC
FEDORA-2022-e1b443388c has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e1b443388c

Comment 6 Fedora Update System 2022-12-09 11:51:37 UTC
FEDORA-2022-71012ec845 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-71012ec845

Comment 7 Fedora Update System 2022-12-10 02:48:33 UTC
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.

Comment 8 Fedora Update System 2022-12-10 03:01:27 UTC
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.

Comment 9 Fedora Update System 2022-12-18 01:40:13 UTC
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.

Comment 10 Fedora Update System 2022-12-18 01:40:45 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.