sci-ml/bitsandbytes
k-bit quantization (QLoRA) and 8-bit optimizers for PyTorch
Screenshots
-
bitsandbytes-0.50.0~amd64rocm python_single_target_python3_12 python_single_target_python3_13 python_single_target_python3_14 debug +amdgpu_targets_gfx908 +amdgpu_targets_gfx90a +amdgpu_targets_gfx942 +amdgpu_targets_gfx1030 +amdgpu_targets_gfx1100 +amdgpu_targets_gfx1101 +amdgpu_targets_gfx1200 +amdgpu_targets_gfx1201 amdgpu_targets_gfx803 amdgpu_targets_gfx900 amdgpu_targets_gfx906 amdgpu_targets_gfx940 amdgpu_targets_gfx941 amdgpu_targets_gfx1010 amdgpu_targets_gfx1011 amdgpu_targets_gfx1012 amdgpu_targets_gfx1031 amdgpu_targets_gfx1102 amdgpu_targets_gfx1103 amdgpu_targets_gfx1150 amdgpu_targets_gfx1151
View 
Download 
Browse License: MIT Overlay: stuff -
bitsandbytes-0.49.2~amd64rocm python_single_target_python3_12 python_single_target_python3_13 debug +amdgpu_targets_gfx908 +amdgpu_targets_gfx90a +amdgpu_targets_gfx942 +amdgpu_targets_gfx1030 +amdgpu_targets_gfx1100 +amdgpu_targets_gfx1101 +amdgpu_targets_gfx1200 +amdgpu_targets_gfx1201 amdgpu_targets_gfx803 amdgpu_targets_gfx900 amdgpu_targets_gfx906 amdgpu_targets_gfx940 amdgpu_targets_gfx941 amdgpu_targets_gfx1010 amdgpu_targets_gfx1011 amdgpu_targets_gfx1012 amdgpu_targets_gfx1031 amdgpu_targets_gfx1102 amdgpu_targets_gfx1103 amdgpu_targets_gfx1150 amdgpu_targets_gfx1151
View Download Browse License: MIT Overlay: stuff
ChangeLog
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 3e63a7606c7a6f2e0d6d445af6366982016bfd4e
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Jul 26 22:43:50 2026 +0200
sci-ml/bitsandbytes: track the supported interpreters on 0.50.0
Upstream 0.50.0 declares requires-python ">=3.10" with classifiers through
3.14, and its wheels are py3-none because the CUDA/HIP library is loaded via
ctypes rather than being a CPython extension, so python3_14 is available.
python3_11 goes at the same time: it is no longer a target in ::gentoo, and
the dep chain (pytorch, transformers) is python3_, so that end of the
range could not be satisfied anyway.
commit 9940c2775afe61610fdd5b545d9c73fbfb158d3c
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Jul 25 10:39:46 2026 +0200
sci-ml/bitsandbytes: add 0.50.0
commit 0f5e06ebaaa049de379b0040fa0c54151787e2d9
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Jul 5 14:42:10 2026 +0200
sci-ml/bitsandbytes: condense the build-backend comments
commit 561af98ec6b5e1cb3f5a8827cf36412bdfd25513
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Jul 4 13:18:44 2026 +0200
sci-ml/bitsandbytes: new package, add 0.49.2
k-bit quantization (QLoRA) and 8-bit optimizers for PyTorch — the load-bearing
enabler for the LlamaFactory fine-tuning cluster. Default COMPUTE_BACKEND=cpu;
USE=rocm builds the HIP backend. Both the CPU backend (build+import) and the
ROCm backend (build, HIP Targets gfx1150 via AMDGPU_TARGETS -> libbitsandbytes_
rocm72.so) are verified here.
Upstream drives CMake from setup.py's build_cmake via the scikit-build-core
setuptools shim (wheel.cmake=false; the CMakeLists has no install() rule and
emits libbitsandbytes_<backend>.so straight into the package dir), so the
ebuild uses DISTUTILS_USE_PEP517=standalone rather than the eclass's
scikit-build-core value; the ROCm backend is selected via CMAKE_ARGS.
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 3e63a7606c7a6f2e0d6d445af6366982016bfd4e
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Jul 26 22:43:50 2026 +0200
sci-ml/bitsandbytes: track the supported interpreters on 0.50.0
Upstream 0.50.0 declares requires-python ">=3.10" with classifiers through
3.14, and its wheels are py3-none because the CUDA/HIP library is loaded via
ctypes rather than being a CPython extension, so python3_14 is available.
python3_11 goes at the same time: it is no longer a target in ::gentoo, and
the dep chain (pytorch, transformers) is python3_, so that end of the
range could not be satisfied anyway.
commit 9940c2775afe61610fdd5b545d9c73fbfb158d3c
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Jul 25 10:39:46 2026 +0200
sci-ml/bitsandbytes: add 0.50.0
commit 0f5e06ebaaa049de379b0040fa0c54151787e2d9
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Jul 5 14:42:10 2026 +0200
sci-ml/bitsandbytes: condense the build-backend comments
commit 561af98ec6b5e1cb3f5a8827cf36412bdfd25513
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Jul 4 13:18:44 2026 +0200
sci-ml/bitsandbytes: new package, add 0.49.2
k-bit quantization (QLoRA) and 8-bit optimizers for PyTorch — the load-bearing
enabler for the LlamaFactory fine-tuning cluster. Default COMPUTE_BACKEND=cpu;
USE=rocm builds the HIP backend. Both the CPU backend (build+import) and the
ROCm backend (build, HIP Targets gfx1150 via AMDGPU_TARGETS -> libbitsandbytes_
rocm72.so) are verified here.
Upstream drives CMake from setup.py's build_cmake via the scikit-build-core
setuptools shim (wheel.cmake=false; the CMakeLists has no install() rule and
emits libbitsandbytes_<backend>.so straight into the package dir), so the
ebuild uses DISTUTILS_USE_PEP517=standalone rather than the eclass's
scikit-build-core value; the ROCm backend is selected via CMAKE_ARGS.