GNU bug report logs - #75523
Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native applications on foreign systems to load

Previous Next

Full log

View this message in rfc822 format

From: Simon Streit <simon <at> netpanic.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 75523 <at> debbugs.gnu.org
Subject: bug#75523: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native applications on foreign systems to load
Date: Sat, 25 Jan 2025 20:32:09 +0100

Hello Maxim,

sorry about the delay.

Maxim Cournoyer <maxim.cournoyer <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.