FS#74863 - [mpv] Build fails with waf 2.0.24, must downgrade to 2.0.23

Attached to Project: Community Packages
Opened by James Harvey (jamespharvey20) - Thursday, 26 May 2022, 23:54 GMT
Last edited by Alexander Epaneshnikov (alex19EP) - Saturday, 28 May 2022, 18:58 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Alexander Epaneshnikov (alex19EP)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
Since maf is just a makedepend, probably nothing for Arch to do until it needs to release a new mpv anyway. Maybe there will be a new version of mpv then that supports waf 2.0.24. If not, mpv can be built using meson now to avoid the entire maf issue. Compiling this package with vapoursynth support was supposed to be simple. :-)

Additional info:
* 0.34.1-4
* Reported upstream: https://github.com/mpv-player/mpv/issues/10234
** Upstream said "Waf is not supposed to be forwards-compatible like that, generally you use the version of waf the project ships."
** I don't know waf, so I'm not going to argue that point, but since Arch likely isn't going to want to have a waf2024 package installable in parallel to waf (i.e. like python2 and python3) the simplest way to build the next package if upstream hasn't fixed this is to change to build using meson.
* config and/or log files etc.
With only changing PKGBUILD to add "set -x" in build():
----------
==> Starting build()...
+ pwd
/build/mpv-vapoursynth-mine/src
+ cd mpv
+ pwd
/build/mpv-vapoursynth-mine/src/mpv
+ waf configure --prefix=/usr --confdir=/etc/mpv --enable-cdda --enable-dvb --enable-dvdnav --enable-libarchive --enable-libmpv-shared --disable-build-date --disable-caca
Error: run waf-light from a folder containing waflib
----------

Steps to reproduce:
Attempt building using devtools' extra-x86_64-build.

Comments:
* waf was just upgraded from 2.0.23-1 to 2.0.24-1 on May 22. Downgrading to 2.0.23-1 allows configuring and building. I know practically nothing about waf or waflib.
* The mpv-git AUR package changed a while ago to building mpv using meson, which was "recently added upstream as an alternative to waf" - qmega.
* Using meson sidesteps the issue.
This task depends upon

Closed by  Alexander Epaneshnikov (alex19EP)
Saturday, 28 May 2022, 18:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  waf-2.0.24-2-any.pkg.tar.zst
Comment by loqs (loqs) - Friday, 27 May 2022, 00:52 GMT
It is a bug in the waf 2.0.24-1 update. The update moved the following to global scope
_py_ver=$(python3 -c "import sys; print(str(sys.version_info.major)+'.'+str(sys.version_info.minor))")
which produces
/startdir/PKGBUILD: line 27: python3: command not found
because it has been executed in the clean chroot before python3 has been installed, resulting in the variable being set to an empty string and waflib is not adjusted to point to the correct location hence the error you encountered.
Comment by James Harvey (jamespharvey20) - Friday, 27 May 2022, 20:59 GMT
loqs, looks like that's a separate issue, I'm thinking that can be encountered when compiling waf. What I ran into was when compiling mpv, when attempting to use the pacman repo package for waf, which sidesteps what you're talking about.

Note quite a bit of discussion happened on the linked upstream issue at https://github.com/mpv-player/mpv/issues/10234

From the discussion there, it looks like the way forward is to ignore this until a new version of mpv is released, then switch to using meson instead of waf. The latest mpv release doesn't have meson support. If a runtime dependency of mpv forces a recompile, then come up with plan b. If anyone else needs to compile their own mpv, consider using mpv-git in the AUR for now.
Comment by loqs (loqs) - Friday, 27 May 2022, 21:23 GMT
@jamesharvey I can build mpv-1:0.34.1-4 with waf 2.0.24-1 with fixed waflib path. I can produce the error message you encountered using waf 2.0.23 using the build for 2.0.24-1 and downgrading the pkgver.

You can verify this locally but you will need to use a clean chroot to reproduce the issue in the waf build.
Edit:
You can also prove it is an issue in waf by trying to build any other package from [1] that uses the waf build system.
Three I picked at random ardour, element and sord all fail to build using waf 2.0.24-1 with
Error: run waf-light from a folder containing waflib
All build with the fixed waf 2.0.24 package.
Edit2:
Attached minimal revert of PKGBUILD changes [2] to allow correct building of waf 2.0.24-1 in a clean chroot.

[1] https://archlinux.org/packages/community/any/waf/
[2] PKGBUILD.diff
Comment by James Harvey (jamespharvey20) - Saturday, 28 May 2022, 00:39 GMT
@loqs, you're 100% correct. I didn't look at what you were saying long enough. Sorry about that. I thought you were talking about a compilation error for maf, but I see now how you're saying it compiles but causes the error I ran into.

Yep, maf 2.0.24-1 is the culprit. Once fixed, future mpv's can stay with maf if desired. Or, it can move to meson to get away from maf, once upstream releases a new mpv.

Loading...