Bug 1266749 - Package gedit installs .mo language files in wrong folder /usr/@DATADIRNAME@/locale/
Package gedit installs .mo language files in wrong folder /usr/@DATADIRNAME@/...
Status: CLOSED DUPLICATE of bug 1258110
Product: Fedora
Classification: Fedora
Component: gedit (Show other bugs)
21
Unspecified Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-27 07:36 EDT by c72578
Modified: 2015-10-23 08:11 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-23 08:11:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to spec-file (205 bytes, patch)
2015-10-06 10:31 EDT, Pieter D.J. Krul
no flags Details | Diff
Patch to spec-file (1.01 KB, patch)
2015-10-06 15:13 EDT, Pieter D.J. Krul
no flags Details | Diff

  None (edit)
Description c72578 2015-09-27 07:36:45 EDT
Description of problem:
The .mo files of gedit are installed in the following wrong folder:
/usr/@DATADIRNAME@/locale/

Hence, gedit is only available in English, no other languages.

Version-Release number of selected component (if applicable):
gedit.x86_64 2:3.14.4-1.fc21

How reproducible:
Always

Steps to Reproduce:
1. Install gedit-3.14.4-1.fc21.x86_64 using yum
2. ls /usr/@DATADIRNAME@/locale/
3. There the .mo files for the available languages of gedit are installed

Actual results:
.mo files are in a wrong folder /usr/@DATADIRNAME@/locale/

e.g.:
locate gedit.mo
/usr/@DATADIRNAME@/locale/af/LC_MESSAGES/gedit.mo
/usr/@DATADIRNAME@/locale/am/LC_MESSAGES/gedit.mo
/usr/@DATADIRNAME@/locale/an/LC_MESSAGES/gedit.mo
...

Expected results:
.mo files should be in:
/usr/share/locale

e.g.:
locate gedit.mo
/usr/share/locale/af/LC_MESSAGES/gedit.mo
/usr/share/locale/am/LC_MESSAGES/gedit.mo
/usr/share/locale/an/LC_MESSAGES/gedit.mo


Additional info:
Comment 1 Pieter D.J. Krul 2015-10-06 10:31 EDT
Created attachment 1080257 [details]
Patch to spec-file

Patch to fix autoreconf not running libtoolize after intltoolize
Comment 2 Pieter D.J. Krul 2015-10-06 10:33:02 EDT
I see the same undesired /usr/@DATADIRNAME@/locale/ path in the RPM, even after rebuilding.

$ rpm -q --queryformat="%{name}-%{version}.%{arch} - %{buildhost} - %{buildtime}\n\n" gedit

gedit-3.14.4.x86_64 - buildvm-27.phx2.fedoraproject.org - 1437411979

It can be fixed by adding libtoolize to the %setup section in the gedit.spec file (see proposed patch).
Comment 3 c72578 2015-10-06 13:10:33 EDT
Thanks for your patch.
I have tested it [1] and the .mo files are installed into the correct folder:

locate gedit.mo
/usr/share/locale/af/LC_MESSAGES/gedit.mo
/usr/share/locale/am/LC_MESSAGES/gedit.mo
/usr/share/locale/an/LC_MESSAGES/gedit.mo
...

And gedit starts with the language of the currently set locale.

However, some manual cleanup is required, to get rid of the previously installed files, e.g.
rm /usr/@DATADIRNAME@/ -rf


[1] https://copr.fedoraproject.org/coprs/c72578/gedit/
Comment 4 Pieter D.J. Krul 2015-10-06 15:13 EDT
Created attachment 1080354 [details]
Patch to spec-file

Patch to fix autoreconf not running libtoolize after intltoolize, and removing /usr/@DATADIRNAME/ from previous versions.
Comment 5 Pieter D.J. Krul 2015-10-06 15:16:07 EDT
Hi,

Please try the new patch #1080257 which also automates the cleanup from prior versions. I also bumped the release to 2.

Cheers,

Pieter
Comment 6 c72578 2015-10-06 16:34:00 EDT
Hello,
patch #1080257 has just been successfully tried.
The currently distributed gedit-3.14.4-1.fc21.x86_64 was installed first and afterwards updated to the patched rpm from the copr c72578/gedit

The directory /usr/@DATADIRNAME@/ was removed as desired.

Thanks,
Wolfgang
Comment 7 c72578 2015-10-23 08:11:17 EDT

*** This bug has been marked as a duplicate of bug 1258110 ***

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