Supported since 0.52.13, released in 2011. Few packages need these
bindings, and it's simpler to update a system, the fewer random C
libraries attempt to acquire a lock on PYTHON_TARGETS.
Furthermore, newt is required by the command-line tools for
networkmanager, which is quite popular and means it is significantly
more likely that PYTHON_COMPAT *needs* to be kept promptly up to date.
Acked-by: Ben Kohler <bkohler@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
configuring building and installing multiple times is very complicated
and also tends to slow down due to repeated configures. Upstream since
2002 (!!!) has supported configuring and building for multiple python
versions in a single `./configure && make`
It is unclear why the copy+configure route was ever taken.
Acked-by: Ben Kohler <bkohler@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
During the most recent version bump, newt-0.52.21-python-sitedir.patch
was dropped from PATCHES, because upstream stopped installing python
code to --libdir. This represented an upstream fix for the problem the
patch tried to solve.
The downstream patch added a Makefile variable which was unset, and had
to be passed as a `make` parameter. We still passed that variable in
`emake` even though the patch which defined it stopped being applied.
Drop the outdated parameter.
Bug: https://pagure.io/newt/pull-request/26
Acked-by: Ben Kohler <bkohler@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
Back in 2018, version 0.52.21 got a dedicated configure parameter to
override the `ls /usr/include/python*/Python.h` used by default.
It was anyways pointless to pass it to econf and then individually
override it in every call to make, since the configure script doesn't
even try to look at the existing value. But anyways it's been six years
since it was relevant to use overrides. Get rid of them and use econf.
in fact, passing PYTHON at configure time was totally broken anyway. It
specifically needs EPYTHON, no full paths. This was correct when passing
the values to make.
Bug: https://pagure.io/newt/issue/3
Acked-by: Ben Kohler <bkohler@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
It silently disabled itself, because the qca ebuild dropped support for
qt5 in commit 931d0cbac6. Even before
that, this ebuild was broken, because it depended on qca[qt5] since commit
08ca947f7a added that USE. It's even
worse, because in commit 74f0b18009 we
"prepared" for qt5 to be the default in qca, and then dropped qt5(+)
entirely in commit 98e9711e2c.
So, once we performed the perennial recycling of Qt major version USE
flags, we no longer got qt5(+) for free, never noticed the dependency
was totally broken, and now the dependency no longer exists to be used.
Drop the USE flag entirely for now.
Fixes: 931d0cbac6
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
They have heard that zlib-ng is "next-gen":
https://github.com/openpmix/openpmix/commit/a20b2851b29407882bb293334f74c419ceffebd4
So now they "prefer" it except actually they end up building both zlib
and zlib-ng support at the same time. The latter, only if build servers
had it installed for something else, which the binhost does, leading to
broken binaries.
Disable it since zlib is already present.
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>