we do a weekly build for the freeorion snap (core22) using the github hooks . Yesterdays build created a runtime problem for me (seems not to find mesa libs anymore).
So i rebuild a older revision which did work two weeks ago and it also is not able to find the mesa libs anymore. The build from two weeks ago still runs fine (installed locally here as freeorion_test) while the same revision build yesterday is broken (freeorion_edge).
This is on a fedora host system
$ sh -c 'snap info freeorion_test ; snap info freeorion_edge' | grep installed
installed: 2023-07-18.3e4785df6 (373) 405MB -
installed: 2023-07-18.3e4785df6 (375) 406MB -
$ freeorion_test
[2023-08-07 16:37:48.184747] [0x00007f39cf281c80] [info] Audio disabled.
$ freeorion_edge
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
edit1: according to the logs, the good build was done with snapcraft 7.4.3 and the bad one with 7.5
On a kubuntu 22.04 (amdgpu) the error i get is
libEGL fatal: did not find extension DRI_Mesa version 1
edit: original title was āCant find mesa/did something change with the snapcraft.io builders?ā
libGL error: did not find extension DRI_Mesa version 1 libGL error: failed to load driver: iris libGL error: did not find extension DRI_Mesa version 1 libGL error: failed to load driver: iris libGL error: did not find extension DRI_Mesa version 1 libGL error: failed to load driver: swrast peruse(179628)/(default) \[31munknown\[0m: Warning: fallback to QtQuick software backend. peruse(179628)/(default) \[31munknown\[0m: Qt: Session management error: Could not open network socket peruse(179628)/(default) \[31m\[34munknown\[0m: No OpenGL context could be created, this is clearly bad...
@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.
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
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.)
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ā¦
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.
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?
