5 Commits

Include renames

Author	SHA1	Message	Date
shadowdaoandClaude Opus 5	9fadfbc37a	Make the AppImage updatable, and drop the deb and rpm ... An AppImage manager can adopt the current build but never update it: the image carries no update information, which is the string that tells such a tool where to look for a newer one. It also carries no AppStream metadata, so a manager has nothing to show but a filename — appimagetool has been warning about that on every build — and linuxdeploy leaves `Categories=` empty, which files the app nowhere in a desktop menu. All three are fixed while the image is already unpacked for the wayland fix, so the cost is a few lines rather than a second pass. `unbundle-wayland-client.sh` is now `finalize-appimage.sh`, since it does more than unbundle. The update URL is a **fixed** `linux-latest` tag on the GitHub mirror, which is where updates are pulled from — deliberately not `releases/latest`. `latest` follows whichever release is newest, and the Gitea-to-GitHub backfill creates one GitHub release per Gitea tag, including the `-win` and `-mac` tags that carry no AppImage. A URL that can resolve to a release with no AppImage in it fails on users' machines and nowhere else. The output is named for that tag too, and that is not cosmetic: zsync records a *relative* filename which a client resolves against the .zsync URL it fetched, so a versioned name would send every client after the build it already has. Verified by reading the generated header — `Filename: Triple-C_x86_64 .AppImage` — and the image's own `.upd_info` section, which is where the tag actually lives. My first guard checked the .zsync for the tag and failed correctly, which is how that distinction got found rather than shipped. Range requests were confirmed against the mirror before building on them: 206 with a correct content-range, so updates are real deltas rather than an 85 MB re-download. The .deb and .rpm go. They are two more artifacts to build, publish and keep working for an audience already served by the one file that runs on every distribution, and neither could ever self-update — which is now the difference that matters. Older releases keep theirs. The Linux job passes `--bundles appimage` rather than changing `tauri.conf.json`, so macOS and Windows are untouched. Verified against the real 0.4.19 artifact: it repacks, the AppStream file and filled-in Categories land inside the image, the update string resolves to the fixed tag, and the wayland fallback still holds. Both publisher failure paths refuse rather than half-publishing — no token, and missing artifacts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm	2026-09-02 17:10:44 -07:00
shadowdaoandClaude Opus 5	7a5c0c1f13	Retire the Arch package, document AppImage desktop integration ... The `triple-c-bin` package was never on the AUR, so installing it meant downloading a file and running `pacman -U` — the same gesture as making an AppImage executable, for a second artifact to keep building. And being `workflow_dispatch`-only it reached 1 release in 28 (only v0.4.16 has a `.pkg.tar.zst`), while HOW-TO-USE.md told Arch and CachyOS users to download it from every release. A distribution channel that is absent 27 times out of 28 is worse than not promising one. `packaging/arch/` and `.gitea/workflows/publish-arch-package.yml` are preserved whole on `hold/arch-packaging`, the same way the disk panel and drag-out work were held rather than deleted. What would make an Arch package worth having is an AUR account and its SSH key as a repo secret — both one-time manual steps that never happened; the workflow's own header already said as much about its AUR push step. This also closes the gap that prompted the review: nothing validated the PKGBUILD until someone manually dispatched the workflow, making it the only packaging path with no CI coverage. Removing it removes the untested surface rather than adding a job to test something nobody installs. In its place, `scripts/install-appimage.sh` does what a package manager's install hooks would. An AppImage carries a `.desktop` entry and icons inside itself, but nothing on the host reads them, so it never appears in the app launcher. The script extracts the bundled icons into the user's icon theme and writes a launcher entry — no sudo, nothing outside `~/.local/share`, and the AppImage itself is never copied or moved. Two details it gets right on purpose: * The `Exec` line is rewritten, not copied. The bundled entry says `Exec=triple-c`, which resolves only inside the running AppImage's own mount — a verbatim copy gives a launcher entry that starts nothing. * Extraction uses `--appimage-extract`, which needs no FUSE, so the script works on a machine where *running* the AppImage would first need `fuse2` installed. That requirement is now documented too: Arch and CachyOS do not ship FUSE 2 by default. Verified against the real artifact — the AppImage from this repo's own preview-3a49a67 release: 4 icon sizes install, `desktop-file-validate` passes with no warnings, `--uninstall` leaves nothing behind, and shellcheck is clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ApLYH6ybHwQFkMCtKuHrrV	2026-08-28 13:11:26 -07:00
shadow-test	3c8296843f	Skip AUR for now — attach the built Arch package to the GitHub release ... Publishing to the AUR needs a maintainer AUR account and its SSH key registered as a secret here, neither of which exists yet. Rather than leave the workflow permanently failing at that last step, it now stops short of AUR and instead uploads the built .pkg.tar.zst to the same GitHub release it built from, as a plain downloadable asset (`pacman -U` to install). The AUR-push step is still in this file's git history if that setup happens later. Renamed publish-aur-package.yml -> publish-arch-package.yml to match. The render/validate steps are unchanged; new here is capturing the exact built package filename from inside the build container (makepkg is the only thing that actually knows it) and an upload step that follows the same create-or-reuse-release, strip-upload_url, POST-octet-stream pattern build-app.yml and backfill-releases.yml already use for GitHub assets, plus a delete-existing-asset-first step so a re-dispatch for an already-packaged version replaces rather than 422s. Verified with a real Docker run end to end: rendered a real PKGBUILD, built a real (synthetic) .deb through makepkg + namcap in an archlinux container, confirmed the container exits 0, and confirmed the exact package filename it captures (triple-c-bin-<version>-1-x86_64.pkg.tar.zst) round-trips out via docker cp intact.	2026-08-27 14:48:39 -07:00
shadow-testandClaude Sonnet 5	b3d07bda09	Fix real workflow bugs a review found: dead bind mount, blind error gate ... 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	2026-08-27 11:24:31 -07:00
shadow-testandClaude Sonnet 5	e025a7441a	Add a native Arch/CachyOS package via its own AUR publish workflow ... 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	2026-08-27 11:10:55 -07:00