yonluandClaude Opus 5
cad3d1339b
Neither packaging/arch/PKGBUILD nor the Homebrew formula had been run since Phase 1, and both were still calling v2's CLI: `wails3 build` takes -tags, -obfuscated and -garbleargs and nothing else, so `-clean -trimpath -ldflags` fails at the flag parser. Both also installed from build/bin/, which is v2's output path — v3 writes to bin/, and build/ is tracked build assets now. Three more things the tree needs that neither recipe had. The tasks invoke `wails3` by bare name, so scripts/toolbin has to be on PATH or the build dies at its first sub-task. `wails3 build` has no -ldflags at all, and build:native computes BUILD_FLAGS in its own vars: so a CLI variable cannot override it — LDFLAGS_EXTRA is appended inside the production -ldflags string instead, on linux and darwin alike, empty by default so make build-dev/build-prod are unchanged. And bundling is a separate step from building: `task build` produces a bare binary on both platforms, so the formula's macOS path runs `task package`. The build assets were the scaffold's, not this app's. Info.plist named CFBundleExecutable `yjref` and com.example.yjref, nfpm packaged ./bin/yjref, the .desktop template said "A yjref application" — an .app built from that plist would not have launched. They generate from build/config.yml, whose info block had never been filled from wails.json either; `wails3 task common:update:build-assets` is the fix. nfpm's homepage and license are not derived from it and are set by hand, which is noted in place, and the refresh regenerates build/ios and build/android, which this repo does not carry. arch-package.yml's pacman list moves to webkitgtk-6.0/gtk4 to match the PKGBUILD's depends(): makepkg installs nothing itself, so a mismatch fails at link time rather than at check time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UDCbcCZQepnpSQYJ6SxxZm
YellowJacket Arch package
This directory holds the PKGBUILD and desktop entry used to build the
Arch Linux package. CI builds it on every push to main (see
.gitea/workflows/arch-package.yml) and publishes it to the Gitea Arch
package registry, from which pacman can install it directly.
Installing from the registry
The registry is public — no login required.
1. Import the registry signing key (one-time)
Gitea signs both the repo database and the packages with a per-instance GPG key. Import its public key and locally sign it so pacman will verify signatures:
curl -fSs "https://git.ljones.me/api/packages/yonlu/arch/repository.key" \
| sudo pacman-key --add -
sudo pacman-key --lsign-key C061B6267CF9D820
- Key ID:
C061B6267CF9D820— UID(Arch Registry), RSA 2048. - This is a public key; publishing it is expected. The private key stays on the Gitea server.
- The key is per-Gitea-instance, so you import it once regardless of how
many registries on
git.ljones.meyou use.
2. Add the repo to /etc/pacman.conf
Append to the end of the file:
[stable]
SigLevel = Required
Server = https://git.ljones.me/api/packages/yonlu/arch/stable/$arch
$archis a literal pacman variable (expands tox86_64); leave it as-is.[stable]matches theARCH_REPOvalue in the publish workflow.
3. Sync and install
sudo pacman -Sy yellowjacket
Alternative: skip signature verification
If you'd rather not import the key, set SigLevel = Never instead of
SigLevel = Required in the repo block above. Simpler, but you lose
tamper detection, and the signing-key path is only a one-time step — so
this is not recommended.
Notes
- Only the runtime package is published; the
-debugpackage makepkg produces (detached symbols) is skipped by the workflow. - Package versions come from
pkgver()in the PKGBUILD, derived from git (e.g.1.3.0.r173.g4ae5ffc-1), so every push tomainyields a new version. - Repo priority: if another configured repo ever provides a package named
yellowjacket, the repo listed first inpacman.confwins. Force a source explicitly withsudo pacman -S stable/yellowjacket.