212 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
marfrit	eab66cfab8	Merge pull request 'build.yml: convert ffmpeg+mpv-debian install-deps to apt-get (closes #55)' (#56) from fix/debian-runner-deps-2026-05-20 into main ... Reviewed-on: #56	2026-05-20 19:13:50 +00:00
marfrit	d2cecbcd05	build.yml: convert ffmpeg+mpv-debian install-deps to apt-get ... 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).	2026-05-20 21:09:50 +02:00
marfrit	2028eccc3c	Merge pull request 'daedalus-v4l2{,-dkms}: 3dd0eb0 -> 462aa4b — kernel ctrl-binding fix' (#54) from claude-noether/marfrit-packages:noether/daedalus-bump-462aa4b into main ... Reviewed-on: #54	2026-05-20 18:45:09 +00:00
marfrit	70c8c2b417	daedalus-v4l2{,-dkms}: 3dd0eb0 -> 462aa4b — kernel ctrl-binding fix ... Upstream PR #2 landed the one-line kernel fix that was the missing half of issue libva-v4l2-request-fourier#8: device_run now calls v4l2_ctrl_request_setup() before reading ctrl->p_cur, so the daedalus_h264_meta the daemon receives reflects the in-flight media_request's bound H.264 stateless control values instead of stale/default ones. Pairs with libva-v4l2-request-fourier 1.0.0+r382+gc1bb444 (max_num_ ref_frames fallback + Fix 4 instrumentation that exposed the control-binding gap in the first place). Effect on Pi 5 / CM5 hosts (higgs): ffmpeg -hwaccel vaapi against H.264 sources now produces actual decoded content (per-frame fnv1a hashes differ, zero MB-decode errors) instead of the constant 0x6a6a05c5 "best-effort give-up" hash and cascading decode warnings. Both packages: pkgver 0.1.0.r22.462aa4b, pkgrel reset to 1. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 20:38:32 +02:00
marfrit	793187ff9e	Merge pull request 'libva-v4l2-request-fourier (deb): catch build-deb.sh up to c1bb444 (follow-up to #52)' (#53) from claude-noether/marfrit-packages:noether/libva-deb-bump-c1bb444 into main ... Reviewed-on: #53	2026-05-20 18:30:24 +00:00
claude-noether	42bf6b1633	libva-v4l2-request-fourier (deb): 9898331 -> c1bb444 (parallel to PR #52) ... PR #52 bumped only arch/libva-v4l2-request-fourier/PKGBUILD; the sibling debian/libva-v4l2-request-fourier/build-deb.sh has its own parallel UPSTREAM_COMMIT + PKGVER + PKGREL pin that I missed. Result: the libva-v4l2-request-fourier-debian CI job ran post-merge, check-already-published.sh saw the .deb-side filename derived from build-deb.sh (libva-v4l2-request-fourier_1.0.0+r380+g9898331-1_arm64.deb) was already in the pool, returned skip=1, and the job short-circuited. trixie repo Packages still advertises r380 instead of r382. This bump catches build-deb.sh up to the same pin (c1bb444) so the next merge triggers the build + reprepro publish path. No code change beyond the three pinned variables + the comment block. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 20:29:10 +02:00
marfrit	40719efc43	Merge pull request 'libva-v4l2-request-fourier: 9898331 -> c1bb444 (PR #9 / issue #8 fix)' (#52) from claude-noether/marfrit-packages:noether/libva-bump-c1bb444 into main ... Reviewed-on: #52	2026-05-20 18:23:42 +00:00
claude-noether	e540384f50	libva-v4l2-request-fourier: 9898331 -> c1bb444 (PR #9 / issue #8 fix) ... Bumps the libva backend pin to include marfrit/libva-v4l2-request-fourier PR #9 — h264_set_controls fix for the bitstream-vs-session value drift that breaks the daedalus_v4l2 strict-consumer path (issue #8): * max_num_ref_frames fallback when VAAPI client left it 0 (count valid DPB entries, then per-profile spec minimum) * one-line request_log at h264_set_controls entry dumping raw VAAPI bitfields for disambiguating remaining PPS-flag-zero portion of #8 The PR explicitly defers the deeper "profile_idc / level_idc from bitstream" portion of #8 — VAAPI's VAPictureParameterBufferH264 omits both fields, so a real fix needs SPS-NAL parsing or daedalus wire-protocol pass-through. Not in this bump. pkgver: 1.0.0.r380.9898331 -> 1.0.0.r382.c1bb444 (commit count 380->382) pkgrel: 1 (fresh pkgver, no rebuild-only iteration) Verified on higgs (Debian 13 trixie, gcc 14.2.0, libva 2.22.0): clean meson build, vainfo enumerates all 8 codec profiles, multi-device probe still wires rkvdec / rpi-hevc-dec / daedalus_v4l2. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 20:21:46 +02:00
marfrit	9ca97374c8	Merge pull request 'mesa-panvk-bifrost: iter13 — implement VK_EXT_transform_feedback for Bifrost' (#51) from claude-noether/marfrit-packages:noether/mesa-panvk-bifrost-iter13 into main ... Reviewed-on: #51	2026-05-20 17:33:05 +00:00
marfrit	902e855d92	mesa-panvk-bifrost: iter13 — implement VK_EXT_transform_feedback for Bifrost ... iter12 hit a wall: Brave's ANGLE-Vulkan path requires GLES3, which requires VK_EXT_transform_feedback, which PanVk-Bifrost did not implement. This iter implements that extension, unlocking the full ANGLE-Vulkan-on-Bifrost stack. The implementation follows Panfrost-Gallium's well-validated XFB lowering (nir_io_add_intrinsic_xfb_info + pan_nir_lower_xfb) wired into the PanVk shader pipeline after nir_lower_io. Adds 4 XFB buffer address sysvals plus per-draw num_vertices to the graphics sysval struct. Buffer state is tracked on the cmd buffer; per-draw sysval upload populates either the bound buffer's GPU address or PAN_SHADER_OOB_ADDRESS (memory-sink) so XFB-capable pipelines used outside Begin/End survive without GPU fault — the Panfrost-Gallium idiom from gallium/drivers/panfrost/ pan_cmdstream.c:1350. Verified on PineTab2 (Mali-G52 r1 MC1, RK3566): - /tmp/panvk-iter13/probe_xfb: 3 vertices captured byte-exact - /tmp/panvk-iter13/probe_xfb_nodraw: XFB pipeline used without Bind/ Begin/End survives — DEVICE_LOST regression closed - Brave 148 with --use-angle=vulkan: WebGL 2.0 (OpenGL ES 3.0) creates cleanly, renderer reports "ANGLE (ARM, Vulkan 1.2.335 (Mali-G52 r1 MC1), panvk)" - chrome://gpu graphics feature status: Canvas/Compositing/OpenGL/ Rasterization/WebGL/WebGL2/WebGPU/Video Decode all hardware accelerated Phase docs: - ~/src/panvk-bifrost/phase4_iter13_close.md (build green) - ~/src/panvk-bifrost/phase5_iter13_close.md (review fixes applied) - ~/src/panvk-bifrost/phase6_iter13_close.md (Brave integration green) pkgver bumped 26.0.6.r2 -> 26.0.6.r3; iter13 patch applied via unified-diff (the 328-line change scope is past sed-of-individual- lines territory). Sanity checks in prepare() verify the patch landed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-20 19:13:05 +02:00
marfrit	64269d69ee	Merge pull request 'ci: convert daedalus-v4l2{,-dkms}-debian install steps to apt-get' (#50) from claude-noether/marfrit-packages:noether/ci-fourier-debian-apt into main ... Reviewed-on: #50	2026-05-20 17:06:21 +00:00
marfrit	e976c88016	ci: convert daedalus-v4l2{,-dkms}-debian install steps to apt-get ... 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>	2026-05-20 19:03:36 +02:00
marfrit	29cc145d44	Merge pull request 'daedalus-v4l2{,-dkms}: 481279c -> 3dd0eb0 (DAEMON-PPS close)' (#49) from claude-noether/marfrit-packages:noether/daedalus-bump-3dd0eb0 into main ... Reviewed-on: #49	2026-05-20 16:54:11 +00:00
marfrit	b16a3f1a77	daedalus-v4l2{,-dkms}: 481279c -> 3dd0eb0 (DAEMON-PPS close) ... Upstream PR #1 landed daemon-side synthesis of H.264 SPS/PPS NAL units from the V4L2 stateless control structs. This bumps the package pin so both the userspace daemon and the kernel module pick up the change in lockstep (wire protocol grew a new DAEDALUS_REQ_FLAG_H264_META bit + struct daedalus_h264_meta — kernel and daemon MUST match). Effect on Pi 5 / CM5 hosts (higgs): ffmpeg -hwaccel vaapi against H.264 sources will actually decode through the daedalus daemon instead of failing with "non-existing PPS 0 referenced". Both arch + debian packages: pkgver 0.1.0.r20.3dd0eb0 (count from git rev-list), pkgrel reset to 1 (new upstream pin). VP9 / AV1 paths unchanged. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 18:53:04 +02:00
marfrit	c2018413aa	Merge pull request 'libva-v4l2-request-fourier: c332d34 -> 9898331 (LIBVA-2 close)' (#48) from claude-noether/marfrit-packages:noether/libva-bump-9898331 into main ... Reviewed-on: #48	2026-05-20 15:09:08 +00:00
marfrit	243e05ca5e	libva-v4l2-request-fourier: c332d34 -> 9898331 (LIBVA-2 close) ... Follow-up to libva PR #7 (merged as 9898331). Without that commit, H.264/VP9/AV1 profiles never got advertised on Pi 5 mixed deploys (rpi-hevc-dec primary + daedalus_v4l2 alt) because the profile- enumeration probe in any_fd_supports_output_format only walked rkvdec / hantro / rpi-hevc-dec / vpu981 fds. ffmpeg vaapi -i h264_test.mp4 on higgs bailed with "No support for codec h264 profile 578" before the LIBVA-1 per-codec dispatch could even fire. 9898331 extends the fds[] from 5 to 6 with video_fd_daedalus as the 6th slot (HAVE_DAEDALUS_V4L2-gated, -1 fallback otherwise). Effect on higgs once this lands: vainfo lists VP9Profile0 + AV1Profile0 + H264* alongside HEVCMain, and ffmpeg -hwaccel vaapi -i h264_test.mp4 routes through the daedalus daemon (via 'd' kind in request_switch_device_for_profile). Both packages: pkgver 1.0.0.r380.9898331 (count from rev-list), pkgrel reset to 1 (new upstream pin). Backward-compatible on RK3399/3588 — the new fd slot is gated by HAVE_DAEDALUS_V4L2 *and* video_fd_daedalus >= 0, both false in those deployments. Companion to the prior LIBVA-{1,ABI} bumps that landed in marfrit- packages PRs #43, #44. Together they close the Pi 5 stack: boot -> modules-load.d loads daedalus_v4l2 -> daedalus-v4l2.service starts daemon -> libva opens both decoders -> ffmpeg -hwaccel vaapi enumerates all codecs from both -> routes per-codec. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 17:08:07 +02:00
marfrit	a29fe71666	build.yml: route 4 fourier-debian jobs to debian-aarch64 (bohr) (#47) ... 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	2026-05-20 14:39:43 +00:00
marfrit	b0ffd4d74f	Merge pull request 'build.yml: runs-on debian-aarch64 (label, not runner name)' (#46) from fix/debian-runner-label-2026-05-20 into main ... Reviewed-on: #46	2026-05-20 13:54:01 +00:00
marfrit	ab60acd9f4	build.yml: runs-on debian-aarch64 (label, not runner name) ... 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).	2026-05-20 15:52:40 +02:00
claude-noether	6a417fcc9d	libva-v4l2-request-fourier-debian: route to debian-aarch64-bohr runner (#45) ... 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>	2026-05-20 13:08:30 +00:00
marfrit	1c77b05f68	Merge pull request 'libva-v4l2-request-fourier-debian: pin trixie libva-dev for ABI' (#44) from claude-noether/marfrit-packages:noether/libva-trixie-abi-pin into main ... Reviewed-on: #44	2026-05-20 12:59:40 +00:00
marfrit	051da5e8dc	libva-v4l2-request-fourier-debian: switch to debian-aarch64-bohr runner ... 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>	2026-05-20 14:58:37 +02:00
marfrit	a1ff6de652	libva-v4l2-request-fourier-debian: pin trixie libva-dev for ABI ... The libva-v4l2-request-fourier .deb shipped with the wrong VA-API symbol export because the CI runner is Arch (libva 2.23 = VA-API 1.23) while the install target is Debian trixie (libva 2.22 = VA-API 1.22). At compile time, <va/va.h>'s VA_MAJOR/VA_MINOR macros are baked into the driver's __vaDriverInit_<MAJOR>_<MINOR> symbol name. trixie's libva runtime looks up __vaDriverInit_1_22, our driver only exported __vaDriverInit_1_23, so dlsym() returned NULL and libva fell back to its sentinel error "has no function __vaDriverInit_1_0". Result: ffmpeg -hwaccel vaapi fails on startup, vainfo fails the same way, on every Pi 5 / CM5 that installed the package. The driver itself doesn't link libva.so (no NEEDED entry — confirmed via readelf on higgs), so the only thing that matters is the symbol NAME the compiler bakes in. Fix is small: in build-deb.sh, download trixie's libva-dev / libva2 / libva-drm2 .deb from deb.debian.org, extract to a sysroot, rewrite the .pc prefixes, and set PKG_CONFIG_PATH so pkg-config returns trixie headers regardless of what the runner has installed. The link step still resolves -lva against the sysroot's libva.so.2, but the resulting .so has no NEEDED entry for it. Added a hard sanity check at the end of build-deb.sh: fail the build if the produced .so doesn't export __vaDriverInit_1_22. This makes future ABI-skew failures loud at CI time instead of silent install- then-refuse-to-load on the target. Tested on boltzmann (aarch64): sysroot build produces a .so exporting __vaDriverInit_1_22 (verified via nm -D). Source unchanged from c332d34; only the build env differs. pkgver/upstream unchanged. PKGREL bumped 1 -> 2 (rebuild against pinned trixie libva-dev) so apt picks up the new .deb on higgs. This is the LIBVA-2 unblocker — the runtime-libva-bind failure was masking whether the LIBVA-1 per-codec dispatch actually works on higgs. Once -2 lands on packages.reauktion.de, apt upgrade on higgs and the daedalus daemon log + rpi-hevc-dec dispatch can be validated end-to-end. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 14:31:40 +02:00
marfrit	b471847b1c	Merge pull request 'libva-v4l2-request-fourier: de27e95 -> c332d34 (LIBVA-1 close)' (#43) from claude-noether/marfrit-packages:noether/libva-bump-c332d34 into main ... Reviewed-on: #43	2026-05-20 11:58:54 +00:00
marfrit	3abfdff943	libva-v4l2-request-fourier: de27e95 -> c332d34 (LIBVA-1 close) ... Bumps both Arch (PKGBUILD) and Debian (build-deb.sh + changelog) pins to upstream c332d34 — the merged LIBVA-1 PR. Effect: Pi 5 / CM5 mixed deployment (higgs) now opens BOTH rpi-hevc-dec and daedalus_v4l2 from one libva session and routes per-codec — HEVC to rpi-hevc-dec ('p'), VP9 / AV1 / H.264 to the daedalus daemon (new 'd' kind). Before c332d34, find_codec_device picked rpi-hevc-dec by known_decoder_drivers[] order and the daedalus slot stayed -1, so VP9/AV1/H.264 frames failed S_FMT. Also closes a small fd leak in RequestTerminate (daedalus pair — caught while reviewing the alt-driver expansion). Both packages: pkgver bumped 1.0.0.r378.c332d34, pkgrel reset to 1 (new upstream pin). Backward-compatible on RK3399/3588 — new branches gated by HAVE_DAEDALUS_V4L2 *and* video_fd_daedalus >= 0, both false in those deployments. Companion: daedalus-v4l2{,-dkms} bump 481279c landed in PR #39 (systemd unit + auto-enable). Together they close the Pi 5 stack: boot → modules-load.d loads daedalus_v4l2 → daedalus-v4l2.service starts daemon → libva opens both decoders → ffmpeg -hwaccel vaapi routes by codec. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 13:58:05 +02:00
marfrit	fce33b02a2	Merge pull request 'libva-v4l2-request-fourier: restore epoch=1' (#42) from epoch-bump/libva-v4l2-request-fourier-2026-05-20 into main ... Reviewed-on: #42	2026-05-20 10:58:26 +00:00
marfrit	da60fa7c49	libva-v4l2-request-fourier: restore epoch=1 ... Installed systems carry 1:1.0.0.r361.cf8cd9d-1 from an earlier build that had epoch=1. Current PKGBUILD ships 1.0.0.r376.de27e95-1 without epoch, which pacman vercmp ranks BELOW the installed version, so ohm refuses to upgrade with: warning: libva-v4l2-request-fourier: local (1:1.0.0.r361.cf8cd9d-1) is newer than marfrit (1.0.0.r376.de27e95-1) Restoring epoch=1 fixes the monotonic version chain.	2026-05-20 12:13:32 +02:00
marfrit	20161d231f	Merge pull request 'ci: skip jobs when their package version is already published' (#41) from claude-noether/marfrit-packages:claude-noether/rebuild-guard-2026-05-20 into main ... Reviewed-on: #41	2026-05-20 10:05:40 +00:00
claude-noether	c7bb14f369	ci: skip jobs when package already published ... 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.	2026-05-20 11:48:46 +02:00
claude-noether	f8d1257d35	ci: add check-already-published helper script ... CI currently rebuilds every recipe on every push. distcc-avahi hasn't changed in weeks but still burns runner-time. Add a small bash helper that takes a recipe dir (arch/<n> or debian/<n>), resolves the expected pool URL on packages.reauktion.de, and prints `skip=1` or `skip=0`. Live-tested against all 14 recipes. Sources PKGBUILDs in a sandboxed subshell so epoch=, ${_pkgver/-/}, and pkgname=() arrays resolve correctly. For debian/*, extracts top-level PKGVER/PKGREL lines with an awk guard that rejects command-subst and embedded-command assignments (avoids false-positive matches against HEREDOC-quoted dkms.conf content). Wiring into build.yml lands in the next commit.	2026-05-20 11:47:24 +02:00
marfrit	f3b1087ac7	Merge pull request 'mesa-panvk-bifrost: new package — Vulkan-compositor Brave for Bifrost SBCs' (#40) from claude-noether/marfrit-packages:noether/mesa-panvk-bifrost into main ... Reviewed-on: #40	2026-05-20 09:08:17 +00:00
claude-noether	2299d7a02f	Revert "linux-pinetab2-danctnix-besser: pkgrel=6 (per-series reconstruction, kernel-agent#29 done proper)" ... This reverts commit 31da35a549.	2026-05-20 11:05:43 +02:00
marfrit	489d6e3862	mesa-panvk-bifrost: new package — Vulkan-compositor Brave for Bifrost SBCs ... 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>	2026-05-20 11:03:59 +02:00
marfrit	265bf669c8	Merge pull request 'daedalus-v4l2{,-dkms}: Linux 6.18 compat + systemd unit + auto-enable' (#39) from claude-noether/marfrit-packages:noether/daedalus-v4l2-kernel-6.18-compat into main ... Reviewed-on: #39	2026-05-20 08:54:28 +00:00
marfrit	df09c1c55d	daedalus-v4l2{,-dkms}: f0cd29a -> 481279c — systemd unit + auto-enable ... 481279c adds packaging/systemd/{daedalus-v4l2.service,modules-load} to the upstream tree. This commit wires those into both the Arch (PKGBUILD + .install) and Debian (build-deb.sh + postinst/prerm/postrm) package layouts so that a fresh install of daedalus-v4l2 + daedalus- v4l2-dkms on a Pi 5 leaves the kernel module loaded at next boot AND the userspace broker daemon enabled — no manual modprobe / systemctl enable dance needed. arch/daedalus-v4l2: * pkgver 0.1.0.r18.481279c, pkgrel reset to 1 (new upstream pin). * Dropped 'systemd-libs' from depends — daemon doesn't link libsystemd (no sd_notify); the .service unit is consumed by systemd-the-init, no link-time dep required. * package() now installs the .service to /usr/lib/systemd/system/daedalus-v4l2.service and the modules- load drop-in to /usr/lib/modules-load.d/daedalus-v4l2.conf. * New .install file: post_install/post_upgrade run daemon-reload + enable + systemd-modules-load + try-restart on upgrade; pre/post remove tear down cleanly. No auto-start — operator decides. arch/daedalus-v4l2-dkms: * pkgver bump to 481279c, pkgrel reset to 1. Kernel module itself is bit-identical to f0cd29a (commit only touches packaging/) but bumping in lockstep keeps DKMS source-tree pkgver matched to the userspace pkgver so /etc/modules-load.d points at a module that actually exists. debian/daedalus-v4l2: * Same bump 481279c, PKGREL=1. * build-deb.sh stages /lib/systemd/system/ + /usr/lib/modules-load.d/ and installs both files. * Generates DEBIAN/postinst that runs daemon-reload, enables the service, triggers systemd-modules-load, and conditionally starts the service iff /dev/daedalus-v4l2 is already present (uses the same ConditionPathExists= guard as the unit file so apt install doesn't fail loudly on a host where dkms hasn't built yet). * Generates DEBIAN/prerm (stop + disable on remove) and DEBIAN/postrm (daemon-reload). debian/daedalus-v4l2-dkms: * Lockstep version bump, PKGREL=1. Postinst (loud-warn-on-missing- headers) unchanged. Verified the SHA via local rev-parse against ~/src/daedalus-v4l2 — 481279c is the "packaging/systemd: ship daedalus-v4l2.service + modules-load drop-in" commit on main. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-20 10:34:55 +02:00
marfrit	e8a5490d44	Merge pull request 'daedalus-v4l2{,-dkms}: f55b2cd -> f0cd29a — Linux 6.18 compat' (#38) from claude-noether/marfrit-packages:noether/daedalus-v4l2-kernel-6.18-compat into main ... Reviewed-on: #38	2026-05-20 08:24:19 +00:00
marfrit	ff9db4e273	daedalus-v4l2{,-dkms}: f55b2cd -> f0cd29a — Linux 6.18 compat ... DKMS build for daedalus_v4l2 fails against kernel 6.18+ with: daedalus_v4l2_main.c:1049: error: too few arguments to function 'v4l2_fh_add' v4l2-fh.h:97: void v4l2_fh_add(struct v4l2_fh *fh, struct file *filp); (same for v4l2_fh_del). Signature changed exactly at v6.18 — verified v6.13–v6.17 still use the one-arg form via raw.githubusercontent.com tag walk. Upstream commit f0cd29a wraps the calls with LINUX_VERSION_CODE so the module keeps building against: * 6.12 LTS / RPi 6.12.75 (one-arg) — hertz * 6.12.88+deb13-arm64 (one-arg) * 6.18.29+rpt-rpi-2712 (file* arg) — higgs running kernel Higgs (Pi CM5) was hitting this: daedalus-v4l2-dkms 0.1.0+r16+gf55b2cd showed 'installed' in dpkg but DKMS autoinstall failed for the running 6.18.29 kernel. Re-running 'dkms autoinstall' after this bump succeeds + /dev/daedalus-v4l2 appears. Also widens debian/daedalus-v4l2-dkms Recommends from linux-headers-generic | linux-headers to linux-headers-rpi-2712 | linux-headers-rpi | linux-headers-generic | linux-headers so apt pulls the right metapackage on Raspberry Pi OS / RPi-2712 kernels by default. Userspace pkgver bumps in lockstep (no userspace change in f0cd29a, but keeps daedalus-v4l2 + daedalus-v4l2-dkms versions matching for LIBVA_DRIVER_NAME selection sanity). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-20 10:21:13 +02:00
marfrit	108a3dabe6	firefox-fourier: ship .desktop launcher (pkgrel=7) ... Stock firefox.desktop disappears when our 'provides=firefox' replaces stock firefox-arch, so installing firefox-fourier left the user without a Plasma/GNOME start-menu entry. Add firefox-fourier.desktop with Categories=Network;WebBrowser; (routes under Internet on KDE Plasma 6), MIME types for the usual web schemes, new-window / private-window actions, and the 128px icon from the package's internal browser/chrome/icons tree. Reported on ohm (PineTab2 / Plasma 6) — manual /usr/share/applications shim proved the file works; this commits it to the recipe so future installs Just Work.	2026-05-20 00:09:31 +02:00
claude-noether	31da35a549	linux-pinetab2-danctnix-besser: pkgrel=6 (per-series reconstruction, kernel-agent#29 done proper) ... Bumps pkgrel from 5 to 6. Cumulative regenerated from the redone per-series reconstruction in kernel-agent (replacing the broken PR #33 attempt with a proper rebase onto v7.0-danctnix1 baseline). cumulative.patch: 162 716 -> 279 554 bytes b2sum: 50397711a6a3... -> eb179c03f35a... manifest.lock: 32 resolved patches (was 4 — c5x interim collapsed the bes2600 driver scope into one cumulative blob; per-series properly tracks each fix) bes2600 series-dirs in kernel-agent: now 25 individual series-dirs (one per cleanups commit + Patch H), each with the proper in-tree drivers/staging/bes2600/* paths Built + installed on ohm 2026-05-19 23:39. Functional verification: uname: 7.0.0-danctnix1-6-pinetab2-danctnix-besser srcversion: 1A919EED0E6DC2478559B17 (differs from pkgrel=5's BEB625FA7443171EA8D55F7 — not byte-equivalent; functional equivalence verified: wlan0 associates, bes2600_btuart loads, Pattern A 0, no WARN/BUG) Per-fix revertability now real: removing an include from fleet/ohm.yaml drops that fix from the cumulative. Bisecting on kernel-agent side becomes practical.	2026-05-19 23:44:47 +02:00
marfrit	b4d1a47d6b	Merge pull request 'daedalus-v4l2{,-dkms}: fix hallucinated upstream commit SHA' (#37) from noether/daedalus-sha-fix into main ... Reviewed-on: #37	2026-05-19 10:06:13 +00:00
test0r	3548a761a5	daedalus-v4l2{,-dkms}: fix hallucinated upstream commit SHA ... The recipes pinned `f55b2cdab8a8c0bc04e8c1bb1d0b6ca85e7d96d2` as the "Phase 8.13: byte-exact end-to-end via libva" commit, but that SHA does not exist in git.reauktion.de/reauktion/daedalus-v4l2. The actual `main` tip (per gitea's for-each-ref) is `f55b2cd002afdfd08f3c093627317f92e4929074` — same 7-char prefix (`f55b2cd`), different full hash. Likely a manually-constructed SHA based on a short prefix from a working copy that was never pushed. git archive --format=tar.gz on the bad SHA fails with fatal: not a tree object: f55b2cdab8a8... which surfaces as 500 from Gitea's archive endpoint, which curl in the CI build-deb.sh sees as `curl: (22) ... error: 500`. Diagnosed by tailing gitea.log during a fresh archive request from the CI runner; the underlying `git archive` command in the gitea container is logged with the full failing SHA + error. Fixed in all four recipes (arch + debian, daedalus-v4l2 + dkms). pkgrel bumped to signal new build (PKGVER short-prefix `gf55b2cd` stays the same — both bad and good SHA share that prefix).	2026-05-19 12:03:39 +02:00
marfrit	6f65462ec4	Merge pull request 'fourier-debian: Path A — ffmpeg into /opt/fourier prefix (no more KDE cascade)' (#36) from noether/fourier-private-prefix into main ... Reviewed-on: #36	2026-05-19 08:15:25 +00:00
test0r	a0e0d123b2	fourier-debian: Path A — ffmpeg into /opt/fourier prefix ... Stock Debian trixie ships FFmpeg 7.1 (libavcodec.so.61), our fork ships FFmpeg 8.1 (libavcodec.so.62) — different SONAMEs, NOT a drop-in for trixie's libavcodec61-consuming desktop. Previous Conflicts: libavcodec61, libavformat61, ... triggered apt to remove ~50 packages (kde-plasma-desktop, vlc, dolphin, ...) when a user just wanted ffmpeg-v4l2-request-fourier installed alongside. This commit: 1. ffmpeg-v4l2-request-fourier (pkgrel=2): - --prefix=/opt/fourier (instead of /usr) - --extra-ldexeflags / --extra-ldsoflags: -Wl,-rpath,/opt/fourier/lib so /opt/fourier/bin/ffmpeg finds its own libs without external help - Ship /etc/ld.so.conf.d/fourier.conf with /opt/fourier/lib + ldconfig in postinst/postrm. dlopen-by-SONAME consumers (firefox, daedalus) find libavcodec.so.62 via ld.so cache without LD_LIBRARY_PATH. - Drop ALL Conflicts/Replaces/Provides for libav* / libpostproc / libsw* — no SONAME clash with stock libavcodec61, no reason to evict anything. - /usr/bin/ffmpeg-fourier + ffprobe-fourier convenience symlinks. 2. daedalus-v4l2 (pkgrel=2): - Depends: ffmpeg-v4l2-request-fourier (>= 2:8.1+rfourier) instead of stock 'ffmpeg (>= 7.1)'. The daedalus binary was linked against libavcodec.so.62 at build time (CI runner had marfrit/ffmpeg-v4l2-request-fourier installed); at runtime it needs the .so.62 that only the fourier pkg provides. Not touched: - libva-v4l2-request-fourier: ships only v4l2_request_drv_video.so at /usr/lib/<triplet>/dri/ which libva dlopens by file pattern. Path A would break the lookup unless every consumer launcher sets LIBVA_DRIVERS_PATH. Driver name is unique; no conflict. STAY. - mpv-fourier: Depends already correctly bound to fourier ffmpeg. Will receive libavcodec.so.62 via the ld.so.cache mechanism above without recipe changes.	2026-05-19 10:12:36 +02:00
marfrit	f22f8f03ac	fourier-debian: fix mpv Conflicts + daedalus ffmpeg conflict (#35)	2026-05-19 06:42:30 +00:00
test0r	e236ec1f42	fourier-debian: fix mpv Conflicts: + daedalus ffmpeg conflict ... 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.	2026-05-19 08:42:01 +02:00
marfrit	57e6bac3d4	Merge pull request 'firefox-fourier: explicit CC/CXX=distcc in mozconfig' (#33) from noether/firefox-fourier-moz-distcc into main ... Reviewed-on: #33	2026-05-19 04:32:23 +00:00
marfrit	c818445611	ci: wire debian builds for 5 fourier recipes (#34)	2026-05-18 22:07:01 +00:00
test0r	45604801fa	ci: wire debian builds for 5 fourier recipes ... 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.	2026-05-19 00:05:40 +02:00
claude-noether	0a922a9f36	firefox-fourier: explicit CC/CXX=distcc in mozconfig ... fermi's makepkg.conf already has BUILDENV=(distcc ...) which prepends /usr/lib/distcc/bin to PATH at build time. But Mozilla's mach configure picks CC/CXX from the environment directly — it doesn't treat the distcc shim in PATH as the default C compiler unless the env vars are set explicitly. Without this guard the distcc workers sat idle while mach drove a local-only build. Mirrors the explicit-distcc pattern already used in ffmpeg-v4l2-request-fourier/PKGBUILD. Caveat documented in the comment: only the C/C++ portion distributes. rustc and host-only build steps stay local. Empirical ~30-40% wall-clock improvement on a 4-worker pool (tesla, dcc1, dcc2, ampere via Avahi zeroconf). pkgrel bumped so a rebuild publishes a new package even though the binary output for users is unchanged (build process speedup only). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-18 21:08:49 +00:00
marfrit	9b170e942c	Merge pull request 'qt6-base-fourier: fix epoch-mismatch in xcb-private-headers dep' (#32) from noether/qt6-xcb-private-headers-fourier-epoch-fix into main ... Reviewed-on: #32	2026-05-18 20:56:54 +00:00