Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 731728 - media-libs/libplacebo-2.72.0 fails to compile due to no mako (using wrong python interpreter)
Summary: media-libs/libplacebo-2.72.0 fails to compile due to no mako (using wrong pyt...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Niklas Haas
Depends on:
Blocks: 768360
  Show dependency tree
Reported: 2020-07-08 12:52 UTC by Mart Raudsepp
Modified: 2021-02-02 13:33 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

build.log (build.log,22.84 KB, text/plain)
2020-07-08 12:54 UTC, Mart Raudsepp

Note You need to log in before you can comment on or make changes to this bug.
Description Mart Raudsepp gentoo-dev 2020-07-08 12:52:21 UTC
libplacebo is failing to compile with:

[1/59] /usr/bin/python3.6 ../libplacebo-v2.72.0/src/vulkan/ /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/ /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 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/ 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:

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).
Comment 1 Mart Raudsepp gentoo-dev 2020-07-08 12:54:02 UTC
Created attachment 648368 [details]
Comment 2 Mart Raudsepp gentoo-dev 2020-07-08 13:02:12 UTC
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.
Comment 3 Niklas Haas 2020-07-08 15:01:44 UTC
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.
Comment 4 Mart Raudsepp gentoo-dev 2020-07-08 15:38:16 UTC
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?
Comment 5 Niklas Haas 2020-07-10 14:43:37 UTC
> What was the reasoning to change from 'python3' to unset? Do you have references? was the bug that prompted the change.
Comment 6 Niklas Haas 2020-07-10 14:45:19 UTC
(In reply to Niklas Haas from comment #5)
> > What was the reasoning to change from 'python3' to unset? Do you have references?
> 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.