Ship Slack's own x86_64 build unchanged so Omarchy controls the package
on both architectures instead of relying on the AUR recipe for x86_64.
The Electron swap and native module replacements stay AArch64-only.
Update both package recipes and source checksums to OWE 0.2.9. The release adds owe intro --start first-frame, so a login intro can start on its own first frame. Package builds pass on x86_64 and aarch64.
Slack only publishes an x86_64 Linux build, so the AUR recipe produces an
aarch64 package full of x86_64 binaries that cannot start. Run Slack's
application code on the AArch64 build of the Electron release it ships
with, replace the three native addons Slack requires at boot with
JavaScript equivalents, and drop the x86_64 addons it can do without.
Marcelo's review: prepare() skipped the patch whenever aurora.c existed, a
file the patch itself creates, so a tree a failed run left half-patched
would build. It now skips only when every hunk is already in, and a
half-patched tree fails prepare(). The patch has a real b2sum, and the
recipe says the driver accepts only /dev/sep-bio interface version 4, so a
kernel bump and this patch move together.
Co-authored-by: Chris Kearney <303316+iconidentify@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Omarchy's fingerprint setup installs libfprint-git, which built for x86_64
only, so an Apple Silicon Mac had no Omarchy libfprint at all. It now builds
for aarch64 too, and there it carries Chris Kearney's aurora driver for
Touch ID, which the aurora kernel's Secure Enclave driver exposes as
/dev/sep-bio. The x86_64 build applies nothing new.
The patch is his libfprint-1.94.100-apple-sep.patch from
iconidentify/aurora-linux sep-7.1.12.aurora2-11.35, less its
tests/meson.build hunk: libfprint 3f1e2817, already in this pin, made the
same fix. The libfprint provide is now versioned, so aurora-touchid's
libfprint>=1.94.100-1.1 still resolves when this replaces his build.
Built on an M2 Max: 131 libfprint tests pass, none fail.
Co-authored-by: Chris Kearney <303316+iconidentify@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
main now has omarchy-mac-pkgs#10: the boot check leaves device tree
overlays out when /etc/default/update-m1n1 does not apply them (an
owner's copy pacman kept over the .pacnew, or no file), instead of
failing a correct boot.bin and stopping omarchy update. #9 is test-only.
Same UTC commit date as 20261004-2, so pkgrel 3. omarchy-mac stays at
2a3ed89.
This reverts f6b9267b (#651), at pkgrel 3 so it replaces 2026.9.6-2. OpenClaw rides the fast ring, so the seed package went straight to edge, rc and stable, where omarchy is still 4.0.4: nothing there seeds ~/.openclaw or moves an existing install, so every OpenClaw user lost the openclaw command on their next update while 4.0.4's --check went on calling it installed. The seed comes back with the Omarchy release that carries omacom/omarchy#13296.
* Add T3 Code nightly package
* Hold a T3 Code nightly until its AppImages have uploaded
Upstream's release workflow publishes the GitHub release before softprops/action-gh-release uploads its assets: across the last 70 nightlies the AppImages finished 13 to 133 seconds after publication. A scheduled sync that lands in that window selects the release, finds no ARM AppImage to hash, and fails the shared sync run. A 30-minute minimum age, the hold omarchy-dev already uses, makes the watcher keep the previous nightly until the new one is complete.
Co-Authored-By: Codex XHigh <noreply@openai.com>
---------
Co-authored-by: Codex XHigh <noreply@openai.com>
The source is the published v0.4.5 release of joshuaswarren/omarchy-ane
(commit d882f48). sha256sums is the checksum of the GitHub archive
archive/refs/tags/v0.4.5.tar.gz.
0.4.5 moves the overlays to /usr/lib/omarchy-mac-boot/dtb-overlays and the
opt-in file to /etc/omarchy-mac-boot/dtb-overlays.opt-in, the layout of
omarchy-mac-boot 20261004-2 (omacom/omarchy-mac-pkgs 2a3ed89).
- conflicts=('omarchy-mac-boot<20261004-2'): an older omarchy-mac-boot does
not read the new overlay directory, and its boot check fails on a DKMS
module. A system without omarchy-mac-boot is not affected.
- prepare() keeps T6000 and T6020 opt-in with the release's own
tools/promote_chip.py, until a row from this package passes on each.
- check() asserts that both stay opt-in: the overlay key, DEFAULT_ON of the
firmware hook, and the UNTESTED line of omarchy-ane-check.
main now has the docs and CI pin from omarchy-mac-pkgs#7 and the device
tree overlays from #3. omarchy-mac 0.1.0-12 and omarchy-mac-boot
20261004-2 (same commit date, so pkgrel 2). omarchy-mac-boot's overlay
tests need dtc in checkdepends.
* Rebase the Cua Hyprland plugin on Driver 0.32.0 source
Driver 0.31.0 took the independent agent keymaps and Num Lock handling from #473 upstream, so independent-keymaps.patch goes. Upstream also added an up-front check that every key the KEY command can press types the US keysym, modifier keys included, which refuses all foreground typing under ctrl:swapcaps, compose:ralt, altwin:swap_alt_win or compose:102. foreground-remaps.patch makes that check run the per-chord check every key already passes over exactly the chords Driver types text with, with Num Lock off and on, so a string is still admitted or refused before its first key and other remaps are left to the per-chord check.
0.32.0 also gives agent keyboards a real repeat rate, which stops single-seat clients like imv crashing on an agent seat (trycua/cua#4257).
cua-driver-bin stays at 0.28.2, which speaks the same input protocol v3: Driver 0.28.3 through 0.32.0 refuse desktop capture on Hyprland with more than one output or with one away from the origin (trycua/cua#4161).
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Keep restarting fcitx5 from crashing Hyprland under the Cua plugin
With plugin input enabled, fcitx5 requests an input method for each of the three seats, and when it exits Hyprland 0.56.2 can still hold an input-method popup that is mapped although its wl_surface is gone: the popup's surface-destroy handler emits unmap but never clears m_mapped. Tearing down the input method then updates every popup, CInputPopup::updateBox dereferences the missing surface and Hyprland restarts in safe mode. Omarchy's omarchy-restart-xcompose reaches this in normal use.
The plugin now hooks CInputPopup::updateBox and CInputPopup::shouldBeRendered so a popup whose getSurface() is empty is neither placed nor rendered, reports the guard in cua:status, and removes the hooks on unload. The guard is compiled into the module only, so the mock-based tests are unchanged. foreground-remaps.patch becomes downstream.patch now that it carries both changes.
* Pin the Cua Hyprland plugin to Arch's hyprland 0.56.2-4 rebuild
Arch rebuilt Hyprland 0.56.2 against vulkan-sdk 1.4.363 and glslang. The executable and two headers change, so the plugin's exact compositor pin and hashes would block hyprland upgrades for anyone with it installed, and Cua's kit has no profile for it (trycua/cua#4216). The release, compiler and runtime are unchanged, so the derivation now also takes the re-measured compositor executable and header inventory; the build's verifier checks both against the installed package.
* Qualify the Cua plugin README on its input-method guard
The guard is installed best effort, so the README promises the fix only while it is active, and the activation checklist now asks for ime_popup_guard: true. 'No hooks' meant package-manager hooks, which the plugin's new function hooks made ambiguous.
Co-Authored-By: Codex XHigh <noreply@openai.com>
---------
Co-authored-by: Codex XHigh <noreply@openai.com>
The meta package depends on omarchy-mlx/omarchy-mlx-vulkan, which this
PR publishes, so its CI job stays red here and the required result
check can never pass. Split out at review; see #791.
Pulls omarchy-mlx, omarchy-mlx-vulkan, omarchy-ane-dkms and
mil-hwx-compiler: MLX on the GPU and Core ML models on the Neural
Engine. Opt-in only; installs through the Install > AI row.
Depends on #745 (omarchy-ane-dkms) and #764 (omarchy-mlx) publishing
first: CI resolves each package against published edge.
The engine enabled omarchy-mac-migrate-verify.service with systemctl; with the unit gone the link would dangle. Also correct which omarchy-mac pull requests every omarchy-mac-pkgs pin includes (#544 has not merged).
Both recipes pin omacom/omarchy-mac-pkgs main 4399105 and stage the
top-level omarchy-mac/ and omarchy-mac-boot/ directories, each tested
from its own copy. omarchy-mac 0.1.0-11 and omarchy-mac-boot 20261004-1
sort above edge and every lab candidate. They carry the depends and the
platform-root provide from #672 and #673 and drop the migration engine,
legacy files and the Apple setup core now owns.
Corrects GPU sin/cos wrong values for 1e4 <= |x| < 1e7 (v0.7.17-0.7.23
defect). Sources re-downloaded twice, hashes equal; wheel and vendor
match the release SHA256SUMS. Mesa pin unchanged; vendor lock delta vs
v0.7.22 is the mlx-omarchy pin only, no new runtime deps.
rustdesk 1.5.0 and its newer vcpkg pin moved five of the ports the recipe
pre-seeds into vcpkg's downloads:
aom 3.12.1 -> 3.14.1 (rustdesk's overlay port)
ffmpeg 7.1 -> 7.1.1 (rustdesk's overlay port)
libjpeg-turbo 3.1.1 -> 3.2.0
meson 1.8.2 -> 1.9.0
pkgconf 2.5.1 -> 3.0.3
vcpkg found none of the old archives useful and fetched all five itself
mid-build, aom from googlesource. Each new tarball matches the SHA512 in
its vcpkg port.
0004-bindgen raised libs/scrap's bindgen to 0.72.1 for Clang 22 and
added a git override for it. rustdesk 1.5.0's libs/scrap/Cargo.toml
already requires bindgen 0.72.1, so the patch no longer applies (the
Cargo.toml hunk fails and the scrap hunk is detected as applied) and
prepare() stopped. Comment it out like the retired 0001 patch and drop
its checksum entries.
googlesource's +archive tarballs are generated per request: their bytes
change on every download, so the recipe skipped their checksums, and the
endpoint refuses CI runners at times (503s on aom failed two #785
builds). Clone both at their pinned commits instead, which git verifies.
_prepare_vc writes downloads/<port>-<ref>.tar.gz with the same git
archive command vcpkg_from_git uses, so vcpkg finds them cached. The
archives hold exactly the files of the old tarballs (aom 1347, libyuv
183).
rustdesk 1.5.0 moved VCPKG_COMMIT_ID in flutter-build.yml from 120deac
to 9e593bb (vcpkg, 2026-07-30), and _prepare_vc stops the build when the
recipe's pin differs. Add the 1.5.0 row to the vcpkg table and the new
archive's checksums. Flutter 3.24.5, Rust 1.75 and the README's vcpkg
library list are unchanged from 1.4.9.
Upstream's res/PKGBUILD no longer depends on pam as of 1.5.0. The
recipe's prepare() checks _dpr against that list, so the sync's version
and checksum bump stopped in _dpr_check with "Update _dpr from
res/PKGBUILD/depends=()". The bump is the sync's, unchanged; _dpr now
matches upstream's 1.5.0 depends.
Upstream's release PKGBUILD added python (packaged skill scripts, since
1.12.0), layer-shell-qt (a required build dependency for the Game Mode
overlay, since 1.14.0) and the libpulse and umu-launcher optdepends.
The upstream sync only rewrites pkgver and checksums, so the recipe kept
1.12.0's dependency list: the published 1.12.0 lacks python, and the
1.14 builds in the sync PR fail at CMake on LayerShellQt.
The recipe now matches upstream's PKGBUILD-1.14.2, comments aside.
0.4.4 keeps T6000 and T6020 on by default. Both flips rest on community rows
from kernels with the in-tree ANE driver, and this first edge package keeps
those two chips opt-in, so the recipe stays at 0.4.2 until a row from this
package exists on each.
The recipe directory is the same as at 48018d1.
The source is the published v0.4.4 release of joshuaswarren/omarchy-ane
(commit df902f5). sha256sums is the checksum of the GitHub archive
archive/refs/tags/v0.4.4.tar.gz.
0.4.4 is a cleanup release of 0.4.3: no driver, libane or dkms.conf change,
and the same 58 packaged paths. It keeps T6000 and T6020 on by default.
The check() change for kernels with the in-tree driver stays.
- watch joshuaswarren/omarchy-mlx (the url= repo) instead of mlx-omarchy
- global checkdepends gains 'lapack' 'blas' 'vulkan-icd-loader' alongside
'openblas', the shared libraries the wheel loads at check() import
- rebuild_on llvm: omarchy-mlx-vulkan links the shared libLLVM
0.4.3 turns T6000 and T6020 on by default. Each flip rests on one community
row from a kernel with the in-tree ANE driver, not from this package, so
this first edge package keeps them opt-in and stays at 0.4.2. The check()
change for kernels with the in-tree driver stays.
pkgver and sha256sums are those of 7980d7b.
The source is the published v0.4.3 release of joshuaswarren/omarchy-ane
(commit 0477f72). sha256sums is the checksum of the GitHub archive
archive/refs/tags/v0.4.3.tar.gz.
No other recipe line changes: the DKMS build files and the 58 packaged paths
are those of 0.4.2. In 0.4.3 the T6000 and T6020 overlays are enabled, and
the firmware hook also fetches on T6020.
makepkg's upfront dependency install covers only pkgbase-level arrays, so the
per-package openblas depends never reach a fresh container and check()'s
mlx.core import failed with a missing libopenblas.so.0. Declare it as a
checkdepends instead; real installs still get it through depends.
dkms.conf sets BUILD_EXCLUSIVE_CONFIG="!CONFIG_DRM_ACCEL_ANE", so on a kernel
that ships the in-tree driver "dkms build" exits 77 and builds nothing.
check() treated that as a failure, and makepkg stopped in check().
check() now takes exit 77 as "no DKMS build" when the kernel's config sets
CONFIG_DRM_ACCEL_ANE, and prints it. After a build it lists ane.ko and
ane_t6021.ko from the DKMS tree. Every other dkms exit status still fails
check().
v0.7.22 (tag 58724762e) supersedes the burned 0.7.15/16/18/20; 0.7.21 stays
the previous release. Mesa pin unchanged. Checksums verified against two
independent downloads per source.
The source is the published v0.4.2 release of joshuaswarren/omarchy-ane
(commit 545d059). sha256sums is the checksum of the GitHub archive
archive/refs/tags/v0.4.2.tar.gz.
No other recipe line changes: the DKMS build files, the packaged files and
the check() tests are those of 0.4.1. dkms.conf now sets
BUILD_EXCLUSIVE_CONFIG="!CONFIG_DRM_ACCEL_ANE", so DKMS skips a kernel that
ships its own ANE driver and builds on every other kernel.
ZacharyZhang-NY
Ryan Hughes