GTK pixbuf errors

Re: GTK pixbuf errors

Reply #15 – Yesterday at 16:26:17

Many thanks for your prompt replies, Artist and Dudemanguy.

I first encountered a problem a week ago, when, after doing my regular weekly 'pacman -Sy; pacman -Su', claws-mail stopped working, with various incomprehensible error messages.

So, not knowing any better, I did a full recovery from a system backup made immediately before: as expected, this fixed claws-mail (and cherrytree continued working OK). I didn't do anything further at that point.

Today, following what I thought was the correct procedure to ensure no further problems, I replaced gdk-pixbuf2 with the 'noglycin' version, then followed this with the 'pacman -Sy; pacman -Su'. Claws-mail is fine, but cherrytree isn't.

Looking at your posts, I'm uncertain how to proceed - should I
1. return to the standard gdk-pixbuf2 (which will presumably also pull in glycin), or
2. try the 'pacman -S --overwrite' command, or
3. do both?

Re: GTK pixbuf errors

Reply #16 – Yesterday at 19:06:54

I'm quite curious about the results of 'pacman -S --overwrite', but it's up to you to try that or not.

artist

Re: GTK pixbuf errors

Reply #17 – Yesterday at 20:25:42

I gave up on gdk-pixbuf2-noglycin. Rednotebook crashed and in my log it said something about I think it was gtk3 that expected gdk-pixbuf2 to be compiled with glycin. It was my own log that I create when i start X and I don't have it anymore.

Re: GTK pixbuf errors

Reply #18 – Today at 04:10:18

For the ones with pixbuf problems has anyone tried?

Code: [Select]

# find /usr/lib/ -type f -name '*.so' | xargs ldd
# ldd /usr/bin/*

And search for what could be depending on glycin still?

I don't recommend overwriting blobs, when I installed gdk-pixbuf2-noglycin it requested removing gdk-pixbuf2 and that should be enough, but then I did:

Code: [Select]

pacman -Rcsu glycin

And got rid on every dependency, and re-installed libical (I found that one as something I still wanted) or something else (not my case) really depending on glycin. Of course you might have way more libraries or applications depending on glycin whether such dependency is known to pacman or not. Actually I don't use the applications mentioned as not working. But so far so good on my side.

Sadly it seems any gtk is getting harder, and these current tendencies will not stop there as @Shoun2137 mentioned before. It seems source based distros are a bit better positioned to allow the users reject things (if features are made able to be disabled) at build time, but that's no go for me at least,

I remember when I was user sourceMage way before I could choose not to link against dbus and a whole lot of stuff, and it had a check one could enable to make sure no link dependencies were left in the system after any update or upgrade.

For now looking into whether link dependencies would help identify possible culprits I believe.

I'm also sad to see another tendency (GTK included) particularly on crates/rust, like pipeline-gtk and other rust apps which instead of taking advantage of shared libraries, each app builds the whole set of dependencies statically, so one ends up with a bunch of the same stuff all over the place. I checked on GTK and it seems it has replicated quite some amount of stuff on crates for static builds, and that tells me there's no bright future on apps if they start migrating to rust using cargo and crates. But I really like GTK CSD and Qt dropped the idea of by configuration supporting both CSD and SSD, and also Qt guys ever since moved to compliant open source libraries have had periods of threatening with not so open source given not seeing their expected revenue I guess. And I believe rust based Iced is to be mostly used following that tendency, and I can't remember if wayland only as well.

All this rant sort of to mention that user choice seems not to be something current tendencies care about, and GTK sadly is part of that, if not leading it.