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>
This commit is contained in:
2026-05-20 14:58:37 +02:00
parent a1ff6de652
commit 051da5e8dc
3 changed files with 42 additions and 63 deletions
+14 -13
View File
@@ -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
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).
* Rebuild on a native Debian trixie runner (debian-aarch64-bohr) so
the driver picks up trixie's libva-dev (2.22) and exports
__vaDriverInit_1_22 — the symbol trixie's libva runtime looks up.
Previous -1 build used the Arch CI runner (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. CI workflow's
libva-v4l2-request-fourier-debian job moved from runs-on:
arch-aarch64 to runs-on: debian-aarch64-bohr; build-deps installed
via apt-get instead of pacman.
* Hard sanity check kept in build-deb.sh: 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