dev-python/pycuda
Python wrapper for NVIDIA CUDA
Screenshots
View
Download
BrowseChangeLog
commit 7e7eff6aded09584cd27a8dce87cf5534969a527
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Apr 29 01:43:10 2026 +0200
dev-python/pycuda: add 2025.1.3
Adds pycuda 2025.1.3 (released 2026-02-18) alongside 2026.1, in
line with the overlay's last-of-each-major-series retention
policy.
The 2025.1.x maintenance branch tracks the 2025-API line in
parallel with 2026.x; install_requires are identical to 2026.1
(mako, numpy, platformdirs, pytools), so the ebuild is a straight
copy of pycuda-2026.1 with only PV/SRC_URI differing.
Tested with ebuild ... clean install against the live cuda
toolkit; no QA notices.
commit 54fbf16529cb77cd87024c992e0ad3582547b34d
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Apr 29 01:42:52 2026 +0200
dev-python/pycuda: set DISTUTILS_EXT=1
The package builds and installs compiled extension modules
(_pvt_struct.so, _driver.so), so distutils-r1.eclass requires
DISTUTILS_EXT=1. Without it, portage emits a QA notice:
QA Notice: Python extension modules (*.so) found installed.
Please set:
DISTUTILS_EXT=1
in the ebuild.
::gentoo's pycuda-2024.1 ebuild has the same omission; this
overlay's ebuild is now ahead.
commit 3510272e319af71171d860684b57e4b96200bd4e
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Apr 23 14:41:20 2026 +0200
dev-python/pycuda: new package, add 2026.1
::gentoo only ships pycuda-2024.1 with PYTHON_COMPAT=python3_.
That leaves dev-python/sasmodels (which cuda?-gates pycuda but claims
python3_) tripping NonsolvableDepsInStable on ~amd64 for the
py3.13/3.14 targets, even though the conditional is never hit for
the cuda-off default. sasmodels can't narrow its own PYTHON_COMPAT
without losing current-default-python coverage, and pkgcheck tests
all USE configurations regardless.
Ship the current upstream pycuda-2026.1 (released 2026-01-15) as an
overlay-local bump. Upstream declares python_requires="~=3.8" and
this keeps landing on py3.13/3.14-capable numpy/boost-python builds
without issue. Changes from ::gentoo's 2024.1 ebuild:
- PYTHON_COMPAT: 3.10..3.12 -> 3.12..3.14 to match current default
python targets and cover sasmodels.
- RDEPEND: upstream install_requires dropped appdirs (replaced by
platformdirs) and decorator. Mirror that here.
- EPYTEST_PLUGINS=() added to quiet pkgcheck's
EPyTestPluginsSuggestion.
- metadata.xml carries personal maintainer in the overlay's
canonical form.
sasmodels' NonsolvableDepsInStable clears as a result; pkgcheck
total 59 -> 56.
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Apr 29 01:43:10 2026 +0200
dev-python/pycuda: add 2025.1.3
Adds pycuda 2025.1.3 (released 2026-02-18) alongside 2026.1, in
line with the overlay's last-of-each-major-series retention
policy.
The 2025.1.x maintenance branch tracks the 2025-API line in
parallel with 2026.x; install_requires are identical to 2026.1
(mako, numpy, platformdirs, pytools), so the ebuild is a straight
copy of pycuda-2026.1 with only PV/SRC_URI differing.
Tested with ebuild ... clean install against the live cuda
toolkit; no QA notices.
commit 54fbf16529cb77cd87024c992e0ad3582547b34d
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Apr 29 01:42:52 2026 +0200
dev-python/pycuda: set DISTUTILS_EXT=1
The package builds and installs compiled extension modules
(_pvt_struct.so, _driver.so), so distutils-r1.eclass requires
DISTUTILS_EXT=1. Without it, portage emits a QA notice:
QA Notice: Python extension modules (*.so) found installed.
Please set:
DISTUTILS_EXT=1
in the ebuild.
::gentoo's pycuda-2024.1 ebuild has the same omission; this
overlay's ebuild is now ahead.
commit 3510272e319af71171d860684b57e4b96200bd4e
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Apr 23 14:41:20 2026 +0200
dev-python/pycuda: new package, add 2026.1
::gentoo only ships pycuda-2024.1 with PYTHON_COMPAT=python3_.
That leaves dev-python/sasmodels (which cuda?-gates pycuda but claims
python3_) tripping NonsolvableDepsInStable on ~amd64 for the
py3.13/3.14 targets, even though the conditional is never hit for
the cuda-off default. sasmodels can't narrow its own PYTHON_COMPAT
without losing current-default-python coverage, and pkgcheck tests
all USE configurations regardless.
Ship the current upstream pycuda-2026.1 (released 2026-01-15) as an
overlay-local bump. Upstream declares python_requires="~=3.8" and
this keeps landing on py3.13/3.14-capable numpy/boost-python builds
without issue. Changes from ::gentoo's 2024.1 ebuild:
- PYTHON_COMPAT: 3.10..3.12 -> 3.12..3.14 to match current default
python targets and cover sasmodels.
- RDEPEND: upstream install_requires dropped appdirs (replaced by
platformdirs) and decorator. Mirror that here.
- EPYTEST_PLUGINS=() added to quiet pkgcheck's
EPyTestPluginsSuggestion.
- metadata.xml carries personal maintainer in the overlay's
canonical form.
sasmodels' NonsolvableDepsInStable clears as a result; pkgcheck
total 59 -> 56.