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>

.gitea/workflows/build.yml

@@ -971,7 +971,12 @@ jobs:
   # -------------------------------------------------------------------------
   libva-v4l2-request-fourier-debian:
     needs: libva-v4l2-request-fourier-aarch64
-    runs-on: arch-aarch64
+    # Native Debian trixie runner — the driver bakes __vaDriverInit_1_<MINOR>
+    # at compile time from <va/va.h>.  Building on Arch (libva 2.23) produced
+    # __vaDriverInit_1_23, which trixie's libva 2.22 runtime cannot bind: the
+    # .deb installed but vaInitialize() returned -1 on every host.  A native
+    # trixie runner avoids the cross-distro ABI skew entirely.
+    runs-on: debian-aarch64-bohr
     continue-on-error: true
     steps:
       - uses: actions/checkout@v4
@@ -989,9 +994,12 @@ jobs:
         run: |
           set -e
           retry() { for i in 1 2 3; do "$@" && return 0; rc=$?; echo "retry $i (exit=$rc)" >&2; sleep $((i*5)); done; return 1; }
-          retry pacman -Syu --noconfirm --needed \
+          export DEBIAN_FRONTEND=noninteractive
-            dpkg openssh rsync curl base-devel git meson ninja pkgconf \
+          retry apt-get update -qq
-            libva libdrm systemd-libs
+          retry apt-get install -y --no-install-recommends \
+              build-essential meson ninja-build pkg-config \
+              libva-dev libdrm-dev \
+              curl openssh-client rsync ca-certificates git dpkg-dev
 
       - name: install hertz deploy ssh key
         if: steps.skip-check.outputs.skip != '1'

debian/libva-v4l2-request-fourier/build-deb.sh

@@ -27,47 +27,6 @@ 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
@@ -81,13 +40,24 @@ meson setup build \
     -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
+# ABI sanity check: the produced .so MUST export __vaDriverInit_1_<MINOR>
-# on trixie and the bug is invisible until someone runs vainfo.
+# matching the install target's libva runtime.  Build is expected to run on
+# a Debian trixie runner where <va/va.h>'s VA_MINOR is 22 — see
+# .gitea/workflows/build.yml (runs-on: debian-aarch64-bohr).  If a future
+# runner change lands the build on a host with a different libva-dev
+# version, the produced symbol won't bind on the install target and ffmpeg/
+# vainfo/firefox-vaapi will all fail with "has no function
+# __vaDriverInit_1_0".  Fail loud at build time instead of shipping a
+# silently-broken .deb (which is what happened in -1).
+# ---------------------------------------------------------------------------
 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"
+    echo "FATAL: built driver does not export __vaDriverInit_1_22."
-    nm -D --defined-only "$SO" | grep -i vadriverinit || true
+    echo "    Build host's <va/va.h> VA_MINOR_VERSION is likely != 22."
+    echo "    Expected runner: debian-aarch64-bohr (trixie, libva 2.22)."
+    echo "    Symbol exports found:"
+    nm -D --defined-only "$SO" | grep -i vadriverinit || echo "    (none)"
     exit 1
 fi
 echo "ABI check: $SO exports __vaDriverInit_1_22 (matches trixie libva 2.22)"

debian/libva-v4l2-request-fourier/debian/changelog

@@ -1,18 +1,19 @@
 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
+  * Rebuild on a native Debian trixie runner (debian-aarch64-bohr) so
-    driver exports __vaDriverInit_1_22 — the symbol trixie's libva
+    the driver picks up trixie's libva-dev (2.22) and exports
-    runtime looks up.  Previous -1 build used the CI runner's Arch
+    __vaDriverInit_1_22 — the symbol trixie's libva runtime looks up.
-    libva (2.23.0) and exported __vaDriverInit_1_23, which trixie's
+    Previous -1 build used the Arch CI runner (libva 2.23.0) and
-    loader cannot bind: vaInitialize() returns -1 ("has no function
+    exported __vaDriverInit_1_23, which trixie's loader cannot bind:
-    __vaDriverInit_1_0") and ffmpeg -hwaccel vaapi fails on startup.
+    vaInitialize() returns -1 ("has no function __vaDriverInit_1_0")
-  * No source change; pure build-env fix.  build-deb.sh now downloads
+    and ffmpeg -hwaccel vaapi fails on startup.
-    libva-dev / libva2 / libva-drm2 from Debian's archive, extracts
+  * No source change; pure build-env fix.  CI workflow's
-    to a sysroot, and uses PKG_CONFIG_PATH to make pkg-config return
+    libva-v4l2-request-fourier-debian job moved from runs-on:
-    trixie headers regardless of what's installed on the runner.
+    arch-aarch64 to runs-on: debian-aarch64-bohr; build-deps installed
-  * Hard sanity check: build fails if the resulting .so doesn't
+    via apt-get instead of pacman.
-    export __vaDriverInit_1_22 (preempts the silent install-then-
+  * Hard sanity check kept in build-deb.sh: build fails if the
-    refuse-to-load failure mode).
+    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