devel/py-pyopencl: update 2026.1.2 → 2026.1.4 PR: 298721 Approved by: Max Brazhnikov <makc@FreeBSD.org> (on behalf of python@)539e0005a1
Port details
devel/py-pyopencl2026.1.4
Python wrapper for OpenCL
- Maintainer
- python@FreeBSD.org
- Packages
- py312-pyopencl 2026.1.4
- Upstream
- up to date
- CPE
- none, CVEs only via VuXML
- WWW
- https://mathema.tician.de/software/pyopencl/
- Links
- cgit · VuXML
Unaddressed (0) · The CVE record lists this version as affected, no VuXML entry names the CVE
None. There is no CVE without a VuXML entry for this version.
VuXML only (0) · listed, port not fixed yet
None.
pkg audit reports nothing for this version.Fixed (0)
No VuXML entries for this package.
Commits (47)
devel/py-pyopencl: Update to 2026.1.2 and switch to NumPy 2 Changes: https://github.com/inducer/pyopencl/releases/tag/v2026.1.1 PR: 294328 PR: 294572ad13f95360
math/py-numpy: switch all consumers to math/py-numpy1 ...and bump PORTREVISIONs of consumers with hard RUN_DEPENDS PR: 281470d4bd5ba72e
devel/py-pyopencl: Pass nullptr instead of NULL to unique_ptr constructor This applies upstream commit bf3cb670f30bc2c5dfec102b147b41146381d769. PR: 286476 Reviewed by: lwhsu Differential Revision: https://reviews.freebsd.org/D50350ffeff2e545
devel/py-pyopencl: Convert to USE_PYTHON=pep517 - Sort BUILD_DEPENDS - Remove PYNUMPY - Bump PORTREVISION for package changedabe075d71
all: remove explicit versions in USES=python for "3.x+"
The logic in USES=python will automatically convert this to 3.8+ by
itself.
Adjust two ports that only had Python 3.7 mentioned but build fine
on Python 3.8 too.
finance/quickfix: mark BROKEN with PYTHON
libtool: compile: c++ -DHAVE_CONFIG_H -I. -I../.. -I -I. -I.. -I../.. -I../C++ -DLIBICONV_PLUG -DPYTHON_MAJOR_VERSION=3 -Wno-unused-variable -Wno-maybe-uninitialized -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -Wall -ansi -Wno-unused-command-line-argument -Wpointer-arith -Wwrite-strings -Wno-overloaded-virtual -Wno-deprecated-declarations -Wno-deprecated -std=c++0x -MT _quickfix_la-QuickfixPython.lo -MD -MP -MF .deps/_quickfix_la-QuickfixPython.Tpo -c QuickfixPython.cpp -fPIC -DPIC -o .libs/_quickfix_la-QuickfixPython.o
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
QuickfixPython.cpp:175:11: fatal error: 'Python.h' file not found
^~~~~~~~~~
1 warning and 1 error generated.
Reviewed by: portmgr, vishwin, yuri
Differential Revision: <https://reviews.freebsd.org/D40568>3d9a815d9cdevel/py-pyopencl: Update USES=python devel/py-pytools requires Python 3.8+5ac3b08e1f
*: Bump PORTREVISIONs for math/mpc update to 1.3.18d3e020ed0
*/*: rename CHEESESHOP to PYPI in MASTER_SITES PR: 267994 Differential revision: D37518 Approved by: bapt77d68471ad
Remove WWW entries moved into port Makefiles Commit b7f05445c00f has added WWW entries to port Makefiles based on WWW: lines in pkg-descr files. This commit removes the WWW: lines of moved-over URLs from these pkg-descr files. Approved by: portmgr (tcberner)fb16dfecae
Add WWW entries to port Makefiles It has been common practice to have one or more URLs at the end of the ports' pkg-descr files, one per line and prefixed with "WWW:". These URLs should point at a project website or other relevant resources. Access to these URLs required processing of the pkg-descr files, and they have often become stale over time. If more than one such URL was present in a pkg-descr file, only the first one was tarnsfered into the port INDEX, but for many ports only the last line did contain the port specific URL to further information. There have been several proposals to make a project URL available as a macro in the ports' Makefiles, over time. This commit implements such a proposal and moves one of the WWW: entries of each pkg-descr file into the respective port's Makefile. A heuristic attempts to identify the most relevant URL in case there is more than one WWW: entry in some pkg-descr file. URLs that are not moved into the Makefile are prefixed with "See also:" instead of "WWW:" in the pkg-descr files in order to preserve them. There are 1256 ports that had no WWW: entries in pkg-descr files. These ports will not be touched in this commit. The portlint port has been adjusted to expect a WWW entry in each port Makefile, and to flag any remaining "WWW:" lines in pkg-descr files as deprecated. Approved by: portmgr (tcberner)b7f05445c0
*/*: bump all consumers after recent boost upgrade4cf39decb3
One more small cleanup, forgotten yesterday. Reported by: lwhsucf118ccf87
Remove # $FreeBSD$ from Makefiles.305f148f48
Drop python 2.7 support from a few ports With hat: portmgraa7a6c429e
devel/boost-*: update to 1.72.0 Changes: http://www.boost.org/users/history/version_1_72_0.html PR: 241449 Exp-run by: antoine Differential Revision: https://reviews.freebsd.org/D22136701aa3bcf8
devel/boost-*: update to 1.71.0 Changes: http://www.boost.org/users/history/version_1_71_0.html PR: 238827 Exp-run by: antoine Differential Revision: https://reviews.freebsd.org/D20774befa71e0f3
Bump PORTREVISION for ports depending on the canonical version of GCC as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3 to GCC 9.1 under most circumstances now after revision 507371. This includes ports - with USE_GCC=yes or USE_GCC=any, - with USES=fortran, - using Mk/bsd.octave.mk which in turn features USES=fortran, and - with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang, c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib plus, everything INDEX-11 shows with a dependency on lang/gcc9 now. PR: 238330ea8c8ec7da
devel/py-pyopencl: fix build Add USES=compiler:c++11-lang to fix: RuntimeError: Unsupported compiler -- at least C++11 support is needed! Approved by: mentors (implicit approval)acd74474dc
devel/boost-*: update to 1.70.0 Changes: http://www.boost.org/users/history/version_1_70_0.html PR: 235956 Exp-run by: antoine Differential Revision: https://reviews.freebsd.org/D193039b21a3a084
Bump PORTREVISION for ports depending on the canonical version of GCC defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t GCC 8.2 under most circumstances. This includes ports - with USE_GCC=yes or USE_GCC=any, - with USES=fortran, - using Mk/bsd.octave.mk which in turn features USES=fortran, and - with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang, c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib plus, as a double check, everything INDEX-11 showed depending on lang/gcc7. PR: 231590a9f015d155
devel/boost-*: update to 1.69.0 Changes: http://www.boost.org/users/history/version_1_69_0.html PR: 232525 Exp-run by: antoine Differential Revision: https://reviews.freebsd.org/D176457c879267dc
Update WWW2ce7c29ace
Update to 2018.2 - Use PYNUMPY Changes: https://documen.tician.de/pyopencl/misc.html#user-visible-changes https://github.com/inducer/pyopencl/commits/master86acea78d8
devel/boost-*: update to 1.68.0 - Switch to C++14 for libboost_system to support C++14 consumers Changes: http://www.boost.org/users/history/version_1_68_0.html PR: 229569 Exp-run by: antoine Differential Revision: https://reviews.freebsd.org/D161650b055d47f2
Use PY_FLAVOR for dependencies. FLAVOR is the current port's flavor, it should not be used outside of this scope. Sponsored by: Absolight4376dbbb58
devel/boost-*: update to 1.67.0 Changes: http://www.boost.org/users/history/version_1_67_0.html PR: 227427 Exp-run by: antoine Differential Revision: https://reviews.freebsd.org/D15030cc95712fbe
Bump PORTREVISIONs of all users of math/mpc that we just updated to version 1.1.0 (via revision 464079).c2a92a1aea
Update to 2018.1.1 Changes: https://documen.tician.de/pyopencl/misc.html#user-visible-changes https://github.com/inducer/pyopencl/commits/masterca8d49fae9
devel/boost-python-libs got forgotten in the python flavorization, fix this oversight. Reviewed by: antoine Sponsored by: Absolight Differential Revision: https://reviews.freebsd.org/D14368f6e7f26602
Update to 2018.1 Changes: https://documen.tician.de/pyopencl/misc.html#user-visible-changes https://github.com/inducer/pyopencl/commits/master11fddb8a41
devel/boost-*: update to 1.66.0 Changes: http://www.boost.org/users/history/version_1_66_0.html PR: 223922 Exp-run by: antoine Differential Revision: https://reviews.freebsd.org/D1327925beeff079
Corrected shared library names that got the .abi3 suffix for python-36 and up after devel/py-cffi upgrade to 1.11.2
This is the followup for the r457997 commit that updated devel/py-cffi to 1.11.2.
As it turned out, the shared object names built by py-cffi has changed in python 36.
Dependent ports can choose between installing such shared object as part of their plist, or
generating them in the runtime and placing them into ~/.cache/{port-name}/ The former ones,
that include the shared objects in their plist, got affected.
4 of the ports were failing explicitly in their py36 flavor during the strip phase.
The other 6 were either missing strip entirely, or performed the strip operation without
using explicit shared object names. These 6 ports didn't trigger any build errors, and were
failing silently during the runtime, making the problem very hard to detect.
Precisely, .abi3 suffix is now added for the py36 flavor of relevant ports.
Here are the 10 ports that got affected and are now corrected:
databases/py-psycopg2cffi devel/py-pygit2 devel/py-xattr devel/py-pyopencl devel/py-atomiclong
multimedia/py-librtmp net/py-nnpy security/py-bcrypt security/py-cryptography security/py-pynacl
All of them got the * in the stripped shared object name, and a PORTREVISION bump.2c43c07183Update to 2017.2.2 Changes: https://documen.tician.de/pyopencl/misc.html#user-visible-changes https://github.com/inducer/pyopencl/commits/masterbd9b5273a3
Update to 2017.2.1 Changes: https://documen.tician.de/pyopencl/misc.html#user-visible-changes https://github.com/inducer/pyopencl/commits/mastere100138ae2
Convert Python ports to FLAVORS.
Ports using USE_PYTHON=distutils are now flavored. They will
automatically get flavors (py27, py34, py35, py36) depending on what
versions they support.
There is also a USE_PYTHON=flavors for ports that do not use distutils
but need FLAVORS to be set. A USE_PYTHON=noflavors can be set if
using distutils but flavors are not wanted.
A new USE_PYTHON=optsuffix that will add PYTHON_PKGNAMESUFFIX has been
added to cope with Python ports that did not have the Python
PKGNAMEPREFIX but are flavored.
USES=python now also exports a PY_FLAVOR variable that contains the
current python flavor. It can be used in dependency lines when the
port itself is not python flavored. For example, deskutils/calibre.
By default, all the flavors are generated. To only generate flavors
for the versions in PYTHON2_DEFAULT and PYTHON3_DEFAULT, define
BUILD_DEFAULT_PYTHON_FLAVORS in your make.conf.
In all the ports with Python dependencies, the *_DEPENDS entries MUST
end with the flavor so that the framework knows which to build/use.
This is done by appending '@${PY_FLAVOR}' after the origin (or
@${FLAVOR} if in a Python module with Python flavors, as the content
will be the same). For example:
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR}
PR: 223071
Reviewed by: portmgr, python
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D12464551be3c723devel/boost-*: update to 1.65.1 Changes: http://www.boost.org/users/history/version_1_65_1.html PR: 218835 Approved by: maintainer timeout (1.65.1: 2 weeks; 1.65.0: 1 month) Tested by: jhibbits (on powerpc64, earlier version) Exp-run by: antoine Differential Revision: https://reviews.freebsd.org/D1158298eb11b2f0
devel/boost-*: enable C++11 features PR: 218835 Obtained from: https://github.com/DragonFlyBSD/DeltaPorts/pull/690 Approved by: maintainer timeout (2 months) Exp-run by: antoine Differential Revision: https://reviews.freebsd.org/D115827e21a6476a
Update to 2017.2 Changes: https://documen.tician.de/pyopencl/misc.html#user-visible-changes https://github.com/pyopencl/pyopencl/commits/master97c0fdc0fe
Update to 2017.1.1 - Add LICENSE_FILE Changes: https://documen.tician.de/pyopencl/misc.html#user-visible-changes https://github.com/pyopencl/pyopencl/commits/master91b3838786
devel/boost-*: update to 1.64.0 Changes: http://www.boost.org/users/history/version_1_64_0.html PR: 218835 Approved by: office (bapt) Exp-run by: antoine Differential Revision: https://reviews.freebsd.org/D10472b324ade02d
devel/boost-*: update to 1.63.0 Changes: http://www.boost.org/users/history/version_1_63_0.html PR: 215598 Exp-run by: antoine Approved by: office (bapt) MFH: 2017Q159e02117ae
devel/boost-*: update to 1.62.0 - Enable `long double` C99 math usage - Switch 9.x back to building with GCC Changes: http://www.boost.org/users/history/ PR: 199601 Submitted by: Chen Xu, bapt, amdmi3, truckman (based on) Reviewed by: rakuco (kde) (earlier version) Exp-run by: antoine (3 tries), truckman (consumers only, earlier versions) Approved by: bapt (office)a8713d15f4
Remove ${PORTSDIR}/ from dependencies, categories d, e, f, and g.
With hat: portmgr
Sponsored by: Absolight4e1b79a0a6- Do not use bundled Boost.Python. - Do not unconditionally set "-O3" to CXXFLAGS.c844a53eab
Prefer package name references over file names. Requested by: koobsb3ca051270
PyOpenCL gives you easy, Pythonic access to the OpenCL parallel computation API. What makes PyOpenCL special? - Object cleanup tied to lifetime of objects. This idiom, often called RAII in C++, makes it much easier to write correct, leak- and crash-free code. - Completeness. PyOpenCL puts the full power of OpenCL's API at your disposal, if you wish. Every obscure get_info() query and all CL calls are accessible. - Automatic Error Checking. All errors are automatically translated into Python exceptions. - Speed. PyOpenCL's base layer is written in C++, so all the niceties above are virtually free. - Helpful Documentation. - Liberal license. PyOpenCL is open-source under the MIT license and free for commercial, academic, and private use. WWW: http://mathema.tician.de/software/pyopencl2a6520717d