7:41 a.m.
Hi all,
While reviewing switchboard-plug-onlineaccounts [0], I noticed the
package places files in /usr/share/locale/mo which isn't owned by
anything. This isn't allowed by the packaging guidelines. Normally such
folders should be owned by filesystem. There are more packages which
place files in /usr/share/locale/mo, most noticable iso-codes:
/usr/share/locale/mo/LC_MESSAGES/[iso_3166.mo|iso_3166-1.mo]. Since
filesystem uses iso-codes to create the directory structure, this is odd.
The origin of
/usr/share/locale/mo/LC_MESSAGES/[iso_3166.mo|iso_3166-1.mo] is [1].
This file provides translation of ISO 3166-1 to Moldovan. The file names
seems to be created using iso-639 codes, but the problem is that the
"mo" ISO 639-1 code is deprecated. This is why filesystem doesn't
create/own the /usr/share/locale/mo directory.
There are more directories with missing ownership (probably with
different reasons), I have compiled a list of them:
==============
am_ET
ar_LY
ar_MA
ar_SA
ary
as_IN
bar
be_BY
be@tarask
ca_ES@valencia
cak
cz
en_BR
es_419
es_ar
gr
gug
gug_PY
hy_AM
hye
it_CH
jam
kmr
ko_KO
kok@roman
ko.UTF-8
ks@deva
ks_IN
LC_MESSAGES
miq
mjw
mnw
mnw_MM
mo
ms@Arab
pa_IN
pl.UTF-8
pt_br
ro_MD
sd@devanagari
sr_BA@latin
sr_CS
sr_Cyrl
sr_Latn
zh_cn
zh_CN.UTF-8
zh_Hans
zh_Hans_CN
zh_Hant
zh_SG
zh_TW.UTF-8
===============
I'm not familiar with this stuff, so I'm not sure how to solve this
issue. I would like to complete my review of
switchboard-plug-onlineaccounts, but this issue blocks it. I see
multiple solutions:
- Ignore it and approve switchboard-plug-onlineaccounts (this is against
the packaging guidelines)
- Patch it, so that "mo" is renamed to "ro" or "rom" and
create an issue
upstream. I'm not sure how feasible this is, since "mo" is effectively
removed and there are also translation files for "ro". This may also
cause conflict.
- Add an entry to lang-exceptions [2] in filesystem to include "mo"
- Suggest upstream iso-codes to look into this issue
For the other directories, I sadly don't have time to look into all of
them, and I think I have too little knowledge in this field.
Regards,
Arthur
[0] https://bugzilla.redhat.com/show_bug.cgi?id=2033886
[1]
https://salsa.debian.org/iso-codes-team/iso-codes/-/blob/main/iso_3166-1/...
[2]
https://src.fedoraproject.org/rpms/filesystem/blob/rawhide/f/lang-exceptions
5:46 a.m.
On Fri, Dec 31, 2021 at 02:41:56PM +0100, Arthur Bols wrote:
The origin of
/usr/share/locale/mo/LC_MESSAGES/[iso_3166.mo|iso_3166-1.mo]
is [1]. This file provides translation of ISO 3166-1 to Moldovan. The file
names seems to be created using iso-639 codes, but the problem is that the
"mo" ISO 639-1 code is deprecated. This is why filesystem doesn't
create/own
the /usr/share/locale/mo directory.
I'm not familiar with this stuff, so I'm not sure how to
solve this issue. I
would like to complete my review of switchboard-plug-onlineaccounts, but
this issue blocks it. I see multiple solutions:
- Ignore it and approve switchboard-plug-onlineaccounts (this is against the
packaging guidelines)
- Add an entry to lang-exceptions [2] in filesystem to include "mo"
- Suggest upstream iso-codes to look into this issue
Yet another solution is to make the package own the 'mo' directory,
i.e. list it in %files. (If a different package does the same, they will
co-own the directory, which is OK.)
Zbyszek
6:01 a.m.
On Sat, Jan 1, 2022 at 12:46 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Fri, Dec 31, 2021 at 02:41:56PM +0100, Arthur Bols wrote:
> The origin of /usr/share/locale/mo/LC_MESSAGES/[iso_3166.mo|iso_3166-1.mo]
> is [1]. This file provides translation of ISO 3166-1 to Moldovan. The file
> names seems to be created using iso-639 codes, but the problem is that the
> "mo" ISO 639-1 code is deprecated. This is why filesystem doesn't
create/own
> the /usr/share/locale/mo directory.
> I'm not familiar with this stuff, so I'm not sure how to solve this issue.
I
> would like to complete my review of switchboard-plug-onlineaccounts, but
> this issue blocks it. I see multiple solutions:
> - Ignore it and approve switchboard-plug-onlineaccounts (this is against the
> packaging guidelines)
> - Add an entry to lang-exceptions [2] in filesystem to include "mo"
> - Suggest upstream iso-codes to look into this issue
Yet another solution is to make the package own the 'mo' directory,
i.e. list it in %files. (If a different package does the same, they will
co-own the directory, which is OK.)
Note that people have been encountering issues like this for almost a
decade, as far as I can tell:
First mention of unowned / unrecognised languages I could find /
remember is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1103545
The "mo" locale also came up in my first package review (that's a trip
down memory lane!):
https://bugzilla.redhat.com/show_bug.cgi?id=1398433
And it seems that just nobody cares (literally for almost ten years
now) whether those directories are unowned, or whether rpmlint
recognises those languages, etc. ...
There's also *lots* of packages that ship translations for "mo". It
seems that launchpad.net's translation functionality had this in the
default set of languages or something, as almost every project
originating in the launchpad.net ecosystem (most ubuntu stuff and most
elementary OS stuff) has translations for "mo".
I'm pretty sure I won't add ownership of /usr/share/locale/mo to
literally dozens of packages just so this minor issue is "fixed". I
think the filesystem package should create and own it.
Fabio
6:09 a.m.
On 01/01/2022 12:01, Fabio Valentini wrote:
I'm pretty sure I won't add ownership of /usr/share/locale/mo
to
literally dozens of packages just so this minor issue is "fixed". I
think the filesystem package should create and own it.
Surely a symlink from mo to ro would be better so that people
can set LANG=ro (the correct code) and get all the translations
for Moldovan regardless of whether packages use the old or new
code for it.
Ideally of course upstreams should be poked to fix their packages
to use the correct code.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
7:40 a.m.
On 01/01/2022 13:09, Tom Hughes via devel wrote:
Surely a symlink from mo to ro would be better so that people
can set LANG=ro (the correct code) and get all the translations
for Moldovan regardless of whether packages use the old or new
code for it.
I think this would create problems since packages would try to place
files in /ro and /mo at the same time.
ro isn't exactly new, mo was removed [0] for reasons. It seems it was
just an alias for Romanian [1] (although this is probably very short
sighted). The Romanian language is much more in use than Moldovan ever
is/was, so packages which would ship translations for mo would most
probably also have translations for ro.
So the symlink would probably not be useful.
Arthur
[0] https://www.loc.gov/standards/iso639-2/php/code_changes.php
[1] https://en.wikipedia.org/wiki/Moldovan_language
856
days inactive
857
days old
4 comments
4 participants
participants (4)
-
Arthur Bols -
Fabio Valentini -
Tom Hughes -
Zbigniew Jędrzejewski-Szmek