kernel-agent corrected the @@ hunk counts in the SCS xor-neon patch
(the previous -9,7 +9,12 'fix' was an overcorrection; actual is
-9,6 +9,11). pkgrel=4 build #4 silently tolerated the wrong counts
because the trailer was stripped, but pkgrel=5 with besser#18
behind SCS exposed the inconsistency.
b2sum: ceec602afa8574c74354... -> 50397711a6a3ba522283...
Size unchanged 162 716.
Kernel-agent restored the trailer on the SCS patch (SCS is no longer
last in the includes ordering — besser#18 is). Cumulative grows
+12 bytes for the restored '-- \n2.54.0\n' sentinel.
b2sum: 0eb091ddaba4... -> ceec602afa85...
Size: 162 704 -> 162 716.
pkgrel=5 = pkgrel=4 + the besser#18 lockdep fix added to the
manifest's includes (in-tree mirror of bes2600-dkms d95453c).
Cumulative b2sum: 334c37b5d37067982bd9... -> 0eb091ddaba4a8f1c3c2a78...
Size: 157 446 -> 162 704 (+5 258 = besser#18 patch with trailer
stripped per the convention now established for the LAST patch in
ka-promote concatenation).
This single pkgrel satisfies all three deliverables of the ohm
migration goal: kernel-agent flow + new marfrit-packages pkg + the
besser#18 fix it contains.
After kernel-agent dropped the wrong git-format-patch trailer from
the SCS xor-neon patch (the trailer was a misdiagnosed fix; the
real problem was the @@ hunk counts).
Cumulative b2sum: ad9e2cb533957f218058... -> 334c37b5d37067982bd9...
Size: 157 458 -> 157 446 (12 byte trailer gone).
Re-promoted after kernel-agent fixed malformed @@ hunk counts in the
SCS xor-neon patch (kernel-agent commit ahead of this on
noether/migrate-pinetab2-pkg-and-patches).
b2sum: bd42cd39106298879eeb... -> ad9e2cb533957f218058...
size unchanged at 157 458.
Drops the f8f3ad9 baseline ("18 commits ahead, BLACK-SCREENS ampere"
per fleet/ampere.yaml bisect note) in favor of the kernel-agent-
managed 10-patch set produced by ka-promote from fleet/ampere.yaml.
Baseline: mainline v7.0-rc3 (3daa4f5dc6cc), plus the 10 scope-tagged
patches under marfrit/kernel-agent/patches/{soc,module,board,driver}/:
- 1 soc/rk3588 pwm15 pinctrl
- 6 board/coolpi-cm5-genbook DTS patches
- 3 driver/media Sarma VP9-on-VDPU381 patches (PR #24 closure)
New _commit 48a8c78 reflects this tree state in ~/src/linux-rockchip
(branch vp9-build on ampere, exactly v7.0-rc3 + 10 manifest patches).
End-to-end verified before this iteration was cut (hand-build of the
same tip on 2026-05-18 booted ampere via arch_vp9_test extlinux
label):
- VP9 decode bit-exact HW==SW==libva (sha c8624d7c42db66525f53a02a515bc38d0a17ef39f692660cc7bebb1e2d2e1b48)
- AV1 decode bit-exact HW==SW via kdirect (sha 30d2091158d92f3c5e0a807217c3e7307f873267673d92632e7fb147383e7dd1, av1-vpu-dec is mainline 7.0)
prebuild.sh canonical sha256 cleared — gzip-version-dependent, the
script warns-not-fails on mismatch. First successful kafr2 build can
pin a canonical sha here if a reproducibility audit ever needs it.
Cross-references:
- marfrit/kernel-agent#12 (VP9 enablement closure)
- marfrit/kernel-agent PR #24 (Sarma patch import + ampere.yaml bump)
The n8.1 pin's hwcontext_v4l2request.c deliberately blanks the
transfer-formats list for AV_PIX_FMT_YUV420P10 sw_format (the mapping
target for V4L2_PIX_FMT_NV15), so `ffmpeg -hwaccel v4l2request
-vf hwdownload,format=p010le` on a Hi10P / Main10 input failed at
filter-init with -22 EINVAL — even though kernel-side decode succeeded.
0002-nv15-to-p010-unpack.patch adds an inline NV15→P010 unpack
(5 bytes per 4 samples, little-endian → high-10-of-16) inside
v4l2request_transfer_data_from, exposes AV_PIX_FMT_P010 in
transfer_get_formats for that sw_format, and rejects non-P010
destinations explicitly with ENOSYS instead of silently corrupting
output via av_frame_copy on NV15-packed bytes.
Verified on fresnel (RK3399, linux-fresnel-fourier 7.0-14):
- 5-frame smoke test from issue #21 → exit 0, 13.8MB output
- 20-frame mid-fixture decode → bit-exact HW==SW
sha256 7d9b66d48d8f17b2281da1881c663ecc31722bb218aba1ae23bf28d07aa66b08
- 8-bit baseline (bbb_60s_720p.h264.mp4) still bit-exact HW==SW (no
regression in the existing NV12 path)
- Cross-device repro of original EINVAL on unpatched ampere (RK3588)
pkgrel=4, confirming the bug is upstream-FFmpeg-side, not RK3399-specific
Patch is upstream-able to Kwiboo's v4l2-request-n8.1 branch.
Closes#21.
Tracks upstream lmcp v1.1.1 (commit 9707f7a). Single-bug-fix
release: lmcp:tool() now normalises empty inputSchema.properties
by dropping the key, so Zod-strict MCP clients don't reject
tools/list with "expected: record, received: array".
Discovered live on a hertz-tools deployment where two custom
no-arg tools tripped the check and caused Claude Code to mark
the endpoint as disconnected.
New tarball sha256:
80c2e815aa61a2d3baab051c51cd247bdefa9dd03d72c4867b99c49b6eae9cb9
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PKGBUILD already renamed itself (pkgname=ffmpeg-v4l2-request-fourier,
replaces=(ffmpeg ffmpeg-v4l2-request-git)) but the containing
directory was never moved. This commit completes the rename to align
the path with the package identity and the rest of the -fourier
umbrella (libva, mpv, kwin, qt6-base, chromium, linux-*).
CI workflow path-trigger is wildcard (arch/**), unaffected. Step
names + cp source path updated to the new directory.
Predecessor experimental package (tarball + 18 stacked patches) is
superseded by libva-v4l2-request-fourier (git-tracked fork tip,
iter38 multi-device probe). The successor already declares
replaces=('libva-v4l2-request-ohm-gl-fix') so installs migrate
automatically; this commit just makes the deprecation visible in
README + pkgdesc.
Kept in-tree as historical reference for the ohm_gl_fix Phase 6
audit trail.
CI binary segfaulted on HEVC vaEndPicture even though
/etc/makepkg.conf has OPTIONS=(... !lto ...). Root cause: arch-meson's
wrapper hard-codes `-D b_lto=true` regardless of makepkg.conf, so
the binary still gets cross-function ICF (Identical Code Folding)
under -O2 + LTO.
HEVC is the only codec in the campaign that submits a per-frame chain
of 4 control structs (SPS + PPS + DECODE_PARAMS + SLICE_PARAMS); ICF
finds a near-duplicate per-codec helper across the codec dispatch and
merges them, then the wrong instance's local stack layout is invoked
on the HEVC path → SEGV. The other 4 codecs (H.264, VP8, VP9, MPEG-2)
submit fewer/simpler control structs and tolerate the folding by
accident.
Empirical confirmation from the issue body's binary bisection:
meson build (default debugoptimized) 485 KB HEVC ✓
arch-meson + --buildtype=release 145 KB HEVC ✓
arch-meson + release + -flto 76 KB HEVC SEGV
CI build (this package, 7ac934e-1) 133 KB HEVC SEGV
Fix: append `-Db_lto=false` to the arch-meson invocation.
pkgrel 1 -> 2.
The exec bit was missing on prebuild.sh as committed in PR #15
(it landed mode 0644). Running './prebuild.sh' fails with
'Permission denied'; bash ./prebuild.sh works as a workaround but
the shebang is intended to do its job.
Caught while running the first linux-ampere-fourier build on
boltzmann today. README.md examples show './prebuild.sh' so users
will hit the same error.
Single-bit fix via git update-index --chmod=+x. No content change.
Sibling to kernel-agent PR #8 which lands the scope-tagged board
patches + fleet/ampere.yaml manifest. This PR carries the
makepkg-side recipe.
## Baseline
marfrit/linux-rk3588-marfrit @ f8f3ad9 (mainline v7.0-rc3 + 18 commits):
10 by Markus Fritsche (board DTS + Kconfig + suspend/wakeup + bt)
4 by Shawn Lin (phy: rockchip-snps-pcie3 stability)
2 by Cristian Ciocaltea (clk + dw-dp bridge — Collabora)
1 by Sebastian Reichel (Rock 5 ITX hdmirx — unused by ampere)
1 by Pedro Alves (CLK_SET_RATE_PARENT VOP2 fix)
The 6 board-relevant patches (pwm15 pinctrl + RK806 power-off +
genbook pwm-fan/speaker/USB-C/lid) are scope-tagged in
kernel-agent. The 12 others are 'cherry-picks-in-baseline'
currently — splitting them into scope-tagged patches is a
follow-up.
## Source distribution
The kernel tree isn't pushable to Gitea (boltzmann's working clone
is shallow). Tarball (260MB) doesn't belong in marfrit-packages
either. Pragmatic shortcut: ship prebuild.sh that produces the
tarball locally from $LINUX_RK3588_MARFRIT_TREE (default
~/src/linux-rockchip) just before makepkg runs. PKGBUILD source
array references the tarball by name; makepkg picks it up from
the PKGBUILD dir.
Build flow:
cd arch/linux-ampere-fourier
./prebuild.sh # produces 260MB tarball; idempotent w/ sha check
makepkg -s --noconfirm
Future iteration: host the tarball on Gitea release assets or
packages.reauktion.de/sources/ and switch source to URL.
## What the PR ships
PKGBUILD — the recipe (linux-rk3588-marfrit @ f8f3ad9)
config — snapshot of ampere's /proc/config.gz
linux-ampere-fourier.preset — mkinitcpio preset, /boot/firmware/ paths
extlinux-add.hook — alpm hook, fires on /boot/firmware/Image* changes
extlinux-add.sh — idempotent managed-label injector for
/boot/firmware/extlinux/extlinux.conf
(vfat on mmcblk0p1, ampere-specific path)
prebuild.sh — source-staging helper (see above)
README.md — build + install runbook
## ampere-specific boot path differences vs fresnel
ampere boots from /boot/firmware/ (vfat partition), not /boot/ (root
partition) like fresnel. The PKGBUILD installs Image + initramfs + DTB
under /boot/firmware/ directly. The extlinux-add hook fires on
/boot/firmware/<X> path changes and edits
/boot/firmware/extlinux/extlinux.conf. The mkinitcpio preset writes
initramfs to /boot/firmware/.
Only one PRESET ('default') — no fallback image — because
/boot/firmware is ~1G total and two ~20MB initramfs files plus the
DTB and a couple of kernel-image backups would squeeze it tight.
## Out of scope this PR
- Ask 2 (VP9 enablement) and Ask 3 (AV1 dec) from kernel-agent issue #6
- Build + publish + install (sequenced after this PR + kernel-agent PR #8 merge)
- Splitting the 12 non-board commits into scope-tagged kernel-agent patches
Sibling to kernel-agent PR #7 (which lands the vb2_dma_resv RFC v2
series under patches/subsystem/media/videobuf2/ and updates
fleet/fresnel.yaml to include them). This PR carries the same three
patches in the build-tree-ready form for the linux-fresnel-fourier
PKGBUILD.
Background: Markus iterated v2 locally on boltzmann reaching pkgrel=14
since the 2026-05-09 bootstrap published 7.0-1. v2 attaches the V4L2
producer fence at device_run in slept-OK context per Dufresne's v1
review on linux-media. Drivers opted in here: hantro + rockchip-rga.
Changes:
- pkgrel 1 -> 14
- pkgdesc adds '+ vb2_dma_resv RFC v2'
- source array gains 3 new local patch files (scope-tagged comments
point to where they live in marfrit/kernel-agent)
- sha256sums extended to 11 SKIP entries
No prepare() edit needed — the existing for-loop applies every *.patch
in $srcdir, so the 4/5/6 patches get picked up automatically. config
unchanged (verified diff vs boltzmann's local pkgrel=14 tree).
Pre-built artifacts: linux-fresnel-fourier-7.0-14-aarch64.pkg.tar.zst
and linux-fresnel-fourier-headers-7.0-14-aarch64.pkg.tar.zst already
exist on boltzmann at /home/mfritsche/src/kernel-agent-bootstrap/
build/marfrit-packages/arch/linux-fresnel-fourier/ — will be signed
and published via marfrit-publish-arch after this PR merges (no fresh
compile needed; the artifacts were built locally during the iteration
loop that reached pkgrel=14).
Empirical follow-up to #9. After packaging 150.0.1-4 and installing on
fresnel, MOZ_LOG showed the failure pattern was still present:
D/FFmpegVideo FFMPEG: Using preferred software codec h264
No VAAPI_VLD engagement, no dmabuf surface locking — Gecko bailed
before reaching the patched VAAPI path. Same symptom as issue #8
pre-fix, despite the prefs file being on disk at the expected path.
Root cause: /usr/lib/firefox-fourier/browser/defaults/preferences/ is
NOT a vendor-prefs scan location in Firefox 150. Mozilla's canonical
scan dir is /usr/lib/<app>/defaults/preferences/ — without the
'browser/' prefix.
Verified by hand-copying the same file to /usr/lib/firefox-fourier/
defaults/preferences/ and re-running the H.264 playback test:
D/FFmpegVideo FFMPEG: Requesting pixel format VAAPI_VLD
D/Dmabuf VideoFrameSurface: VAAPI locking dmabuf surface UID 26267
FFMPEG ID 0x4000000 mAVHWFrameContext ...
D/Dmabuf VideoFrameSurface: VAAPI locking dmabuf surface UID 26268
FFMPEG ID 0x4000001 ...
(15+ surface locks)
End-to-end zero-copy DMABUF path engaged, hantro/rkvdec dekodes the
H.264 stream via libva-v4l2-request-fourier iter38b.
pkgrel 4 -> 5. No other PKGBUILD changes.
Triggered by 'pacman -Syu' on fresnel showing local 1:6.11.0-2 newer
than (then-)extra 6.11.0-4. By the time of this commit Arch has moved
on to 6.11.1-1; rebase straight to that.
Diff against Arch's qt6-base 6.11.1 PKGBUILD reduced:
- _pkgver 6.11.0 -> 6.11.1
- pkgrel 3 -> 1 (reset on pkgver bump)
- sha256 of git tag updated to 2eafe504... (matches Arch's 6.11.1 PKGBUILD)
- Drop cherry-pick of 8b54513cdcf6 (qdbus crash fix landed upstream
in 6.11.1; Arch dropped it from theirs as well)
- depends: gcc-libs replaced by libgcc + libstdc++ (Arch split these
into separate packages between 6.11.0 and 6.11.1)
- Build flag: -DFEATURE_sql_ibase=OFF removed, -DFEATURE_mimetype_database=OFF
added (Arch toggled in 6.11.1)
Kept (the reason this fork exists):
- 0001/0002/0003 GL_R8-on-ES3 patches (Mali GLES3 KWin compositor stall fix)
- qt6-base-cflags.patch + qt6-base-nostrip.patch (system CFLAGS + skip strip)
- qt6-xcb-private-headers-fourier sub-package (depended on by other fork pkgs)
- epoch=1 (precedence guarantee until upstream lands GL_R8/ES3 fix)
Patches NOT dry-run-verified against 6.11.1 source (qt clone is multi-GB
and impractical to fetch for a quick check). They touch glyph cache and
RHI gles2 paths that have been stable since Qt 6.10; expected to apply
cleanly. Will revert pkgrel and re-pin if first build hits hunk failures.
Triggered by 'pacman -Syu' on fresnel showing local 1:6.6.4-1 newer
than extra 6.6.5-1 (epoch wins, but our base lags upstream).
- pkgver 6.6.4 -> 6.6.5
- pkgrel 3 -> 1 (reset on pkgver bump)
- sha256sum updated for new tarball
- 0001-transaction-bypass-watchDmaBuf-fence-wait.patch dry-run verified
clean against 6.6.5/src/wayland/transaction.cpp
Epoch=1 retained until upstream lands a proper V4L2 implicit-sync
fence-wait bypass (the patch-header hypothesis is still being tested
through ohm/fresnel HW-decode validation; not upstreamable yet).
Follow-up to #10. The subdir layout I assumed worked turned out to not
work — per 'man PKGBUILD':
The filename in the array must NOT include any path components like ./
makepkg's source-staging only honors basenames; the patches/ subdir
references staged the files but the basename-lookup at apply time
failed with the same 'not found in build directory' error that #9 hit.
I copied the chromium-fourier convention thinking it was proven, but
chromium-fourier has no CI either and likely has the same latent
breakage (separate issue, not in this PR's scope).
The actually-working pattern is the mpv-fourier one: patches at the
top level next to the PKGBUILD. mpv-fourier iter2 just built green
on CI (#92) with that layout.
This commit:
- Moves all 8 patches (5 fourier + 3 arch upstream) from patches/
to arch/firefox-fourier/ via git mv (preserves blame).
- Removes the now-empty patches/ subdir.
- Strips 'patches/' prefix from source array entries.
- Strips '/patches' from prepare() patch -i paths.
No semantic change to the patch content or apply order.
pkgrel 3 -> 4.
The PKGBUILD has been structurally broken since at least the 150.0.1
import: source array referenced patches at top level ('0001-...patch')
but the actual files live in patches/ — makepkg searched for them in
the package root and failed before doing any work. The arch-0002/3/4
upstream toolchain patches (clang 22, glibc 2.43, Rust 1.95) weren't
shipped in the repo at all.
Caught when boltzmann tried to build 150.0.1-2 (PR #9 follow-up); fails
at the source-staging phase with:
==> ERROR: arch-0002-Bug-2033279-Make-enable-rust-simd-work-with-Rust-1.9.patch
was not found in the build directory and is not a URL.
Why nobody noticed: firefox-fourier has no Gitea Actions job (too heavy
for the runner pool). The shipped 150.0.1-1 .pkg.tar.zst was produced
by hand-staging files; the PKGBUILD itself never reproduced from a
clean checkout.
This commit:
- Moves all source-array patch references under patches/ to match the
on-disk layout (same convention as chromium-fourier).
- Updates prepare() paths accordingly.
- Adds arch-0002/3/4 patches fetched verbatim from
https://gitlab.archlinux.org/archlinux/packaging/packages/firefox
(raw/main/{0002,0003,0004}-...patch). Renamed with arch- prefix in
the repo to avoid namespace collision with the local 0001..0005.
- Adds the previously-omitted 0005-rdd-sandbox-v4l2-media-ctl.patch
to the source array + prepare(); this is the patch that broadens
the RDD sandbox so /dev/media* and /dev/video* ioctls reach the
decoder child (README §1 enumerates it as load-bearing for the HW
path). It was present in patches/ but not wired up.
Dry-run verified all 8 patches apply cleanly against firefox-150.0.1
source (some hunks offset by ≤3 lines, no conflicts).
pkgrel 2 -> 3.
Three prefs that gate the patched VAAPI / V4L2-request code path are
'false' upstream and need to be 'true' for the libva-v4l2-request
backend to actually engage on RK3399 / panfrost EGL:
widget.dmabuf.force-enabled
media.hardware-video-decoding.force-enabled
media.ffvpx-hw.enabled
Without them, Gecko's DMA-BUF probe silently fails (panfrost EGL
doesn't trip the right detection), the (Intel-tuned) HW-vs-SW cost
heuristic picks SW, and the FFvpx PDM never selects its HW-capable
variant for VP8/VP9. Net result: fresh profiles SW-decode despite the
0001..0004 unlock patches being applied.
Shipped as a vendor-default file at:
/usr/lib/firefox-fourier/browser/defaults/preferences/rockchip-fourier-defaults.js
Lower precedence than user.js / about:config — power users debugging
HW decode can still flip them off without touching the package.
pkgrel 1 -> 2.
Closes: #8
Carries the fork from libva-multiplanar iter8 close (2026-05-06) to
fresnel-fourier iter38b (2026-05-14): multi-device probe so a single
libva session serves rkvdec (H.264 + HEVC + VP9) + hantro (MPEG-2 +
VP8) without LIBVA_V4L2_REQUEST_VIDEO_PATH overrides, plus the
MAX_PROFILES bounds-check fix from iter38b.
Required by the fresnel-fourier README's HW-decode stack (vainfo
exposes all 10 profiles in one session, byte-exact bench verified
across 5 codecs).
68 commits between the old pin (65969da3) and the new (7ac934e0).
pkgver() recomputes the rev count at build time; the static placeholder
is bumped from r280 to r348 to reflect the new pin.
Adds Kwiboo / Langdale's 2024-08 patches (0001-meson + 0002-vo-hwdec-drmprime)
so AV_HWDEVICE_TYPE_V4L2REQUEST flows through mpv's drmprime VO hwdec and
`--hwdec=v4l2request` engages against the dmabuf-wayland VO instead of failing
with "Could not create device". The matcher previously filtered on
AV_HWDEVICE_TYPE_DRM and rejected v4l2request even when libavcodec's hwaccel
returned a valid PRIME descriptor.
PKGBUILD: pkgrel 9 → 10, source[] picks up both new patches, prepare() applies
them before the existing 0001-vo_dmabuf_wayland cache-sync workaround,
meson build flag -Dv4l2request=enabled added so the new option compiles in.
Stacks on top of iter1 (713a856): the dma_buf cache-sync workaround stays
load-bearing for the existing vaapi_dmabuf and drmprime_dmabuf import paths;
this iter only adds the wiring for the drmprime VO's hwdec selector.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Workaround for the dmabuf-wayland green-frames bug
(marfrit/dmabuf-modifier-triage#1). iter1 phase 2 source-read of
KWin 6.6.4 + Mesa 26.0.6 ruled out the original H1/H2 hypotheses
(panfrost offset handling and KWin wl_dmabuf import are clean) and
matched the green tone to BT.601 limited-range YUV(0,0,0) -> RGB(0,
135, 0). Conclusion: panfrost reads zero-fill memory despite hantro
having written real data — a cache-coherency / synchronization gap.
V4L2 doesn't attach implicit fences (dma_resv) to CAPTURE buffers
on VIDIOC_DQBUF; this gap is the same one our vb2_dma_resv RFC v2
addresses upstream. The userspace workaround is to issue
DMA_BUF_IOCTL_SYNC(SYNC_START|SYNC_RW) + SYNC_END(SYNC_RW) on each
EXPBUF fd before submitting to the compositor — invokes the producer
driver's begin_cpu_access / end_cpu_access path, which on most ARM
SoCs flushes write buffers and synchronizes coherent memory.
Patch covers BOTH vaapi_dmabuf_importer (the path our test exercises
via `mpv --hwdec=vaapi`) and drmprime_dmabuf_importer (for symmetry
when used via `--hwdec=drmprime`).
If this works, ship it; if it doesn't, hypothesis space narrows
further to GPU-side cache invalidation in panfrost's kernel-mode
dma_buf import path (H7).
pkgrel 8 -> 9. Patch sha256
6c929bea7636b8d81b63a1275ba1d8a471fe2f249fc23509043ace6cf9b076a7.
FFmpeg's configure script resolves the compiler via `which gcc` and bakes
the absolute path /usr/bin/gcc into the generated makefiles. With
BUILDENV=(distcc ...) makepkg prepends /usr/lib/distcc/bin to PATH, but
configure has already resolved past the shim — so every translation unit
compiles locally despite the worker pool being available.
Pass --cc='distcc gcc' / --cxx='distcc g++' to configure when the distcc
shim path is present. Falls back to plain gcc/g++ otherwise so a !distcc
build is unaffected.
Validated locally: distcc-avahi 3.4-19 on fermi exposes
/usr/lib/distcc/bin/gcc -> ../../../bin/distcc, and the four-worker pool
(tesla, dcc1, dcc2, boltzmann) is reachable via DISTCC_HOSTS=+zeroconf.
Earlier ffmpeg builds on run 76 logged zero connections on any worker
despite distcc-avahi being correctly installed — this is the missing
piece.
Mirror Arch upstream's /usr/lib/$pkgname/bin/<compiler> -> ../../../bin/distcc
symlink farm in package(). Without it, makepkg's buildenv_distcc() check
[[ -d /usr/lib/distcc/bin ]] fails, BUILDENV=(distcc ...) is silently a
no-op, and aarch64 builds compile locally instead of distributing.
Also keeps the legacy /usr/lib/$pkgname/<compiler> -> ../../bin/distcc
flat layout that update-distcc-symlinks(1) used to produce, so distcc
hosts using the Debian-style invocation continue to work.
Drop the post_install/_warn_masq update-distcc-symlinks dance since the
symlinks now ship in the package. Add pre_upgrade hook that strips
untracked legacy symlinks from <= 3.4-18 so pacman can drop the new
tracked ones in their place without a file conflict.
Compiler set matches Arch upstream (c++ c89 c99 cc clang clang++ cpp g++
gcc, plus \$CHOST-{gcc,g++,gcc-\$(gcc -dumpversion)}).
Run #73 hit:
warning: ffmpeg-v4l2-request-fourier-... is up to date -- reinstalling
File /var/cache/pacman/pkg/ffmpeg-v4l2-request-fourier-...pkg.tar.xz
is corrupted (invalid or corrupted package (checksum)).
The corrupt cached file is left over from the ccache misadventure
that interrupted earlier builds mid-download. Pacman doesn't auto-
redownload corrupt cached files in this code path. Add a targeted rm
of cached ffmpeg-v4l2-request-fourier-*.pkg.tar.* before the install
so the next pacman -S downloads fresh.
Yak shave count for mpv-fourier-aarch64 to actually run: 6
(pkgrel→4 to outrank stock, [marfrit] config, ffmpeg-v4l2-request
explicit dep, conflict-prompt acceptance, pipefail-friendly printf,
cache rm).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Run #70 actually succeeded at the pacman level (log shows ffmpeg
removed and ffmpeg-v4l2-request-fourier installed) but the step
exited non-zero. Cause: bash's set -o pipefail (Gitea Actions
default) sees `yes` get SIGPIPE'd when pacman closes its stdin,
yes exits 141, pipeline reports 141 → step fails.
Replace `yes y | pacman -S ...` with finite-stream printf that
exits 0 cleanly. Three y's cover all expected prompts.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Run #69 hit:
ffmpeg-v4l2-request-fourier-2:... and ffmpeg-2:8.1.1-1 are in conflict.
Remove ffmpeg? [y/N]
error: unresolvable package conflicts detected
pacman -S --noconfirm defaults [y/N] prompts to N and refuses the swap.
Switch to `yes y | pacman -S ...` (without --noconfirm) to accept the
conflict-removal prompt cleanly.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Run #68's mpv-fourier-1:0.41.0-4 fails to start on ohm with libavcodec
ABI mismatch:
build version 62.28.101 incompatible with runtime version 62.28.100
Build host (fermi) pulls stock arch ffmpeg via makepkg --syncdeps —
that ffmpeg currently ships libavcodec 62.28.101. Consumer host (ohm)
runs marfrit/ffmpeg-v4l2-request-fourier (Kwiboo's fork pinned to
commit b57fbbe, libavcodec 62.28.100). The build/runtime drift
silently aborts mpv at startup before the version banner prints.
Fix: configure [marfrit] on fermi and pre-install our ffmpeg before
makepkg --syncdeps. mpv-fourier PKGBUILD now depends on
ffmpeg-v4l2-request-fourier explicitly (replacing the generic ffmpeg
dep), making the build target unambiguous.
Workflow change: new step in mpv-fourier-aarch64 between "install
deploy ssh key" and "makepkg" — imports the marfrit signing key into
pacman-key, appends [marfrit] block to /etc/pacman.conf if absent,
syncs db, installs marfrit/ffmpeg-v4l2-request-fourier explicitly so
makepkg --syncdeps finds the dep already satisfied via provides=ffmpeg.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Stock arch ships mpv 1:0.41.0-3. Our 1:0.41.0-2 is OLDER per vercmp, so
pacman -Syu refuses to apply replaces=mpv (no auto-downgrade across the
replaces relation). Bump to pkgrel=4 to win the comparison.
Going forward: when stock arch bumps mpv pkgrel, mpv-fourier needs a
matching bump.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Run #66 failed at meson setup with "Feature win32-threads cannot be
enabled". Root cause: arch-meson defaults to --auto-features=enabled,
which makes mpv's platform-specific features (win32-threads, etc.)
required and fails the build on Linux. Stock arch's PKGBUILD passes
--auto-features=auto explicitly to make features opt-in instead of
required.
Adopted stock arch's full meson_options block:
--auto-features auto
-Dlibmpv=true
-Dgl-x11=enabled -Dcaca=disabled -Ddrm=enabled
-Dcdda=enabled -Ddvbin=enabled -Ddvdnav=enabled
-Dlibarchive=enabled -Dopenal=enabled
-Dsdl2-audio=enabled -Dsdl2-video=enabled -Dsdl2-gamepad=enabled
Also matched stock makedepends (added ladspa, vulkan-headers, dropped
ninja/pkgconf which are pulled in transitively), added !emptydirs option,
adopted the package() pkgconfig-cleanup + docs/scripts install pattern,
added epoch=1 to match stock's versioning (so replaces= works cleanly).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mpv on ohm is currently stock arch from [extra]. To ship the
vo_dmabuf_wayland plane-semantics fix per
marfrit/dmabuf-modifier-triage#1, we need an mpv-fourier package
following the same fourier-umbrella pattern as kwin-fourier,
qt6-base-fourier, firefox-fourier, libva-v4l2-request-fourier.
This commit lays down:
- arch/mpv-fourier/PKGBUILD pinning upstream mpv 0.41.0 tarball, with
empty patch slot in prepare(). replaces=mpv. provides=mpv,libmpv.so.
When iter1 produces the patch, add it to source=()/sha256sums=()
and uncomment the patch -p1 line.
- arch/mpv-fourier/README.md documenting why + tracker links
- .gitea/workflows/build.yml job mpv-fourier-aarch64 chained after
libva-v4l2-request-fourier-aarch64 for marfrit.db serialization.
Same fermi LXC runner, same makepkg → sign → repo-add → rsync flow.
Initial scaffold builds vanilla mpv 0.41.0 with no fourier patches —
once iter1 lands, bump pkgrel and add the patch.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Production-tip successor to the experimental libva-v4l2-request-ohm-gl-fix
(tarball + 18-patch stack, never published). Tracks the libva-multiplanar
campaign fork's git history directly via git+commit pin, so iteration
sweeps land in a clean linear log instead of a growing patch stack.
Pinned commit 65969da3 = libva-multiplanar iter8 close (last commit on
master before fresnel-fourier work began layering MPEG-2 rewrites on top
2026-05-08). Promote to a later pin only after a future iteration closes
cleanly.
Workflow job mirrors ffmpeg-v4l2-request-aarch64 (same fermi LXC runner,
same makepkg → sign → repo-add → rsync-to-nc.reauktion.de pattern), and
chains via needs: ffmpeg-v4l2-request-aarch64 to serialize marfrit.db
updates. nasm dropped from bootstrap (libva has no x264-style asm).
replaces=(libva-v4l2-request libva-v4l2-request-ohm-gl-fix) covers both
stock Arch and locally-installed predecessor copies; predecessor was
never published so no marfrit.db collision.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Stock distcc and earlier distcc-avahi releases ship /etc/conf.d/distccd
with DISTCC_ARGS=, while our distccd.service reads $DISTCC_OPTS. On
hosts that had stock distcc installed first, pacman keeps the existing
conf file (it's marked backup=) so the rename never happens — distccd
starts with empty options, falls back to --allow-private, and warns
about missing /usr/lib/distcc masquerade dir.
Add a post_install/post_upgrade .install hook that:
- detects DISTCC_ARGS= in /etc/conf.d/distccd and renames to DISTCC_OPTS=
(keeping a timestamped backup beside it)
- runs update-distcc-symlinks if /usr/lib/distcc is unpopulated
- prompts the operator to restart distccd if it's already active
Bumps pkgrel to 18.
Hit on ampere 2026-04-29 during fourier-campaign distcc enrollment;
likely lurking on every host with stock-distcc legacy state.
claude-noether
test0r
claude-noether
marfrit