claude-noether/marfrit-packages
1
0
Fork 0
forked from marfrit/marfrit-packages
Code Pull Requests Activity

libva-v4l2-request-fourier-debian: pin trixie libva-dev for ABI

Browse Source 
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>
This commit is contained in:
Markus Fritsche
2026-05-20 14:31:40 +02:00
parent 3abfdff943
commit a1ff6de652
2 changed files with 71 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
debian/libva-v4l2-request-fourier/debian/changelog
Vendored
+18
View File
@@ -1,3 +1,21 @@
libva-v4l2-request-fourier (1.0.0+r378+gc332d34-2) bookworm trixie; urgency=medium
* Rebuild against pinned Debian trixie libva-dev (2.22.0-3) so the
driver exports __vaDriverInit_1_22 — the symbol trixie's libva
runtime looks up. Previous -1 build used the CI runner's Arch
libva (2.23.0) and exported __vaDriverInit_1_23, which trixie's
loader cannot bind: vaInitialize() returns -1 ("has no function
__vaDriverInit_1_0") and ffmpeg -hwaccel vaapi fails on startup.
* No source change; pure build-env fix. build-deb.sh now downloads
libva-dev / libva2 / libva-drm2 from Debian's archive, extracts
to a sysroot, and uses PKG_CONFIG_PATH to make pkg-config return
trixie headers regardless of what's installed on the runner.
* Hard sanity check: build fails if the resulting .so doesn't
export __vaDriverInit_1_22 (preempts the silent install-then-
refuse-to-load failure mode).
-- Markus Fritsche <mfritsche@reauktion.de> Wed, 20 May 2026 18:00:00 +0000
libva-v4l2-request-fourier (1.0.0+r378+gc332d34-1) bookworm trixie; urgency=medium
* Bump to c332d34 — LIBVA-1 per-codec dispatch close. Pi 5 mixed