libplacebo is failing to compile with: [1/59] /usr/bin/python3.6 ../libplacebo-v2.72.0/src/vulkan/utils_gen.py /usr/share/vulkan/registry/vk.xml src/utils_gen.c FAILED: src/utils_gen.c /usr/bin/python3.6 ../libplacebo-v2.72.0/src/vulkan/utils_gen.py /usr/share/vulkan/registry/vk.xml src/utils_gen.c Module 'mako' not found, please install 'python3-mako' or an equivalent package on your system! While the ebuild has all the correct checks for the correct mako, it isn't helping, because meson is launching utils_gen.py with python3.6, instead of what python-any-r1.eclass chose and set up in $EPYTHON and co. This happens because meson is launching it with the same version as meson itself is using, not what we want it to, and my meson is (intentionally to spot these issues) still using only python3.6. To fix this, the prog_python = import('python').find_installation() line in src/meson.build needs to change to prog_python = import('python').find_installation('python3') as then meson will explicitly re-evaluate what python to use, instead of just picking whatever it itself is using. This is documented here: https://mesonbuild.com/Python-module.html So unless the build system should be using the same version as meson itself, it should not leave the first argument empty there, but explicitly request python3. This automatically makes it work correctly for mako finding, as this re-discovery will allow python-any-r1 setup variables to affect it and it'll do what is expected of it. This is something that should be fixed upstream as well, in my opinion - the argument being that the python version used by meson shouldn't affect what gets used for the utility (e.g., meson could be using python2).
Created attachment 648368 [details] build.log
After locally fixing bug 731728, I hit another problem in compilation, due to having too old vulkan-headers (as I had it installed, but nothing else was forcing an upgrade of it, just like libplacebo didn't). So a minimum version dependency might be in order - however the oldest currently available main tree vulkan-headers is sufficient, so it's not an issue for most and not strictly a required mindep according to others.
This was specifically changed upstream from 'python3' to '' because of a different bug report. When authoring this ebuild I was advise that meson would be run using the same python version as those checks. I didn't realize it's hard-coded as python3.6. Is it possible that we could hard-code the libplacebo ebuild to use the same python version as meson? (That also avoids the need for PYTHON_COMPAT and stuff) Alternatively we could patch it in the ebuild.
No, that doesn't seem possible, and meson is ran by user chosen python, not anything in portage control. What was the reasoning to change from 'python3' to unset? Do you have references?
> What was the reasoning to change from 'python3' to unset? Do you have references? https://code.videolan.org/videolan/libplacebo/-/issues/97 was the bug that prompted the change.
(In reply to Niklas Haas from comment #5) > > What was the reasoning to change from 'python3' to unset? Do you have references? > > https://code.videolan.org/videolan/libplacebo/-/issues/97 was the bug that > prompted the change. Actually, looking at the bug report again, it seems to me that it would be fine to work around that particular bug by using the logic in my comment (i.e. looking for 'python3' first and only using '' as a fallback), which would also make it work on Gentoo.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9cdc7c96e725f66601c24233b332eeee68e1da84 commit 9cdc7c96e725f66601c24233b332eeee68e1da84 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-11-06 10:54:40 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-11-07 19:27:56 +0000 media-libs/libplacebo: add 5.229.1 With partly revamped ebuild, and: * ensure use right python executble wrt bug #731728 * disable demos wrt bug #851927, there's little use in enabling as only one of them gets installed by default and it's a very barebone test video player USE=glslang is now a no-op if shaderc is set, these provide the same functionality and shaderc is the default pick upstream. Previously, glslang would force disable shaderc even if set. Alternatively could use REQUIRED_USE to prevent setting both but feel this is mostly an annoyance. Closes: https://bugs.gentoo.org/731728 Closes: https://bugs.gentoo.org/851927 Co-authored-by: Nick Sarnie <sarnex@gentoo.org> Signed-off-by: Ionen Wolkens <ionen@gentoo.org> media-libs/libplacebo/Manifest | 2 + .../files/libplacebo-5.229.1-llvm-libunwind.patch | 9 +++ .../libplacebo-5.229.1-python-executable.patch | 11 +++ .../files/libplacebo-5.229.1-shared-glslang.patch | 12 +++ media-libs/libplacebo/libplacebo-5.229.1.ebuild | 91 ++++++++++++++++++++++ 5 files changed, 125 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0e1f8f4089ddfe21900556d71fd9a271684b5fbd commit 0e1f8f4089ddfe21900556d71fd9a271684b5fbd Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-11-06 11:43:46 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-11-07 19:27:56 +0000 media-libs/libplacebo: build fixes for stable Just non-intrusive fixes partly backported from the ~arch ebuild: * ensure use right python executble wrt bug #731728 * disable demos wrt bug #851927 * require <glslang-1.3.231 (~arch is fixed with newer) * multilib usedep for unwind * add := to glslang for upcoming subslot, albeit this won't really get to use it given the above Bug: https://bugs.gentoo.org/731728 Bug: https://bugs.gentoo.org/851927 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> .../files/libplacebo-4.192.1-python-executable.patch | 8 ++++++++ ...bo-4.192.1-r1.ebuild => libplacebo-4.192.1-r2.ebuild} | 16 ++++++++++++---- 2 files changed, 20 insertions(+), 4 deletions(-)
