* Call python-single-r1_pkg_setup (i.e. python_setup) conditionally
based on USE=cairo to match the other Python conditionals
* Fix style (conditional last, not first in *DEPEND; whitespace; variable
order)
Closes: https://bugs.gentoo.org/950448
Signed-off-by: Sam James <sam@gentoo.org>
The existing check makes an intimidating value proposition: that all
software being checked was installed using distutils-r1.eclass, hence
moving the check from there as-is to a new home is sufficient. This
includes the use of functions specific to the distutils-r1 eclass
inheritance chain. In particular, get_modname is part of
multilib.eclass, which distutils-r1 inherits, but python-single-r1 does
not inherit.
This results in the following QA warning:
```
/var/db/repos/gentoo/metadata/install-qa-check.d/60python-site: line 53: get_modname: command not found
/var/db/repos/gentoo/metadata/install-qa-check.d/60python-site: line 53: get_modname: command not found
/var/db/repos/gentoo/metadata/install-qa-check.d/60python-site: line 53: get_modname: command not found
* Verifying compiled files for python3.12
*
* QA Notice: Extensions found compiled for the wrong Python version
* (likely broken build isolation):
*
* /usr/lib/python3.12/site-packages/__pycache__/init_calibre.cpython-312.pyc
* /usr/lib/python3.12/site-packages/__pycache__/init_calibre.cpython-312.opt-1.pyc
* /usr/lib/python3.12/site-packages/__pycache__/init_calibre.cpython-312.opt-2.pyc
```
because we are matching all files matching "*.cpython*" that are also
named "*" instead of all files named "*$(get_modname)".
Instead of using multilib.eclass, go directly to the preferred canonical
source, and query cpython what *it* thinks a module extension should be.
This is also more flexible since cpython itself doesn't really guarantee
that extension modules are named anything like get_modname, but
generally equals -- for backwards compatibility -- the final value from
`_PyImport_DynLoadFiletab` / `_imp.extension_suffixes()` (and on
Windows, that is .pyd instead of .dll, though admittedly,
sysconfig.get_config_vars is pretty empty there; on the other hand, PyPy
doesn't recognize unadorned .so because it doesn't need the
compatibility, so we see that it's not really a guarantee, and might as
well go for the sysconfig variable which is unambiguous where present).
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>
One of the upstream backports on releases/gcc-13 clashes with our
gimple split backports, so revert that before applying the split changes,
then apply the version on master afterwards. It's noted that the file the
reverted backport touches is different in the commit anyway for exactly
this reason.
Signed-off-by: Sam James <sam@gentoo.org>
...aside from too many changes to follow up on, even upstream both
qmake and cmake are broken right now, so nothing to target with 9999.
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
Michał Górny
Sam James
Hans de Graaff
Jakov Smolić
Christopher Fore
Eli Schwartz
Michael Orlitzky
Andreas Sturmlechner
Alfredo Tupone
Lukas Schmelting
Conrad Kostecki