diet-guard/packaging/aur
Krzysztof kuhy Rudnicki fc9822b516
Some checks are pending
pre-commit / pre-commit (push) Waiting to run
Tests / test (3.10) (push) Waiting to run
Tests / test (3.11) (push) Waiting to run
Tests / test (3.12) (push) Waiting to run
release-apk / release (APK) (push) Waiting to run
packaging/aur: track the current release tag
Routine follow-up to the per-commit version bump: the clean vX.Y.Z tag moved,
so the template's pkgver follows. sha256sums stays 'SKIP' -- the tarball for a
tag contains this file, so the real hash can only be filled in by updpkgsums in
the AUR checkout after the tag exists.

Note this line is inherently a lagging indicator: publishing runs updpkgsums
against whatever tag is newest at that moment, so the AUR may be a release
ahead of what is written here. ~/utils/aur-publish/publish.sh resolves the tag
itself and does not read this value.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Aoa1nKWRrAbowz7Hfd3tgL
2026-08-10 07:18:53 +02:00
..
PKGBUILD packaging/aur: track the current release tag 2026-08-10 07:18:53 +02:00
README.md Add the real AUR PKGBUILD as packaging/aur 2026-08-09 22:56:01 +02:00

AUR packaging

PKGBUILD here is the source of truth for the diet-guard-app AUR package. The AUR checkout (~/aur/diet-guard-app) is a copy of this file plus a generated .SRCINFO.

Why the checksum can go stale

source= points at the GitHub tarball for tag v$pkgver, and sha256sums is the hash of that tarball. A tarball contains this very file, so the checksum for tag vX cannot be committed before vX is tagged. The copy here is therefore a template: after pushing a new tag, run updpkgsums in the AUR checkout to fill in the real hash, and copy the result back here.

Tagging hazard (read before tagging)

This repo has grafted upstream Flutter SDK history, so the local clone carries hundreds of tags (flutter-N.N-candidate.N, vN.N.N-N.N.pre, and a v1.16.3 that points at a 2020 [flutter_tools] commit) that do not belong to this app. The remote has only a handful.

  • Never run git push --tags here. It would publish all of them.
  • Always push one tag explicitly: git push origin v1.2.3.
  • Resolve the next free version with git ls-remote --tags origin, never with the local git tag.

v1.0.0 on the remote points at an older commit that predates the LICENSE, so the first packageable tag was v1.0.1.

Release flow

# 1. bump `version:` in app/pubspec.yaml, commit, push
# 2. tag and push the SINGLE tag
git tag v1.2.3 && git push origin v1.2.3

# 3. sync + checksum + build + verify
cp packaging/aur/PKGBUILD ~/aur/diet-guard-app/PKGBUILD
cd ~/aur/diet-guard-app
# bump pkgver to match the tag, then:
updpkgsums
makepkg -Cf
namcap ./*.pkg.tar.zst
sudo pacman -U ./diet-guard-app-*.pkg.tar.zst
diet-guard-app   # must print: diet_guard desktop serving on http://localhost:8732

# 4. publish
makepkg --printsrcinfo > .SRCINFO
git add PKGBUILD .SRCINFO && git commit && git push   # branch is `master`

Notes

  • The Flutter app lives in app/, so the tarball extracts as diet-guard-$pkgver/app/ while LICENSE sits at the repo root. build() and package() cd into the subdir; the license is installed from an absolute $srcdir path.
  • StartupWMClass is diet_guard_app (underscores) while the icon name is diet-guard-app (hyphens). They genuinely differ — the WM class must match what Chrome gets from the wrapper's --class flag.
  • install_arch.sh is deliberately not wired to this PKGBUILD. That script builds the working tree for local development; this one builds a downloaded release tarball. Merging them would destroy the dev loop.
  • options=('!strip') is load-bearing — see the comment in the PKGBUILD.
  • Building requires network access (pub get, plus a git fetch of the shared crdt_sync dependency). The tracked pubspec.lock pins what gets resolved.