Right now, we don't depend on dev-libs/gobject-introspection to avoid
the circular dependency and we do a has_version check to see if we need
to bootstrap it if it isn't installed.
On the binhost, we had a failure like:
```
FAILED: girepository/introspection/GLib-2.0.gir
[...]
Traceback (most recent call last):
File "/usr/bin/g-ir-scanner", line 99, in <module>
from giscanner.utils import dll_dirs
File "/usr/lib64/gobject-introspection/giscanner/utils.py", line 385, in <module>
import distutils.cygwinccompiler
ModuleNotFoundError: No module named 'distutils'
[...]
ninja: build stopped: subcommand failed.
* ERROR: dev-libs/glib-2.82.5::gentoo failed (compile phase):
```
That's because we automagically used the installed gobject-introspection's
g-ir-scanner which doesn't yet have *its* setuptools dependency satisfied
(or hasn't been rebuilt for the same Python impl that setuptools has been)
but Portage doesn't know that dev-libs/glib uses gobject-introspection, so
it doesn't see the need to rebuild it yet.
Workaround this (fix it, really) by checking `g-ir-scanner --version` doesn't
crash. This may end up fixing bug #951487 too (which is a separate problem).
(If it doesn't fix bug #951487, we can go further and do a has_version vs
--version check here, just care will be needed to sanitise the --version
output before passing it into has_version. Or perhaps best_version and
a glob would work better.)
Bug: https://bugs.gentoo.org/951487
Signed-off-by: Sam James <sam@gentoo.org>
For Qt 5, it's best to just disable reduce-relocations, because it
doesn't (unlike Qt 6) support -mno-direct-extern-access, which means
CMake applications building against Qt 5 are prone to all the issues
mentioned in the bug.
Bug: https://bugs.gentoo.org/754021
Signed-off-by: Sam James <sam@gentoo.org>
From 8.14.0, curl now installs the `wcurl` wrapper script
by default. This script can be used anywhere that `wget`
is used currently, and accepts the same options.
Signed-off-by: Matt Jolly <kangie@gentoo.org>
Quoting myself on the bug:
> I don't understand why it's even doing that. It should unconditionally set it
> to the right shebang instead (and perhaps use python-single-r1). But
> whatever, I'll add the workaround (dropping 3.10). Keeping the bug open
> to answer that point though.
Drop python3.10 given it obviously breaks now it's no longer a target.
Bug: https://bugs.gentoo.org/955281
Signed-off-by: Sam James <sam@gentoo.org>
There's no need for an explicit BDEPEND on it for a minimum version as
the eclass has SCONS_MIN_VERSION which is 4.4.0 these days. Supposing
we needed a newer version than it defaults to, we'd need to set SCONS_MIN_VERSION,
not add in the dep ourselves.
Signed-off-by: Sam James <sam@gentoo.org>
Michał Górny
Michael Mair-Keimberger
Sam James
Arthur Zamarin
Hans de Graaff
Patrick Lauer
Matt Jolly
Ionen Wolkens
Mike Gilbert
Ian Jordan