Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[gentoo-user] Q: What is "python-exec2c"? Why would "python3" dispatched through it not see an installed copy of pyyaml?
318 views
Skip to first unread message
Steven Lembark
Mar 6, 2021, 2:40:03 PM3/6/21
to
Question then is why "python-exec2c" dispatched via a symlink from
"python3" would fail to see the installed copy of pyyaml (or how
should I check with modules are avalable via "python3")?
e.g., is there the equivalent of "perl -MYAML -d -E 0" that would
allow me to check what it is that python thinks is installed?
I think that pyyaml is installed:
* dev-python/pyyaml
Latest version available: 5.4.1
Latest version installed: 5.4.1
Size of files: 170 KiB
Homepage: https://pyyaml.org/wiki/PyYAML https://pypi.org/project/PyYAML/ https://github.com/yaml/pyyaml
Description: YAML parser and emitter for Python
License: MIT
Running make for a program blows up with:
<snip>
PYTHON species-data.h
Traceback (most recent call last):
* File "/scratch/Build/crawl/crawl-ref/source/util/species-gen.py", line 23, in <module>
* import yaml # pip install pyyaml
ModuleNotFoundError: No module named 'yaml'
make: *** [Makefile:1741: species-data.h] Error 1
make -C rltiles all ARCH=x86_64-pc-linux-gnu NO_PKGCONFIG= TILES=y
make[1]: Entering directory '/scratch/Build/crawl/crawl-ref/source/rltiles'
make[1]: Leaving directory '/scratch/Build/crawl/crawl-ref/source/rltiles'
make: Target 'all' not remade because of errors.
make: Leaving directory '/scratch/Build/crawl/crawl-ref/source'
$ head -n1 /scratch/Build/crawl/crawl-ref/source/util/species-gen.py
#!/usr/bin/env python3
$ which python3
/usr/bin/python3
$ ls -ld $(which python3)
lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python3 -> python-exec2c
Thanks
--
Steven Lembark
Workhorse Computing
lem...@wrkhors.com
+1 888 359 3508
Mark Knecht
Mar 6, 2021, 4:30:03 PM3/6/21
to
>
> $ which python3
> /usr/bin/python3
>
> $ ls -ld $(which python3)
> lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python3 -> python-exec2c
>
> Thanks
>
What do you see just running python3 in a terminal?
- Mark
David Haller
Mar 6, 2021, 6:20:02 PM3/6/21
to
Hello,
On Sat, 06 Mar 2021, Steven Lembark wrote:
>Question then is why "python-exec2c" dispatched via a symlink from
>"python3" would fail to see the installed copy of pyyaml (or how
>should I check with modules are avalable via "python3")?
[..]
for what python versions that module is actually installed for and
compare that with the default python3 version (check 'python3 --version')
You probably need to re-emerge dev-python/pyyaml if PYTHON_TARGETS has
changed. You probably have it installed just for one target (which is
not your current default python3).
$ equery uses dev-python/pyyaml
[..]
+ + python_targets_python3_7 : Build with Python 3.7
+ + python_targets_python3_8 : Build with Python 3.8
- - python_targets_python3_9 : Build with Python 3.9
[..]
So I have it installed for python 3.7.x and 3.8.x ...
HTH,
-dnh
--
It's simply unbelievable how much energy and creativity people have
invested into creating contradictory, bogus and stupid licenses...
--- Sven Rudolph about licences in debian/non-free.
On Sat, 06 Mar 2021, Steven Lembark wrote:
>Question then is why "python-exec2c" dispatched via a symlink from
>"python3" would fail to see the installed copy of pyyaml (or how
>should I check with modules are avalable via "python3")?
>I think that pyyaml is installed:
>
>* dev-python/pyyaml
> Latest version available: 5.4.1
> Latest version installed: 5.4.1
> Size of files: 170 KiB
> Homepage: https://pyyaml.org/wiki/PyYAML https://pypi.org/project/PyYAML/ https://github.com/yaml/pyyaml
> Description: YAML parser and emitter for Python
> License: MIT
Check with 'eix dev-python/pyyaml' or 'equery uses dev-python/pyyaml'
>
>* dev-python/pyyaml
> Latest version available: 5.4.1
> Latest version installed: 5.4.1
> Size of files: 170 KiB
> Homepage: https://pyyaml.org/wiki/PyYAML https://pypi.org/project/PyYAML/ https://github.com/yaml/pyyaml
> Description: YAML parser and emitter for Python
> License: MIT
for what python versions that module is actually installed for and
compare that with the default python3 version (check 'python3 --version')
You probably need to re-emerge dev-python/pyyaml if PYTHON_TARGETS has
changed. You probably have it installed just for one target (which is
not your current default python3).
$ equery uses dev-python/pyyaml
[..]
+ + python_targets_python3_7 : Build with Python 3.7
+ + python_targets_python3_8 : Build with Python 3.8
- - python_targets_python3_9 : Build with Python 3.9
[..]
So I have it installed for python 3.7.x and 3.8.x ...
HTH,
-dnh
--
It's simply unbelievable how much energy and creativity people have
invested into creating contradictory, bogus and stupid licenses...
--- Sven Rudolph about licences in debian/non-free.
Steven Lembark
Mar 7, 2021, 11:10:03 AM3/7/21
to
On Sun, 7 Mar 2021 00:09:47 +0100
David Haller <gen...@dhaller.de> wrote:
> Hello,
>
> On Sat, 06 Mar 2021, Steven Lembark wrote:
> >Question then is why "python-exec2c" dispatched via a symlink from
> >"python3" would fail to see the installed copy of pyyaml (or how
> >should I check with modules are avalable via "python3")?
> [..]
> >I think that pyyaml is installed:
> >
> >* dev-python/pyyaml
> > Latest version available: 5.4.1
> > Latest version installed: 5.4.1
> > Size of files: 170 KiB
> > Homepage: https://pyyaml.org/wiki/PyYAML
> > https://pypi.org/project/PyYAML/ https://github.com/yaml/pyyaml
> > Description: YAML parser and emitter for Python License:
> > MIT
>
> Check with 'eix dev-python/pyyaml' or 'equery uses dev-python/pyyaml'
> for what python versions that module is actually installed for and
> compare that with the default python3 version (check 'python3
> --version')
I believe there isn't any PYTHON_TARGET-ish setting on the system:
David Haller <gen...@dhaller.de> wrote:
> Hello,
>
> On Sat, 06 Mar 2021, Steven Lembark wrote:
> >Question then is why "python-exec2c" dispatched via a symlink from
> >"python3" would fail to see the installed copy of pyyaml (or how
> >should I check with modules are avalable via "python3")?
> [..]
> >I think that pyyaml is installed:
> >
> >* dev-python/pyyaml
> > Latest version available: 5.4.1
> > Latest version installed: 5.4.1
> > Size of files: 170 KiB
> > Homepage: https://pyyaml.org/wiki/PyYAML
> > https://pypi.org/project/PyYAML/ https://github.com/yaml/pyyaml
> > Description: YAML parser and emitter for Python License:
> > MIT
>
> Check with 'eix dev-python/pyyaml' or 'equery uses dev-python/pyyaml'
> for what python versions that module is actually installed for and
> compare that with the default python3 version (check 'python3
> --version')
$ grep PYTHON_TARGET /etc/portage/make.conf /etc/portage/package.use/*
/etc/portage/make.conf:#PYTHON_TARGETS="python3_7 python2_7"
/etc/portage/package.use/dizzy:#*/* PYTHON_TARGETS: python3_6 python3_7
/etc/portage/package.use/dizzy~:#*/* PYTHON_TARGETS: python3_6 python3_7
> You probably need to re-emerge dev-python/pyyaml if PYTHON_TARGETS has
> changed. You probably have it installed just for one target (which is
> not your current default python3).
> $ equery uses dev-python/pyyaml
> [..]
> + + python_targets_python3_7 : Build with Python 3.7
> + + python_targets_python3_8 : Build with Python 3.8
> - - python_targets_python3_9 : Build with Python 3.9
> [..]
>
> So I have it installed for python 3.7.x and 3.8.x ...
>
> HTH,
> -dnh
>
[ Legend : U - final flag setting for installation]
[ : I - package is installed with flag ]
[ Colors : set, unset ]
* Found these USE flags for dev-python/pyyaml-5.4.1:
U I
- - examples : Install examples, usually source code
+ + libyaml : enable support for C implementation using
libyaml
- - python_targets_python3_7 : Build with Python 3.7
+ + python_targets_python3_8 : Build with Python 3.8
- - python_targets_python3_9 : Build with Python 3.9
- - test : Enable dependencies and/or preparations
- - python_targets_python3_9 : Build with Python 3.9
necessary to run tests (usually controlled by
FEATURES=test but can be toggled independently)
(ins)lembark@dizzy ~ $ eselect python list
Available Python interpreters, in order of preference:
[1] python3.9
[2] python3.6
[3] python3.8 (fallback)
[4] python3.7 (fallback)
[5] python2.7 (fallback)
$ python3 --version;
Python 3.9.1
Q: If don't have PYTHON_TARGETS set
Given that I installed it yesterday when the makefile told me
about pyyaml not being installed, there aren't any TARGETS set
(both commented), python3 appears to be python-3.9...
Q: Why would emerge pyyaml install the pacakge for a non-target
python version that isn't the one linked via python3?
Q: Is this related to the fact that I'm not actually checking
python but a wrapper named "python-exec2c":
$ ls -l /usr/bin/python3
lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python3 -> python-exec2c
i.e., could the wrapper be mis-diagnosing the correct python
version at install time?
Q: Is there any reasonable way to have a single version of python
installed so that I get out of this maze? Previous python
target advice left me with one machine being re-installed and
I'd rather not have my server disabled at this point.
Michael
Mar 7, 2021, 12:10:03 PM3/7/21
to
On Sunday, 7 March 2021 17:03:22 GMT Arve Barsnes wrote:
> default python target setting. Check yours with something like:
> $ emerge --info | grep PYTHON_TARGETS
>
> The default at the moment is 3.8, and as eselect showed you, your
> default python interpreter is 3.9. Did you set this explicitly? If you
> have no particular need to move to 3.9 early, you could set 3.8 as the
> default and probably be rid of your problems immediately.
> wanted version. The link is the same on my system, but I have 3.8 as
> my default interpreter, so I would not have these problems.
>
> Regards,
> Arve
While eselect python is still available the OP can run:
eselect python update
eselect python cleanup
> On Sun, 7 Mar 2021 at 17:00, Steven Lembark <lem...@wrkhors.com> wrote:
> > I believe there isn't any PYTHON_TARGET-ish setting on the system:
> > $ grep PYTHON_TARGET /etc/portage/make.conf
> > /etc/portage/package.use/*
> >
> > /etc/portage/make.conf:#PYTHON_TARGETS="python3_7 python2_7"
> > /etc/portage/package.use/dizzy:#*/* PYTHON_TARGETS: python3_6
> > python3_7
> > /etc/portage/package.use/dizzy~:#*/* PYTHON_TARGETS: python3_6
> > python3_7
>
> What this is telling you is that you have no manual *override* of the
> > I believe there isn't any PYTHON_TARGET-ish setting on the system:
> > $ grep PYTHON_TARGET /etc/portage/make.conf
> > /etc/portage/package.use/*
> >
> > /etc/portage/make.conf:#PYTHON_TARGETS="python3_7 python2_7"
> > /etc/portage/package.use/dizzy:#*/* PYTHON_TARGETS: python3_6
> > python3_7
> > /etc/portage/package.use/dizzy~:#*/* PYTHON_TARGETS: python3_6
> > python3_7
>
> default python target setting. Check yours with something like:
> $ emerge --info | grep PYTHON_TARGETS
>
> The default at the moment is 3.8, and as eselect showed you, your
> default python interpreter is 3.9. Did you set this explicitly? If you
> have no particular need to move to 3.9 early, you could set 3.8 as the
> default and probably be rid of your problems immediately.
>
> > Q: Is this related to the fact that I'm not actually checking
> >
> > python but a wrapper named "python-exec2c":
> > $ ls -l /usr/bin/python3
> > lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python3 ->
> > python-exec2c
> >
> > i.e., could the wrapper be mis-diagnosing the correct python
> > version at install time?
>
> It is finding python 3.9, which your system has set up to be the
> > Q: Is this related to the fact that I'm not actually checking
> >
> > python but a wrapper named "python-exec2c":
> > $ ls -l /usr/bin/python3
> > lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python3 ->
> > python-exec2c
> >
> > i.e., could the wrapper be mis-diagnosing the correct python
> > version at install time?
>
> wanted version. The link is the same on my system, but I have 3.8 as
> my default interpreter, so I would not have these problems.
>
> Regards,
> Arve
While eselect python is still available the OP can run:
eselect python update
eselect python cleanup
Arve Barsnes
Mar 7, 2021, 12:10:03 PM3/7/21
to
On Sun, 7 Mar 2021 at 17:00, Steven Lembark <lem...@wrkhors.com> wrote:
> I believe there isn't any PYTHON_TARGET-ish setting on the system:
>
> $ grep PYTHON_TARGET /etc/portage/make.conf /etc/portage/package.use/*
> /etc/portage/make.conf:#PYTHON_TARGETS="python3_7 python2_7"
> /etc/portage/package.use/dizzy:#*/* PYTHON_TARGETS: python3_6 python3_7
> /etc/portage/package.use/dizzy~:#*/* PYTHON_TARGETS: python3_6 python3_7
>
> $ grep PYTHON_TARGET /etc/portage/make.conf /etc/portage/package.use/*
> /etc/portage/make.conf:#PYTHON_TARGETS="python3_7 python2_7"
> /etc/portage/package.use/dizzy:#*/* PYTHON_TARGETS: python3_6 python3_7
> /etc/portage/package.use/dizzy~:#*/* PYTHON_TARGETS: python3_6 python3_7
What this is telling you is that you have no manual *override* of the
default python target setting. Check yours with something like:
$ emerge --info | grep PYTHON_TARGETS
The default at the moment is 3.8, and as eselect showed you, your
default python interpreter is 3.9. Did you set this explicitly? If you
have no particular need to move to 3.9 early, you could set 3.8 as the
default and probably be rid of your problems immediately.
default python target setting. Check yours with something like:
$ emerge --info | grep PYTHON_TARGETS
The default at the moment is 3.8, and as eselect showed you, your
default python interpreter is 3.9. Did you set this explicitly? If you
have no particular need to move to 3.9 early, you could set 3.8 as the
default and probably be rid of your problems immediately.
> Q: Is this related to the fact that I'm not actually checking
> python but a wrapper named "python-exec2c":
>
> $ ls -l /usr/bin/python3
> lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python3 -> python-exec2c
>
>
> i.e., could the wrapper be mis-diagnosing the correct python
> version at install time?
> python but a wrapper named "python-exec2c":
>
> $ ls -l /usr/bin/python3
> lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python3 -> python-exec2c
>
>
> i.e., could the wrapper be mis-diagnosing the correct python
> version at install time?
Steven Lembark
Mar 7, 2021, 1:40:03 PM3/7/21
to
> While eselect python is still available the OP can run:
>
> eselect python update
> eselect python cleanup
Switching to python3.9
# eselect python cleanup
# eselect python list;
Available Python interpreters, in order of preference:
[1] python3.9
[2] python3.6
[3] python3.8 (fallback)
[4] python3.7 (fallback)
[5] python2.7 (fallback)
Sanity check: Is this something I should be doing with
[1] python3.9
[2] python3.6
[3] python3.8 (fallback)
[4] python3.7 (fallback)
[5] python2.7 (fallback)
every python update (don't use python for anything myself
so if it works for system updates only I'm fine).
Steven Lembark
Mar 7, 2021, 1:50:03 PM3/7/21
to
Checking my environment, I'd expect that "python" is 3.9.1, I think?
# which python
/usr/bin/python
# ls -al /usr/bin/python
lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python -> python-exec2c
# /usr/bin/python --version;
Python 3.9.1
(ins)root@dizzy ~ # eselect python list;
Available Python interpreters, in order of preference:
[1] python3.9
[2] python3.6
[3] python3.8 (fallback)
[4] python3.7 (fallback)
[5] python2.7 (fallback)
Yet when I "emerge pyyaml" it seems to prefer 3.8 (see ? below):
[1] python3.9
[2] python3.6
[3] python3.8 (fallback)
[4] python3.7 (fallback)
[5] python2.7 (fallback)
(cmd)root@dizzy ~ # emerge pyyaml
Calculating dependencies... done!
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) dev-python/pyyaml-5.4.1::gentoo
* pyyaml-5.4.1.gh.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ]
>>> Unpacking source...
>>> Unpacking pyyaml-5.4.1.gh.tar.gz to /tmp/portage/dev-python/pyyaml-5.4.1/work
>>> Source unpacked in /tmp/portage/dev-python/pyyaml-5.4.1/work
>>> Preparing source in /tmp/portage/dev-python/pyyaml-5.4.1/work/pyyaml-5.4.1 ...
* Applying pyyaml-5.1-cve-2017-18342.patch ... [ ok ]
>>> Source prepared.
>>> Configuring source in /tmp/portage/dev-python/pyyaml-5.4.1/work/pyyaml-5.4.1 ...
? * Using python3.8 in global scope
? * python3_8: running distutils-r1_run_phase python_configure_all
>>> Source configured.
^C
Exiting on signal 2
>>> Compiling source in /tmp/portage/dev-python/pyyaml-5.4.1/work/pyyaml-5.4.1 ...
^Csandbox:stop caught signal 2 in pid 8217
Sandboxed process killed by signal: Interrupt
* The ebuild phase 'die_hooks' has been killed by signal 2.
* Messages for package dev-python/pyyaml-5.4.1:
* Log file: /var/log/portage/dev-python:pyyaml-5.4.1:20210307-183833.log
Q: Is it reasonable to simply remove everything other than 3.9 and
some version of 2.7?
Trying to build 3.9 for one of my co-workers was hell, we ended up
using 3.8. Would it make more sense to remove 3.9?
Not entirely sure why I have so many versions of python left behind
by upgrades.
Michael
Mar 7, 2021, 2:40:03 PM3/7/21
to
eselect python cleanup
emerge --depclean -v -p
emerge @preserved-rebuild -v -a
I don't have any python targets specified and on a (mostly) stable system I
get:
$ /usr/bin/python --version
Python 3.8.7
$ eselect python list
Available Python interpreters, in order of preference:
[1] python3.8
[2] python3.9 (fallback)
$ ls -al /usr/bin/python
lrwxrwxrwx 1 root root 13 Feb 13 09:04 /usr/bin/python -> python-exec2c
$ emerge -1Dvp pyyaml
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-python/pyyaml-5.4.1::gentoo USE="libyaml -examples -
test" PYTHON_TARGETS="python3_8 (-pypy3) -python3_7 -python3_9" 170 KiB
Total: 1 package (1 new), Size of downloads: 170 KiB
It would use PYTHON_TARGETS="python3_8" which is the default on this system,
since I have not modified my python settings.
Neil Bothwick
Mar 7, 2021, 5:10:04 PM3/7/21
to
On Sun, 7 Mar 2021 11:00:16 -0500, Steven Lembark wrote:
> I believe there isn't any PYTHON_TARGET-ish setting on the system:
>
> $ grep PYTHON_TARGET /etc/portage/make.conf
> /etc/portage/package.use/*
> /etc/portage/make.conf:#PYTHON_TARGETS="python3_7 python2_7"
> /etc/portage/package.use/dizzy:#*/* PYTHON_TARGETS: python3_6 python3_7
> /etc/portage/package.use/dizzy~:#*/* PYTHON_TARGETS: python3_6 python3_7
There is, just not set by you. There is still the default setting, which
> I believe there isn't any PYTHON_TARGET-ish setting on the system:
>
> $ grep PYTHON_TARGET /etc/portage/make.conf
> /etc/portage/package.use/*
> /etc/portage/make.conf:#PYTHON_TARGETS="python3_7 python2_7"
> /etc/portage/package.use/dizzy:#*/* PYTHON_TARGETS: python3_6 python3_7
> /etc/portage/package.use/dizzy~:#*/* PYTHON_TARGETS: python3_6 python3_7
emerge --info will show you is 3.8.
> $ equery uses dev-python/pyyaml
> [ Legend : U - final flag setting for installation]
> [ : I - package is installed with flag ]
> [ Colors : set, unset ]
> * Found these USE flags for dev-python/pyyaml-5.4.1:
> U I
> - - examples : Install examples, usually source
> code
> + + libyaml : enable support for C implementation
> using libyaml
> - - python_targets_python3_7 : Build with Python 3.7
> + + python_targets_python3_8 : Build with Python 3.8
> - - python_targets_python3_9 : Build with Python 3.9
> - - test : Enable dependencies and/or
> preparations necessary to run tests (usually controlled by
> FEATURES=test but can be toggled
> independently) (ins)
place.
> lembark@dizzy ~ $ eselect python list
> Available Python interpreters, in order of preference:
> [1] python3.9
> [2] python3.6
> [3] python3.8 (fallback)
> [4] python3.7 (fallback)
> [5] python2.7 (fallback)
>
> $ python3 --version;
> Python 3.9.1
you two choices:
1) use eselect to set your default python to 3.8
2) Add python_39 to PYTHON_TARGETS
3) Explicitly call python38 in the shebang line of the affected script.
--
Neil Bothwick
QOTD:
The only easy way to tell a hamster from a gerbil is that the
gerbil has more dark meat.
Steven Lembark
Mar 7, 2021, 6:40:03 PM3/7/21
to
On Sun, 07 Mar 2021 19:30:21 +0000
Michael <confa...@kintzios.com> wrote:
> eselect python cleanup
> emerge --depclean -v -p
> emerge @preserved-rebuild -v -a
cleanup doesn't seem to change anything.
Michael <confa...@kintzios.com> wrote:
> eselect python cleanup
> emerge --depclean -v -p
> emerge @preserved-rebuild -v -a
depcleand doesn't remove anything.
@preserved-rebuild failes due to lack of an already-installed
python library.
Steven Lembark
Mar 7, 2021, 6:40:03 PM3/7/21
to
On Sun, 7 Mar 2021 22:04:39 +0000
Neil Bothwick <ne...@digimed.co.uk> wrote:
> But you have chosen a different default version of Python. That leaves
> you two choices:
>
> 1) use eselect to set your default python to 3.8
> 2) Add python_39 to PYTHON_TARGETS
> 3) Explicitly call python38 in the shebang line of the affected
> script.
So, I go back and eselect 3.8.
Neil Bothwick <ne...@digimed.co.uk> wrote:
> But you have chosen a different default version of Python. That leaves
> you two choices:
>
> 1) use eselect to set your default python to 3.8
> 2) Add python_39 to PYTHON_TARGETS
> 3) Explicitly call python38 in the shebang line of the affected
> script.
I then try to perform some basic maintainence which fails for
lack of a python module I think is installed for python 3.8.
Q: Is there no way to have a consistent version of Python on
the system?
# eselect python list;
Available Python interpreters, in order of preference:
[1] python3.8
[2] python3.6
[3] python3.9
[4] python3.7 (fallback)
[5] python2.7 (fallback)
# emerge dev-python/chardet;
[5] python2.7 (fallback)
<snip>
writing byte-compilation script '/tmp/portage/dev-python/chardet-4.0.0/temp/tmp591yrh90.py'
* /usr/bin/python3.8 /tmp/portage/dev-python/chardet-4.0.0/temp/tmp591yrh90.py
removing /tmp/portage/dev-python/chardet-4.0.0/temp/tmp591yrh90.py
writing byte-compilation script '/tmp/portage/dev-python/chardet-4.0.0/temp/tmp9vcif_en.py'
* /usr/bin/python3.8 /tmp/portage/dev-python/chardet-4.0.0/temp/tmp9vcif_en.py
removing /tmp/portage/dev-python/chardet-4.0.0/temp/tmp9vcif_en.py
<snip>
>>> Installing (1 of 1) dev-python/chardet-4.0.0::gentoo
>>> Auto-cleaning packages...
>>> No outdated packages were found on your system.
* GNU info directory index is up-to-date.
!!! existing preserved libs:
>>> package: dev-libs/icu-68.2
* - /usr/lib64/libicudata.so.67
* - /usr/lib64/libicudata.so.67.1
* - /usr/lib64/libicui18n.so.67
* - /usr/lib64/libicui18n.so.67.1
* used by /usr/bin/js60 (dev-lang/spidermonkey-60.5.2_p0-r4)
* used by /usr/lib64/libmozjs-60.so (dev-lang/spidermonkey-60.5.2_p0-r4)
* - /usr/lib64/libicuuc.so.67
* - /usr/lib64/libicuuc.so.67.1
* used by /usr/bin/js60 (dev-lang/spidermonkey-60.5.2_p0-r4)
* used by /usr/lib64/libmozjs-60.so (dev-lang/spidermonkey-60.5.2_p0-r4)
Use emerge @preserved-rebuild to rebuild packages using these libraries
* python3_8: running distutils-r1_run_phase distutils-r1_python_install_all
# $emerge @preserved-rebuild
These are the packages that would be merged, in order:
Calculating dependencies... done!
<snip>
# emerge --search dev-python/chardet;
[ Results for search key : dev-python/chardet ]
Searching...
* dev-python/chardet
Latest version available: 4.0.0
Latest version installed: 4.0.0
# emerge --info dev-python/chardet;
* Portage 3.0.13 (python 3.8.7-final-0, default/linux/amd64/17.1, gcc-9.3.0, glibc-2.32-r3, 5.9.1-gentoo-af x86_64)
* dev-lang/python: 2.7.18-r6::gentoo, 3.6.12-r2::gentoo, 3.7.9-r2::gentoo, 3.8.7-r1::gentoo, 3.9.1-r1::gentoo
* USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 python3_8 (-pypy3) -python3_9"
See <https://pastebin.com/JbKXEptz> for details of --info.
Neil Bothwick
Mar 7, 2021, 6:50:03 PM3/7/21
to
On Sun, 7 Mar 2021 18:32:26 -0500, Steven Lembark wrote:
> > 1) use eselect to set your default python to 3.8
> > 2) Add python_39 to PYTHON_TARGETS
> > 3) Explicitly call python38 in the shebang line of the affected
> > script.
>
> So, I go back and eselect 3.8.
> I then try to perform some basic maintainence which fails for
> lack of a python module I think is installed for python 3.8.
If your system has been built entirely with PYTHON_TARGETS="python_38"
> > 1) use eselect to set your default python to 3.8
> > 2) Add python_39 to PYTHON_TARGETS
> > 3) Explicitly call python38 in the shebang line of the affected
> > script.
>
> So, I go back and eselect 3.8.
> I then try to perform some basic maintainence which fails for
> lack of a python module I think is installed for python 3.8.
then all installed modules should be available.
> Q: Is there no way to have a consistent version of Python on
> the system?
--
Neil Bothwick
Do Roman paramedics refer to IV's as "4's"?
Steven Lembark
Mar 7, 2021, 7:00:03 PM3/7/21
to
> > Q: Is there no way to have a consistent version of Python on
> > the system?
>
> Yes, make sure PYTHON_TARGETS and your chosen version of python match.
I never deal with the language... last I saw was some news that
turn off the targets would be preferable. Is there some real
advantage to targets vs target (i.e., at this point is it reasonable
to just have a single target)?
I'm still not sure, however, why a module installed with python 3.8
would leave portage disfunctional if that version were selected.
Thanks
Neil Bothwick
Mar 7, 2021, 7:00:03 PM3/7/21
to
On Sun, 7 Mar 2021 23:47:26 +0000, Neil Bothwick wrote:
> > So, I go back and eselect 3.8.
> > I then try to perform some basic maintainence which fails for
> > lack of a python module I think is installed for python 3.8.
>
> If your system has been built entirely with PYTHON_TARGETS="python3_8"
> > So, I go back and eselect 3.8.
> > I then try to perform some basic maintainence which fails for
> > lack of a python module I think is installed for python 3.8.
>
> then all installed modules should be available.
>
> > Q: Is there no way to have a consistent version of Python on
> > the system?
>
> Yes, make sure PYTHON_TARGETS and your chosen version of python match.
I forgot to add that PYTHON_TARGETS can include multiple versions, so the
>
> > Q: Is there no way to have a consistent version of Python on
> > the system?
>
> Yes, make sure PYTHON_TARGETS and your chosen version of python match.
sensible option in your situation may be to set it to "python3_8 python3_9".
--
Neil Bothwick
Sacred cows make great hamburgers.
Arve Barsnes
Mar 8, 2021, 1:10:04 AM3/8/21
to
On Mon, 8 Mar 2021 at 00:32, Steven Lembark <lem...@wrkhors.com> wrote:
> * emerge: there are no ebuilds to satisfy ">=dev-python/chardet-3.0.2[python_targets_python3_6(-),python_targets_python3_7(-),python_targets_python3_8(-),-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]".
> <snip>
If you can unsnip here and show more of the output, we could see what
> * emerge: there are no ebuilds to satisfy ">=dev-python/chardet-3.0.2[python_targets_python3_6(-),python_targets_python3_7(-),python_targets_python3_8(-),-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]".
> <snip>
package is causing this error. This error is telling you that
something in the snipped output is requiring dev-python/chardet to be
built with python targets matching that other package, and that
package seems to be using other targets than the default 3.8.
Since you've already mentioned that depclean doesn't remove anything,
do you have any package-specific python targets set that you've
forgotten about?
# grep python_targets /etc/portage/package.use/*
It seems to me very similar to other threads on this list where people
have older packages hanging back that creates problems because portage
can't remove them.
Regards,
Arve
Neil Bothwick
Mar 8, 2021, 4:30:03 AM3/8/21
to
On Sun, 7 Mar 2021 18:52:50 -0500, Steven Lembark wrote:
> > > Q: Is there no way to have a consistent version of Python on
> > > the system?
> >
> > Yes, make sure PYTHON_TARGETS and your chosen version of python
> > match.
>
> Q: How do I know which verson of python is suitable?
>
> I never deal with the language... last I saw was some news that
> turn off the targets would be preferable. Is there some real
> advantage to targets vs target (i.e., at this point is it reasonable
> to just have a single target)?
In that case, you had no reason to use eselect to switch away from the
> > > Q: Is there no way to have a consistent version of Python on
> > > the system?
> >
> > Yes, make sure PYTHON_TARGETS and your chosen version of python
> > match.
>
> Q: How do I know which verson of python is suitable?
>
> I never deal with the language... last I saw was some news that
> turn off the targets would be preferable. Is there some real
> advantage to targets vs target (i.e., at this point is it reasonable
> to just have a single target)?
default. Switch back to 3.8 with eselect and all should be well - at
least after an emerge -auDN @world
> I'm still not sure, however, why a module installed with python 3.8
> would leave portage disfunctional if that version were selected.
--
Neil Bothwick
Documentation: (n.) a novel sold with software, designed to entertain the
operator during episodes of bugs or glitches.
Arve Barsnes
Mar 13, 2021, 1:00:04 PM3/13/21
to
On Sat, 13 Mar 2021 at 18:23, Steven Lembark <lem...@wrkhors.com> wrote:
> > grep python_targets /etc/portage/package.use/*
>
> That was it: I never new that the python targets got stuck
> in the zz_autoconfigure file.
>
> Sanity check: Do I actually need to set the python target or
> python single target for the system to function?
Usually not, they have defaults that works most of the time. You
should really only set them for specific packages and specific
versions where you need it for something special.
Regards,
Arve
> > grep python_targets /etc/portage/package.use/*
>
> That was it: I never new that the python targets got stuck
> in the zz_autoconfigure file.
>
> Sanity check: Do I actually need to set the python target or
> python single target for the system to function?
Usually not, they have defaults that works most of the time. You
should really only set them for specific packages and specific
versions where you need it for something special.
Regards,
Arve
0 new messages