Red Hat Bugzilla – Bug 968808
Interlingua installs result in errors setting locale and apparent failure of g-i-s to create a user account
Last modified: 2013-06-18 21:10:01 EDT
This probably isn't really an anaconda bug, but not sure where else to put it for now.
Interlingua was added to the language list in anaconda 19.30.1. I did a test install with it. The install completes successfully, but there appear to be problems in the installed system.
I didn't create a user in anaconda, so g-i-s ran to create a user account. The g-i-s wizard went through apparently fine, but after it finished, the desktop session never appeared, neither did GDM. Forcing a reboot caused g-i-s to run again. Trying to login as the user I created at a console failed.
Logging in as root as a console I see a bunch of errors:
-bash: warning: setlocale: LC_CTYPE: cannot change locale (ia.UTF-8): No such file or directory
and the same for COLLATE, MESSAGES, NUMERIC and TIME.
There is no /usr/share/i18n/locales/ia . There is a /usr/share/i18n/locales/ia_FR , though.
I suspect g-i-s' failure to create a user is related to the locale problem. I guess either anaconda should set ia_FR.UTF-8 as the locale for interlingua, or we need a bare 'ia' locale?
[mfabian@Fedora-19-Beta-RC4-x86_64-netins ~]$ locale -a | grep ^ia
I.e. anaconda should set “ia_FR.UTF-8” locale.
I made langtable.py (langtable 0.0.4) return this:
Python 2.7.3 (default, Aug 9 2012, 17:23:57)
[GCC 4.7.1 20120720 (Red Hat 4.7.1-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import langtable
>>> from langtable import list_locales
>>> from langtable import list_keyboards
>>> from langtable import list_consolefonts
>>> from langtable import language_name
>>> list_locales(languageId="ia", territoryId="FR")
['ia_FR.UTF-8', 'fr_FR.UTF-8', 'br_FR.UTF-8', 'oc_FR.UTF-8', 'ca_FR.UTF-8']
>>> list_keyboards(languageId="ia", territoryId="FR")
>>> language_name(languageId="ia", languageIdQuery="en")
Well, what's in /etc/locale.conf?
The patch that should resolve this issue has been posted to anaconda-patches. However, it is a fairly intrusive patch (because it tries to do things the right way not the easiest way) and thus a special compose  with it included has been created for testing. If it get's some testing and it turns out there are no regressions, the patch could be included in the f19-branch, otherwise it will go only to the master branch targetting Fedora 20.
Please test the .iso file above and check if choosing different languages work for both the installation process and the installed system. What should be different with the patch are names of some languages and this issue fixed. Moreover anaconda should consume ~20 MB less memory (can be checked with 'grep RSS /proc/`cat /var/run/anaconda.pid`/status'). And the patch streamlines and clears the code a lot, so I'd really like it included in the f19-branch.
Proposing as a freeze exception since the system installed with "Interlingua" chosen as language is fairly broken.
Vratislav, just wanted to check something: as I read it, the langtable patch essentially affects only locale setting, right? It doesn't do anything else with langtable yet. So we'd just need to do installs with each of the languages listed on the first screen, and check that they used the correct language and locale during install and post-install (or at least were no worse than without the patch), right?
Tested so far English (US), French, Japanese and Interlingua installs and all worked fine, looking good. I'll try a few more later.
(In reply to Adam Williamson from comment #7)
> Vratislav, just wanted to check something: as I read it, the langtable patch
> essentially affects only locale setting, right? It doesn't do anything else
> with langtable yet. So we'd just need to do installs with each of the
> languages listed on the first screen, and check that they used the correct
> language and locale during install and post-install (or at least were no
> worse than without the patch), right?
Basically yes, the patch I've sent is intentionally using langtable only to fix some issues, but to preserve the same behaviour as the code we had so far. There are small changes in the language names on the Welcome screen and some issues with the locales (like the one described in this bug) should be fixed.
Some more usage of the langtable (setting better keyboard and timezone defaults, etc.) will come later, not for the Fedora 20, as they will change the behaviour. I'd also like to come up with a two-phase language-locale selection allowing users to choose the locale they want to use, not the language. Something like (in a GUI version):
1. Choose a language:
2. Choose a variant:
English (United States)
Anyway, the patch has been approved for both master and f19-branch. In case of any troubles I can provide a fix or we can revert the patch.
should fix this issue.
Discussed at 2013-06-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-17/f19final-blocker-review-6.2013-06-17-16.01.log.txt . Accepted as a freeze exception issue as we want to fix locale issues before release, they cannot be fixed post-release. Testing so far is positive. The change will be in TC4 once we get that built.
Confirmed fixed as of TC5. Closing.