Pin GenAI 2026.4.1.0 to match Arch OpenVINO 2026.4.1. Restrict the package to edge while rc and stable retain 2026.3.1, derive the exact core dependency from the GenAI version, and keep updates manual. Set standard PCRE2 install paths for the current CMake build.
Co-authored-by: GPT 6.1 Sol High <noreply@openai.com>
Driver 0.28.3 through 0.33.3 refused desktop capture on Hyprland with more than one output or one output away from the origin (trycua/cua#4161), which is why the package was held at 0.28.2; 0.33.4 fixes it (trycua/cua#4305). The plugin sources are unchanged from 0.32.0 through 0.33.4 and speak the same input protocol, so the plugin package stays and only its README names the new pairing.
Give the DX13260 aliases their own ownership paths so a stable refresh can retain them while Arch continues updating the stock firmware. Include every speaker ID and target in the boot image. Retain the package identity across channel transitions so pacman can restore the overlay on downgrades. Keep the existing shim for the staged consumer migration.
Co-authored-by: Codex GPT-6.1-Sol XHigh <noreply@openai.com>
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>
* 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>
* 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.
* 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.
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.
Move the Voxtype optional dependency metadata and release bump to a separate draft pending upstream 1.1. The GenAI runtime package can ship independently.
Co-Authored-By: GPT-6 (Codex) <noreply@openai.com>
Bump pkgrel so the builder produces an artifact and installed packages receive the optional dependency metadata. Restrict the Intel/OpenVINO recommendations to x86_64, where these packages are available.
Co-Authored-By: GPT-6 (Codex) <noreply@openai.com>
Co-Authored-By: GPT-6 Astra XHigh (Codex) <noreply@openai.com>
The Panther Lake XPS 13 (audio subsystem 1028:0e54) drives all of its
speakers through two CS35L56 amplifiers behind the CS42L43 codec. Their
DSP firmware aliases (cs35l56-b2-dsp1-misc-10280e54-spkid{1,2,3}) were
added to linux-firmware on 2026-08-18 and ship in Arch's
linux-firmware-cirrus 20260910-2, but the stable channel's Arch snapshot
is still on 20260810-2. Without them the amps run ROM firmware and the
machine is completely silent; upstream 7.2 already selects the sidecar
amplifier path for this SSID, so no kernel change is involved.
Ship the 20260910-2 payload to stable as a self-retiring shim:
- fast ring, no upstream watch (sync: false): the version is deliberately
20260810-3, above the snapshot's 20260810-2 and below Arch's real
20260910-2, so the genuine package supersedes it in the same
transaction that upgrades linux-firmware-other once the snapshot
advances. Bumping pkgver would defeat that.
- the signed Arch package is verified against the Arch packager key in
keys/pgp/ and reinstalled as-is, minus the cs42l45 SDCA tree that Arch
moved out of linux-firmware-other in 20260910: on the stable snapshot
those 190 files are still owned by -other 20260810-2 and would
conflict. The nine 10280e54 links and the 39 new SDCA files are kept.
Verified on a DX13260: cold boot loads 10280e54-spkid1 v4.5.9 on both
amps with "Calibration applied", and a 440 Hz tone measured through the
internal microphones peaks 238x over the noise floor on the stock UCM
bridge route. Delete this recipe once stable's snapshot carries
linux-firmware >= 20260910.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
A channels list of edge alone is the outer bound on where a package may build, so both packages were refused for rc and stable and could only ever reach edge users. The fast ring builds them natively for all three channels, each against its own base mirror, which is how the other prebuilt -bin applications here ship. The channels key has to go rather than sit beside the ring: package_builds_for_mirror checks it first, so an edge-only list would still block the rc and stable builds the ring asks for.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Each package ships libaudiocpp, which upstream's own third-party notices describe as Apache-2.0 with BSD-3-Clause PocketFFT-derived code retained in it, and installs those texts under /usr/share/licenses. A license array of MIT alone describes only the project's own source, so pacman -Qi misreports what the package contains.
Co-Authored-By: GPT-6 Astra XHigh <noreply@openai.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The builder's makepkg.conf enables debug and emptydirs. With strip off, makepkg still takes the debug branch of tidy_strip, creates usr/src/debug/<pkgbase> inside the package to hold debug sources, finds none in a prebuilt tree, and emptydirs then ships the empty directory to every user. Seven of the ten -bin packages here that disable strip already disable debug with it.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The top-level .gitignore excludes pkgbuilds/*/.SRCINFO and pkgbuilds/*/.gitignore, and none of the packages under pkgbuilds/ tracks either. These four were added under the retired pkgbuilds/edge/ path, which that rule does not cover, and the move to pkgbuilds/ carried them along as already-tracked files. The per-package .gitignore negates the repository rule for its own directory and its leading * hides every future file there, so a patch or an .omarchy/upstream.sh dropped beside the PKGBUILD would never show up in git status. The build planner reads PKGBUILD and .omarchy/package.json; the only other reader, bin/package-worktree, takes .SRCINFO as a fallback while importing from the AUR and then removes both files as AUR-only.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Give background agent seats independent keymaps and check foreground keyboard compatibility per operation. Package the downstream patch with separate source integrity and build provenance, retaining the upstream ABI verifier.
Co-Authored-By: Codex XHigh <noreply@openai.com>
The builder discovers package directories directly under pkgbuilds and requires local package metadata. Move Omawake and Omaspeak out of the retired edge directory and restrict their channels to edge so the release pipeline builds them without promoting the release candidates.
Co-Authored-By: GPT-6 Astra XHigh <noreply@openai.com>
Move the package from the stable-only fast ring into the ordinary edge-to-RC-to-stable pipeline. Update the replay and promotion instructions while keeping the Driver 0.27.0 qualification boundary explicit.
Co-Authored-By: GPT-5.6 Sol XHigh <noreply@openai.com>
The in-tree 7.2 CVS driver we ship as the intel-cvs DKMS module requests its
"wake" line with devm_gpiod_get(). On the Dell XPS 14 DA14260 that pin
(\_SB.GPI1 20) is the shared GpioIo the four CS35L57 amplifiers read their
speaker ID from, so with this package installed every cs35l56 probe fails with
"error -EBUSY: Failed to get spk-id-gpios" and the machine has no sound card.
Carry Junjie Cao's upstream fix, "media: i2c: cvs: Get the wake IRQ without
claiming the GPIO" (Cc: stable, Fixes: 8e2b43d2c10b), applied to the
downloaded intel-cvs-core.c in prepare(). makepkg symlinks plain downloads
into srcdir and patch refuses symlinks, so the file is copied first. Drop the
patch once the stable tag we fetch from contains the fix.
Link: https://github.com/thesofproject/sof/issues/11152
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2529031
Linux 7.2 changed how the Intel CVS controller (ACPI INTC10E1 on Panther
Lake) appears to the IPU. ipu-bridge now places it between the sensor and
the IPU CSI2 receiver, like IVSC, and the new in-tree drivers/media/i2c/cvs
driver provides the matching "Intel CVS" V4L2 bridge sub-device. Our
out-of-tree vision-drivers intel_cvs has no sub-device and displaces the
in-tree module of the same name, so on 7.2 the sensor never joins the
media graph and the HAL reports "No sensors available". Both linux-ptl
7.2.3 and linux-omarchy 7.2.5 fail this way.
Ship the in-tree 7.2 CVS driver verbatim as DKMS module intel-cvs for 7.2+
kernels. Arch-derived kernel configs cannot enable CONFIG_VIDEO_INTEL_CVS
themselves: it sits under a menu hidden by MEDIA_HIDE_ANCILLARY_SUBDRV, so
olddefconfig drops it. Keep vision-drivers for kernels before 7.2. Both
dkms.conf files carry a BUILD_EXCLUSIVE_KERNEL regex that the pacman dkms
hook honours.
Teach the camera HAL about the bridge with upstream ipu7-camera-hal commit
f167239 (MediaControl routes the sensor link through "Intel CVS" and finds
the I2C bus through it) and add "Intel CVS" pad formats to the ipu75xa
ov08x40 config so link validation passes. Links stay sensor to CSI2 in the
config and are rewritten at runtime, so the same files work on 7.1.
Feed GitHub release pages to jq through stdin so real pages do not exceed Linux argument limits. Generate an oversized fixture response in the curl mock, and run hook fixtures against a temporary pinned PKGBUILD so routine package updates do not break repository self-tests.
Co-Authored-By: Codex GPT-6 XHigh <noreply@openai.com>
Anthropic ships the Claude desktop app for Linux only through its own
Debian repository, so the package repacks the deb the way
openai-codex-desktop does: extract data.tar.xz, replace the bare
/usr/bin symlink with a launcher that asks Chromium for Wayland
directly, and keep the vendor copyright as the license.
Updates come through the declarative "debian" upstream provider: the
apt Packages index names the newest version, and the per-architecture
pool debs are hashed when one appears. Verified by pinning 1.44121.2
and watching bin/sync-upstream rewrite it back to 1.46388.2
byte-identically.
Release 2026.8.31-3 preserves upstream desktop settings and explicit launch environment without invoking the CLI sandbox setup. Keep incomplete runtimes from blocking the packaged fallback, and use the namespace sandbox consistently in both locations.
Co-Authored-By: Codex XHigh <noreply@openai.com>
Use the same direct executable path for menu launches and URLs, require working user namespaces, and retain only the first-update relaunch gate backport. This avoids the upstream CLI fallback that makes a helper in the user runtime setuid-root.
Co-Authored-By: GPT-6 Codex (xhigh) <noreply@openai.com>
Track main while pinning the initial release commit. Ship the matching upstream installer and Linux namespace sandbox backport, and launch the native user build prepared by Omarchy.
Co-Authored-By: GPT-6 Codex (xhigh) <noreply@openai.com>
Revert the native installer and updater packaging introduced by #325. Keep the prebuilt desktop and existing launcher, updating only the release tag, commit and archive checksum from the previous recipe.
Keep build-time registration private, verify the published launcher, and then let the native command register the final desktop entry. Keep that launcher first on the desktop environment PATH for subsequent registrations.
Co-Authored-By: GPT-6 Codex (xhigh) <noreply@openai.com>
Stage the initial clone before publishing its ownership marker and build the desktop through the same native CLI used by updates. Keep a concurrent checkout intact and reset pkgrel for the version change.
Co-Authored-By: Claude Opus 5 (default) <noreply@anthropic.com>
Install Hermes into its writable native layout instead of shipping a frozen /opt desktop. Preserve the native update path, migrate tagged bootstraps, and keep existing CLI launchers until the desktop is ready.
Co-Authored-By: GPT-6 Codex (xhigh) <noreply@openai.com>
cua-driver update --apply pipes the vendor installer into bash, which
installs a second copy under ~/.cua-driver and links it into ~/.local/bin,
stepping around pacman and the repository's release gate. Upstream offers
no switch for that path, and a /usr/bin wrapper would not cover it either:
the MCP configurations the binary generates record the resolved executable.
prepare() rewrites the installer URL inside the binary, in place and at
equal length, to file:///usr/lib/cua-driver/pm.sh, a stand-in that declines
and names pacman. The build asserts the URL appears exactly twice before
the rewrite and not at all after it, so an upstream change to the updater
stops the build instead of shipping a live self-updater.
Verified in a clean archlinux:base container: pacman -Qkk is clean, the
CLI and cursor-theme helper still run, and on the nightly channel
update --apply prints the notice, exits 1, and creates nothing under
~/.cua-driver/packages or ~/.local/bin.
cua-driver ships prebuilt from the trycua/cua monorepo release feed. The
declarative github provider reads a release feed as a single product and
trips on the monorepo's foreign and hyphenated tags, so a bespoke
.omarchy/upstream.sh selects the newest stable cua-driver-rs release by
tag shape (upstream flags every driver release prerelease; nightlies are
distinguished by tag prefix instead) and reads its checksums.txt manifest.
The vendor tree stays together under /usr/lib/cua-driver with a /usr/bin
symlink, matching upstream's own layout: the CLI resolves its cursor-theme
compiler as a sibling of /proc/self/exe. Verified by installing the built
package into a clean archlinux:base container and exercising the CLI.
Review caught that the allowlist only listed files and symlinks, so a
future deb shipping an empty top-level bin/, sbin/ or lib64/ -- each a
filesystem-owned symlink here, the exact conflict class this guard
exists to close -- would pass it, as would FIFOs and device nodes.
Delete the one known unit, rmdir its emptied parents, and treat any
remaining entry outside opt/ and usr/ as unexpected, whatever its type.
This also stops silently rm -rf'ing future /lib content: anything new
there now fails the build for a human to look at instead.
Verified: clean build ships only etc/, opt/ and usr/; an injected empty
bin/, a stray lib64/ file, and a FIFO each abort package() with the
entry listed. Built via bin/build; installs clean in a fresh container.
26.9.1 added /lib/systemd/system/perplexity-local-runtime-setup.service
to the deb, and wholesale extraction made the package own /lib -- a
symlink owned by filesystem -- so pacman refused every install and
upgrade. The unit could never work here anyway: its setup script
apt-installs Docker and the NVIDIA Container Toolkit and exits on any
distro but Ubuntu, so the Arch equivalents ride optdepends instead.
package() now allowlists what leaves the deb: opt/, usr/, and that one
known unit path (deleted). Anything else stops the build rather than
shipping the next filesystem conflict.
Verified in a clean container: the published -1 reproduces the /lib
conflict; -2 installs fresh and upgrades from 26.8.4 cleanly.
