aurupdater

ffmpeg7.1

Build times (auto-updated)

Migrated 2026-09-24 from local-install/ (untracked, plain AUR clone) to adapted/ffmpeg7.1 (git-tracked) – see that date’s entry below for why. The install_only_packages line for it is gone.

Built x86_64 only, purely as a dependency: [[makemkv]]’s makemkv-oss component (libffabi/src/ffabi.c) needs AVCodec struct fields (ch_layouts, sample_fmts, supported_samplerates) that current extra/ffmpeg (9.0.1) removed. ffmpeg4.4 doesn’t exist on the AUR; ffmpeg7.1 was the closest available versioned build still old enough to keep those fields.

Coinstallable by design, no RPATH hacking needed

This AUR package namespaces its headers under /usr/include/ffmpeg7.1/ and its dev symlinks + pkgconfig under /usr/lib/ffmpeg7.1/ (--incdir/--libdir in its configure call) so it doesn’t clash with the main ffmpeg package’s own /usr/include//usr/lib files. But the actual soname-versioned runtime libraries (libavcodec.so.61 etc.) install straight into the normal system libdir /usr/lib/ — since ffmpeg7.1 uses soname 61 and current extra/ffmpeg (9.0.1) uses soname 63, there’s no collision, and any binary linked against ffmpeg7.1 finds its runtime .so.61 via the normal ld.so cache with no RPATH or ld.so.conf.d entry required. To link something against it at build time: -I /usr/include/ffmpeg7.1 and -L/usr/lib/ffmpeg7.1 -lavcodec ... (or PKG_CONFIG_PATH=/usr/lib/ffmpeg7.1/pkgconfig).

2026-08-14 build

Published x86_64 7.1.3-1 (ffmpeg7.1 + ffmpeg7.1-debug), clean build (large dependency list, most already satisfied by the system’s existing multimedia stack).

2026-08-27 rebuild (libbluray soname bump)

libbluray 1.5.0-1 landed in extra with soname bump (libbluray.so=3), breaking the installed ffmpeg7.1 7.1.3-1 which was linked against soname 2. AUR itself hadn’t bumped pkgver (still 7.1.3), so this was a packaging-only rebuild: pkgrel bumped 1 -> 1.1 (X.Y scheme per [[feedback_local_install_rebuilds]]), no source/PKGBUILD content changes. Fresh clone + repo_release.sh, clean x86_64-only build, published without incident. Old 7.1.3-1 archived normally.

2026-09-24: migrated to adapted/, aarch64 added

Needed a real local deviation (aarch64 added to arch=()) to unblock [[makemkv]]’s aarch64 build – local-install/’s whole convention is unmodified upstream PKGBUILDs (see [[feedback_local_install_rebuilds]]), so this no longer fit there. Moved the working tree from /data/INSTALL/ffmpeg7.1 (dropped its nested .git, since adapted/ isn’t itself a submodule here) into arch/adapted/ffmpeg7.1, removed the install_only_packages line.

Depended on [[svt-av1]] being built for aarch64 first (new adapted/svt-av1, see its own memory file) – official extra/svt-av1 never had an aarch64 build, and it’s this package’s only genuinely-missing dependency on that arch (every other apparent gap from pacman -Si was a false negative against a provides= match: jack2 satisfies jack, libglvnd satisfies libgl, sdl2-compat satisfies sdl2, libvpl satisfies onevpl).

pkgrel 1.1 -> 1.2. Built + published clean: x86_64 (refresh, 7m50s) and aarch64 (new, 54m9s on eurobuild14 with a temporary MAKEFLAGS=-j4 override, reverted back to the standing -j1 right after this session’s builds – see config/remote_build.conf).

Gotcha hit twice: eurobuild14’s local pacman db was stale right after each of svt-av1’s and this package’s own publish – pacman -Si <newly-published-pkg> returned nothing until a manual sudo pacman -Sy on the board. Worth doing proactively before any remote build that depends on something just published this same session.

i686 still not built for this package (arch=(x86_64 aarch64) only) – not attempted, no immediate consumer needs it yet ([[makemkv]]’s own i686 arch fails for exactly this reason, but that’s pending too).