lib32-sdl2-compat

Category: local-install, plain unmodified AUR rebuild (no local edits). Rebuilt via the standard yay -Qu-triggered workflow — found outdated on euronuc, not tracked under arch/, rebuilt+published for archlinuxaba per [[feedback_local_install_rebuilds]]. Has validpgpkeys (Sam Lantinga’s SDL key) — ran arch/scripts/update_pgp_key_dir.sh from inside the checkout before building; key was already known to the local GPG keyring.

2026-09-21: uncovered a real multilib gap in the x86_64 chroot

First build attempt failed: depends=('sdl3' 'lib32-glibc' 'lib32-sdl3' 'sdl2-compat') needs lib32-sdl3, which only exists in the official multilib repo. The archlinuxaba-x86_64 build chroot’s pacman config (arch/config/pacman.conf.d/archlinuxaba.conf, used for x86_64 since there’s no archlinuxaba-x86_64.conf override) had no [multilib] repo enabled at all — error: target not found: lib32-sdl3, build aborted with “no arch built successfully”.

Fixed with the user’s go-ahead by adding a [multilib] section to arch/config/pacman.conf.d/archlinuxaba.conf (see that file’s own comment for the full rationale). Confirmed this only affects the x86_64 chroot — i486/i686/pentium4 each have their own archlinuxaba-<arch>.conf override that takes precedence and is untouched by this change, so no risk of multilib leaking into the native-32-bit archlinux32 chroots. Also confirmed empirically that the fix took effect on an already-created chroot with no rebuild/-c clean needed — archbuild’s -C <pacman_config> is passed to arch-nspawn on every invocation (not just chroot creation), so editing the project-local conf file alone was enough; the next repo_release.sh run picked it up after a plain pacman -Syuu inside the existing chroot.

Retried after the fix: built, signed, and published cleanly (x86_64 only, arch=(x86_64)).

Open question for future lib32-* packages: memory/grub-legacy.md records that package’s lib32-glibc/lib32-gcc-libs deps resolving successfully on 2026-08-27, before this multilib section existed — never root-caused how that worked (possibly the chroot state at the time differed, or those two specific packages were resolvable some other way). Not investigated further since the multilib fix here is a strict superset of that resolution path going forward. If a different lib32 dependency ever fails to resolve again despite multilib being enabled, check whether it needs multilib-testing or is Archlinux32- specific (unlikely to exist for compat libraries).