commit 65900eef9a4cebb6d6c675361c89c0b36da891e9
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Oct 4 15:08:47 2026 +0200

dev-python/hf-transfer: update vendored crates for RustSec, revbump

Upstream's 0.1.9 lockfile pins crates with RustSec advisories that have
semver-compatible fixes. Carry the lockfile change as a patch and list
the newer crates:

bytes 1.9.0 -> 1.12.1 (RUSTSEC-2026-0007)
h2 0.4.7 -> 0.4.19 (RUSTSEC-2026-0258)
openssl 0.10.68 -> 0.10.81 (RUSTSEC-2025-0004, RUSTSEC-2025-0022)

The patch header also lists 1 crate that moves with these to satisfy the
newer requirements.

openssl-sys 0.9.117 declares a newer rust-version, so RUST_MIN_VER moves
from 1.74.0 to 1.80.0.

ring, rustls and rustls-webpki also have advisories but stay as upstream
pinned them, since the shipped build does not compile them.

The remaining advisories need breaking upgrades upstream and are left
for a version bump: pyo3 0.23.3 (RUSTSEC-2025-0020, RUSTSEC-2026-0177).

commit 63ea7e7a643c62c53eabe88d2af4ae559ac78948
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri Oct 2 20:55:55 2026 +0200

dev-python/hf-transfer: add dependent crate licenses

The extension statically links its vendored crates, but LICENSE named
only the project's own license. The block is pycargoebuild's output
for CRATES, under the marker its in-place mode looks for.

ring 0.17.8 states its terms in a LICENSE file, which pycargoebuild
skips, so its ISC, OpenSSL, SSLeay and MIT terms get a separate line,
as ::gentoo does for the same crate.

commit 220f227937eb6185180f1943183b70660c257613
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 08:26:51 2026 +0200

dev-python/hf-transfer: remove vague crate-license comment

commit c1e02c320c4ac558a936f20f06054a7041966e48
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Sep 5 10:34:19 2026 +0200

dev-python/hf-transfer: Keyword 0.1.9 for ~arm64

The PyO3 extension and its Rust dependency graph support aarch64.

commit d26e488d095396a8343a1053601f18f59982a8df
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Jul 27 10:04:12 2026 +0200

*/*: drop dead Python targets from PYTHON_COMPAT

139 ebuilds across 65 packages still listed python3_10, python3_11 or
python3_13t. None of the three is a supported implementation any more:
gentoo's python-utils-r1 sets _PYTHON_ALL_IMPLS to python3_ plus
python3_t, and everything older falls into the branch commented
"implementations deprecated prior to EAPI 9 are fatal".

Inert today, which is why nothing caught it. Targets outside
_PYTHON_ALL_IMPLS are silently dropped rather than rejected, so they
never became USE flags and never produced a dependency atom -- an ebuild
declaring python3_ was only ever offering 12, 13 and 14.

Two reasons to clean them up anyway. The eclass branch they land in
dies for any EAPI other than 7 or 8, so all 139 are waiting to break on
the first EAPI 9 bump. And pkgcheck's OldPythonCompat is a git-scoped
check that only inspects ebuilds touched in a commit range, so it never
reports these on a full-tree scan and would instead fire on whichever
unrelated commit next touches one of them.

No revbump, because nothing observable changes. Verified on a sample
spanning every transformation shape that the python USE flags portage
offers are byte-identical before and after, and that a pkgcheck run
over all 65 packages returns a set-identical list of findings.

The eight python2_7 ebuilds are deliberately untouched: that target is
also absent from _PYTHON_ALL_IMPLS, but they reach it through the
_PYTHON_ALLOW_PY27 hatch in the overlay's forked python-utils-r1_py2.

commit dea2e262a7360d02cb9f7ee85bc3f8a4e2365902
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Jul 4 14:16:42 2026 +0200

dev-python/hf-transfer: new package, add 0.1.9

Rust-based accelerator for Hugging Face Hub file transfers (used by
huggingface_hub when HF_HUB_ENABLE_HF_TRANSFER=1). maturin build with the
crate set vendored via CRATES; build + import verified.