The 32-bit builds were disabled, because some packages started
disappearing. MSYS2 is slowly phasing out 32-bit support, but since we
still support it we have to test it somehow. Recent brakage with calling
convention mismatch would be spotted a lot quicker. So enable it, but
with some, not available, packages disabled.
This reverts a56d5c7fa1
Ubuntu 24.04 linux-azure kernel, used on GHA, is compiled with
CONFIG_COMPAT_32BIT_TIME=n. This prevents running any 32-bit binaries
through wine, so disable tests when doing i686 build. 32-bit builds are
still tested on Windows.
See: https://github.com/actions/runner-images/issues/9977
This uses an alpine 3.15 container, which should be one of the oldest
distros that mpv master can compile on and that uses ffmpeg 4.4. Some
functionality is missing due to library versions being too old on
alpine, e.g. wayland, mujs, and pipewire.
The alpine build is also explicitly minimal, to test builds in
conditions where many common mpv features may not be available.
With 1.3.277 the AV1 decode headers have been upstreamed.
These get preferred over ffmpeg's internal non-standard header
for this extension (same name). FFmpeg currently only builds
using its own header and a patch to work with upstream ones
is in review.
For now pin vulkan at the version before that to unbreak our CI.
This package isn't available for i686 anymore, and not worth the hassle
to only install it for win64 since it isn't particularly useful.
See: fff2fa3711
As it is now, the FreeBSD CI is failing because meson can't find the
dvb headers.
FreeBSD puts the relevant headers into /usr/local which is bothersome
and in fact required a workaround to be added to the Wayland detection
already (3bdf702b1d) but this should be
addressed by us adding the path to CFLAGS already.
With a more minimal example the detection works fine in my FreeBSD VM.
I'm at my wits end debugging this so just disable it for now.
This actually started having a linking error a few days ago, but the ci
never actually actually exited 1 for some reason so it was never caught.
The actual commits where this started happening are unrelated (reverted
all of the them to be sure) and there's no other obvious things like a
meson update that would cause this. All I can assume is some other
package within BSD itself, but I can't be bothered to debug it. Anyways,
just disable iconv in the build for now so the CI stops failing.
Presumably there's something wrong in the environment with GNU's
libiconv and the built-in one clashing somehow. Also, sdl unbelievably
defines HAVE_ICONV in their public header so we have to disable that
too.
Kacper Michajłow
Guido Cella
sfan5
Jan Ekström
Andarwinux
nanahi
LaserEyess
der richter
Dudemanguy
llyyr