[ten9876]

Summary

The Linux AppImage fails to package on both x86_64 and aarch64 since the Qt 6.12.0 pin (#5842). The next tagged release would ship without an AppImage. This fixes the packaging step.

Cause

Qt 6.12.0 ships a single Wayland platform plugin, plugins/platforms/libqwayland.so, in place of 6.8's libqwayland-generic.so and libqwayland-egl.so. appimage.yml still asked linuxdeploy-plugin-qt for the old names, so both legs failed in Build AppImage:

[qt/stdout] ERROR: Cannot deploy non-existing library file: .../Qt/6.12.0/gcc_64/plugins/platforms/libqwayland-generic.so
ERROR: Failed to run plugin: qt (exit code: 1)

How I verified it, by installing the exact archives the workflow uses (aqt install-qt linux desktop <ver> linux_gcc_64 --archives qtbase qtwayland, aqtinstall 3.3.0):

Qt	plugins/platforms/ Wayland plugins
6.8.3	libqwayland-generic.so, libqwayland-egl.so
6.12.0	libqwayland.so

The 6.12 plugin's embedded metadata lists keys wayland, wayland-egl, wayland-brcm, so the one plugin covers both old ones. wayland-graphics-integration-client/libqt-plugin-wayland-egl.so, which the workflow stages by hand for OpenGL, is still present in 6.12, and so are wayland-decoration-client and wayland-shell-integration.

Change

.github/workflows/appimage.yml, one functional line:

-          EXTRA_PLATFORM_PLUGINS: libqwayland-generic.so;libqwayland-egl.so
+          EXTRA_PLATFORM_PLUGINS: libqwayland.so

The rest of the diff corrects three comments that described the old two-plugin layout, including the bundle-assertion step's reference to the "generic" platform plugin. The Assert the Wayland plugins were bundled step is otherwise unchanged: it already accepts any libqwayland*.so in platforms/ and still requires the EGL integration plugin plus the decoration and shell directories, so it continues to guard against the #1389 regression.

Evidence

• Before: workflow_dispatch on a branch with the 6.12 pin failed on both legs with the error above (run 37051991518).
• After: the same change dispatched on this branch built, packaged and passed the Wayland assertion on x86_64 and aarch64 (run 37061738812). It also packaged the CTR2 branch on both arches (run 37065101641).
• On the head being merged (5467cdd6f, current main merged in): a dispatch passed on both arches (run 37141239411). linuxdeploy logs Deploying extra platform plugin: libqwayland.so, and the Wayland assertion lists platforms/libqwayland.so, wayland-decoration-client, wayland-graphics-integration-client and wayland-shell-integration on x86_64 and aarch64.
• check_qt_pin.py --strict and its self-test pass, and the YAML parses.

Not tested: running the resulting AppImage under a native Wayland session. The packaging step and its plugin assertion are what this PR fixes and proves.

This is a CI workflow change, made at the maintainer's request.

🤖 Generated with Claude Code

[aethersdr-agent]

Issue fit

Yes — with the caveat that there is no linked issue; the PR is self-describing and names #5842 (bc4f2b04, "migrate binary Qt pin to final 6.12.0") as the cause, which I confirmed is the last functional change to appimage.yml on main before this one. GOVERNANCE.md does not want an RFC here: this is a CI breakage with a named root cause, the author is a COLLABORATOR, and the body states it was made at the maintainer's request. The stated defect (linuxdeploy-plugin-qt asked for plugin filenames that no longer exist in the 6.12 tree) is addressed by exactly the one functional line it needs to be.

Scope

File / group	What it changes	Claimed in body?	Verdict
.github/workflows/appimage.yml:391	EXTRA_PLATFORM_PLUGINS: libqwayland-generic.so;libqwayland-egl.so → libqwayland.so	Yes, quoted verbatim	In scope — the fix
.github/workflows/appimage.yml:185-187, 325-327	Two comments rewritten to describe the single-plugin 6.12 layout	Yes ("corrects two comments")	In scope

git diff --stat main on the head checkout is one file, 7 insertions / 8 deletions — everything in the diff is explained by the stated fix. No CHANGELOG entry (correct). No new public surface, no config key, no settings or capability touch, so CONSTITUTION I/II/III/V/VI and the AGENTS.md persistence, migration and credential rules are not implicated. No preference content: nothing user-visible changes, and the comment edits move toward the real layout rather than away from it.

Blockers

None.

Nits

• A third stale comment survived. appimage.yml:447, inside the unchanged "Assert the Wayland plugins were bundled" step, still reads "The generic platform plugin gets OpenGL only through this one…". That's the pre-6.12 name, and the body's claim is that the diff corrects the comments describing the old two-plugin layout — this one is the same class and got missed. Untouched line, so no inline anchor; suggest "The Wayland platform plugin gets OpenGL only through this one". Purely editorial.

What I tried to break

• Sibling call sites. Grepped the whole head checkout for libqwayland, wayland-generic and qwayland-egl: after this PR the only hits are in appimage.yml. scripts/setup/setup-qt.sh, tools/check_qt_pin.py, cmake/qt-pin.env, the CI Dockerfile, the other 13 workflows and docs/BUILDING.md name no Qt plugin filenames — BUILDING.md documents only QT_QPA_PLATFORM strings, which this does not change. No surface left on the old names.
• Deleted lines read as carefully as added ones. The removed text was explanatory (why wayland resolved to -generic and not -egl), not a guard, an early return or a confirmation. The guard in this file is the assertion step, and it is untouched: find "$plugins/platforms" -maxdepth 1 -name 'libqwayland*.so' (line 437) is prefix-globbed, so it covers the new name without edits, and it still requires libqt-plugin-wayland-egl.so plus the wayland-decoration-client and wayland-shell-integration dirs. The #1389 shape stays fenced.
• "linuxdeploy's auto-deploy keys off the libqwayland* name" — this is the quiet dependency the one-line change could have broken (a single name instead of two could plausibly have stopped triggering the decoration/shell special case). The assertion step checks both of those directories and it passed on both arches, so that one is actually proved by the runs, not just argued.
• The CI evidence, checked rather than taken on trust. get_check_runs on 5aac8578 shows build-appimage green for both ubuntu-22.04 / x86_64 and ubuntu-24.04-arm / aarch64 in run 37131747885 — the exact run the body cites. Note for the maintainer what kind of evidence that is: appimage.yml triggers only on push: tags and workflow_dispatch, so this is an author-dispatched run on the PR head, not an automatic PR gate. It is legitimate and it is on the current head. Separately, the existence claim holds up on its own logic: the before-run's failure mode is Cannot deploy non-existing library file, i.e. linuxdeploy hard-errors on a name that isn't there, so a green packaging step is proof that libqwayland.so exists in the 6.12 aqt tree.
• Could not check, and the author says so. The "keys wayland, wayland-egl, wayland-brcm" claim — that QT_QPA_PLATFORM=wayland (and wayland;xcb, which src/main.cpp:299 actually requests) selects this plugin at runtime — is not tested by anything here. The assertion step is file-presence only; no gate reads plugin metadata. The body discloses this honestly ("Not tested: running the resulting AppImage under a native Wayland session"), so I am recording it as a disclosed coverage boundary rather than a finding. If it were wrong, the symptom would be a silent XWayland fallback on a release AppImage, which the assertion step cannot catch by construction — a one-time manual smoke test on a Wayland host before the next tag would close it.
• No tests are owed: this is a CI workflow file with no deterministic in-tree seam, and no socket test or fake peer is added, modified or removed anywhere in the diff. All findings above are reasoned from the diff and the head checkout plus the CI API; I ran no build and executed nothing.

Recommendation

Approve with nits. The fix is minimal, the stale-name surface is genuinely exhausted, the regression guard that protects #1389 survives the change untouched because it was written prefix-globbed, and the packaging legs are green on this exact head for both architectures. The only thing worth doing before merge is the :447 wording, and that is editorial enough to fold into a follow-up if you would rather not re-dispatch the release workflow. Thanks for including the before/after run IDs and for naming what you did not test — both made this much faster to check.

---

_{🤖 aethersdr-agent · cost: $2.9219 · model: claude-opus-5}

[ten9876]

Issue fit

Yes — the stated packaging defect is addressed. There is no linked issue; reviewed against the PR's stated intent. At head 5aac857852c4444d3e6015fda17cdcad0c43cc05, .github/workflows/appimage.yml:391 replaces the two obsolete platform filenames with libqwayland.so for both matrix legs. The existing integration staging and bundle assertions remain intact. GOVERNANCE.md explicitly exempts build/CI fixes from an RFC; no new dependency, public interface, UX preference, or architecture change is introduced.

Scope

File / lines	Change	Claimed in body?	Verdict
.github/workflows/appimage.yml:391	Request the Qt 6.12 platform plugin	Yes	In scope
.github/workflows/appimage.yml:185–190,325–329	Describe the single-plugin layout	Yes	In scope

Everything in the diff is explained by the stated fix. One commit, authored October 2; no unrelated commit or CHANGELOG addition. Parsed YAML comparison, excluding shell comment lines, confirms exactly one changed configuration value. No source/test changes, socket-owning tests, engine-boundary growth, or relaxed guards.

Blockers

None.

Nits — non-blocking

1. Stale terminology: .github/workflows/appimage.yml:447 still calls it the “generic platform plugin.” Independently confirmed the earlier bot's editorial finding. Suggested replacement:

             # The Wayland platform plugin gets OpenGL only through this one, and no

Verification and attacks

• Inspected the actual failing logs from run 37051991518: both architectures report Cannot deploy non-existing library file: .../plugins/platforms/libqwayland-generic.so and plugin exit 1. Inspected exact-head run 37131747885: both packaging steps and both Wayland assertions succeed. Both assertion logs print AppDir/usr/plugins/platforms/libqwayland.so, wayland-decoration-client, and wayland-shell-integration. This is executed CI evidence, not a new local packaging build.
• In a detached scratch worktree, ran python3 tools/check_qt_pin.py --strict (28 sites pass), python3 tools/test_check_qt_pin.py (17/17 pass), and YAML parsing/comparison. The pin checker is consistency coverage, not regression coverage for the filename change.
• Executed the unchanged bundle-assertion shell against temporary filesystem fixtures: the new plugin layout exits 0; separately removing the platform plugin, EGL integration file, decoration directory, or shell directory makes it exit 1. These negative checks prove the file-presence guard still rejects incomplete layouts; they do not prove plugin loading. Searched sibling deployment references: no remaining old filenames outside the removed lines.
• CI freshness: current main is 732b99a90e9f6ad8154872bc1ab11471d04d2569, also this PR's merge base. Its timestamp is 2026-10-03T04:07:30Z; earliest head run was created 15:01:17Z. All four protection-required checks passed. AppImage is a separate workflow_dispatch run on the exact head, not a PR merge gate. Protection has strict: false, but no stale-main gap exists at this review snapshot.
• No GUI bridge session or native Wayland smoke test: this change repairs the release-packaging path, and an offscreen demo would not prove native Wayland plugin loading. The archive comparison, embedded plugin-key metadata (.github/workflows/appimage.yml:185–186), and native runtime were not independently reproduced. The latter is explicitly disclosed by the author; a native Wayland AppImage smoke test remains useful before release. No operator app/radio was touched. A separate automated code-review skill was unavailable; performed the manual equivalent and verified the prior bot's relevant claims.

Recommendation

Approve with nits. The packaging failure and exact-head success on both architectures are supported by logs, and local negative checks confirm the unchanged bundle guard still works. The remaining wording fix is optional; retain the disclosed native-Wayland runtime boundary and obtain the required maintainer CODEOWNER sign-off for this Tier-1 release workflow. This is a COMMENT review, not an approval or merge.

[ten9876]

Both reviews' nit is fixed. The only finding was the stale "generic platform plugin" wording at appimage.yml:447. The automated code-review pass at medium effort flagged the same line and nothing else.

• Fix: dfdede6f9 changes .github/workflows/appimage.yml:447 to "The Wayland platform plugin gets OpenGL only through this one". It is a comment-only edit, and the YAML still parses. A grep of .github/ scripts/ docs/ tools/ cmake/ finds no qwayland-generic, qwayland-egl or "generic platform" left.
• Main merged in: 5467cdd6f, because feat(tx): apply TUNE power live while TUNE is keyed (HL2, Icom). Principle VI. #6104, fix(rtl): gate worker spectrum and read errors after disconnect. Principle VIII. #6107 and fix(sim): open the gate before announcing connected, reply before disconnecting. Principle VIII. #6108 landed after the previous head's CI ran. All three commits are signed (verified=true, reason=valid).
• Proof on the exact head: AppImage run 37141239411 on 5467cdd6f passed on both x86_64 and aarch64. linuxdeploy logged Deploying extra platform plugin: libqwayland.so, and the assertion step printed:

  AppDir/usr/plugins/platforms/libqwayland.so
  AppDir/usr/plugins/wayland-decoration-client
  AppDir/usr/plugins/wayland-graphics-integration-client
  AppDir/usr/plugins/wayland-shell-integration
  

  PR CI on the same head passed: build, check-windows, check-macos and Static checks.
• Still unverified: the native Wayland runtime smoke test both reviews mention. It needs a Wayland host running the release AppImage before the next tag; nothing in CI can exercise it.

The author and the acting identity are the same account, so an approving review is impossible. This lands by maintainer admin-merge.