| View previous topic :: View next topic |
| Author |
Message |
leifbk
Guru
Joined: 05 Jan 2004
Posts: 422
Location: Bærum, Norway
|
 Posted: Mon Jun 03, 2024 9:56 am Post subject: |
 |
|
If there is any hope of this trainwreck of an upgrade to be sorted out soon, I think that I will postpone any attempts to upgrade my system further for a few days.
| Code: | These are the packages that would be merged, in order:
Calculating dependencies... done!
Dependency resolution took 5.79 s (backtrack: 0/20).
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
dev-python/gpep517:0
(dev-python/gpep517-16:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_12 -python3_10 -python3_11 -python3_13" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/gpep517-16:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13" pulled in by
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/jaraco-context-5.3.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/setuptools-scm-8.1.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/packaging-24.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/ordered-set-4.1.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/flit-core-3.9.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?] required by (dev-python/backports-tarfile-1.2.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 -python3_10"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/platformdirs-4.2.2:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/cython-3.0.10:0/0::gentoo, installed) USE="-debug -doc -test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/jaraco-functools-4.0.1:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/setuptools-70.0.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/pyproject-metadata-0.8.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_11 python3_12 -pypy3 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/wheel-0.43.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/numpy-2.0.0_rc2-r1:0/2::gentoo, ebuild scheduled for merge) USE="lapack -debug -test" ABI_X86="(64)" PYTHON_TARGETS="python3_11 python3_12 -pypy3 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/more-itertools-10.2.0:0/0::gentoo, installed) USE="-doc -test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/meson-python-0.16.0-r1:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_11 python3_12 -pypy3 -python3_10 -python3_13"
>=dev-python/gpep517-15[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/jaraco-text-3.12.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/packaging:0
(dev-python/packaging-24.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_12 -python3_10 -python3_11 -python3_13" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/packaging-24.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13" pulled in by
>=dev-python/packaging-24[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/setuptools-70.0.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/packaging-19[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/pyproject-metadata-0.8.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_11 python3_12 -pypy3 -python3_10 -python3_13"
dev-python/packaging[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/wheel-0.43.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/packaging[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/setuptools-scm-8.1.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/flit-core:0
(dev-python/flit-core-3.9.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_12 -python3_10 -python3_11 -python3_13" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/flit-core-3.9.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13" pulled in by
>=dev-python/flit-core-3.9.0[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/packaging-24.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/flit-core-3.9.0[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/ordered-set-4.1.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/flit-core-3.9.0[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/pyproject-metadata-0.8.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_11 python3_12 -pypy3 -python3_10 -python3_13"
>=dev-python/flit-core-3.9.0[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/platformdirs-4.2.2:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/flit-core-3.9.0[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/more-itertools-10.2.0:0/0::gentoo, installed) USE="-doc -test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/flit-core-3.9.0[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/jaraco-functools-4.0.1:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/flit-core-3.9.0[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/wheel-0.43.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/flit-core-3.9.0[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/jaraco-context-5.3.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/flit-core-3.9.0[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?] required by (dev-python/backports-tarfile-1.2.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 -python3_10"
>=dev-python/flit-core-3.9.0[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/jaraco-text-3.12.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/installer:0
(dev-python/installer-0.7.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_12 -python3_10 -python3_11 -python3_13" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/installer-0.7.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13" pulled in by
>=dev-python/installer-0.5.0[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/gpep517-16:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/setuptools:0
(dev-python/setuptools-70.0.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_12 -python3_10 -python3_11 -python3_13" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/setuptools-70.0.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13" pulled in by
>=dev-python/setuptools-69.0.3[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/cython-3.0.10:0/0::gentoo, installed) USE="-debug -doc -test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/setuptools[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/setuptools-scm-8.1.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/jaraco-text:0
(dev-python/jaraco-text-3.12.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_12 -python3_10 -python3_11 -python3_13" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/jaraco-text-3.12.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13" pulled in by
>=dev-python/jaraco-text-3.7.0-r1[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/setuptools-70.0.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/more-itertools:0
(dev-python/more-itertools-10.2.0:0/0::gentoo, ebuild scheduled for merge) USE="-doc -test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_12 -python3_10 -python3_11 -python3_13" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/more-itertools-10.2.0:0/0::gentoo, installed) USE="-doc -test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13" pulled in by
>=dev-python/more-itertools-8.12.0-r1[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/setuptools-70.0.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
>=dev-python/more-itertools-0.12.0-r1[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/jaraco-functools-4.0.1:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/ordered-set:0
(dev-python/ordered-set-4.1.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_12 -python3_10 -python3_11 -python3_13" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/ordered-set-4.1.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13" pulled in by
>=dev-python/ordered-set-4.0.2-r1[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/setuptools-70.0.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/platformdirs:0
(dev-python/platformdirs-4.2.2:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_12 -python3_10 -python3_11 -python3_13" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/platformdirs-4.2.2:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13" pulled in by
>=dev-python/platformdirs-2.6.2-r1[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/setuptools-70.0.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/wheel:0
(dev-python/wheel-0.43.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_12 -python3_10 -python3_11 -python3_13" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/wheel-0.43.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13" pulled in by
>=dev-python/wheel-0.37.1-r1[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/setuptools-70.0.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/setuptools-scm:0
(dev-python/setuptools-scm-8.1.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_12 -python3_10 -python3_11 -python3_13" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/setuptools-scm-8.1.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13" pulled in by
dev-python/setuptools-scm[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/setuptools-70.0.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/jaraco-context:0
(dev-python/jaraco-context-5.3.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_12 -python3_10 -python3_11 -python3_13" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/jaraco-context-5.3.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13" pulled in by
>=dev-python/jaraco-context-4.1.1-r1[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/jaraco-text-3.12.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/jaraco-functools:0
(dev-python/jaraco-functools-4.0.1:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_12 -python3_10 -python3_11 -python3_13" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/jaraco-functools-4.0.1:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13" pulled in by
>=dev-python/jaraco-functools-3.5.0-r1[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?,python_targets_python3_12(-)?,python_targets_python3_13(-)?] required by (dev-python/jaraco-text-3.12.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
dev-python/backports-tarfile:0
(dev-python/backports-tarfile-1.2.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 -python3_10 -python3_11" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(dev-python/backports-tarfile-1.2.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 -python3_10" pulled in by
dev-python/backports-tarfile[python_targets_pypy3(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?] required by (dev-python/jaraco-context-5.3.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10 -python3_13"
It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously.
For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.
|
_________________
Grumpy old man |
|
| Back to top |
|
 |
leifbk
Guru
Joined: 05 Jan 2004
Posts: 422
Location: Bærum, Norway
|
| Posted: Mon Jun 03, 2024 10:18 am Post subject: |
|
|
Kind of fixed it, by adding these two lines on the top of /etc/portage/package.use:
| Code: | */* PYTHON_TARGETS: -* python3_11 python3_12
*/* PYTHON_SINGLE_TARGET: -* python3_11 |
Seems like the CF went away, and my computer is now merrily compiling 127 packages.
Just tell me when I can remove those two lines from my package.use by way of a news letter, please.
_________________
Grumpy old man |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2417
|
| Posted: Mon Jun 03, 2024 2:35 pm Post subject: |
|
|
| e8root wrote: | Imho the defaults should be
| Code: | | */* PYTHON_TARGETS: -* python3_11 python3_12 |
and python3_11 removed from targets when and only when all packages needing python work with Python 3.12
Removing python3_11 from targets only adds issues. |
| steve_v wrote: | | e8root wrote: | Imho the defaults should be
| Code: | | */* PYTHON_TARGETS: -* python3_11 python3_12 |
and python3_11 removed from targets when and only when all packages needing python work with Python 3.12
|
Bingo. |
Am I stupid, or you both invented something that wasn't there? I will write the following out of my memory and later I'll check the news idem again to see where you were instructed to touch python targets. From what I remember, that was for the ones who wanted to migrate early or delay the migration, any of which you both didn't do.
Regarding what an overlay has to do with the main tree, rather than complaining like you I took the matters in my own hands which I suggest you do too. Be it with just filing bugs, that could be helpful too.
No, we can't wait every package to support python 3.12, because as I said, some will never do. They just don't have maintainers. In the same time nobody forced you to remove 3.11. You could stay with it a good 6 months at least. Had you read the news item carefully, you could decide to set PYTHON_TARGETS instead of dealing with "misleading output" or whatever. The change was announced well in advance. I even tried to migrate early and realized it was not going to happen. Yesterday I could still stay with 3.11 but decided to ditch a package I wasn't sure I even ever used.
Now is moment of truth - I checked the news item and nowhere there is explicitly advised to set python targets. Quite the contrary, a few cases when you might want to do that and how exactly to do it are described and one of them is a safe upgrade procedure which you could follow. From this point on I consider it pointless to engage in further discussion.
Best Regards,
Georgi
Last edited by logrusx on Mon Jun 03, 2024 2:42 pm; edited 1 time in total |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2417
|
| Posted: Mon Jun 03, 2024 2:39 pm Post subject: |
|
|
| leifbk wrote: | Kind of fixed it, by adding these two lines on the top of /etc/portage/package.use:
| Code: | */* PYTHON_TARGETS: -* python3_11 python3_12
*/* PYTHON_SINGLE_TARGET: -* python3_11 |
Seems like the CF went away, and my computer is now merrily compiling 127 packages.
Just tell me when I can remove those two lines from my package.use by way of a news letter, please. |
You shouldn't have had to do that. It must overlap with the default behavior. When you ask for help you should post the command you're running as well. That way we could diagnose your issue, which might be hidden in the command itself.
Also it is better to open your own thread where people can focus on your particular issue, rather than getting confused with the problems of others.
Regarding when you should remove that, what you put in your /etc/portage is your responsibility. Make note or something to check it in the future. One way to notice is when you see packages building with both 3.11 and 3.12 and 3.12 is marked new, I think it was marked with asterisk as well as a different color, in my case it's yellow, but I think that depends on the color scheme of the terminal.
Best Regards,
Georgi |
|
| Back to top |
|
|
leifbk
Guru
Joined: 05 Jan 2004
Posts: 422
Location: Bærum, Norway
|
| Posted: Mon Jun 03, 2024 3:17 pm Post subject: |
|
|
| logrusx wrote: | | leifbk wrote: | Kind of fixed it, by adding these two lines on the top of /etc/portage/package.use:
| Code: | */* PYTHON_TARGETS: -* python3_11 python3_12
*/* PYTHON_SINGLE_TARGET: -* python3_11 |
Seems like the CF went away, and my computer is now merrily compiling 127 packages.
Just tell me when I can remove those two lines from my package.use by way of a news letter, please. |
You shouldn't have had to do that. It must overlap with the default behavior. When you ask for help you should post the command you're running as well. That way we could diagnose your issue, which might be hidden in the command itself. |
The two lines of code are from the news letter that announced the coming Python 3.12 upgrade, and, as I understand it, intended as a remedy against exactly this kind of problems. I have been running Gentoo for more than twenty years and generally know what I'm doing. I don't post here too often, but I became perplexed by the current upgrade.
It seems like what happened is that some time yesterday net-print/hplip was marked as ready to build with Python 3.12. It broke under compiling, but I was just able to do the rest of the upgrade. Today the hplip upgrade was reverted to build with Python 3.11. The result when I tried to set "python_single_target_python3_11" on the hplip in package.use was a cascade of other dependencies as mentioned by Hu in another thread.
Hopefully net-print/hplip will be fixed soon, see https://bugs.gentoo.org/932150
| Quote: | | Regarding when you should remove that, what you put in your /etc/portage is your responsibility. Make note or something to check it in the future. One way to notice is when you see packages building with both 3.11 and 3.12 and 3.12 is marked new, I think it was marked with asterisk as well as a different color, in my case it's yellow, but I think that depends on the color scheme of the terminal. |
Sounds like good advice 
_________________
Grumpy old man |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Mon Jun 03, 2024 3:43 pm Post subject: |
|
|
| steve_v wrote: | | the news item states that unless you have manually set python_targets or want to delay the change, this is supposed to be handled automatically. |
It also states: | Quote: | | the package manager will try |
| Quote: | | or have problems with the update |
| Quote: | | some programs may temporarily fail to find their dependencies throughout the upgrade |
| Quote: | | you have a few configuration options to choose from |
Emphasis added. They don't prescribe a method. | Quote: | | your package manager should handle the upgrade automatically. However, you may still need to run the update commands if any problems arise. |
| Quote: | | safer approach (i.e. less likely to temporarily break packages during the upgrade), you can perform a multi-step |
Since this seems to happen every time, I don't know why you haven't tried to help yourself avoid some frustration by choosing the safer approach.
| steve_v wrote: | | If the "Safer upgrade procedure" is the way to go about this without removing a bunch of high-profile applications or having portage blow up in your face, it should simply be called "The upgrade procedure". |
I agree, they should specifically recommend using that procedure and leave the other methods as available but not recommended. In the meantime, why do you insist on not using it when experience tells you the other method you choose won't work on your system(s)?
| steve_v wrote: | | So we're going to drop kicad then are we? |
That isn't what I wrote. I was referring to all upstream packages having unknowable schedules for adding 3.12 support. AT SOME POINT, the switch will be arbitrary for some packages which don' t include support. THAT is the point I was trying to make.
I too would prefer a slower pace, but I don't get to make the choice.
The choice I do get is which upgrade path to take. In the past I've chosen to delay updating. To avoid frustration, I've switched to the "safer" procedure.
You choose whatever path you want to take.
Spoiler alert, 3.13 is in portage as "beta" versions. Will it be coming in 2025? 2026?
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2417
|
| Posted: Mon Jun 03, 2024 3:45 pm Post subject: |
|
|
| leifbk wrote: | | logrusx wrote: | | leifbk wrote: | Kind of fixed it, by adding these two lines on the top of /etc/portage/package.use:
| Code: | */* PYTHON_TARGETS: -* python3_11 python3_12
*/* PYTHON_SINGLE_TARGET: -* python3_11 |
Seems like the CF went away, and my computer is now merrily compiling 127 packages.
Just tell me when I can remove those two lines from my package.use by way of a news letter, please. |
You shouldn't have had to do that. It must overlap with the default behavior. When you ask for help you should post the command you're running as well. That way we could diagnose your issue, which might be hidden in the command itself. |
The two lines of code are from the news letter that announced the coming Python 3.12 upgrade, and, as I understand it, intended as a remedy against exactly this kind of problems. |
Nowhere in the news item are those two lines alone. They are only present in the safer upgrade procedure which you apparently undertook. However you failed to mention that and it looks like you followed it only partially. Nevertheless, that likely wouldn't have been successful as, safer or not the upgrade procedure can happen only if you don't have packages which only support python up to 3.11.
| leifbk wrote: | | I have been running Gentoo for more than twenty years and generally know what I'm doing. I don't post here too often, but I became perplexed by the current upgrade. |
You see, when somebody is doing something for a long time it becomes very easy to overlook things out of experience and knowledge. At least for me, that happens a lot. Sometimes I overlook obvious things.
| leifbk wrote: | | It seems like what happened is that some time yesterday net-print/hplip was marked as ready to build with Python 3.12. It broke under compiling, but I was just able to do the rest of the upgrade. Today the hplip upgrade was reverted to build with Python 3.11. The result when I tried to set "python_single_target_python3_11" on the hplip in package.use was a cascade of other dependencies as mentioned by Hu in another thread. |
That's a direct consequence of you needlessly undertaking the safer upgrade procedure. After whole two days discussing this issue with people who didn't read the news item in whole or misunderstood it, I'm starting to think that was the most unnecessary part of this news item.
Once again, you don't need to fully migrate to 3.12. In your case it might be better to just wait for it to be fixed as you've already done a lot of work and it would be wasteful to repeat it only to return back to the previous state just for one package. And as I wrote that I checked the history of the package and I see there's a commit from 3 hours ago. You should be good to try again.
| leifbk wrote: | | Quote: | | Regarding when you should remove that, what you put in your /etc/portage is your responsibility. Make note or something to check it in the future. One way to notice is when you see packages building with both 3.11 and 3.12 and 3.12 is marked new, I think it was marked with asterisk as well as a different color, in my case it's yellow, but I think that depends on the color scheme of the terminal. |
Sounds like good advice :) |
I hope it really works for you. At least it something obvious it would catch your attention if you have it in the back of your mind.
Best Regards,
Georgi
Last edited by logrusx on Mon Jun 03, 2024 3:51 pm; edited 1 time in total |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2417
|
| Posted: Mon Jun 03, 2024 3:48 pm Post subject: |
|
|
| pjp wrote: |
| steve_v wrote: | | If the "Safer upgrade procedure" is the way to go about this without removing a bunch of high-profile applications or having portage blow up in your face, it should simply be called "The upgrade procedure". |
I agree, they should specifically recommend using that procedure and leave the other methods as available but not recommended. |
No, this is not "The upgrade procedure" exactly because of cases like steve_v's i.e. packages still not supporting python 3.12. There's no "The upgrade procedure" if even only one such package exists. It is pointless to continue further discussion about it because the conditions to investigate why exactly this happened are gone, only the whining is here which it totally unnecessary. And the more I think about it, the more it seems OP likely did something on their side that caused that situation and either doesn't realize it or doesn't want to admit it.
"The upgrade procedure" is to let portage try to figure it out and from then on intervene, if necessary.
Best Regards,
Georgi |
|
| Back to top |
|
|
cameta
Veteran
Joined: 04 Aug 2004
Posts: 1351
|
| Posted: Mon Jun 03, 2024 3:55 pm Post subject: |
|
|
The best solution for me is deferring the upgrade for now
To defer the upgrade, explicitly set the old targets in package.use:
*/* PYTHON_TARGETS: -* python3_11
*/* PYTHON_SINGLE_TARGET: -* python3_11
_________________
Si algo falla LEE el jodido manual, Si sigue fallando LEE BIEN el jodido manual. |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2417
|
| Posted: Mon Jun 03, 2024 4:00 pm Post subject: |
|
|
| cameta wrote: | The best solution for me is deferring the upgrade for now
To defer the upgrade, explicitly set the old targets in package.use:
*/* PYTHON_TARGETS: -* python3_11
*/* PYTHON_SINGLE_TARGET: -* python3_11 |
Yes, but you should do it prior to doing any compiling. Otherwise you might need to do unnecessary work to go back.
In the mean time better inspect your packages and see if you can find a testing version that has been already moved to 3.12.
Best Regards,
Georgi |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Mon Jun 03, 2024 4:06 pm Post subject: |
|
|
| szatox wrote: | | Great, so, since python has effectively 5 supported versions, and version 12 has just been released, is there any harm in delaying changing the defaults for the whole repository from 11 to 12 until all packages in main repo are ready? |
I don't know why the choice is made, I only offered some reasons why waiting until the whole repository supports 3.12 may not work. The whole repository may never support 3.12. You don't have to use 3.12. In the news announcement, option 2 is to defer the upgrade.
| szatox wrote: | Some problems solve themselves when left alone for some time, so not rushing could reduce the burned on Gentoo maintainers, while also not exploding everyone's @world updates with portage complaining about installed packages not having suitable targets.
Say, instead of going over existing ebuilds and enabling python 3.12 for them, wait for regular version bumps? |
I suspect a lack of visibility into what the devs have to do may be relevant here. I really dislike hearing when someone who doesn't know what goes on says something like "It's easy, all you have to do is <something demonstrating their ignorance>."
A favorable way to look at the upgrades might be: The devs probably have a lot to do, and this schedule works for them. This schedule isn't great for me, but at least they provided options I can choose.
| szatox wrote: | | I get that I can locally override the default and just force the older python on my system, but if I do that, I'll have to remember to clean it up later. Meanwhile, it looks like the whole issue could have been completely avoided with just a little bit of patience. |
At some point, the switch has to be made. Which date upsets no one? That's likely in part what it comes down to. The devs can probably come to a decision on what time window works for them. They can never pick a window that works for all users.
| szatox wrote: | | Also, AFAIR python is slotted in Gentoo, so I kinda wonder why packages which don't support 3.12 don't fall back to another installed version... I though it was a solved problem by now; looks like I was wrong though. Oh, well... |
If you have 3.11 and 3.12 installed and the package is compiled with support for both, then I believe it does work. If you build only with 3.12 support, it obviously can't use 3.11. Maybe I misunderstand your point or how it works.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
kurisu
Apprentice
Joined: 19 Jan 2011
Posts: 177
Location: Munich, Germany
|
| Posted: Mon Jun 03, 2024 4:15 pm Post subject: |
|
|
| sam_ wrote: | | Hu wrote: | The plan to move to Python3.12 was announced well in advance, and the date was known too. I cannot comment on why some packages are not ready yet.
I do agree that no one needs NodeJS though. Some things are better left to rot. However, in this case, net-libs/nodejs: needs upgrade to Python 3.12 (PythonCompatUpdate) reported that it needed an update. It looks like the unstable versions received one. As above, I cannot comment on why the stable versions were not ready in time. |
Just to comment on this bit: python-any-r1 upgrades are less important because they don't require any user intervention. Lagging for those only prevents users depcleaning python3.11 but won't ever produce any USE flag issues and such.
I appreciate people's understanding overall. |
Word!
_________________
#1 Ryzen 7 2700 | Asus ROG Strix X470-F Gaming | G.Skill 32 GB DDR4-3000 | PowerColor Radeon RX 5700 Red Dragon | Samsung SSD 970 EVO Plus 1TB NVMe
#2 Ryzen 5 2400G | ASRock B450 Steel Legend | G.Skill 16 GB DDR4-3000 | Samsung SSD 850 PRO 512GB SATA |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Mon Jun 03, 2024 4:17 pm Post subject: |
|
|
| logrusx wrote: | | "The upgrade procedure" is to let portage try to figure it out and from then on intervene, if necessary. |
Our disagreement may be an example of why the news item does not say "Do this" and instead offers 5 choices: - maybe it works
- defer
- early
- safe
- arbitrary per package
On my non-GUI system, I had the "maybe it works" method work without problems for the first time. I don't expect that outcome when I get around to updating my laptop. In a Perfect World it would work differently.
The reason the "safer" approach could be beneficial as the recommended path is that it might reduce friction. Every time there are updates, quite a few users have problems. Rolling release distros and upstream version churn lead to these situations, and the latter doesn't seem to be going away any time soon.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2417
|
| Posted: Mon Jun 03, 2024 4:25 pm Post subject: |
|
|
| pjp wrote: |
The reason the "safer" approach could be beneficial as the recommended path is that it might reduce friction. |
I have nothing against the safer upgrade procedure. Only some users seem to be taking "safer" to be "guaranteed successful" which is not the case.
Best Regards,
Georgi |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Mon Jun 03, 2024 4:48 pm Post subject: |
|
|
Oh, I hadn't perceived that.
As I quoted in an earlier reply, the announcement has a lot of verbiage that suggest there are likely to be issues that need to be manually resolved.
I don't think it is possible to have an announcement / procedure that is without some issue for some users. The only issue I've had with the Safer procedure is forgetting the last step until the next upgrade (3.10 to 3.11 if I recall). I had to finish the previous migration before starting the next.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
metafarion
n00b
Joined: 15 Mar 2012
Posts: 13
Location: Madison, WI
|
| Posted: Mon Jun 03, 2024 4:54 pm Post subject: |
|
|
I wonder if maybe a lot of this stress and bother would go away if portage had a mechanism to warn users WHAT effect an upcoming global change like a new default python target would have on their system.
Not just an easily missable news item that says "Hey, change coming, take stock of your packages and defer this change if you depend on python 3.11" but more like emerge actually outputs "Hey, you have the following packages installed whose ebuilds don't have a python 3.12 as a build target. This is going to cause SYSTEMWIDE INSTALLATION ISSUES on June 1; here's what you should do it you depend on these packages." Maybe even output this in a prompt that the user needs to acknowledge in order to continue emerging. It would almost certainly be more useful than the infamous pages and pages of emerge dependency spam that provides "all the information you need!" but communicates nothing about the real problem.
Incidentally, I too, had a couple of these packages on my system, and they actually compiled fine when I altered the ebuild to include python 3.12 as a target. Not that the user should have to do that, but I think lots of these issues arise not because a package CAN'T run with the newer python, but because the ebuild that installs it doesn't account for the newer python's existence. Maybe portage itself should have a way to auto-generate a contingency ebuild for such packages if they're unmaintained or seldom-maintained. It would be preferable to tombstoning them just because the designated maintainer has neglected to change python3_{10..11} to python3_{10..12} in the ebuild. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Mon Jun 03, 2024 5:32 pm Post subject: |
|
|
| metafarion wrote: | I wonder if maybe a lot of this stress and bother would go away if portage had a mechanism to warn users WHAT effect an upcoming global change like a new default python target would have on their system.
Not just an easily missable news item that says |
If the user doesn't read their news items, how are they going to know when to employ this new mechanism? The python 3.12 news item was on May 9th, which is nearly a month of not reading news items. That's not "easily missable," that's willfully ignoring an important part of maintaining Gentoo.
| metafarion wrote: | | "Hey, change coming, take stock of your packages and defer this change if you depend on python 3.11" but more like emerge actually outputs "Hey, you have the following packages installed whose ebuilds don't have a python 3.12 as a build target. This is going to cause SYSTEMWIDE INSTALLATION ISSUES on June 1; here's what you should do it you depend on these packages." Maybe even output this in a prompt that the user needs to acknowledge in order to continue emerging. It would almost certainly be more useful than the infamous pages and pages of emerge dependency spam that provides "all the information you need!" but communicates nothing about the real problem. |
I would hope the prompt acknowledgement could be disabled. I don't thin portage has any "automatic" mechanism. Manually updating the system is going to present the new settings as they arrive. The mechanism seems to suggest a default "defer" state that expects a user to run a "python upgrade check" tool, but if they could do that, they can read a news announcement.
| metafarion wrote: | | I altered the ebuild to include python 3.12 as a target. Not that the user should have to do that, |
They don't have to and shouldn't. The correct approach is to set PYTHON_TARGETS and PYTHON_SINGLE_TARGET for the affected packages (which settings are provided in output from emerge).
| metafarion wrote: | | I think lots of these issues arise not because a package CAN'T run with the newer python, but because the ebuild that installs it doesn't account for the newer python's existence. |
That is true. It takes time to get them updated which also depends on upstream.
| metafarion wrote: | | Maybe portage itself should have a way to auto-generate a contingency ebuild for such packages if they're unmaintained or seldom-maintained. It would be preferable to tombstoning them just because the designated maintainer has neglected to change python3_{10..11} to python3_{10..12} in the ebuild. |
It is trivial to copy the previous ebuild to a new version number. It may well be automated, I don't know. If the new version doesn't build, a developer has to figure out why. Then there is the time to wait before it is release as stable. If the upstream package isn't maintained, EVENTUALLY tombstoning is the only practical (if unfortunate) option. There are only so many dev hours available that need to be spread across "tasks."
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2417
|
| Posted: Mon Jun 03, 2024 5:45 pm Post subject: |
|
|
| metafarion wrote: | I wonder if maybe a lot of this stress and bother would go away if portage had a mechanism to warn users WHAT effect an upcoming global change like a new default python target would have on their system.
Not just an easily missable news item that says "Hey, change coming, take stock of your packages and defer this change if you depend on python 3.11" |
That's not going to work because the news items do the same job, the same way and people still miss them. I usually check the output of portage prior to eix doing its things and since eix-update ouputs a lot of unnecessary output after that, I deliberately go back to see if portage spit something opt.
| metafarion wrote: | | but more like emerge actually outputs "Hey, you have the following packages installed whose ebuilds don't have a python 3.12 as a build target. |
That actually sounds good except who's going to implement it and then maintain it when it's only needed occasionally.
| metafarion wrote: | | Maybe even output this in a prompt that the user needs to acknowledge in order to continue emerging. It would almost certainly be more useful than the infamous pages and pages of emerge dependency spam that provides "all the information you need!" but communicates nothing about the real problem. |
It does it now, only it says you have unread news items which apparently people ignore, so it's not going to work for the same reason the first suggestion won't.
| metafarion wrote: | | Incidentally, I too, had a couple of these packages on my system, and they actually compiled fine when I altered the ebuild to include python 3.12 as a target. Not that the user should have to do that, but I think lots of these issues arise not because a package CAN'T run with the newer python, but because the ebuild that installs it doesn't account for the newer python's existence. Maybe portage itself should have a way to auto-generate a contingency ebuild for such packages if they're unmaintained or seldom-maintained. It would be preferable to tombstoning them just because the designated maintainer has neglected to change python3_{10..11} to python3_{10..12} in the ebuild. |
It has been said time and time again that there simply aren't maintainers for all packages. If someone dares to touch an unmaintained ebuild, they automatically become accountable, nevertheless it was just an isolated event of them doing the necessary thing. Given that the current maintainers and developers already have a ton of work, why would they do that to themselves?
Best Regards,
Georgi |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3428
|
| Posted: Mon Jun 03, 2024 6:12 pm Post subject: |
|
|
| pjp wrote: | | szatox wrote: | | Great, so, since python has effectively 5 supported versions, and version 12 has just been released, is there any harm in delaying changing the defaults for the whole repository from 11 to 12 until all packages in main repo are ready? |
I don't know why the choice is made, I only offered some reasons why waiting until the whole repository supports 3.12 may not work. The whole repository may never support 3.12. You don't have to use 3.12. In the news announcement, option 2 is to defer the upgrade. |
There is a difference between "the defaults working not the way I want in my particular use case", and "the defaults not working, period".
Right now there are a bunch of packages in the main repo which don't have a suitable target AKA don't work with the new defaults.
And before someone brings up that many packages require custom USE flags to build at all: use flags are meant to be customized and they are not _expected_ to be updated afterwards, as opposed to python versions changing on schedule, while different versions are similar enough there is little reason to not follow the trend.
| Quote: | | szatox wrote: | Some problems solve themselves when left alone for some time, so not rushing could reduce the burned on Gentoo maintainers, while also not exploding everyone's @world updates with portage complaining about installed packages not having suitable targets.
Say, instead of going over existing ebuilds and enabling python 3.12 for them, wait for regular version bumps? |
I suspect a lack of visibility into what the devs have to do may be relevant here. I really dislike hearing when someone who doesn't know what goes on says something like "It's easy, all you have to do is <something demonstrating their ignorance>."
A favorable way to look at the upgrades might be: The devs probably have a lot to do, and this schedule works for them. This schedule isn't great for me, but at least they provided options I can choose. |
I explicitly asked why things are being done the way they're being done right now, so calling out my ignorance for trying to learn something without providing any information is inappropriate and not very helpful.
I hereby uno reverse your move, calling you out for calling me out. Callception!
| Quote: |
| szatox wrote: | | I get that I can locally override the default and just force the older python on my system, but if I do that, I'll have to remember to clean it up later. Meanwhile, it looks like the whole issue could have been completely avoided with just a little bit of patience. |
At some point, the switch has to be made. Which date upsets no one? That's likely in part what it comes down to. The devs can probably come to a decision on what time window works for them. They can never pick a window that works for all users.
|
No, >>I<< and probably the vast, vast majority of other users don't depend on any particular version of python, which is precisely why use defaults. This schedule _clearly_ didn't work for _devs_ who are maintaining ::gentoo tree. The main repo, ::gentoo, is not ready for the switch.
Users are just getting splashed with collateral.
Now, although I might be ignorant of the details regarding the dealing within Gentoo devs silo, I am not new to either schedules nor working in an ogranization, so even without direct visibility I can make a guess that blaming it on "the developers" covers way too many people who were not involved in making this decision.
While working for such an organization (like in: for money), I have actually pushed back against managers and their schedules when they would have us, techies, running in circles doing things twice just so they can have the first result next week instead of next month when prerequisites are met and we wouldn't have to repeat the same work again.
Someone already pointed out that there are never enough maintainers. Is making them frantically fix stuff which broke due to new default an effective use of their time? I personally hate fixing a mess which could have been avoided with minimal effort, and I've seen my share of people in important chairs, whose lack of foresight caused one unnecessary mess after another.
| Quote: |
| szatox wrote: | | Also, AFAIR python is slotted in Gentoo, so I kinda wonder why packages which don't support 3.12 don't fall back to another installed version... I though it was a solved problem by now; looks like I was wrong though. Oh, well... |
If you have 3.11 and 3.12 installed and the package is compiled with support for both, then I believe it does work. If you build only with 3.12 support, it obviously can't use 3.11. Maybe I misunderstand your point or how it works. |
I though that a package which can use 3.11 but not 3.12 would fall back to 3.11 even if 3.12 is the system default as long 3.11 is available.
Right now it doesn't seem to be the case, as having both 3.11 and 3.12 in python targets with single target pointing to 3.12 doesn't allow those to build. Single-target must be 3.11 too, so there is little reason to even include 3.12 in python_targets.
| Quote: | | I wonder if maybe a lot of this stress and bother would go away if portage had a mechanism to warn users WHAT effect an upcoming global change like a new default python target would have on their system. |
Oh, but this one was supposed to be seamless, right? And it probably would have been, if all ebuilds were updated before it came into effect.
_________________
Make Computing Fun Again |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20485
|
| Posted: Mon Jun 03, 2024 7:25 pm Post subject: |
|
|
| szatox wrote: | | There is a difference between "the defaults working not the way I want in my particular use case", and "the defaults not working, period". |
For one of my systems, this go around has been easier than any other. So, "not working period" isn't accurate. So far I haven't seen anything in posts that seems out of the norm compared with the last few upgrades. Given the mechanism for how updates work, independent of User #1 and User #2 for whom today and tomorrow don't work and User #3, rolling release isn't going to have a perfect "everything aligned, hurry up and press the release button." Even if June 1st was the wrong day, there isn't going to be a day that works for everyone. I'm either not able to make that clear, or I'm not understanding why that is difficult to grasp or otherwise so objectionable to accept that it results in these kinds of threads.
| szatox wrote: | | Right now there are a bunch of packages in the main repo which don't have a suitable target AKA don't work with the new defaults. |
I don't think that is disputed. Is it quantifiably different than the last few upgrades?
It doesn't matter to me if new versions are delayed a year. But the new version is also considered the "current" version. What about the users who don't like lagging behind upstream? They shouldn't have to go out of their way to use the current major version or wait "too long" to have it available by default. 3.12 was first released in Oct 2023. Is 7 months too soon or too long? I don't know when the "beta" versions were dropped, so that may matter too.
| szatox wrote: | | as opposed to python versions changing on schedule, while different versions are similar enough there is little reason to not follow the trend. |
Which trend? In my limited experience, developers clamor to get the latest current version as soon as possible. RedHat even went out of their way to add a Dr. Frankenstein hack to support newer versions of packages because their release cycle didn't (often?) offer major version updates.
| szatox wrote: | I explicitly asked why things are being done the way they're being done right now, so calling out my ignorance for trying to learn something without providing any information is inappropriate and not very helpful.
I hereby uno reverse your move, calling you out for calling me out. Callception! |
That comment was in general to stave off the torch and pitchforkers. This seems to happen every time. I don't know if there has been a specific answer about how the timing is chosen. Asking for one is fine. But for those who get angry about it, I presented that point of view. Also, ignorance isn't a criticism or insult.
| szatox wrote: | | Is making them frantically fix stuff which broke due to new default an effective use of their time? |
Either they unwittingly do that every time (only this one time?) or they otherwise make the choice that Somehow Make Sense?
Other than adding category/package "python target" specifications, is there something else that's not working? Other than going through the list of packages which takes some time, is something else breaking? The one system I updated was an unusually early upgrade for me, so I can't comment. But when I've updated in the past after delaying it, I've always had packages that I had to fix by setting the old target or single target version. I'm all for a way to solve the problem. I'm not aware of a way to make it go away. Well, maybe it would have been Reasonable to not switch until everything supported 3.12. If so, then that would be the answer I'd like to hear. That's why I presume it isn't a viable approach and that waiting another 6 months wouldn't have made much difference.
| szatox wrote: | I though that a package which can use 3.11 but not 3.12 would fall back to 3.11 even if 3.12 is the system default as long 3.11 is available.
Right now it doesn't seem to be the case, as having both 3.11 and 3.12 in python targets with single target pointing to 3.12 doesn't allow those to build. Single-target must be 3.11 too, so there is little reason to even include 3.12 in python_targets. |
I presume single_target 3.11 means it is required, and that if other versions are in python_targets, they are part of the migration process without immediate effect. | Quote: | The PYTHON_TARGETS variable is used for packages that support enabling more than a single Python implementation. Therefore, the variable may contain any number of implementations.
The PYTHON_SINGLE_TARGET variable is used for packages that are built for a single implementation of choice only. It may contain only a single implementation. Due to technical limitations, the implementation specified as PYTHON_SINGLE_TARGET must also be included in PYTHON_TARGETS for the package in question. |
But I'm "interpreting" a bit.
https://wiki.gentoo.org/wiki/Project:Python/PYTHON_TARGETS
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2417
|
| Posted: Mon Jun 03, 2024 7:37 pm Post subject: |
|
|
| szatox wrote: | | pjp wrote: | | szatox wrote: | | Great, so, since python has effectively 5 supported versions, and version 12 has just been released, is there any harm in delaying changing the defaults for the whole repository from 11 to 12 until all packages in main repo are ready? |
I don't know why the choice is made, I only offered some reasons why waiting until the whole repository supports 3.12 may not work. The whole repository may never support 3.12. You don't have to use 3.12. In the news announcement, option 2 is to defer the upgrade. |
There is a difference between "the defaults working not the way I want in my particular use case", and "the defaults not working, period".
Right now there are a bunch of packages in the main repo which don't have a suitable target AKA don't work with the new defaults.
And before someone brings up that many packages require custom USE flags to build at all: use flags are meant to be customized and they are not _expected_ to be updated afterwards, as opposed to python versions changing on schedule, while different versions are similar enough there is little reason to not follow the trend. |
I will address only that part of your post as I'm tired.
First, "the defaults not working, period" what pjp said. Defaults worked for me too with minimal adjustment, one bug failed, which was resolved in like 30 minutes, a few testing versions added to package.accept_keywords and letting go of one package I wasn't sure if I ever used.
Second, there seem to be some confusion about defaults. Defaults do not exclude fallback. And it's there, I still have 3.11 and a few packages not having a 3.12 version. Did you intentionally hard set the defaults to not have a fallback? Sorry if you've already addressed that above, this discussion became rather long.
Third, following from the second, there are no packages which have no suitable target. Maybe unless they are 3.10 compatible or even older. I'm not aware what's the earliest python available. I think the other day it was 3.9, so unless you have packages that are 3.8 and below, you're covered.
There is this possibility I see that there's a complicated dependency between python packages themselves, which somehow prevents dependency resolution. But this should be a very obscure case.
Best Regards,
Georgi |
|
| Back to top |
|
|
steve_v
Guru
Joined: 20 Jun 2004
Posts: 409
Location: New Zealand
|
| Posted: Tue Jun 04, 2024 8:30 am Post subject: |
|
|
Great, now we have a new stable freecad ebuild (previous revisions removed of course) which, assuming you want a GUI, requires either explicitly disabling python 3.12 (i.e. 'python_single_target_python3_11 -python_single_target_python3_12' ) or installing qt6 (which is still masked in stable profiles) and dealing with a bunch of open QT6 bugs.
This is ridiculous. Enough.
| Code: | */* PYTHON_TARGETS: -* python3_11
*/* PYTHON_SINGLE_TARGET: -* python3_11 |
it is then. Wake me when this mess is sorted out.
| Quote: | | There are a bunch of open issues on the upstream bug tracker, but it is mostly usable. |
While this is in reference to freecad, at this point I'm pretty sure it applies just as much to python 3.12 on gentoo in general. Operative word being "mostly", with a side of "if you add a generous helping of manual overrides and other screwing around".
If we're talking about maintainer workload, why is python packaging trying so hard to force everyone else to scramble "mostly usable" ebuilds?
_________________
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 163
|
| Posted: Tue Jun 04, 2024 10:00 am Post subject: |
|
|
| Hu wrote: | | I did not readily find Gentoo bug reports for any of those packages breaking with the Python 3.12 upgrade. Could you link to where this breakage is reported, preferably with enough detail that someone can fix it? |
Bug reports are definitely helpful. I couldn't even tell you offhand which packages I maintain use python, let alone which ones have or have-not been updated to work with 3.12. Somebody filed a bug for one of them on Saturday just before the cutover and I fixed it within an hour or so.
I suspect that many of the problems are simply due to the fact that maintainers aren't aware of them. |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2417
|
| Posted: Tue Jun 04, 2024 11:04 am Post subject: |
|
|
| steve_v wrote: | | why is python packaging trying so hard to force everyone else to scramble "mostly usable" ebuilds? |
I'm saying this for a gazilionth time, nobody forced anybody into anything. I didn't read a single thread in which the issue was not cause by the user attempting to do something they didn't need to, except maybe the thread I started.
Best Regards,
Georgi |
|
| Back to top |
|
|
steve_v
Guru
Joined: 20 Jun 2004
Posts: 409
Location: New Zealand
|
| Posted: Tue Jun 04, 2024 12:08 pm Post subject: |
|
|
| logrusx wrote: | | I didn't read a single thread in which the issue was not cause by the user attempting to do something they didn't need to |
I'm wasn't talking about users, I was referring to the maintainers who have to pull in and maintain a bunch of unstable patches to support 3.12 where upstream isn't there yet... Particularly with regard to earlier comments on there not being enough maintainers.
_________________
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
