Python 3.14 stability

[Maitreya]

Gentoo is usually the sweetspot on stable/bleeding edge.

Has fine standards to declare something "stable" and still allows you to shoot yourself in the foot if you choose to do so.

Understanding that "3.14" is just too beautiful of a version to release for piethon , it doesn't seem very stable.
Or at least I am gettin quite some error due to it's new async features and portage not liking it.

Portage being so core to Gentoo, I am a bit surprised that 3.14 was marked stable, is just me or shouldn't it be?

[fedeliallalinea]

The package dev-lang/python:3.14 is marked stable but python_targets_python3.14 and python_single_target_python3.14 use flag no.
So emerge command still working with python:3.13 or with version you set in PYTHON_SINGLE_TARGET and PYTHON_TARGETS.

[Maitreya]

The package dev-lang/python:3.14 is marked stable but python_targets_python3.14 and python_single_target_python3.14 use flag no.
So emerge command still working with python:3.13 or with version you set in PYTHON_SINGLE_TARGET and PYTHON_TARGETS.

That's what I used to think too, or at least, since the dissappearance of `eselect python` it seemed that PYTHON_SINGLE_TARGET is also the version portage uses.

But whether if I have it in my profile or hardcoded in my make.conf, it just seems to ignore me! (its probably me doing something wronG)

PYTHON_TARGETS="python3_12 python3_13 python3_14"
PYTHON_SINGLE_TARGET="python3_13"

But still it just goes ahead and uses 3.14 anyway (binpkg for portage disabled explicitly too):

Code: Select all

>>> Emerging (1 of 1) sys-apps/portage-3.0.75::gentoo
>>> Installing (1 of 1) sys-apps/portage-3.0.75::gentoo
>>> Completed (1 of 1) sys-apps/portage-3.0.75::gentoo
 * IMPORTANT: 19 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.
>>> Verifying ebuild manifests
 * IMPORTANT: 19 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.
>>> Running pre-merge checks for acct-group/stapdev-0-r2
HTTP request sent, awaiting response... 200 OK
Length: 20480 (20K) [application/x-tar]
Saving to: ‘/var/cache/binpkgs/acct-group/stapdev/stapdev-0-r2-1.gpkg.tar.partial’
     0K .......... ..........                                 100% 80.0M=0s
2026-01-15 09:22:23 (80.0 MB/s) - ‘/var/cache/binpkgs/acct-group/stapdev/stapdev-0-r2-1.gpkg.tar.partial’ saved [20480/20480]
>>> Failed to emerge acct-group/stapdev-0-r2
>>> Running pre-merge checks for acct-group/stapsys-0-r2
HTTP request sent, awaiting response... 200 OK
Length: 20480 (20K) [application/x-tar]
Saving to: ‘/var/cache/binpkgs/acct-group/stapsys/stapsys-0-r2-1.gpkg.tar.partial’
     0K .......... ..........                                 100% 44.0M=0s
2026-01-15 09:22:23 (44.0 MB/s) - ‘/var/cache/binpkgs/acct-group/stapsys/stapsys-0-r2-1.gpkg.tar.partial’ saved [20480/20480]
>>> Failed to emerge acct-group/stapsys-0-r2
>>> Running pre-merge checks for acct-group/stapusr-0-r2
>>> Running pre-merge checks for sys-apps/pciutils-3.14.0
HTTP request sent, awaiting response... 200 OK
Length: 225280 (220K) [application/x-tar]
Saving to: ‘/var/cache/binpkgs/sys-apps/pciutils/pciutils-3.14.0-1.gpkg.tar.partial’
     0K .......... .......... .......... .......... .......... 22% 4.08M 0s
    50K .......... .......... .......... .......... .......... 45% 3.96M 0s
   100K .......... .......... .......... .......... .......... 68% 65.1M 0s
   150K .......... .......... .......... .......... .......... 90% 4.74M 0s
   200K .......... ..........                                 100% 27.7M=0.04s
2026-01-15 09:22:25 (5.96 MB/s) - ‘/var/cache/binpkgs/sys-apps/pciutils/pciutils-3.14.0-1.gpkg.tar.partial’ saved [225280/225280]
>>> Failed to emerge sys-apps/pciutils-3.14.0
 * 
 * The following 3 packages have failed to build, install, or execute
 * postinst:
 * 
 *  (acct-group/stapdev-0-r2-1:0/0::gentoo, binary scheduled for merge)
 *  (acct-group/stapsys-0-r2-1:0/0::gentoo, binary scheduled for merge)
 *  (sys-apps/pciutils-3.14.0-1:0/0::gentoo, binary scheduled for merge)
 * 
Exception ignored while closing generator <coroutine object BinpkgFetcher._main at 0x7f734bf5f9c0>:
Traceback (most recent call last):
  File "/usr/lib/python3.14/site-packages/_emerge/BinpkgFetcher.py", line 130, in _main
    await fetcher.async_unlock()
  File "/usr/lib/python3.14/site-packages/_emerge/BinpkgFetcher.py", line 306, in async_unlock
    result = self._lock_obj.async_unlock()
  File "/usr/lib/python3.14/site-packages/_emerge/AsynchronousLock.py", line 93, in async_unlock
    self.scheduler.call_soon(unlock_future.set_result, None)
  File "/usr/lib/python3.14/asyncio/base_events.py", line 827, in call_soon
    self._check_closed()
  File "/usr/lib/python3.14/asyncio/base_events.py", line 550, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
[ERROR] Task was destroyed but it is pending!
task: <Task cancelling name='Task-591' coro=<BinpkgFetcher._main() done, defined at /usr/lib/python3.14/site-packages/_emerge/BinpkgFetcher.py:54> wait_for=<Future cancelled> cb=[AsyncTaskFuture._done_callback()]>
[ERROR] Task was destroyed but it is pending!
task: <Task pending name='Task-593' coro=<PipeLogger._io_loop() done, defined at /usr/lib/python3.14/site-packages/portage/util/_async/PipeLogger.py:83> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[PipeLogger._io_loop_done()]>
[ERROR] Task was destroyed but it is pending!
task: <Task cancelling name='Task-594' coro=<BuildLogger._main() done, defined at /usr/lib/python3.14/site-packages/portage/util/_async/BuildLogger.py:131> wait_for=<Future cancelled> cb=[BuildLogger._main_exit()]>
[ERROR] Task was destroyed but it is pending!
task: <Task pending name='Task-595' coro=<PipeLogger._io_loop() done, defined at /usr/lib/python3.14/site-packages/portage/util/_async/PipeLogger.py:83> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[PipeLogger._io_loop_done()]>
[ERROR] Task was destroyed but it is pending!
task: <Task pending name='Task-596' coro=<SpawnProcess._main() done, defined at /usr/lib/python3.14/site-packages/_emerge/SpawnProcess.py:193> wait_for=<Future pending cb=[AsynchronousTask.async_wait.<locals>.<lambda>() at /usr/lib/python3.14/site-packages/_emerge/AsynchronousTask.py:49, Task.task_wakeup()]> cb=[SpawnProcess._main_exit()]>
[ERROR] Task was destroyed but it is pending!
task: <Task pending name='Task-599' coro=<MultiprocessingProcess.wait() done, defined at /usr/lib/python3.14/site-packages/portage/process.py:439> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[SubProcess._async_waitpid_cb()]>
[ERROR] Task was destroyed but it is pending!
task: <Task pending name='Task-600' coro=<MultiprocessingProcess._proc_join() done, defined at /usr/lib/python3.14/site-packages/portage/process.py:459> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[MultiprocessingProcess._proc_join_done()]>
subprocess exited with status 1
subprocess exited with status 1

[sam_]

We generally try to un-stable-mask new Python targets as soon as we can after release because it facilitates more testing and contributions for packages to support Python 3.14. Python 3.14 (or any new impl) only gets added to PYTHON_COMPAT in an ebuild once it is tested with it.

A new Python target is truly ready to use when it's the default. You are free and encouraged to set it beforehand if you want to help or are keen etc but I would not be surprised by the occasional bump either.

Your original post didn't include the problem but I saw it on mobile and had a guess for what it was, and sure enough your followup does have what I expected. A change in Python 3.14.2 (it worked with earlier versions) broke Portage, see bug 967199. Newer versions of Python 3.14 are currently masked to allow time for that fix to propagate.

As for PYTHON_TARGETS vs PYTHON_SINGLE_TARGET, PYTHON_SINGLE_TARGET only influence ebuilds using python-single-r1 directly or indirectly, it doesn't affect the interpreter choice for PYTHON_TARGETS ebuilds (multiple impls enabled) like Portage if you've configured that.

[Maitreya]

We generally try to un-stable-mask new Python targets as soon as we can after release because it facilitates more testing and contributions for packages to support Python 3.14. Python 3.14 (or any new impl) only gets added to PYTHON_COMPAT in an ebuild once it is tested with it.

A new Python target is truly ready to use when it's the default. You are free and encouraged to set it beforehand if you want to help or are keen etc but I would not be surprised by the occasional bump either.

Your original post didn't include the problem but I saw it on mobile and had a guess for what it was, and sure enough your followup does have what I expected. A change in Python 3.14.2 (it worked with earlier versions) broke Portage, see bug 967199. Newer versions of Python 3.14 are currently masked to allow time for that fix to propagate.

As for PYTHON_TARGETS vs PYTHON_SINGLE_TARGET, PYTHON_SINGLE_TARGET only influence ebuilds using python-single-r1 directly or indirectly, it doesn't affect the interpreter choice for PYTHON_TARGETS ebuilds (multiple impls enabled) like Portage if you've configured that.

Ah thank you, so it's a known issue.
Sorry for not checking bugzilla first, sort of assumed some configuration/missed news update on my end.

Also thank you for explaining PYTHON_* effects

I'll mask >=3.14.2 locally as well then (it's in CI so the portage I use there doesn't get a "emerge --sync" as that doesnt seem idiosyncratic for that layer) and watch the progress on that bug!

[sam_]

No problem.

The bug is fixed, both in Portage (and in stable Portage too as I backported it), and that Python version is masked in ::gentoo for a bit longer to allow people time to update Portage, but of course this is no good if you already have 3.14.2 and a bad Portage. It's unfortunate but not many people will have enabled 3.14 yet so hopefully not so bad.

If you have a broken Portage (and obviously cannot use emerge to downgrade Python or upgrade Portage), please see the workaround / fix I mention in https://bugs.gentoo.org/967199#c28

I did consider a news item (and still am) but the thing is, you would have be so careful with the phrasing because it doesn't affect most users at all, and it'll end up confusing those who don't need to do anything.

[grknight]

But still it just goes ahead and uses 3.14 anyway (binpkg for portage disabled explicitly too):

IIRC, if a command is misbehaving with a certain python slot, you can set the EPYTHON environment variable to force a single run so long as it was enabled at install time.
e.g.: EPYTHON=python3.13 emerge ...

[sam_]

Yes, very good point, and the user indeed mentions having multiple PYTHON_TARGETS.

[freke]

IIRC I recovered by simply using

Code: Select all

/usr/lib/python-exec/python3.13/emerge -va1 portage

[EDIT]esentially the same as this I guess...

But still it just goes ahead and uses 3.14 anyway (binpkg for portage disabled explicitly too):

IIRC, if a command is misbehaving with a certain python slot, you can set the EPYTHON environment variable to force a single run so long as it was enabled at install time.
e.g.: EPYTHON=python3.13 emerge ...