Closes#55.
PR #47 routed ffmpeg-v4l2-request-debian and mpv-fourier-debian to
runs-on: debian-aarch64 (bohr), but their install-deps steps still
called pacman -Syu. That is a latent break that would surface on the
next pkgver bump (currently silent-skipped by check-already-published.sh
since pool versions match the staged PKGVER).
This patch follows PR #50's pattern (daedalus-v4l2{,-dkms}-debian):
- Replace retry pacman -Syu ... with retry apt-get install ...
- Translate Arch package names to Debian (base-devel -> build-essential,
pkgconf -> pkg-config, libdrm -> libdrm-dev, x264 -> libx264-dev, etc.).
- For mpv: drop the "configure [marfrit] repo + pre-install
ffmpeg-v4l2-request-fourier" step entirely. Under apt, stock
libavcodec-dev / libavformat-dev / libavutil-dev provide trixie-ABI
headers matching what mpv-fourier's binary will see at runtime; the
daemon dlopens the fourier libs if installed but doesn't link against
them at build time.
Validated upstream: equivalent debian build-deps installed cleanly in
PRs #44 (libva) and #50 (daedalus).
PR #47 moved the daedalus-v4l2-debian + daedalus-v4l2-dkms-debian
jobs from runs-on: arch-aarch64 to runs-on: debian-aarch64, but
left the install-deps steps using `pacman -Syu` — which doesn't
exist on the Debian runner. Both jobs were latent-broken; the
break only surfaces once a daedalus pkgver actually changes (the
rebuild guard skipped them in runs #133-134 since nothing about
daedalus moved between PR #47 and PR #48).
PR #49 bumped both daedalus packages to 0.1.0+r20+g3dd0eb0 (the
DAEMON-PPS H.264 SPS/PPS NAL synth landing) — so run #135's
daedalus-debian + daedalus-dkms-debian jobs actually executed and
hit the broken pacman step. Result: instant failure on `pacman -Syu`.
Fix: replace the pacman invocations with apt-get equivalents.
For daedalus-v4l2-debian, drop the [marfrit] ffmpeg-v4l2-request-
fourier preinstall — Debian's stock libavcodec-dev / libavformat-
dev / libavutil-dev provide matching headers (both trixie ffmpeg
and the daedalus daemon's runtime dlopen target are libavcodec
61.x), and the daemon never link-binds against libav (Option γ —
dlopen at runtime), so any header set with the right struct
definitions works.
Verified end-to-end on higgs (Debian trixie aarch64, equivalent
to bohr): clone the source tarball, run build-deb.sh, produces
daedalus-v4l2_0.1.0+r20+g3dd0eb0-1_arm64.deb cleanly (10/10
ninja steps, daedalus_v4l2_daemon binary linked).
NOTE: ffmpeg-v4l2-request-debian (line ~907) and mpv-fourier-
debian (line ~1048) have the same pacman-on-Debian bug from
PR #47 but are still skipped because their pkgvers haven't moved.
Not fixing those in this PR to keep the change focused on
unblocking DAEMON-PPS verification — they'll need the same
treatment the next time they bump.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Closes task #134 work.
PR #44 showed the cross-distro ABI hazard for `libva-v4l2-request-fourier-debian`: building on Arch (libva 2.23) produced `__vaDriverInit_1_23`, which trixies libva 2.22 runtime cant bind. Same hazard applies to other fourier-debian jobs that link against debian-native libs.
**Moved from runs-on: arch-aarch64 → debian-aarch64:**
- ffmpeg-v4l2-request-debian
- mpv-fourier-debian
- daedalus-v4l2-debian
- daedalus-v4l2-dkms-debian
**Left alone (arch=all, no native compile against debian libs):**
- lmcp-debian
- claude-his-debian
Depends on PR #46 (label vs name fix) being merged so `debian-aarch64` actually routes to bohr.
Reviewed-on: #47
5feab57 set runs-on to actrunner-debian-aarch64-bohr, which is the
display name of the bohr runner, not a label. Gitea Actions matches
runs-on against labels — the actual labels on bohr are debian-trixie,
aarch64, debian-aarch64. Using the runner-name as runs-on leaves the
job unrouted (no matching runner).
Two follow-ups to PR #44 (which landed the libva-dev ABI pin):
- `051da5e` switch runs-on from arch-aarch64 → debian-aarch64-bohr
- `5feab57` fix runner label: actrunner-debian-aarch64-bohr (label name mismatch in 051da5e)
**Squash on merge** to keep main history clean.
Co-authored-by: Markus Fritsche <mfritsche@reauktion.de>
Reviewed-on: #45
Co-authored-by: Claude (noether) <claude@reauktion.de>
Co-committed-by: Claude (noether) <claude@reauktion.de>
Per @marfrit on PR #44 review: a native Debian trixie aarch64 runner
(debian-aarch64-bohr) is available — use it instead of the sysroot
hack from the previous commit.
The sysroot approach worked but was a workaround for not having the
right runner. Native trixie runner is much cleaner:
- libva-dev installs via apt-get directly from trixie's archive
(2.22.0-3) — pkg-config returns trixie headers, driver compiles
in __vaDriverInit_1_22 naturally.
- No need to symlink libva.so.2 -> libva.so or rewrite .pc prefixes.
- No bsdtar/ar/dpkg-deb juggling on an Arch runner that doesn't
natively have dpkg.
Changes from PR v1:
- .gitea/workflows/build.yml: libva-v4l2-request-fourier-debian
runs-on: debian-aarch64-bohr (was arch-aarch64). Build-deps
installed via apt-get instead of pacman -Syu.
- build-deb.sh: drop the sysroot download / pkgconfig rewrite /
symlink block. Keep the post-build ABI sanity check (nm -D |
grep __vaDriverInit_1_22) — same defensive role as before, with
an updated error message that points to the expected runner.
- debian/.../changelog: -2 entry rewritten to describe the runner
move instead of the sysroot.
Tested approach on boltzmann (aarch64): meson build against trixie
sysroot produces __vaDriverInit_1_22 (proves the source compiles
correctly with VA-API 1.22 headers). Native runner build will
follow the same path, just without the explicit sysroot setup.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Wire .gitea/scripts/check-already-published.sh into every job in
build.yml. New step `skip if already published` (id: skip-check) lands
right after actions/checkout@v4 and runs the helper against the job's
recipe-dir. Subsequent steps gain `if: steps.skip-check.outputs.skip
!= '1'`, except `wipe secrets` which keeps its existing
`if: always()`.
Recipe-dir per job is taken from each job's existing `cp -r arch/...`
or `cd debian/...` line — no guessing.
Effect: on push where only e.g. firefox-fourier changed, 13 jobs HEAD
the pool, see 200, and short-circuit; only firefox-fourier rebuilds.
Verified live against packages.reauktion.de — current branch tip
would skip 10/14 jobs.
Patch is text-based (no PyYAML round-trip) so comments and blank
lines stay where they were. Diff is 190 lines added, 0 removed.
iter9 of the panvk-bifrost campaign — operator-confirmed Vulkan output
on PineTab2 (Mali-G52 r1 MC1) 2026-05-20.
Patches Mesa 26.0.6's PanVk Vulkan driver:
- VK_KHR/EXT_robustness2 + nullDescriptor exposed for PAN_ARCH 6/7
- has_vk1_1 / has_vk1_2 = true on Bifrost
Patches applied via sed in PKGBUILD prepare() (cleaner than maintaining
a Mesa fork for two two-line tweaks; upstream context drifts between
Mesa releases would make a literal .patch brittle).
Co-installs at /usr/lib/panvk-bifrost/ — stock mesa untouched. Stock
libvulkan_panfrost.so and its ICD JSON keep working for everyone not
opting into the patched driver.
Ships /usr/bin/brave-vulkan that wires up:
VK_ICD_FILENAMES=/usr/lib/panvk-bifrost/icd.json
PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1
MESA_VK_VERSION_OVERRIDE=1.2 # ANGLE needs apiVersion>=1.1; the
# has_vk1_x flags don't move it, so
# the env-var override carries that
brave --use-gl=disabled --enable-features=Vulkan --use-vulkan=native
--ozone-platform=x11 --no-sandbox --disable-gpu-sandbox
--ignore-gpu-blocklist "$@"
Side-steps the stock "GLES3 is unsupported / GPU process exits" failure
documented in panvk-bifrost/README's "Consumer-side benefit" section.
Known limitation: WebGL/WebGL2 in-page won't work — ANGLE needs GLES3
which needs VK_EXT_transform_feedback, which PanVk-Bifrost doesn't
currently support. Browser chrome + standard page rendering work fine.
Gitea Actions job mesa-panvk-bifrost-aarch64 added to build.yml,
patterned on libva-v4l2-request-fourier-aarch64. Mesa build is slow
(~30-60min on actrunner-aarch64). Standalone (no needs:),
continue-on-error so it doesn't block other jobs.
Campaign artifacts: ~/src/panvk-bifrost/{README.md, phase8_iteration9_close.md,
phase0_evidence/iter9_brave_vulkan_breakthrough.txt}.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two deterministic CI failures from run 115 (PR #34 wiring):
mpv-fourier-debian (task 566): dpkg-deb refuses `Conflicts: pkg1 |
pkg2` — Debian policy doesn't allow alternatives in Conflicts.
Split into separate entries.
daedalus-v4l2-debian (task 563): pacman -Syu pulled stock arch
ffmpeg which conflicts with the already-installed
ffmpeg-v4l2-request-fourier left behind by the earlier
mpv-fourier-aarch64 job (it configures [marfrit] + pre-installs
the fourier ffmpeg). Drop 'ffmpeg' from the pacman line; mirror
the [marfrit]+pre-install step from mpv-fourier-debian. Daedalus
only needs libavcodec/libavformat headers which the fourier
package supplies.
The debian/{ffmpeg-v4l2-request-fourier,libva-v4l2-request-fourier,mpv-fourier,daedalus-v4l2,daedalus-v4l2-dkms}
recipes have been sitting in the tree with no CI trigger since 2026-05-18.
build-deb.sh exists and is runnable, but nothing fires it — so no .debs
were ever pushed to packages.reauktion.de/debian/pool/.
Mirror the lmcp-debian / claude-his-debian pattern: build natively on
the arch-aarch64 runner (dpkg-deb is in extra), rsync the .deb to
hertz's incoming dir, trigger publish-deb for bookworm + trixie.
mpv-fourier-debian also pre-installs ffmpeg-v4l2-request-fourier from
[marfrit] for libavcodec ABI symmetry, matching the arch sibling job.
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.
`rm -rf /root/.gnupg` removes the homedir and its socket file but does
not kill the gpg-agent process that was watching the original inode.
The next gpg invocation on the fresh homedir then races a half-dead
agent: `gpg --import-ownertrust` reports "can't connect to the
gpg-agent: IPC connect call failed" and the import-key step exits
non-zero under set -e, killing the job.
Run 78 lmcp-any landed on this. The previous run's ffmpeg job spawned
an agent at /root/.gnupg/S.gpg-agent and was still alive when lmcp-any
prep ran.
Add `gpgconf --homedir /root/.gnupg --kill all` immediately before each
of the six `rm -rf /root/.gnupg /root/repo_pass` sites. `|| true` keeps
the first-ever run's missing-agent case quiet.
distcc-avahi 3.4-19 + the ffmpeg --cc=distcc-shim landing means fermi can
actually fan compiles out across the zeroconf pool. With MAKEFLAGS="-j$(nproc)"
the runner only had ~3 outstanding TUs at a time, leaving ~57 worker slots
idle. Bump to -j60 to fill the pool (tesla 16 + dcc1 16 + dcc2 16 +
boltzmann 10 + a few local).
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>
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>
First carrier package for the Fourier umbrella. Tracks Kwiboo's
v4l2-request-n8.1 branch (ffmpeg 8.1 base) pinned at commit b57fbbe —
bump _commit to rebase onto newer tip. CI job chained after
claude-his-any so it serializes on the shared aarch64 repo-db;
continue-on-error: true so long ffmpeg builds don't block the debian
downstream.
Deliberately diverges from the AUR package:
- AUR pins 6.1.1 with epoch=2 → would downgrade stock Arch ffmpeg 2:8.1-3.
We track 8.1 so install is a sideways swap, not a regression.
- AUR pulls X11/AMF/CUDA/FireWire/AviSynth/OpenMPT/Bluray/OpenMAX/JPEG-XL/
Theora/XVid/rsvg/soxr/ssh/vidstab/modplug/SDL2/Vulkan/JACK/GSM/Speex —
dropped here; none are needed on a Wayland ARM video-decode fleet.
- AUR uses #branch=…, sha256sums=(SKIP) → every build is tip-of-branch,
not reproducible. We pin via #commit=<sha>.
Kept: encoders (libx264/libx265/libvpx/libdav1d), VAAPI, libdrm, libv4l2,
neon, OpenGL, PulseAudio, subtitle/font stack, gnutls TLS. SDL2 dropped
means no ffplay binary (mpv covers interactive playback).
provides=(ffmpeg) conflicts=(ffmpeg) so it replaces stock ffmpeg on the
target host deliberately. Primary consumers: ohm (Fourier step 5),
fresnel, ampere.
Observed two flakes in 24h — distcc-avahi-aarch64 at 66a7050 and lmcp-any
at 22060e0. Journal for both showed the job starting then failing silently
before any sudo/makepkg line. Theory: transient pacman mirror sync
failures on \"pacman -Syu --needed\" in the bootstrap steps, with the
rsync-to-nc step as secondary exposure (IPv6 prefix rotations from the
Fritz reconnect cron are visible in the runner journal).
Wrap pacman -Syu (5 sites), rsync to nc and hertz (5 sites), and ssh
publish-deb (2 sites) in a tiny 3-try exponential-backoff retry helper
defined per-step. No workflow restructure, no job-graph changes.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
distcc-avahi build failure was breaking the entire chain (lmcp-* and
claude-his-* depend transitively on it). These jobs only share a runner,
not real build outputs — one failing package should not block the
others.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- arch/claude-his-agent/PKGBUILD: fetches v0.1.0 tarball from
git.reauktion.de/marfrit/claude-his-agent, installs agent+skill+helper
to /usr/share/claude-agents/, /usr/share/claude-skills/his/, /usr/bin/
- debian/claude-his-agent/: control+changelog+copyright + build-deb.sh
mirroring the lmcp-debian pattern (dpkg-deb, reproducible mtimes)
- .gitea/workflows/build.yml: two new serialized jobs (claude-his-any +
claude-his-debian) after lmcp-debian; same publish flow as lmcp.
makepkg output isn't byte-deterministic across runs; same pkgver-pkgrel
rebuilds produce different .pkg.tar.xz bytes. repo-add no-ops on
same-version entries, leaving the db's CSIZE/SHA256 pointing at the
previous build while the nc copy is the new one — alpm then refuses
download with 'Maximum file size exceeded'. Force-remove first.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- debian/lmcp/build-deb.sh fetches the v0.3.0 tarball, lays out the
filetree, and uses dpkg-deb to assemble lmcp_0.3.0-1_all.deb directly
on the Arch aarch64 runner (no debhelper needed for a pure-Lua pkg).
- workflow job 'lmcp-debian' rsyncs the .deb to hertz's marfritrepo
incoming dir, then ssh-triggers 'publish-deb <suite>' for both
bookworm and trixie. publish-deb wraps 'reprepro includedeb' and
rsyncs dists/+pool/ to nc.
- New secret MARFRIT_REPO_HERTZ_KEY uploaded to Gitea repo. Forced
command on hertz routes rsync uploads vs publish-deb triggers.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
lmcp is arch=any (pure Lua). One build on the aarch64 runner serves
all pacman targets — the pure-Lua package drops into both repo dbs.
Depends on lua + lua-socket from the target distro's base repos.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- distcc-3.4 tarball hash + local support files hashed (no more SKIP)
- .gitea/workflows/build.yml now builds, signs, repo-adds and rsyncs
to nc via the marfrit-repo-deploy key. Triggers on push to arch/**
or manual workflow_dispatch.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
marfrit
claude-noether
test0r
claude-noether