| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Run not only scripts inside build system, but also meson itself with
Python 3.11.
Fixes: eb4da3400a1c37eea7b258b00297e8b8fcdd8db4
|
|
|
|
|
| |
It is unstable and fails quite often. Just disable it and remove log
printing of failure.
|
| |
|
|
|
|
|
|
|
|
|
| |
There is a long-standing bug with random crashes of Python 3.10 on CI.
See:
https://github.com/python/cpython/issues/105400
https://github.com/msys2/MINGW-packages/issues/11864
https://github.com/msys2/MINGW-packages/issues/17415
|
|
|
|
|
|
|
|
|
| |
To avoid building against stale version of dependencies. In particular
libplacebo is moving target and as we can see the build has been broken
few times recently, so let the CI validate it for us.
The time to build everything is under 30 minutes, which is acceptable in
my opinion, not much longer than macos build.
|
|
|
|
|
| |
Allows python to download waf correctly, fixing CI failure due to its
outdated built-in certificate pool.
|
|
|
|
|
| |
luajit is currently crashing on 32-bit build:
https://github.com/msys2/MINGW-packages/issues/17042
|
| |
|
|
|
|
|
| |
libplacebo-next version requirement was increased recently, need to
rebuild it to fix mingw CI builds.
|
|
|
|
| |
libplacebo requires >= 0.63
|
|
|
|
|
|
|
| |
It turns out that you actually have to add failure() to each condition
otherwise a default status check of success() is applied (thanks
github). Looks redundant but whatever. Thanks to @kasper93 for actually
reading the documentation.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of running the test directly in the build script, we can make a
separate step in the workflow so it looks a little prettier. For running
the actual tests, we skip mingw since they will never be run (cross
compiled). Additionally, improve the github workflow logic a bit so that
way logs on failure are only shown when that specific step fails. The
freebsd job still has to be less elegant since it's in a weird vm
thingy.
Not really related but the location of various build directories
(particularly waf) are corrected as well (might as well).
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
While the waf build has served us well for many years, it's time to
officially consider it deprecated. The meson build was added fully with
the intention to eventually replace waf and its current state is more
than good enough to do that. Let's start the deprecation period now to
give users a heads up to switch before we remove waf for good.
|
|
|
|
|
|
|
|
|
|
| |
This way each time a new Python version is installed via Homebrew
, we don't get CI failures due to the upstream Python distribution
also being installed.
Ref: actions/runner-images#6459
Ref: actions/runner-images#6507
Ref: actions/runner-images#2322
|
|
|
|
|
|
|
| |
Workflow virtual machines have now been updated so that moby package
contains rule for the newly added syscalls, such as 'clone3'.
Effectively reverts 64fa440c697b9b8e96e14e33f7e79c6674c5b1a3 .
|
|
|
|
|
| |
These utilize a custom docker container in any case, but this brings
us to consistency with the mingw-w64 jobs.
|
|
|
|
|
| |
mingw-w64 has utilized this for a while so might as well make it
consistent.
|
|
|
|
|
|
|
| |
Thankfully, this version is no longer the default on any of the
macOS runners.
Effectively reverts a76527772eb52084c61241b89cfb42ce59f6f6a4 .
|
|
|
|
|
|
|
|
|
| |
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 f7164fcfaca1b1d8f0ceb9cb58e532c172cf83fa
and can now just use the package manager version.
|
| |
|
|
|
|
|
|
|
| |
- newer library versions
- use libplacebo submodules
- prefer meson where possible
- fix minor details
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Apparently an implicit dependency on it through one of the
otherwise installed packages is no longer there.
|
| |
|
|
|
|
| |
Reduce the churn by transparently picking up bustage fixes.
|
| |
|
|
|
|
|
| |
FreeBSD doesn't support /latest and /quarterly package repos on EOL
versions. 13.0 reaches EOL on 2022-08-31, so avoid CI breakage.
|
|
|
|
| |
This is needed for x11 which is in turn needed for vdpau.
|
|
|
|
| |
Newer image builds already include Meson.
|
| |
|
|
|
|
|
| |
Updates mingw-w64 to 8.0 as well as generally bumps the toolchain
to gcc 10.x.
|
|
|
|
|
|
| |
Apparently it is now in public beta.
ref actions/virtual-environments#5446
|
|
|
|
|
|
|
|
|
|
| |
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 78cfeee2b93830f2988508a653b508336147b79d.
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.
|
|
|
|
| |
We have this ao again since #9298 so let's run it through the CI.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
The old directory was wrong. The actual build directory has the matrix
prefix in its name.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
I find it both hilarious and sad that Github decided that defaulting
to XCode 13.0 was a good idea... At least they added 13.1 quickly.
Ref actions/virtual-environments#4180
Ref actions/virtual-environments#4300
|
| |
|
|
|
|
| |
This image has finally become public.
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Requested to be changed while at it.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 #7396
Fixes #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.
|
|
|
|
|
| |
--log-file uses debug log level by default. On command line, -v -v will
use debug log level.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Most files are LGPL anyway by now. contribute.md still requires
contributors to provide changes under LGPL, which should cover changes
to files that are LGPL, as well as GPL files.
|
|
|
|
| |
The latter seems to give 500 errors more often than not these days.
|
|
|
|
| |
Is there even anything that fucking sucks more than it?
|
|
|
|
| |
Since some users apparently can't figure this out.
|
|
|
|
|
|
| |
I guess there is a hard to balance tradeoff between appearing rude or
dismissive, and making the user think it's ok to not provide essential
information.
|
| |
|
| |
|
|
|
|
|
| |
Word this sentence slightly more positively because we are a positive
project.
|
|
|
|
|
| |
Also, try to save users from trying to use the github file upload
function. While we're at it, also make the sprunge.us hint a link.
|
| |
|
| |
|
|
I do not understand why github requires adding this crap to source code
repositories themselves, instead of making them part of the repository
configuration. Remove CONTRIBUTING.md to compensate for github crap
accumulating.
|