On 31 October 2014 14:20, Mateus Rodrigues Costa wrote:

2014-10-31 12:14 GMT-02:00 Paul Gideon Dann :

...

Is there some additional configuration I need beyond /etc/locale.conf now? I've checked locale.gen and rerun locale-gen without any effect. I've also tried rerunning mkinitpio for good measure.

Any ideas?

Paul

localectl list-locales localectl set-locale en_GB.utf8

Hmm well that helped a little: # sudo localectl list-locales en_GB en_GB.iso88591 en_GB.utf8 # sudo localectl set-locale en_GB.utf8 Failed to issue method call: Invalid Locale data. Could this be a corrupted file? (Feasible, as we did have a power cut.) I tried reinstalling glibc, but that didn't help. Paul

On 31 October 2014 15:42, Mateus Rodrigues Costa wrote:

2014-10-31 13:34 GMT-02:00 Paul Gideon Dann :

...

# sudo localectl set-locale en_GB.utf8 Failed to issue method call: Invalid Locale data.

Could this be a corrupted file? (Feasible, as we did have a power cut.) I tried reinstalling glibc, but that didn't help.

Paul

localectl set-locale LANG=en_GB.utf8

# sudo localectl set-locale LANG=en_GB.utf8 # echo $LANG en_US.UTF-8 # sudo localectl System Locale: LANG=en-GB.utf8 VC Keymap: dvorak X11 Layout: n/a I tried a new login session too in a fresh VT, and the LANG environment variable is still en_US.UTF-8. Paul

Am 03.11.2014 10:21, schrieb Paul Gideon Dann:

On 31 October 2014 15:42, Mateus Rodrigues Costa wrote:

...

2014-10-31 13:34 GMT-02:00 Paul Gideon Dann :

...

# sudo localectl set-locale en_GB.utf8 Failed to issue method call: Invalid Locale data.

Could this be a corrupted file? (Feasible, as we did have a power cut.) I tried reinstalling glibc, but that didn't help.

Paul

localectl set-locale LANG=en_GB.utf8

# sudo localectl set-locale LANG=en_GB.utf8 # echo $LANG en_US.UTF-8 # sudo localectl System Locale: LANG=en-GB.utf8 VC Keymap: dvorak X11 Layout: n/a

I tried a new login session too in a fresh VT, and the LANG environment variable is still en_US.UTF-8.

Paul

You have to run # locale-gen

On 3 November 2014 09:45, Jürgen Werner wrote:

You have to run

# locale-gen

Jürgen, note my original post:

I've checked locale.gen and rerun locale-gen without any effect. I've also tried rerunning mkinitpio for good measure.

Paul

Am 03.11.2014 11:03, schrieb Paul Gideon Dann:

On 3 November 2014 09:45, Jürgen Werner wrote:

...

You have to run

# locale-gen

Jürgen, note my original post:

...

I've checked locale.gen and rerun locale-gen without any effect. I've also tried rerunning mkinitpio for good measure.

Paul

Well, I meant after running sudo localectl set-locale LANG=en_GB.utf8 You didn't list that, so I thought you forgot it.

Em Mon Nov 03 2014 at 08:00:43, Paul Gideon Dann escreveu:

On 3 November 2014 09:24, Jesse Jaara wrote:

Also:

# locale -a locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_COLLATE to default locale: No such file or directory C POSIX en_GB en_GB.iso88591 en_GB.utf8

Paul

Shouldn't you also have the en_US locales available? Just in case? Also, why enable the ISO locales if you can run basically with only the UTF-8 ones?

On 3 November 2014 11:36, Mateus Rodrigues Costa wrote:

Shouldn't you also have the en_US locales available? Just in case? Also, why enable the ISO locales if you can run basically with only the UTF-8 ones?

I've tried enabling the en_US locales, and it doesn't help. I suspect the issues I'm having with console rendering is actually not directly related to the locale, as I've been able to get en_GB.UTF-8 to show up in LANG now by disabling the logic in my ZSH profile that was setting the locale because it was unset. I've no idea how it's set to en_GB.UTF-8 *after* the ZSH config runs, but that seems to be the case. I've tried disabling the ISO locale and re-running locale-gen, but that doesn't help. My best bet at this stage is that I have a corrupted file somewhere, but pacman -Qqkk doesn't show up anything obvious. I'd think it was an issue with a new package version, but as I'm the only one seeing this, I assume it must be a configuration / corruption issue with my specific system. Paul

Any chance this helps? https://wiki.archlinux.org/index.php/Locale Also, how about setting LANG=en_GB.utf8 inside /etc/locale.conf and ~/.config/locale.conf ? Now, about the UTF-8 and utf8 difference: I am not sure if there is any, but both localectl list-locales and locale -a use "utf8" in my system.

the canonical name is UTF-8 and that's the one that should be used, glibc normalizes that to lowercase and removes the dashes and underscores when it searches the archive (because of legacy iso-8859-x charsets which didn't have a clear standard how to write them down) I don't know of programs that will use ~/.config/locale.conf. Most (if not all) Linux/glibc programs use the LANG and LC_* environment variables. So to have a working locale in your environment, you have to know how unix environment variables are inherited and from where in your case. Also, always use just the LANG variable to set the locale, only use LC_CTYPE etc, if you want to override some part of the locale. Only ever use LC_ALL on the command line if you must make sure that some hierarchy of processes will use that locale (it overrides LANG and the other LC_ variables). -- damjan

On 3 November 2014 15:05, Mauro Santos wrote:

On 03-11-2014 14:03, Paul Gideon Dann wrote:

...

My best bet at this stage is that I have a corrupted file somewhere, but pacman -Qqkk doesn't show up anything obvious. I'd think it was an issue with a new package version, but as I'm the only one seeing this, I assume it must be a configuration / corruption issue with my specific system.

Paul

Did you check /etc/profile.d for any changed/added files that may be changing the locale?

-- Mauro Santos

Thanks to all for the suggestions so far. This in particular did yield something interesting: The /etc/profile.d/locale.sh file (from the "filesystem" package) changed recently. Basically, it looks like the logic has altered a little: whereas previously it would unset LANG and source /etc/locale.conf, it now only sets LANG if it's not already set. That explains the weird interaction with my zshenv: it was supposed to fall back to en_US in zshenv, but in fact was always setting en_US, which was later forcibly reset to en_GB by /etc/profile.d/locale.sh. After the filesystem update, /etc/profile.d/locale.sh was leaving LANG as it was. I've fixed this in my .zshenv for now. So that explains why my locale wasn't being set correctly. However, it doesn't explain why I'm seeing broken rendering of special characters in the terminal (mainly lines and other terminal graphics). This looks like it might not be directly related? Paul

On 03-11-2014 15:26, Paul Gideon Dann wrote:

So that explains why my locale wasn't being set correctly. However, it doesn't explain why I'm seeing broken rendering of special characters in the terminal (mainly lines and other terminal graphics). This looks like it might not be directly related?

Paul

If it is terminal emulator under X I would check the font configuration, if you mean VT then /etc/vconsole.conf is the place to look at. On the other hand, I would check what was updated around the time things started looking weird, maybe you caught a bug, or font handling changed. I would also check other terminal emulators, preferably with different dependencies to try a rule out any bug in the dependencies. -- Mauro Santos

Em Mon Nov 03 2014 at 14:08:11, Paul Gideon Dann escreveu:

I'd forgotten about this, although I mentioned it a few posts back:

# locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en-GB.utf8 LC_CTYPE="en-GB.utf8" LC_NUMERIC="en-GB.utf8" LC_TIME="en-GB.utf8" LC_COLLATE="en-GB.utf8" LC_MONETARY="en-GB.utf8" LC_MESSAGES="en-GB.utf8" LC_PAPER="en-GB.utf8" LC_NAME="en-GB.utf8" LC_ADDRESS="en-GB.utf8" LC_TELEPHONE="en-GB.utf8" LC_MEASUREMENT="en-GB.utf8" LC_IDENTIFICATION="en-GB.utf8" LC_ALL=

Looks like there are still locale issues...

Paul

Looks like it wants some unavailable locales. Is the en_US.utf8 locale available? Also shouldn't it be "en_GB" instead of "en-GB"?

On 03-11-2014 16:07, Paul Gideon Dann wrote:

I'd forgotten about this, although I mentioned it a few posts back:

# locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en-GB.utf8 LC_CTYPE="en-GB.utf8" LC_NUMERIC="en-GB.utf8" LC_TIME="en-GB.utf8" LC_COLLATE="en-GB.utf8" LC_MONETARY="en-GB.utf8" LC_MESSAGES="en-GB.utf8" LC_PAPER="en-GB.utf8" LC_NAME="en-GB.utf8" LC_ADDRESS="en-GB.utf8" LC_TELEPHONE="en-GB.utf8" LC_MEASUREMENT="en-GB.utf8" LC_IDENTIFICATION="en-GB.utf8" LC_ALL=

Looks like there are still locale issues...

Paul

This is what I have/get: # locale LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=pt_PT.UTF-8 LC_COLLATE=pt_PT.UTF-8 LC_MONETARY=pt_PT.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=pt_PT.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL= I do have all of these explicitly set in /etc/locale.conf, exactly like shown on the output of locale (except LC_ALL). As a last resort shot in the dark I would try changing en-GB.utf8 to whatever 'locale -a' outputs. The output of 'locale -a' should include the locale you want, if it doesn't then you have to double check /etc/locale.gen and rerun locale-gen. Another shot in the dark, try with a new user and set the shell to bash, just to add another data point and dismiss anything weird going on with the shell you are using. No more ideas here. This is most probably caused by something you might have changed, the trouble is always finding what. -- Mauro Santos