| Summary: | sys-block/targetcli-fb needs python3.12 support | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | demo <deyaa.saifeldin> |
| Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | deyaa.saifeldin, eschwartz, kingjon3377, paolo.pedroni, parona |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: | https://github.com/gentoo/gentoo/pull/37008 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 921826 | ||
|
Description
demo
2024-06-03 19:38:15 UTC
This is unrelated to the profile update https://www.gentoo.org/support/news-items/2024-05-09-python3-12.html (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! 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. 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. (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. (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! :) (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! 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(-) |
