The first pins (quattro ee8ebf6, omasnap eb22bfe) date from 2026-09-21.
Edge has since published omarchy-dev from quattro 7b336b1 through a
manual rebuild, so merging the old pin would ship older code under a
higher version. Moved with the tracker's own code:
bin/sync-upstream --lane auto-merge (BYPASS_MIN_RELEASE_AGE=1)
Since publishing moved to CI on merge, a package whose PKGBUILD never
changes while its source moves was never rebuilt: omarchy-dev and
omarchy-settings-dev followed quattro through "#branch=" and a pkgver()
function, and nothing in this repository changed when quattro did. The
host timers that used to notice are off, so edge fell days behind.
The rule now: no git source without a commit or tag pin
(tests/pinned-sources.sh, run in CI). A package that has to follow a
branch declares a git_branch upstream watch, and the pin moves through
the same PR/build/publish path as every other version bump.
Watch (helpers/upstream-watch.py)
git_branch gains tag_pattern: the newest release tag in the pinned
commit's own history, exposed as {tag}/{version}/{distance}, so a
branch build is versioned <tag>.r<n>.g<sha>, above the release it
follows and below the next one. One blobless clone per branch per
run, shared by every package on it. min_release_age selects the
newest commit older than the window, so a push burst builds once.
Lane (helpers/package-metadata.sh, bin/sync-upstream --lane)
"auto_merge": true moves a package from the reviewed 6-hourly sync
PR to the unattended lane. Packages pinned from the same branch move
together: a failure on one restores the others and fails the group,
so the dev pair can never ship from two quattro commits.
Tracker (.github/workflows/track-branches.yml)
Every two hours: pin, open one PR with a GitHub App token, enable
auto-merge. Branch protection still gates the merge on result,
self-tests and build-isolation. A tip that fails to build stays an
open red PR until the next tick supersedes it. The App is required:
a PR opened with GITHUB_TOKEN has its checks held for approval and
its auto-merge would not fire publish.yml.
The reviewed workflows (sync-upstream, sync-rebuilds) open their PRs
with the same App so their builds start without a maintainer clicking
"Approve workflows to run"; without the App they fall back to
GITHUB_TOKEN and behave as before.
Recipes
The dev pair pins _commit and a real sha256sum, keeps the OMARCHY_SRC
override, and drops pkgver(). Its r-number stays the branch's total
commit count because the published history used it and pacman must
never see the version go down. omasnap-git is new: omacom/omasnap
main, versioned <tag>.r<distance>.g<sha>, provides/conflicts omasnap.
The Omarchy payload is architecture-independent, but the package is not.
On x86_64 omarchy pulls the Limine + mkinitcpio hook + Snapper boot stack;
on Apple Silicon the system boots through m1n1 + GRUB from the Asahi
packages on Arch Linux ARM's kernel, so that stack does not apply, and
Wi-Fi on the Broadcom parts needs the iwd backend. The shipped /etc tree
differs too: mkinitcpio reads every file under /etc/mkinitcpio.conf.d/,
so shipping omarchy_hooks.conf on aarch64 injects the Limine hooks into
the Asahi kernel's initramfs, and the zram/zswap/oomd drop-ins and the
zram-tuned vm.* sysctls belong to the x86_64 memory stack.
makepkg only honours depends_<arch> and optdepends_<arch> on
arch-specific packages, so arch=('any') becomes ('x86_64' 'aarch64').
backup=() has no arch-suffixed form, so the x86_64-only entries are
appended under CARCH and each of those paths is removed from the aarch64
package in package(). The x86_64 package keeps exactly the contents it
had; only its filename suffix changes.
The install scriptlet applies the hardened cups-files.conf on every
platform, then on Apple Silicon keeps the Arch Linux ARM system identity
(/etc/os-release stays the distribution's symlink) instead of the
etc-overrides. The -dev pair carries the same change so the pairs stay in
lockstep.
A package's .omarchy/package.json may now pin where it lives with
"channels": [...]. With the key present the package builds in each listed
channel except stable (stable is only fed by promotion); without it, today's
defaults hold (build for edge; fast-ring also builds stable directly).
package_moves_to_channel() is the advance/promote eligibility rule: a member
of the destination channel that is not built there natively.
The release pair (omarchy, omarchy-settings) is edge+rc+stable — edge stays
during the client-migration overlap window and drops later. The dev pair is
pinned to edge only.
ryanrhughes