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>
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>
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
Import the unchanged recipe from the cua-driver-rs-v0.24.0 build kit. Keep fast-ring automatic builds disabled pending native channel qualification and document explicit ABI updates and compositor restarts.
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.
Every channel has failed since 0.2.1 landed: one package failing fails the
whole build, and the build step aborts the release before sign, promote or
sync. Nothing has published on edge, rc or stable since 2026-09-11, and 26
built packages have been rebuilt and discarded every cycle.
backend::redo::tests::redo_refuses_changed_sources_and_destination_collisions
writes a file and immediately asks redo to notice the edit. flea decides
"changed" from ctime alone -- src/backend/undo.rs records (ctime, ctime_nsec)
as the whole identity -- and this kernel stamps ctime from the coarse clock,
so two writes microseconds apart share a timestamp and the guard sees no
change. redo returns Ok where the test demands Err, which is why it fails
almost every run rather than intermittently.
Measured on this builder: 196/200 back-to-back write pairs on /dev/shm and
192/200 on the root filesystem produced an identical ctime. That also retires
the premise of 82363cb: /dev/shm does not buy finer timestamps here, so moving
the suite to tmpfs could never have fixed this, and the comment saying it does
is corrected. A probe cannot decide this at runtime either -- one using stat
reports the filesystem as fine-grained, because the stat subprocess alone
costs more than the granule it is trying to measure.
Both halves belong upstream in thisisgm/flea: the test assumes a resolution
the kernel never promised, and the identity it exercises cannot see a
same-granule edit, which is a real hole in undo/redo rather than only a test
artifact. Skipping one test is the narrow fix; holding the package back would
have stalled the other 26.
Only this test is affected. new_file_is_recreated_but_changed_or_replaced_
files_survive_undo asserts the same refusal and passes, because enough work
separates its write from the identity capture to cross a granule.
Verified with bin/repo build --package flea: filesystem suite 63 passed,
main suite 528 passed, flea 0.2.1-3 built.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ryan Hughes