fix(ci): un-bundle libwayland from the AppImage to stop the EGL abort (#67)

[lukaszsobala]

Summary

Fixes #67 — the Linux AppImage shows a blank white window and logs:

Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...

Root cause

linuxdeploy pulls libwebkit2gtk's transitive libwayland-{client,cursor,egl,server} into the AppImage. Those copies come from the Ubuntu 24.04 build environment and are older than the Mesa the user is running, so when libEGL_mesa initialises the Wayland platform it hits a protocol/ABI mismatch and aborts. The webview never paints.

The abort happens inside EGL display init, before WebKit reads any of its environment — which is exactly why WEBKIT_DISABLE_DMABUF_RENDERER, WEBKIT_DISABLE_COMPOSITING_MODE, GDK_BACKEND=x11 and LIBGL_ALWAYS_SOFTWARE have no effect for the reporters in #67.

Fix

libwayland — like libGL/libEGL/libgbm/libdrm, which linuxdeploy already excludes — has to come from the running system so it matches the loaded EGL stack. Its soname has been frozen for over a decade, so deferring to the host is safe.

scripts/build/appimage-unbundle-wayland.sh runs after the Tauri build: extract → delete the four libwayland-* → repack with appimagetool → re-sign. It's wired into all three workflows that produce an AppImage (maintenance-release, maintenance-build, maintenance-pr-check).

This is the same thing several people in #67 confirmed by hand (--appimage-extract, rm squashfs-root/usr/lib/*wayland*so*, run AppRun) — just done once at build time so users don't have to.

Only the AppImage bundles libraries; the .deb links the system libwayland and is unaffected.

Note on the updater signature

Repacking changes the AppImage bytes, so the .sig Tauri emitted during the build no longer matches. The script re-signs with cargo tauri signer sign; without that the in-app updater would reject every Linux update. Worth a careful look during review, since it's the one part that can't be exercised without the release signing secret.

(tauri signer sign reads TAURI_PRIVATE_KEY/TAURI_PRIVATE_KEY_PASSWORD, not the TAURI_SIGNING_* names the bundler uses — the script maps them, and fails loudly rather than shipping a stale signature if the key is missing.)

Verification

A/B tested against the published Armbian.Imager_2.0.2_amd64.AppImage on Wayland (XDG_SESSION_TYPE=wayland), running the script exactly as CI invokes it:

Stock release — reproduces the bug:

qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...

After the script — starts and renders:

● main: === Armbian Imager Starting ===
● picture_cache: Pre-populate complete: 436/436 assets processed
● frontend::app: Not running on Armbian system
● frontend::updater: No updates available

No EGL error, and the frontend::* lines mean the webview actually executed the app.

The script found and removed all four libs, and repacked cleanly:

squashfs-root/usr/lib/libwayland-server.so.0
squashfs-root/usr/lib/libwayland-egl.so.1
squashfs-root/usr/lib/libwayland-cursor.so.0
squashfs-root/usr/lib/libwayland-client.so.0

CI-side, the Linux job of this PR's own build exercises the script end to end.

Notes

• No new build dependency: appimagetool bundles its own mksquashfs.
• Arch-aware (x86_64 / aarch64), so the ARM64 AppImage gets the same treatment.
• Uses --appimage-extract-and-run so no FUSE is needed on the runners.
• The find … -delete is path-tolerant and a no-op if a future linuxdeploy stops bundling these, so the step won't break the build once it's no longer needed.
• This is narrower than the "build against a newer WebKitGTK" idea floated in [Bug]: White Blank Screen while using .AppImage #67 — it doesn't change what WebKit version ships, only which libwayland gets loaded. The two aren't mutually exclusive.

[SuperKali]

LGTM