Open twnlink opened 4 years ago
Hey! Are you having this problem, or have you fixed it? If you haven't, could you cat /etc/locale.gen
? As well as eselect locale list
. Cheers!
Hey! Are you having this problem, or have you fixed it? If you haven't, could you
cat /etc/locale.gen
? As well aseselect locale list
. Cheers! @Bobbbay
iirc, swapping it out to en_US.UTF-8 UTF-8
in /etc/locale.gen and doing sudo locale-gen
fixed the issue on my machine.
- I assume you are no longer having this problem?
- What did the original locales file contain?
- If you are no longer having this problem, we could just tell bedrock to correctly initialize the locales before completing install. @Bobbbay
C.UTF8 UTF-8
as the one Bedrock made, I just swapped it out to en_US.UTF-8 UTF-8
Ah, now I understand - no problem, of course! You most probably did as you said the following:
C.UTF8 UTF-8
with en_US.UTF-8 UTF-8
locale-gen
Now, the more politically correct way would be:
/etc/locale.gen
to the following:
en_US ISO-8859-1
en_US.UTF-8 UTF-8
C.UTF-8 UTF-8
locale-gen
# eselect locale list
Available targets for the LANG variable: [1] C [2] POSIX [3] en_US [4] en_US.iso88591 [5] en_US.utf8 [ ] (free form)
eselect locale set 5
env-update && source /etc/profile
Or at least, that's the [Handbook](https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Configure_locales) way of doing things. I have little experience with the Bedrock codebase - hence, I'll just leave the instructions up here, since I use Gentoo 😉
Cheers!
Actually no I lied, Bedrock codebase is freaking awesome, found what I need in 10 seconds. Created a PR #205
The underlying issue appeared to be a bug busybox
. When setting up locales for Gentoo (but not other distros due to the quirkiness of the busybox
bug), brl fetch
incorrectly splits en_US.UTF-8 UTF-8
into two separate fields, then (correctly) detects that each is an invalid localegen value and backs the change out. Here's a snippet from brl fetch gentoo
output:
[11/14 ( 78%)] Setting locale
* Generating 1 locales (this might take a while) with 24 jobs
* Bad entry in locale.gen: 'en_US.UTF-8 '; skipping
* (1/1) Generating C.UTF-8 ... [ ok ]
* Generation complete
* Adding locales to archive ... [ ok ]
* Generating 2 locales (this might take a while) with 24 jobs
* (2/2) Generating UTF-8 ...
[error] character map file `en_US.UTF-8' not found: No such file or directory
[error] cannot open locale definition file `UTF-8': No such file or directory [ !! ]
* (1/2) Generating C.UTF-8 ... [ ok ]
* Generation complete
* Adding locales to archive ...
incomplete set of locale files in "//usr/lib64/locale/UTF-8" [ !! ]
* Could not set UTF-8 locale, skipping.
I believe I've worked around the issue in 0.7.19beta1 by implementing the splitting differently. If you have the time, please give it a try and let me know if it properly resolves things for you.
This is more of an aesthetic issue than anything, but every time emerge is used this gets printed:
setlocale: unsupported locale setting
A fix for this is to tamper with your locale, but having it work out of the box would be better.