fix(ci): strip host-coupled libwayland from the AppImage so it starts on newer Mesa - #499
Merged
PathGao merged 1 commit intoAug 7, 2026
Conversation
… on newer Mesa The AppImage bundles the ubuntu-24.04 libwayland-client.so.0, which shadows a newer host copy and makes host libEGL fail eglGetPlatformDisplay with EGL_BAD_PARAMETER. WebKit's WebProcess aborts and the window comes up blank. That library is on the AppImage excludelist precisely because it must come from the host, but tauri/linuxdeploy bundles it anyway. Strip the six host-coupled graphics libraries after the build, repack, and re-sign so the updater signature still matches the artifact. This is separate from the WebKitGTK version pin fixed in sftwrdotdev#463 (shipped in 2.7.1); see sftwrdotdev#498.
Closed
Collaborator
|
Thank you for testing the built artifact rather than trusting the diff — including mine. I wrote in #496 that #182 would be fixed the moment 2.7.1 shipped, on the strength of reading #463. You went and ran it. That was the right order and I have corrected the issue. The Linux judgement here is yours, and I am not going to second-guess it. I have no Linux hardware and cannot reproduce or verify any of it, and it would not be a good trade to hold up a fix from someone who can run it on a reviewer who cannot. The single-library isolation table settles the cause about as directly as it can be settled. One thing I do want to flag, because it is not a Linux question and does not need a Linux machine to judge:
Pinning to a tagged release, or keeping For context on why this reads as load-bearing here: Everything else — the six libraries, the repack mechanics, the backend independence — I defer to you on entirely. |
This was referenced Aug 7, 2026
PathGao
added a commit
that referenced
this pull request
Aug 11, 2026
* ci: compile pull requests on the Ubuntu the release compiles on test_build.yml's Linux entry has said ubuntu-22.04 since the commit that created the workflow -- `git log -S` finds exactly one, "added test and build workflows" -- while build.yml moved to ubuntu-24.04 and has been maintained there through #499's AppImage strip and #463's WebKitGTK unpin. Nothing chose 22.04; nothing revisited it either. Two Ubuntus are two sets of system libraries, so the platform check was answering a question nobody asked: "the pull request compiled" did not mean "the release will". And the AppImage a pull request produces bundles libraries from a release nothing ships -- the class of defect #463 and #498 both were. The other direction is the usual AppImage advice: build on the older distribution, because a binary linked against an older glibc runs on more systems. It is not available here. jammy's WebKitGTK is older than noble's, and older WebKitGTK failing EGL against current Mesa is precisely #463. Releasing from 22.04 means solving that again. One assertion, in the shape of the Node one beside it: the two workflows are compared against each other rather than against a literal, so a named version does not become a fourth place to update. Checked by mutation -- restoring 22.04 fails it, and nothing else. 974 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * ci: one Ubuntu for everything that compiles, named in one place Extends this branch after its own first run failed. test.yml runs on ubuntu-22.04 too, and it runs `cargo test` behind the same apt list -- so the third compiling workflow was on the third environment, not the second. It moves to 24.04 with the others. And the first attempt here broke, which is the more useful half. Moving test_build.yml's matrix to 24.04 left `install dependencies (ubuntu only)` asking for `matrix.platform == 'ubuntu-22.04'`, so it was skipped in silence and `cargo test` failed on a missing libwebkit2gtk-4.1-dev -- a failure that said nothing about the change that caused it (run 31486273066). build.yml repeats the same pattern twelve times. Every matrix already carries a stable name for the entry -- `os` in build.yml, `os-name` in test_build.yml -- that does not change when the runner does. All thirteen conditions now use it, and no workflow branches on a runner name. The runner is written where the matrix declares it and nowhere else. Two assertions, both checked by mutation, both failing alone: - reverting test.yml to 22.04 fails "every workflow that compiles compiles on the same Ubuntu" - reverting one condition fails "a step asks which matrix entry it is" The first mutation check for the second assertion silently did not mutate -- BSD sed ignores `0,/re/s//repl/` -- and reported a pass. Redone with the edit verified before the run. 975 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: PathGao <gaoyanbo@gaoyanbodeMacBook-Air.local> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
PathGao
pushed a commit
that referenced
this pull request
Aug 11, 2026
Stacked on ci/one-linux-dependency-list. Two questions about the Linux artifact that nothing has been answering, and one comment that was about to become false. `check-appimage-libraries.sh`, on every pull request. strip-appimage.sh proves its six libraries are gone afterwards; that is "we removed what we meant to", not "six is still the right number". What decides the right number is not in this repository -- `tauri build` fetches linuxdeploy-plugin-gtk from the tip of someone else's branch on every run, so the set copied into the AppDir can change with no commit here, no pull request and no notification. The script intersects what is bundled with the AppImage project's own excludelist and requires the result to equal the strip list exactly, in both directions. It reads that list out of strip-appimage.sh rather than restating it. It runs on the pull request build because that AppImage is the un-stripped one, which for this question is the right artifact rather than a worse one. It only became comparable when #580 moved this job to the release's Ubuntu. `smoke-appimage.sh`, on the release, after the re-sign and before the upload. strip-appimage.sh said a CI smoke test cannot catch this defect because the runner's Mesa is the one the libraries came from -- true of the runner, and only of the runner. A container is another distribution's userspace on the same kernel, which is a host that can disagree. The comment now says so. Liveness is not the check. #499 records that the GTK shell survives while WebKit's WebProcess aborts behind a blank window, so both defects this exists to catch would have passed a "is it still running" test. It greps for the abort, and keeps the liveness check as the backstop for a reworded one. Both scripts also run on pull requests, after a strip, and that is the point rather than thoroughness: smoke-appimage.sh would otherwise reach the release path having never run anywhere, and strip-appimage.sh has never run outside a release -- it failed in two of the three v2.7.2 release attempts. Roughly three minutes on a twelve-minute job. Also, one line in dependabot.yml: the github-actions ecosystem covers `uses:` and not `runs-on:`, so nothing proposes ubuntu-24.04 -> 26.04 and nobody should assume something is watching. Three assertions, each checked by mutation and each failing alone: smoking before the strip, dropping the release smoke, and restating the library list in the new script. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
pushed a commit
that referenced
this pull request
Aug 11, 2026
Stacked on ci/one-linux-dependency-list. Two questions about the Linux artifact that nothing has been answering, and one comment that was about to become false. `check-appimage-libraries.sh`, on every pull request. strip-appimage.sh proves its six libraries are gone afterwards; that is "we removed what we meant to", not "six is still the right number". What decides the right number is not in this repository -- `tauri build` fetches linuxdeploy-plugin-gtk from the tip of someone else's branch on every run, so the set copied into the AppDir can change with no commit here, no pull request and no notification. The script intersects what is bundled with the AppImage project's own excludelist and requires the result to equal the strip list exactly, in both directions. It reads that list out of strip-appimage.sh rather than restating it. It runs on the pull request build because that AppImage is the un-stripped one, which for this question is the right artifact rather than a worse one. It only became comparable when #580 moved this job to the release's Ubuntu. `smoke-appimage.sh`, on the release, after the re-sign and before the upload. strip-appimage.sh said a CI smoke test cannot catch this defect because the runner's Mesa is the one the libraries came from -- true of the runner, and only of the runner. A container is another distribution's userspace on the same kernel, which is a host that can disagree. The comment now says so. Liveness is not the check. #499 records that the GTK shell survives while WebKit's WebProcess aborts behind a blank window, so both defects this exists to catch would have passed a "is it still running" test. It greps for the abort, and keeps the liveness check as the backstop for a reworded one. Both scripts also run on pull requests, after a strip, and that is the point rather than thoroughness: smoke-appimage.sh would otherwise reach the release path having never run anywhere, and strip-appimage.sh has never run outside a release -- it failed in two of the three v2.7.2 release attempts. Roughly three minutes on a twelve-minute job. Also, one line in dependabot.yml: the github-actions ecosystem covers `uses:` and not `runs-on:`, so nothing proposes ubuntu-24.04 -> 26.04 and nobody should assume something is watching. Three assertions, each checked by mutation and each failing alone: smoking before the strip, dropping the release smoke, and restating the library list in the new script. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
pushed a commit
that referenced
this pull request
Aug 11, 2026
Stacked on ci/one-linux-dependency-list. Two questions about the Linux artifact that nothing has been answering, and one comment that was about to become false. `check-appimage-libraries.sh`, on every pull request. strip-appimage.sh proves its six libraries are gone afterwards; that is "we removed what we meant to", not "six is still the right number". What decides the right number is not in this repository -- `tauri build` fetches linuxdeploy-plugin-gtk from the tip of someone else's branch on every run, so the set copied into the AppDir can change with no commit here, no pull request and no notification. The script intersects what is bundled with the AppImage project's own excludelist and requires the result to equal the strip list exactly, in both directions. It reads that list out of strip-appimage.sh rather than restating it. It runs on the pull request build because that AppImage is the un-stripped one, which for this question is the right artifact rather than a worse one. It only became comparable when #580 moved this job to the release's Ubuntu. `smoke-appimage.sh`, on the release, after the re-sign and before the upload. strip-appimage.sh said a CI smoke test cannot catch this defect because the runner's Mesa is the one the libraries came from -- true of the runner, and only of the runner. A container is another distribution's userspace on the same kernel, which is a host that can disagree. The comment now says so. Liveness is not the check. #499 records that the GTK shell survives while WebKit's WebProcess aborts behind a blank window, so both defects this exists to catch would have passed a "is it still running" test. It greps for the abort, and keeps the liveness check as the backstop for a reworded one. Both scripts also run on pull requests, after a strip, and that is the point rather than thoroughness: smoke-appimage.sh would otherwise reach the release path having never run anywhere, and strip-appimage.sh has never run outside a release -- it failed in two of the three v2.7.2 release attempts. Roughly three minutes on a twelve-minute job. Also, one line in dependabot.yml: the github-actions ecosystem covers `uses:` and not `runs-on:`, so nothing proposes ubuntu-24.04 -> 26.04 and nobody should assume something is watching. Three assertions, each checked by mutation and each failing alone: smoking before the strip, dropping the release smoke, and restating the library list in the new script. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
pushed a commit
that referenced
this pull request
Aug 11, 2026
…ing on it
The check's first run found something real and then drew the wrong conclusion
from it. Run 31493065830, on the pull request build:
Bundled libraries the excludelist says must come from the host:
libwayland-client.so.0
strip-appimage.sh removes a library nothing bundles any more:
libwayland-cursor.so.0 libwayland-egl.so.1 libwayland-server.so.0
libxcb-render.so.0 libxcb-shm.so.0
Those five are deliberate. #499 named libwayland-client.so.0 as necessary and
sufficient and added five more that "belong to the host graphics stack for the
same reason and are on the same excludelist" -- prophylaxis against the plugin
starting to bundle them, and `rm -f` costs nothing when they are absent. A build
not bundling them is not a defect, so it is a notice now. A seventh appearing is
still an error, which is the direction that matters.
Worth printing, though, because the two builds disagree and nobody knew. In the
release, `rm -v` reported all six removed in both v2.7.2 and v2.7.3 -- they were
all there. On the pull request's shorter package list, only one is. So the two
jobs have been producing different AppImages, and #581's package prune will
change what a release bundles rather than being the no-op its own message
claimed. The direction is right -- fewer host-coupled libraries is the goal --
but "no behaviour change" was verified against "it builds and produces three
bundles", not against the contents.
Which difference does it, the package list or the linuxdeploy build.yml
pre-downloads, is not isolated. Once both jobs install the same packages, the
next release's `removed` lines say.
The assertion holding the list to one home now exempts comments, the same way
the Ubuntu one does: the new comment names a library while explaining what was
measured, and tripped it. 979 pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
pushed a commit
that referenced
this pull request
Aug 11, 2026
Stacked on ci/one-linux-dependency-list. Two questions about the Linux artifact that nothing has been answering, and one comment that was about to become false. `check-appimage-libraries.sh`, on every pull request. strip-appimage.sh proves its six libraries are gone afterwards; that is "we removed what we meant to", not "six is still the right number". What decides the right number is not in this repository -- `tauri build` fetches linuxdeploy-plugin-gtk from the tip of someone else's branch on every run, so the set copied into the AppDir can change with no commit here, no pull request and no notification. The script intersects what is bundled with the AppImage project's own excludelist and requires the result to equal the strip list exactly, in both directions. It reads that list out of strip-appimage.sh rather than restating it. It runs on the pull request build because that AppImage is the un-stripped one, which for this question is the right artifact rather than a worse one. It only became comparable when #580 moved this job to the release's Ubuntu. `smoke-appimage.sh`, on the release, after the re-sign and before the upload. strip-appimage.sh said a CI smoke test cannot catch this defect because the runner's Mesa is the one the libraries came from -- true of the runner, and only of the runner. A container is another distribution's userspace on the same kernel, which is a host that can disagree. The comment now says so. Liveness is not the check. #499 records that the GTK shell survives while WebKit's WebProcess aborts behind a blank window, so both defects this exists to catch would have passed a "is it still running" test. It greps for the abort, and keeps the liveness check as the backstop for a reworded one. Both scripts also run on pull requests, after a strip, and that is the point rather than thoroughness: smoke-appimage.sh would otherwise reach the release path having never run anywhere, and strip-appimage.sh has never run outside a release -- it failed in two of the three v2.7.2 release attempts. Roughly three minutes on a twelve-minute job. Also, one line in dependabot.yml: the github-actions ecosystem covers `uses:` and not `runs-on:`, so nothing proposes ubuntu-24.04 -> 26.04 and nobody should assume something is watching. Three assertions, each checked by mutation and each failing alone: smoking before the strip, dropping the release smoke, and restating the library list in the new script. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
pushed a commit
that referenced
this pull request
Aug 11, 2026
…ing on it
The check's first run found something real and then drew the wrong conclusion
from it. Run 31493065830, on the pull request build:
Bundled libraries the excludelist says must come from the host:
libwayland-client.so.0
strip-appimage.sh removes a library nothing bundles any more:
libwayland-cursor.so.0 libwayland-egl.so.1 libwayland-server.so.0
libxcb-render.so.0 libxcb-shm.so.0
Those five are deliberate. #499 named libwayland-client.so.0 as necessary and
sufficient and added five more that "belong to the host graphics stack for the
same reason and are on the same excludelist" -- prophylaxis against the plugin
starting to bundle them, and `rm -f` costs nothing when they are absent. A build
not bundling them is not a defect, so it is a notice now. A seventh appearing is
still an error, which is the direction that matters.
Worth printing, though, because the two builds disagree and nobody knew. In the
release, `rm -v` reported all six removed in both v2.7.2 and v2.7.3 -- they were
all there. On the pull request's shorter package list, only one is. So the two
jobs have been producing different AppImages, and #581's package prune will
change what a release bundles rather than being the no-op its own message
claimed. The direction is right -- fewer host-coupled libraries is the goal --
but "no behaviour change" was verified against "it builds and produces three
bundles", not against the contents.
Which difference does it, the package list or the linuxdeploy build.yml
pre-downloads, is not isolated. Once both jobs install the same packages, the
next release's `removed` lines say.
The assertion holding the list to one home now exempts comments, the same way
the Ubuntu one does: the new comment names a library while explaining what was
measured, and tripped it. 979 pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
pushed a commit
that referenced
this pull request
Aug 11, 2026
Stacked on ci/one-linux-dependency-list. Two questions about the Linux artifact that nothing has been answering, and one comment that was about to become false. `check-appimage-libraries.sh`, on every pull request. strip-appimage.sh proves its six libraries are gone afterwards; that is "we removed what we meant to", not "six is still the right number". What decides the right number is not in this repository -- `tauri build` fetches linuxdeploy-plugin-gtk from the tip of someone else's branch on every run, so the set copied into the AppDir can change with no commit here, no pull request and no notification. The script intersects what is bundled with the AppImage project's own excludelist and requires the result to equal the strip list exactly, in both directions. It reads that list out of strip-appimage.sh rather than restating it. It runs on the pull request build because that AppImage is the un-stripped one, which for this question is the right artifact rather than a worse one. It only became comparable when #580 moved this job to the release's Ubuntu. `smoke-appimage.sh`, on the release, after the re-sign and before the upload. strip-appimage.sh said a CI smoke test cannot catch this defect because the runner's Mesa is the one the libraries came from -- true of the runner, and only of the runner. A container is another distribution's userspace on the same kernel, which is a host that can disagree. The comment now says so. Liveness is not the check. #499 records that the GTK shell survives while WebKit's WebProcess aborts behind a blank window, so both defects this exists to catch would have passed a "is it still running" test. It greps for the abort, and keeps the liveness check as the backstop for a reworded one. Both scripts also run on pull requests, after a strip, and that is the point rather than thoroughness: smoke-appimage.sh would otherwise reach the release path having never run anywhere, and strip-appimage.sh has never run outside a release -- it failed in two of the three v2.7.2 release attempts. Roughly three minutes on a twelve-minute job. Also, one line in dependabot.yml: the github-actions ecosystem covers `uses:` and not `runs-on:`, so nothing proposes ubuntu-24.04 -> 26.04 and nobody should assume something is watching. Three assertions, each checked by mutation and each failing alone: smoking before the strip, dropping the release smoke, and restating the library list in the new script. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
pushed a commit
that referenced
this pull request
Aug 11, 2026
…ing on it
The check's first run found something real and then drew the wrong conclusion
from it. Run 31493065830, on the pull request build:
Bundled libraries the excludelist says must come from the host:
libwayland-client.so.0
strip-appimage.sh removes a library nothing bundles any more:
libwayland-cursor.so.0 libwayland-egl.so.1 libwayland-server.so.0
libxcb-render.so.0 libxcb-shm.so.0
Those five are deliberate. #499 named libwayland-client.so.0 as necessary and
sufficient and added five more that "belong to the host graphics stack for the
same reason and are on the same excludelist" -- prophylaxis against the plugin
starting to bundle them, and `rm -f` costs nothing when they are absent. A build
not bundling them is not a defect, so it is a notice now. A seventh appearing is
still an error, which is the direction that matters.
Worth printing, though, because the two builds disagree and nobody knew. In the
release, `rm -v` reported all six removed in both v2.7.2 and v2.7.3 -- they were
all there. On the pull request's shorter package list, only one is. So the two
jobs have been producing different AppImages, and #581's package prune will
change what a release bundles rather than being the no-op its own message
claimed. The direction is right -- fewer host-coupled libraries is the goal --
but "no behaviour change" was verified against "it builds and produces three
bundles", not against the contents.
Which difference does it, the package list or the linuxdeploy build.yml
pre-downloads, is not isolated. Once both jobs install the same packages, the
next release's `removed` lines say.
The assertion holding the list to one home now exempts comments, the same way
the Ubuntu one does: the new comment names a library while explaining what was
measured, and tripped it. 979 pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PathGao
added a commit
that referenced
this pull request
Aug 11, 2026
* ci: ask the AppImage what it bundles, and whether it starts Stacked on ci/one-linux-dependency-list. Two questions about the Linux artifact that nothing has been answering, and one comment that was about to become false. `check-appimage-libraries.sh`, on every pull request. strip-appimage.sh proves its six libraries are gone afterwards; that is "we removed what we meant to", not "six is still the right number". What decides the right number is not in this repository -- `tauri build` fetches linuxdeploy-plugin-gtk from the tip of someone else's branch on every run, so the set copied into the AppDir can change with no commit here, no pull request and no notification. The script intersects what is bundled with the AppImage project's own excludelist and requires the result to equal the strip list exactly, in both directions. It reads that list out of strip-appimage.sh rather than restating it. It runs on the pull request build because that AppImage is the un-stripped one, which for this question is the right artifact rather than a worse one. It only became comparable when #580 moved this job to the release's Ubuntu. `smoke-appimage.sh`, on the release, after the re-sign and before the upload. strip-appimage.sh said a CI smoke test cannot catch this defect because the runner's Mesa is the one the libraries came from -- true of the runner, and only of the runner. A container is another distribution's userspace on the same kernel, which is a host that can disagree. The comment now says so. Liveness is not the check. #499 records that the GTK shell survives while WebKit's WebProcess aborts behind a blank window, so both defects this exists to catch would have passed a "is it still running" test. It greps for the abort, and keeps the liveness check as the backstop for a reworded one. Both scripts also run on pull requests, after a strip, and that is the point rather than thoroughness: smoke-appimage.sh would otherwise reach the release path having never run anywhere, and strip-appimage.sh has never run outside a release -- it failed in two of the three v2.7.2 release attempts. Roughly three minutes on a twelve-minute job. Also, one line in dependabot.yml: the github-actions ecosystem covers `uses:` and not `runs-on:`, so nothing proposes ubuntu-24.04 -> 26.04 and nobody should assume something is watching. Three assertions, each checked by mutation and each failing alone: smoking before the strip, dropping the release smoke, and restating the library list in the new script. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(ci): report the unbundled half of the strip list rather than failing on it The check's first run found something real and then drew the wrong conclusion from it. Run 31493065830, on the pull request build: Bundled libraries the excludelist says must come from the host: libwayland-client.so.0 strip-appimage.sh removes a library nothing bundles any more: libwayland-cursor.so.0 libwayland-egl.so.1 libwayland-server.so.0 libxcb-render.so.0 libxcb-shm.so.0 Those five are deliberate. #499 named libwayland-client.so.0 as necessary and sufficient and added five more that "belong to the host graphics stack for the same reason and are on the same excludelist" -- prophylaxis against the plugin starting to bundle them, and `rm -f` costs nothing when they are absent. A build not bundling them is not a defect, so it is a notice now. A seventh appearing is still an error, which is the direction that matters. Worth printing, though, because the two builds disagree and nobody knew. In the release, `rm -v` reported all six removed in both v2.7.2 and v2.7.3 -- they were all there. On the pull request's shorter package list, only one is. So the two jobs have been producing different AppImages, and #581's package prune will change what a release bundles rather than being the no-op its own message claimed. The direction is right -- fewer host-coupled libraries is the goal -- but "no behaviour change" was verified against "it builds and produces three bundles", not against the contents. Which difference does it, the package list or the linuxdeploy build.yml pre-downloads, is not isolated. Once both jobs install the same packages, the next release's `removed` lines say. The assertion holding the list to one home now exempts comments, the same way the Ubuntu one does: the new comment names a library while explaining what was measured, and tripped it. 979 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(ci): give the smoke container the libraries an AppImage expects from a host First real run, on the pull request rather than on a release: host graphics stack: mesa 1:26.1.6-1 Markpad: error while loading shared libraries: libfontconfig.so.1 exit 127 Not the defect this is looking for. An AppImage deliberately does not carry libfontconfig -- it is on the same excludelist as the six strip-appimage.sh removes, and for the same reason -- so it expects the host to have it. A bare archlinux container is not a desktop and does not. fontconfig and a font go in beside xvfb and mesa. And a missing host library now says so, instead of being reported as the app quitting early: the two look identical at exit 127 and mean opposite things. Worth recording that the container's mesa is 1:26.1.6-1, which is the version #498 was reported on. The environment is the failing case, not an approximation of it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(ci): ask the smoke container for GTK, not for one library per round Naming the host's libraries individually is a round of CI each. Run 31494803899 wanted libfontconfig.so.1; with that added, run 31497012965 wanted libfribidi.so.0. There is no reason to think that was the last one. The set is not arbitrary. An AppImage deliberately does not carry these -- they are on the same excludelist as the six strip-appimage.sh removes, and for the same reason -- so what it needs from a host is GTK's own dependency closure, which is exactly what a machine that can run a GTK application has. Installing gtk3 asks for all of it in one go. --------- Co-authored-by: PathGao <gaoyanbo@gaoyanbodeMacBook-Air.local> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The Linux AppImage still fails to display on hosts whose Mesa is newer than the ubuntu-24.04 build runner (#498). The window opens but stays blank white and WebKit's WebProcess aborts:
This is a second, independent cause behind #182, distinct from the WebKitGTK version pin fixed in #463. The published v2.7.1 AppImage bundles WebKitGTK 2.52.3 (confirmed by dlopening the bundled library and reading
webkit_get_*_version), so #463 landed correctly.Root cause
The AppImage bundles
libwayland-client.so.0from the ubuntu-24.04 runner. On a host with a newer libwayland/Mesa, that older bundled copy shadows the host one, and hostlibEGLthen failseglGetPlatformDisplaywithEGL_BAD_PARAMETER.Single-library isolation (extract the published AppImage, move one library out of the AppDir at a time, run): removing only
libwayland-client.so.0is necessary and sufficient to make the full UI render. It is on the AppImageCommunity/pkg2appimage excludelist precisely because it must come from the host.The failure is backend independent (the default forced
GDK_BACKEND=x11andGDK_BACKEND=waylandboth abort), andWEBKIT_DISABLE_DMABUF_RENDERER,WEBKIT_DISABLE_COMPOSITING_MODE, andLIBGL_ALWAYS_SOFTWAREdo not help.Change
A step after "Build Linux" that extracts the AppImage, removes the six host-coupled graphics libraries (
libwayland-*,libxcb-render/shm), repacks with appimagetool, and re-signs.The re-sign is required:
tauri buildalready signed the pre-strip file, and the updater verifies the downloaded AppImage against the signature inlatest.json, so the repacked artifact must be signed again. Both the upload step and thelatest.jsonjob read the regenerated.AppImage.sig.--appimage-extractandappimagetool --appimage-extract-and-runare used so no libfuse2 is needed on the runner.Validation
Validated locally on Arch (Intel, Mesa 26.1.6): extracting the published v2.7.1 AppImage, removing the libs, repacking, and launching the result renders the full UI with no EGL error (before/after screenshots on #498). The signer invocation and the no-FUSE extract/repack were exercised directly.
Not validated, and it cannot be before a release: the step running on the ubuntu-24.04 runner with the real signing secret. As with #463, the resulting AppImage is the first artifact that can be tested, so it is worth confirming the published file starts before announcing.
Why the #463 verification did not catch this
My #463 check rebuilt on Arch, so linuxdeploy bundled Arch's
libwayland-client(matching the host) and could not reproduce the mismatch. The ubuntu-24.04 release build bundles the older one. Two independent bugs: the version pin (#463) and this libwayland bundling.Addresses #498 and the remaining AppImage failure in #182. Leaving both open so they can be closed after the published 2.7.x AppImage is confirmed to start.