Upstream merged the installer rollback, renderer Host check, contrast warning and playback fixes and cut v0.1.2 with them, plus a fullscreen intro that is canvas geometry only: no new dependencies, files or runtime paths. The checksum is the one its SHA256SUMS manifest publishes.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Packages llstrk/omarchy-billboard-generator from its GitHub release archive: the runtime tree plus locked production npm dependencies under /usr/lib, entry-point symlinks in /usr/bin, a desktop entry whose WM class matches the Chromium app-mode window, and the fonts and provenance notices the project bundles. Chromium and ffmpeg are runtime dependencies found on PATH rather than downloaded, which is how the project itself works.
The desktop entry is written from the PKGBUILD rather than shipped as a second source because sync-upstream rewrites the checksum array wholesale from the release manifest. The catalog checks pin the data directories to empty scratch paths so the build reads bundled data rather than a synced snapshot in the builder's home.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Codex XHigh <noreply@openai.com>
Upstream 0.9.1 bumps vendored libghostty-vt's minimum_zig_version to
0.16.0, so the pinned Zig tarballs move from 0.15.2 to 0.16.0 with
checksums taken from ziglang.org's download index.
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
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>
1Password reads the display scale itself, the way Electron apps do, so
on a scaled monitor it comes up oversized next to every other window.
Pin it in the .desktop we install and let the compositor scale it.
Rewriting Exec on the way in is how spotify, perplexity and sublime-text
already fix up their entries here. Only the stable package: 1password-beta
syncs from the AUR, so a patch there would be overwritten.
Claude-Session: https://claude.ai/code/session_01JB9phxP56gnP7qSidkkUJE
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
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.
The launcher only delegated to omarchy-install-hermes-cli and, when that was
absent, printed a warning to stderr -- which nothing sees under a graphical
launch -- and started the app anyway. The app then offered to install Hermes
itself, and that copy wins permanently: it checks ~/.hermes/hermes-agent
before it checks PATH, so installing the CLI afterwards changes nothing until
that directory is deleted.
So install it here when omarchy's script isn't around, with the same
interpreter pin and the same exported cooldown, and hand the app the real
executable by putting the mise install's bin directory on PATH instead of
leaving it to search. Its probe allows 15 seconds; resolving this way takes
0.2. mise and uv become dependencies, which is what makes the package
self-sufficient on a machine without Omarchy.
Pin the build stamp. write-build-stamp.mjs resolves the commit the app pins
its first-launch bootstrap to, preferring $GITHUB_SHA and otherwise running
`git rev-parse`. That fallback is wrong under makepkg: the build happens
inside this repository, so git ascends out of srcdir and stamps the app with
an omarchy-pkgs commit that means nothing upstream. Confirmed by rebuilding --
the stamp now reads the tag's own commit rather than this repo's HEAD.
Ship upstream's MIT licence. The package declares MIT and was installing only
Electron's licence text.
Repair a drifted CLI before launching rather than only a missing one. `mise
up` can leave Hermes rebuilt against the system Python, and a stub can be
there but cold; either way the wrapper's own repair takes minutes while the
app allows 15 seconds before bootstrapping its own copy. Running the installer
unconditionally costs nothing when Hermes is healthy.
Register the hermes:// scheme. The desktop entry took %U while declaring no
MimeType, so the scheme electron-builder configures went unhandled.
Chromium falls back to XWayland often enough to matter, and the result is a
blurry window on every scaled display -- the same reason the ChatGPT and Grok
Bot launchers set this. Skipped when the caller has already named a platform.
Install > AI is for GUI apps, so the package becomes the desktop shell and the
terminal agent moves to a lazy mise stub that omarchy installs itself.
Nous builds Hermes Desktop for macOS and Windows only -- their download page
offers a .dmg and an .exe and points Linux users at a terminal install -- so
there is no vendor binary to repackage the way grok-bot repackages xAI's deb.
Their electron-builder config does carry a Linux target though, untested by
upstream but working: npm ci at the workspace root, npm run pack in
apps/desktop, and electron-builder stages node-pty and get-windows for
linux-x64 on its own. 337 MB unpacked, 129 MB packaged.
The app is only a shell -- it runs `hermes serve` against a CLI it does not
ship, and clones its own unpinned copy into ~/.hermes when it finds none. So
/usr/bin/hermes-desktop makes sure the CLI is there before handing over, and
says so plainly rather than bootstrapping a second Hermes where Omarchy's
installer isn't around to do it properly.
Both files changed after the sums were generated -- the wrapper learned to
fall back to hermes when invoked under an unknown name, and the desktop entry
dropped its second main category -- so makepkg rejected them.
Hermes pins every one of its ~120 dependencies with == and declares
Requires-Python >=3.11,<3.14, so it can neither be built against Arch's
Python 3.14 nor share the python-* packages, and Arch's next Python bump
would break any venv this package built. So it ships a wrapper instead and
lets mise give Hermes a private environment -- the arrangement
omarchy-mise-install already makes for the other coding agents.
Two things the wrapper has to work around. mise reads [...] as its own tool
options rather than as Python extras, so the extras have to be spelled
[extras=all]; written [all] they are dropped without a word and the install
comes out byte-identical to a bare one. And given no compatible interpreter
to hand, uv builds the venv against the system Python in violation of
Hermes' own bound, reports success, and leaves the breakage to surface later
inside some dependency. The interpreter is therefore pinned on install and
re-checked on every run, since mise up reinstalls without the pin.
The icon is upstream's own 1024x1024 app icon -- the mark the site serves as
its favicon -- downscaled at build time so menus don't smudge it themselves.
A second review pass found the PKGBUILD rewriting could still go wrong in ways
the pattern matching did not anticipate: an array element carrying a ")" in a
comment left the tail of the old array behind, and jq's "$" also matches before
a trailing newline, so a pkgver of "1.0\n" passed validation and then broke sed
after the checksum arrays had already been written.
Rather than chase each shape, prove the result. Every edit now lands on a
scratch copy that is parsed with bash -n and read back to confirm it holds the
version and checksums we meant to write, and only then replaces the PKGBUILD in
a single rename. Corruption that slips past the matching fails loudly with the
original untouched instead of landing in a pull request.
The validation anchors are \A and \z accordingly, empty checksum lists are
rejected rather than written as '', and the hook picks the newest stanza with
vercmp so it agrees with the comparator the updater uses.
Also stop the launcher probing /.config when HOME and XDG_CONFIG_HOME are both
unset, and require a regular file, so a directory at that path is skipped
instead of crashing the app on startup.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenAI ships the ChatGPT desktop app several times a week and the AUR
packaging trails it -- as of this commit by a full version, 26.803.81509
against 26.810.52044. Every sync we took from there was a sync we could have
taken from OpenAI directly.
So track OpenAI's own Debian repository instead. Its per-architecture package
index carries the version and SHA256 of every deb, which makes an update two
small HTTP requests rather than a 750 MB download, and the pool keeps old
versions, so the URLs pinned here stay resolvable after the next release.
Omarchy now maintains the package outright: the max-zstd patch is simply part
of the PKGBUILD, chatgpt-launcher.sh is ours, and the Arch REUSE files are
gone -- they annotated packaging paths (.SRCINFO, keys/**, .nvchecker.toml)
that do not exist here. The app's own license still ships; package() installs
upstream's copyright file.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Some vendors publish a release feed of their own that is faster and more
precise than anyone's packaging of it. A package opts in with an
.omarchy/upstream.sh hook that reports the newest release as JSON, and the
driver rewrites pkgver, the checksum arrays the hook names, and pkgrel.
Writes are guarded on both ends: every assignment the update will touch is
verified to exist before anything is written, so a hook naming an array the
PKGBUILD lacks fails with the file untouched rather than half rewritten; and
pkgver is held to pacman's character set, because it lands in a file makepkg
sources as shell.
Ordering is vercmp's, not sort -V's -- they disagree about whether 1.0a
precedes 1.0, and pacman is what decides if a published package is an upgrade.
That is also why the workflow runs in an Arch container rather than straight on
the runner.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Omarchy 4 generates most theme specs from default/themed/neovim.lua.tpl on
top of aether, pinned as `name = "aether", branch = "v3"`. lazy indexes
specs by url and lets an explicit name rename the merged plugin, so the
bare "bjarneo/aether.nvim" entry here built the cache into lazy/aether.nvim
while every aether-themed install renamed that same plugin to lazy/aether at
runtime -- a directory the package never shipped. Picking one of those themes
on a fresh install cloned aether over the network at first launch and left
the session on tokyonight until nvim was restarted. Six stock Omarchy 4
themes route through the template, plus last-horizon.
Naming the entry to match builds the cache into lazy/aether directly. There
is still only one clone: Omarchy 3.8's hackerman theme depends on the bare
"bjarneo/aether.nvim" url, which merges into the same plugin, so 3.8 keeps
resolving offline as before.
Also keep refs/remotes/origin/HEAD when slimming. It pins no objects, but
lazy.nvim resolves the default branch through it for plugins parked on a
detached HEAD by a version pin -- lazy.nvim, LazyVim and blink.cmp. Without
it get_branch() returns nil and every lockfile write asserts, so :Lazy
install/update/sync died with E5113 on a fresh install, taking out the usual
self-heal path too. Regression from 45ca871.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
#6746 added the unit, the binary, the enable-user-units.sh entry, and a
migration, but not the install line here -- so omarchy-settings shipped
omarchy-crash-watch.service only into the default/ template tree and never
into the search path systemd actually reads.
install/user/first-run/enable-user-units.sh enables its six units in a single
`systemctl --user enable --now` call, so the missing unit failed the whole
call. omarchy-provision-first-run only marks first-run-user when every step
succeeds, which meant first-run never completed and replayed on every login,
re-firing the "Learn Keybindings" and "Update System" notifications. Because
enable is atomic, it also left the other five units disabled -- no bluetooth
agent, sleep lock, monitor recovery, migrate notifier, or fcitx5.
Migration 1786539345 falls back to writing the wants symlink by hand when
there is no live user manager, pointing at the /usr/lib path this omission
left empty, so existing installs got a dangling symlink too.
No new migration is needed: affected installs retry first-run on the next
login and succeed, and the dangling symlinks resolve as soon as the file
exists at that path.
test/shell.d/config-test.sh already asserts this install and fails without it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jm1hEGtGRUrfqxMbTi1fWe
The first version checked for pacman and refused anything else, so it would
have declined to run on the actual repository host. Nothing about that host
needs to be Arch: makepkg, repo-add and signing all happen inside containers.
Setup now detects apt or pacman and installs the right names for each --
bsdtar is libarchive-tools on Debian and libarchive on Arch. The requirement
list drops gnupg and the Arch build tools, which the host never runs directly,
leaving Docker, rclone, bsdtar, jq, git and rsync.
Docker is checked before being installed. A host may be running a version from
Docker's own repository, and replacing that underneath a working builder would
be a poor trade for consistency; setup starts it if stopped and otherwise
leaves it alone.
Verified both paths: apt installs the five dependencies and docker.io on a
bare Ubuntu 24.04 container, and an Arch host with Docker already running is
left untouched. A missing systemctl now reports that a container cannot be a
repository host instead of failing on an unknown command.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The sync guard could not read the repository database because bsdtar was not
installed on the host, and the first fix was to parse around its absence. The
better answer is for the host to have what the tooling needs: libarchive ships
the library pacman links against without necessarily installing the binary, so
bsdtar being present was an assumption, not a fact.
bin/setup installs the dependencies, enables Docker, creates the state
directory, and installs and enables the release timers -- the steps the README
previously listed by hand. It is idempotent and takes --check to report without
changing anything. Signing credentials and the rclone remote hold secrets, so
it reports on those rather than creating them.
sync-repo goes back to reading the database with bsdtar alone, and says to run
bin/setup when it is missing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The partial-tree guard parsed omarchy.db with bsdtar, which is not installed on
the repository host. Every sync there aborted with "the remote database exists
but could not be read" -- a guard meant to catch a partial tree instead blocked
a complete one, stopping a publish after sign, promote and update had already
succeeded.
GNU tar reads the database fine when it is a seekable file; the pipe was what
defeated it originally, and that is already downloaded to a temp file. tar now
leads, with bsdtar as a fallback for a tar too old to detect zstd.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
--package meant a pkgbase to bin/build and a literal package name to
bin/push-build, so deploy --package nvidia-580xx-utils built three packages and
published one, leaving nvidia-580xx-dkms and opencl-nvidia-580xx behind with no
indication anything was missing. Hit while deploying exactly that package.
Selection now matches on the pkgbase recorded in .PKGINFO as well as on the
package name, so a pkgbase ships all of its outputs and an individual name
still selects just that one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
bin/build asks the local repository database which packages are already built.
A build machine has no such database, so every package looks out of date: an
unscoped 'bin/repo deploy' on this laptop would have built all 108 packages and
published them. Verified with a dry run.
deploy now refuses to run unscoped when that database is absent, and push
refuses the same combination under --yes, where nobody would see the list it
prints before publishing. Both are allowed on the repository host, which has
the database that makes the comparison meaningful.
Also states the split in the README: build, push and deploy are the three
commands that may run off the repository host; everything else works on the
published tree directly.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
