makemkv

Not tracked in arch/ — plain upstream AUR package, rebuilt from a fresh clone of https://aur.archlinux.org/makemkv.git into /data/INSTALL/makemkv. See arch/scripts/install_only_packages (local-install category) and [[feedback_local_install_rebuilds]].

Built x86_64 only. arch=(x86_64 i686 aarch64) upstream, i686/aarch64 deliberately not attempted.

Sources: makemkv.com is flaky, and the two tarballs must match pkgver

source= pulls makemkv-bin-${pkgver}.tar.gz and makemkv-oss-${pkgver}.tar.gz directly from https://www.makemkv.com/download/. That host intermittently returns Cloudflare 525 (SSL handshake failed between Cloudflare and origin) — seen 2026-08-14, resolved on its own after a while (not fixable from this side, just retry later or fetch manually). If fetching manually and dropping the file into /data/INSTALL/makemkv/ to skip the network fetch: the version must match pkgver exactly — an oss tarball for a different version than bin (or vice versa) fails signature/checksum validation, not just “wrong content.”

FFmpeg 9 incompatibility: needs ffmpeg7.1, not the system ffmpeg

makemkv-oss’s libffabi/src/ffabi.c reads AVCodec struct fields directly (ch_layouts, sample_fmts, supported_samplerates) that current extra/ffmpeg (9.0.1) no longer exposes (replaced by avcodec_get_supported_config()). Building against the system ffmpeg fails outright with “has no member named ‘ch_layouts’” etc.

Fix applied 2026-08-14 (inline PKGBUILD edit — local-only, will NOT survive a fresh git clone from AUR, must be re-applied on future rebuilds): build against [[ffmpeg7.1]] instead (a separately built+published local-install package, see its memory file for why 7.1 and not something newer/older):

• depends=(qt5-base ffmpeg7.1 libavcodec.so) — swapped ffmpeg for ffmpeg7.1 (the bare libavcodec.so soname dependency auto-resolves correctly at package time regardless).
• build(): ffmpeg_CFLAGS="-I/usr/include/ffmpeg7.1" ffmpeg_LIBS="-L/usr/lib/ffmpeg7.1 -lavcodec -lavutil" ./configure --prefix=/usr — the oss source’s autoconf configure accepts ffmpeg_CFLAGS/ffmpeg_LIBS env overrides that bypass its own pkg-config libavcodec libavutil detection entirely, which is more reliable than fighting PKG_CONFIG_PATH precedence against the system ffmpeg’s own .pc files.

No RPATH/runtime linking concerns — see [[ffmpeg7.1]]’s memory note on why its versioned .so.NN runtime libs resolve normally via the system libdir.

namcap flags libavcodec.so as “not required by any files” on the built package — harmless; ffabi’s codec support is evidently a runtime-loaded component of makemkv’s own binaries, not something namcap’s static NEEDED-entry scan picks up directly on the top-level executable.

2026-08-14 build

Published x86_64 1.18.4-1 (makemkv + makemkv-debug).

2026-08-16: sources now mirrored on our own repo host, not makemkv.com

makemkv is actually tracked in arch/private/makemkv now (the note above about it being a plain untracked AUR rebuild is stale — kept for historical context, not current). source= in its PKGBUILD used to pull both tarballs straight from ${url}/download/, hitting the Cloudflare-525 flakiness described above.

Fixed by adding a general-purpose flat src/ mirror dir on the repo host (${REPOSITORY_REMOTE_PATH}/src/, sibling of os//archive/, uploaded via the new scripts/repo_src_upload.sh) — see memory/REPO_PUBLISH_DESIGN.md §1/§3 for the general design. makemkv’s makemkv-bin-1.18.4.tar.gz and makemkv-oss-1.18.4.tar.gz were uploaded there and the PKGBUILD’s source= now points at https://archlinux32.andreasbaumann.cc/archlinuxaba/src/makemkv-{bin,oss}-1.18.4.tar.gz instead, with the original ${url}/download/... URLs kept as a comment above source= for reference. sha256sums unchanged (identical bytes, just re-hosted) and re-verified against the mirrored copy.

When bumping pkgver in future: the old flow of “fetch from makemkv.com, let makepkg checksum it” no longer applies automatically — the new tarballs must be fetched (from makemkv.com or wherever) and re-uploaded to src/ via repo_src_upload.sh before updpkgsums will succeed, since the URL now points at our own mirror which won’t auto-update. This is the same pattern to use for genuinely proprietary sources supplied out-of-band (e.g. jdk6-sun) — get the file from the human, repo_src_upload.sh it into src/, point source= there.

2026-08-16 build: published the pending 1.1 pkgrel (ffmpeg7.1 fix + src mirror)

pkgrel=1.1 had been sitting unpublished since 2026-08-14 (the ffmpeg7.1 build fix, see above); this session’s source-mirror change piggybacked on the same unreleased pkgrel, so no further bump was needed. repo_release.sh . run:

• x86_64: built clean against the new src/ mirror URLs (fetch + checksum both passed), signed, published. Old 1.18.4-1 (both makemkv and makemkv-debug) moved to archive/x86_64/.
• i686: error: target not found: ffmpeg7.1 — expected, not a regression: ffmpeg7.1 is a local-install package (see its own memory file) only ever built/published for x86_64, so any other arch’s chroot can never see it as a dependency. This matches the “Built x86_64 only… i686/aarch64 deliberately not attempted” note above; repo_release.sh now attempts i686 automatically (it’s in arch=() and a local archlinuxaba-i686-build exists) and fails loudly on it every time rather than silently skipping — harmless, x86_64 still published fine, just expect this FAILED line on every future rebuild until/unless ffmpeg7.1 is ever published for i686 too (unlikely, see its own memory file for why 7.1 specifically).
• aarch64: skipped, no local extra-aarch64-build, as always.

Published x86_64 1.18.4-1.1 (makemkv + makemkv-debug).