Hi all,
So recently upon updating my system I noticed libreoffice, gimp, and inkscape all broke with similar complaints about not being able to find icons. The error message looks like this:
Gtk-WARNING **: 13:32:59.126: Could not load a pixbuf from /org/gtk/libgtk/icons/16x16/actions/go-previous.png.
This may indicate that pixbuf loaders or the mime database could not be found.
After some poking around the Arch Linux Forums, I did find a recent post (https://bbs.archlinux.org/viewtopic.php?id=302145) regarding this issue and thought I'd post it here for those who encounter a similar issue.
Essentially due to a symlink issue in a recent update to the glycin package, icons will not load and therefore loading many gnome/gtk applications will not run. Funny enough you can run them using sudo, but of course, that's not ideal.
I found that many recommended downgrading gdk-pixbuf2 back to version 2.42.12-2 solved the issue as recommended by one of the posters there. For me, I have the lib32 of that as well. So upon running:
sudo pacman -U /var/cache/pacman/pkg/gdk-pixbuf2-2.42.12-2-x86_64.pkg.tar.zst /var/cache/pacman/pkg/lib32-gdk-pixbuf2-2.42.12-2-x86_64.pkg.tar.zst
This fixed the issue. You of course have to add to your /etc/pacman.conf for now:
IgnorePkg=gdk-pixbuf2
IgnorePkg=lib32-gdk-pixbuf2
To make sure pacman doesn't upgrade to the latest broken version.
The issue on glycin's gitlab page (https://gitlab.gnome.org/GNOME/glycin/-/issues/196) has already been raised, so hopefully it gets fixed in future updates, but if anyone is having similar issues, maybe this will help.
Thanks as always to the devs for keeping this distro maintained. Peace.
I have gdk-pixbuf2 on Artix OpenRC Xlibre XFCE:
pacman -Q gdk-pixbuf2
gdk-pixbuf2 2.44.2-1
Libreoffice runs normally.
Gimp shows me error messages, but they seem unrelated to gdk-pixbuf2...
gimp
(gimp:12926): Gtk-WARNING **: 06:07:18.691: Theme parsing error: gtk.css:6:31: Expected a valid selector
set device 'Telink Trust Deskset Consumer Control' to mode: disabled
set device 'Virtual core XTEST pointer' to mode: disabled
set device 'Telink Trust Deskset Mouse' to mode: disabled
set device 'Logitech Wireless Receiver Mouse' to mode: disabled
/usr/lib/gimp/3.0/plug-ins/file-fits/file-fits: error while loading shared libraries: libcfitsio.so.10: cannot open shared object file: No such file or directory
gimp: LibGimpBase-AVERTISSEMENT: gimp: gimp_wire_read(): unexpected EOF
env: « gjs »: Aucun fichier ou dossier de ce nom
gimp: LibGimpBase-AVERTISSEMENT: gimp: gimp_wire_read(): unexpected EOF
Yes, I'm not sure why, but on my desktop I had to downgrade gdk-pixbuf2, while on my laptop I did not. I also have had issues with obs-studio on my desktop, but not on my laptop. Meanwhile my laptop had an issue with mesa and had to downgrade about a month ago, and my desktop didn't have any issues.
This likely isn't a very common bug, but nevertheless I just posted this here in case someone else had this issue.
It's all the fault of the GNOME:
https://blogs.gnome.org/sophieh/2025/06/13/making-gnomes-gdkpixbuf-image-loading-safer/
If you don't want this bullshit on your system make sure you don't have glycin installed. Once again they're not testing anything, they're just pushing shit onto other DEs...
I guess it's the same cause as my problem. They wrote about it here: https://bbs.archlinux.org/viewtopic.php?id=308456 Problem is solved by update to glycin.
Edit: No that didn't solve the problem. See my next post in this thread.
Fair assessment. Interesting read nevertheless. I'm not familiar with most image processing programming, so it was curious to look at.
Anyways, I can do without Libreoffice. I've used OnlyOffice and other office suites in the past on Linux with no problems, but I hate to say it but I can't say the same about GIMP. It's probably just because my image editing workflow has become accustomed to using it ever since I switched to Linux about a decade ago, but my experiments with other similar software including Krita, PhotoPea, and others have proven to not be as intuitive, at least for me.
But yeah, there are issues with GNOME like this one that are sadly just part of the deal with the devil I make I guess.
Another good thread to follow related to this problem. It doesn't look like the problem was solved. Most posts from Yesterday indicate the problem has yet to be resolved.
Again, I don't think everyone is encountering this issue. My laptop updated to the new gdk-pixbuf2 just fine and everything operated as expected. I had the whole "It works on my machine" moment, combined with "But not on my other machine". It was frustrating, as I cannot for the life of me understand why this is. Thankfully both my laptop and desktop are mainly used for study purposes instead of work, so it wasn't like I was sweating bullets.
Still, I'd like to see this resolved, as my "fix" is obviously isn't a fix at all, just an adhesive bandage.
Anyways, thanks to the both of you for the insightful article and other forum post that helps elucidate on the issue.
Your're right, it wasn't solved, i just thought so yesterday. For now it seems to be solved by recompiling gdk-pixbuf2 with the PKGBUILD for gdk-pixbuf2-noglycin from the aur. But I renamed it back to gdk-pixbuf2 to get updates from official repo and avoid breakage, because many packages depend on it.
I just woke up to this crap. There is already gdk-pixbuf2-noglycin in the AUR (https://aur.archlinux.org/pkgbase/gdk-pixbuf2-noglycin), but for me, compiling that would pull in 24 crappy makedepends, so I didn't feel like doing it. Any Artix developer interested in packaging that? I know the general policy on AUR, but this bubblewrap move really, really sucks.
I've added packages gdk-pixbuf2-noglycin-2.44.2-1-x86_64.pkg.tar.zst and -doc to then omniverse repo.
However, I am not familiar enough with the underlying issue to know if this is the solution or even a part of it. So, feedback is welcome for everybody's understanding.
artist
I think this is a bandaid that will most likely stop working in the future, because GNOME deliberately made
glycin codepath forced, so that even if you set all the libraries of
glycin + libjpeg-turbo + libpng + libtiff so they're all available to the gdk-pixbuf2...:
gdk-pixbuf 2.44.2
Directories
prefix : /usr
libdir : /usr/lib
datadir : /usr/share
libexecdir : /usr/lib
docdir : /usr/share/doc
Loaders
Shared modules : YES
Enabled loaders : png
glycin
gif
ani
bmp
icns
ico
pnm
qtif
tga
xbm
xpm
jpeg
tiff
Builtin loaders : all
Thumbnailer : NO
Build
Debugging : NO
Optimization : plain
GIO MIME sniffing : YES
MediaLib : NO
Introspection : YES
Documentation : YES
Manual pages : YES
Relocatable : NO
Build tests : YES
Installed tests : NO
User defined options
android : disabled
auto_features : enabled
b_pie : true
buildtype : plain
builtin_loaders : all
documentation : true
gif : enabled
glycin : enabled
gtk_doc : true
installed_tests : false
introspection : enabled
jpeg : enabled
libexecdir : lib
man : true
others : enabled
png : enabled
prefix : /usr
python.bytecompile: 1
sbindir : bin
thumbnailer : disabled
tiff : enabled
wrap_mode : nodownload
-------------------------------------------------------------------------------------------------------------
+ PKGBUILD's build() func:
local meson_options=(
-D android=disabled
-D builtin_loaders=all
-D documentation=true
-D gif=enabled
-D glycin=enabled
-D gtk_doc=true
-D installed_tests=false
-D introspection=enabled
-D jpeg=enabled
-D man=true
-D others=enabled
-D png=enabled
-D thumbnailer=disabled
-D tiff=enabled
)
-------------------------------------------------------------------------------------------------------------
[all-libs+glycin]$ librewolf
XPCOMGlueLoad error for file /usr/lib/librewolf/libmozgtk.so:
libglycin-2.so.0: cannot open shared object file: No such file or directory
Couldn't load XPCOM.
...so this breakage is 100% intentional and going by the recent nonsystemd removal, this codepath of
libjpeg-turbo + libpng + libtiff will be removed too.
In a sane project that isn't governed by a bunch of footfags that forcibly break userspace to this extent or other DEs with experimental bullshit, because they're simply nonexistant to them this would be unacceptable behaviour (half a year ago similar breakage happened in libxml2 due to exactly same bullshit reason), but due to how GNOME got the entire linux desktop hostage with deep integration into the GTK (hah, how ironic...
/usr/lib/librewolf/libmozgtk.so) as
507 applications are dependant on gdk-pixbuf2 alone. https://i.imgur.com/T2BsdmA.mp4
Oh well, just so you know if one installs "gdk-pixbuf2-noglycin", one needs to get rid of loupe and valent:
pacman -Qi glycin
...
Required By : loupe valent-git
Time to go back to feh and nitrogen (actually gui with with .desktop), and for valent there's the original kdeconnect but it brings so many unwanted deps, and besides, I'm all for CSD, and actually remove the titlebar of any app if present on i3. At any rate the I used kdeconnect mainly to exchange files, since the SMS functionality on my pc never worked, no matter if using kdeconnect itself or valent, :(, so maybe another sync tool might work