claude-noether/marfrit-packages
1
0
Fork 0
forked from marfrit/marfrit-packages
Code Pull Requests Activity
Files
a1ff6de65274c553a856854e6913008296ae0017
marfrit-packages/debian/libva-v4l2-request-fourier/build-deb.sh
T
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

129 lines
5.5 KiB
Bash
Executable File
Raw Blame History

#!/bin/bash
# Build libva-v4l2-request-fourier_<ver>_arm64.deb.
#
# Compiles the libva ICD from the marfrit/libva-v4l2-request-fourier
# tip pinned in PKGVER below. Mirrors arch/libva-v4l2-request-fourier
# (Arch Linux build). Output is a single arm64 .deb that ships the
# VA-API driver as /usr/lib/aarch64-linux-gnu/dri/v4l2_request_drv_video.so.
#
# Sibling Arch package: ../../arch/libva-v4l2-request-fourier/PKGBUILD
# Upstream fork: https://git.reauktion.de/marfrit/libva-v4l2-request-fourier
set -euo pipefail
# Same pin as the Arch PKGBUILD. c332d34 = LIBVA-1 close — per-codec
# dispatch on Pi 5: rpi-hevc-dec + daedalus_v4l2 both probe each other
# as alts, VP9/AV1/H.264 route to daedalus via new 'd' kind, HEVC stays
# on 'p' (rpi-hevc-dec).
UPSTREAM_COMMIT=c332d34643be29e88012e30878d2fbeb255b20ab
PKGVER=1.0.0+r378+gc332d34
PKGREL=2 # rebuild against pinned trixie libva-dev (2.22) for __vaDriverInit_1_22 ABI
HERE=$(dirname "$(readlink -f "$0")")
# Reproducible build. 2026-05-18 23:00 UTC — Phase 8.13 close.
export SOURCE_DATE_EPOCH=1779231600
work=$(mktemp -d)
trap "rm -rf $work" EXIT
cd "$work"
# ---------------------------------------------------------------------------
# Pin libva ABI to Debian trixie's version (libva 2.22.0 -> VA-API 1.22).
#
# Without this, when the CI runner is Arch (libva 2.23.0 currently) the
# driver compiles in __vaDriverInit_1_23 from Arch's <va/va.h> — but the
# Debian trixie libva runtime on the install target looks up
# __vaDriverInit_1_22 and the dlsym() returns NULL. libva then reports
# "has no function __vaDriverInit_1_0" (its fallback search name) and
# vaInitialize() fails with -1.
#
# The driver itself doesn't link against libva.so — only the symbol NAME
# matters, and the name is computed at compile time from VA_MAJOR /
# VA_MINOR macros in <va/va.h>. So all we have to do is point pkg-config
# at trixie's libva-dev headers; the link step still resolves -lva
# against the runner's libva (any version is fine — it's just for the
# linker to be happy, the result has no NEEDED entry for libva).
# ---------------------------------------------------------------------------
LIBVA_TRIXIE_VER="2.22.0-3"
TRIXIE_SYSROOT="$work/trixie-sysroot"
mkdir -p "$TRIXIE_SYSROOT"
for pkg in libva-dev libva2 libva-drm2; do
curl -sSLfo "$work/${pkg}.deb" \
"https://deb.debian.org/debian/pool/main/libv/libva/${pkg}_${LIBVA_TRIXIE_VER}_arm64.deb"
dpkg-deb -x "$work/${pkg}.deb" "$TRIXIE_SYSROOT"
done
# Rewrite the prefix in the .pc files so pkg-config returns -I/-L pointing
# inside the sysroot (Debian's pkg-config files default to /usr).
for pc in "$TRIXIE_SYSROOT"/usr/lib/aarch64-linux-gnu/pkgconfig/libva*.pc; do
sed -i "s|^prefix=/usr|prefix=$TRIXIE_SYSROOT/usr|" "$pc"
done
# Symlink libva.so -> libva.so.2 inside the sysroot so the linker can
# resolve `-lva` against trixie's shipped runtime (no -dev symlink in
# the libva2 .deb). Same for libva-drm.
ln -sf libva.so.2 "$TRIXIE_SYSROOT/usr/lib/aarch64-linux-gnu/libva.so"
ln -sf libva-drm.so.2 "$TRIXIE_SYSROOT/usr/lib/aarch64-linux-gnu/libva-drm.so"
export PKG_CONFIG_PATH="$TRIXIE_SYSROOT/usr/lib/aarch64-linux-gnu/pkgconfig:${PKG_CONFIG_PATH:-}"
curl -sSLfo libva-fourier.tar.gz \
"https://git.reauktion.de/marfrit/libva-v4l2-request-fourier/archive/${UPSTREAM_COMMIT}.tar.gz"
tar xzf libva-fourier.tar.gz
SRCDIR=$(echo libva-v4l2-request-fourier)
cd "$SRCDIR"
meson setup build \
--buildtype=release \
--prefix=/usr \
--libdir=lib/aarch64-linux-gnu \
-Db_lto=false
meson compile -C build
# Sanity check: the produced .so MUST export __vaDriverInit_1_22 (not 1_23).
# Fail loud if it doesn't — otherwise the .deb installs but refuses to load
# on trixie and the bug is invisible until someone runs vainfo.
SO=$(find build -name 'v4l2_request_drv_video.so' | head -1)
if ! nm -D --defined-only "$SO" | grep -q '__vaDriverInit_1_22'; then
echo "FATAL: built driver does not export __vaDriverInit_1_22"
nm -D --defined-only "$SO" | grep -i vadriverinit || true
exit 1
fi
echo "ABI check: $SO exports __vaDriverInit_1_22 (matches trixie libva 2.22)"
ROOT="$work/pkgroot"
DESTDIR="$ROOT" meson install -C build
# Strip any non-package debug, then drop dependencies + control.
install -Dm644 "$HERE/debian/copyright" "$ROOT/usr/share/doc/libva-v4l2-request-fourier/copyright"
install -Dm644 "$HERE/debian/changelog" "$ROOT/usr/share/doc/libva-v4l2-request-fourier/changelog.Debian"
gzip -9 -n "$ROOT/usr/share/doc/libva-v4l2-request-fourier/changelog.Debian"
mkdir -p "$ROOT/DEBIAN"
cat > "$ROOT/DEBIAN/control" <<EOF
Package: libva-v4l2-request-fourier
Version: ${PKGVER}-${PKGREL}
Section: libs
Priority: optional
Architecture: arm64
Depends: libva2, libdrm2
Conflicts: libva-v4l2-request
Replaces: libva-v4l2-request
Provides: libva-driver, libva-v4l2-request (= ${PKGVER}-${PKGREL})
Maintainer: Markus Fritsche <mfritsche@reauktion.de>
Homepage: https://git.reauktion.de/marfrit/libva-v4l2-request-fourier
Description: VA-API backend for V4L2 stateless decoders (fourier fork)
LibVA implementation for the Linux Video4Linux2 Request API, multiplanar
fork of bootlin/libva-v4l2-request. Drives rkvdec / hantro / cedrus /
rpi-hevc-dec / daedalus_v4l2 stateless decoders for H.264, HEVC, VP8,
VP9, AV1, and MPEG-2.
.
Auto-detected by VAAPI consumers (ffmpeg -hwaccel vaapi, mpv --hwdec=vaapi,
Firefox VAAPI accel) when LIBVA_DRIVER_NAME=v4l2_request is set.
EOF
DEB_OUT="libva-v4l2-request-fourier_${PKGVER}-${PKGREL}_arm64.deb"
dpkg-deb --root-owner-group --build "$ROOT" "$HERE/$DEB_OUT"
echo "built: $HERE/$DEB_OUT"
View Git Blame Copy Permalink