commit 6650951c388e97f18d996015b08ab9900f1653e3
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 03:12:43 2026 +0200

dev-python/tilelang: trim 0.1.9 comment prose

commit b709aa1e2399fb563afd168b2ee6d8bd3096d7fe
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 03:12:43 2026 +0200

dev-python/tilelang: trim 0.1.10 comment prose

commit 91426a709e5a9c6e20449b4591134d30c6cf7fdd
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 03:11:42 2026 +0200

dev-python/tilelang: trim 0.1.12 comment prose

commit 0b101049e4fef0eebb6d0bd2f2e60d636c365ed5
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 03:10:58 2026 +0200

dev-python/tilelang: trim 0.1.13-r2 comment prose

commit 43ea5f3db8859caba37cea4d77494301fe89c18a
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 03:10:31 2026 +0200

dev-python/tilelang: trim 0.1.14 comment prose

commit 306fca023d3634d4644e74cd84fb230aceaee297
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Sep 2 09:35:11 2026 +0200

dev-python/tilelang: add 0.1.14

Deps unchanged -- requires_dist is identical to 0.1.13. The work here is
the patch stack.

Dropped the py-limited-api patch: it is obsolete at 0.1.14. Its whole
purpose was that dev-python/cython-3.3 refuses to generate limited-API
code below 3.9, and upstream has now raised wheel.py-api from "cp38" to
"cp39", which satisfies exactly that constraint. Our patch went further
to cp310 to match upstream's own requires-python = ">=3.10", but that
was tidiness layered on the build fix; cp39 is a more conservative
stable-ABI target and is fine for PYTHON_COMPAT 3_12..14.

Verified rather than reasoned: built against the installed cython-3.3.0
with the patch removed, and the backend produced
tilelang-0.1.14-cp39-abi3-linux_x86_64.whl with
tilelang_cython_wrapper.abi3.so compiled -- so the limited-API level
really is cp39 and Cython accepted it.

The cudahostcxx patch is still required -- 0.1.14's
tilelang/contrib/cc.py still reads only CXX and CC in
get_cplus_compiler() -- and applies cleanly, so it is carried forward
under the new version-named filename.

Add-only: 0.1.9, 0.1.10 and 0.1.12 are each the sole match for an exact
~ pin in a retained dev-python/vllm ebuild, so none of them is
droppable despite the last-two rule.

commit 21d824cacf00631755408bb1f3d5cfe84d6f61fa
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 31 12:43:56 2026 +0200

dev-python/tilelang: restore 0.1.9, 0.1.10, 0.1.12 with the cython-3.3 fix

Dropping these in 2f6309494 left every dev-python/vllm ebuild in the tree
unsolvable. That commit stated "Nothing outside the package pins a tilelang
version", which was wrong: all three vllm versions exact-pin these, in BOTH
their cuda and rocm branches --

vllm-0.26.0 ~tilelang-0.1.9 (cuda) ~tilelang-0.1.10 (rocm)
vllm-0.27.1 ~tilelang-0.1.12 (cuda) ~tilelang-0.1.10 (rocm)
vllm-0.28.0 ~tilelang-0.1.12 (cuda) ~tilelang-0.1.10 (rocm)

so with only 0.1.13 in the tree none of them could ever be installed. This is
the second time these exact versions have been dropped and restored
(83f5e064f, then b9958b40f).

The technical objection in that commit was real, though, so this is not a plain
revert: all three hardcode wheel.py-api = "cp38" in pyproject.toml, which feeds
SKBUILD_SABI_VERSION and hence -DPy_LIMITED_API, and >=dev-python/cython-3.3
refuses to generate limited-API code below 3.9. Restored as-is they would
resolve and then fail to compile, which is worse than the problem being fixed.
So each carries the same one-line backport 0.1.13 already ships -- cp38 ->
cp310, upstream's own requires-python = ">=3.10" making cp38 an inconsistency
rather than a floor. 0.1.12's cudahostcxx patch is restored alongside it.

Verified rather than assumed:
- all three build clean with USE=rocm on cython-3.3.0, each producing
tilelang_cython_wrapper.abi3.so, so the stable ABI is still in use at 3.10
- pkgcheck NonexistentDeps on dev-python/vllm goes 3 -> 0
- vllm 0.27.1 and 0.28.0 now resolve

vllm-0.26.0 still does not resolve, for an unrelated and pre-existing reason:
it wants ~sci-ml/pytorch-2.11.0 while 2.13.0 is installed, and the two cannot
coexist. That is a torch-generation conflict, not a tilelang one.

Note for future drops: bin/retention-audit.py answers exactly the question that
was got wrong here, and answers it correctly -- with these versions present it
does not list tilelang as droppable, because it checks every atom in the tree
rather than looking for pins by hand. Also note pkgcheck under-reports this
class: it flagged only the three cuda-branch pins and stayed silent about the
identical rocm-branch pins on ~tilelang-0.1.10.

commit 70a2ff8a5ed98e2ea4a4e03844b9e64a22786093
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Aug 30 18:45:13 2026 +0200

dev-python/tilelang: revbump 0.1.13-r1 -> -r2

0.1.13-r1 is already published, and this branch adds
tilelang-0.1.13-py-limited-api-310.patch to it. That patch rewrites
pyproject.toml's wheel.py-api from cp38 to cp310, which feeds
SKBUILD_SABI_VERSION -> USE_SABI -> -DPy_LIMITED_API, i.e. it changes the
ABI tag of the installed extension. Without a revision bump portage sees no
version change and never rebuilds, so an existing install keeps the cp38
limited-API build the patch exists to replace.

Renamed rather than kept alongside: -r1 cannot build against the
dev-python/cython-3.3 in the tree at all ("Cython 3.3 requires the Python
Limited API version to be 3.9 or greater"), and an ebuild that cannot build
is not a rollback target. Same reasoning that dropped 0.1.9/0.1.10/0.1.12.

Both PATCHES entries interpolate $, not $, so the patch filenames
are unaffected by the revision.

commit 2f6309494461e4e4b630402318502613045c301e
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Aug 30 17:58:48 2026 +0200

dev-python/tilelang: drop 0.1.9, 0.1.10, 0.1.12

All three hardcode wheel.py-api = "cp38" and so cannot be built against
>=dev-python/cython-3.3, which refuses to generate limited-API code below 3.9.
They are not viable rollback targets -- an ebuild that cannot build offers
nothing to roll back to -- so the usual "keep the last two" retention does not
apply here. 0.1.13-r1 carries the fix and is the installed version.

Also drops tilelang-0.1.12-cudahostcxx.patch, which only 0.1.12 referenced;
0.1.9 and 0.1.10 used no patches. Nothing outside the package pins a tilelang
version.

Backporting the one-line py-api fix to them was the alternative, but they are
superseded, unbuildable as shipped, and 0.1.13 is a straight upgrade.

commit 128d02efcf37e48cb7520c9b1db1bcf1720c0a44
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Aug 30 17:55:09 2026 +0200

dev-python/tilelang: target the 3.10 limited API so it builds with cython 3.3

dev-python/cython-3.3 refuses to generate limited-API code below 3.9, so the
generated wrapper failed to compile and the package could not be built at all:

build/tilelang_cython_wrapper.cpp:70:8: error:
#error "Cython 3.3 requires the Python Limited API version to be 3.9 or greater."

pyproject.toml asks for wheel.py-api = "cp38", which feeds SKBUILD_SABI_VERSION,
which CMakeLists.txt passes to python_add_library() as USE_SABI -- that is what
becomes -DPy_LIMITED_API=0x03080000.

cp38 is upstream inconsistency rather than a real constraint: the same
pyproject.toml declares requires-python = ">=3.10", so the package cannot run on
3.8 or 3.9 regardless, and this ebuild builds only for
PYTHON_COMPAT=( python3_ ). cp310 matches the declared floor.

Verified: builds, installs tilelang_cython_wrapper.abi3.so (so the stable ABI is
still in use, just at 3.10), imports, and sees gfx1150.

Older versions in the tree carry the same cp38 line and remain unbuildable
against cython 3.3; they are drop candidates under the retention policy rather
than worth backporting to.

commit f6bc6f74effa29a708b6d2db20041c9ae4227b3a
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri Aug 14 20:19:16 2026 +0200

dev-python/tilelang: honor CUDAHOSTCXX during JIT

TileLang passes an explicit host compiler to nvcc, so NVCC_PREPEND_FLAGS cannot
override an unsupported system compiler. Prefer CUDAHOSTCXX in the runtime compiler
helper and document that effective control.

commit 71061964d300f5db66a5e75dce8bc427434de22d
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri Aug 14 10:24:04 2026 +0200

dev-python/tilelang: enforce build dependency floors

The 0.1.13 source requires CMake 3.26.1 through its scikit-build configuration and Z3
4.13.0 through its project metadata. Express both floors so older versions cannot
satisfy the build dependencies.

commit dc01f2f074c02c7d0f24dae16d1238b96198a02a
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri Aug 14 09:06:19 2026 +0200

dev-python/tilelang: honor CUDAHOSTCXX for runtime JIT

TileLang unconditionally adds an nvcc compiler-bindir flag derived from CXX or PATH,
overriding NVCC_PREPEND_FLAGS and selecting compilers rejected by CUDA 13. Prefer
CUDAHOSTCXX explicitly and retain a compatible GNU C++ compiler for runtime kernel
generation.

commit 99dd7c7c99e8f35ba76db237290776b08f71f3be
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Aug 13 19:18:59 2026 +0200

dev-python/tilelang: drop 0.1.11

The retained later 0.1 releases provide rollback coverage without carrying this
superseded version.

commit f430fa51c1c55e751dd408a0bbab82ff8583aaff
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Aug 12 01:52:33 2026 +0200

dev-python/tilelang: add 0.1.12 for vllm 0.27.1 cuda

commit 84463cae405576121dbfc32036212999f451b1a9
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Aug 5 10:55:00 2026 +0200

dev-python/tilelang: date the z3-solver cap rationale

Stamp the tested-version cap note; the in-tree z3 (4.16.0/5.0.0) is newer than
upstream's <4.15.5 ceiling.

commit abc016550c4f45d53bb54d7e3a12d256ed71a7b0
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 3 18:05:08 2026 +0200

dev-python/tilelang: fix backend and FFI integration in 0.1.13

Model CUDA and ROCm as exclusive backends, select supported toolchains, and
repair installed library paths. Pin the exact apache-tvm-ffi release the
ABI-symlink build links against, and leave compiler caching to Portage.

commit fa89282afb1c9d66aeec897fb2293dbf67fafd6a
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 3 18:05:00 2026 +0200

dev-python/tilelang: fix backend and FFI integration in 0.1.11

Model CUDA and ROCm as exclusive backends, select supported toolchains, and
repair installed library paths. Follow upstream's compatible FFI range and
leave compiler caching to Portage.

commit b5bdc1beb8b0e91d22b6640ac07cc368fab2323a
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 3 18:04:51 2026 +0200

dev-python/tilelang: fix backend and FFI integration in 0.1.10

Model CUDA and ROCm as exclusive backends, select supported toolchains, and
repair installed library paths. Retain the bundled 0.1.11 header snapshot,
follow upstream's compatible FFI range, and leave caching to Portage.

commit a050ecabea99aca40e7cfb3dc55410e8475950af
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 3 18:04:43 2026 +0200

dev-python/tilelang: fix backend and FFI integration in 0.1.9

Model CUDA and ROCm as exclusive backends, select supported toolchains, and
repair installed library paths. Keep the bundled FFI headers, follow upstream's
compatible FFI range, and leave compiler caching to Portage.

commit b9958b40ff462a8fa723391c914a05abc2d78623
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 3 14:51:21 2026 +0200

dev-python/tilelang: restore 0.1.9 and 0.1.10

Retained vLLM releases still require these exact backend versions for CUDA and ROCm.
Restore the previously verified ebuilds so their dependency branches remain solvable.

commit 83f5e064f233f60d87053765ab5eeb272f989aae
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 3 09:46:33 2026 +0200

dev-python/tilelang: drop 0.1.9, 0.1.10, 0.1.12

0.1.12 caps <dev-python/apache-tvm-ffi-0.1.12, but the tree no longer
carries a tvm-ffi below 0.1.12, so that bound no longer solves. 0.1.9
and 0.1.10 were already past the last-two retention window. Keep 0.1.11
(open tvm-ffi dep) alongside the new 0.1.13 for rollback.

commit 9fb7715fb55030f93406859c3104cd749cc6b89f
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 3 09:46:02 2026 +0200

dev-python/tilelang: add 0.1.13

commit ba297f2bb98e5b1020078236fa0a2508549c8998
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri Jul 10 14:22:22 2026 +0200

dev-python/tilelang: add 0.1.12

commit 255d2b80fa6d8a5dd918c486b5d25b8c60e9d2a6
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Tue Jun 9 01:08:43 2026 +0200

dev-python/tilelang: restore 0.1.9

dev-python/vllm (0.21.0, 0.22.1) pins ~dev-python/tilelang-0.1.9; dropping
0.1.9 left that dependency unsatisfiable. Keep it while vllm requires the
exact version.

commit 8b03f9b1092c6157223d84122867366a503b896b
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Jun 8 12:58:45 2026 +0200

dev-python/tilelang: drop 0.1.9

commit 2d960f92899c50884f3e7ac2abdefd6968e14065
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Jun 8 12:58:31 2026 +0200

dev-python/tilelang: add 0.1.11

libtvm_runtime.so/libtilelang.so call CUDA driver symbols but Gentoo's
--as-needed strips the libcuda stub from DT_NEEDED despite
TILELANG_USE_CUDA_STUBS=OFF; with -z now this fails 'import tilelang' at
dlopen. python_install_all re-adds libcuda.so.1 via patchelf. pkg_postinst
documents the runtime-JIT NVCC_PREPEND_FLAGS=-ccbin gcc-15 requirement on
CUDA 13.x. Verified import + sm_86 GPU kernel.

commit 00e82f29e8e5359d45fd0c4498e2f881668e06ce
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon May 25 14:00:21 2026 +0200

dev-python/tilelang: add 0.1.10

Patch bump from 0.1.9. Upstream tightened apache-tvm-ffi pin from
~=0.1.0,>=0.1.2 to ~=0.1.0,>=0.1.10; mirror that with a >=0.1.10
floor on the python_gen_cond_dep entry (we already ship 0.1.11 in
the overlay so resolution stays clean). Other pyproject.toml deps
unchanged. Build-verified with python3_13 single-impl + the
existing CMAKE_CUDA_HOST_COMPILER / TILELANG_USE_CUDA_STUBS workarounds;
all four dated rationale comments re-verified against 0.1.10.

commit 51472bd93965ef04435f1165226d7a499e1bc72f
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed May 13 14:42:59 2026 +0200

dev-python/tilelang: drop stale python3_11 conditional

python_single_target_python3_11 was removed from PYTHON_COMPAT in the
python3_11 sweep but the torch-c-dlpack-ext conditional block was not
cleaned up, causing an UnstatedIuse pkgcheck error.

commit 5458d487801025adc249579494ecf1bb7eb68c52
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed May 13 14:35:35 2026 +0200

dev-python/tilelang: disable py3.11

commit 738368c3910b766e9fd40e870d6d78a5ceba313f
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun May 10 16:13:17 2026 +0200

dev-python/tilelang: fix z3 dep — use $

sci-mathematics/z3 is python-single-r1 (single-impl). The earlier
DISTUTILS_SINGLE_IMPL conversion left z3 inside python_gen_cond_dep
with [python,$], which silently auto-satisfies via
[X(-)?] when z3 doesn't have python_targets_* in IUSE. Move it out of
the multi-impl wrap and use [python,$] so the
Python-target match between tilelang and z3 is actually enforced.

commit 6ad25de09e790db9d83139a3d5611d32b6c04769
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun May 10 15:28:12 2026 +0200

dev-python/tilelang: switch to DISTUTILS_SINGLE_IMPL

sci-ml/pytorch is SINGLE_IMPL, and the existing python_targets_python3_*?
guards on the now-single-impl dev-python/torch-c-dlpack-ext need to flip
to python_single_target_python3_*?. Multi-impl helpers (apache-tvm-ffi,
cloudpickle, ml-dtypes, etc.) move into python_gen_cond_dep.

commit 655ba501a783d05d1463c4978bc50efbe0a409e3
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu May 7 18:25:53 2026 +0200

dev-python/tilelang: new package, 0.1.9

Tier 4 of the vllm CUDA target packaging cycle. Tile-level programming
language for high-performance ML kernels — used by flashinfer-python's
fused-attention paths and (via apache-tvm-ffi) by quack-kernels.

Build is scikit-build-core + a vendored full TVM source tree (407 MiB
under 3rdparty/tvm), plus vendored CUTLASS C++ and Composable-Kernel
headers. ~677 ninja steps; on this 24-thread / 31 GiB host the full
build runs ~10 min once unblocked.

Three ebuild-side fixes were needed to land:

* z3 lookup. Upstream's bundled cmake/pypi-z3/FindZ3.cmake searches
ONLY inside the PyPI z3-solver wheel's site-packages layout
(NO_DEFAULT_PATH). On Gentoo the headers + libz3 live at standard
/usr/include + /usr/lib64 paths. Pre-setting Z3_INCLUDE_DIR and
Z3_LIBRARY via DISTUTILS_ARGS short-circuits find_path /
find_library and lets the imported z3::libz3 target build cleanly
against ::gentoo's z3.

* nvcc host compiler. CUDA 13.2's crt/host_config.h hard-#errors when
__GNUC__ > 15, but this host's active gcc is 16. Pinning nvcc's
host compiler to /usr/bin/x86_64-pc-linux-gnu-g++-15 (slot 2 from
gcc-config) via -DCMAKE_CUDA_HOST_COMPILER and CUDAHOSTCXX keeps
the system slot at 16 while the CUDA toolchain stays in band.
Likely affects every other CUDA-source consumer in this stack.

* CUDA stub linkage. TILELANG_USE_CUDA_STUBS defaults ON and links
libtvm.so against tilelang's own libcudart_stub / libnvrtc_stub
for "portable wheel" lazy resolution. But there is no driver-API
stub, so direct calls to cuDeviceGetName etc. become undefined-
symbol at import. Turning the option OFF makes the build NEEDED-
link libtvm.so directly against /opt/cuda's stubs/libcuda.so /
libcudart.so / libnvrtc.so — the SONAMEs resolve to the real
driver+runtime libs at runtime via /etc/ld.so.cache. We don't
ship portable wheels, so the loss-of-portability is moot.

Z3-solver pin (<4.15.5) is intentionally NOT honored — ::gentoo only
carries z3-4.16.0; the cap reads as conservative ("tested up to here")
and tilelang imports + initializes cleanly against 4.16. Will revisit
if a runtime test surfaces a real incompatibility.

Accepting the NonsolvableDepsInStable false positive from
sci-mathematics/z3 / sci-ml/pytorch keyword stacks (same shape as
xgrammar etc.).