This new revision is based off François Bissey's ebuild in the
sage-on-gentoo overlay, which has accrued some fixes not present in
the ::gentoo version. Of note, it fixes an open build bug, and an
unreported issue where 32-bit libraries are detected on a 64-bit
system.
The update to EAPI=7 required only moving the LaTeX dependencies to
BDEPEND. In the process, I updated the LICENSE to LGPL-2.1+ because
upstream has done the same. I also looked long and hard for a reason
why we have RESTRICT=mirror in the ebuild. Finding none, I have
removed the restriction.
Closes: https://bugs.gentoo.org/470732
Closes: https://bugs.gentoo.org/688674
Package-Manager: Portage-2.3.84, Repoman-2.3.20
Signed-off-by: Michael Orlitzky <mjo@gentoo.org>
protontricks now have a setup-time dependency on
dev-python/setuptools_scm, which means we have to use use release
tarballs from PyPI rather than from GitHub - the latter cause builds to
fail with
LookupError: setuptools-scm was unable to detect version for '/.../app-emulation/protontricks-1.4.1/work/protontricks-1.4.1'.
Make sure you're either building from a fully intact git repository or PyPI tarballs. Most other sources (such as GitHub's tarballs, a git checkout without the .git folder) don't contain the necessary metadata and will not work.
The upshot of the above is that we can no longer run tests because
the necessary files are not included in PyPI tarballs.
Signed-off-by: Marek Szuba <marecki@gentoo.org>
The dependencies and build system of gmp-ecm have been improved over
the years, and much of the cruft in the ebuild could simply be
deleted. This commit adds an -r2, based on François Bissey's ebuild in
the sage-on-gentoo overlay, to modernize things. I've manually verified
the diff for sanity, and the test suite passes for me on amd64.
Closes: https://bugs.gentoo.org/466498
Package-Manager: Portage-2.3.84, Repoman-2.3.20
Signed-off-by: Michael Orlitzky <mjo@gentoo.org>
The main use case for rw is as a library, specifically one used by
SageMath. The "rw" executable was nice to have, but it pulls in
dev-libs/igraph, and igraph upstream has gone crazy and started
copy/pasting libraries into its "src" directory. Since igraph
will never be upgraded like that, it's staying unmaintained and
won't be stabilized, thereby blocking the stabilization of rw.
This commit drops the "rw" executable entirely, so that we can get rid
of the igraph dependency and stabilize a version of rw.
Package-Manager: Portage-2.3.84, Repoman-2.3.20
Signed-off-by: Michael Orlitzky <mjo@gentoo.org>
virtual/opencl uses media-libs/mesa[opencl] as driver-independent
fallback OpenCL provider. However, media-libs/mesa[opencl] depends
on dev-libs/libclc - which at the time of me writing this only
supports nvidia, r600 and radeonsi, and whose REQUIRED_USE clause
requires at least one of the corresponding VIDEO_CARDS flags to be
set. This effectively breaks the OpenCL dependency cycle for a lot of
configurations, e.g. for VIDEO_CARDS="nouveau" systems.
Only try to use Mesa as an OpenCL provider when VIDEO_CARDS includes a
GPU supported by dev-libs/libclc.
Note that this means there is now no fallback OpenCL provider for
ABI_X86_32. Moreover, for ABI_X86_64 the fallback provider is now
dev-util/intel-ocl-sdk, which almost certainly doesn't work on AMD CPUs
- which however should be mostly harmless (the package should simply do
nothing beyond satisfying virtual/opencl dependencies), especially given
many OpenCL-aware applications ignore CPU-type devices anyway.
Closes: https://bugs.gentoo.org/710724
Signed-off-by: Marek Szuba <marecki@gentoo.org>
Agostino Sarubbo
Craig Andrews
Michael Orlitzky
Andrey Grozin
Christoph Junghans
Matthew Thode
Mike Pagano
Marek Szuba
Miroslav Šulc
Louis Sautier
Stephan Hartmann
Joerg Bornkessel
Mikle Kolyada
Hans de Graaff