GTK 2 or related package - Debug left enabled by accident?

[fier]

I've recently updated my system's kernel, initramfs and packages (via tce-update) and noticed GTK 2 applications (like pcmanfm) no longer work. Upon inspection, I noticed that these additional packages are required, for some reason:
- libXdamage
- libdrm
- llvm19-lib
- spirv-tools
- libxshmfence
- elfutils

Some of these are rather large. Can someone look into if maybe some debug flag was left enabled on the GTK 2 build or something? A friend of mine said that could be a likely cause.

[Zhe]

just update all dep , you can exec  "update-everything"

[CNK]

This is due to the mesa update, since on x86 mesa is a dependency of GTK2 (not on x86_64 though, strangely).

An easy solution if like me you don't care about using the latest graphics acceleration (which isn't even used by the GTK2 programs I run) is to keep the old libEGL, libGLESv2, etc. extensions and delete the .md5.txt files so they won't be changed on the next update. You might even be able to make empty dummy extensions for them if they're not really used. Or edit gtk2.tcz.dep to remove libGLESv2.tcz and libEGL.tcz, but then the updater might try to revert that.

Or build your own Mesa extensions disabling the drivers that pull in the huge dependencies (if you're not using them for graphics acceleration on your hardware), like I described in the thread.

I still haven't really worked out myself which is the ideal solution for customising dependencies since this Mesa update forced me to do so. I get so far into looking into how the updater scripts decide what to change and what to leave alone, then run out of time and forget it all.

[Juanito]

I updated gtk2 in the tc-16.x x86 repo - it no longer has a dep on libEGL/GL/GLESv2

[Zhe]

If I don't need xorg-7.7-3d, I will need to manually add libEGL.tcz to onboot.lst.

Code: [Select]

cat /var/log/Xorg.0.log | grep -E "\(EE\)"
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   194.068] (EE) Failed to load /usr/local/lib/xorg/modules/drivers/modesetting_drv.so: libgbm.so.1: cannot open shared object file: No such file or directory
[   194.068] (EE) Failed to load module "modesetting" (loader failed, 0)
[   194.068] (EE) No drivers available.
[   194.068] (EE)
[   194.068] (EE) no screens found(EE)
[   194.068] (EE)
[   194.068] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[   194.068] (EE)
[   194.068] (EE) Server terminated with error (1). Closing log file.


[Juanito]

You should see something like this:

Code: [Select]

[   391.239] (==) Matched intel as autoconfigured driver 0
[   391.239] (==) Matched modesetting as autoconfigured driver 1
[   391.239] (==) Matched fbdev as autoconfigured driver 2
[   391.239] (==) Matched vesa as autoconfigured driver 3
I would have thought that if the modesetting driver did not load, xorg-server would use fbdev or vesa?

[Zhe]

I would have thought that if the modesetting driver did not load, xorg-server would use fbdev or vesa?

Yes, this is a problem caused by my configuration. I used my own etc/X11/xorg.conf: Driver "modesetting"

[fier]

Splendid Juanito, the problem is solved! Zhe, thank you for telling me about update-everything

However, the packages are also pulled in with libva2 (used by mplayer-cli for example) as well, due to it also depending on libGL. Is there anything that can be done about that or rather not?

EDIT: I would like to add, I am personally not strapped for space. I was just worried that the performance may be decreased due to some kind of debug. But knowing what I know now, I know this is not the case. So personally for me, it is not important to get rid of this dependency.

[Juanito]

libva provides video acceleration for intel hardware, which users might find useful, so I'd prefer to leave it as-is.