* Move the dev sudo grant lifecycle into omarchy-settings-dev
The hardened omarchy-sudo-passwordless publishes a grant only when its revocation hook is installed and no package transaction has left /run/omarchy-sudo-passwordless-package-removing behind. The hook sets that marker before every settings upgrade, and the settings scriptlets are what clear it, so shipping the hook alone let the first grant work and then refused every grant after the next update until a reboot.
omarchy-settings-dev now ships the command, omarchy-security-functions, the boot cleanup rule and the hook together, with the scriptlets from #257 that revoke before the package changes and clear the marker once no grant remains. omarchy-dev stops shipping the two helpers and requires the settings release that does: without it omarchy-update has no library to source.
Co-authored-by: Afonso Oliveira <afonso.oliveira707@gmail.com>
* Check that settings-dev registers the scriptlet the lifecycle test exercises
The lifecycle test reads the .install file directly, so it kept passing with the recipe's install= line gone, which is the one change that would strand the hook's marker again.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Keep omarchy-dev's settings dependency unversioned
The dev pair builds each package on its own against the published edge repository, in the PR build and in publish alike, so omarchy-dev cannot require a settings-dev release that only this change produces: the floor failed both omarchy-dev builds on this PR, and an exact pkgver match would fail the same way on every upstream pin bump. Nothing needs it. The upstream watch moves both pins together, publish stops the run before anything is published when one package fails, and a new settings-dev over an old runtime is refused on the files they would both own.
* Refuse settings-dev releases that predate the grant helper move
With the dependency unversioned, a new omarchy-dev could still install over a settings-dev that is held back or not yet published, removing omarchy-security-functions from both, and omarchy-update cannot start without it. A versioned conflict refuses that pairing at install time without constraining the per-package builds, which resolve only depends.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Require the security library as a capability instead of a version floor
The conflict named the last settings-dev release without the helpers, a version that moves with every upstream pin bump and settings-only pkgrel while this change waits to merge, and a rebase that kept a stale floor still passed the tests while the published release slipped past it. omarchy-settings-dev now provides omarchy-security-functions and omarchy-dev's package() requires it. makepkg checks only the top-level depends before building, so the per-package builds still resolve against the published repository, while pacman refuses a runtime without a settings release that ships the library, and pulls that release in when only the runtime is asked for.
Co-Authored-By: Codex XHigh <noreply@openai.com>
---------
Co-authored-by: Spencer Bull <spencer@omarchy.org>
Co-authored-by: Afonso Oliveira <afonso.oliveira707@gmail.com>
Co-authored-by: Codex XHigh <noreply@openai.com>
omarchy and omarchy-dev pulled iwd in on every aarch64 machine. Only
Apple Silicon uses it, and omarchy-mac depends on it already. On other
ARM laptops its 80-iwd.link renames the Wi-Fi interface to wlan0 at the
next boot, so a saved NetworkManager connection tied to the old name
stops connecting.
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