unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
* bug#75523: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native applications on foreign systems to load
@ 2025-01-12 18:32 Simon Streit
  2025-01-15  5:37 ` Maxim Cournoyer
  0 siblings, 1 reply; 2+ messages in thread
From: Simon Streit @ 2025-01-12 18:32 UTC (permalink / raw)
  To: 75523; +Cc: Maxim Cournoyer

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




^ permalink raw reply	[flat|nested] 2+ messages in thread

* bug#75523: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native applications on foreign systems to load
  2025-01-12 18:32 bug#75523: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native applications on foreign systems to load Simon Streit
@ 2025-01-15  5:37 ` Maxim Cournoyer
  0 siblings, 0 replies; 2+ messages in thread
From: Maxim Cournoyer @ 2025-01-15  5:37 UTC (permalink / raw)
  To: Simon Streit; +Cc: 75523

Hi Simon,

Simon Streit <simon@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




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-01-15  5:38 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-12 18:32 bug#75523: Sourcing GDK_PIXBUF_MODULE_FILE prevents icons of native applications on foreign systems to load Simon Streit
2025-01-15  5:37 ` Maxim Cournoyer

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).