commit 2fb9835305c2a88aa6166fd95dd5265ba25631aa
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri Sep 11 10:46:10 2026 +0200

sci-ml/pytorch: trim 2.14.0-r91 comments

commit 6c34e5702e32ff242971229a3a5c0c1b1c3b2250
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri Sep 11 10:46:10 2026 +0200

sci-ml/pytorch: trim 2.13.0-r93 comments

commit 4426d32a16c9002481819bdc98b5e9bda2fc37e9
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri Sep 11 10:46:10 2026 +0200

sci-ml/pytorch: trim 2.11.0-r92 comments

commit 53cc1e16bce2fd56fb6d8ee3499656684a7b451f
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 13:35:29 2026 +0200

sci-ml/pytorch: forward caffe2's USE flags to 2.13.0/2.11.0, revbump

2.14.0-r91 declared caffe2's IUSE and forwarded each flag to caffe2, so
consumers written against ::gentoo's monolithic pytorch resolve against
this split. The 2.13.0 and 2.11.0 forks still had no USE flags. For
2.13 that is a latent copy of the same failure: ::gentoo's
torchvision-0.28.0 needs =sci-ml/pytorch-2.13*[numpy,cuda?,rocm?],
which only ::gentoo's own pytorch-2.13.0-r3 could satisfy, and portage
has not taken that path only because this overlay's torchvision-0.28.0,
at the same version, wins on repository priority. 2.11 has no
flag-using consumer and ::gentoo carries no 2.11; the flags keep it in
step with the other two forks.

Both get the same block as 2.14.0-r91: caffe2's IUSE, one
USE-conditional caffe2 dependency per flag, caffe2's REQUIRED_USE minus
its amdgpu_targets rule, and numpy at runtime under numpy. caffe2's
IUSE and REQUIRED_USE are identical across 2.11.0, 2.13.0 and 2.14.0.

No build step reads the flags. The revbumps are there so installed
copies pick up the new dependencies, since portage does not re-resolve
an installed package's dependencies without --changed-deps.

commit f8a9a7618709d494054eb9997b3c0d9303cc366d
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 13:05:57 2026 +0200

sci-ml/pytorch: forward caffe2's USE flags, revbump

This split pytorch had no USE flags, while ::gentoo's monolithic pytorch
carries caffe2's full IUSE and its consumers depend on those flags.
::gentoo's torchvision-0.29.0-r1 needs
=sci-ml/pytorch-2.14*[numpy,cuda?,rocm?]. Nothing here could satisfy
that, so portage chose ::gentoo's pytorch-2.14.0-r2 instead, which
blocks sci-ml/caffe2 and, with rocm, pins the ROCm libraries below 7.3.
A world update then failed on slot conflicts across the ROCm stack.

The same IUSE is now declared here, and each flag requires caffe2 built
with it, so pytorch[rocm] guarantees caffe2[rocm] without forcing the
two USE sets to match. REQUIRED_USE follows caffe2's, minus its
amdgpu_targets rule, and numpy also adds numpy at runtime, as ::gentoo's
pytorch does. The forwarding is one USE-conditional block per flag:
written as flag? use-dependencies on a single caffe2 atom, it is more
than pkgcheck can expand, and pkgcheck then stops checking this
package's dependencies.

No build step reads the flags. The revbump is there so an installed
-r90 picks up the new dependencies, since portage does not re-resolve
an installed package's dependencies without --changed-deps.

commit 4faef9b4aebcf06b9090d64ec410a660680fef20
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 3 02:47:29 2026 +0200

sci-ml/pytorch: add 2.14.0-r90

Unblocks sci-ml/caffe2-2.14.0-r90, which nothing could consume without
this: 44 packages in the tree depend on sci-ml/pytorch and pytorch pins
~sci-ml/caffe2-$ exactly, so a caffe2 bump alone reaches none of
them.

2.14.0 moved the build from setuptools to scikit-build-core. setup.py is
now a deprecation shim and tools/setup_helpers/env.py is gone, which
removes both halves of this overlay's caffe2/pytorch split: the
dontbuildagain patch deleted setup.py's build_pytorch() call, and the
BUILD_DIR sed pointed env.py at the CMakeCache.txt caffe2 drops in
/var/lib/caffe2 so setup.py believed the build already existed.

The split is kept rather than retired, via scikit-build-core's own
wheel.cmake knob. Set false, it skips the CMake configure/build/install
entirely (build/wheel.py gates on it, and build/__init__.py then drops
cmake+ninja from the build requires) and packages just the python trees
upstream names in [tool.scikit-build.wheel] packages -- torch, torchgen
and functorch. That is precisely this package's half. wheel.platlib is
forced true alongside it because scikit-build-core switches to purelib
when cmake is off, and this must land in the platlib caffe2 installs
torch/_C into.

Verified on the built image rather than assumed: zero cmake/ninja
invocations in the log, no .so or libtorch* anywhere in the image, a
223.0 MiB tree against caffe2's 914.8 MiB, functorch/torch/torchgen plus
torch-2.14.0.dist-info installed, and no torch/version.py or
torch/_C.cpython* -- both of which caffe2 owns and neither of which
exists in the source tree, so there is nothing to collide over.

Two ebuild-side fixes this needed:

- project.license-files globs third_party/**/LICENSE{,.txt,.rst}, and
PEP 639 requires every pattern to match at least one file. The GitHub
archive ships no submodule contents, so all three are empty and
pyproject_metadata hard-errors before the build starts. They are
dropped; we unbundle third_party against system libraries, so none of
those licences cover anything installed here. The top-level LICENSE,
which does, is kept and guarded.
- The %LIB_DIR% substitution runs after distutils-r1_src_prepare for the
same reason as 2.13.0-r92, with the same grep guard; verified lib64 in
the image. cpp-extension-multilib is rebased for 2.14.0, where the
2.10.0 patch applied only with fuzz 2.

dontbuildagain is dropped -- setup.py no longer builds anything, so
there is nothing left for it to delete. The prefix inherit goes with
hprefixify, which went with env.py.

NOT verified: runtime `import torch` against caffe2-2.14.0. Doing that
means displacing the working 2.13 stack on this host, and the 2.13 forge
is on record that consumption found two bugs a build-check could not.

Merging the stack is a coordinated three-package upgrade -- `emerge
sci-ml/caffe2 sci-ml/pytorch sci-ml/torchvision` resolves, while
upgrading any one alone conflicts on the exact pins (installed
torchvision pins =sci-ml/pytorch-2.13*, installed pytorch pins
~sci-ml/caffe2-2.13.0). That is the same shape the 2.12 -> 2.13
migration had and is normal for an exact-pinned stack.

commit fa4c79a3696bb4625ff5e080cac521ba48fcc561
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Sep 2 23:49:36 2026 +0200

sci-ml/pytorch: substitute %LIB_DIR% after patching, not before

files/pytorch-2.10.0-cpp-extension-multilib.patch introduces a %LIB_DIR%
placeholder into torch/utils/cpp_extension.py, and src_prepare replaced
it with $(get_libdir) -- but did so BEFORE distutils-r1_src_prepare, and
distutils-r1_src_prepare is what applies PATCHES. The placeholder did
not exist yet, so the sed matched nothing, exited 0 and the literal
shipped.

The merged sci-ml/pytorch-2.13.0-r91 on this host had:

1779: lib_dir = '%LIB_DIR%'
1782: paths.append(os.path.join(HIP_HOME, '%LIB_DIR%'))

so library_paths() handed ROCm C++ extension builds /usr/%LIB_DIR% and
$HIP_HOME/%LIB_DIR% instead of the real libdir. Only the ROCm branch is
affected; the CUDA and CPU branches compute lib_dir in Python and never
used the placeholder, which is why nothing else noticed.

Both affected versions are fixed together: 2.13.0-r92 and 2.11.0-r91.
2.11.0 is the frozen torch-2.11 rollback ebuild -- exactly the stack a
user falls back to when something newer breaks, so the last place to
leave a silent packaging defect.

Move the sed after distutils-r1_src_prepare in both and add a grep guard
so the same silent no-op cannot recur. Rebuilt images carry lib64 at
both sites. Revbumped because the fix changes installed content.
verified 2026-09-03

commit 87c79c6ee084f37380169d79eb7952e63837ea17
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri Aug 14 21:11:03 2026 +0200

sci-ml/pytorch: update documentation URL

PyTorch permanently redirects the old documentation hostname. Use the canonical docs
endpoint directly.

commit aac10b8915b6fce56c7c9f5becc8654cea5a6ebb
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri Aug 14 09:42:11 2026 +0200

sci-ml/pytorch: normalize copyright header

Use the overlay-wide required copyright range consistently across consumer-retained
versions.

commit 6932a03e3f2f57ff08f00a0f6b4110bded397373
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Aug 8 12:01:30 2026 +0200

sci-ml/pytorch: add 2.11.0-r90

Restores the thin torch-2.11 frontend that vllm (0.24/0.25/0.26) pins via
~sci-ml/pytorch-2.11.0. ::gentoo dropped torch 2.11 and our fork jumped
straight to 2.13.0, leaving vllm unresolvable. Adapted from 2.13.0-r91
(same caffe2/pytorch split: dontbuildagain reuse of the caffe2 build)
against the existing sci-ml/caffe2-2.11.0-r90 backend. One deviation from
torch 2.11.0's Requires-Dist: its setuptools<82 cap is unsatisfiable on a
current system (it forces setuptools-79, colliding with consumers that
need >=80 like dev-python/ipython, and nothing exists in [80,82)), so
relax to the same >=77.0.3 floor our 2.13.0-r91 frontend already uses.
Both frontend patches apply to 2.11.0.

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

*/*: normalize metadata.xml whitespace

Use the overlay-wide two-space XML indentation convention and remove the remaining trailing whitespace so metadata stays consistent and diff-safe.

commit 71285ad8b369f6bdd6b64718b23b4574dda4273d
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Jul 27 08:54:04 2026 +0200

sci-ml/pytorch: declare torch's unconditional runtime deps, revbump

RDEPEND listed sympy and typing-extensions, both without floors, and
nothing else. torch declares seven unconditional Requires-Dist. The
five that were missing entirely are filelock, fsspec, jinja2, networkx
and setuptools; sympy and typing-extensions were present but unbounded
where upstream floors them at 1.13.3 and 4.10.0.

Only typing-extensions is pulled in by `import torch`, which is why the
gap went unnoticed: the rest are reached lazily. sympy and networkx
come in through torch.fx, jinja2 and filelock through the inductor
codegen and its compile cache, fsspec through torch.load and save on
remote paths, setuptools through torch.utils.cpp_extension. Upstream
marks none of them as an extra -- the ones that are optional are listed
separately under extra == "optree", "opt-einsum" and "pyyaml", and
those are correctly absent here. Anyone reaching torch.compile without
them installed gets an ImportError rather than a dependency error.

caffe2 does not cover them either; its RDEPEND is C++ and system
libraries plus a USE-gated numpy.

The block is written to mirror Requires-Dist verbatim, floors included,
so it can be diffed against the built torch-2.13.0.dist-info/METADATA
instead of re-derived.

Revbump because the package is installable at -r90 and portage does not
re-resolve dependencies for an installed package without --changed-deps;
without a new revision an existing install would keep the old set. -r91
stays inside the band this fork uses, below the -r99 that marks a
straight fork of the gentoo ebuild.

gentoo's own sci-ml/pytorch-2.12.0 carries the same incomplete RDEPEND,
so this is worth reporting upstream rather than only fixing here.

commit 4cb9a73ef8fe789add28e419383e788e8e5db826
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Jul 18 16:40:59 2026 +0200

sci-ml/pytorch: add 2.13.0-r90

Python-bindings metapackage for sci-ml/caffe2-2.13.0 (RDEPEND ~caffe2-$).
Fork of ::gentoo's pytorch-2.12.0, which pairs with caffe2 at 2.12.0; carries
its two patches (dontbuildagain, cpp-extension-multilib) and the build-dir /
libdir seds unchanged.