Kron4ek / Conty

Easy to use unprivileged Linux container packed into a single portable executable

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

locale issues warning message

bayazidbh opened this issue · comments

Hi, I noticed this warning when I ran conty:

$ conty_lite_dwarfs.sh lutris
Running Conty

Unsupported locale setting. Fix your locales

(lutris:235165): Gtk-WARNING **: 14:20:52.359: Locale not supported by C library.
        Using the fallback 'C' locale.

I checked what locale conty has, and it seems my locale en_SG.UTF-8 isn't included in locale.gen. I'm not sure how I can add locale to locale.gen outside of building my own Conty executable, and the prebuilt locales are all AUR-only with no chaotic-aur build, so I can't install them.

Currently, setting alias conty_lite_dwarfs.sh='LC_ALL=en_US.UTF-8 conty_lite_dwarfs.sh' does seem to work and gets rid of the warning, and conty_lite_dwarfs.sh env LC_ALL=ja_JP.UTF-8 winecfg seems to override the original LC_ALL and set it to Japanese correctly.

I'm not sure what should be done, I guess just listing it as a known issue would work? And most apps still behave normally with C locale anyways. Unless there is a way to take a pre-built Conty executable, extract it and then modify it to not create your own executable from scratch?

System Info

$neofetch --off
fenglengshun@tuxedo-laptop
--------------------------
OS: TUXEDO OS 2 x86_64 
Host: HP 89FE 
Kernel: 6.1.0-1009-tuxedo 
Uptime: 23 hours, 28 mins 
Packages: 2316 (dpkg), 1156 (nix-user), 46 (nix-default), 22 (flatpak) 
Shell: bash 5.1.16 
Resolution: 1920x1080 
DE: Plasma 5.27.2 
WM: KWin 
Theme: [Plasma], WhiteSur-Dark-solid [GTK2/3] 
Icons: [Plasma], WhiteSur-dark [GTK2/3] 
Terminal: konsole 
Terminal Font: MesloLGS NF 10 
CPU: AMD Ryzen 5 5625U with Radeon Graphics (12) @ 2.300GHz 
GPU: AMD ATI Barcelo 
Memory: 11710MiB / 15335MiB

Hi,

Maybe i'll add that to known issues. As you already mentioned, many apps do indeed perform normally with C locale, they use English localization in this case though, which may or may not be an issue for someone.

Unless there is a way to take a pre-built Conty executable, extract it and then modify it to not create your own executable from scratch?

Technically it is possible with the use of ./conty.sh -o, dd, unsquashfs/dwarfsextract and mksquashfs/mkdwarfs, but it's too much of a hassle, probably even more than just building a Conty executable from scrath.

However, it is possible to generate locales without (re)building Conty at all. For example:

$ ./conty.sh cp -r /usr/lib/locale ~/locale
$ echo "en_US.UTF-8 UTF-8" >> ~/locale.gen
$ echo "en_SG.UTF-8 UTF-8" >> ~/locale.gen
$ ./conty.sh --bind ~/locale /usr/lib/locale --bind ~/locale.gen /etc/locale.gen locale-gen
Running Conty

Generating locales...
  en_US.UTF-8... done
  en_SG.UTF-8... done

But then you will need to always run Conty like this in order for new locales to work and be visible inside the container:

$ ./conty.sh --bind ~/locale /usr/lib/locale someapp

Of course, you can put the locale directory in any other location, not necessarily in HOME.

It is even possible to passthrough system locales into the container, but since the glibc version between the host and the container may differ (let alone systems with musl libc), this may cause issues i think:

$ ./conty.sh --bind /usr/lib/locale /usr/lib/locale someapp

I see, thanks for the info. I'll think about building my own conty binary, but it isn't a big deal since ja_JP.UTF-8 is already present.

There is two more questions that I'm thinking about creating an issue for:

  1. Dealing with binaries that calls to an installation at /opt (tried with heroic, seems like it's trying to look for heroic inside my real /opt folder).
  2. Exporting of generated .desktop files in conty's /usr/share/applications (currently I just cp them, and then edit them manually replacing /usr/bin/ with $HOME/.local/bin/conty.sh and then move them to ~/.local/share/applications/conty/)
  3. Installing AUR packages?

Would you mind if I create a new issue for those, so that they can be tracked / closed with comments if not planned?

Dealing with binaries that calls to an installation at /opt (tried with heroic, seems like it's trying to look for heroic inside my real /opt folder).

Conty mounts host system's /opt by default, so such packages can't be used currently. But i plan to fix this in the next release.

As for 2 and 3, maybe in the future.

Okay, I'll open an issue so that it can be tracked, if you don't mind?

I don't mind.