Hello Maxim, sorry about the delay.
Maxim Cournoyer <maxim.courno...@gmail.com> writes: > That's annoying, but kind of inherit to the design of that single > entry GDK_PIXBUF_MODULE_FILE. If we had a GDK_PIXBUF_MODULE_FILES > instead, allowing multiple entries, we could, in the guix-install.sh > script arrange so that the that environment variable would always have > a default value to that of the system, like we currently do for a > bunch of XDG_* variable already. With a hint from outside it finally became obvious what the problem is: Debian Bookworm's glibc is at 2.35 while Guix updated it to 2.39 last summer. Ever since, the foreign system may silently fail to load the icons. Which explains why I was trying to bisect my way to August 2024. I only observe this on my stable Debian systems. I set up a Debian Testing and: The images are back again. Including after sourcing GDK_PIXBUF_MODULE_FILE. Trixie's glibc is currently at 2.40. The error is usually silent. Only after adding librsvg to a profile and sourcing GDK_PIXBUF_MODULE_FILE will give you the following: --8<---------------cut here---------------start------------->8--- (nm-applet:2793559): nm-applet-WARNING **: 23:07:43.649: failed to load icon "nm-device-wired": Failed to load /usr/share/icons/Papirus/16x16/panel/nm-device-wired.svg: Unable to load image-loading module: /gnu/store/4sh8wcw94d4x7gpp82a4ryk8hd9zr0s9-librsvg-2.56.4/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by /gnu/store/4sh8wcw94d4x7gpp82a4ryk8hd9zr0s9-librsvg-2.56.4/lib/librsvg-2.so.2) --8<---------------cut here---------------end--------------->8--- Quoting gdk-pixbuf-query-loaders(1): > Normally, the output of gdk-pixbuf-query-loaders is written to $lib- > dir/gdk-pixbuf-2.0/2.10.0/loaders.cache, where gdk-pixbuf looks for it > by default. If it is written to some other location, the environment > variable GDK_PIXBUF_MODULE_FILE can be set to point gdk-pixbuf at the > file. Which means, gdk-pixbuf is now looking into a completely different environment that may not properly know how to load, which can be the case if there is a mismatch with versions of glibc. > That's not a bad way, though again because of the design of > GDK_PIXBUF_MODULE_FILE, it would make it impossible for the user to > add extra loaders to their profile. This pixbuf module thing is akin > to plugins; it's ideally meant to be extendable by the user > post-installation. I took that advice and wrapped rofi-wayland with GDK_PIXBUF_MODULE_FILE. It helped. Rofi had its icons back. As it is an application launcher, it will pass on the variables from its own environment to the application it is launching. Which means: The icons in the native application are missing again. There has been a discussion regarding flatpak leaking its environment into the sandbox [1]. We are not discussing a sand-boxed environment, though it does look familiar. > I'm sorry, I do not know why this has recently become a problem for you. > This GDK_PIXBUF_MODULE_FILE thing has been in Guix for at least 2 years. > > I think the best course of action would be to open an issue upstream > against gdk-pixbuf, detailing our use case and how the current single > entry GDK_PIXBUF_MODULE_FILE variable is a problematic, and throw the > idea of having an actual search path of modules, such as > GDK_PIXBUF_MODULE_FILES. You're right. I should place a note upstream. For my part this issue is now resolved. Closing. [1] https://issues.guix.gnu.org/55072 Kind regards -- Simon
