ci: install the six Linux packages a pull request proved the build needs by PathGao · Pull Request #581 · sftwrdotdev/Markpad

PathGao · 2026-08-11T12:02:07Z

Stacked on #580. Base is ci/one-linux-runner; merge #580 first and this retargets to master. The diff shown is against #580.

build.yml asked apt for sixteen packages. test_build.yml asks for six, compiles the same tree and bundles the same three formats. Nothing said which was right — build.yml only runs on workflow_dispatch, so its apt list is the one part of the Linux build no pull request has ever exercised.

The ten

Six apt installs anyway. libwebkit2gtk-4.1-dev depends on libwebkit2gtk-4.1-0, libjavascriptcoregtk-4.1-dev, gir1.2-webkit2-4.1 and libgtk-3-dev; those pull libjavascriptcoregtk-4.1-0 and gir1.2-javascriptcoregtk-4.1 behind them. Naming them changes nothing.

Four libxcb *-dev packages and xdg-utils appear in no Tauri v2 Debian/Ubuntu prerequisite list:

sudo apt install libwebkit2gtk-4.1-dev build-essential curl wget file \
  libxdo-dev libssl-dev libayatana-appindicator3-dev librsvg2-dev

The evidence is not that reasoning

Run 31487547674, on ubuntu-24.04 — the release's own runner, after #580 moves test_build.yml there:

install dependencies (ubuntu only) :: success     ← the six
run cargo test                     :: success
Build app                          :: success
Upload artifacts                   :: success

app-bundle-linux   101 MB          ← bundle/deb/*.deb + bundle/rpm/*.rpm
                                     + bundle/appimage/*.AppImage

The three Linux formats a release ships were built with these six and nothing else, on the same Ubuntu, by a pull request.

One list, not a shorter one

That is the part worth keeping. Both workflows compile and bundle, so any difference between their lists is a release depending on something nothing tested — which is exactly what this was. The assertion holds them equal, and holds test.yml to the same list minus the bundlers, since it compiles but never bundles.

Checked by mutation in both directions:

add xdg-utils to build.yml     → ✖ a release installs the dependencies a pull request proved it can build with
remove librsvg2-dev from test.yml → ✖ (same assertion, the test.yml half)

Each fails alone. npm test — 977 pass.

The risk, stated

build.yml cannot be run outside a release, so this list is exercised for the first time when a release is cut. What makes that acceptable rather than reckless:

the six are the list a pull request just built all three bundles with, on the release's runner, not a list reasoned down from sixteen;
a wrong answer fails at apt-get or at cargo, before any asset is uploaded, on a release that is still a draft nobody can install;
after ci: compile pull requests on the Ubuntu the release compiles on #580 the two workflows share a runner, so from here on every pull request exercises the release's dependency list on the release's Ubuntu.

Reverting is this commit alone.

🤖 Generated with Claude Code

Stacked on ci/one-linux-runner. build.yml asked apt for sixteen packages; test_build.yml asks for six and compiles the same tree and bundles the same three formats. Nothing said which was right, because build.yml only runs on workflow_dispatch -- its apt list is the one part of the Linux build no pull request has ever exercised. Six of the ten extras apt installs regardless: libwebkit2gtk-4.1-dev depends on libwebkit2gtk-4.1-0, libjavascriptcoregtk-4.1-dev, gir1.2-webkit2-4.1 and libgtk-3-dev, and those pull libjavascriptcoregtk-4.1-0 and gir1.2-javascriptcoregtk-4.1 behind them. The other four are libxcb1-dev, libxcb-render0-dev, libxcb-shape0-dev and libxcb-xfixes0-dev, plus xdg-utils -- none of which appear in Tauri v2's Debian/Ubuntu prerequisites. The evidence is not that reasoning. Run 31487547674 built the .deb, the .rpm and the AppImage on ubuntu-24.04 -- the release's own runner, after the change below this one -- with these six and nothing else, and uploaded 101 MB of bundles. Making the lists identical is the point rather than making one shorter. Both workflows compile and bundle, so any difference between them is a release depending on something nothing tested. An assertion holds them together, and holds test.yml to the same list minus the bundlers, since it compiles but never bundles. Checked by mutation in both directions: adding a package to build.yml fails it, and removing one from test.yml fails it. 977 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…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>

…ter (#583) * ci: key the cargo cache on the runner image, not just on "Linux" Moving the Ubuntu would otherwise have restored the wrong cache silently. rust-cache's key ends in `runner.os`, which is `Linux` for both 22.04 and 24.04. Read off two runs of the same job, one per Ubuntu, it is identical: v0-rust-linux-build-test-Linux-x64-e8b3ee54-a2c94f3a ^^^^^ the image is not in here So master's next run on 24.04 would have restored a target/ built on 22.04 as a full match. Cargo fingerprints do not track system libraries: webkit2gtk-sys's build script probes the distribution's headers and caches the result, and that result would have been reused against a different distribution's, with nothing to notice. `$ImageOS` is what the runner calls its own image -- ubuntu22, ubuntu24, macos15. Keying on it invalidates on this move and on the next one, including the ones `macos-latest` and `windows-latest` make with no commit at all. Read from the runner rather than written down, so it is not a fourth thing to remember. The previous keys become unreachable and expire on the usual seven-day-unused or least-recently-used path. One extra set of ~4.45 GB until they do, against the 10 GB limit that no longer holds the npm caches. Checked by mutation: dropping IMAGE_OS from the key fails the new assertion and nothing else. The first attempt at that check reported a pass because bash ate the `${{ }}` before python saw it and the file was never mutated -- the same shape as `continue-on-error`, a check that cannot fail looking exactly like a check that passed. Redone with the edit asserted before the run. 976 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * ci: install the six Linux packages a pull request proved the build needs (#581) Stacked on ci/one-linux-runner. build.yml asked apt for sixteen packages; test_build.yml asks for six and compiles the same tree and bundles the same three formats. Nothing said which was right, because build.yml only runs on workflow_dispatch -- its apt list is the one part of the Linux build no pull request has ever exercised. Six of the ten extras apt installs regardless: libwebkit2gtk-4.1-dev depends on libwebkit2gtk-4.1-0, libjavascriptcoregtk-4.1-dev, gir1.2-webkit2-4.1 and libgtk-3-dev, and those pull libjavascriptcoregtk-4.1-0 and gir1.2-javascriptcoregtk-4.1 behind them. The other four are libxcb1-dev, libxcb-render0-dev, libxcb-shape0-dev and libxcb-xfixes0-dev, plus xdg-utils -- none of which appear in Tauri v2's Debian/Ubuntu prerequisites. The evidence is not that reasoning. Run 31487547674 built the .deb, the .rpm and the AppImage on ubuntu-24.04 -- the release's own runner, after the change below this one -- with these six and nothing else, and uploaded 101 MB of bundles. Making the lists identical is the point rather than making one shorter. Both workflows compile and bundle, so any difference between them is a release depending on something nothing tested. An assertion holds them together, and holds test.yml to the same list minus the bundlers, since it compiles but never bundles. Checked by mutation in both directions: adding a package to build.yml fails it, and removing one from test.yml fails it. 977 pass. Co-authored-by: PathGao <gaoyanbo@gaoyanbodeMacBook-Air.local> 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>

…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>

* 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>

PathGao merged commit acce4c9 into ci/one-linux-runner Aug 11, 2026
4 checks passed

PathGao deleted the ci/one-linux-dependency-list branch August 11, 2026 12:26

PathGao mentioned this pull request Aug 11, 2026

ci: restore the cache key and the package list that did not reach master #583

Merged

Navigation Menu

Uh oh!

Uh oh!

ci: install the six Linux packages a pull request proved the build needs - #581

ci: install the six Linux packages a pull request proved the build needs#581
PathGao merged 1 commit into
ci/one-linux-runnerfrom
ci/one-linux-dependency-list

PathGao commented Aug 11, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

PathGao commented Aug 11, 2026

The ten

The evidence is not that reasoning

One list, not a shorter one

The risk, stated

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant