This effectively bumps minimal MinGW-w64 requirement to v11.0.1. As it
is available in the latest Ubuntu LTS.
While at it clean installed packages list.
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.
Homebrew finally pulled the plug on lua 5.1*, and it is no more. So we
have to change to a different lua package and the only other choice is
luajit (no 5.2 in homebrew). We used to use luajit for the ci, but
649556b2b6 switched it to lua 5.1. As
explained there, luajit 2.0 was horribly bugged and not usuable for mpv
and the build had to do dumb hacks to work around it. I expected 5.1 to
last a bit longer than a couple of years, but luckily it seems like
luajit in homebrew now pulls a luajit 2.1 version (some rolling release
thing or however upstream works). The details don't really matter for
us since 2.1 does not have all the awful issues that 2.0 used to have.
So just switch to luajit again.
*: 57d73df3ba
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
In the pursuit of stability.
It is slower and QEMU-based, but if this isn't stable, I don't know what
will be.
Bump the timeout to 30 minutes, just in case. It seems to take 12-15
minutes to finish.
Since vmactions is basically a bootlooping disaster* with no signs of
life from upstream, let's try a different action instead and hope it
works better. We don't need to force the latest release channel, so
delete that part. Also make the pkg install just one command for
simplicity.
*: https://github.com/vmactions/freebsd-vm/issues/74
I won't even comment how terrible this option is and why in 2023 default
is not at least `autocrlf=input`.
Disable the conversion to CRLF. We build everything in MSYS2 sysroot,
which supports/expects LF. While the checkout itself is done with
actions/checkout@v3 and this causes problems.
Homebrew has finally given up supporting macOS 11, and all updated
dependencies are being built locally. Additionally, python3.12 - being
a dependency of libass in Homebrew - seems to completely fail under
cairo's meson usage on macOS 11, even if we let it build.
Thus, finally remove macOS 11 from our macOS build matrix, leaving
12 and 13.
ref: Homebrew/brew#16019
When someone purely changes some documentation or something similar,
there's no point in having the whole CI build go off. This also leads to
the bot spamming a comment linking to artifacts. This is only useful if
actual source code changes (i.e. so users can test if need). So just add
a path filter to blacklist directories we don't want to consider. If all
changed files match those directories then the CI won't run.
Python 3.11 will be released soon as default Python package, and
actually python3.11 package already disappeared from the repository.
This reverts commit c637beb522.
Can significantly reduce build time, most of dependencies have fixed
versions, so they can be cached fully. Others will be incrementally
build.
Cache is saved on every run and restored from the newest one. Size is
limited to 500M (compressed) to keep cache save/restore fast. Clean
cached build is little over 100M, so we have a headroom as things will
grow. ccache will automatically evict least recently used entries.
It is unlikely that clean build will exceed the limit anytime soon, but
it is something to keep in mind, as we do not want to evict cache
entries from current build, so the cache size need to be set correctly.
Kacper Michajłow
der richter
Andarwinux
LaserEyess
Dudemanguy
nanahi
llyyr
Jan Ekström
sfan5
Niklas Haas