* 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 enables omarchy-usb-authorization.service and
omarchy-thunderbolt-authorization.service from first-run, and the
Thunderbolt one from its setup command and a migration. The settings
packages left both only in /usr/share/omarchy/default/systemd/user, where
systemd does not look.
On edge the Thunderbolt migration (1790344599) therefore fails with "Unit
omarchy-thunderbolt-authorization.service does not exist" and every later
migration stays pending. First-run fails as well and enables none of its
units.
Install both in /usr/lib/systemd/user, wherever the source has them: the
4.0.4 release does not, so its package is unchanged.
omacom/omarchy#13362 (d0b94d98c) dropped the omarchy-hw-platform copy
omarchy-settings shipped beside its platform guard. Its 00-omarchy-hooks.conf
now asks the runtime's own detector on PATH, and keeps the busybox line where
there is none. The aarch64 settings recipes still refused any source whose
baseline names omarchy-hw-platform without that copy, so every aarch64 build
of quattro would fail once #13362 merges.
Both recipes drop that check. The copy is still installed when a source ships
the guard, as before. The test fixture follows #13362's current baseline, and
the split-layout test checks the package builds from it and ships no copy.
#638 gave omarchy-settings this and -dev was never ported, so edge, the only
channel aarch64 machines are qualified for, still stripped zram, oomd, zswap,
the sysctl tuning and USB autosuspend there: on Snapdragon, migration
1790328426 installs zram-generator, finds no dev-zram0.swap and completes
without zram. A source with default/settings-runtime-profile now gets the same
files, backup and optdepends on aarch64 as on x86_64, Thunderbolt drop-in
included, and its HOOKS files ship as they are. Older sources, including the
current quattro pin, keep today's aarch64 package. The platform guard and its
detector check stay aarch64-only (#691, #694). The keyboard backlight unit
first-run enables ships whenever the source has it, as in omarchy-settings.
tests/settings-runtime-profile.sh now runs both recipes. pkgrel 5 so the
recipe change builds; the payload from the current pin is unchanged.
The guard and its detector copy now ship on aarch64 only (#691), so the check that 00-omarchy-hooks.conf has its detector failed every x86_64 build from a source that carries the HOOKS baseline. x86_64 keeps the busybox line without a detector. Same scoping as omarchy-settings in #638.
No platform package is built for x86_64 and pacman refuses another architecture's package there, so x86 transactions gain nothing from the guard. The x86 HOOKS baseline keeps the busybox line without a detector, so the detector copy goes too. omarchy-settings gets the same change in #638.
omacom/omarchy#13362 sets HOOKS per platform inside 00-omarchy-hooks.conf,
with no column-0 HOOKS= line, so the aarch64 build failed on it; settings-dev
tracks quattro automatically and would break as soon as it lands. Wrap only a
single-line HOOKS=(...), refuse any other column-0 HOOKS=, then source the
shipped files onto a Mac line and a stock line: the Mac line must come through
unchanged and the stock one must not. Back up 00-omarchy-hooks.conf when it
ships, and refuse it without the omarchy-hw-platform copy it asks.
The test now uses the real v4.0.4 hooks file, #13362's two files and
omarchy-mac-boot's 90-94 fragments, and covers upgrades over a hand-restored
file.
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.
Apple Silicon Macs install the aarch64 package too, and an unconditional
HOOKS= line would replace their asahi hooks. Apply Omarchy's HOOKS line only
when the incoming hooks lack asahi, in whichever drop-in carries it, and
rebuild omarchy-settings (4.0.4-3) so existing installs get the fix.
Moving omarchy-hw-platform from omarchy to omarchy-settings loses the file
when the dev pair installs in separate transactions, since omarchy-dev does
not pin omarchy-settings-dev's version. Settings now installs a copy beside
the guard script and omarchy keeps its detector, so no file changes owner.
The settings package's platform guard runs omarchy-hw-platform before the
omarchy runtime is installed. omarchy leaves the detector out of its bin/
loop and settings ships it, with the /usr/share/omarchy/bin link the Apple
predicate and the CLI router use, whenever the source has it.
The guard hook and the script it runs install together from omarchy-settings,
so they are resident before the runtime and hardware packages. Conditional, so
builds from sources without them are unchanged.
Preserve the v4.0.4 source pin and checksum while retaining the settings package revision bump. Keep Jim Martin’s boot-configuration fix and original commit intact.
basecamp/omarchy#11653 added etc/udev/rules.d/60-omarchy-io-scheduler.rules. package() already ships the whole etc/ tree, so the rule lands on new installs with the next build; list it in backup= so pacman keeps a user's local edit of the rule across upgrades, like the other package-owned /etc drop-ins.
Claude-Session: https://claude.ai/code/session_01EqYNBv5cERVom2zox5epyE
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
The aarch64 packages removed etc/mkinitcpio.conf.d and
etc/limine-entry-tool.d wholesale. On an encrypted aarch64 install that boots
with Limine (DGX Spark, Snapdragon X), installing the published package
therefore drops omarchy_hooks.conf, HOOKS falls back to /etc/mkinitcpio.conf,
and the next kernel update builds an initramfs with no encrypt hook: the
machine hangs waiting for /dev/mapper/root with no prompt.
Ship both drop-in directories on aarch64 and remove only
thunderbolt_module.conf, whose module ARM kernels do not have. Keep the
Limine template and the snapper notifier autostart for the same reason. The
memory-stack removals (zram, oomd, zswap, USB autosuspend) are unchanged.
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