hplip still has PYTHON_COMPAT=( python3_{10,11} ) which causes emerge to fail if PYTHON_SINGLE_TARGET is set to 3_12. Default python will switch to python 3.12 on Jun 1st, so please make the ebuild support 3.12 asap.
FWIW as a another user with hplip now being the only thing on my system without 3.12 support... hplip depends (with USE=snmp set) on net-analyzer/net-snmp, which seems to fairly consistently be near the last to get new-python support (that's what hplip was waiting on for 3.11 support, for instance)... which means hplip is too. =:^( If you have hplip installed with USE=-snmp you can try putting hplip in your overlay and bumping the dep yourself. I've done this on previous python bumps without issue and am in the middle of an upgrade trying it for 3.12 now (it built/merged fine but unknown if it will it run properly after I finish upgrading everything else and reboot), as my second-to-last 3.11-only package finally got 3.12 support on my last sync leaving only hplip which I suspect will work with my overlay bump. We'll see. Tho unlike previous times I'm on qt6 now and I'm running no-gui (USE=-qt5) for hplip as it's still qt5 only, which means if there are GUI-related issues I'm likely to miss them in any case...
Same again!
(In reply to Daniel Pielmeier from comment #2) > Same again! The package is effectively m-n. You should feel free to add py3.12 to it if it works.
(In reply to Sam James from comment #3) > (In reply to Daniel Pielmeier from comment #2) > > Same again! > > The package is effectively m-n. You should feel free to add py3.12 to it if > it works. Okay, will take a look at it in the next days.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7822cb2e578a179f0c3aa5d1d5d341ac356f9aa0 commit 7822cb2e578a179f0c3aa5d1d5d341ac356f9aa0 Author: David Seifert <soap@gentoo.org> AuthorDate: 2024-06-02 12:11:01 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2024-06-02 12:11:01 +0000 net-print/hplip: enable py3.12 Closes: https://bugs.gentoo.org/932150 Signed-off-by: David Seifert <soap@gentoo.org> net-print/hplip/hplip-3.23.12-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7de70acabd1b3bab62eba8af0ff5b315db31d934 commit 7de70acabd1b3bab62eba8af0ff5b315db31d934 Author: David Seifert <soap@gentoo.org> AuthorDate: 2024-06-02 16:30:43 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2024-06-02 16:30:43 +0000 net-print/hplip: drop py3.12 support * hplip depends on removed configparser.readfp() Bug: https://bugs.gentoo.org/932150 Reverts: 7822cb2 ("net-print/hplip: enable py3.12") Signed-off-by: David Seifert <soap@gentoo.org> net-print/hplip/hplip-3.23.12-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Is this configparser.readfp() in the base code of hplip or in optional code controlled by some USE flag? Can hplip switch between PYTHON_COMPAT 10..11 and 10..12 depending on USE flags? I have USE="minimal policykit static-ppds -X -doc -fax -hpcups -hpijs -kde -libnotify -libusb0 -parport -qt5 -scanner -snmp", so I'm using only a small fraction of hplip.
Created attachment 894962 [details, diff] Fix depracated use of configparser.readfp() As see here: https://github.com/python/cpython/blob/dd0e8a62df8be2a09ef6035b4c92bd9a68a7b918/Lib/configparser.py#L757-L764 Porting to non-deprecated(now removed) method is trivial.
corresponding fedora bug, with a slightly differnt fix: https://bugzilla.redhat.com/show_bug.cgi?id=2221311
*** Bug 933431 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=255c6af2ee1c67fd54d34f9b7ed15ea78f9ba917 commit 255c6af2ee1c67fd54d34f9b7ed15ea78f9ba917 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-06-03 12:32:19 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-06-03 12:32:22 +0000 net-print/hplip: try again w/ py3.12 (w/ patch) Bug: https://bugs.gentoo.org/932150 Thanks-to: David <david.guglielmi@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> net-print/hplip/files/hplip-3.23.12-py3.12.patch | 47 ++++ net-print/hplip/hplip-3.23.12-r2.ebuild | 297 +++++++++++++++++++++++ 2 files changed, 344 insertions(+)
scan/sane/hpaio.c:383:24: error: passing argument 1 of 'orblite_get_devices' from incompatible pointer type [-Wincompatible-pointer-types] 383 | orblite_get_devices(devList, localOnly); | ^~~~~~~ | | | SANE_Device *** This is with gcc 14.1.1_p20240518. Am I right this is not related to the python12 issue, in which case I can file a separate bug. (I looked and didn't see one.)
(In reply to Jack from comment #12) > scan/sane/hpaio.c:383:24: error: passing argument 1 of 'orblite_get_devices' > from incompatible pointer type [-Wincompatible-pointer-types] > 383 | orblite_get_devices(devList, localOnly); > | ^~~~~~~ > | | > | SANE_Device *** > > This is with gcc 14.1.1_p20240518. Am I right this is not related to the > python12 issue, in which case I can file a separate bug. (I looked and > didn't see one.) You could give it a try with stable gcc 13.2.1_p20240210 first. If it compiles without problems you are sure it is related to the gcc version.
Successful compile with gcc 13.2.1_p20240210 but not 14.1.1_p20240518. At least it looks like the conversion to python3.12 works. Filed https://bugs.gentoo.org/933485
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e4d300923046983e1179b90fb851fbb1e8ab60e5 commit e4d300923046983e1179b90fb851fbb1e8ab60e5 Author: Daniel Pielmeier <billie@gentoo.org> AuthorDate: 2024-06-03 20:28:23 +0000 Commit: Daniel Pielmeier <billie@gentoo.org> CommitDate: 2024-06-03 20:29:00 +0000 net-print/hplip: add 3.23.12-r3 Closes: https://bugs.gentoo.org/932150 Closes: https://bugs.gentoo.org/933485 Signed-off-by: Daniel Pielmeier <billie@gentoo.org> net-print/hplip/Manifest | 1 + net-print/hplip/hplip-3.23.12-r3.ebuild | 296 ++++++++++++++++++++++++++++++++ 2 files changed, 297 insertions(+)
The new revision with python-3.12 support is still not stable, should this really have been closed? This still block the python 3.12 update on stable amd64 for me.
(In reply to Daniel Nilsson from comment #16) > The new revision with python-3.12 support is still not stable, should this > really have been closed? This still block the python 3.12 update on stable > amd64 for me. I know it is not stable. Unmask it and test it. I think it can be stabilised quickly as the the patches added only fix build failures,
(In reply to Daniel Pielmeier from comment #17) > I know it is not stable. Unmask it and test it. I think it can be stabilised > quickly as the the patches added only fix build failures, (No worries, I like to run on stable if I can and just wanted to make sure it wasn't closed prematurely by accident. Thank you for you work on hplip in gentoo.) I have now tested net-print/hplip-3.23.12-r3 with python 3.11. Appears to work fine, I can print. I will do the python upgrade later when I have time, maybe tomorrow, and report back.
(In reply to Daniel Nilsson from comment #18) > (In reply to Daniel Pielmeier from comment #17) > > I know it is not stable. Unmask it and test it. I think it can be stabilised > > quickly as the the patches added only fix build failures, > > (No worries, I like to run on stable if I can and just wanted to make sure > it wasn't closed prematurely by accident. Thank you for you work on hplip in > gentoo.) Appreciated. Maintaining hplip is not a lot of fun. Support from HP is basically non existing. They say it is open source but that's it. I have given up on reporting bugs upstream a long time ago because nobody seems to care. > I have now tested net-print/hplip-3.23.12-r3 with python 3.11. Appears to > work fine, I can print. I will do the python upgrade later when I have time, > maybe tomorrow, and report back. Bug #933605 has already been opened so let's just start stabilising it. Please report any problems you find.
I have upgraded to python-3.12, no issues with hplip, printing still works. Thank you again!
