also for the freeorion snap or is it a different one?
This is one of my KDE snaps peruse
If you build again with 7.4.3 does it work?
@sgmoore if both of these are using the kde-neon extension, the only major change there was your request to remove the PKG_CONFIG_PATH setting among other things in build-environment from the extension, you might want to look into adding those manually back.
7.4 is not available (as a snap) anymore as far as I can see
the freeorion snap does not use kde-neon; also the fedora desktop is gnome (tried both wayland and X)
I tried building locally with 7.5.1, which leads to the same problems.
I also see some linter warnings were present already in the working build; Note that the libraries are in the LD_LIBRARY_PATH in the snaps
Lint warnings:
- library: libEGL_mesa.so.0: unused library 'usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0.0.0'. (https://snapcraft.io/docs/linters-library)
- library: libGLU.so.1: unused library 'usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1'. (https://snapcraft.io/docs/linters-library)
- library: libGLX_mesa.so.0: unused library 'usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0'. (https://snapcraft.io/docs/linters-library)
- library: libboost_prg_exec_monitor.so.1.74.0: unused library 'usr/lib/x86_64-linux-gnu/libboost_prg_exec_monitor.so.1.74.0'. (https://snapcraft.io/docs/linters-library)
- library: libboost_unit_test_framework.so.1.74.0: unused library 'usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.74.0'. (https://snapcraft.io/docs/linters-library)
- library: libboost_wserialization.so.1.74.0: unused library 'usr/lib/x86_64-linux-gnu/libboost_wserialization.so.1.74.0'. (https://snapcraft.io/docs/linters-library)
- library: libicuio.so.70: unused library 'usr/lib/x86_64-linux-gnu/libicuio.so.70.1'. (https://snapcraft.io/docs/linters-library)
- library: libicutest.so.70: unused library 'usr/lib/x86_64-linux-gnu/libicutest.so.70.1'. (https://snapcraft.io/docs/linters-library)
- library: libpulse-simple.so.0: unused library 'usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.1'. (https://snapcraft.io/docs/linters-library)
- library: libtheora.so.0: unused library 'usr/lib/x86_64-linux-gnu/libtheora.so.0.3.10'. (https://snapcraft.io/docs/linters-library)
- library: libtheoraenc.so.1: unused library 'usr/lib/x86_64-linux-gnu/libtheoraenc.so.1.1.2'. (https://snapcraft.io/docs/linters-library)
$ ls -la /snap/freeorion/x1/usr/lib/x86_64-linux-gnu/lib*mesa*.so*
lrwxrwxrwx. 1 root root 20 Jun 19 13:41 /snap/freeorion/x1/usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0 -> libEGL_mesa.so.0.0.0
-rw-r--r--. 1 root root 296600 Jun 19 13:41 /snap/freeorion/x1/usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0.0.0
lrwxrwxrwx. 1 root root 20 Jun 19 13:41 /snap/freeorion/x1/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 -> libGLX_mesa.so.0.0.0
-rw-r--r--. 1 root root 463800 Jun 19 13:41 /snap/freeorion/x1/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0
edit: also no luck with 7.5.2
7.4.3 can be installed by revision number
Rev. Uploaded Arches Version Channels
9367 2023-06-14T11:58:21Z riscv64 7.4.3 7.x/candidate,7.x/stable,latest/candidate,latest/stable
9366 2023-06-14T09:26:15Z ppc64el 7.4.3 7.x/candidate,7.x/stable,latest/candidate,latest/stable
9365 2023-06-14T09:26:14Z armhf 7.4.3 7.x/candidate,7.x/stable,latest/candidate,latest/stable
9364 2023-06-14T09:24:15Z arm64 7.4.3 7.x/candidate,7.x/stable,latest/candidate,latest/stable
9363 2023-06-14T09:24:13Z s390x 7.4.3 7.x/candidate,7.x/stable,latest/candidate,latest/stable
9362 2023-06-14T09:17:16Z amd64 7.4.3 7.x/candidate,7.x/stable,latest/candidate,latest/stable
ok did a snapcraft remove purge ; snapcraft install --revision 9362 ; snapcraft clean ; snapcraft
$ snap run freeorion_test743
libGL error: did not find extension DRI_Mesa version 1
libGL error: failed to load driver: crocus
libGL error: did not find extension DRI_Mesa version 1
libGL error: failed to load driver: crocus
libGL error: did not find extension DRI_Mesa version 1
libGL error: failed to load driver: swrast
X Error: BadValue
Request Major code 152 (GLX)
Request Minor code 3 ()
Value 0x0
Error Serial #124
Current Serial #125
$ snapcraft --version
snapcraft 7.4.3
$ snap info snapcraft | grep installed
installed: 7.4.3 (9362) 60MB classic
So if I read correctly, it is not Snapcraft per se, but probably some mesa driver has been updated.
Another perhaps for me to relay to @Saviq or @kenvandine
@A333 can you point at the last working snap on edge? Comparing the contents of the two may shed light on the problem.
Also looking at the build logs for the working and non-working one could surface what changed.
https://wiki.gnome.org/Apps/Meld is quite helpful in finding the differences.
1 Like
My issue is resolved by libEGL warning: MESA-LOADER: failed to open DRI library In short I am able to launch my app locally with doing the patch-elf / no-patch-elf on the dri directory and then running LIBGL_DRIVERS_PATH=$SNAP/usr/lib/x86_64-linux-gnu/dri peruse inside a snap run --shell peruse environment. So it looks like in my case I need to update the kde content pack as the desktop-launcher sets LIBGL_DRIVERS_PATH to the content pack dri drivers which don’t work and setting LIBGL_DRIVERS_PATH in environment: has no affect ( I guess the desktop launcher overwrites it.)
Update: Rebuilding the content pack did fix mine. Had to snap refresh to get the new build.
We do the things mentioned in the link above in our content pack build. So my guess is a mesa update.
1 Like
Seeing that https://launchpad.net/ubuntu/+source/mesa got an update in Jammy a week ago, it does indeed look like there can be incompatibility between the content snaps and the “consumer” ones.
But that would mean there’s a problem with the boundary between the snaps - everything Mesa should be in the content snaps, so an update to mesa in the archive should not cause the consumer snaps to stop working.
Sure, rebuilding helps, but if they have to be kept in sync, then we can’t have them separated…
1 Like
OK I found the culprit in another snap.
You have to make sure that you have no Mesa left in your consumer snap - that only the gnome-platform (or mesa-core22) libraries are in use.
In the case I saw, the gnome extension (I think) should clear them up, but didn’t.
These are the files I found (and removed) in the snap I looked at:
./usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
./usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0
./usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0
./usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0.0.0
./usr/share/glvnd/egl_vendor.d/50_mesa.json
Just look in your snaps for any files with mesa in them, those should not be there. Some others may also be problematic.
Basically check the relevant content snap (gnome or mesa-core22) and make sure there’s no overlap. Again, Meld to the rescue 
4 Likes
Do the extensions do cleanup automatically? From what I’d been testing a few weeks ago, it doesn’t appear to have been the case; but I wasn’t looking at Mesa specifically. I’ve always assumed people would have to add the boilerplate cleanup “part” explicitly.
1 Like
reporting some progress.
I do not understand the implications of referenced fix sgmore used from ( libEGL warning: MESA-LOADER: failed to open DRI library )
So i stole the cleanup part from the gnome-calculator to get rid of duplicates. And i removed some libs from snapcraft.yaml and it kind of works on a local build - the game is playable (with having some mysteriuous extraenous *png.import files in the snap). But it failed to build (probably because of the removed libs). So hopefully will be resolved soon
The libs are supposed to be removed after everything is built; I could understand it causing errors at runtime, but I’d expect that if you’re having problems with the building itself, the cleanup part isn’t properly setup. Did you both make sure the after: [parts] section covers all your parts and change the hardcoded names for the base/content snap to match the base/content snap you’re using?
in hindsight that build problem is quite expected; by mistake I removed a library which is not in the gnome extension.
The puzzling thing is rather that the local build did succeed (cache thingy or taking stuff from the host system?)
Possibly cache/state, although snapcraft attempts to detect when rebuilding parts are needed to ensure a consistent state, there’s plenty of scenarios where you can end up in a bad state and need to clean/reset the whole build instance for proper reproducability.
Thanks everybody, removing the duplicate libraries using the cleanup part from gnome-calculator resolved the issue.
Should I change the title to something more useful?
1 Like