Monologue now publishes a GitHub release for every version, so declare
its v{pkgver} tags as the upstream feed, as Hype does. The scheduled sync
picks up new releases and hashes the tag archive, instead of pinning a
commit by hand. This first release brings Monologue to 0.2.0, which
builds trimming in, so the omacut optdepend goes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Elsewhen moved into the Omarchy shell as omarchy.elsewhen (basecamp/omarchy#13429),
and a migration there removes the installed package. Nothing else in the repo
references it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The deb's /etc/cron.daily/microsoft-edge runs a script that writes an
apt keyring to /usr/share/keyrings every day. pacman doesn't track that
file, so it stays behind after Edge is removed. Remove the cron job and
its script the way the Chrome recipe already does, and skip the empty
/etc left behind. pkgrel 2 so this build replaces AUR-installed copies.
Found in a Codex review.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
omarchy-install-browser still reaches for yay to install Chrome, Edge,
Brave, Brave Origin and Zen. These were the only packages anywhere in
Omarchy's installers and menus that aren't available from core, extra,
multilib or OPR. Serving them from OPR means installing any Omarchy
browser no longer depends on the AUR being up.
Imported once from the AUR with bin/add-package, on the fast ring so
browser security releases reach stable promptly, each with a direct
vendor watch:
- google-chrome: Google's stable apt index
- microsoft-edge-stable-bin: Microsoft's stable apt index
- brave-bin, brave-origin-bin: Brave's stable apt index. Brave's
GitHub releases can't be used because nightlies aren't marked as
prereleases there.
- zen-browser-bin: GitHub releases (the twilight tag doesn't match)
Package names match what Omarchy's scripts already check for, so the
existing omarchy-pkg-aur-add calls resolve to the repo package without
any change on the Omarchy side.
Validation: upstream-watch check reports all five as current. A sync
of downgraded copies of zen-browser-bin and brave-origin-bin reproduces
the checked-in pkgver and both architectures' checksums. All five build
with makepkg on x86_64, and the launchers, desktop IDs and /opt paths
match what omarchy-default-browser and omarchy-theme-set-browser use.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
ttfx releases are now published on GitHub only, so sync-upstream picks up new
versions through a github watch instead of ttfx's release script editing this
recipe. The recipe also points at the repository's current home, and x86_64
builds pull in NASM, which the new assembly engine needs (without it the
build silently falls back to the Rust engine).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MxJcVYpBxFDam6czK4bGjp
Hype now publishes a GitHub release for every version, so declare its
v{pkgver} tags as the upstream feed. The scheduled sync picks up new
releases and hashes the tag archive, instead of a hand-written PR each
time. This first sync brings Hype to 0.4.2.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
