Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 933489 - sys-block/targetcli-fb needs python3.12 support
Summary: sys-block/targetcli-fb needs python3.12 support
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal blocker (vote)
Assignee: No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 921826
  Show dependency tree
 
Reported: 2024-06-03 19:38 UTC by demo
Modified: 2024-06-06 06:47 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description demo 2024-06-03 19:38:15 UTC
After following the instructions to upgrade the current working profile to 23.0, rebuilding the system doesn't work and I get this output:

!!! The ebuild selected to satisfy "sys-block/targetcli-fb" has unmet requirements.
- sys-block/targetcli-fb-2.1.54::gentoo USE="" ABI_X86="(64)" PYTHON_TARGETS="-python3_10 -python3_11"

The following REQUIRED_USE flag constraints are unsatisfied:
any-of ( python_targets_python3_10 python_targets_python3_11 )

(dependency required by "sys-libs/libblockdev-3.1.1::gentoo[test]" [ebuild])
(dependency required by "sys-fs/udisks-2.10.1::gentoo" [installed])
(dependency required by "sys-apps/gnome-disk-utility-45.1::gentoo" [installed])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])

Please consider providing the python-12 compatible source for this package asap!

Reproducible: Always

Steps to Reproduce:
1. emerge -DNuva @world
2. emerge --ask --emptytree @world
3. 
Actual Results:  
emerge doesn't work at all!

Expected Results:  
A full list of software to be rebuilt and to proceed with the rebuild normally.
Comment 1 Alfred Wingate 2024-06-03 19:43:15 UTC
This is unrelated to the profile update https://www.gentoo.org/support/news-items/2024-05-09-python3-12.html
Comment 2 demo 2024-06-03 19:46:04 UTC
(In reply to Alfred Wingate from comment #1)
> This is unrelated to the profile update
> https://www.gentoo.org/support/news-items/2024-05-09-python3-12.html

The issue only appeared after the profile upgrade. Unfortunately I cannot revert back to the old profile in order to double check, to avoid further system corruption.

Before the profile switch I used to run "emerge -DNuva @installed" without any issues whatsoever, so the profile upgrade is the only suspect I have in mind!
Comment 3 Alfred Wingate 2024-06-03 19:48:43 UTC
I recommend that you defer the python upgrade as stated in the news item. That should give you better time getting the profile upgrade done. Then you can do this later.

This is just bad timing, but ill look at targetcli-fb. Ill see if I can get away with a python3.12 in stable or if it needs fixes from a newer version.
Comment 4 Alfred Wingate 2024-06-03 20:00:35 UTC
https://github.com/gentoo/gentoo/pull/37008 Should be merged at some point. In the meantime you should disable the test useflag for libblockdev or to defer the python target update.
Comment 5 demo 2024-06-03 20:15:58 UTC
(In reply to Alfred Wingate from comment #4)
> https://github.com/gentoo/gentoo/pull/37008 Should be merged at some point.
> In the meantime you should disable the test useflag for libblockdev or to
> defer the python target update.

Disabling the "test" use flag for the libblockdev doesn't really do the trick, as many other dev-python/* packages want in into "python_targets_python3_11".

I didn't actually do a profile upgrade to python-12 "intentionally", this system is only a month old or a little bit less, and I believe it was just installed with the transition already done. Reverting back to python-11 is going to be a tough choice given the number of python packages on the system, and the fact that at some point I'll need to un-revert.

The reason behind me asking for upgrade of the package source is that my machine is a bit slow, so I don't really enjoy having 900 packages or so being built/rebuilt within a couple of hours like the rest of people, instead it may take me a day, most probably more.

I guess I'll just hold on for a few more days before trying to do further updates or reinstalls.
Comment 6 Eli Schwartz gentoo-dev 2024-06-03 23:34:22 UTC
(In reply to demo from comment #5)
> The reason behind me asking for upgrade of the package source is that my
> machine is a bit slow, so I don't really enjoy having 900 packages or so
> being built/rebuilt within a couple of hours like the rest of people,
> instead it may take me a day, most probably more.


You may also wish to take a look at https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html

For what it's worth: I *have* a machine that could compile all packages from source. I'm just morally opposed to doing so, and used binary distros until Gentoo released an official binhost. ;)

Compiling for the USE flags I use is quite enough for me, I don't need to rebuild the same bytes that a buildbot already built.

You could do the same, and it will probably do a *lot* to ease the load of packages you need to compile yourself.

Hope that helps! :)
Comment 7 demo 2024-06-04 10:41:38 UTC
(In reply to Eli Schwartz from comment #6)
> (In reply to demo from comment #5)
> > The reason behind me asking for upgrade of the package source is that my
> > machine is a bit slow, so I don't really enjoy having 900 packages or so
> > being built/rebuilt within a couple of hours like the rest of people,
> > instead it may take me a day, most probably more.
> 
> 
> You may also wish to take a look at
> https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html
> 
> For what it's worth: I *have* a machine that could compile all packages from
> source. I'm just morally opposed to doing so, and used binary distros until
> Gentoo released an official binhost. ;)
> 
> Compiling for the USE flags I use is quite enough for me, I don't need to
> rebuild the same bytes that a buildbot already built.
> 
> You could do the same, and it will probably do a *lot* to ease the load of
> packages you need to compile yourself.
> 
> Hope that helps! :)

It's a great thing that gentoo decided to provide prebuilt binaries, although I became less enthusiastic about the idea of prebuilt binaries for the GNU system, after a long experience with debian.

With me the issue however is that I use different optimizations to workaround the low speed of my machine. These include architecture tuning " -march=x86-64-v3 -mtune=skylake". And also some uncommonly used use flags to know which packages are more prone to failure like the "test" flag. These reasons make emerge skip on the public prebuilt binaries. I also have the debug flag " -gddb3" for many packages.

But thanks for the suggestion anyway!
Comment 8 Larry the Git Cow gentoo-dev 2024-06-06 06:47:45 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fdc894745b60906ea37321d046c2cceb72673674

commit fdc894745b60906ea37321d046c2cceb72673674
Author:     Alfred Wingate <parona@protonmail.com>
AuthorDate: 2024-06-03 19:57:15 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2024-06-06 06:44:35 +0000

    sys-block/targetcli-fb: enable py3.12
    
    Closes: https://bugs.gentoo.org/933489
    Signed-off-by: Alfred Wingate <parona@protonmail.com>
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-block/targetcli-fb/targetcli-fb-2.1.54.ebuild | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)