commit 779a0b19708fa037f6c77f72b3b76705ecf3e222
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Nov 9 12:20:25 2026 +0100

dev-python/triton: gate the CUDA toolkit on USE=cuda, revbump

Every version pulled in dev-util/nvidia-cuda-toolkit and linked its
ptxas, cuobjdump, nvdisasm and headers into the NVIDIA backend, so an
AMD-only host got the whole toolkit for a backend it never uses.
Add a cuda flag, off by default as ::gentoo's cuda flags are, that
gates both the dependency and the links. NVIDIA hosts need USE=cuda
(or a global USE=cuda) to keep the links; without them the first
CUDA JIT fails to find ptxas. virtual/triton and its consumers are
unchanged.

Revbumps 3.7.1-r2, 3.8.0-r2 and 3.9.0-r1.

Bug: https://github.com/istitov/stuff/issues/307

commit cc7cbdc6feffced0efe60b8d68db01e99f28fae4
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Nov 5 23:32:32 2026 +0100

dev-python/triton: depend on nanobind, not pybind11, in 3.9.0

3.9.0 moved its Python bindings from pybind11 to nanobind:
pyproject.toml requires nanobind and the CMake build does
find_package(nanobind CONFIG REQUIRED); pybind11 is no longer used. The
ebuild still declared pybind11, so the build worked only where nanobind
happened to be installed. BDEPEND only, no revbump.

commit 9a19fb76a5bf54ab6338b5607f21c1e2665215a3
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Nov 5 10:45:15 2026 +0100

dev-python/triton: update the nlohmann comment in 3.9.0

The comment was copied from 3.8.0 and named that release. 3.9.0
still needs JSON_SYSPATH and pins the same v3.11.3, so it now says
"since 3.8.0" and is re-dated. Comment-only, no revbump.

commit 50e0ff45a826feb8458300ecd702b0a93e6cfbfe
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Nov 5 00:06:01 2026 +0100

dev-python/triton: add zlib to 3.8.0's RDEPEND, revbump

libtriton.so and FileCheck link libz.so.1 (scanelf on the installed
3.8.0), so zlib belongs in RDEPEND, as in 3.9.0.

commit e1d745eb854d9d5f3027d88136010ef8961016ac
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Nov 5 00:01:53 2026 +0100

dev-python/triton: add 3.9.0

PyTorch 2.15.0 pins Triton 3.9.0. The AMD backend now loads a separate
libtriton_amd_codegen.so linked against its own LLVM, pinned in
cmake/amd-llvm-info.json. The offline build would otherwise fetch it,
so upstream's published amd-codegen archive is added to SRC_URI, its
library is put where the backend loads it, and TRITON_AMD_CODEGEN_PATH
stops the helper's download.

libtriton.so, FileCheck and the codegen library all link libz, so
zlib joins RDEPEND.

commit e7abb64e5566b3202c77970def837319f495cbdc
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Nov 4 18:37:29 2026 +0100

dev-python/triton: add 3.8.0

PyTorch 2.14 pins triton 3.8.0. Its LLVM pin moved to cmake/llvm-info.json
(5f07f818, build 1); the prebuilt archive matches the SHA-256 recorded
there. In offline mode setup.py now requires JSON_SYSPATH, so the system
nlohmann_json headers stand in for the v3.11.3 download. The plugins
directory is no longer installed, so its removal goes.

commit 182210266c3ba20701248acdd60ea697af5ffd2b
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Oct 5 19:15:19 2026 +0200

dev-python/triton: link the toolkit's CUDA headers, revbump

The first CUDA kernel launch compiles backends/nvidia/driver.c with the
host C compiler, and driver.py gives it backends/nvidia/include as the
only CUDA include path, with no environment override. The binary wheel
fills that directory with a copy of the toolkit headers, but
TRITON_OFFLINE_BUILD=1 skips the download that provides them and the
source tarball carries none, so the directory was never created and
every launch died on "cuda.h: No such file or directory" before a
kernel reached ptxas.

Symlink the directory to the toolkit's headers, next to the tool
symlinks that cover the same gap for ptxas, cuobjdump and nvdisasm.
The toolkit is already a runtime dependency.

Revbumped because the installed tree gains the symlink.

commit c5f55df8de638e5e56fde1ac664ce0f716b0f668
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri Sep 11 23:50:33 2026 +0200

dev-python/triton: disable LTO in 3.7.1

The AMD and NVIDIA backend archives expose conflicting global
definitions when combined into libtriton. GCC diagnoses them during LTO,
and upstream's -Werror turns the diagnostics into a link failure.

Filter LTO until upstream makes the combined link ODR-clean. Upstream
tests remain restricted because they require accelerator hardware.

Bug: https://github.com/istitov/stuff/issues/286

commit 6498fd2dbc9f365ca48b994f85e9fcfdc7890eed
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 03:21:01 2026 +0200

dev-python/triton: trim 3.7.1 comment prose

commit f913e6eecd6f49f2e91b4cf61e0836c34daf7f05
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Sep 9 17:55:22 2026 +0200

dev-python/triton: symlink the CUDA tools the offline build omits

The CUDA backend had no ptxas, so the package compiled, installed and
imported cleanly and then died at the first CUDA JIT with "Cannot find
ptxas".

TRITON_OFFLINE_BUILD=1 suppresses upstream's download of the NVIDIA tools
and the source tarball carries none, so nothing ever placed them in
backends/nvidia/bin. knobs.py resolves them through env_nvidia_tool, which
tries $TRITON_<TOOL>_PATH and then that directory and raises RuntimeError;
there is no PATH fallback, so the toolkit already being on PATH through
env.d does not help.

Symlink ptxas, cuobjdump and nvdisasm to the toolkit and depend on it.
ptxas-blackwell has no toolkit counterpart, so sm_100 and later still need
TRITON_PTXAS_BLACKWELL_PATH set by hand.

The binary wheel bundles the NVIDIA tools itself, so only this provider was
affected -- which is why the gap survived: nothing had ever selected it.
Found by build-checking through install and reading the staged image rather
than the sources.

commit 00a30854274bd1059070667f705f77b5f84caeb2
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Sep 9 17:16:47 2026 +0200

dev-python/triton: declare the bundled LLVM and HSA licences

LICENSE="MIT" covered only the Triton half of what this package ships.

The ebuild fetches upstream's prebuilt LLVM alongside the Triton sources,
and that code reaches the installed tree in two forms: statically linked
into triton/_C/libtriton.so, which is 162 MiB, resolves no external libLLVM
through ldd and exports llvm symbols of its own, and copied verbatim as
triton/FileCheck. The AMD backend additionally installs six HSA headers
under triton/backends/amd/include/hsa carrying the University of
Illinois/NCSA licence, and python_install does not remove them.

Every term is cumulative rather than an any-of choice. Read off the staged
image rather than inferred from SRC_URI.

commit f0329e072a3280b7a9a50a91a4fc3693d1fd3efb
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Aug 23 12:42:34 2026 +0200

dev-python/triton: block triton-bin

commit 5f9a8189f547c108baf0c909d5b53b926160adc2
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Aug 23 11:00:41 2026 +0200

dev-python/triton: new package

GPU-kernel compiler built from source against upstream's pinned LLVM
(commit 1f126a6d, prestaged via a SRC_URI blob with TRITON_OFFLINE_BUILD=1).
Several LLVM translation units need multiple GiB each, so MAX_JOBS is
capped at 4 to avoid OOM.