fedora-cloud / docker-brew-fedora

MIT License
176 stars 46 forks source link

[Fedora 22] Use utf-8 locale #14

Closed ghost closed 4 years ago

ghost commented 9 years ago

Hi,

when I use the following Dockerfile with Fedora 21, everything works fine and the output of the date command is perfectly using the previous set locale:

from fedora:21

run echo "LANG=de_DE.UTF-8" > /etc/locale.conf
run echo "LC_MESSAGES=C" >> /etc/locale.conf

env LANG de_DE.UTF-8

run date

Outputs:

Step 4 : RUN date
 ---> Running in 07e5b6c9beab
Fr 29. Mai 20:44:23 UTC 2015

Using the same with Fedora 22 won't set the locale to de_DE.UTF-8 correctly - the output is:

Step 4 : RUN date
 ---> Running in aad73e404dfe
Fri May 29 20:50:06 UTC 2015

When running RUN dnf --version an error message occurs:

Failed to set locale, defaulting to C

When using some git commands another error messages are like:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LANGUAGE = (unset),
    LC_ALL = (unset),
    LANG = "de_DE.UTF-8"
    are supported and installed on your system.

In the offical Fedora 22 Administrator Guide I found the localectl command, which I used in my Dockerfile:

run localectl set-locale LANG=de_DE.utf8

The error message is then:

Step 4 : RUN localectl set-locale LANG=de_DE.utf8
 ---> Running in 9f2585861602
Failed to create bus connection: No such file or directory

What is the right way to use an utf-8 locale?

The Docker image I used is:

22: Pulling from fedora
48ecf305d2cf: Already exists 
ded7cd95e059: Already exists 
Digest: sha256:cc47966101aeba8015c933f9c3854811a27363f93fa4e0e52e6c55181c56c66c
Status: Image is up to date for fedora:22

Thanks many in advance,

Stefan

theherk commented 9 years ago

I believe you either have to get systemd running which is another topic to use localectl, or export LANG in each shell.

ncoghlan commented 8 years ago

Defaulting to the C locale is now even more problematic in Fedora 23, as Python 3.4 is the default system Python, which believes the OS when it says that the operating system interfaces should be interpreted as ASCII rather than as UTF-8.

This leads to error messages like the following:

# pyp2rpm --help
Traceback (most recent call last):
  File "/usr/bin/pyp2rpm", line 9, in <module>
    load_entry_point('pyp2rpm==2.0.0', 'console_scripts', 'pyp2rpm')()
  File "/usr/lib/python3.4/site-packages/click/core.py", line 700, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python3.4/site-packages/click/core.py", line 655, in main
    raise RuntimeError('Click will abort further execution '
RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment. Either switch to Python 2 or consult http://click.pocoo.org/python3/ for mitigation steps.

(This isn't a click bug, it's a valid design decision. Feeding the Python 3 interpreter incorrect locale settings as the cloud images currently do means Python decodes some information incorrectly at start-up, which applications and application support libraries like click can't readily detect or recover from)

ncoghlan commented 8 years ago

Based on a technique used in sti-base, I came up with the following workaround for https://github.com/ncoghlan/fedbuildenv/blob/09a18d91e7af64a45394669bac2595a4b628960d/Dockerfile#L26:

# Set a useful default locale
RUN echo "export LANG=en_US.utf-8" > /opt/export_LANG.sh
ENV BASH_ENV=/opt/export_LANG.sh \
    ENV=/opt/export_LANG.sh \
    PROMPT_COMMAND="source /opt/export_LANG.sh"

BASH_ENV covers non-interactive bash sessions, ENV covers sh sessions, and PROMPT_COMMAND covers interactive bash sessions.

jberkus commented 7 years ago

This appears to still be an issue in Fedora:25

azam10x commented 7 years ago

@jberkus, Hi, is there any solving of this ? My locale.conf file consists of these lines:

d-a-v commented 7 years ago

would this help ? (this solved perl always complaining) (this seems to be the debians's equivalent of locale-gen)

RUN localedef -v -c -i fr_FR -f UTF-8 fr_FR.UTF-8 || true

siddharthvipul commented 4 years ago

issue related to the EOL versions. Please reopen if you notice this in newer images

chargio commented 3 years ago

This is still an issue in Fedora 34 and Fedora 35, when deploying to a container in OPenShift 4.7. Wouldn't it be easier to set up a sensible default for the images? en_US.UTF-8 would do

cverna commented 3 years ago

I just checked an the default locale in F34 and F35 is C.UTF-8 IIRC we use this one to keep the image small and not pull extra dependencies to install different language pack

chargio commented 3 years ago

Wouldn't it be possible to define sensible environment variables that reflect so?. Images are not used using documentation, and guessing the default locale is hard.

By default, I get an error message, even if the fix is as simple as defining a LOCALE ENV.

cverna commented 3 years ago

We do have the LANG environment variable

 [cverna@localhost]  $ podman run -it --rm docker.io/library/fedora:34
[root@d7fb0aa518f8 /]# env | grep LANG
LANG=C.UTF-8
[root@d7fb0aa518f8 /]# 

but it seems to be set by bash since running env directly does not return it

 [cverna@localhost]  $ podman run -it --rm docker.io/library/fedora:34 env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM=xterm
container=podman
DISTTAG=f34container
FGC=f34
FBR=f34
HOME=/root
HOSTNAME=b28f0cff3c16

I think we can probably set that variable when we build the image so that would be available without bash