snap: consume graphics-core22 instead of bundling Mesa drivers

[axpnet]

Problem

Snapcraft's GPU linter reports that the AeroFTP core22 snap primes its own Mesa DRI/EGL/GLX/libdrm stack. The current package contains usr/lib/x86_64-linux-gnu/dri/*_dri.so, libEGL_mesa, libGLX_mesa, libgbm, and vendor libdrm libraries even though hardware-specific userspace should come from a graphics content provider.

Canonical's current guidance recommends the graphics-core22 content interface with mesa-core22, the maintained wrapper, and cleanup helper. This matters beyond package size: shipping a private Mesa stack can conflict with host/NVIDIA userspace and was visible while diagnosing the confined WebKit GUI regression in #462 / PR #463.

Official guide: https://ubuntu.com/frame/docs/22/how-to/use-snap-graphics/

Acceptance criteria

• Add a graphics-core22 content plug targeting $SNAP/graphics, default provider mesa-core22.
• Run the maintained graphics-core22-wrapper in the app command chain without breaking the GNOME extension's desktop launcher.
• Add the official graphics-core22-cleanup part after AeroFTP and remove provider-owned Mesa/DRI/GLVND/libdrm files from the primed app snap.
• Add the documented X11/libdrm layouts required by the wrapper.
• Confirm snapcraft lint no longer emits gpu: warnings for bundled drivers; assess remaining library-linter warnings individually (dynamic loading vs genuinely unused) rather than blanket-ignore them.
• CI: G1 ABI, G2 installed CLI payload, and G3 confined GUI readiness under Xvfb all pass.
• Validate on a real GPU-capable disposable CI/VM path as a separate acceleration check; do not use the owner's desktop session.
• Do not publish to the Snap Store until the migration and GUI gates are green.

Scope note

PR #463 should first restore a renderable confined GUI and prove startup. This issue owns the larger graphics-provider migration so it can be reviewed and validated independently rather than combining two runtime architecture changes in one recovery PR.

[axpnet]

Status, criterion by criterion, with the evidence for each

The migration is implemented on main and not yet exercised anywhere. Those are two different things and the checklist conflates them, so here is each box with what actually backs it.

#	Criterion	State	Evidence
1	graphics-core22 content plug targeting $SNAP/graphics, default provider mesa-core22	✅ implemented	snap/snapcraft.yaml, plugs: block, target: $SNAP/graphics, default-provider: mesa-core22
2	graphics-core22-wrapper in the command chain without breaking the GNOME extension launcher	⚠️ implemented, unproven	command-chain: [bin/graphics-core22-wrapper] sits next to extensions: [gnome] and desktop:. That the launcher still works is a claim only G3 can settle, and G3 has not run (see below)
3	graphics-core22-cleanup part after AeroFTP, provider-owned files removed from the prime	⚠️ implemented, unproven	part graphics-core22, after: [aeroftp], override-prime runs graphics-core22-cleanup mesa-core22 nvidia-core22, source pinned to d2b0948e. Whether it removes anything has never been observed on a built snap
4	Documented X11/libdrm layouts	✅ implemented	layout: binds /usr/share/libdrm, symlinks drirc.d, X11/XErrorDB, X11/locale
5	snapcraft lint clean of gpu:, library warnings judged individually	✅ now has a check	#485 adds scripts/snap-gpu-lint-check.sh as Gate G4. Before it, G1 only grepped /dri/*_dri.so and libEGL/GLX_mesa, missing libgbm, the vendor libdrm family and vulkan ICDs, and never ran the linter at all
6	CI: G1, G2, G3 all pass	❌ unverified	see below, this is the one that matters
7	Validate on a real GPU-capable disposable CI/VM	❌ not possible today	GitHub-hosted runners have no GPU. Being evaluated separately as a self-hosted runner question
8	Do not publish to the Store until migration and GUI gates are green	✅ holding	nothing published since. The Store still serves 4.1.6, which predates the migration

Criterion 6: the gates have never run against a snap that has this migration

This is not a suspicion, it is a timeline:

• the gate that checks for bundled GPU userspace arrived in d688efadc, 2026-07-26 23:01;
• the last snap-refresh run that actually packed a snap was 2026-07-26 01:56, twenty-one hours earlier;
• the only run since, 2026-07-27 07:53, completed audit and skipped payload and pack.

So no build of this snapcraft.yaml has ever been produced, let alone gated.

There is a structural reason, and it is the same one that keeps the white-window fix out of users' hands: snap-refresh packs with the snapcraft.yaml of the tag it rebuilds, and the newest tag predates the migration. Rebuilding an old tag faithfully reproduces the old snap.

Measured rather than assumed. snap download aeroftp from the stable channel, then the new gate:

Snap:     aeroftp-store.snap        (meta/snap.yaml: version 4.1.6)
Unpacked: 9574 files
::error::the snap primes 27 provider-owned GPU file(s):
    usr/lib/x86_64-linux-gnu/dri/{crocus,d3d12,i915,iris,kms_swrast,nouveau,
                                  r300,r600,radeonsi,swrast,virtio_gpu,
                                  vmwgfx,zink}_dri.so
    usr/lib/x86_64-linux-gnu/libdrm_{amdgpu,intel,nouveau,radeon}.so.*
    usr/lib/x86_64-linux-gnu/lib{EGL_mesa,GLX_mesa,gbm}.so.*

That snap has no graphics-core22 plug and no command-chain in meta/snap.yaml at all. It is the pre-migration package, exactly as expected, and it doubles as the proof that the new gate reports the real state instead of passing vacuously.

What actually closes this issue

A v4.1.7 tag. Everything else is either done or blocked behind it: criterion 6 becomes checkable the moment a tag carrying this snapcraft.yaml gets packed, and criteria 2 and 3 get their evidence from the same run.

Until then this issue is correctly open, and closing it would record as verified something that has never been built.

Criterion 7 is a separate decision about self-hosted GPU runners and does not have to gate the rest.

[axpnet]

Criterion 7: decided, will not be pursued

The GPU-capable validation path is dropped, deliberately, and the reason is worth recording so nobody re-opens the question in six months.

GitHub-hosted GPU runners (linux_4_core_gpu, $0.052/min) require a Team or Enterprise Cloud plan; this organization is on free, and larger runners are not free on public repositories either. The remaining alternatives are a rented GPU box (Hetzner starts at 184 EUR/month, billed monthly, with no stop-to-save) or a self-hosted runner on a developer machine. The last one is the trap: aeroftp is a public repository, so a self-hosted runner would let any fork's pull request execute code on that machine. Free and open source is the right shape for this project, and none of the three fits it.

What replaces it is not a workaround, it is the thing that was needed anyway: tag v4.1.7. That makes criterion 6 checkable, since snap-refresh packs with the snapcraft.yaml of the tag and would finally build this one, and criteria 2 and 3 get their evidence from the same run. The accelerated path stays covered by what the app already does at runtime: after #466 it probes EGL at startup and falls back to software only when EGL cannot answer, which is the behaviour a GPU runner would have been asserting.

So this issue is now blocked on a release tag and on nothing else.