The dropbox watch failed with "no matching releases" on some runs
(e.g. actions run 37236931512). It is not the network: Dropbox's download
redirect sends a share of requests to a newer build the pattern rejects
on purpose. On 2026-10-04, 96 of 100 HEADs ended at
dropbox-lnx.x86_64-272.4.3798 and 4 at 274.3.4801, which is not an x.4.y
stable build. The redirect provider made one probe, so one unlucky
answer failed the whole watch.
It now probes up to five times and keeps the first final URL that
matches, and curl gets --retry 2 as Fetcher.file already has. Live,
100 discovers against Dropbox all found 272.4.3798 in 103 probes. Two
tests cover a rollout answer before the stable one and every probe
missing.
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.
When edge already holds the version, a PKGBUILD whose recipe changed
(comments and blank lines aside) builds nothing and publishes nothing.
Arch bumps pkgrel only when the built package changes, which is the
reviewer's call, so this is a warning annotation on the PKGBUILD and a
job summary line, not a failure. Comment-only and hook-only changes
stay silent.
A PR can change a package's directory without bumping its version: an
upstream hook, its tests, a README. bin/build then plans nothing, and
the pack step failed on the empty build output, turning the required
result check red (seen on #769). Make the same dry-run check
publish.yml's rebuild job already makes, and skip packing and uploading
when nothing was built. publish.yml finds no artifact for such a merge
and records the package as already published.
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.
* Apply the Intel IPU7 camera's ISP tuning and fix its gain, range and exposure
The XPS 14 / 16 webcam looked soft and grainy because almost none of the
image pipeline was tuned:
- 0011: the graph asks for ISP tuning mode 4, which the OV08X40 tuning
does not carry, so the generic AIC found no tunings and noise
reduction, TNR and sharpening ran on library defaults. Fall back to
the tuning's default ISP container.
- 0010: AIQ emits the raw analog gain register code, which the in-tree
ov08x40 driver halves, so the sensor ran at twice the gain AE and the
ISP noise model assumed.
- 0008: the HAL ignored the requested YUV range and always produced
full-range frames that consumers decode as limited range.
- 0009 + relay config: icamerasrc pinned auto exposure to 1/30 s; a new
fps-range property lets AE lengthen frames in dim light, with gain
capped at 27 dB.
* Guard fps-range against NULL and correct two descriptions
Setting icamerasrc's new fps-range property to NULL, its own default, handed NULL to gst_camerasrc_parse_range, which crashed in strlen(). NULL now leaves the last range in effect, because the HAL has no way to drop a range once set. The value the relay sets goes through unchanged.
The relay comment said AE raises gain past 27 dB once frames reach 15 fps, but gain-range becomes a hard ISO ceiling (manual_iso_max), so gain never goes past it. The 0008 message credited the sensor JSON's yuvColorRangeMode, which only the mock HAL reads.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Free fps-range when icamerasrc is destroyed
finalize never freed the string the fps-range setter allocates, so every icamerasrc element that had the property set leaked it. The other string properties leak the same way upstream and are left to an upstream fix for all of them.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Harden IPU7 PSYS userptr pinning
(cherry picked from commit 5f1d0013b0e37d9229dfb906806dee0e98199035)
* Avoid unverified IPU7 permission assurances
(cherry picked from commit 9ce97d9788f2be508743fe785f8434ccfec7842e)
* Check IPU7 against Omarchy headers without a runtime dependency
Use linux-omarchy-headers only for check(), avoiding Arch headers on installed Omarchy systems and matching the supported kernel build configuration.
Signed-off-by: Afonso Oliveira <afonso.oliveira707@gmail.com>
(cherry picked from commit d0d382c07ea99eca5bb5c52240841db779d24b14)
* Test IPU7 build-only headers and kernel-tree selection
Signed-off-by: Afonso Oliveira <afonso.oliveira707@gmail.com>
(cherry picked from commit eb37cc828fac201a360c35aa1e87a1daf2d5fed1)
* Restrict the IPU7 PSYS node to root
Intel's PSYS driver has two buffer-lifecycle bugs that this package does not fix: a GETBUF that is never mapped leaves the buffer owned by both the PSYS handle and the exported dma-buf, so closing the two is a use-after-free and a double free, and UNMAPBUF drops its mapping reference before clearing the attachment, racing a concurrent dma-buf release. Any account that can open /dev/ipu7-psys0 can reach both.
Nothing but v4l2-relayd@ipu7, which runs as root, opens the node; applications use the v4l2loopback device. With the node at 0600 root:root the camera streams the same, so the video group and the seat user lose nothing and the bugs need root. GROUP and MODE are explicit so the upgrade's change event also tightens nodes on running machines.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Drop the DKMS Intel CVS driver now that linux-omarchy ships it
linux-omarchy and linux-omarchy-bore build drivers/media/i2c/cvs in-tree (CONFIG_VIDEO_INTEL_CVS=m) and carry the same wake-IRQ fix as our 0007 (0542), plus the Nova Lake ACPI ID (0541) that our copy lacks. The DKMS module has the same name and installs under updates/, so on every 7.2+ kernel it displaced the kernel's signed module with an unsigned, older copy: on Nova Lake that copy cannot bind the CVS device and the camera fails, and any later fix in the kernel's driver would be masked. Krzysztof Wilczyński reported the conflict on #723.
Skipping the build only on kernels that carry the driver (BUILD_EXCLUSIVE_CONFIG) would have kept it for stock Arch kernels, but the pacman dkms hook reports every such skip as "exited 77", so every Omarchy kernel update would print a warning. A stock Arch kernel left installed as the fallback boot entry now has no camera.
On upgrade the dkms hook removes intel-cvs and restores the kernel's original module. vision-drivers still covers kernels before 7.2.
* intel-ipu7-camera: build the Lunar Lake HAL plugin and stop rotating its frames
Two Panther Lake assumptions in this package break Lunar Lake boards, where it
is installed by the same hardware detection.
Build both HAL platforms. libcamhal picks its plugin by platform, and a Lunar
Lake machine asks for one that was never built:
CamHAL[ERR] HalAdaptor: load_camera_hal_library, failed to open library:
/usr/lib/libcamhal/plugins/ipu7x.so: No such file or directory
CamHAL[WAR] CameraParserInvoker: parseSensors: No sensors available
so the camera cannot work at all. The proprietary side of it is already
shipped -- libia_aic-ipu7x.so and the rest of that set come from
ipu7-camera-bins today; only the plugin the HAL loads was missing. Upstream
builds both platforms from one configure run and `make install` lays down
/etc/camera/ipu7x/ alongside ipu75xa, including the tuning this hardware
wants (OV08X40_BBG802N3_LNL.aiqb, gcss/OV08X40_BBG802N3_LNL.IPU7X.bin), so the
change is the IPU_VERSIONS list plus 0008, the ipu7x twin of 0006: the
"Intel CVS" pad formats that 1.0.6 added to the ipu75xa sensor config are
needed in the ipu7x one for the same reason, or link validation fails at
stream-on behind the Linux 7.2 bridge entity.
Pick the relay pipeline per board. v4l2-relayd-ipu7.conf rotates every frame
180 degrees, which is right where the sensor is mounted inverted and wrong
here: the sensor reports camera_sensor_rotation = 0 and camera_orientation =
Front, and the picture arrives upside down in every application. camera-init
now writes VIDEOSRC to /run based on the bridge ACPI id and the relay drop-in
reads it. Only INTC10DE takes the new path; INTC10E1, INTC10CF, INTC10E0 and
anything unrecognised keep the packaged pipeline byte for byte, and a boot
where camera-init did not run falls back to it as well.
Verified on a Dell Pro 14 Premium PA14250 (Lunar Lake, INTC10DE, OV08X40 +
HM1092) against intel-ipu7-camera 1.0.6-2 on linux-omarchy 7.2.5-3: with the
package's own intel-cvs DKMS the sensor joins the graph behind "Intel CVS",
the ipu7x plugin built from the pinned commit with 0005 and 0008 resolves
ov08x40-uf on CSI port 0, v4l2-relayd streams 30 fps to /dev/video50 and the
image is upright in a browser.
Note for reviewers: necessary but not sufficient on Lunar Lake. Three more
things this board needs are not in this PR: the sensor probe races the
bridge's runtime suspend (camera-init's `sleep 2` lands while the I2C bus is
still owned by the bridge firmware and ov08x40 reads its chip id as -110),
the in-tree cvs driver's quirk for the Synaptics SVP7500 (06cb:0701) hands
the privacy LED to the host so it never lights, and ipu-bridge before 7.3
does not know the HM1092 IR sensor. Details in #366.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
(cherry picked from commit 9be51b47104da9d115a7d79e04bc2ae5445809fc)
* Derive the Lunar Lake relay pipeline from the packaged one
camera-videosrc-init wrote VIDEOSRC for every board, with a copy of the pipeline the relay config carried when it was written, and its file is read after /etc/v4l2-relayd.d/ipu7.conf. On Panther Lake that replaced this branch's fps-range, gain-range and color-range settings with the old sharpness=80 ev=-1 saturation=10 pipeline. It now writes nothing unless the board is Lunar Lake, and there it takes the packaged pipeline and drops only the rotation, so a later change to the relay config reaches both platforms. It also removes a file left by an earlier run, which camera-init's restart on resume would otherwise keep.
The ipu7x CVS format patch becomes 0012: 0008 is already the YUV range patch.
* Regenerate the Lunar Lake pipeline on every relay start
camera-videosrc-init ran from camera-init.service and sourced /etc/v4l2-relayd.d/ipu7.conf as bash. A config that is valid for systemd but not for bash, such as an unquoted VIDEOSRC, made it fail and Lunar Lake fell back to the rotated pipeline; and because camera-init stays active, editing the config and restarting only the relay kept the override cached since boot.
It now runs as the relay's ExecStartPre, where systemd hands it VIDEOSRC already parsed from the relay's own environment files, and writes the override quoted for systemd's parser. ExecStart re-reads the drop-in's EnvironmentFile and ExecStopPost removes it, so each start sees the current config.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Scale the Lunar Lake ov08x40's analog gain codes too
The Lunar Lake tuning (OV08X40_BBG802N3_LNL.aiqb) carries the same CMC gain table as the Panther Lake one, 1x = code 256, and both platforms use the same in-tree ov08x40 driver, which takes 1x = 128. Without the shift a 4x request ran the Lunar Lake sensor at 8x, the mismatch 0010 fixes on Panther Lake. 0010 now sets analogGainCodeShift in the ipu7x sensor config as well.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Remove the Lunar Lake override before the generator runs
systemd passes ExecStartPre the unit's environment files as they stand when
that command starts, so the generator saw a /run override left behind by a
crash or SIGKILL (anything that skipped ExecStopPost) and took its VIDEOSRC
for the configured one: an edited /etc/v4l2-relayd.d/ipu7.conf would lose to
the stale file. Removing the file in its own ExecStartPre first means the
generator's environment is re-read without it.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Author the HAL and icamerasrc patches from the Omarchy address
---------
Signed-off-by: Afonso Oliveira <afonso.oliveira707@gmail.com>
Co-authored-by: Codex XHigh <noreply@openai.com>
Co-authored-by: Afonso Oliveira <afonso.oliveira707@gmail.com>
Co-authored-by: Kolbas <pkolbas@pm.me>
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
A copy under /usr/lib/node_modules belongs to pacman, and upstream's updater refuses to write there, so neither `openclaw update` nor the Control UI's Update Gateway worked. The package now carries the release instead: the sha256-pinned npm tarball and the install-cli.sh that came in it, from which Omarchy seeds a copy under ~/.openclaw that updates itself.
Joshua Warren