Default Electron to the gnome-libsecret password store so Hermes can use GNOME Keyring for secure remote tokens. Declare libsecret as a runtime dependency.
cmd_rc handed maybe_iso the bare train version, so omarchy-iso-release
named every candidate omarchy-X.Y.Z-rc.iso — rc2 uploaded over rc1's
URL. Pass the pinned rcN version instead; paired with omarchy-iso's
f9be60b, the artifact becomes omarchy-4.0.2rc2.iso. The ship path
keeps passing the final version.
Edge is the channel the 4.0.2 RC ISOs point pacman at until the rc-channel
migration lands, but edge only carried omarchy 4.0.1 — older than the
installed 4.0.2rc1, so those installs never saw an upgrade. Bumping master's
pin lets the normal edge pipeline build and publish 4.0.2rc2, whose migration
repoints [omarchy] at the rc channel.
Stable is unaffected: pinned packages never build for stable
(package_builds_for_mirror), it only receives them via the rc->stable advance
at ship time.
(cherry picked from rc-branch pin commit 11767d6)
pkgs.omarchy.org sits behind Cloudflare, and right after a sync the
plain db URL keeps serving the previous file from the edge cache
(observed: a cache HIT with age 900s+ returning the pre-release db).
That made status report the old version, wait_for_published poll a
frozen file for its full timeout, and would let RC auto-numbering
count from last release's versions. A unique query string per fetch
skips the cached entry.
package_builds_for_mirror gates pinned packages' rc builds on
OMARCHY_RC_PINS, but that check runs inside the container via
build.sh, and docker run only forwarded ARCH/MIRROR/PACKAGES —
so the rc trigger's pinned builds were always skipped as 'not
configured for direct rc builds'.
The rc trigger passes '--package omarchy omarchy-settings', and bin/build
already consumes every name up to the next --option, but bin/release only
took one — the second name fell through to 'Unknown option' and the
release exited before building anything. Parse greedily, like bin/build.
Ship the least-privilege rule with asdcontrol so authorization follows the package lifecycle. Install it after older broad rules for safe staggered upgrades.
Same upstream release, so only pkgrel moves. Built from v0.0.35-omarchy.4,
which carries the fixes from nine rounds of review on the upstream PR: the
CLI no longer overwrites an unreadable settings.json, setting a
single-appearance theme actually switches the client, reconnects no longer
flash published themes back to stock, and already-shipped clients keep
their config subscription instead of losing it to an unknown event.
`gh pr list` orders by creation date, so `--limit 30` cut the candidate set by
when PRs were opened, not when they merged. The `sort_by(.mergedAt)` that
followed only reordered whatever survived that cut. A PR opened before the
window but merged inside it — exactly the kind a release branch still needs —
never reached the already-on-branch check at all. #7649 and #7709 were both
missing from v4-0-2's list for this reason.
The window is now bounded by the branch point instead of a count: pull a wide
page and keep what merged after the merge-base's commit date, since anything
merged into the dev branch before the release branch left it is already there
by ancestry. v4-0-2 went from 11 candidates to 31.
Widening it surfaced a second gap. A change re-applied by hand carries neither
a PR number nor a cherry-pick trailer, so already_on_branch could not see it
and offered it again (#6939, applied as 33d7363c). It now also compares the PR
title against the branch's subjects, with any trailing "(#N)" stripped.
Comment-only. The .env requirement and the fact that only a PKGBUILD
version change triggers the build server both bit us once each; the
recipe now lives where the next rebuild starts.
The r2 artifact was built without the public Connect configuration official
artifacts carry (relay URL, Clerk publishable key, CLI OAuth client id), so
Connect prompted for login with no way to log in. Same code, rebuilt with
the configuration recovered from the published npm t3 package.
Rebuilt from v0.0.35-omarchy.2 of the environment-theme branch: the stream
event is capability-gated so old clients keep their config subscription,
republish dedupe is structural, the connect stream is gap-free, default
adoption is scoped per environment and keyed on the set generation, and
reserved theme ids cannot be published over. Joins the fast ring like
t3code-bin so patch rebuilds reach machines quickly.
Built from the environment-theme branch of ryanrhughes/t3code (tag
v0.0.35-omarchy.1) until upstream ships it: the app follows themes the
machine publishes into its state directory -- Omarchy retints it live --
and t3 theme set works. Same packaging as t3code-bin, conflicts with it,
and the next upstream release supersedes it after a rebase.
The desktop bundle already contains the full server -- the same entrypoint
npm's t3 package runs -- so a launcher that starts it through the bundled
Electron as Node puts the CLI on PATH without a second runtime. Upstream
only distributes the CLI via npm, which Omarchy's install scripting cannot
assume.
The rc channel's Arch base can sit anywhere between stable's snapshot and
edge's, so a package built against stable's libraries is not necessarily
correct for rc. Copying stable's fast-ring artifacts into rc therefore shipped
possibly-mislinked packages to RC testers. Fast-ring packages now build
natively for all three channels, each in its own image against its own base
mirror, and the stable release's replication step is gone.
That required separating 'may be built here' from 'whose version wins'. The
release pair is now marked "pinned": its version is set per release on the rc
branch, so it builds for rc only from that branch's worktree
(OMARCHY_RC_PINS=1, set by omarchy-release rc) — master's shipped pins can
never overwrite an in-flight RC, even though check-versions now discovers rc
work like it does for edge and stable.
The fast-ring replication announced itself before the release that triggered
it, so chat read as though an rc job had run on its own — the reverse of what
happened. The publish report now fires first, and the replication says only
how many packages were kept in parity: the release report immediately above it
already lists them by name.
Synced from the AUR at 04592d5. Two upstream releases land together: 4.29.5
hardened the aether protocol imports and moved the repository links from
bjarneo to omacom-io, which is why the url and every source line change here
as well; 4.29.6 disables WebView GPU acceleration on Linux. The packaging
itself is untouched between the two -- only pkgver and the checksums differ --
so taking HEAD rather than pinning 4.29.5 costs nothing and carries the
hardening either way.
aether is fast ring, so this reaches stable without an edge-to-stable
migration once it is built for that mirror.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Pin the official Linux .deb to Cursor stable 0.29.0 (commit f0e5bfce).
Binary, icons, and grokbot:// handler are unchanged from 0.24.0; keep the
Wayland wrapper and /usr/bin/sand compat symlink.
Linux still has no update feed. Leave pinning to update-pkgver.sh.
Sections that still described the old two-channel, host-only world:
- command scope: the host-tree commands forward over ssh now, and advance
replaces the deprecated migrate
- global flags: --mirror takes edge|rc|stable, and --local exists
- build examples and directory structure: the rc channel and the release lock
- release section: omarchy-release is the front door; omarchy-pkgs is the pin
engine it drives (and still usable directly)
- management: bin/repo timers, the backoff state files, and clearing a stale
lock, instead of raw systemctl invocations that omitted the rc units
- a leftover reference to the 6-hourly timer as the trigger backstop
Also fixed an anchor that pointed at the section containing the link rather
than the Quick Start section it names.
Matches what is already published to edge: 0.0.34 was built on the server
before the bump reached git, so the checkout read as out of date and queued a
rebuild of the older 0.0.33-2 that promotion then refused. Produced by
bin/sync-upstream, the same path the scheduled workflow uses.
Reporting to BASECAMP_CHATBOT_URL is a working setup — the second variable
exists only for those who want release traffic in its own chat. setup now
states which chat receives reports instead of warning about the common case,
and the README frames the split as optional rather than expected.
Two failures from the first live run:
notify_basecamp declared 'local BASECAMP_CHATBOT_URL' and then called
release_chatbot_url, whose fallback reads that same global — bash locals are
visible to called functions, so the fallback saw the empty local and every
notification silently went nowhere for anyone with only the legacy variable
set. The local is now named 'url'.
check-versions compared PKGBUILD and published versions with !=, so a checkout
BEHIND the channel queued a rebuild of an older version every cycle: the
builder produced it and promotion refused it, because that exact filename is
already published with different bytes. It now skips (with a warning naming
the package) when an artifact for the PKGBUILD's version already exists in the
channel, whichever direction the versions differ.
The rc service fetched and reset /root/omarchy-pkgs-rc in ExecStartPre, but
that worktree does not exist until the first RC creates the rc branch — so on
a freshly set up host the unit failed every five minutes, forever, and showed
up as a failed unit in the timer report.
It now runs bin/auto-release-rc from the main checkout, which always exists:
nothing queued exits silently, no rc branch is a clean no-op, and a missing
worktree is created on demand before handing off to the worktree's own
auto-release.
A bad in-place edit truncated the file to zero: open(p,'w') ran before
open(p).read(), so the read saw an already-empty file. Restored from c0a63dd
and reapplied the two intended changes — the start report now naming queued
packages, and the nothing-to-publish report described as the check/builder
disagreement signal it is.
Restores the no-change report now that it is clear it cannot fire on an idle
timer tick: releases only run when the version check queued work, so a run
that publishes nothing means check-versions and the builder disagree about
what is out of date. The report names the packages that were queued but never
built, so a recurring disagreement is diagnosable rather than invisible.
A release that published nothing is not news, and at a 5-minute cadence those
messages would bury the ones that matter — the log and bin/repo timers still
show the run happened.
Removing it would have left a start report with no follow-up, so the start
report now carries its own answer: check-versions writes the package names it
queued into the state file instead of touching an empty one, and the release
run reads them. 'A build is running' becomes 'your package is in this build',
which is the question the reports exist to answer.
Only failures were reported, so a push could reach the mirror with no way to
know short of querying the database by hand. Release runs now report:
- start: channel, arch, host, and the commit being built
- published: the packages and versions that went out, duration, channel URL
- no-changes: the run found nothing to build
- promoted: what advance moved between channels, including the rc bootstrap
and fast-ring replication
- failed: unchanged, plus the commit context the other reports carry
Release traffic goes to OMARCHY_RELEASE_CHATBOT_URL, falling back to
BASECAMP_CHATBOT_URL, so build reports stop drowning the repository chat the
sync workflows post to. bin/setup reports which destination is configured.
The published list is captured after the build step because promote moves the
files out of build-output, and is capped at 25 entries so a full rebuild does
not produce an unreadable wall of chat.
A push reaching the mirror should take minutes, not up to six hours. All four
units now fire every 5 minutes, staggered a minute apart. Three guards make
that cadence safe:
- Scheduled runs take the release lock NON-BLOCKING (try_release_lock) and
skip the tick when a build is running. Blocking would stack one stalled
process per tick behind a long build and stampede when it finished. Manual
commands still wait, as an operator expects.
- check-versions takes the lock too, and now owns its git pull (--pull, passed
by the unit) instead of an ExecStartPre: at this cadence an unlocked pull
would swap PKGBUILDs out from under a running build.
- A failed release records .build-failed-<channel> and backs off
exponentially (10m, 20m, 40m … capped at 6h) rather than rebuilding the same
broken tree every 5 minutes. Any new commit clears the backoff, since a push
is the most likely fix.
Idle ticks exit without output so the journal keeps showing the runs that
matter, and bin/repo timers reports backoff state — a paused channel is
otherwise indistinguishable from an idle one.
Wraps systemctl list-timers with the things you actually want when checking on
the build host: per-unit enabled state, last run and whether it succeeded,
which channels have builds queued (state files), whether the release lock is
held by a live process, and any failed units. Units are discovered from
systemd/*.timer so the report cannot drift from what setup installs.
It forwards over ssh like the other host commands, so the build box's timer
state is one command away from a workstation (--local to inspect this machine).
ZacharyZhang-NYandAndy Stewart