fix gtk load on snap

Author: fcjr

.github/workflows/release-app.yml

@@ -18,9 +18,14 @@ jobs:
         include:
           - os: macos-14
             toolchain: stable
-          - os: ubuntu-22.04
+          # ubuntu-24.04 to match the snap's core24 base: the snap is packed
+          # in destructive mode further down, so stage-packages resolve
+          # against this runner's archive. Bumping the base means bumping
+          # these together. Side effect: the .deb and AppImage now link
+          # noble's glibc/webkit, so they need Ubuntu 24.04 or newer.
+          - os: ubuntu-24.04
             toolchain: stable
-          - os: ubuntu-22.04-arm
+          - os: ubuntu-24.04-arm
             toolchain: stable
           # Windows uses the GNU host toolchain — the vendored C stack is built
           # with autotools (no MSVC), and it's what the helper + app link against.
@@ -146,7 +151,7 @@ jobs:
       # Pack the .deb into a snap and publish it to the Snap Store under the
       # plain `restorekit` name (the CLI ships separately as `restorekit-cli`).
       # Destructive mode builds on the host directly, which works because the
-      # runner (ubuntu-22.04) matches the snap's core22 base. Pack runs under
+      # runner (ubuntu-24.04) matches the snap's core24 base. Pack runs under
       # sudo: snapcraft shells out to `snap install` for the gnome extension's
       # build snaps, and snapd only allows that as root. It also swallows snap's
       # stderr, so dump its log on failure to see the real error.

apps/desktop/snap/snapcraft.yaml

@@ -3,11 +3,21 @@
 # homebrew/restorekit.rb). The plain `restorekit` snap name is the desktop
 # app; the CLI ships separately as `restorekit-cli` (see .goreleaser.yaml).
 #
-# base core22 must match the runner the .deb is built on (ubuntu-22.04) —
+# base core24 must match the runner the .deb is built on (ubuntu-24.04) —
 # bump both together.
+#
+# core24 is load-bearing, not housekeeping: on core24 the gnome extension
+# resolves to gnome-46-2404 and plugs `gpu-2404`, which hands the snap a
+# self-consistent Mesa userspace from the mesa-2404 content snap. A core22
+# build has no gpu-2404 and instead borrows the *host's* DRI drivers through
+# the plain `opengl` interface. Once the host's Mesa outruns the runtime's
+# (Ubuntu 26.04 ships Mesa 26; gnome-42-2204 carries 25.2), the two disagree
+# about the driver-loading interface and the app dies at startup with
+# "libEGL fatal: did not find extension DRI_Mesa version 1". No environment
+# variable works around it — the failure is under the app, in EGL.
 name: restorekit
 title: RestoreKit
-base: core22
+base: core24
 version: "VERSION_PLACEHOLDER"
 summary: Restore Apple Silicon Macs with one click
 description: |
@@ -20,10 +30,11 @@ license: Apache-2.0
 grade: stable
 confinement: strict
 
-# WebKit looks up its subprocess binaries at the host path.
+# WebKit looks up its subprocess binaries at the host path. core24 dropped
+# $CRAFT_ARCH_TRIPLET in favour of the explicit build-for spelling.
 layout:
-  /usr/lib/$CRAFT_ARCH_TRIPLET/webkit2gtk-4.1:
-    bind: $SNAP/usr/lib/$CRAFT_ARCH_TRIPLET/webkit2gtk-4.1
+  /usr/lib/$CRAFT_ARCH_TRIPLET_BUILD_FOR/webkit2gtk-4.1:
+    bind: $SNAP/usr/lib/$CRAFT_ARCH_TRIPLET_BUILD_FOR/webkit2gtk-4.1
 
 apps:
   restorekit:
@@ -39,7 +50,7 @@ parts:
     source-type: deb
     # GTK3 comes from the gnome extension; webkit2gtk does not. Neither does
     # libusb — restorekit-desktop links it dynamically, and it's in neither
-    # core22 nor gnome-42-2204, so the app dies at exec with
+    # core24 nor gnome-46-2404, so the app dies at exec with
     # "libusb-1.0.so.0: cannot open shared object file".
     stage-packages:
       - libwebkit2gtk-4.1-0