Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native applications on foreign systems to load

  • Done
  • quality assurance status badge
Details
3 participants
  • ???
  • Maxim Cournoyer
  • Simon Streit
Owner
unassigned
Submitted by
Simon Streit
Severity
normal
S
S
Simon Streit wrote on 12 Jan 19:32 +0100
(address . bug-guix@gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
yguh663q3wv.fsf@netpanic.org
Hello,

if Guix is installed on a foreign system (Debian Bookworm), sourcing
GDK_PIXBUF_MODULE_FILE will prevent native applications on foreign
systems from loading their icons:

Toggle snippet (9 lines)
user@host:~$ /usr/bin/nautilus
** Message: 18:24:36.710: Connecting to org.freedesktop.Tracker3.Miner.Files

(org.gnome.Nautilus:134621): Gtk-WARNING **: 18:24:36.915: Failed to load icon /org/gnome/nautilus/icons/scalable/actions/funnel-symbolic.svg: Unable to load image-loading module: /gnu/store/cip1g5lwcvrmwp57y0fxyzp6jamn4xjk-librsvg-2.58.5/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/cip1g5lwcvrmwp57y0fxyzp6jamn4xjk-librsvg-2.58.5/lib/librsvg-2.so.2)

...

I have a user profile with the following in .bashrc:

Toggle snippet (13 lines)
export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
export GUIX_BUILD_OPTIONS="--cores=$(echo $(lscpu | grep ^Core) | awk '{print $4}')"
export GUIX_PROFILE="${HOME}/.config/guix/current"
. "${GUIX_PROFILE}/etc/profile"

eval $(guix package --search-paths=prefix)

# Manually sourcing it to be independent of gdk-pixbuf and/or librsvg
# being installed in the profile:
export GDK_PIXBUF_MODULE_FILE=".guix-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache"


If GDK_PIXBUF_MODULE_FILE is explicitly sourced, then Guix based
applications show their icons. If not, no icons are displayed and the
host has the ability restored to show icons.

This leaves Guix on foreign systems currently at: Either the foreign
system knows how to load icons, or Guix, if sourcing
GDK_PIXBUF_MODULE_FILE. Not simultaneously.

This behaviour is somewhat similar in Guix Systems too and has had a
similar discussion before: [1]. There it was proposed to wrap the
applications to provide GDK_PIXBUF_MODULE_FILE directly.


But, there was a time where this was not a problem that lasted up to at
least commit 6da03fcc459f4475553f394354ef37c628f39f97. I tried to
bisect my way into the past and find the offending change.
Unfortunately, I had to give up as trying to pull into commits around
August 2024 is close to impossible now. Many commits failed on me and I
never got anywhere close to where that change happened.


Therefor I am opening this bug report hoping that someone will help me
figure out what is going on here?

I do remember reading a thread last year, where Maxim – CCed – discussed
a problem related to librsvg and gdk-pixbuf. I only found an upstream
issue at [2]. But not the discussion on the lists here.




Kind regards

--
Simon
M
M
Maxim Cournoyer wrote on 15 Jan 06:37 +0100
(name . Simon Streit)(address . simon@netpanic.org)(address . bug-guix@gnu.org)
87r054d4e6.fsf@gmail.com
Hi Simon,

Simon Streit <simon@netpanic.org> writes:

Toggle quote (6 lines)
> Hello,
>
> if Guix is installed on a foreign system (Debian Bookworm), sourcing
> GDK_PIXBUF_MODULE_FILE will prevent native applications on foreign
> systems from loading their icons:

[...]

Toggle quote (8 lines)
> If GDK_PIXBUF_MODULE_FILE is explicitly sourced, then Guix based
> applications show their icons. If not, no icons are displayed and the
> host has the ability restored to show icons.
>
> This leaves Guix on foreign systems currently at: Either the foreign
> system knows how to load icons, or Guix, if sourcing
> GDK_PIXBUF_MODULE_FILE. Not simultaneously.

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.

Toggle quote (4 lines)
> This behaviour is somewhat similar in Guix Systems too and has had a
> similar discussion before: [1]. There it was proposed to wrap the
> applications to provide GDK_PIXBUF_MODULE_FILE directly.

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.

If we had GDK_PIXBUF_MODULE_FILES, we could opt to wrap the binaries with
it in a 'prefix' fashion, leaving open the door for the user to augment
its value (say by installing some loaders in their user profile).

Toggle quote (12 lines)
>
> But, there was a time where this was not a problem that lasted up to at
> least commit 6da03fcc459f4475553f394354ef37c628f39f97. I tried to
> bisect my way into the past and find the offending change.
> Unfortunately, I had to give up as trying to pull into commits around
> August 2024 is close to impossible now. Many commits failed on me and I
> never got anywhere close to where that change happened.
>
>
> Therefor I am opening this bug report hoping that someone will help me
> figure out what is going on here?

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.

If you get around to do that, please post the link so we can follow the
conversation there, and perhaps participate.

--
Thanks,
Maxim
S
S
Simon Streit wrote on 25 Jan 20:32 +0100
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . bug-guix@gnu.org)
yguplkabsg6.fsf@netpanic.org
Hello Maxim,

sorry about the delay.

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (7 lines)
> 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:

Toggle snippet (3 lines)
(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)

Quoting gdk-pixbuf-query-loaders(1):

Toggle quote (6 lines)
> 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.

Toggle quote (6 lines)
> 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.

Toggle quote (9 lines)
> 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.




Kind regards

--
Simon
S
S
Simon Streit wrote on 25 Jan 20:34 +0100
control message for bug #75523
(address . control@debbugs.gnu.org)
yguo6zubsbi.fsf@netpanic.org
close 75523
quit
?
?
??? wrote on 26 Jan 04:53 +0100
Re: bug#75523: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native applications on foreign systems to load
(name . Simon Streit)(address . simon@netpanic.org)
87ed0q1b9x.fsf@envs.net
Simon Streit <simon@netpanic.org> writes:
Toggle quote (14 lines)
>> 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.
>

Hello, just add a note that this issue would be addressed in
GUIX_GDK_PIXBUF_MODULE_FILES in guix to avoid influence foreign
programs.

Thanks.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 75523@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 75523
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch