Pierre Rouanet 9cfd24e49f Build the robot's GStreamer plugins natively, from pinned sources
Two plugins the micro duck robot needs and no archive provides:
`libgstrockchipmpp.so` for hardware H.264 through Rockchip MPP, and
`libgstrswebrtc.so`/`libgstrsrtp.so` for webrtcsink. Debian ships no Rockchip
encoder in any suite, Radxa's prebuilt plugin is decode-only (measured on a
Zero 3W: mppvideodec and mppjpegdec, nothing else — 1.14.4 predates the
encoders), and gstreamer1.0-plugins-rs exists in no Debian suite at all.
`webrtcbin` is deliberately absent: Debian has it.

Native arm64 in a debian:trixie container, which is the point. The daemon
cross-compiles with cargo-zigbuild and its one C dependency is already the
documented cost of that; GStreamer would be a far larger second one, and both
routes — x86 multiarch or a sysroot with a meson cross file — link against an
approximation of the target rather than the target. Here nothing is
approximated.

Public because arm64 runners are free on public repositories, and more
importantly because a release asset is fetched by the updater's preinstall
hook, which runs with a cleared environment and no token. That is the same
arrangement the daemon already relies on for ONNX Runtime.

Pins are commits or tags, never branches, in one file both the build and the
release manifest read — a plugin whose version nobody can name is what makes a
media bug unreproducible, which is exactly what the third-party debs we
rejected could not answer. gst-plugins-rs is pinned at 0.15.3 rather than the
0.14.5 the reachy_mini SDK documents: 0.14.5 is the floor that matters, since
the tags below it miss a webrtcsink deadlock fix between remote description and
ICE handling, and both series declare a GStreamer v1_22 floor against a robot
running 1.26.2.

Two guards written from reading the trees rather than hoping.
`gst/rockchipmpp/meson.build` ends in `if not mpp_dep.found() → subdir_done()`,
so a missing librockchip-mpp-dev makes meson skip the plugin and *succeed*;
pkg-config is checked first and the .so checked for after. And the Radxa debs
are installed as one closure, because dpkg -i resolves nothing for direct
downloads — learning that one package at a time cost three rounds on a board.

Building also drops rkximage and kmssrc, the X11 and KMS sinks in the same
tree, which a headless robot has no use for and which are why the prebuilt deb
depends on libx11-6.

Assisted-by: Claude:claude-opus-5[1m] shellcheck
2026-08-24 16:02:47 +02:00

42 lines
2.2 KiB
Bash

# What this repo builds, and from exactly where.
#
# One file, sourced by `scripts/build.sh` and read by the release workflow, so a bump is one
# commit and the manifest in a release can never disagree with what was built.
#
# Pins are commits or tags, never branches. A plugin whose version nobody can name is what makes
# a media bug unreproducible, and both of these upstreams move.
# ── Rockchip MPP: mpph264enc, mpph265enc, mppjpegenc, mppvp8enc, mppvideodec, mppjpegdec ──
#
# `rockchip-linux/gstreamer-rockchip` — the homepage both Radxa's and every third-party deb name
# — is a 404 now. `JeffyCN/mirrors` is the live mirror, same maintainer (Jeffy Chen).
#
# Why build it at all: Debian has no Rockchip encoder in any suite, and Radxa's
# `gstreamer1.0-rockchip1_1.14-4` is **decode-only** — measured on a Zero 3W, it provides
# `mppvideodec` and `mppjpegdec` and nothing else. 1.14.4 predates the encoders.
GST_ROCKCHIP_REPO=https://github.com/JeffyCN/mirrors.git
GST_ROCKCHIP_BRANCH=gstreamer-rockchip
GST_ROCKCHIP_REF=dcbcd6454ef892e385b3a782600369eb6c0719db
# ── gst-plugins-rs: webrtcsink, webrtcsrc, and the rtp sibling the same stack wants ──
#
# Why build it: `gstreamer1.0-plugins-rs` does not exist in **any** Debian suite — not trixie,
# not backports, not sid, not experimental.
#
# 0.15.3 rather than the 0.14.5 that Pollen's reachy_mini SDK documents. 0.14.5 is the floor that
# matters — the tags below it miss a `webrtcsink` deadlock fix between remote description and ICE
# handling, which presents as a client spinning forever on "connecting" — and 0.15.3 is simply
# newer than it. Both declare a GStreamer `v1_22` feature floor, and the robot runs 1.26.2, so
# the newer series costs nothing.
GST_PLUGINS_RS_REPO=https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs.git
GST_PLUGINS_RS_REF=0.15.3
# ── Rockchip userspace, from Radxa's pool ──
#
# Not in Debian either. These are the *build* dependencies of the MPP plugin; the runtime halves
# of the same versions are what a robot installs. A header/library version mismatch here is a
# plugin that builds and then misbehaves, so both sides come from one place.
RADXA_POOL=https://radxa-repo.github.io/bullseye/pool/main
MPP_VERSION=1.5.0-1
RGA_VERSION=2.2.0-1