GNU date accepts relative expressions like '2 days ago', which would let a
buggy hook fabricate a release age; the backstop now insists on an ISO 8601
timestamp before date parses it. The provider header now states, rather than
contradicts, the code's behavior for a feed with no stable releases: that is
a loud failure by design, while quarantined releases report no update.
An empty min_release_age string now maps to unparseable rather than absent,
so "min_release_age": "" fails validation instead of silently running
with a zero-second quarantine. The end-to-end fixtures extend the
checked-in pkgver (.90/.91) so the test keeps working at any future mise
version. A Tests workflow runs bin/sync-upstream self-test and
bin/omarchy-pkgs self-test on every PR in the Arch container, making the
proof machine-checked instead of author-supplied. The README package
metadata field list documents upstream and min_release_age.
The self-test now runs sync_package over the checked-in mise-bin package --
its real metadata and PKGBUILD, the full selection/validation/backstop/
rewrite/read-back path -- with only the two network fetches replaced by
mise-shaped fixtures, asserting the final PKGBUILD holds the quarantine-
cleared version, pkgrel 1, and both architecture checksums.
Review fixes: the release-row builder uses "" fallbacks instead of empty
so a malformed row cannot shift columns past the per-field checks, and
provider discovery now keys on the presence of an upstream declaration
rather than a well-formed one, with sync_package failing loudly on a
declaration it cannot use -- a malformed manifest can no longer silently
drop a package out of scheduled synchronization.
bin/sync-upstream self-test swaps the two network fetches in
helpers/upstream-github.sh for fixture readers and runs the production code
paths: fallback past a quarantined release, draft/prerelease filtering, the
deliberate bypass, unchanged-version and all-quarantined no-update paths,
unusable tags/timestamps and missing checksums failing the sync, {tag} and
{pkgver} asset templates with ./ and * manifest prefixes across both
architectures, the min_release_age backstop verdicts (now a testable
release_age_status function), the duration parser, and manifest validation.
Also fixes from the review: the duration parser forces base-10 arithmetic
(leading zeros no longer parse as octal) and bounds values to nine digits so
no suffix can overflow; jq // treating false as absent can no longer let
"min_release_age": false or "upstream": false slip through as unset; the
release feed page grew to the API maximum of 100 with the bounded search
documented; and the README package-metadata section documents the upstream
block, min_release_age, the bypass, and provider-versus-hook exclusivity.
After the quarantine moved into the manifest, all mise-bin's hook still knew
was data: the repository, the checksum manifest name, and the asset filename
patterns. That now lives in .omarchy/package.json as an upstream block --
"upstream": {
"github": "jdx/mise",
"checksums": "SHASUMS256.txt",
"assets": { "x86_64": "mise-{tag}-linux-x64.tar.xz", ... }
}
-- handled by helpers/upstream-github.sh inside bin/sync-upstream. The
provider walks the release feed (drafts/prereleases excluded), honors
min_release_age and BYPASS_MIN_RELEASE_AGE during selection, reports
published_at so the framework backstop still applies, fails closed on any
unreadable tag or timestamp, and skips the checksum fetch when the newest
qualifying release is already checked in.
upstream.sh remains the escape hatch for feeds that fit no convention
(openai-codex-desktop's Debian index, tmog's version.txt, t3code's
electron-builder manifest); declaring both is an error.
Move the hold from a mise-only hardcode to min_release_age in
.omarchy/package.json ("24h", "2d", or bare seconds), alongside source and
release_ring where package policy already lives. bin/sync-upstream exports
the window to every hook as MIN_RELEASE_AGE_SECONDS so a hook that can walk
its release feed selects the newest release that has cleared it, and
enforces it as a backstop: with a policy set, the hook must report
published_at, and a release younger than the window is treated as no
update. A hook that cannot prove the age fails the sync rather than
shipping unverified. BYPASS_MIN_RELEASE_AGE=1 replaces the package-specific
bypass for deliberate emergency updates; scheduled automation never sets it.
The mise hook keeps its release-list walk but reads the window from the
environment and reports published_at; the other upstream hooks are
untouched and unaffected until they opt in.
Gating on /releases/latest alone starves updates when mise's near-daily
cadence keeps the newest release perpetually inside the quarantine window:
today that left Omarchy on 2026.8.8 while 2026.8.11 had already aged past
24 hours. Walk the release list (drafts and prereleases excluded) and pick
the newest release, by vercmp, whose published_at is at least 24 hours old.
The quarantine guarantee is unchanged: nothing younger than the window ever
ships without the explicit MISE_BIN_BYPASS_RELEASE_AGE=1 bypass, and invalid
tags or timestamps still fail closed - now for every release in the feed,
plus a hard failure if the feed reports no stable releases at all.
Pin the official Linux .deb to Cursor stable 0.24.0 (commit 302d75da).
Upstream renamed the binary sand -> grok-bot and ships grok-bot icons
and a grokbot:// handler; keep a Wayland wrapper and /usr/bin/sand compat
symlink.
Linux still has no update feed. Leave pinning to update-pkgver.sh rather
than a sync-upstream hook, which cannot atomically rewrite _commit.
TMOG ships no source and no AUR package, so this repackages the vendor's
Linux tarball. That artifact is 7.9 MB against the system Qt, where the
AppImage is 55 MB carrying a second copy of the Qt the shell already
installs.
Every release is served from one versionless URL, so .omarchy/upstream.sh
reads /version.txt, computes the checksum from the artifact, and checks
the tarball's own directory name to confirm the mutable path really
served the version it announced.
The beta licence forbids public redistribution, so publishing this needs
the publisher's permission; .omarchy/README.md records that.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011K4ra2oZTtzUQZJ2kwP3io
Tidying the terminal agent's Hermes away only happened in the menu installer,
so `pacman -S hermes-desktop` on its own, or an install interrupted after the
package landed, left two Hermeses -- and by then the menu entry that would
have noticed is disabled, because we are installed.
Co-Authored-By: Codex XHigh <noreply@openai.com>
The package built from omacom-io/herdr, a fork pinned to a commit and versioned 0.8.0.r13. Its only divergence was three commits replaying an agent's CLI options when a session resumed, which upstream declined twice — from a contributor in herdrdev/herdr#2036 and from us in herdrdev/herdr#2614, closed in favour of an agent resume manifest meant to supersede it. Those three are dropped; every other commit the fork carried is in v0.8.2.
The fork also self-reported "0.8.0" while speaking wire protocol 20, which upstream's published 0.8.0 did not: it spoke 19. An official client attaching to an Omarchy host therefore saw a server claiming to be its own version yet refusing to talk to it, and offered to stop it without ever naming the protocol. That is omacom-io/omarchy-pkgs#161.
Upstream released v0.8.2 today, and it settles both halves. It carries protocol 20, and the stable manifest now publishes 0.8.2 at protocol 20, so an official client and this package agree. It also contains the five features Omarchy contributed after the v0.8.0 tag — configurable outer pane borders, direct pane resize keybindings, move tab keybind actions, centered tab labels and outer terminal window title sync — which is what made packaging the earlier release a regression rather than a return to upstream.
Because the build is now the release it claims to be, it needs no build-identity marking: HERDR_BUILD_CHANNEL and HERDR_BUILD_ID are gone, and the binary reports a bare 0.8.2. The package name is unchanged, so nothing needs a rename, a migration or a database removal to reach existing installs; 0.8.2-1 simply supersedes 0.8.0.r13-1.
🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh.
apply_pkgrel_override compares the checked-in pkgver against the incoming one to decide whether Omarchy's pkgrel metadata has gone stale, but read the two sides differently: previous_pkgver came from get_pkgbuild_field, which strips quotes, while current_pkgver was parsed again in place and kept them. A PKGBUILD writing pkgver='1.0' therefore compared unequal to itself, and the pkgrel metadata of an unchanged package was deleted on every sync.
spotify, rustdesk and limine-mkinitcpio-hook all quote pkgver. None carries pkgrel metadata today, so nothing has been losing a suffix, but rebuild_on writes exactly that metadata and would have had it thrown away on the next sync.
Reading through the same accessor rather than parsing a second time removes the divergence instead of correcting one side of it.
🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh.
Co-Authored-By: Codex XHigh <codex@openai.com>
A review at xhigh found several ways this command could report success while delivering nothing, which is the exact failure it exists to prevent.
A trigger named in rebuild_on but missing from rebuilt_against was never examined, because the comparison walked the record rather than the declared list. Adding a dependency to a package already opted in left that dependency untracked forever. The comparison now walks the declared triggers, so a name the record does not carry reads as changed.
That also retires the separate baseline path. Recording a package's triggers without bumping pkgrel certified a build nobody had checked: a package already broken by a release that moved before it opted in would be recorded as current and never rebuilt. Opting in now costs one rebuild, which is much the cheaper mistake.
A bumped version was only checked against the checked-in one. The floor is what users already have, so a checkout that had fallen behind the repository could be bumped to a version pacman orders below the package it means to replace, with the record advancing regardless. The published database is now the floor, and an unreadable one warns rather than blocks.
Metadata that did not parse dropped its package out of an unscoped run without a word, an unreadable rebuild_on being indistinguishable from an absent one. It is now reported and fails the run.
The workflow reads versions from mirror.omarchy.org, the mirror the x86_64 builder itself uses, rather than whichever mirror the container defaulted to. A mirror running ahead of the builder would record a version the build never linked against, and nothing re-fires once the record matches.
aarch64 stays uncovered and is documented as such: those builds resolve from Arch Linux ARM, one record cannot describe two architectures, and only x86_64 is published today.
bin/sync-rebuilds --self-test covers each of these against a throwaway repository root with pacman and curl stubbed.
🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh.
Co-Authored-By: Codex XHigh <codex@openai.com>
Arch shipped qt6-base 6.11.2-2 on 2026-08-20, and the published 0.3.0.r20.g28771c7-1, built against 6.11.1, stopped starting: undefined symbol _ZN23QUntypedPropertyBindingC1EP23QPropertyBindingPrivate, version Qt_6_PRIVATE_API. quickshell-check.hook caught it post-transaction, but detecting is all it does, so pacman logged the failure and omarchy-update-restart went on to restart a shell whose binary could no longer launch.
The git rev has not moved, so the rebuild only reaches anyone through a pkgrel bump. rebuild_on names the three Qt packages quickshell actually links against: qt6-base for Core, Gui, Widgets, Network, DBus and OpenGL, qt6-declarative for Quick and the Qml libraries, qt6-wayland for WaylandClient. rebuilt_against is seeded with the versions this rebuild will link against, so bin/sync-rebuilds starts from a correct baseline and fires on the next Qt release rather than repeating this one.
🤖 Generated by Opus 5 in Claude Code.
A package that links Qt private API has to be rebuilt whenever qt6-base moves, because Qt_6_PRIVATE_API symbols are not covered by the soname and pacman upgrades Qt out from under the installed binary while the dependency stays unversioned. Nothing here noticed. Both version gates ask whether the package's own source moved, and for a VCS package pinned to a commit that answer stays no through every Qt release.
Unlocking the build gate would not have been enough on its own. A rebuild that reuses the published version string produces a package pacman never offers anyone, so the trigger has to edit git and bump pkgrel, which is why it sits beside sync-aur and sync-upstream rather than inside check-versions or the builder. Once pkgrel moves, both existing gates already do the right thing untouched.
Packages opt in with rebuild_on in .omarchy/package.json. bin/sync-rebuilds records what each was last bumped for in rebuilt_against and compares that to core, extra and multilib, ignoring testing and kde-unstable because those are not what the builder links against. A package with no record yet is only recorded, never bumped: what its published build linked against is not knowable from here, so the first run establishes the baseline. For an AUR-synced package the bump is written as the dotted Omarchy pkgrel suffix in the metadata as well, since the next sync replaces the PKGBUILD wholesale and would otherwise drop it.
🤖 Generated by Opus 5 in Claude Code.
intel-lpmd, pinta and umu-launcher arrived together in the bulk AUR import of 2026-05-07, and all three have since been deleted from the AUR, which is what happens when Arch moves a package into its own repositories. extra now carries intel-lpmd 0.1.0-4 and pinta 3.1.2-2, and multilib carries umu-launcher 1.4.4-1, against the 0.1.0-2, 3.1.2-1 and 1.1.3-1.1 checked in here.
Nothing noticed because bin/sync-aur treats a missing AUR package as a warning rather than an error, so the sync has completed green every run since May while these three sat frozen.
They were never reachable in any case: pacman stops at the first repository carrying a name, and [omarchy] is ordered below core, extra and multilib, so every machine has been resolving the official builds. That also makes the umu-launcher patch here dead code -- it stripped the build down from the AUR's dependency list, but multilib's package is what actually gets installed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The fork carried three commits that replayed an agent's CLI options when Herdr resumed its session. Upstream declined that work twice — once from a contributor in #2036 and once from us in #2614, closed in favour of an agent resume manifest system that is meant to supersede it — so the fork was a permanent rebase treadmill for one feature, and it is dropped here.
Packaging the v0.8.0 release instead would have regressed more than the fork gained: configurable outer pane borders, direct pane resize keybindings, move tab keybind actions, centered tab labels and outer terminal window title sync all merged upstream after that tag, so the release predates five features Omarchy contributed. The package follows upstream master and takes the -git name that says so, replacing both herdr and omarchy-herdr.
Master's Cargo.toml reads 0.8.1, a release upstream cut and withdrew hours later, while the wire protocol is already 20 against the published release's 19. An unmarked build therefore self-reports a version that no release carries, which is how an official client came to insist on stopping an Omarchy host's server without saying why. HERDR_BUILD_CHANNEL and HERDR_BUILD_ID make it report 0.8.1-omarchy.<commit>. The channel is not "preview" because that gates is_preview(), which makes the stable updater treat every published release as installable and overwrite /usr/bin/herdr outside pacman.
pkgver() excludes the preview tags that sit on master between releases; describing without that returns a preview build id that pacman ranks below the version already shipped. It fails rather than falling back for the same reason: with no release tag reachable, every version it could invent sorts lower than what users already have.
Cross-architecture remote attach cannot bootstrap a helper for this build, because the stable manifest lists only published releases. That is true of any build from master, marked or not: an unmarked one asks the manifest for 0.8.1 and is told it does not exist.
🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh.
Co-Authored-By: Codex XHigh <codex@openai.com>
The entry comes from upstream's AppImage rather than a hand-written one, because that is what carries the t3code:// scheme handlers, and it arrives named "T3 Code (Alpha)" from electron-builder's productName. That name is stale: the app's own code calls it `legacyUserDataDirName` and has already moved its data to ~/.config/t3code, so the launcher was advertising an identity upstream has moved off.
Rewrite Name= alongside the Exec= rewrite already there. The scheme handlers, the MimeType line and the rest of upstream's entry are untouched.
pkgrel goes to 2 because 0.0.33-1 is already published, and a packaging-only change reaches an installed machine only through a new release.
🤖 Generated by Opus 5 in Claude Code.
Pairing the app with the mise CLI does not work, and pinning the app back to
the tag behind PyPI's release does not rescue it: v2026.7.20's desktop reaches
"backend is ready" and then hangs without ever opening a window, against its
own matching runtime. Only the newest app against a runtime built from its own
commit starts, which is the arrangement upstream ships.
So the package returns to the newest tag and the launcher sets
HERMES_DESKTOP_IGNORE_EXISTING, which keeps the app off whatever hermes is on
PATH -- on Omarchy that is the mise CLI installed for the terminal agent, a
different release, and the version gap is what produced the 401. The app
provisions ~/.hermes itself on first launch instead.
mise and uv are no longer dependencies, since the launcher no longer installs
anything; git and curl are, because the app's own bootstrap needs them.
Built from v2026.8.18 against the CLI on PyPI, the app never starts: it
resolves the CLI, launches the backend, and then fails its readiness probe
with 401 Unauthorized. The two have to agree on the dashboard session-token
handshake -- the app scrapes window.__HERMES_SESSION_TOKEN__ out of the served
HTML, and web_server.py falls back to a random token when it cannot agree, so
every probe after that is rejected. A month separated the two: the tag was
2026-08-18, hermes-agent 0.19.0 on PyPI was 2026-07-20.
Upstream never meets this because their installer builds the app from the same
checkout it installs the CLI from. Pinning the CLI forward to the app's commit
is not open to us either -- Hermes refuses a non-editable install from a git
checkout and tells you to use `uv sync` instead. So the app is pinned back
instead, to the tag PyPI's current release was cut from.
Verified on a worker: the desktop reaches "Hermes backend is ready" and maps
its window, where the newer build stopped at the 401 every time.
David Heinemeier Hansson