I've noticed this because sys-libs/libcxx tests were failing in devbox containers. Long story short, if you leave /etc/locale.gen empty, and run locale-gen, you get: # locale-gen * No locales to generate found, keeping archive but ensuring C.UTF-8 is present * Generating 1 locales (this might take a while) with 32 jobs * (1/1) Skipping C.UTF-8 * Generation complete * No locales are to be added to the archive. * Keeping old locales: ... But the "old" locales can apparently be outdated/broken with new glibc, leading to problems. Perhaps we should default to regenerating all locales then?
I _think_ Kerin and I may have discussed this in the context of his locale-gen rewrite but I'm not completely sure.
Not this particular aspect, though I found myself pondering the utility of the -u option only recently. Irrespective of that option, the utility could be made to act as if usr/share/i18n/SUPPORTED is the input in the case that /etc/locale.gen produces an empty list after validation - perhaps with a courtesy diagnostic. That seems like a rather sensible suggestion to me.
This is now supported by my work-in-progress. In the absence of the -c and -A options, the routine that reads and validates the configuration file will be passed a list consisting of both ${EROOT}/etc/locale.gen and ${DESTDIR}/usr/share/i18n/SUPPORTED, in that order. Should an attempt to open a file raise an error, the error shall be disregarded unless either of the following two conditions apply. a) the error was something other than ENOENT b) the pathname just tried was the last one in the list As such, it will even allow for locale.gen not to exist at all, while maintaining robust error handling. I'm hoping to get all this properly tested and on a course for submission as soon as is reasonably possible. Work has been trying of late.
*** Bug 945872 has been marked as a duplicate of this bug. ***
Not sure if it is related or not. But after the recent update, when I try to change my KDE localization (via GUI), I get: ``` * Generating 4 locales (this might take a while) with 16 jobs * (2/4) Generating en_DE.UTF-8 ... [error] cannot open locale definition file `en_DE': No such file or directory [ !! ] * (4/4) Generating C.UTF-8 ... [ ok ] * (1/4) Generating de_DE.UTF-8 ... [ ok ] * (3/4) Generating en_US.UTF-8 ... [ ok ] * Generation complete * Adding locales to archive ... [ !! ] * These locales have been duplicated in your config:\nde_DE.UTF-8 UTF-8 de_DE.UTF-8 UTF-8 * Some might be filtered, but you must fix it. incomplete set of locale files in "//usr/lib/locale/en_DE.utf8" ``` AFAIK it used to work fine before. And FTR: Yes, I am using a english/german mix, which affects (I think) LC_CTYPE and LC_COLLATE. If this is unrelated, please tell me
Bernd, I presume that you have "en_DE.UTF-8 UTF-8" present in locale.gen? The problem is that there is no such locale as "en_DE". Try running the following command. find /usr/share/i18n/locales -type f -exec grep -lxF LC_IDENTIFICATION {} + | sed -e 's/^.*\///' | sort It will print a complete list of locales, without character maps. Note that "en_DE" is nowhere to be found among them. Consequently, the current version of locale-gen raises a rather incoherent warning. For cases of misconfiguration, my impending rewrite of locale-gen will display a useful error message before refusing to proceed. For example: $ locale-gen locale-gen: Invalid locale at /etc/locale.gen[3]: "en_DE.UTF-8 UTF-8" $
Just to add also that the rewrite will not complain about duplicate entries in the config file. Instead, duplicates shall be silently discarded and it shall only concern itself with whether the entries are legitimate.
I see that Plasma has a KCM (KDE Configuration Module) that is able to invoke locale-gen for some distributions. If the issue described by comment #5 was caused by an invalid /etc/locale.gen entry, it may be disregarded. My fear now is that it may instead have been caused by the KCM passing an invalid argument to locale-gen. Bernd, can you please determine whether it is the latter case that applies to you? If it does, please file a separate bug, for it would definitely need to be investigated.
Indeed I had in my /etc/locale.gen # generated by KDE Plasma Region & Language KCM en_DE.UTF-8 UTF-8 de_DE.UTF-8 UTF-8 en_US.UTF-8 UTF-8 de_DE.UTF-8 UTF-8 I removed it, and tried to change it via KDE kcm again. It was added again, and got the same error.
