Locales-all no longer working since core22?

I use the legacy snapcraft-desktop-helpers as I do custom build of Qt framework. Since some time, apparently updating to core22, I noticed I see error messages like


** (telegram-desktop:3286): WARNING **: 16:32:30.856: Can't set the global locale to the user's preferred locale.
   locale::facet::_S_create_c_locale name not valid
   The environment variable LANG may be wrong.


(telegram-desktop:3286): Gtk-WARNING **: 16:32:30.951: Locale not supported by C library.
        Using the fallback 'C' locale.

If I do locale, I see the following error messages:

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

My first guess was that glibc no longer reads LOCPATH for some reason as locale -a is not aware of any locale:

locale: Cannot set LC_CTYPE to default locale: No such file or directory
warning: The LOCPATH variable is set to "/snap/telegram-desktop/4534/usr/lib/locale"
C
C.utf8
POSIX

So I tried to use layout $SNAP/usr/lib/locale to /usr/lib/locale. As a result, locale -a lists all the locales, but the app itself and locale continue to throw error messages. Between various attempts to make locales work, I tried to unset LOCPATH while not using layout and I noticed a difference in error messages:

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

So, it also errors about LC_MESSAGES now. Does this means something is wrong with the locale files that setting LC_CTYPE doesn’t work, what consequently makes entire setlocale(LC_ALL, "") fail?

I also noticed that core22 has C.utf8 locale file in /usr/lib/locale. I tried to set C.UTF-8 locale and there’s no error, so this locale file works. When I tried to use C.UTF-8 locale while using layout, it errored out with the 3 errors (LC_CTYPE, LC_MESSAGES, LC_ALL), then I checked and found that $SNAP/usr/lib/locale has no C.utf8 file. I also can’t find any package providing the file on packages.ubuntu.com.

I really need help on this as I’m out of ideas how to make locales work now, maybe there’s a glibc bug?

You should be able to build qt as a part without the legacy helpers. I would recommend using the gnome extension in snapcraft with your qt part, this way you get a well tested desktop-launch script for core22. There is a neon extension in the works for snapcraft, which is currently being reviewed.

The gnome extension seems like too much given that gtk is used by Qt only to query desktop settings and by webkit2gtk that I guess will pull gtk anyway, so there will be 2 gtk copies, one in the extension and one in the snap?

It won’t need to pull in gtk, the extension adds the gnome-42-2204-sdk as a build-snap. So you won’t need to include the gtk devel build packages.

I mean, does it contain webkit2gtk? If not, I would need to pull webkit2gtk anyway and it will pull core22’s gtk as a dependency.

It would be really nice it there was a dummy extension: no toolkit inside, just a bare minimum for the launch script without toolkit-specific details (like glib-only in snapcraft-desktop-helpers).

It does contain webkitgtk2

Is there really no way to make it find locale without the extension? :frowning:

I’m sure that could be resolved, I’m just saying there have been lots of fixes in the desktop-launch script provided by the gnome extension. And we know it works properly in that scenario. It should also be easier to maintain and reduce the size of the snap as well.

I see a problem with using the gnome extension: it overrides LIBGL_DRIVERS_PATH. There were a lot of reports that 22.04’s mesa prevents application’s image viewer window from showing (it just doesn’t appears or appears fully transparently, don’t remember exactly), so the package is using latest mesa from kisak/kisak-mesa PPA. As the desktop-launch script overrides these variables, the bug is likely to be restored (as it seems GNOME runtime provides 22.04’s mesa).

Web functionality has also stopped working, with the following message:

** (telegram-desktop:4161): ERROR **: 20:04:59.016: Unable to spawn a new child process: Failed to spawn child process ?/usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/WebKitNetworkProcess? (No such file or directory)

The thing is gnome extension’s desktop-launch script seem to be identical to snapcraft-desktop-helpers one regarding the locales, that’s why thing go mysterious for me

Please try adding this layout

layout:
    /usr/lib/$SNAPCRAFT_ARCH_TRIPLET/webkit2gtk-4.1:
        bind: $SNAP/gnome-platform/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/webkit2gtk-4.1

I’ll try, although due to https://bugs.launchpad.net/snapd/+bug/2002835 I can’t build on local machine and build on GitHub Actions takes 3 hours.

Yeah, this helped, the only remaining problem is old mesa

It’ll get mesa 22.2.5 soon, once it finishes migrating out of the proposed pocket for jammy. We’ll need to get gnome-42-2204 rebuilt and published, but i’ll get that done pretty quickly.

Couldn’t desktop-exports script be changed to append_dir to LIBGL_DRIVERS_PATH rather than overwriting it? It does like that with LIBVA_DRIVERS_PATH and __EGL_VENDOR_LIBRARY_DIRS

The problem is solved by staging libc-bin package