tmog-bin: follow tmog.org's versioned downloads and update to 1.0.0

TMOG 1.0.0 moved the site under /rtm/ and publishes each Linux tarball
under a versioned name with a .sha256 sidecar. The versionless
/downloads/TMOG-Task-Manager-Linux-x86_64.tar.gz path the hook fetched
now returns 404, so every upstream sync since 1.0.0 has failed.

Point source=() at the versioned tarball and have the hook read the
version from /rtm/version.txt and the checksum from the sidecar, which
drops the 8 MB download and the directory-name check the mutable URL
needed.

pkgbuilds/tmog-bin/.omarchy/README.md

@@ -36,36 +36,33 @@ public distribution", so the terms themselves may still move.
 Nothing in the packaging depends on the answer -- it is a question for the
 publisher, and it is recorded here so it is not mistaken for settled.
 
-## The versionless download URL
+## Where releases come from
 
-Every TMOG release is served from one path:
+Since 1.0.0 the site lives under `/rtm/`, and each Linux artifact is published
+under a versioned name with a `.sha256` sidecar beside it:
 
 ```text
-https://tmog.org/downloads/TMOG-Task-Manager-Linux-x86_64.tar.gz
+https://tmog.org/rtm/version.txt
+https://tmog.org/rtm/downloads/TaskManagerOG-<version>-linux-x86_64.tar.gz
+https://tmog.org/rtm/downloads/TaskManagerOG-<version>-linux-x86_64.tar.gz.sha256
 ```
 
-Nothing in it identifies a version, and `downloads/release.json` -- the manifest
-the macOS updater verifies -- describes the DMG only. So the Linux side has no
-manifest to read a checksum out of, and `.omarchy/upstream.sh` computes one from
-the artifact. That download is 7.9 MB and happens only when `/version.txt`
-reports something other than the checked-in `pkgver`, so the six-hourly check
-normally costs a single small request.
+`downloads/release.json` -- the manifest the macOS updater verifies -- still
+describes the DMG only, so `.omarchy/upstream.sh` reads the version from
+`version.txt` and the checksum from the sidecar, and checks that the sidecar
+names the tarball it was asked about. The check costs two small requests and
+never downloads the tarball.
 
-Two details follow from the path being mutable:
+Up to 0.1.1 every release was served from one versionless path,
+`/downloads/TMOG-Task-Manager-Linux-x86_64.tar.gz`, and the hook downloaded it
+to compute a checksum. That path now returns 404, which is what broke the
+upstream sync when 1.0.0 shipped.
 
-- **The `?v=<version>-free` query string** in `source=()` is upstream's own
-  cache key; tmog.org appends it to its Linux download links for the same
-  reason, so a CDN holding an older object under this path cannot answer for a
-  new release.
-- **The hook checks the tarball's top-level directory**, which upstream names
-  `TaskManagerOG-<version>-linux-x86_64`. It is the only evidence available that
-  the bytes that arrived are the release `/version.txt` announced. On a mismatch
-  the hook reports no update and leaves the package alone, which is the right
-  answer whether the cause is a half-published release or a stale object.
-
-`sha256sums` is reported under the key `any` rather than `x86_64`: upstream
-publishes no aarch64 build, so the package has one plain `source=()` array, and
-`any` is `bin/sync-upstream`'s name for the unsuffixed checksum array.
+`sha256sums` is reported under the key `any` rather than `x86_64`: the package
+builds x86_64 alone, so it has one plain `source=()` array, and `any` is
+`bin/sync-upstream`'s name for the unsuffixed checksum array. Upstream began
+publishing an aarch64 tarball (with its own sidecar) at 1.0.0; adding it means
+moving to `source_x86_64`/`source_aarch64` and reporting both keys.
 
 ## Testing
 

pkgbuilds/tmog-bin/.omarchy/upstream.sh

@@ -1,19 +1,12 @@
 #!/bin/bash
 # TMOG publishes no manifest for its Linux builds -- release.json describes the
-# macOS DMG only -- so the version comes from /version.txt and the checksum has
-# to be computed from the artifact itself. That is 8 MB, and only when the
-# version has actually moved, so the six-hourly check normally costs one tiny
-# request.
-#
-# The download path carries no version, which makes it worth proving that what
-# arrived is what was announced: the tarball's top-level directory is named for
-# the release, and a mismatch means the object served is not the one
-# /version.txt describes. Reporting no update leaves the checked-in package
-# alone and lets the next run try again, which is the right answer whether the
-# cause is a half-published release or a stale CDN object.
+# macOS DMG only -- so the version comes from /rtm/version.txt. Each Linux
+# artifact is published under a versioned name with a `<artifact>.sha256`
+# sidecar beside it, and that sidecar is the checksum reported here, so the
+# six-hourly check costs two tiny requests and never the tarball itself.
 set -euo pipefail
 
-BASE_URL="https://tmog.org"
+BASE_URL="https://tmog.org/rtm"
 
 current=$(grep -m1 '^pkgver=' PKGBUILD | cut -d= -f2- | tr -d "\"'")
 
@@ -28,27 +21,22 @@ if [[ $version == "$current" ]]; then
   exit 0
 fi
 
-tarball=$(mktemp)
-trap 'rm -f "$tarball"' EXIT
-
-curl -fsSL -o "$tarball" \
-  "$BASE_URL/downloads/TMOG-Task-Manager-Linux-x86_64.tar.gz?v=${version}-free"
-
-# Every entry is listed rather than just the first: `head -1` would close the
-# pipe under `tar` and take the whole hook down with SIGPIPE, and reading them
-# all also catches a tarball that unpacks more than one top-level directory.
-expected_dir="TaskManagerOG-${version}-linux-x86_64"
-served_dir=$(tar tzf "$tarball" | cut -d/ -f1 | sort -u)
-if [[ $served_dir != "$expected_dir" ]]; then
-  echo "Download holds $served_dir, but /version.txt announced $version; skipping" >&2
-  echo '{}'
-  exit 0
+# The sidecar names the file it describes; insisting on that name catches a
+# sidecar left over from another release or architecture. A failed download or
+# a file without a trailing newline leaves `read` short, which the check below
+# reports rather than letting set -e exit silently.
+artifact="TaskManagerOG-${version}-linux-x86_64.tar.gz"
+sha256="" name=""
+read -r sha256 name < <(curl -fsSL "$BASE_URL/downloads/$artifact.sha256") || true
+if [[ ! $sha256 =~ ^[0-9a-f]{64}$ || ${name#\*} != "$artifact" ]]; then
+  echo "Unusable checksum for $artifact: '$sha256 $name'" >&2
+  exit 1
 fi
 
 # "any" is bin/sync-upstream's name for the unsuffixed sha256sums array, which
-# is the one this package has: upstream publishes x86_64 alone, so there is a
-# single plain source=() rather than per-architecture arrays.
+# is the one this package has: it builds x86_64 alone, so there is a single
+# plain source=() rather than per-architecture arrays.
 jq -n \
   --arg pkgver "$version" \
-  --arg sha256 "$(sha256sum "$tarball" | cut -d' ' -f1)" \
+  --arg sha256 "$sha256" \
   '{pkgver: $pkgver, sha256sums: {any: [$sha256]}}'

pkgbuilds/tmog-bin/PKGBUILD

@@ -5,13 +5,12 @@
 # is 55 MB of bundled Qt -- the same binary, minus a second copy of what
 # Omarchy already installs.
 #
-# The download URL carries no version: tmog.org serves every release from the
-# same path. .omarchy/upstream.sh rewrites the pkgver and sha256 below when
-# /version.txt moves, and checks the tarball's own directory name to be sure
-# the mutable URL really served the version it announced.
+# .omarchy/upstream.sh rewrites the pkgver and sha256 below when
+# /rtm/version.txt moves, taking the checksum from the .sha256 sidecar tmog.org
+# publishes beside each versioned tarball.
 
 pkgname=tmog-bin
-pkgver=0.1.1
+pkgver=1.0.0
 pkgrel=1
 pkgdesc="Native system monitor and task manager"
 arch=('x86_64')
@@ -39,11 +38,8 @@ options=('!debug' '!strip')
 
 _srcdir="TaskManagerOG-${pkgver}-linux-x86_64"
 
-# The query string is upstream's own cache key -- tmog.org appends it to the
-# Linux links for the same reason, so a CDN holding an older object under this
-# mutable path cannot answer for a new release.
-source=("${pkgname}-${pkgver}.tar.gz::${url}downloads/TMOG-Task-Manager-Linux-x86_64.tar.gz?v=${pkgver}-free")
-sha256sums=('4d319d3d27f513e83801daeec8eb64cb78ddec1f6483bbe90d57d11e607af39d')
+source=("${pkgname}-${pkgver}.tar.gz::${url}rtm/downloads/${_srcdir}.tar.gz")
+sha256sums=('a147c613d4a6f5c0ec16eaf52965593de523f9f0231e09c241460cc63352f325')
 
 package() {
   cd "${_srcdir}"