Part of triple-c#34's third ask ("I would like to also have an Arch/CachyOS native version as well"), split out from the Wayland crash fix (#38) since it's an unrelated feature, not a bug fix.
packaging/arch/PKGBUILD — a -bin AUR package repackaging the same .debbuild-app.yml already produces. No Rust/Node toolchain needed to install it; the user gets exactly the binary the project ships and tests.
.gitea/workflows/publish-aur-package.yml — publishes it. Given a version (or "latest"), finds that release's real Linux asset on GitHub, downloads it, computes real checksums, renders the PKGBUILD, validates the result with makepkg/namcap inside a real Arch container, and pushes to AUR. workflow_dispatch only — automatic triggers on release/push have the same race problem that killed sync-release.yml in #32 (this repo's releases are assembled by build-app.yml across three separate platform jobs; there's no single automatic event that fires only once the Linux .deb this needs actually exists).
Verified against a real release (v0.4.14), not Tauri's generic docs — I don't have a real Arch/Wayland machine to test the installed app on, but I could and did verify the packaging itself for real:
Downloaded the actual .deb asset and confirmed the real filename shape (Triple-C_X.Y.Z_amd64.deb — capitalized, matching productName verbatim, not the lowercase Cargo binary name a naive guess would produce).
ldd'd the actual binary inside a real Arch container to ground-truth depends — dropped pango (already pulled in transitively by gtk3) and libayatana-appindicator (never linked at all; this app has no tray icon or menu) from an earlier draft that had them because Tauri's own docs list them generically.
Ran a real makepkg build, namcap lint, and pacman -U install cycle. namcap caught a real issue this way — no license file under /usr/share/licenses/triple-c-bin/ — now fixed by fetching LICENSE alongside the .deb. Re-verified clean after the fix.
Deliberately broke the PKGBUILD to confirm the workflow's namcap-error-detection step actually fires on a real regression, not just passes silently on the happy path.
Requires a repo secret this workflow cannot set up itself: AUR_SSH_PRIVATE_KEY, from an AUR account that has already created (or been given co-maintainer access to) triple-c-bin — both are one-time manual steps on aur.archlinux.org that nothing here can automate. Until that secret exists, the workflow fails loudly at the push step rather than silently doing nothing. See packaging/arch/README.md for the full maintenance flow.
Contributes to #34 (does not close it — the "links not opening" item is still open, pending more diagnosis).
Test plan
YAML syntax validated
PKGBUILD validated end-to-end against a real release: real makepkg build, real namcap lint (clean), real pacman -U install, binary confirmed to start and fail only at GTK display init (expected in a headless container, not a missing-library error)
The render step's Python substitution logic tested against real discovered data (real filename, real sha256sums) with a working makepkg build as final proof
The namcap error-detection logic tested against both a passing and a deliberately-broken PKGBUILD
Cannot test the actual "Push to AUR" step — no AUR account/secret exists yet — nor the real GUI on real Arch/Wayland hardware
## Summary
Part of triple-c#34's third ask ("I would like to also have an Arch/CachyOS native version as well"), split out from the Wayland crash fix (#38) since it's an unrelated feature, not a bug fix.
- `packaging/arch/PKGBUILD` — a `-bin` AUR package repackaging the same `.deb` `build-app.yml` already produces. No Rust/Node toolchain needed to install it; the user gets exactly the binary the project ships and tests.
- `.gitea/workflows/publish-aur-package.yml` — publishes it. Given a version (or "latest"), finds that release's real Linux asset on GitHub, downloads it, computes real checksums, renders the PKGBUILD, validates the result with `makepkg`/`namcap` inside a real Arch container, and pushes to AUR. `workflow_dispatch` only — automatic triggers on `release`/`push` have the same race problem that killed `sync-release.yml` in #32 (this repo's releases are assembled by `build-app.yml` across three separate platform jobs; there's no single automatic event that fires only once the Linux `.deb` this needs actually exists).
**Verified against a real release (v0.4.14), not Tauri's generic docs** — I don't have a real Arch/Wayland machine to test the installed app on, but I could and did verify the packaging itself for real:
- Downloaded the actual `.deb` asset and confirmed the real filename shape (`Triple-C_X.Y.Z_amd64.deb` — capitalized, matching `productName` verbatim, not the lowercase Cargo binary name a naive guess would produce).
- `ldd`'d the actual binary inside a real Arch container to ground-truth `depends` — dropped `pango` (already pulled in transitively by `gtk3`) and `libayatana-appindicator` (never linked at all; this app has no tray icon or menu) from an earlier draft that had them because Tauri's own docs list them generically.
- Ran a real `makepkg` build, `namcap` lint, and `pacman -U` install cycle. `namcap` caught a real issue this way — no license file under `/usr/share/licenses/triple-c-bin/` — now fixed by fetching `LICENSE` alongside the `.deb`. Re-verified clean after the fix.
- Deliberately broke the PKGBUILD to confirm the workflow's namcap-error-detection step actually fires on a real regression, not just passes silently on the happy path.
**Requires a repo secret this workflow cannot set up itself**: `AUR_SSH_PRIVATE_KEY`, from an AUR account that has already created (or been given co-maintainer access to) `triple-c-bin` — both are one-time manual steps on aur.archlinux.org that nothing here can automate. Until that secret exists, the workflow fails loudly at the push step rather than silently doing nothing. See `packaging/arch/README.md` for the full maintenance flow.
Contributes to #34 (does not close it — the "links not opening" item is still open, pending more diagnosis).
## Test plan
- [x] YAML syntax validated
- [x] PKGBUILD validated end-to-end against a real release: real `makepkg` build, real `namcap` lint (clean), real `pacman -U` install, binary confirmed to start and fail only at GTK display init (expected in a headless container, not a missing-library error)
- [x] The render step's Python substitution logic tested against real discovered data (real filename, real sha256sums) with a working `makepkg` build as final proof
- [x] The namcap error-detection logic tested against both a passing and a deliberately-broken PKGBUILD
- [ ] Cannot test the actual "Push to AUR" step — no AUR account/secret exists yet — nor the real GUI on real Arch/Wayland hardware
Part of triple-c#34's third ask ("I would like to also have an
Arch/CachyOS native version as well"), addressed separately from the
Wayland crash fix (fix/wayland-webkit-egl-crash) since it's an unrelated
feature, not a bug.
packaging/arch/PKGBUILD is a "-bin" AUR package repackaging the same .deb
build-app.yml already produces — no Rust/Node toolchain needed to install
it, and the user gets exactly the binary the project ships and tests.
Verified end to end against a real release (v0.4.14) rather than going by
Tauri's generic docs: downloaded the actual .deb, ldd'd the actual binary
to ground-truth `depends` (dropped `pango` and `libayatana-appindicator`
from an earlier draft — the first is already pulled in transitively by
gtk3, the second was never linked at all since this app has no tray icon
or menu), and ran a real makepkg/namcap/pacman -U cycle. namcap caught a
real issue this way (missing license file under
/usr/share/licenses/triple-c-bin/), now fixed by fetching LICENSE
alongside the .deb.
.gitea/workflows/publish-aur-package.yml does the actual publishing:
given a version (or "latest"), it finds that release's real Linux asset
on GitHub, downloads it, computes real checksums, renders the PKGBUILD
template, validates the result with makepkg and namcap inside a real
Arch container, and pushes to AUR. workflow_dispatch only, deliberately —
the same reasoning that killed sync-release.yml in triple-c#32 (releases
are assembled by build-app.yml across three separate platform jobs, so
there's no single automatic event that fires only once the Linux .deb
this needs actually exists) applies here too.
Requires a repo secret this workflow cannot set up itself:
AUR_SSH_PRIVATE_KEY, from an AUR account that has already created (or
been given co-maintainer access to) triple-c-bin — both one-time manual
steps on aur.archlinux.org. Until that secret exists, the workflow fails
loudly at the push step rather than silently doing nothing. See
packaging/arch/README.md for the full maintenance flow.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
A review found the "Validate with makepkg and namcap" step's bind mount
(docker run -v "$PWD/rendered:/work") would very likely fail on Gitea's
own act_runner: a containerized job's $PWD isn't a path the daemon's host
can resolve, so the mount would silently attach an empty directory
instead of failing loudly — the same class of problem noted elsewhere for
this exact environment. Switched to docker create + docker cp (in and
back out) + docker start -a, the pattern already validated locally, which
works regardless of where the daemon actually lives.
Also found and fixed, most severe first:
- The namcap error gate (`grep -q "^[a-zA-Z0-9_-]*bin E:"`) only matched
one of namcap's two line shapes for reporting an error
("triple-c-bin E: ...") and missed the other ("PKGBUILD
(triple-c-bin) E: ...") entirely — confirmed by reproducing both against
a real namcap run. The PKGBUILD-level half of the safety net was dead.
Replaced with a plain `grep -q " E: "`, confirmed to match both real
shapes (and a split-package variant) and nothing else.
- package()'s `ar x "Triple-C_${pkgver}_amd64.deb"` named the asset
literally, defeating the whole point of the resolve step discovering
the real filename from the release instead of assuming a pattern — a
future Tauri bundler naming change would still break here with an
opaque error. Changed to `ar x ./*_amd64.deb`, which `source=()` already
guarantees matches exactly one file.
- `pacman -Sy` before installing packages is the canonical Arch partial-
upgrade footgun; changed to `pacman -Syu --noconfirm --needed`.
- `${{ inputs.version }}` was interpolated directly into a shell step
instead of routed through `env:`, unlike every other step in the file.
- `git push origin master` assumes the local branch name after cloning a
brand-new (not-yet-created) AUR repo's empty state is `master`, which
depends on the runner's own `init.defaultBranch` if the server sends no
symref. `git push origin HEAD:master` is unambiguous either way.
- The private key was written with a plain redirect then chmod'd after,
leaving a window where it's world-readable; now created at its final
mode first via `install -m 600 /dev/null`. Added `-o IdentitiesOnly=yes`
so a runner ssh-agent can't offer a different key first.
- Added GH_PAT auth to the api.github.com calls, matching every other
workflow in this repo, to avoid the unauthenticated 60/hour rate limit.
- Fixed two comments: the `options` comment credited `!debug` for
suppressing the empty debug-package directory, when it's actually
`!strip` doing that (verified in a real build); and documented in the
README that a hand-edit made directly in the AUR repo is silently
reverted by the next dispatch, since every run renders fresh from this
repo's template.
All of the above re-verified with the same real end-to-end methodology as
the original commit: real makepkg build, real namcap lint (clean), and
the exact updated docker create/cp/start sequence run against a live
container.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
jknapp
merged commit 81b1cfba09 into main2026-08-27 18:30:01 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
Part of triple-c#34's third ask ("I would like to also have an Arch/CachyOS native version as well"), split out from the Wayland crash fix (#38) since it's an unrelated feature, not a bug fix.
packaging/arch/PKGBUILD— a-binAUR package repackaging the same.debbuild-app.ymlalready produces. No Rust/Node toolchain needed to install it; the user gets exactly the binary the project ships and tests..gitea/workflows/publish-aur-package.yml— publishes it. Given a version (or "latest"), finds that release's real Linux asset on GitHub, downloads it, computes real checksums, renders the PKGBUILD, validates the result withmakepkg/namcapinside a real Arch container, and pushes to AUR.workflow_dispatchonly — automatic triggers onrelease/pushhave the same race problem that killedsync-release.ymlin #32 (this repo's releases are assembled bybuild-app.ymlacross three separate platform jobs; there's no single automatic event that fires only once the Linux.debthis needs actually exists).Verified against a real release (v0.4.14), not Tauri's generic docs — I don't have a real Arch/Wayland machine to test the installed app on, but I could and did verify the packaging itself for real:
.debasset and confirmed the real filename shape (Triple-C_X.Y.Z_amd64.deb— capitalized, matchingproductNameverbatim, not the lowercase Cargo binary name a naive guess would produce).ldd'd the actual binary inside a real Arch container to ground-truthdepends— droppedpango(already pulled in transitively bygtk3) andlibayatana-appindicator(never linked at all; this app has no tray icon or menu) from an earlier draft that had them because Tauri's own docs list them generically.makepkgbuild,namcaplint, andpacman -Uinstall cycle.namcapcaught a real issue this way — no license file under/usr/share/licenses/triple-c-bin/— now fixed by fetchingLICENSEalongside the.deb. Re-verified clean after the fix.Requires a repo secret this workflow cannot set up itself:
AUR_SSH_PRIVATE_KEY, from an AUR account that has already created (or been given co-maintainer access to)triple-c-bin— both are one-time manual steps on aur.archlinux.org that nothing here can automate. Until that secret exists, the workflow fails loudly at the push step rather than silently doing nothing. Seepackaging/arch/README.mdfor the full maintenance flow.Contributes to #34 (does not close it — the "links not opening" item is still open, pending more diagnosis).
Test plan
makepkgbuild, realnamcaplint (clean), realpacman -Uinstall, binary confirmed to start and fail only at GTK display init (expected in a headless container, not a missing-library error)makepkgbuild as final proofPart of triple-c#34's third ask ("I would like to also have an Arch/CachyOS native version as well"), addressed separately from the Wayland crash fix (fix/wayland-webkit-egl-crash) since it's an unrelated feature, not a bug. packaging/arch/PKGBUILD is a "-bin" AUR package repackaging the same .deb build-app.yml already produces — no Rust/Node toolchain needed to install it, and the user gets exactly the binary the project ships and tests. Verified end to end against a real release (v0.4.14) rather than going by Tauri's generic docs: downloaded the actual .deb, ldd'd the actual binary to ground-truth `depends` (dropped `pango` and `libayatana-appindicator` from an earlier draft — the first is already pulled in transitively by gtk3, the second was never linked at all since this app has no tray icon or menu), and ran a real makepkg/namcap/pacman -U cycle. namcap caught a real issue this way (missing license file under /usr/share/licenses/triple-c-bin/), now fixed by fetching LICENSE alongside the .deb. .gitea/workflows/publish-aur-package.yml does the actual publishing: given a version (or "latest"), it finds that release's real Linux asset on GitHub, downloads it, computes real checksums, renders the PKGBUILD template, validates the result with makepkg and namcap inside a real Arch container, and pushes to AUR. workflow_dispatch only, deliberately — the same reasoning that killed sync-release.yml in triple-c#32 (releases are assembled by build-app.yml across three separate platform jobs, so there's no single automatic event that fires only once the Linux .deb this needs actually exists) applies here too. Requires a repo secret this workflow cannot set up itself: AUR_SSH_PRIVATE_KEY, from an AUR account that has already created (or been given co-maintainer access to) triple-c-bin — both one-time manual steps on aur.archlinux.org. Until that secret exists, the workflow fails loudly at the push step rather than silently doing nothing. See packaging/arch/README.md for the full maintenance flow. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZA review found the "Validate with makepkg and namcap" step's bind mount (docker run -v "$PWD/rendered:/work") would very likely fail on Gitea's own act_runner: a containerized job's $PWD isn't a path the daemon's host can resolve, so the mount would silently attach an empty directory instead of failing loudly — the same class of problem noted elsewhere for this exact environment. Switched to docker create + docker cp (in and back out) + docker start -a, the pattern already validated locally, which works regardless of where the daemon actually lives. Also found and fixed, most severe first: - The namcap error gate (`grep -q "^[a-zA-Z0-9_-]*bin E:"`) only matched one of namcap's two line shapes for reporting an error ("triple-c-bin E: ...") and missed the other ("PKGBUILD (triple-c-bin) E: ...") entirely — confirmed by reproducing both against a real namcap run. The PKGBUILD-level half of the safety net was dead. Replaced with a plain `grep -q " E: "`, confirmed to match both real shapes (and a split-package variant) and nothing else. - package()'s `ar x "Triple-C_${pkgver}_amd64.deb"` named the asset literally, defeating the whole point of the resolve step discovering the real filename from the release instead of assuming a pattern — a future Tauri bundler naming change would still break here with an opaque error. Changed to `ar x ./*_amd64.deb`, which `source=()` already guarantees matches exactly one file. - `pacman -Sy` before installing packages is the canonical Arch partial- upgrade footgun; changed to `pacman -Syu --noconfirm --needed`. - `${{ inputs.version }}` was interpolated directly into a shell step instead of routed through `env:`, unlike every other step in the file. - `git push origin master` assumes the local branch name after cloning a brand-new (not-yet-created) AUR repo's empty state is `master`, which depends on the runner's own `init.defaultBranch` if the server sends no symref. `git push origin HEAD:master` is unambiguous either way. - The private key was written with a plain redirect then chmod'd after, leaving a window where it's world-readable; now created at its final mode first via `install -m 600 /dev/null`. Added `-o IdentitiesOnly=yes` so a runner ssh-agent can't offer a different key first. - Added GH_PAT auth to the api.github.com calls, matching every other workflow in this repo, to avoid the unauthenticated 60/hour rate limit. - Fixed two comments: the `options` comment credited `!debug` for suppressing the empty debug-package directory, when it's actually `!strip` doing that (verified in a real build); and documented in the README that a hand-edit made directly in the AUR repo is silently reverted by the next dispatch, since every run renders fresh from this repo's template. All of the above re-verified with the same real end-to-end methodology as the original commit: real makepkg build, real namcap lint (clean), and the exact updated docker create/cp/start sequence run against a live container. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ