Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On 12/30/20 9:35 AM, Arve Barsnes wrote: On Wed, 30 Dec 2020 at 08:46, n952162 wrote: Well, yes, the current version, indeed requires python3_8. The version that was installed on my system, however, to be updated, listed python3_7 in the PYTHON_TARGETS section. That was the only difference between the two packages in the collision. It apparently disqualified the update with a slot conflict. I tried walking you through the massive output from portage on one of these conflicts last week, was it helpful? The point either way, was that the slot conflict is not setuptools itself, but further down the dependency chain, where some package is unable to update to python 3.8, and it's dragging its dependencies back with it. Regards, Arve I spent hours studying your analysis, and then I thought it was a simple transitive-closure problem. I wrote a script that would take an emerge log and turn it into vectors and do a TC on those, but it didn't work. For one thing, I got tangled up in the issue of whether the "scheduled for merge" or the "installed" section was relevant. Then I noticed that in most (but not all) cases, the problem centered around a single package that had multiple, slightly different (mostly in the PYTHON_TARGETS variable) specs. At first, I thought that there was always just one such conflict package, all the other having a single new depender, rather than multiple. But I think now, that was a red herring. In your analysis, I didn't see that you made a distinction between "scheduled for emerge" and "installed" dependers. When using all potential dependers, I just wasn't able to following any chain to a useful conclusion. Perhaps it's there and just requires more thought. Anyway, my blanket --depclean kind of put a stop to that direction.
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On Wednesday, 30 December 2020 07:22:34 GMT n952162 wrote: > On 12/30/20 1:05 AM, Michael wrote: > > On Tuesday, 29 December 2020 22:55:03 GMT Neil Bothwick wrote: > >> On Tue, 29 Dec 2020 23:16:11 +0100, n952162 wrote: > So, I tried to do an emerge on @system. I got another slot conflict! > This time for mako, which I'd seen go by sometimes as a "package of > interest". It's only transgression: PYTHON_TARGET containing > python3_7. > >>> > >>> Note that both the "scheduled for merge" depender and the "installed" > >>> depender both required the same version of mako, 1.1.1-r1. The only > >>> difference is the fact that one requirements specification has > >>> python3-7, the other python3-8. The same pkg, the same binaries. > >>> Something is wrong here. Why is it not good enough to specify python3? > >> > >> PYTHON_TARGET determines for which version(s) of Python a package > >> installs its modules. The modules may be identical, but 3.7 and 3.8 have > >> different search paths, e.g. /usr/lib/python3.7/site-packages vs. > >> /usr/lib/python3.8/site-packages. > >> > >> It is possible you have some old python_targets settings in package.use, > >> that's where I would check first. > > > > As discussed recently, removing any manually configured python targets and > > letting portage work its magic, rather than fighting against it, is > > usually a sound way to get out of such a muddle. > > I don't understand what manually configured python targets are. There > are, in general, no python specifiers on my system in > /etc/portage/package.use or make.conf. Do you mean somewhere else? I mean: '/etc/portage/package.use' and any files if it is a directory, or under any subdirectories therein. '/etc/portage/make.conf' Any files referred to in /etc/portage/env/ or /etc/portage/package.env if you have configured any package specific emerge parameters there yourself. Any python related entries in /var/lib/portage/world. Run 'eselect python list' as well as 'cleanup' & 'update' to make sure there are no old version symlinks hanging on. If there is some deep dependency indicated by the output of emerge still asking for an old(er) python version, which portage will not resolve itself, then quickpkg it, uninstall it and re-run emerge. The above ought to get a stable portage able to update itself into a clean state. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On Wed, 30 Dec 2020 at 08:46, n952162 wrote: > Well, yes, the current version, indeed requires python3_8. The version > that was installed on my system, however, to be updated, listed > python3_7 in the PYTHON_TARGETS section. That was the only difference > between the two packages in the collision. It apparently disqualified > the update with a slot conflict. I tried walking you through the massive output from portage on one of these conflicts last week, was it helpful? The point either way, was that the slot conflict is not setuptools itself, but further down the dependency chain, where some package is unable to update to python 3.8, and it's dragging its dependencies back with it. Regards, Arve
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On 12/30/20 1:05 AM, Michael wrote: On Tuesday, 29 December 2020 22:55:03 GMT Neil Bothwick wrote: On Tue, 29 Dec 2020 23:16:11 +0100, n952162 wrote: So, I tried to do an emerge on @system. I got another slot conflict! This time for mako, which I'd seen go by sometimes as a "package of interest". It's only transgression: PYTHON_TARGET containing python3_7. Note that both the "scheduled for merge" depender and the "installed" depender both required the same version of mako, 1.1.1-r1. The only difference is the fact that one requirements specification has python3-7, the other python3-8. The same pkg, the same binaries. Something is wrong here. Why is it not good enough to specify python3? PYTHON_TARGET determines for which version(s) of Python a package installs its modules. The modules may be identical, but 3.7 and 3.8 have different search paths, e.g. /usr/lib/python3.7/site-packages vs. /usr/lib/python3.8/site-packages. It is possible you have some old python_targets settings in package.use, that's where I would check first. As discussed recently, removing any manually configured python targets and letting portage work its magic, rather than fighting against it, is usually a sound way to get out of such a muddle. I sync'ed portage a few hours ago today. Neither mako, nor setuptools require anything other than python3_8 on this system: $ eix -l setuptools [I] dev-python/setuptools Available versions: 46.4.0-r3 ^t [test PYTHON_TARGETS="pypy3 python2_7 python3_6 python3_7 python3_8 python3_9"] ["|| ( python_targets_pypy3 python_targets_python2_7 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] 50.3.0^t [test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"]["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] ~51.0.0^t [test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"]["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] ~51.1.0^t [test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"]["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] Installed versions: 50.3.0^t(12:47:38 05/12/20)(-test PYTHON_TARGETS="python3_8 -pypy3 -python3_6 -python3_7 -python3_9") Homepage:https://github.com/pypa/setuptools https://pypi.org/ project/setuptools/ Description: Collection of extensions to Distutils $ eix -l mako [I] dev-python/mako Available versions: 1.1.3-r1 ^t [doc test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"]["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] Installed versions: 1.1.3-r1^t(13:09:34 05/12/20)(-doc -test PYTHON_TARGETS="python3_8 -pypy3 -python3_6 -python3_7 -python3_9") Homepage:https://www.makotemplates.org/ https://pypi.org/ project/Mako/ Description: A Python templating language ... Well, yes, the current version, indeed requires python3_8. The version that was installed on my system, however, to be updated, listed python3_7 in the PYTHON_TARGETS section. That was the only difference between the two packages in the collision. It apparently disqualified the update with a slot conflict.
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On 12/30/20 1:05 AM, Michael wrote: On Tuesday, 29 December 2020 22:55:03 GMT Neil Bothwick wrote: On Tue, 29 Dec 2020 23:16:11 +0100, n952162 wrote: So, I tried to do an emerge on @system. I got another slot conflict! This time for mako, which I'd seen go by sometimes as a "package of interest". It's only transgression: PYTHON_TARGET containing python3_7. Note that both the "scheduled for merge" depender and the "installed" depender both required the same version of mako, 1.1.1-r1. The only difference is the fact that one requirements specification has python3-7, the other python3-8. The same pkg, the same binaries. Something is wrong here. Why is it not good enough to specify python3? PYTHON_TARGET determines for which version(s) of Python a package installs its modules. The modules may be identical, but 3.7 and 3.8 have different search paths, e.g. /usr/lib/python3.7/site-packages vs. /usr/lib/python3.8/site-packages. It is possible you have some old python_targets settings in package.use, that's where I would check first. As discussed recently, removing any manually configured python targets and letting portage work its magic, rather than fighting against it, is usually a sound way to get out of such a muddle. I don't understand what manually configured python targets are. There are, in general, no python specifiers on my system in /etc/portage/package.use or make.conf. Do you mean somewhere else?
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On 12/30/20 1:21 AM, Dale wrote: Michael wrote: I expect in a few weeks the tree will settle on python3_9, so all this rinse and repeat exercise with all the python updates should hopefully go quiet. :-) It may not be a bad idea for the OP to sync again and see if that helps. It's rare but in the past I've caught the tree in a state where things were not quite right. Someone is making changes but not all the needed changes made it at the same time. Sometimes even a few minutes can make a difference. I've re-synced in the past and it can help get past some roadblocks. It's not a sure thing but it may be worth a try. Dale :-) :-) I've synced copiously. I last synced on 27.12. After doing the emerge @system on the stripped out system of 103 packages last night, a new sync and emerge @system this morning yielded an update of 34 packages.
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
Michael wrote: > > I expect in a few weeks the tree will settle on python3_9, so all this rinse > and repeat exercise with all the python updates should hopefully go quiet. :-) It may not be a bad idea for the OP to sync again and see if that helps. It's rare but in the past I've caught the tree in a state where things were not quite right. Someone is making changes but not all the needed changes made it at the same time. Sometimes even a few minutes can make a difference. I've re-synced in the past and it can help get past some roadblocks. It's not a sure thing but it may be worth a try. Dale :-) :-)
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On Tuesday, 29 December 2020 22:55:03 GMT Neil Bothwick wrote: > On Tue, 29 Dec 2020 23:16:11 +0100, n952162 wrote: > > > So, I tried to do an emerge on @system. I got another slot conflict! > > > This time for mako, which I'd seen go by sometimes as a "package of > > > interest". It's only transgression: PYTHON_TARGET containing > > > python3_7. > > > > Note that both the "scheduled for merge" depender and the "installed" > > depender both required the same version of mako, 1.1.1-r1. The only > > difference is the fact that one requirements specification has > > python3-7, the other python3-8. The same pkg, the same binaries. > > Something is wrong here. Why is it not good enough to specify python3? > > PYTHON_TARGET determines for which version(s) of Python a package > installs its modules. The modules may be identical, but 3.7 and 3.8 have > different search paths, e.g. /usr/lib/python3.7/site-packages vs. > /usr/lib/python3.8/site-packages. > > It is possible you have some old python_targets settings in package.use, > that's where I would check first. As discussed recently, removing any manually configured python targets and letting portage work its magic, rather than fighting against it, is usually a sound way to get out of such a muddle. I sync'ed portage a few hours ago today. Neither mako, nor setuptools require anything other than python3_8 on this system: $ eix -l setuptools [I] dev-python/setuptools Available versions: 46.4.0-r3 ^t[test PYTHON_TARGETS="pypy3 python2_7 python3_6 python3_7 python3_8 python3_9"] ["|| ( python_targets_pypy3 python_targets_python2_7 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] 50.3.0^t[test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"] ["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] ~51.0.0^t[test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"] ["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] ~51.1.0^t[test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"] ["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] Installed versions: 50.3.0^t(12:47:38 05/12/20)(-test PYTHON_TARGETS="python3_8 -pypy3 -python3_6 -python3_7 -python3_9") Homepage:https://github.com/pypa/setuptools https://pypi.org/ project/setuptools/ Description: Collection of extensions to Distutils $ eix -l mako [I] dev-python/mako Available versions: 1.1.3-r1 ^t[doc test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"] ["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] Installed versions: 1.1.3-r1^t(13:09:34 05/12/20)(-doc -test PYTHON_TARGETS="python3_8 -pypy3 -python3_6 -python3_7 -python3_9") Homepage:https://www.makotemplates.org/ https://pypi.org/ project/Mako/ Description: A Python templating language I expect in a few weeks the tree will settle on python3_9, so all this rinse and repeat exercise with all the python updates should hopefully go quiet. :-) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On Tue, 29 Dec 2020 23:16:11 +0100, n952162 wrote: > > So, I tried to do an emerge on @system. I got another slot conflict! > > This time for mako, which I'd seen go by sometimes as a "package of > > interest". It's only transgression: PYTHON_TARGET containing > > python3_7. > Note that both the "scheduled for merge" depender and the "installed" > depender both required the same version of mako, 1.1.1-r1. The only > difference is the fact that one requirements specification has > python3-7, the other python3-8. The same pkg, the same binaries. > Something is wrong here. Why is it not good enough to specify python3? PYTHON_TARGET determines for which version(s) of Python a package installs its modules. The modules may be identical, but 3.7 and 3.8 have different search paths, e.g. /usr/lib/python3.7/site-packages vs. /usr/lib/python3.8/site-packages. It is possible you have some old python_targets settings in package.use, that's where I would check first. -- Neil Bothwick Growing old is mandatory; growing up is optional!! pgpxiyNnvqiKr.pgp Description: OpenPGP digital signature
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
n952162 wrote: > On 12/29/20 11:07 PM, n952162 wrote: >> >> >> So, I tried to do an emerge on @system. I got another slot conflict! >> This time for mako, which I'd seen go by sometimes as a "package of >> interest". It's only transgression: PYTHON_TARGET containing python3_7. >> >> > > Note that both the "scheduled for merge" depender and the "installed" > depender both required the same version of mako, 1.1.1-r1. The only > difference is the fact that one requirements specification has > python3-7, the other python3-8. The same pkg, the same binaries. > Something is wrong here. Why is it not good enough to specify python3? > > > > All I can say is there is a reason for it. It seems there is significant changes between 3.7, 3.8 and 3.9 that causes compatibility issues, which is why each is slotted I guess. There is a comment on this bug that may explain it better. https://bugs.gentoo.org/762406#c1 It should go to the comment but if it doesn't, it's the first actual comment by Michał Górny. There's also a thread on -dev about this but it is short and likely won't explain much. Dale :-) :-)
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On 12/29/20 11:07 PM, n952162 wrote: So, I tried to do an emerge on @system. I got another slot conflict! This time for mako, which I'd seen go by sometimes as a "package of interest". It's only transgression: PYTHON_TARGET containing python3_7. Note that both the "scheduled for merge" depender and the "installed" depender both required the same version of mako, 1.1.1-r1. The only difference is the fact that one requirements specification has python3-7, the other python3-8. The same pkg, the same binaries. Something is wrong here. Why is it not good enough to specify python3?
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On 12/3/20 9:33 PM, n952162 wrote: I'm trying to update the gentoo system that I last updated 6 weeks ago, but it seems not to work. Can somebody explain to me why? I tried and tried to figure out how I could determine what the fatal slot conflict would be. No matter how I mixed things, setuptools came up fighting about these things: - certifi - setuptools - jinja - markupsafe - libxml2 All the requirements were essentially equivalent, the only problem is that all had PYTHON_TARGETS with PYTHON3_8, while setuptools also had 3_6 and 3_7. I was not able to learn how to force PYTHON_TARGETS, also not by modifying the ebuild. Out of desperation or carelessness, I did a --depclean on the contents of the world file. 179 packages were removed, including sudo and my window manager. 106 packages were left. At least, I could still execute emerge. So, I tried to do an emerge on @system. I got another slot conflict! This time for mako, which I'd seen go by sometimes as a "package of interest". It's only transgression: PYTHON_TARGET containing python3_7. BUT! Finally, I could emerge mako. Along with it are coming 50 other packages! I presume that tomorrow, I'll be able to do a full @system and @world update and then re-install my old world file.
