On 31 October 2014 14:20, Mateus Rodrigues Costa <charles.costar@gmail.com> wrote:

2014-10-31 12:14 GMT-02:00 Paul Gideon Dann <pdgiddie@gmail.com>:

...

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 <charles.costar@gmail.com> wrote:

2014-10-31 13:34 GMT-02:00 Paul Gideon Dann <pdgiddie@gmail.com>:

...

# 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

On 3 November 2014 09:24, Jesse Jaara <jesse.jaara@gmail.com> wrote:

Maybe you have the lang set somewhere in your shell configfile. Have you tried with a new user?

Hmm; yeah, getting somewhere now. I haven't made any modifications to my shell config for a while, but I did find this (I use zprezto): if [[ -z "LANG" ]]; then export LANG='en_US.UTF-8' fi I've commented that out, and I get en_GB.UTF-8 now (which is odd in itself), but Tmux and Vim still render incorrectly: dividing lines are accented characters. The Linux built-in console renders some lines correctly, but some angled lines in Vim are rendered as blocks, so it doesn't seem to be a Konsole thing. When I try to invoke "man", I get: man: can't set the locale; make sure $LC_* and $LANG are correct. I don't have any LC_ variable set manually, but I didn't think I needed to... 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 I've done: # pacman -Qqkk | grep GB ...but that returns nothing. Any more ideas? Paul

Em Mon Nov 03 2014 at 08:00:43, Paul Gideon Dann <pdgiddie@gmail.com> escreveu:

On 3 November 2014 09:24, Jesse Jaara <jesse.jaara@gmail.com> 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 <charles.costar@gmail.com> 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 <registo.mailling@gmail.com> 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 <pdgiddie@gmail.com> 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 3 November 2014 16:24, Mateus Rodrigues Costa <charles.costar@gmail.com> wrote:

Em Mon Nov 03 2014 at 14:08:11, Paul Gideon Dann <pdgiddie@gmail.com> 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"?

Yes! Right on the money. I don't know when locale became more fussy, but fixing that dash to an underscore fixes the issue with locale: # locale 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= ...and after restarting my X session, the rendering issues have gone away. *Thanks* everyone involved. I guess the system had been tolerating that incorrect LANG setting in /etc/locale.conf for some time, and an update finally triggered the issue. I definitely didn't touch the file, so I guess some code somewhere decided to be less tolerant. Ultimately my own fault, of course! I'm pretty embarrassed that I hadn't checked it carefully enough! Thanks again to all! Paul

Am 03.11.2014 10:21, schrieb Paul Gideon Dann:

On 31 October 2014 15:42, Mateus Rodrigues Costa <charles.costar@gmail.com> wrote:

...

2014-10-31 13:34 GMT-02:00 Paul Gideon Dann <pdgiddie@gmail.com>:

...

# 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

Am 03.11.2014 11:03, schrieb Paul Gideon Dann:

On 3 November 2014 09:45, Jürgen Werner <jotz.csp@web.de> 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.