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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75523 in the body.
You can then email your comments to 75523 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: bug-guix <at> gnu.org
Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native
 applications on foreign systems to load
Date: Sun, 12 Jan 2025 19:32:16 +0100

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:

--8<---------------cut here---------------start------------->8---

user <at> 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)

...
--8<---------------cut here---------------end--------------->8---

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

--8<---------------cut here---------------start------------->8---
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"
--8<---------------cut here---------------end--------------->8---


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.


[1] https://issues.guix.gnu.org/63427
[2] https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/933/diffs?commit_id=2dba33bc1b752e2e6fbed3c78f1cec6a74dea201
[3] https://issues.guix.gnu.org/60434


Kind regards

-- 
Simon

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Simon Streit <simon <at> netpanic.org>
Cc: bug-guix <at> gnu.org
Subject: Re: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native
 applications on foreign systems to load
Date: Wed, 15 Jan 2025 14:37:05 +0900

Hi Simon,

Simon Streit <simon <at> netpanic.org> writes:

> 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:

[...]

> 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.

> 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).

>
> 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

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Simon Streit <simon <at> netpanic.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: bug-guix <at> gnu.org
Subject: Re: 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

Message #16 received at 75523 <at> debbugs.gnu.org (full text, mbox):

From: 宋文武 <iyzsong <at> envs.net>
To: Simon Streit <simon <at> netpanic.org>
Cc: 75523 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#75523: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of
 native applications on foreign systems to load
Date: Sun, 26 Jan 2025 11:53:14 +0800

Simon Streit <simon <at> netpanic.org> writes:
>> 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
https://issues.guix.gnu.org/75795 later.  By using
GUIX_GDK_PIXBUF_MODULE_FILES in guix to avoid influence foreign
programs.

Thanks.

Previous Next

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