Workflow virtual machines have now been updated so that moby package
contains rule for the newly added syscalls, such as 'clone3'.
Effectively reverts 64fa440c69 .
This older image has been deprecated and will be removed in December.
The images have also already had planned outages during which the CI
flow has been affected. Thus it feels like a good idea to clean
this up at this point.
Ref: actions/runner-images#5583
This was only needed because the mingw CI used to run on Ubuntu 20.04
which had a version of meson too old for mpv. This hasn't been the case
since we switched to 22.04 in f7164fcfac
and can now just use the package manager version.
Despite being run in a VM, the workflow actually copies the files back
to the host. We can then explictly print the error logs on failure in
their own separate section for visibility instead of it being hidden
within all the vm output.
Recently, git patched a CVE which makes it much more strict about
different users operating on directories they don't own. For us, this
causes breakage with version.sh and version.py since they both run a git
describe command to fetch the commit hash. Currently, this only affects
the tumbleweed container (likely because it was recently changed) and
thus the git describe command always errors out. Workaround this by just
explictly adding the mpv directory as a safe directory for git.
LuaJIT is still actively developed, but upstream is allergic to making
new releases for whatever reason. The last tagged release was in May of
2017, so we probably shouldn't expect a new release anytime soon. Now
for mpv, this doesn't really matter except in the case of macOS where
2.0.5 is actually a bit broken (and of course the CI uses luajit). More
specifically, the 2.0.5 pc is broken and has a "-pagezero_size 10000"
flag which causes libmpv to fail (only executables are allowed to use
this). This magically works on waf. It's possible that it just happens
to ignore the link arguments. However on the meson build, this is broken
and led to a really ugly hack using a partial dependency so both mpv and
libmpv succeed. Fortunately, the 2.1 luajit branch fixes this.
Unfortunately, there's no actual release.
Instead, just use Lua 5.1. Note that lua 5.1 is technically deprecated
in homebrew, but the chances of this going away is pretty slim since
everyone knows that new lua versions are not backwards compatible.
Anyways, using 5.1 works fine and lets us get rid of a terrible hack in
the meson build. People really shouldn't be using 2.0 LuaJIT anyway.
This define was always just a stopgap for that two month period (August
2021 - October 2021) where the bytes_read field in ffmpeg was completely
missing. Before that time, it was a private member in a struct (which
mpv used). Afterwards, it officially became public. Fortunately, the
lack of this field never actually made it into a release, so it could
have only possibly affected people building from the master branch.
Since ffmpeg 5.0 came out recently, and it's been plenty of months since
that two month window, we can go ahead and drop this check. This
finishes up the work done in 78cfeee2b9.
Sidenote: the cached ffmpeg version in the mingw ci were from that time
period when the bytes_read field was missing. The N in the workflow is
bumped to force a full rebuild and fresh clone of ffmpeg.
When this was originally added, some OS package managers were slow and
behind the required meson version needed for mpv to build. Both opensuse
tumbleweed and freebsd now appear to carry meson 0.60.3 in their repos
so we no longer need to do the two-step process of installing pip3 and
then installing meson via pip. Instead, just use the OS package manager
version.
Update the github workflows to also do meson builds for every OS.
Additionally, make every workflow execute the built mpv executable
(except for windows and FreeBSD's waf executable) to make sure that it
runs. As an aside, FreeBSD unfortunately is a bit less elegant since it
is in a VM.
This CI builder bases on openSUSE Tumbleweed, and recently had
its glibc updated. This led to new syscalls such as 'clone3' not
being allowed through the security layer.
Can be reverted after Github Actions updates their security policy.
actions/virtual-environments#3812
this creates a default log for the last mpv run when started from the
bundle. that way one can get a log of what happened even after an issue
occurred. also add a menu entry under Help to show the current log, but
only when the bundle is used.
Fixes#7396Fixes#2547
It's not that we _want_ the log to be on an external site. We just want
the log, somehow. Probably not pasted inline into the issue text.
Also reword the "we are assholes who really want logs" part of the text.
It's a subtle balance between trying to be nice and being a complete
asshole, but no matter what you do, it will always sound like the
latter, so be direct.
How hard can it be? I know contribute.md is a shitty wall of text, but
that doesn't make it less important, and each violation will make it
take longer by adding another review round anyway.
And we really don't need lazy pull requests. If you can't be assed to
follow a few simple rules, your code is probably shit or you wanted to
be quick and lazy. Why should we accept it? We're the ones who have to
maintain it and fix bugs in it, and if the contributor is lazy, the
chance of you maintaining it is probably slim as well. On the other
hand, WE the maintainers are not obligated to anything.
Don't say that though, the first contact doesn't need to be negative. I
don't know if the "lazy pull requests" is still too strong, but I can't
tell.
Jan Ekström
Dudemanguy
sfan5
Thomas Weißschuh
Jan Beich
SukkaW
Mia Herkt
a1346054
der richter
Philip Sequeira
wm4