Mailing List Archive

On Thu, 19 Nov 2020 at 22:36, Steven Lembark <lembark@wrkhors.com> wrote:
> PYTHON_TARGETS="python2_7 python3_7"
> PYTHON_SINGLE_TARGET="python3_7"

What does

emerge --info

say about your actual value for those variables?


> The depclean step gave me:
>
> * Have you forgotten to do a complete update prior to depclean? The
> * most comprehensive command for this purpose is as follows:
> *
> * emerge --update --newuse --deep --with-bdeps=y @world

And what happens if you run the command it suggests?

Regards,
Arve

On Fri, Nov 20, 2020 at 8:36 AM Steven Lembark <lembark@wrkhors.com> wrote:

>
> Based on:
>
> 2020-04-22 Python 3.7 to become the default target
>
> I'd have thought that using:
>
> PYTHON_TARGETS="python2_7 python3_7"
> PYTHON_SINGLE_TARGET="python3_7"
>
>
I would remove those entries and try again. As a Gnome ~amd64 user, python
2.7 was depcleaned on the 11th as the last dependency was removed.

>

On 2020.11.19 17:37, Adam Carter wrote:
> On Fri, Nov 20, 2020 at 8:36 AM Steven Lembark <lembark@wrkhors.com>
> wrote:
>
> >
> > Based on:
> >
> > 2020-04-22 Python 3.7 to become the default target
> >
> > I'd have thought that using:
> >
> > PYTHON_TARGETS="python2_7 python3_7"
> > PYTHON_SINGLE_TARGET="python3_7"
> >
> >
> I would remove those entries and try again. As a Gnome ~amd64 user,
> python
> 2.7 was depcleaned on the 11th as the last dependency was removed.
I don't think that's quite fully true - as it's still a build time
dependency for a small number of packages, chromium and qtwebengine
being somewhat notable examples. However, removing all explicity
python target flags is still a reasonable thing to try.

You've made the mistake of appearing knowlegable :-)

20 years I've been using Gentoo, I'm about to remove it because I
have not been able to maintain it since the whole python 2.7
deprecation process started.

Given my /usr/portage/package.accept_keywords is down to a
single line:

*/* ~amd64

At this point pretty much anything I try to update bumps into:



I have tried various combinations in package.use/local (i.e.,
separate from zz_autoconfig) of:

nada.

*/* PYTHON_TARGETS="-python2_7"
*/* PYTHON_SINGLE_TARGET="python3_6"

*/* PYTHON_TARGETS="-python2_7 python3_6"
*/* PYTHON_SINGLE_TARGET="python3_6"

followed by a combinatorial product of -python2_7 python3_{456789}
for the PYTHON_TARGETS and each of the alternatives as PYTHON_SINGLE_TARGET.

I've tried setting these in /etc/portage/make.conf also.

One oddity I notice is that emerge and eselect seem out of sync on
the version of python installed:

# eselect python list;
Available Python interpreters, in order of preference:
? [1] python3.7
? [2] python3.6
? [3] python2.7 (fallback)
root@steamer:package.use # emerge --search dev-lang/python;

[ Results for search key : dev-lang/python ]
Searching...

<snip>

* dev-lang/python
? Latest version available: 3.10.0_alpha4
? Latest version installed: 3.9.0_beta1
Size of files: 18,279 KiB
Homepage: https://www.python.org/
Description: An interpreted, interactive, object-oriented programming language
License: PSF-2




Q: If you have a working Gentoo system, what version of python do
you have installed? What does eselect show you? What are you
using for PYTHON_TARGETS & PYTHON_TARGETS?

Thank you.

--
Steven Lembark
Workhorse Computing
lembark@wrkhors.com
+1 888 359 3508

On Monday, 25 January 2021 18:04:26 GMT Steven Lembark wrote:
> You've made the mistake of appearing knowlegable :-)

Clearly this does not appear to me. I just bumble along trying not to break
things! :p


> 20 years I've been using Gentoo, I'm about to remove it because I
> have not been able to maintain it since the whole python 2.7
> deprecation process started.
>
> Given my /usr/portage/package.accept_keywords is down to a
> single line:
>
> */* ~amd64
>
> At this point pretty much anything I try to update bumps into:
>
>
>
> I have tried various combinations in package.use/local (i.e.,
> separate from zz_autoconfig) of:
>
> nada.
>
> */* PYTHON_TARGETS="-python2_7"
> */* PYTHON_SINGLE_TARGET="python3_6"
>
> */* PYTHON_TARGETS="-python2_7 python3_6"
> */* PYTHON_SINGLE_TARGET="python3_6"
>
> followed by a combinatorial product of -python2_7 python3_{456789}
> for the PYTHON_TARGETS and each of the alternatives as PYTHON_SINGLE_TARGET.
>
> I've tried setting these in /etc/portage/make.conf also.
>
> One oddity I notice is that emerge and eselect seem out of sync on
> the version of python installed:
>
> # eselect python list;
> Available Python interpreters, in order of preference:
> ? [1] python3.7
> ? [2] python3.6
> ? [3] python2.7 (fallback)
> root@steamer:package.use # emerge --search dev-lang/python;
>
> [ Results for search key : dev-lang/python ]
> Searching...
>
> <snip>
>
> * dev-lang/python
> ? Latest version available: 3.10.0_alpha4
> ? Latest version installed: 3.9.0_beta1
> Size of files: 18,279 KiB
> Homepage: https://www.python.org/
> Description: An interpreted, interactive, object-oriented
> programming language License: PSF-2
>
>
>
>
> Q: If you have a working Gentoo system, what version of python do
> you have installed? What does eselect show you? What are you
> using for PYTHON_TARGETS & PYTHON_TARGETS?
>
> Thank you.

I run stable systems, with only a few keyworded packages. This is what I have
installed here:

$ eix -l dev-lang/python
[I] dev-lang/python
Available versions:
(2.7)
2.7.18-r5 [.-berkdb bluetooth build examples gdbm hardened ipv6
libressl +ncurses +readline sqlite +ssl +threads tk +wide-unicode wininst +xml
ELIBC="uclibc"]
2.7.18-r6 [.-berkdb bluetooth build examples gdbm hardened ipv6
libressl +ncurses +readline sqlite +ssl +threads tk verify-sig +wide-unicode
wininst +xml ELIBC="uclibc"]
(3.6)
3.6.12-r1 (3.6/3.6m)^t [.bluetooth build examples gdbm hardened ipv6
libressl +ncurses +readline sqlite +ssl test +threads tk wininst +xml]
3.6.12-r2 (3.6/3.6m)^t [.bluetooth build examples gdbm hardened ipv6
libressl +ncurses +readline sqlite +ssl test +threads tk verify-sig wininst
+xml]
(3.7)
3.7.9-r1 (3.7/3.7m)^t [.bluetooth build examples gdbm hardened ipv6
libressl +ncurses +readline sqlite +ssl test tk wininst +xml]
3.7.9-r2 (3.7/3.7m)^t [.bluetooth build examples gdbm hardened ipv6
libressl +ncurses +readline sqlite +ssl test tk verify-sig wininst +xml]
(3.8)
3.8.6-r1 ^t [.bluetooth build examples gdbm hardened ipv6
libressl +ncurses +readline sqlite +ssl test tk wininst +xml]
3.8.7-r1 ^t [.bluetooth build examples gdbm hardened ipv6
libressl +ncurses +readline sqlite +ssl test tk verify-sig wininst +xml]
(3.9)
3.9.0-r1 ^t [.bluetooth build examples gdbm hardened ipv6
libressl +ncurses +readline sqlite +ssl test tk wininst +xml]
3.9.1-r1 ^t [.bluetooth build examples gdbm hardened ipv6
libressl +ncurses +readline sqlite +ssl test tk verify-sig wininst +xml]
(3.10)
~ 3.10.0_alpha3-r1 ^t [.bluetooth build examples gdbm hardened ipv6
libressl +ncurses +readline sqlite +ssl test tk wininst +xml]
~ 3.10.0_alpha4 ^t [.bluetooth build examples gdbm hardened ipv6
libressl +ncurses +readline sqlite +ssl test tk verify-sig wininst +xml]
Installed versions: 2.7.18-r6(2.7)(09:15:42 25/01/21)(bluetooth gdbm
ipv6 ncurses readline sqlite ssl threads wide-unicode xml -berkdb -build -
examples -hardened -libressl -tk -verify-sig -wininst ELIBC="-uclibc")
3.8.7-r1(3.8)^t(09:05:54 25/01/21)(bluetooth gdbm
ipv6 ncurses readline sqlite ssl xml -build -examples -hardened -libressl -
test -tk -verify-sig -wininst)
3.9.1-r1(3.9)^t(09:11:05 25/01/21)(bluetooth gdbm
ipv6 ncurses readline sqlite ssl xml -build -examples -hardened -libressl -
test -tk -verify-sig -wininst)
Homepage: https://www.python.org/
Description: An interpreted, interactive, object-oriented
programming language

[I] dev-lang/python-exec
Available versions:
(2)
2.4.6-r2 [PYTHON_TARGETS="pypy3 python2_7 python3_7 python3_8
python3_9"]
~ 2.4.6-r3 [+native-symlinks PYTHON_TARGETS="pypy3 python2_7
python3_7 python3_8 python3_9"]
~ 2.4.6-r4 [+native-symlinks PYTHON_TARGETS="pypy3 python2_7
python3_7 python3_8 python3_9"]
Installed versions: 2.4.6-r2(2)(11:45:49 16/01/21)(PYTHON_TARGETS="pypy3
python2_7 python3_7 python3_8 python3_9")
Homepage: https://github.com/mgorny/python-exec/
Description: Python script wrapper


These are the current versions:

$ eselect python list
Available Python interpreters, in order of preference:
[1] python3.9
[2] python3.8
[3] python2.7 (fallback)


I have not set up any targets manually - this is from 'emerge --info':

PYTHON_SINGLE_TARGET="python3_8" PYTHON_TARGETS="python2_7 python3_8"


Someone will hopefully drop in soon with ~amd64 to compare notes.

On Mon, 25 Jan 2021 13:04:26 -0500, Steven Lembark wrote:

> 20 years I've been using Gentoo, I'm about to remove it because I
> have not been able to maintain it since the whole python 2.7
> deprecation process started.
>
> Given my /usr/portage/package.accept_keywords is down to a
> single line:
>
> */* ~amd64

So you're basically running an ~arch system, why not set in in make.conf?

> At this point pretty much anything I try to update bumps into:

Bumps into what?

> I have tried various combinations in package.use/local (i.e.,
> separate from zz_autoconfig) of:
>
> nada.
>
> */* PYTHON_TARGETS="-python2_7"
> */* PYTHON_SINGLE_TARGET="python3_6"
>
> */* PYTHON_TARGETS="-python2_7 python3_6"
> */* PYTHON_SINGLE_TARGET="python3_6"
>
> followed by a combinatorial product of -python2_7 python3_{456789}
> for the PYTHON_TARGETS and each of the alternatives as
> PYTHON_SINGLE_TARGET.
>
> I've tried setting these in /etc/portage/make.conf also.

I have found that setting PYTHON*_TARGET manually is something to be
avoided unless absolutely necessary. I would remove all of these settings
and let portage manage it. Then run emerge -uavDN @world. You may need to
*temporarily* set PYTHON_TARGETS to get through this.

Most importantly, carefully go through any emerge errors, and the recent
discussions on this list, to find out the cause of any clashes. In most
cases, it is usually older versions of software having dependencies
involving python2.7 that is at the root.

> One oddity I notice is that emerge and eselect seem out of sync on
> the version of python installed:

Get these in line by running:

eselect python update
eselect python cleanup


> Q: If you have a working Gentoo system, what version of python do
> you have installed?

dev-lang/python-3.9.1-r1
dev-lang/python-3.8.7-r1
dev-lang/python-2.7.18-r6

> What does eselect show you?

Available Python interpreters, in order of preference:
[1] python3.8
[2] python2.7
[3] python3.9 (fallback)

> What are you
> using for PYTHON_TARGETS & PYTHON_TARGETS?

Portage defaults, nothing in /etc/portage

PYTHON_SINGLE_TARGET="python3_8"
PYTHON_TARGETS="python2_7 python3_8"


--
Neil Bothwick

Stop tagline theft! Copyright your tagline (c)

On Mon, 25 Jan 2021 19:01:36 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> On Mon, 25 Jan 2021 13:04:26 -0500, Steven Lembark wrote:
>
> > 20 years I've been using Gentoo, I'm about to remove it because I
> > have not been able to maintain it since the whole python 2.7
> > deprecation process started.
> >
> > Given my /usr/portage/package.accept_keywords is down to a
> > single line:
> >
> > */* ~amd64
>
> So you're basically running an ~arch system, why not set in in
> make.conf?

Because I'm not normally running an arch system. I am desparate
after months of being able to install or upgrade anything on this
machine. Runing ~amd64 was one of the straws I grasped at during
the process.

> > At this point pretty much anything I try to update bumps into:

Bumps into not having sys-apps/portage-9999::gentoo:

# $emerge dev-db/pgmodeler
Calculating dependencies... done!

!!! All ebuilds that could satisfy "sys-apps/portage[python_targets_python2_7(-),python_targets_python3_6(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-apps/portage-9999::gentoo (masked by: missing keyword)

(dependency required by "dev-java/java-config-2.2.0-r4::gentoo" [installed])
(dependency required by "sys-devel/gettext-0.20.2::gentoo" [installed])
(dependency required by "dev-perl/Locale-gettext-1.70.0::gentoo" [installed])
(dependency required by "sys-apps/help2man-1.47.16::gentoo[nls]" [installed])
(dependency required by "sys-devel/automake-1.16.3-r1::gentoo" [ebuild])
(dependency required by "sys-devel/libtool-2.4.6-r6::gentoo" [installed])
(dependency required by "sys-libs/zlib-1.2.11-r2::gentoo[minizip]" [installed])
(dependency required by "dev-lang/perl-5.30.3-r1::gentoo" [installed])
(dependency required by "sys-devel/autoconf-2.69-r5::gentoo" [installed])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.



--
Steven Lembark
Workhorse Computing
lembark@wrkhors.com
+1 888 359 3508

On 2/13/2021 2:41 PM, Steven Lembark wrote:

[snip]
> Bumps into not having sys-apps/portage-9999::gentoo:
> # $emerge dev-db/pgmodeler
> Calculating dependencies... done!
>
> !!! All ebuilds that could satisfy "sys-apps/portage[python_targets_python2_7(-),python_targets_python3_6(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]" have been masked.
> !!! One of the following masked packages is required to complete your request:
> - sys-apps/portage-9999::gentoo (masked by: missing keyword)

Portage-9999 is risky since it's VERY MUCH still developmental. BUT, if
you really want it, add this to your package.accept_keywords:
sys-apps/portage **

Include the two stars.  That will override missing keyword. It may be
better to specify a full token rather than a shortcut. In that case use:
=sys-apps/portage-9999 **

--

Dan Egli
On my test server

On 2/13/21 8:42 PM, Dan Egli wrote:
> On 2/13/2021 2:41 PM, Steven Lembark wrote:
>
> [snip]
>> Bumps into not having sys-apps/portage-9999::gentoo:
>> # $emerge dev-db/pgmodeler
>> Calculating dependencies... done!
>>
>> !!! All ebuilds that could satisfy
>> "sys-apps/portage[python_targets_python2_7(-),python_targets_python3_6(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]"
>> have been masked.
>> !!! One of the following masked packages is required to complete your
>> request:
>> - sys-apps/portage-9999::gentoo (masked by: missing keyword)
>
> Portage-9999 is risky since it's VERY MUCH still developmental. BUT, if
> you really want it, add this to your package.accept_keywords:
> sys-apps/portage **
>
> Include the two stars.  That will override missing keyword. It may be
> better to specify a full token rather than a shortcut. In that case use:
> =sys-apps/portage-9999 **
>
The portage-9999 suggestion seems like a red herring to me. More likely
the reason the portage ebuild does not satisfy the dependency is because
it is installed with different python_targets/python_single_target than
what the consuming package wants.

On 11/19/20 1:36 PM, Steven Lembark wrote:
>
> Based on:
>
> 2020-04-22 Python 3.7 to become the default target
>
> I'd have thought that using:
>
> PYTHON_TARGETS="python2_7 python3_7"
> PYTHON_SINGLE_TARGET="python3_7"
>
> and
>
> emerge --depclean;
> emerge -1vUD @world;
> emerge --depclean;
>
> should have updated my system. I'd done a fairly recent
> "emerge @world" and it completed so I'd have thought that
> everything was up to date.
>
> The depclean step gave me:
>
> * Have you forgotten to do a complete update prior to depclean? The
> * most comprehensive command for this purpose is as follows:
> *
> * emerge --update --newuse --deep --with-bdeps=y @world
>
>
> At this point pretty much anything I update runs into:
>
> !!! All ebuilds that could satisfy "sys-apps/portage[python_targets_python2_7(-),python_targets_python3_6(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]" have been masked.
> !!! One of the following masked packages is required to complete your request:
> - sys-apps/portage-9999::gentoo (masked by: missing keyword)
>
>
>
>
Did you run emerge --sync before emerge -1vUD @world?

The Python 3.7 change is old news -- by now it's already migrated to 3.8
on my system.

On Sat, 13 Feb 2021 16:41:59 -0500, Steven Lembark wrote:

> # $emerge dev-db/pgmodeler
> Calculating dependencies... done!
>
> !!! All ebuilds that could satisfy
> "sys-apps/portage[python_targets_python2_7(-),python_targets_python3_6(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]"
> have been masked. !!! One of the following masked packages is required
> to complete your request:
> - sys-apps/portage-9999::gentoo (masked by: missing keyword)
>
> (dependency required by "dev-java/java-config-2.2.0-r4::gentoo"

~java-config-2.2.0 isn't in the portage tree, the only version is 2.3.1.

> [installed]) (dependency required by "sys-devel/gettext-0.20.2::gentoo"

Also not in the tree.

I'd start by unmerging these two, quickpkg them first, and running a deep
world update.

> [installed]) (dependency required by
> "dev-perl/Locale-gettext-1.70.0::gentoo" [installed]) (dependency
> required by "sys-apps/help2man-1.47.16::gentoo[nls]" [installed])
> (dependency required by "sys-devel/automake-1.16.3-r1::gentoo"
> [ebuild]) (dependency required by "sys-devel/libtool-2.4.6-r6::gentoo"
> [installed]) (dependency required by
> "sys-libs/zlib-1.2.11-r2::gentoo[minizip]" [installed]) (dependency
> required by "dev-lang/perl-5.30.3-r1::gentoo" [installed]) (dependency
> required by "sys-devel/autoconf-2.69-r5::gentoo" [installed]) For more
> information, see the MASKED PACKAGES section in the emerge man page or
> refer to the Gentoo Handbook.


--
Neil Bothwick

OS/2: Obsolete Soon, Too

On Sat, 13 Feb 2021 21:42:12 -0700
Dan Egli <dan@newideatest.site> wrote:

> On 2/13/2021 2:41 PM, Steven Lembark wrote:
>
> [snip]
> > Bumps into not having sys-apps/portage-9999::gentoo:
> > # $emerge dev-db/pgmodeler
> > Calculating dependencies... done!
> >
> > !!! All ebuilds that could satisfy
> > "sys-apps/portage[python_targets_python2_7(-),python_targets_python3_6(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)]"
> > have been masked. !!! One of the following masked packages is
> > required to complete your request:
> > - sys-apps/portage-9999::gentoo (masked by: missing keyword)
>
> Portage-9999 is risky since it's VERY MUCH still developmental. BUT,
> if you really want it, add this to your package.accept_keywords:
> sys-apps/portage **


No. All I want is to get the regular portage working.
I have been following a variety of suggestiions since the system
stopped upgrading around the python 2-3 idiocy.


--
Steven Lembark
Workhorse Computing
lembark@wrkhors.com
+1 888 359 3508

On Sat, 13 Feb 2021 20:59:08 -0800
cal <cal@mail.meme.technology> wrote:

> Did you run emerge --sync before emerge -1vUD @world?

A cron job here runs "emerge --sync && emerge --update --fetchonly"
every day at 0300.

> The Python 3.7 change is old news -- by now it's already migrated to
> 3.8 on my system.

This system has been fried ever since

2020-04-22-python3-7
Title Python 3.7 to become the default target
Author Micha? Górny <mgorny@gentoo.org>
Posted 2020-04-22
Revision 1

On 2020-05-06 (or later), Python 3.7 will replace Python 3.6 as one
of the default Python targets for Gentoo systems. The new default
values will be:

Followed those instructions -- don't use python for anything here
and the local copies of what I actually use are in /opt/perl,
/opt/postgresql, etc, built from git checkouts.

At this point I've added and removed python single and multiple
target entries from make.conf & package.use/local, with various
sets of values and exclusions.

A bare sync tells me there is a new version of portage available,
installing it fails, however with:

# emerge --sync;

<snip>

Action: sync for repo: gentoo, returned code = 0

* An update to portage is available. It is _highly_ recommended
* that you update portage now, before any other packages are updated.

* To update portage, run 'emerge --oneshot sys-apps/portage' now.


# emerge --oneshot sys-apps/portage 2>&1 | tee a;

Calculating dependencies ....... done!
[ebuild N ] dev-lang/python-exec-conf-2.4.6 PYTHON_TARGETS="python3_8 -pypy3 -python3_7 -python3_9"
[ebuild N ] acct-group/portage-0
[ebuild U ] dev-lang/python-exec-2.4.6-r4 [2.4.6-r1] USE="native-symlinks%*" PYTHON_TARGETS="(python3_8%*) (python3_9%*)"
[ebuild N ] acct-user/portage-0
[ebuild U ] dev-python/certifi-10001-r1 [10001] PYTHON_TARGETS="python3_8*"
[ebuild U ~] dev-python/setuptools-53.0.0 [44.0.0] PYTHON_TARGETS="python3_8* -python3_9%"
[ebuild U ~] dev-python/setuptools_scm-5.0.1 [4.1.2] PYTHON_TARGETS="python3_8*"
[ebuild U ] dev-python/chardet-4.0.0 [3.0.4] PYTHON_TARGETS="python3_8* -python3_9%"
[ebuild U ] dev-python/idna-2.10-r1 [2.8] PYTHON_TARGETS="python3_8* -python3_9%"
[ebuild U ] dev-python/PySocks-1.7.1-r1 [1.6.8] PYTHON_TARGETS="python3_8* -python3_9%"
[ebuild U ~] dev-python/urllib3-1.26.3-r1 [1.24.2] USE="-brotli%" PYTHON_TARGETS="python3_8%* -python3_9%"
[ebuild U ] dev-python/requests-2.25.1-r1 [2.21.0-r1] USE="-test%" PYTHON_TARGETS="python3_8%* -python3_9%"
[ebuild U ~] app-crypt/gnupg-2.2.27 [2.2.20] USE="-scd-shared-access%"
[ebuild U ] app-portage/gemato-16.2 [14.3] PYTHON_TARGETS="python3_8* -python3_7* -python3_9%"
[ebuild U ~] sys-apps/portage-3.0.14 [3.0.1] USE="-test%" PYTHON_TARGETS="python3_8* -python3_7*"
[blocks B ] <=dev-lang/python-2.7.18-r3:2.7 ("<=dev-lang/python-2.7.18-r3:2.7" is blocking dev-lang/python-exec-2.4.6-r4)
[blocks B ] <dev-lang/python-exec-2.4.6-r4 ("<dev-lang/python-exec-2.4.6-r4" is blocking dev-lang/python-exec-conf-2.4.6)

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-lang/python-exec:2

(dev-lang/python-exec-2.4.6-r4:2/2::gentoo, ebuild scheduled for merge) USE="native-symlinks" ABI_X86="(64)" PYTHON_TARGETS="(pypy3) (python3_7) (python3_8) (python3_9)" pulled in by
>=dev-lang/python-exec-2:=[python_targets_pypy3(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (dev-python/chardet-4.0.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 -pypy3 -python3_7 -python3_9"

>=dev-lang/python-exec-2:=[python_targets_pypy3(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (dev-python/setuptools-53.0.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 python3_8 -pypy3 -python3_9"


Full output at:
<https://pastebin.com/mEJg3N7N>



Q: Is there any way to clean up python at this point without
a full re-install?

thanks

--
Steven Lembark
Workhorse Computing
lembark@wrkhors.com
+1 888 359 3508

Steven Lembark <lembark@wrkhors.com> wrote:
>
> # emerge --oneshot sys-apps/portage 2>&1 | tee a;
>
The output of this information is not very useful:
Unsurprisingly, it only shows that update of only the portage
dependencies collides with the dependencies of packages which
are not updated. You should instead try to make

emerge -NaDu --with-bdeps=y @world

succeed. But for a system which haa not been updated since
more than half a year, this can be difficult.

On Sun, 14 Feb 2021 17:26:03 -0000 (UTC)
Martin Vaeth <martin@mvath.de> wrote:

> emerge -NaDu --with-bdeps=y @world

Normally I use:

/usr/bin/emerge --deep --backtrack=128 --with-bdeps y \
--complete-graph y --autounmask-write --verbose-conflicts \
--jobs --load-average 4 --keep-going --update @world;

This gets me the same failures, with a bit more information.

The output of your command above is:

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

sys-libs/binutils-libs:0

(sys-libs/binutils-libs-2.35.1-r1:0/2.35.1::gentoo, ebuild scheduled for merge) USE="nls -64-bit-bfd (-cet) -multitarget -static-libs" ABI_X86="32 (64) (-x32)" pulled in by
(no parents that aren't satisfied by other packages in this slot)

(sys-libs/binutils-libs-2.34-r2:0/2.34::gentoo, installed) USE="nls -64-bit-bfd -multitarget -static-libs" ABI_X86="32 (64) (-x32)" pulled in by
sys-libs/binutils-libs:0/2.34=[abi_x86_32(-),abi_x86_64(-)] required by (x11-libs/cairo-1.16.0-r4:0/0::gentoo, installed) USE="X glib svg (-aqua) -debug (-gles2-only) -opengl -static-libs -utils -valgrind" ABI_X86="32 (64) (-x32)"
^^^^^^^^
<snip>


<https://pastebin.com/r7Qe4yUf>

Running it with a loop moving ._cfg000000_autoconfig and re-running
emerge eventually brick walls into the same result.


--
Steven Lembark
Workhorse Computing
lembark@wrkhors.com
+1 888 359 3508

Steven Lembark <lembark@wrkhors.com> wrote:
: sys-apps/sg3_utils:0
:
: (sys-apps/sg3_utils-1.44:0/0::gentoo, ebuild scheduled for merge) [...]
:
: (sys-apps/sg3_utils-1.42:0/0::gentoo, installed) [...]
: <sys-apps/sg3_utils-1.44 required by (sys-apps/rescan-scsi-bus [...]
^ ^^^^

This looks already like a first problem:
sys-apps/rescan-scsi-bus depends on <sys-apps/sg3_utils-1.44
which is not the latest stable version.
Either you should mask >=sys-apps/sg3_utils-1.44 or (permanently)
unmerge sys-apps/rescan-scsi-bus and whatever pulls it in as a
dependency.
Then perhaps the rest can be resolved better.
(If not, the next real conflict has to be found...)

On Sun, 14 Feb 2021 10:56:03 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> ~java-config-2.2.0 isn't in the portage tree, the only version is
> 2.3.1.
>
> > [installed]) (dependency required by
> > "sys-devel/gettext-0.20.2::gentoo"
>
> Also not in the tree.
>
> I'd start by unmerging these two, quickpkg them first, and running a
> deep world update.

# emerge --unmerge ~java-config-2.2.0
* This action can remove important packages! In order to be safer, use
* `emerge -pv --depclean <atom>` to check for reverse dependencies before
* removing packages.

dev-java/java-config
selected: 2.2.0-r4
<snip>

# emerge --unmerge ~sys-devel/gettext-0.20.2
* This action can remove important packages! In order to be safer, use
* `emerge -pv --depclean <atom>` to check for reverse dependencies before
* removing packages.

sys-devel/gettext
selected: 0.20.2
<snip>

OK, that seemed to work: picked a single version each time.

Checking java-config it's at 2.3.1 in the repository, trying
"emerge --pretend java-config" failes with a long list of conflicts,
most of which appear to include python versions.

Ditto sys-devel/gettext.

Attempting the world-merge:

# /usr/bin/emerge --deep --with-bdeps y --complete-graph y \
--autounmask-write --verbose-conflicts --jobs --load-average 4 \
--keep-going --update @world 2>&1 |
tee /tmp/b ;

* IMPORTANT: config file '/etc/portage/package.use/zz_autoconfigure' needs updating.

# git diff zz_autoconfigure ._cfg0000_zz_autoconfigure
diff --git a/zz_autoconfigure b/._cfg0000_zz_autoconfigure
index 22069a3..86e9b33 100644
--- a/zz_autoconfigure
+++ b/._cfg0000_zz_autoconfigure
@@ -272,3 +272,7 @@ media-libs/gegl cairo
# required by @selected
# required by @world (argument)
>=app-crypt/pinentry-1.1.1 gnome-keyring
+# required by media-video/cheese-3.34.0-r1::gentoo
+# required by @selected
+# required by @world (argument)
+>=media-libs/gst-plugins-base-1.16.3 theora

# mv ._cfg0000_zz_autoconfigure diff zz_autoconfigure;

Second pass:

# /usr/bin/emerge --deep --with-bdeps y --complete-graph y \
--autounmask-write --verbose-conflicts --jobs --load-average 4 \
--keep-going --update @world 2>&1 |
tee /tmp/b ;

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-python/idna:0

(dev-python/idna-3.1:0/0::gentoo, ebuild scheduled for merge) USE="" ABI_X86="(64)" PYTHON_TARGETS="python3_8 -pypy3 -python3_7 -python3_9" pulled in by
(no parents that aren't satisfied by other packages in this slot)

(dev-python/idna-2.10-r1:0/0::gentoo, ebuild scheduled for merge) USE="" ABI_X86="(64)" PYTHON_TARGETS="python3_8 -pypy3 -python3_7 -python3_9" pulled in by
<dev-python/idna-3[python_targets_pypy3(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (dev-python/requests-2.25.1-r1:0/0::gentoo, ebuild scheduled for merge) USE="-socks5 -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 -pypy3 -python3_7 -python3_9"

<snip>

Full output at:

<https://pastebin.com/qhyhW0mx>

At this point the various targets I've tried are all commented out
(whitespace added):

# grep PYTHON /etc/portage/make.conf /etc/portage/package.use/steamer ;
/etc/portage/make.conf:...
#PYTHON_TARGETS="python3_6 python3_7 python3_8 python3_9"
#PYTHON_SINGLE_TARGET="python3_9"

/etc/portage/package.use/steamer:..
#*/* PYTHON_TARGETS="-python2_7 python3_6 python3_6"
#*/* PYTHON_SINGLE_TARGET="python3_7"

Q: Is there any combination of targets that would suffice to get
things cleaned up to the point where I could eventuall remove
them?

I've tried this with an initially empty local & zz_autoconfig just
moving the generated autoconfig's in place as they are generated
but that didn't work either.

After zeroing zz_autoconfig and running a few emerges I get a autoconfig
file that hits a brick wall.


Thank you

--
Steven Lembark
Workhorse Computing
lembark@wrkhors.com
+1 888 359 3508

On Sun, 14 Feb 2021 16:03:40 -0500, Steven Lembark wrote:

> !!! Multiple package instances within a single package slot have
> been pulled !!! into the dependency graph, resulting in a slot conflict:
>
> dev-python/idna:0
>
> (dev-python/idna-3.1:0/0::gentoo, ebuild scheduled for merge)
> USE="" ABI_X86="(64)" PYTHON_TARGETS="python3_8 -pypy3 -python3_7
> -python3_9" pulled in by (no parents that aren't satisfied by other
> packages in this slot)
>
> (dev-python/idna-2.10-r1:0/0::gentoo, ebuild scheduled for merge)
> USE="" ABI_X86="(64)" PYTHON_TARGETS="python3_8 -pypy3 -python3_7
> -python3_9" pulled in by
> <dev-python/idna-3[python_targets_pypy3(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
> required by (dev-python/requests-2.25.1-r1:0/0::gentoo, ebuild
> scheduled for merge) USE="-socks5 -test" ABI_X86="(64)"
> PYTHON_TARGETS="python3_8 -pypy3 -python3_7 -python3_9"

I have vague recollections of both idna and requests causing problems
for me when 2.7 was removed, I had to re-emerge both of those, and one or
two others, in order to clean things up.

Look for anything that is currently installed with python2_7 in
PYTHON_TARGETS, something like this should do it

eix --installed-with-use python_targets_python2_7


--
Neil Bothwick

Anything is possible if you don't know what
you are talking about.

Steven Lembark <lembark@wrkhors.com> wrote:
> (dev-python/idna-3.1:0/0::gentoo, ebuild scheduled for merge)
> (no parents that aren't satisfied by other packages in this slot)
>
> (dev-python/idna-2.10-r1:0/0::gentoo, ebuild scheduled for merge)
> <dev-python/idna-3 [...] dev-python/requests-2.25.1-r1:0/0::gentoo

This is again a serious conflict:
dev-python/requests requires <dev-python/idna-3 while (IIRC) you
have unmasked all testing packages - and idna-3.1 is the latest