Scripts in initscripts package give this error: paradise:~# service nscd restart /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8) Stopping nscd: /etc/init.d/functions: line 114: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8) [ OK ] Starting nscd: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8) /etc/init.d/functions: line 114: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8) [ OK ] This is because /etc/init.d/functions sets this variables: TEXTDOMAINDIR=/etc/locale LOCPATH=/etc/locale and I have a locale that loos legal (en_US.utf8), but there is no dir for that locale in /etc/locale: paradise:~# locale -a | grep en_US en_US en_US.iso88591 en_US.utf8 en_US.UTF-8 Options: unset TEXTDOMAINDIR and LOCPATH in initscripts, or use something like this on initscripts or locale install: paradise:~# cat sl #!/bin/bash DIR=/etc/locale for i in $DIR/* do f=$(basename $i) b=${f%.*} s=${f##*.} if [ $b != $s ] then sl=$(echo $s | tr [A-Z] [a-z]) ln -sf $b.$s $DIR/$b.$sl sl=$(echo $s | tr [A-Z] [a-z] | tr -d -) ln -sf $b.$s $DIR/$b.$sl fi done This generates the variants *.utf-8 and *.utf8 for all locales as symlinks. Reproducible: Steps to Reproduce:
But I have: $ ls -1d /etc/locale/en_US* /etc/locale/en_US/ /etc/locale/en_US.UTF-8/ And: $ rpm -q --scripts locales-en postinstall scriptlet (using /bin/sh): /usr/bin/locale_install.sh en_AG en_AU en_BE en_BW en_CA en_DK en_GB en_HK en_IE en_IN en_NG \ en_NZ en_PH en_SG en_US en_ZA en_ZW preuninstall scriptlet (using /bin/sh): if [ "$1" = "0" ]; then /usr/bin/locale_uninstall.sh en_AG en_AU en_BE en_BW en_CA en_DK en_GB en_HK en_IE en_IN \ en_NG en_NZ en_PH en_SG en_US en_ZA en_ZW fi so they should get created when installing locales-en, why they weren't on your system, I don't know... Is this an upgrade or a clean install?
Please compare bug#460
CC: (none) => dvgevers
(In reply to comment #2) > Please compare bug#460 That's a different issue (you can confirm this by looking at the output of 'ls /etc/locale').
Source RPM: initscripts-9.21-5.mga1.src.rpm => locales
I'm refering to locales with the .utf-8 or .utf8 suffix _in lowercase_ and/or _without-the-dash_, that is the problem. According to locale -a output paradise:~# locale -a | grep en_US en_US en_US.iso88591 en_US.utf8 en_US.UTF-8 the 'en_US.utf8' is a valid locale. I use this for compatibility with other systems (look like all RH derivatives use .utf8, like CentOS or SL) at work, where $HOME is shared between several OSes. But if I set this in Mandriva or Mageia, init scripts barf about a non valid locale. Lookin in depth, only the .utf8 (no dash, lowercase) is needed, others like Solaris, OSX or OSF1/Tru64 use .UTF-8 (yup, I share $HOME between Mandriva, Mageia, Solaris, Tru64, CentOS, SL and I think I forget something...yup, Win). But it the convention is that this lowecase naming scheme is incorrect, perhaps something could be done to make it dissapear from Mageia also (ie, don't offer *.utf8 locales). I really don't know which is the standard.
CC: (none) => jamagallon
I see, sorry I missed it the first time. The stuff in /et/locale/ are copied from /usr/share/locale/ , there's no utf8 or uft-8 dirs in /usr/share/locale. This is not a standard situation in Mageia as the Mageia tools that set the locale use UTF-8 AFAICS.
According to http://www.kernel.org/doc/man-pages/online/pages/man3/setlocale.3.html A locale name is typically of the form language[_territory][.codeset][@modifier], where language is an ISO 639 language code, territory is an ISO 3166 country code, and codeset is a character set or encoding identifier like ISO-8859-1 or UTF-8. For a list of all supported locales, try "locale -a", cf. locale(1). But I can not find anywhere a specification for it. On Ubuntu I notice this strange thing: $ grep en_US /usr/share/i18n/SUPPORTED en_US.UTF-8 UTF-8 en_US ISO-8859-1 en_US.ISO-8859-15 ISO-8859-15 $ locale -a | grep en_US en_US en_US.iso885915 en_US.utf8
CC: (none) => pterjan
@ JA Magallón Is the problem still there in current cauldron or in Mageia 1?
CC: (none) => marja11
No, this does not happen anymore.
(In reply to comment #8) > No, this does not happen anymore. ok thanks for the reply closing.
Status: NEW => RESOLVEDVersion: Cauldron => 1Resolution: (none) => FIXED