v0.7.17 (tag a33a4e395) is the published Latest; v0.7.15/16 were burned and
never shipped. check() now runs the release's scripts/verify_runtime_assets.py
against the staged parakeet share tree so a stage whose ANE bytes disagree with
the wheel's runtime pin fails the build instead of shipping. Mesa pin unchanged.
GitHub archives now extract to omarchy-mlx-<ver> for every tag, so the
source filename and the build cd follow the omarchy-mlx name. Tarball
sha256 unchanged: 7ad98f7df4df54c1e194b2be1469200da767dc3e374d79e66dcb98bdbb958a9d.
omarchy-mlx builds the v0.7.10 release wheel and vendor tarball from
github.com/joshuaswarren/omarchy-mlx; omarchy-mlx-vulkan pins the
honeykrisp-omarchy-v3 driver at mesa-1 e7631595df6281748ea5e643d74db59c5f783b01
with MESA_GIT_SHA1_OVERRIDE set to the short sha the driver reports and the
runtime compares. omarchy-mac-ml now pulls omarchy-mlx-vulkan directly and its
description names MLX on the GPU and Core ML models on the Neural Engine.
Both packages come from one PKGBUILD, so the MLX wheel and the Vulkan
driver it was qualified on publish together.
omarchy-mlx-vulkan builds only the Honeykrisp Vulkan driver from
joshuaswarren/mesa-1 9b97b82ab1. It installs the driver, an ICD
manifest with an absolute library_path, and the driver's git SHA in
/usr/lib/omarchy-mlx/vulkan/. The manifest is outside the loader's
search path, so only omarchy-mlx uses the driver. It provides nothing
generic and conflicts with mesa-honeykrisp-omarchy.
omarchy-mlx builds the private venv offline from the release's
hash-locked vendor wheels and depends on the exact omarchy-mlx-vulkan
build.
The mlx-omarchy sources are placeholders until v0.7.7 is published.
* Accept the fifth Hermes desktop launch option
Hermes now returns five values from _desktop_launch_options(), appending the renderer accessibility switch. The launcher unpacked exactly four, so once a user's runtime updated, every launch died with "too many values to unpack" before the app opened. The launcher now takes the first four and reads the fifth when present, so it keeps working with the packaged release and with newer runtimes, and it bridges an explicit accessibility opt-out the same way Hermes' own launcher does. The launch check now also runs a five-value helper, which fails against the previous launcher.
Fixesbasecamp/omarchy#13491
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* hermes-desktop: launch against the installed runtime, accept the helper's new arity
_desktop_launch_options() returns five values since Hermes grew a trailing
renderer_accessibility field, so the launcher died with "too many values to
unpack (expected 4)" before os.execve — and gtk-launch discards stderr, so the
app icon became a silent no-op that left no process and no log line behind.
The launcher also exported HERMES_DESKTOP_IGNORE_EXISTING=1 unconditionally
while preferring the runtime's own app binary a few lines above it: with a
runtime installed, Desktop skipped that runtime and offered first-run setup
instead of the user's sessions. Ignoring an existing runtime is only correct for
the bundled /opt app, which is built from the package's release commit and
cannot drive a runtime built from another one.
pkgrel bumped for the changed artifact.
* Tell only the packaged Hermes Desktop to skip an existing install
The runtime's own app now finds its runtime the way `hermes desktop` launches it, through the installed-runtime lookup, instead of being pinned to it with HERMES_DESKTOP_HERMES_ROOT. That variable is upstream's developer override: it resolves before the lookup that Repair install bypasses, so pinning the runtime turned a hard repair into a restart against the same broken venv. HERMES_DESKTOP_IGNORE_EXISTING is set only when the launcher falls back to the packaged /opt app, and an explicit value in the environment still wins, so the in-app updater's relaunch of the runtime app no longer inherits it.
The fifth launch option is read the way it was accepted in the previous commit but one, with the checksums the two earlier commits left stale brought up to date. runtime-test.py now records both variables, so it fails if the unconditional export or the root pin comes back.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Codex XHigh <noreply@openai.com>
---------
Co-authored-by: manuaudio <manu@arimaka.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Omni <omni@omninova.com.mx>
Co-authored-by: Codex XHigh <noreply@openai.com>
cua-hyprland-plugin 0.26.1-6 pins glibc=2.44+r24+g16be1518495f-1 exactly. Arch core has moved to 2.44+r50+g1848099f063e-1, so on any upgraded edge system pacman refuses the plugin with "unable to satisfy dependency", even though cua-driver-bin installs.
Derive a new profile, omarchy-edge-20260928-remaps, that pins the current glibc and takes its source from the Driver 0.28.2 release that cua-driver-bin ships. The plugin files in that release are byte-identical to 0.26.1 and 0.27.0, so the keymap patch applies unchanged and only the upstream base in DOWNSTREAM-PROVENANCE.json moves. The download wrapper now substitutes the 0.28.2 archive and manifest into the verified upstream kit and renders the recipe from the kit's own PROFILE-PKGBUILD.in, so the derived kit is one Cua's profile_verify.py accepts as complete.
pkgrel starts at 2 because profile validation refuses package release 1.
#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.
* Add disktree
* disktree-bin: 0.9.1
* disktree-bin: 0.10.1, for aarch64 too
0.10.1 ships gpui-omarchy 0.1.3, and the release now builds an aarch64
Linux tarball, so the recipe and the upstream asset map cover both.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* voxtype-bin: update to 1.1.0
Ship the signed 1.1.0 release assets, baseline and ARM binaries, and the complete Quickshell and OSD style trees. Add OpenVINO optional dependencies from #526 and select the baseline binary automatically on pre-AVX2 hosts.
* voxtype-bin: bump pkgrel past the published 1.1.0-1
voxtype-bin 1.1.0-1 is already published to edge, rc and stable from master's upstream sync. This branch changes that package's contents (baseline binary, OSD styles and recipes, the install hook, OpenVINO optdepends) without changing its version, so publish.yml would call it already published and skip it, and publish-artifact refuses different bytes under an existing filename. pacman would not offer it as an upgrade either.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* voxtype-bin: list accelerator optdepends for x86_64 only
makepkg appends optdepends_$CARCH to optdepends rather than replacing it, so optdepends_aarch64 did not drop the Vulkan, CUDA, ROCm and MIGraphX entries on aarch64: it listed all sixteen shared ones and then eleven of them a second time. The accelerator runtimes move to optdepends_x86_64 beside the OpenVINO ones, and the aarch64 array goes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* voxtype-bin: move pre-AVX2 hosts to the baseline build on upgrade
The baseline pick in _set_default_backend only runs when no backend was saved, which is a fresh install. Every release before 1.1.0 gave a CPU without AVX2 voxtype-avx2, and pre_upgrade saves that path, so post_upgrade restored the build the host cannot run and the machines the baseline binary exists for never reached it. A saved AVX2 or AVX-512 build whose instruction set the CPU lacks is now picked again; GPU and ONNX choices are left alone.
tests/voxtype-bin-install.sh covers the fresh-install pick and the upgrade cases, and runs with the other self-tests. It borrows the hook's fixed /tmp/.voxtype-backend-upgrade, so it refuses to start when anything is already there, a dangling symlink included: CI runs it as root, and writing through a planted link would land outside the test.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Codex XHigh <noreply@openai.com>
* tests: keep voxtype-bin-install's upgrade state out of /tmp
The test borrowed the hook's /tmp/.voxtype-backend-upgrade and checked it was free only once, so a real voxtype-bin upgrade writing its state during the run could have that state overwritten or deleted, and the hook would then lose the user's backend. The test now redefines the sourced _preserve_or_set_backend with the path moved into its own directory, and fails outright if the hook stops using that path rather than passing without reading it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Codex XHigh <noreply@openai.com>
* tests: never parse voxtype-bin-install's temp path as code
The redefined _preserve_or_set_backend went through eval with the mktemp path pasted in, so a TMPDIR holding shell syntax -- a directory named $HOME, or $(...) -- was expanded or run when the function was called. It now carries a reference to $SAVED, which expands to the path only at run time.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Codex XHigh <noreply@openai.com>
---------
Co-authored-by: Spencer Bull <spencer@omarchy.org>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Codex XHigh <noreply@openai.com>
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.
Build it in edge and promote through rc to stable like other packages,
matching cua-hyprland-plugin, which left the fast ring in #432.
#693 held upstream sync while 0.28.3+ breaks screenshots. Make that the
standing policy: Omarchy bumps the driver by hand, so the PKGBUILD no
longer says to re-enable sync after the fix, and docs/upstream-sources.md
records the hold. The hook and min_release_age stay, so lifting the hold
is a one-line revert.
Publish as 0.28.2-3 so the PR builds; the payload is unchanged.
No platform package is built for x86_64, so an x86 machine has nothing to
guard. The check that 00-omarchy-hooks.conf has its detector copy follows it:
without the copy, x86_64 keeps the busybox line it would have anyway, and
leaving the check unscoped would fail every x86_64 build from a source that
asks omarchy-hw-platform. Taken from #691, which keeps the -dev recipe.
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.
A source with default/settings-runtime-profile decides at runtime which
platform-specific files apply, so its aarch64 package now gets the same files,
backup and optdepends as x86_64: the Thunderbolt request and the memory stack
stay, and its HOOKS files ship as they are. The check that a Mac's asahi line
survives still runs on every aarch64 build. Older sources, including the pinned
v4.0.4, keep #380's aarch64 package: Thunderbolt removed, the HOOKS line guarded
for asahi, the memory stack stripped. The keyboard backlight unit first-run
enables ships whenever the source has it.
pkgrel 4 so the recipe change builds: edge already holds 4.0.4-3 on both
architectures. The payload built from v4.0.4 is unchanged.
The planner took 'git diff base.sha head.sha', a two-dot diff between
the current master tip and the PR head. For a PR that branched before
later merges, that counts every package master has changed since, so
the PR plans those too and builds its own stale copies of them: wasted
builds, and 'already up to date' Pack failures that turn the PR red for
packages it never touched. #397 (lazyjournal) planned 22 packages for a
one-package change. The checkout is shallow, so ask GitHub for the PR's
files, which are listed against the merge base.
'git status --short | head' under set -o pipefail: once the PR's
pkgbuilds/ differs from base in more than ten files, head exits, git
takes SIGPIPE and the step fails with 141 before anything builds. Every
PR branched far enough behind master hit it (omadev #423, llmman-bin
#428 and others on 2026-09-28). sed -n '1,10p' prints the same preview
and drains the stream.
Joshua Warren