subject:"\[gentoo\-user\] update fails, but I don't see why"


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]

2020-12-29 Thread Dale

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]

2020-12-29 Thread Michael

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]

2020-12-29 Thread Neil Bothwick

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]

2020-12-29 Thread Dale

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.

Re: [gentoo-user] update fails, but I don't see why

2020-12-20 Thread Peter Humphrey

On Sunday, 13 December 2020 10:07:42 GMT n952162 wrote:

> If rust, llvm, firefox or thunderbird is in that list, I'll go crazy.

You can avoid compiling rust by 'emerge -1 rust-bin && emerge -C rust'. I do 
that because it consumes huge amounts of resources and is only used in firefox 
building - here, at least.

-- 
Regards,
Peter.

Re: [gentoo-user] update fails, but I don't see why


On 12/14/20 1:04 AM, Michael wrote:


If you're running a stable system then you should not *need* to define a
particular python version or python target manually in your USE preferences
configuration and you should not need to add python or any lib packages in
general, in your '/var/lib/portage/world' file.

Portage will take care of python for itself and for any packages which have
python as a dependency.

eselect python list
eselect python update
eselect python cleanup



Ah, I'll investigate update and cleanup, thank you.

Re: [gentoo-user] update fails, but I don't see why



On 12/13/20 10:39 PM, antlists wrote:

On 13/12/2020 21:02, n952162 wrote:

My problem is I can't find a diagnostic methodology.  The one I most
often hear is, update more often, or trail and error solutions.


Although I haven't yet had the grief of something like this python
thing, I've always found that unmerging everything that clashes (with
care not to break emerge), or *u**pdating everything that will
update*, has always worked for me in the past.



I forgot about that.  That's helped in the past.

Re: [gentoo-user] update fails, but I don't see why



On 12/13/20 10:31 PM, Dale wrote:

I've seen some say
to start at the bottom, then work your way up.  Even with that, it
doesn't help me understand it most times.



It would be cool if the attached vim coloration script would be useful
for somebody.

" vim: tw=0
syn match maskedinstalled "^- [^/]\+/.* (masked by:.*" contains=masked_by
hi maskedinstalled ctermfg=blue
syn match masked_by "(masked by[^)]*)"
hi masked_by ctermfg=black ctermbg=lightblue

syn match section_headers "^!!!.*"
hi section_headers ctermbg=blue ctermfg=white

"syn match slot "^\a\w*-\a\w*/\a\w*\(-\a\w*\)\?:\d\+$"
syn match slot "^\a\w*-\a\w*/\a[0-9A-Za-z_-]*:\d\+$"
hi slot ctermbg=magenta ctermfg=white

syn match offender "  (.*) pulled in by" 
contains=offender_installed,offender_ebuild
hi offender ctermfg=magenta

"  (dev-python/setuptools-36.7.2:0/0::gentoo, installed) pulled in by
"syn match offender_installed "  
(\a\w*-\a\w*/\a\w*-\d\+\.\d\+\.\d\+:\d\+/\d\+::gentoo, installed) .*" contained
"syn match offender_installed "  
(\a\w*-\a\w*/\a\w*-[0-9.]\+\(-r\d\+\)*:\d\+/\d\+::gentoo, installed) .*" 
contained
 syn match offender_installed "  
(\a\w*-\a\w*/\a[0-9A-Za-z_-]*-[0-9.]\+\(_p[0-9]\)\?\(-r\d\+\)*:\d\+/\d\+::gentoo,
 installed) .*" contained
hi offender_installed ctermfg=green

"  (dev-python/setuptools-40.6.3:0/0::gentoo, ebuild scheduled for merge) 
pulled in by
syn match offender_ebuild "  
(\a\w*-\a\w*/\a\w*-[0-9.]\+\(-r[0-9]\+\)\?:\d\+/\d\+::gentoo, ebuild scheduled 
for merge) .*" contained
hi offender_ebuild ctermfg=green ctermbg=yellow

syn match details "^\S*\[[^]]*\] required by .*$" contains=details_list,pkg
syn match details_list "\[.*\]" contained
hi details_list ctermfg=blue

syn match pkg_status "^  ([^:]*[^)]*)" contains=installed,merge
syn match installed "installed" contained
hi installed ctermbg=cyan ctermfg=black
syn match merge "ebuild scheduled for merge"
hi merge ctermbg=cyan ctermfg=blue
syn match pkg "^[^:[]*" contained
hi pkg ctermfg=darkcyan


syn region resolution start="The following keyword changes are necessary to 
proceed:" end="^$"
hi resolution ctermbg=green ctermfg=magenta

syn region caldep start="^Calculating dependencies ( \.)* done!" end="^$" 
contains=assignments
syn match assignments '\w\+="[^\"]*"' contained
hi assignments ctermfg=darkcyan



"[nomerge   ]   dev-libs/libgcrypt-1.8.1:0/20::gentoo  
USE="static-libs -doc" ABI_X86="(64) -32 (-x32)" 
"[ebuild U  ]dev-libs/libgpg-error-1.29::gentoo 
[1.27-r1::gentoo] USE="nls static-libs -common-lisp" ABI_X86="(64) -32 (-x32)" 
874 KiB

syn match dep_nomerge "^\[nomerge...\]\s*.*" 
contains=dep_pkgs,dep_installed,dep_defs
hi dep_nomerge ctermfg=cyan cterm=bold
syn match dep_emerge "^\[ebuild\]\s*.*" 
contains=dep_needed,dep_installed,dep_defs
hi dep_emerge ctermbg=cyan
syn match dep_needed "[a-z_][a-z_0-9-]*/[a-z_][a-z_0-9-]\S*" contained
hi dep_needed ctermbg=blue ctermfg=white
syn match dep_pkgs "[a-z_][a-z_0-9-]*/[a-z_][a-z_0-9-]\S*" contained
hi dep_pkgs ctermfg=blue
syn match dep_installed ".\[[^]]*\]" contained
hi dep_installed ctermbg=green ctermfg=black
syn match dep_defs '\w\+="[^"]*"' contained
hi dep_defs ctermfg=green cterm=bold 

"[blocks B  ] >> Emerging (\d\+ of \d\+) \S\+"
hi emerging ctermfg=darkblue ctermbg=lightblue
syn match installing ">>> Installing (\d\+ of \d\+) \S\+"
hi installing ctermfg=darkgreen ctermbg=lightgreen
syn match failed ">>> Failed to emerge \S\+"
hi failed ctermfg=darkred ctermbg=lightred
syn match failed "Traceback (most recent call last):"


">>> No outdated packages were found on your system.
syn match done ">>> No outdated packages were found on your system."
hi done ctermbg=green ctermfg=black

Re: [gentoo-user] update fails, but I don't see why


That's good.  I'll do that


On 12/13/20 10:40 PM, Dale wrote:

n952162 wrote:

On 12/13/20 10:02 PM, n952162 wrote:

On 12/13/20 9:06 PM, Dale wrote:

Mark Knecht wrote:

On Sun, Dec 13, 2020 at 12:03 PM n952162 mailto:n952...@web.de>> wrote:

On 12/13/20 9:18 AM, Neil Bothwick wrote:

Nearly 2 months, quite a long time in Gentoo update terms.



Okay, is the solution then to re-install?


Personally I wouldn't start with a reinstall.

I'd start with my world file and remove/comment out every
'application' not required to keep the machine running/booting. That
should be nearly everything other than things like grub, your kernels,
hardware drivers, terminals, etc.

NOTE: Just because you comment something out in the world file doesn't
mean it won't run, it just won't get updated or be part of portage's
considerations about what to do.

At that point emerge @world should only be considering, from a build
POV, the stuff you really need.

This python problem everyone is having I cannot help with. Solving
problems like that is why people run Gentoo. With lots of power comes
lots of responsibility. However with all the applications
'unconsidered' you have a chance of getting the really important stuff
built and booting.

If I got that far then I'd start adding apps back in/uncommenting one
or two at a time and see if I could make headway.

I've updated machines that were a year out of date but it took days
and days. If I didn't want to build code every week I decided I
couldn't run Gentoo.

HTH,
Mark

I agree.  I update once a week.  It seems a pretty good balance between
not having to do it to often and not having such drastic changes
that it
makes things hard to work through.

That said, when the tree is in the process of huge changes, it can
create problems even with weekly updates.  Right now, it is python and
the speed it is moving at.  Some versions that have been around for
ages, 2.7, is being removed.  Then python 3.6 is leaving etc etc etc.
Those of us that have been around long enough have seen this with other
packages as well.  Some packages are just hard to upgrade to begin with
and some create circular problems. The longer it goes between updates,
the larger that problem gets to be.  You get two different packages
doing that, you can find yourself running around in circles trying to
get emerge to chew what it can.

While I usually do updates on Sunday evening, I'm considering doing
twice a week, Sunday and Wednesday.  At least until python settles down
a bit. Thing is, I think the worst part may be about over.  I think 2.7
is gone here, I think 3.6 is too.  That's two down.  It seems 3.7 and
above will be around a while but if they start going away soon, I
may do
two updates a week if it starts making updates harder.

Time can be a problem but sometimes it just depends on what packages
have changed and how fast they have changed.  For some systems that
haven't been updated in a while, having to remove python 2.7 and 3.6 in
one go, can cause problems that are hard to get around.  Right now just
isn't a good time to let updates get to far apart.

The only thing that makes some of this survivable, getting help on this
mailing list.  Some people can decode the output of emerge and find a
way to work through it. Some are fairly easy, some not so much.
Sometimes removing/commenting out things in the world file will help.
Sometimes doing @system first helps. Sometimes you just have to update
certain packages in small chunks to get through a upgrade. Finding that
right option sometimes requires help.

Just some thoughts.

Dale

:-)  :-)




My problem is I can't find a diagnostic methodology.  The one I most
often hear is, update more often, or trail and error solutions.

Does all that information in emerge's output point the way to the
problem, and I just have to learn to understand it,  or am I just
wasting my time there?  Are there better tools than log parsing? I know,
there are lots of good tools,  but there needs to be methodology for
using them (like understanding gentoo ;-) )



But commenting stuff out of the world file is at least a path. I'll
start with that tomorrow.






Another option some use, sets.  That way instead of updating world all
in one go, they update sets instead.  Example.  You have several GUIs
installed, KDE, Gnome and maybe even a couple more.  You break those up
into sets for each one.  Most of the time, you may can just update world
all in one go.  At times, it may be easier to update the lighter
desktops first then move to the next until they are all done.  Then
update world which should be a much smaller set of updates since most
updates would already be done.

Quite a few here use sets.  It can work well depending on your setup.
If you do use them, there is people here than can help you work through
issues.  Linkys:

https://wiki.gentoo.org/wiki//etc/portage/sets

https://wiki.gentoo.org/wiki/Package_sets

Last one is about sets already being used.  Good for examples

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread Michael

On Sunday, 13 December 2020 21:10:14 GMT n952162 wrote:
> On 12/13/20 10:55 AM, Michael wrote:
> > On Sunday, 13 December 2020 08:57:53 GMT n952162 wrote:

> >> $ sed -n -e '/^\s*#/d' -e '/python3_6/p' /etc/portage/package.use/*
> >> 
> >>> =dev-python/certifi-10001-r1 python_targets_python3_6
> >>> =dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
> >>> =dev-python/requests-2.24.0-r1 python_targets_python3_6
> >>> =dev-python/chardet-3.0.4-r1 python_targets_python3_6
> >>> =dev-python/idna-2.10-r1 python_targets_python3_6
> >>> =dev-python/urllib3-1.25.11 python_targets_python3_6
> >>> =dev-python/cryptography-3.2.1 python_targets_python3_6
> >>> =dev-python/cffi-1.14.0-r3 python_targets_python3_6
> >>> =dev-python/pycparser-2.20-r1 python_targets_python3_6
> >>> =dev-python/ply-3.11-r1 python_targets_python3_6
> >>> =dev-python/PySocks-1.7.1-r1 python_targets_python3_6
> >>> =dev-python/pyopenssl-19.1.0-r1 python_targets_python3_6
> >>> =dev-python/setuptools-50.3.0 python_targets_python3_6
> >>> =dev-python/six-1.15.0-r1 python_targets_python3_6
> > 
> > Why had you set up these in your package.use?
> 
> Basically, whenever emerge tells me I need USE variables, I define them.
> 
> It's not clear to me how I should know to override that, for example, to
> say, oh that's not needed anymore.

If you're running a stable system then you should not *need* to define a 
particular python version or python target manually in your USE preferences 
configuration and you should not need to add python or any lib packages in 
general, in your '/var/lib/portage/world' file.

Portage will take care of python for itself and for any packages which have 
python as a dependency.

eselect python list
eselect python update
eselect python cleanup

and running emerge --depclean -v -a

after a new python version arrives should keep your system stable without any 
more clashes, in most cases.  The devs usually do a very good job in leaving 
the stable tree in a ... stable condition.  :-)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread Neil Bothwick

On Sun, 13 Dec 2020 22:02:44 +0100, n952162 wrote:

> My problem is I can't find a diagnostic methodology.  The one I most
> often hear is, update more often, or trail and error solutions.

Neither of which is a diagnostic methodology.

> Does all that information in emerge's output point the way to the
> problem, and I just have to learn to understand it,

Yes. The output is there for a reason, work though it carefully. Most
importantly, try to fix one problem at a time. The number f new threads
you have started with different problems show how not doing that can lead
to even more confusion.

-- 
Neil Bothwick

If you don't pay your exorcist, you get repossessed.

pgpbjhIl3mMa4.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread Neil Bothwick

On Sun, 13 Dec 2020 19:58:40 +0100, n952162 wrote:

> > Nearly 2 months, quite a long time in Gentoo update terms.

> Okay, is the solution then to re-install?

Reinstalling is never a solution, just a way to run away from the
problem, until it happens again.

The solution is to work through the issues and update your system, then
don't leave it so long next time.

-- 
Neil Bothwick

A bit of tolerance is worth a megabyte of flaming. -- Henry Spencer

pgpPVxv1o9idA.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread Walter Dnes

On Sun, Dec 13, 2020 at 11:07:42AM +0100, n952162 wrote
> 
> If rust, llvm, firefox or thunderbird is in that list, I'll go crazy.

  You can "unmerge rust", followed by "emerge rust-bin" as a drop-in
replacement.  The same option is possible with firefox-bin, but
firefox-bin is hard-coded to require pulseaudio, which some people
abhor.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] update fails, but I don't see why

n952162 wrote:
> On 12/13/20 10:55 AM, Michael wrote:
>> On Sunday, 13 December 2020 08:57:53 GMT n952162 wrote:
>>> On 12/13/20 9:18 AM, Neil Bothwick wrote:
 There's a lot to trawl through here, it looks like you haven't updated

>> for quite some time.
> The (compressed) log of  a system and world update from 20. October
> (2020!) is attached.
 Nearly 2 months, quite a long time in Gentoo update terms.
>>> !!!  After 2 months the system can no longer be update-able?
>> A system can be updated and updatable after more than two months, but be
>> prepared for some manual intervention and a staged approach to
>> running emerge.
>
>
> (I just discoved your posting, thank you)
>
> By staged approach, you mean first @system and then @world?  I've just
> realized that doing this doesn't bring anything ;-)
>
>     emerge ... @system @world


That should be emerge ... @system and when you get that done, then do
emerge ... @world.  Sometimes that helps, sometimes not.  When stuck,
it's worth a try. 


>
>
>> Starting with 'eselect news read new' is advisable for any heads up
>> to changes
>> in gentoo, major packages and configuration.
>
>
> Yeah, except I wouldn't know what to do about it.
>

Almost all the time, the news item tells you if you need to do something
and what to do.  If not, it usually contains a link that explains what
is going on and what to do.  Some, maybe most, are also targeted in a
way that they only display IF they affect your system.  Example. 
Something only affects KDE and you don't have anything KDE installed. 
It won't display since it doesn't affect you.  If you do have KDE or
part of KDE installed, then it shows up.


>
>>
>> Also pay attention to any messages on the CLI when you run emerge about
>> packages which are due to be removed from portage, as you will need
>> to take
>> care of these manually in your local or some external 3rd party overlay.
>
>
> You mean, like get them out of my world file?
>
>
>>
>>
 ...

>>     What do
>>
>> grep -r python3_6 /etc/portage
> That showed that the only references are in package.use
 But what does it show. We need the output of commands, not some vague
 reference to them. I suspected there was something in package.use,
 but we
 need to know what. Those references should probably be removed but
 no one
 can say for sure without seeing them.
>>> Oh sorry.  You mentioned
>>>
>>> PYTHON_TARGETS="python3_6"
>>>
>>> and I didn't connect that with USE variables.  Here there are (with
>>> comments
>>> removed)
>> It isn't just USE flags for python-3.6 you may have set up yourself,
>> but USE
>> flags for any python version you have specified.  Under normal
>> circumstances
>> you would not need to specify these yourself and pegging python at a
>> particular version is bound to cause warnings later on, when that python
>> version has been deprecated and is no longer available in portage.
>>
>>
>>> $ sed -n -e '/^\s*#/d' -e '/python3_6/p' /etc/portage/package.use/*
>>>
 =dev-python/certifi-10001-r1 python_targets_python3_6
 =dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
 =dev-python/requests-2.24.0-r1 python_targets_python3_6
 =dev-python/chardet-3.0.4-r1 python_targets_python3_6
 =dev-python/idna-2.10-r1 python_targets_python3_6
 =dev-python/urllib3-1.25.11 python_targets_python3_6
 =dev-python/cryptography-3.2.1 python_targets_python3_6
 =dev-python/cffi-1.14.0-r3 python_targets_python3_6
 =dev-python/pycparser-2.20-r1 python_targets_python3_6
 =dev-python/ply-3.11-r1 python_targets_python3_6
 =dev-python/PySocks-1.7.1-r1 python_targets_python3_6
 =dev-python/pyopenssl-19.1.0-r1 python_targets_python3_6
 =dev-python/setuptools-50.3.0 python_targets_python3_6
 =dev-python/six-1.15.0-r1 python_targets_python3_6
>> Why had you set up these in your package.use?
>
>
> Basically, whenever emerge tells me I need USE variables, I define them.
>
> It's not clear to me how I should know to override that, for example, to
> say, oh that's not needed anymore.
>
>

I use eix-test-obsolete to find most of those.  Keep in mind, there may
be times when it says something is redundant when it isn't.  Example.  I
run unstable KDE here.  I have all of KDE listed in package.keyword. 
However, if all of KDE that is installed is stable, it says it is
redundant and can be removed.  However, a week or so later, I'll need
them again when the next unstable release hits the tree.  One has to
think about what goes and what stays. 


>>
>> If you comment them out and re-run emerge are you getting any more
>> warnings/
>> errors?
>
>
> Yes, those are all gone.
>
>
> .
>


Dale

:-)  :-)

Re: [gentoo-user] update fails, but I don't see why

n952162 wrote:
> On 12/13/20 10:02 PM, n952162 wrote:
>> On 12/13/20 9:06 PM, Dale wrote:
>>> Mark Knecht wrote:

 On Sun, Dec 13, 2020 at 12:03 PM n952162 >>> > wrote:
> On 12/13/20 9:18 AM, Neil Bothwick wrote:
>> Nearly 2 months, quite a long time in Gentoo update terms.
>>
>>
> Okay, is the solution then to re-install?
>
 Personally I wouldn't start with a reinstall.

 I'd start with my world file and remove/comment out every
 'application' not required to keep the machine running/booting. That
 should be nearly everything other than things like grub, your kernels,
 hardware drivers, terminals, etc.

 NOTE: Just because you comment something out in the world file doesn't
 mean it won't run, it just won't get updated or be part of portage's
 considerations about what to do.

 At that point emerge @world should only be considering, from a build
 POV, the stuff you really need.

 This python problem everyone is having I cannot help with. Solving
 problems like that is why people run Gentoo. With lots of power comes
 lots of responsibility. However with all the applications
 'unconsidered' you have a chance of getting the really important stuff
 built and booting.

 If I got that far then I'd start adding apps back in/uncommenting one
 or two at a time and see if I could make headway.

 I've updated machines that were a year out of date but it took days
 and days. If I didn't want to build code every week I decided I
 couldn't run Gentoo.

 HTH,
 Mark
>>>
>>> I agree.  I update once a week.  It seems a pretty good balance between
>>> not having to do it to often and not having such drastic changes
>>> that it
>>> makes things hard to work through.
>>>
>>> That said, when the tree is in the process of huge changes, it can
>>> create problems even with weekly updates.  Right now, it is python and
>>> the speed it is moving at.  Some versions that have been around for
>>> ages, 2.7, is being removed.  Then python 3.6 is leaving etc etc etc.
>>> Those of us that have been around long enough have seen this with other
>>> packages as well.  Some packages are just hard to upgrade to begin with
>>> and some create circular problems. The longer it goes between updates,
>>> the larger that problem gets to be.  You get two different packages
>>> doing that, you can find yourself running around in circles trying to
>>> get emerge to chew what it can.
>>>
>>> While I usually do updates on Sunday evening, I'm considering doing
>>> twice a week, Sunday and Wednesday.  At least until python settles down
>>> a bit. Thing is, I think the worst part may be about over.  I think 2.7
>>> is gone here, I think 3.6 is too.  That's two down.  It seems 3.7 and
>>> above will be around a while but if they start going away soon, I
>>> may do
>>> two updates a week if it starts making updates harder.
>>>
>>> Time can be a problem but sometimes it just depends on what packages
>>> have changed and how fast they have changed.  For some systems that
>>> haven't been updated in a while, having to remove python 2.7 and 3.6 in
>>> one go, can cause problems that are hard to get around.  Right now just
>>> isn't a good time to let updates get to far apart.
>>>
>>> The only thing that makes some of this survivable, getting help on this
>>> mailing list.  Some people can decode the output of emerge and find a
>>> way to work through it. Some are fairly easy, some not so much.
>>> Sometimes removing/commenting out things in the world file will help.
>>> Sometimes doing @system first helps. Sometimes you just have to update
>>> certain packages in small chunks to get through a upgrade. Finding that
>>> right option sometimes requires help.
>>>
>>> Just some thoughts.
>>>
>>> Dale
>>>
>>> :-)  :-)
>>>
>>>
>>>
>>
>> My problem is I can't find a diagnostic methodology.  The one I most
>> often hear is, update more often, or trail and error solutions.
>>
>> Does all that information in emerge's output point the way to the
>> problem, and I just have to learn to understand it,  or am I just
>> wasting my time there?  Are there better tools than log parsing? I know,
>> there are lots of good tools,  but there needs to be methodology for
>> using them (like understanding gentoo ;-) )
>>
>>
>
> But commenting stuff out of the world file is at least a path. I'll
> start with that tomorrow.
>
>
>
>


Another option some use, sets.  That way instead of updating world all
in one go, they update sets instead.  Example.  You have several GUIs
installed, KDE, Gnome and maybe even a couple more.  You break those up
into sets for each one.  Most of the time, you may can just update world
all in one go.  At times, it may be easier to update the lighter
desktops first then move to the next until they are all done.  Then
update world which should be a much smaller set of updates since most

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread antlists


On 13/12/2020 21:02, n952162 wrote:

My problem is I can't find a diagnostic methodology.  The one I most
often hear is, update more often, or trail and error solutions.

Although I haven't yet had the grief of something like this python 
thing, I've always found that unmerging everything that clashes (with 
care not to break emerge), or updating everything that will update, has 
always worked for me in the past.



Does all that information in emerge's output point the way to the
problem, and I just have to learn to understand it,  or am I just
wasting my time there?  Are there better tools than log parsing? I know,
there are lots of good tools,  but there needs to be methodology for
using them (like understanding gentoo ;-) )


Isn't that one of the major points of gentoo - that you need to 
understand what you're doing?


One more tip I'll give you. In package.use, a lot of your lines start 
with ">=". That means "any package equal or newer". If you change that 
to "=", it'll fix the current problem, but it'll come back with the next 
upgrade (or not). If you're having troubles upgrading anyway, getting 
rid of the ">" on stuff that's already problematic might make the 
underlying problem easier to understand. Especially if it's python :-)


Cheers,
Wol

Re: [gentoo-user] update fails, but I don't see why

n952162 wrote:
> On 12/13/20 9:06 PM, Dale wrote:
>>
>> I agree.  I update once a week.  It seems a pretty good balance between
>> not having to do it to often and not having such drastic changes that it
>> makes things hard to work through.
>>
>> That said, when the tree is in the process of huge changes, it can
>> create problems even with weekly updates.  Right now, it is python and
>> the speed it is moving at.  Some versions that have been around for
>> ages, 2.7, is being removed.  Then python 3.6 is leaving etc etc etc.
>> Those of us that have been around long enough have seen this with other
>> packages as well.  Some packages are just hard to upgrade to begin with
>> and some create circular problems. The longer it goes between updates,
>> the larger that problem gets to be.  You get two different packages
>> doing that, you can find yourself running around in circles trying to
>> get emerge to chew what it can.
>>
>> While I usually do updates on Sunday evening, I'm considering doing
>> twice a week, Sunday and Wednesday.  At least until python settles down
>> a bit. Thing is, I think the worst part may be about over.  I think 2.7
>> is gone here, I think 3.6 is too.  That's two down.  It seems 3.7 and
>> above will be around a while but if they start going away soon, I may do
>> two updates a week if it starts making updates harder.
>>
>> Time can be a problem but sometimes it just depends on what packages
>> have changed and how fast they have changed.  For some systems that
>> haven't been updated in a while, having to remove python 2.7 and 3.6 in
>> one go, can cause problems that are hard to get around.  Right now just
>> isn't a good time to let updates get to far apart.
>>
>> The only thing that makes some of this survivable, getting help on this
>> mailing list.  Some people can decode the output of emerge and find a
>> way to work through it. Some are fairly easy, some not so much.
>> Sometimes removing/commenting out things in the world file will help.
>> Sometimes doing @system first helps. Sometimes you just have to update
>> certain packages in small chunks to get through a upgrade.  Finding that
>> right option sometimes requires help.
>>
>> Just some thoughts.
>>
>> Dale
>>
>> :-)  :-)
>>
>>
>>
>
> My problem is I can't find a diagnostic methodology.  The one I most
> often hear is, update more often, or trail and error solutions.
>
> Does all that information in emerge's output point the way to the
> problem, and I just have to learn to understand it,  or am I just
> wasting my time there?  Are there better tools than log parsing? I know,
> there are lots of good tools,  but there needs to be methodology for
> using them (like understanding gentoo ;-) )
>
>
>


I been using Gentoo for a good long while and most of the time, I still
can't understand what it spits out onto my screen.  I've seen some say
to start at the bottom, then work your way up.  Even with that, it
doesn't help me understand it most times.  Generally, I do some trial
and error.  If that fails, post to this list including everything I can
that is relevant. 

I think the thing that has helped me the most, good defaults when
updating the system.  I set the -1 emerge option as a default to keep
the world file clean.  After that, the rest is about updating as deep as
I can to keep things as sane as possible.  Sure, it may update things
other options would leave out but it gives me a more stable system. 
It's rare that I have software crash.  It happens but is usually cleared
up with the next upgrade.  I don't have them because of some mismatch
between different versions of software tho.  Doing just a plain emerge
-u world is not near as good as emerge -uUDN world.  Just the -D will
make a big difference.

I posted this before but not sure what thread it was.  This is my
default options from make.conf.  Keep in mind, this links to the real
one in /etc/portage.  I'm still used to the old location.


root@fireball / # cat /etc/make.conf | grep emerge
EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=100 --keep-going -v -j5
--quiet-build=n -1 --unordered-display"
root@fireball / #


I haven't adjusted that in a while but may look into it later.  I've
seen a few posts about some new options.  Over the years tho, that has
given me a pretty stable system.  Depending on what packages are getting
updated upstream, one may can wait a month or so between updates.  At
times tho, weekly may be a lot easier.  It reminds me of the old
question; how do you eat a elephant?  One bite at a time is a lot easier
than trying to swallow it whole.  Updating a Gentoo system is sort of
the same way.  It is a lot easier than it was 10 or 15 years ago tho. 

Just some ideas and how I do things.  Your mileage may vary. 

Dale

:-)  :-)

Re: [gentoo-user] update fails, but I don't see why


On 12/13/20 10:02 PM, n952162 wrote:

On 12/13/20 9:06 PM, Dale wrote:

Mark Knecht wrote:


On Sun, Dec 13, 2020 at 12:03 PM n952162 mailto:n952...@web.de>> wrote:

On 12/13/20 9:18 AM, Neil Bothwick wrote:

Nearly 2 months, quite a long time in Gentoo update terms.



Okay, is the solution then to re-install?


Personally I wouldn't start with a reinstall.

I'd start with my world file and remove/comment out every
'application' not required to keep the machine running/booting. That
should be nearly everything other than things like grub, your kernels,
hardware drivers, terminals, etc.

NOTE: Just because you comment something out in the world file doesn't
mean it won't run, it just won't get updated or be part of portage's
considerations about what to do.

At that point emerge @world should only be considering, from a build
POV, the stuff you really need.

This python problem everyone is having I cannot help with. Solving
problems like that is why people run Gentoo. With lots of power comes
lots of responsibility. However with all the applications
'unconsidered' you have a chance of getting the really important stuff
built and booting.

If I got that far then I'd start adding apps back in/uncommenting one
or two at a time and see if I could make headway.

I've updated machines that were a year out of date but it took days
and days. If I didn't want to build code every week I decided I
couldn't run Gentoo.

HTH,
Mark


I agree.  I update once a week.  It seems a pretty good balance between
not having to do it to often and not having such drastic changes that it
makes things hard to work through.

That said, when the tree is in the process of huge changes, it can
create problems even with weekly updates.  Right now, it is python and
the speed it is moving at.  Some versions that have been around for
ages, 2.7, is being removed.  Then python 3.6 is leaving etc etc etc.
Those of us that have been around long enough have seen this with other
packages as well.  Some packages are just hard to upgrade to begin with
and some create circular problems. The longer it goes between updates,
the larger that problem gets to be.  You get two different packages
doing that, you can find yourself running around in circles trying to
get emerge to chew what it can.

While I usually do updates on Sunday evening, I'm considering doing
twice a week, Sunday and Wednesday.  At least until python settles down
a bit. Thing is, I think the worst part may be about over.  I think 2.7
is gone here, I think 3.6 is too.  That's two down.  It seems 3.7 and
above will be around a while but if they start going away soon, I may do
two updates a week if it starts making updates harder.

Time can be a problem but sometimes it just depends on what packages
have changed and how fast they have changed.  For some systems that
haven't been updated in a while, having to remove python 2.7 and 3.6 in
one go, can cause problems that are hard to get around.  Right now just
isn't a good time to let updates get to far apart.

The only thing that makes some of this survivable, getting help on this
mailing list.  Some people can decode the output of emerge and find a
way to work through it. Some are fairly easy, some not so much.
Sometimes removing/commenting out things in the world file will help.
Sometimes doing @system first helps. Sometimes you just have to update
certain packages in small chunks to get through a upgrade. Finding that
right option sometimes requires help.

Just some thoughts.

Dale

:-)  :-)





My problem is I can't find a diagnostic methodology.  The one I most
often hear is, update more often, or trail and error solutions.

Does all that information in emerge's output point the way to the
problem, and I just have to learn to understand it,  or am I just
wasting my time there?  Are there better tools than log parsing? I know,
there are lots of good tools,  but there needs to be methodology for
using them (like understanding gentoo ;-) )




But commenting stuff out of the world file is at least a path. I'll
start with that tomorrow.

Re: [gentoo-user] update fails, but I don't see why


On 12/13/20 10:55 AM, Michael wrote:

On Sunday, 13 December 2020 08:57:53 GMT n952162 wrote:

On 12/13/20 9:18 AM, Neil Bothwick wrote:

There's a lot to trawl through here, it looks like you haven't updated


for quite some time.

The (compressed) log of  a system and world update from 20. October
(2020!) is attached.

Nearly 2 months, quite a long time in Gentoo update terms.

!!!  After 2 months the system can no longer be update-able?

A system can be updated and updatable after more than two months, but be
prepared for some manual intervention and a staged approach to running emerge.



(I just discoved your posting, thank you)

By staged approach, you mean first @system and then @world?  I've just
realized that doing this doesn't bring anything ;-)

    emerge ... @system @world



Starting with 'eselect news read new' is advisable for any heads up to changes
in gentoo, major packages and configuration.



Yeah, except I wouldn't know what to do about it.




Also pay attention to any messages on the CLI when you run emerge about
packages which are due to be removed from portage, as you will need to take
care of these manually in your local or some external 3rd party overlay.



You mean, like get them out of my world file?






...


What do

grep -r python3_6 /etc/portage

That showed that the only references are in package.use

But what does it show. We need the output of commands, not some vague
reference to them. I suspected there was something in package.use, but we
need to know what. Those references should probably be removed but no one
can say for sure without seeing them.

Oh sorry.  You mentioned

PYTHON_TARGETS="python3_6"

and I didn't connect that with USE variables.  Here there are (with comments
removed)

It isn't just USE flags for python-3.6 you may have set up yourself, but USE
flags for any python version you have specified.  Under normal circumstances
you would not need to specify these yourself and pegging python at a
particular version is bound to cause warnings later on, when that python
version has been deprecated and is no longer available in portage.



$ sed -n -e '/^\s*#/d' -e '/python3_6/p' /etc/portage/package.use/*


=dev-python/certifi-10001-r1 python_targets_python3_6
=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
=dev-python/requests-2.24.0-r1 python_targets_python3_6
=dev-python/chardet-3.0.4-r1 python_targets_python3_6
=dev-python/idna-2.10-r1 python_targets_python3_6
=dev-python/urllib3-1.25.11 python_targets_python3_6
=dev-python/cryptography-3.2.1 python_targets_python3_6
=dev-python/cffi-1.14.0-r3 python_targets_python3_6
=dev-python/pycparser-2.20-r1 python_targets_python3_6
=dev-python/ply-3.11-r1 python_targets_python3_6
=dev-python/PySocks-1.7.1-r1 python_targets_python3_6
=dev-python/pyopenssl-19.1.0-r1 python_targets_python3_6
=dev-python/setuptools-50.3.0 python_targets_python3_6
=dev-python/six-1.15.0-r1 python_targets_python3_6

Why had you set up these in your package.use?



Basically, whenever emerge tells me I need USE variables, I define them.

It's not clear to me how I should know to override that, for example, to
say, oh that's not needed anymore.




If you comment them out and re-run emerge are you getting any more warnings/
errors?



Yes, those are all gone.

Re: [gentoo-user] update fails, but I don't see why


On 12/13/20 9:06 PM, Dale wrote:

Mark Knecht wrote:


On Sun, Dec 13, 2020 at 12:03 PM n952162 mailto:n952...@web.de>> wrote:

On 12/13/20 9:18 AM, Neil Bothwick wrote:

Nearly 2 months, quite a long time in Gentoo update terms.



Okay, is the solution then to re-install?


Personally I wouldn't start with a reinstall.

I'd start with my world file and remove/comment out every
'application' not required to keep the machine running/booting. That
should be nearly everything other than things like grub, your kernels,
hardware drivers, terminals, etc.

NOTE: Just because you comment something out in the world file doesn't
mean it won't run, it just won't get updated or be part of portage's
considerations about what to do.

At that point emerge @world should only be considering, from a build
POV, the stuff you really need.

This python problem everyone is having I cannot help with. Solving
problems like that is why people run Gentoo. With lots of power comes
lots of responsibility. However with all the applications
'unconsidered' you have a chance of getting the really important stuff
built and booting.

If I got that far then I'd start adding apps back in/uncommenting one
or two at a time and see if I could make headway.

I've updated machines that were a year out of date but it took days
and days. If I didn't want to build code every week I decided I
couldn't run Gentoo.

HTH,
Mark


I agree.  I update once a week.  It seems a pretty good balance between
not having to do it to often and not having such drastic changes that it
makes things hard to work through.

That said, when the tree is in the process of huge changes, it can
create problems even with weekly updates.  Right now, it is python and
the speed it is moving at.  Some versions that have been around for
ages, 2.7, is being removed.  Then python 3.6 is leaving etc etc etc.
Those of us that have been around long enough have seen this with other
packages as well.  Some packages are just hard to upgrade to begin with
and some create circular problems. The longer it goes between updates,
the larger that problem gets to be.  You get two different packages
doing that, you can find yourself running around in circles trying to
get emerge to chew what it can.

While I usually do updates on Sunday evening, I'm considering doing
twice a week, Sunday and Wednesday.  At least until python settles down
a bit. Thing is, I think the worst part may be about over.  I think 2.7
is gone here, I think 3.6 is too.  That's two down.  It seems 3.7 and
above will be around a while but if they start going away soon, I may do
two updates a week if it starts making updates harder.

Time can be a problem but sometimes it just depends on what packages
have changed and how fast they have changed.  For some systems that
haven't been updated in a while, having to remove python 2.7 and 3.6 in
one go, can cause problems that are hard to get around.  Right now just
isn't a good time to let updates get to far apart.

The only thing that makes some of this survivable, getting help on this
mailing list.  Some people can decode the output of emerge and find a
way to work through it. Some are fairly easy, some not so much.
Sometimes removing/commenting out things in the world file will help.
Sometimes doing @system first helps. Sometimes you just have to update
certain packages in small chunks to get through a upgrade.  Finding that
right option sometimes requires help.

Just some thoughts.

Dale

:-)  :-)





My problem is I can't find a diagnostic methodology.  The one I most
often hear is, update more often, or trail and error solutions.

Does all that information in emerge's output point the way to the
problem, and I just have to learn to understand it,  or am I just
wasting my time there?  Are there better tools than log parsing? I know,
there are lots of good tools,  but there needs to be methodology for
using them (like understanding gentoo ;-) )

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread Arve Barsnes

On Sun, 13 Dec 2020 at 20:52, n952162  wrote:
>
> I have this funny pkg entry in the emerge log:
>
> dev-python/setuptools[python_targets_python2_7(-),-python_single_target_python2_7(-)]
> required by (dev-python/ipaddress-1.0.23:0/0::gentoo, installed) USE=""
> ABI_X86="(64)" PYTHON_TARGETS="python2_7"

Didn't we go over this last week? You need to run a depclean to get
rid of old packages like dev-python/ipaddress which no longer are in
the tree. They were removed exactly because they create problems like
this.

Regards,
Arve

Re: [gentoo-user] update fails, but I don't see why

Mark Knecht wrote:
>
>
> On Sun, Dec 13, 2020 at 12:03 PM n952162  > wrote:
> >
> > On 12/13/20 9:18 AM, Neil Bothwick wrote:
> > >
> > > Nearly 2 months, quite a long time in Gentoo update terms.
> > >
> > >
> >
> > Okay, is the solution then to re-install?
> >
>
> Personally I wouldn't start with a reinstall.
>
> I'd start with my world file and remove/comment out every
> 'application' not required to keep the machine running/booting. That
> should be nearly everything other than things like grub, your kernels,
> hardware drivers, terminals, etc. 
>
> NOTE: Just because you comment something out in the world file doesn't
> mean it won't run, it just won't get updated or be part of portage's
> considerations about what to do.
>
> At that point emerge @world should only be considering, from a build
> POV, the stuff you really need.
>
> This python problem everyone is having I cannot help with. Solving
> problems like that is why people run Gentoo. With lots of power comes
> lots of responsibility. However with all the applications
> 'unconsidered' you have a chance of getting the really important stuff
> built and booting.
>
> If I got that far then I'd start adding apps back in/uncommenting one
> or two at a time and see if I could make headway.
>
> I've updated machines that were a year out of date but it took days
> and days. If I didn't want to build code every week I decided I
> couldn't run Gentoo.
>
> HTH,
> Mark

I agree.  I update once a week.  It seems a pretty good balance between
not having to do it to often and not having such drastic changes that it
makes things hard to work through. 

That said, when the tree is in the process of huge changes, it can
create problems even with weekly updates.  Right now, it is python and
the speed it is moving at.  Some versions that have been around for
ages, 2.7, is being removed.  Then python 3.6 is leaving etc etc etc. 
Those of us that have been around long enough have seen this with other
packages as well.  Some packages are just hard to upgrade to begin with
and some create circular problems. The longer it goes between updates,
the larger that problem gets to be.  You get two different packages
doing that, you can find yourself running around in circles trying to
get emerge to chew what it can. 

While I usually do updates on Sunday evening, I'm considering doing
twice a week, Sunday and Wednesday.  At least until python settles down
a bit. Thing is, I think the worst part may be about over.  I think 2.7
is gone here, I think 3.6 is too.  That's two down.  It seems 3.7 and
above will be around a while but if they start going away soon, I may do
two updates a week if it starts making updates harder. 

Time can be a problem but sometimes it just depends on what packages
have changed and how fast they have changed.  For some systems that
haven't been updated in a while, having to remove python 2.7 and 3.6 in
one go, can cause problems that are hard to get around.  Right now just
isn't a good time to let updates get to far apart. 

The only thing that makes some of this survivable, getting help on this
mailing list.  Some people can decode the output of emerge and find a
way to work through it. Some are fairly easy, some not so much. 
Sometimes removing/commenting out things in the world file will help.
Sometimes doing @system first helps. Sometimes you just have to update
certain packages in small chunks to get through a upgrade.  Finding that
right option sometimes requires help. 

Just some thoughts.

Dale

:-)  :-)

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread cal

On 12/13/20 11:31 AM, n952162 wrote:

On 12/13/20 1:09 AM, Dan Egli wrote:

Have to agree with Neil on this one. You've got a LOT of updates.
World is great, but start with emerge -UDuv @system, after you find
the culprit that is still setting python3_6 as a target. Once the
system emerge is done then you can try world again and hopefully get a
much smaller list. We can help you much better from there.

python3_6 is bad, I've got that now, but lots and lots of packages have
something similar to this:

PYTHON_TARGETS="python3_6 python3_7 python3_8 (-pypy3) -python3_9"

but I have no USE flags set to call for python3_6.

PYTHON_TARGETS is a USE_EXPAND:
https://wiki.gentoo.org/wiki/Project:Python/PYTHON_TARGETS

Some defaults are set by the profile, but this can also be overridden in
package.use. You need to find where PYTHON_TARGETS is including python3_6.

I presumed that
would come from the ebuilds, like this from dev-python/setuptools:

PYTHON_COMPAT=( python2_7 python3_{6,7,8,9} pypy3 )

This is simply specifying which versions of Python setuptools is
compatible with. Which one(s) actually get used is determined by
PYTHON_TARGETS.

Other than the PYTHON_TARGETS=, and this:

dev-python/markupsafe[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?...

I don't see where python3_6 is coming into play.

It is the PYTHON_TARGETS.

Incidently, because I saw python3_9 somewhere, I emerged that, and
selected it:

$ 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)

but it didn't change anything that I could see.

This only sets the default interpreter (which version of Python is
linked to /usr/bin/python). It does not do anything to the portage
tree, as far as I am aware. Portage Python dependencies should be
controlled with PYTHON_TARGETS.

I can't find out how to make python3.6 fallback. depclean doesn't
remove it.

Depclean doesn't remove it because your PYTHON_TARGETS output above
indicates there are packages still depending on it.

What's particularly frustrating is I can't make out from the log that
there's anything wrong.

Did you try the suggestion from earlier in the thread to try to emerge
in smaller pieces, since your @world update is so large? Portage output
is daunting when 100s of packages are involved, it is easier to start
from a smaller set and work out what's wrong.

I hope my only alternative is not just to reinstall. A reinstall takes
a couple of days of compiling.

This thread has been going since a week ago... at a certain point
reinstalling and letting portage chug through a day of compiling would
be less effort than troubleshooting a broken installation.

On 12/12/2020 3:35 PM, Neil Bothwick wrote:

On Sat, 12 Dec 2020 23:08:15 +0100, n952162 wrote:

I did a --depclean but that didn't help. I'm not seeing where an error
is indicated.

This was done with this still installed:

*/* PYTHON_TARGETS: python3_7

I commented that out and tried again, and after a few USE flag
iterations, I ended up with what seems like the same situation. Log on
request.

There's a lot to trawl through here, it looks like you haven't updated
for quite some time. I'd suggest you try to cut down on the noise by
updating only @system instead of @world.

A quick glance at some of the output suggests that you still have
PYTHON_TARGETS="python3_6" set somewhere. What do

grep -r python3_6 /etc/portage
emerge --info | grep -i python

tell you?

Re: [gentoo-user] update fails, but I don't see why


I have this funny pkg entry in the emerge log:

dev-python/setuptools[python_targets_python2_7(-),-python_single_target_python2_7(-)]
required by (dev-python/ipaddress-1.0.23:0/0::gentoo, installed) USE=""
ABI_X86="(64)" PYTHON_TARGETS="python2_7"

Where does the python2_7 come from?  The ebuild has this:

BDEPEND="dev-python/setuptools[${PYTHON_USEDEP}]"

A recursive grep in /etc/portage doesn't turn up a PYTHON_USEDEP


Question: if I HAVE NOT included a (recommended) USE flag definition
like this, could that be the cause of the python2_7 token, above,
because the default 2.7 isn't overriden?

>=dev-python/docutils-0.16 -python_targets_python2_7

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread Mark Knecht

On Sun, Dec 13, 2020 at 12:03 PM n952162  wrote:
>
> On 12/13/20 9:18 AM, Neil Bothwick wrote:
> >
> > Nearly 2 months, quite a long time in Gentoo update terms.
> >
> >
>
> Okay, is the solution then to re-install?
>

Personally I wouldn't start with a reinstall.

I'd start with my world file and remove/comment out every 'application' not
required to keep the machine running/booting. That should be nearly
everything other than things like grub, your kernels, hardware drivers,
terminals, etc.

NOTE: Just because you comment something out in the world file doesn't mean
it won't run, it just won't get updated or be part of portage's
considerations about what to do.

At that point emerge @world should only be considering, from a build POV,
the stuff you really need.

This python problem everyone is having I cannot help with. Solving problems
like that is why people run Gentoo. With lots of power comes lots of
responsibility. However with all the applications 'unconsidered' you have a
chance of getting the really important stuff built and booting.

If I got that far then I'd start adding apps back in/uncommenting one or
two at a time and see if I could make headway.

I've updated machines that were a year out of date but it took days and
days. If I didn't want to build code every week I decided I couldn't run
Gentoo.

HTH,
Mark

Re: [gentoo-user] update fails, but I don't see why


On 12/13/20 1:09 AM, Dan Egli wrote:

Have to agree with Neil on this one. You've got a LOT of updates.
World is great, but start with emerge -UDuv @system, after you find
the culprit that is still setting python3_6 as a target. Once the
system emerge is done then you can try world again and hopefully get a
much smaller list. We can help you much better from there.



python3_6 is bad, I've got that now, but lots and lots of packages have
something similar to this:

PYTHON_TARGETS="python3_6 python3_7 python3_8 (-pypy3) -python3_9"

but I have no USE flags set to call for python3_6.  I presumed that
would come from the ebuilds, like this from dev-python/setuptools:

PYTHON_COMPAT=( python2_7 python3_{6,7,8,9} pypy3 )

Other than the PYTHON_TARGETS=, and this:

 
dev-python/markupsafe[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?...

I don't see where python3_6 is coming into play.

Incidently, because I saw python3_9 somewhere, I emerged that, and
selected it:

$ 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)

but it didn't change anything that I could see.

I can't find out how to make python3.6 fallback.  depclean doesn't
remove it.

What's particularly frustrating is I can't make out from the log that
there's anything wrong.

I hope my only alternative is not just to reinstall.  A reinstall takes
a couple of days of compiling.




On 12/12/2020 3:35 PM, Neil Bothwick wrote:

On Sat, 12 Dec 2020 23:08:15 +0100, n952162 wrote:


I did a --depclean but that didn't help.  I'm not seeing where an error
is indicated.

This was done with this still installed:

   */* PYTHON_TARGETS: python3_7

I commented that out and tried again, and after a few USE flag
iterations, I ended up with what seems like the same situation. Log on
request.

There's a lot to trawl through here, it looks like you haven't updated
for quite some time. I'd suggest you try to cut down on the noise by
updating only @system instead of @world.

A quick glance at some of the output suggests that you still have
PYTHON_TARGETS="python3_6" set somewhere. What do

grep -r python3_6 /etc/portage
emerge --info | grep -i python

tell you?

Re: [gentoo-user] update fails, but I don't see why


On 12/13/20 9:18 AM, Neil Bothwick wrote:


Nearly 2 months, quite a long time in Gentoo update terms.




Okay, is the solution then to re-install?

Re: [gentoo-user] update fails, but I don't see why


(sorry Neil, that you got directly addressed again, wasn' intentional,
don't know how it happened)

Re: [gentoo-user] update fails, but I don't see why


On 12/13/20 9:18 AM, Neil Bothwick wrote:

On Sun, 13 Dec 2020 08:14:04 +0100, n952162 wrote:

...

There's a lot to trawl through here, it looks like you haven't updated
for quite some time.


The (compressed) log of  a system and world update from 20. October
(2020!) is attached.

Nearly 2 months, quite a long time in Gentoo update terms.



Yes, I see.  I'm updating another machine where I'd done a fresh install
of this:

    stage3-amd64-20201104T214503Z.tar.xz

and I'm updating 175 packages.


If rust, llvm, firefox or thunderbird is in that list, I'll go crazy.

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread Michael

On Sunday, 13 December 2020 08:57:53 GMT n952162 wrote:
> On 12/13/20 9:18 AM, Neil Bothwick wrote:
> > There's a lot to trawl through here, it looks like you haven't updated
> > 
> >>> for quite some time.
> >> 
> >> The (compressed) log of  a system and world update from 20. October
> >> (2020!) is attached.
> > 
> > Nearly 2 months, quite a long time in Gentoo update terms.
> 
> !!!  After 2 months the system can no longer be update-able?

A system can be updated and updatable after more than two months, but be 
prepared for some manual intervention and a staged approach to running emerge.  
Starting with 'eselect news read new' is advisable for any heads up to changes 
in gentoo, major packages and configuration.

Also pay attention to any messages on the CLI when you run emerge about 
packages which are due to be removed from portage, as you will need to take 
care of these manually in your local or some external 3rd party overlay.

> > ...
> > 
> >>>What do
> >>> 
> >>> grep -r python3_6 /etc/portage
> >> 
> >> That showed that the only references are in package.use
> > 
> > But what does it show. We need the output of commands, not some vague
> > reference to them. I suspected there was something in package.use, but we
> > need to know what. Those references should probably be removed but no one
> > can say for sure without seeing them.
> 
> Oh sorry.  You mentioned
> 
> PYTHON_TARGETS="python3_6"
> 
> and I didn't connect that with USE variables.  Here there are (with comments
> removed)

It isn't just USE flags for python-3.6 you may have set up yourself, but USE 
flags for any python version you have specified.  Under normal circumstances 
you would not need to specify these yourself and pegging python at a 
particular version is bound to cause warnings later on, when that python 
version has been deprecated and is no longer available in portage.

> $ sed -n -e '/^\s*#/d' -e '/python3_6/p' /etc/portage/package.use/*
> 
> >=dev-python/certifi-10001-r1 python_targets_python3_6
> >=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
> >=dev-python/requests-2.24.0-r1 python_targets_python3_6
> >=dev-python/chardet-3.0.4-r1 python_targets_python3_6
> >=dev-python/idna-2.10-r1 python_targets_python3_6
> >=dev-python/urllib3-1.25.11 python_targets_python3_6
> >=dev-python/cryptography-3.2.1 python_targets_python3_6
> >=dev-python/cffi-1.14.0-r3 python_targets_python3_6
> >=dev-python/pycparser-2.20-r1 python_targets_python3_6
> >=dev-python/ply-3.11-r1 python_targets_python3_6
> >=dev-python/PySocks-1.7.1-r1 python_targets_python3_6
> >=dev-python/pyopenssl-19.1.0-r1 python_targets_python3_6
> >=dev-python/setuptools-50.3.0 python_targets_python3_6
> >=dev-python/six-1.15.0-r1 python_targets_python3_6

Why had you set up these in your package.use?

If you comment them out and re-run emerge are you getting any more warnings/
errors?

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] update fails, but I don't see why


On 12/13/20 9:18 AM, Neil Bothwick wrote:


There's a lot to trawl through here, it looks like you haven't updated

for quite some time.


The (compressed) log of  a system and world update from 20. October
(2020!) is attached.

Nearly 2 months, quite a long time in Gentoo update terms.



!!!  After 2 months the system can no longer be update-able?



...



   What do

grep -r python3_6 /etc/portage


That showed that the only references are in package.use

But what does it show. We need the output of commands, not some vague
reference to them. I suspected there was something in package.use, but we
need to know what. Those references should probably be removed but no one
can say for sure without seeing them.




Oh sorry.  You mentioned

PYTHON_TARGETS="python3_6"

and I didn't connect that with USE variables.  Here there are (with comments 
removed)

$ sed -n -e '/^\s*#/d' -e '/python3_6/p' /etc/portage/package.use/*

=dev-python/certifi-10001-r1 python_targets_python3_6
=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
=dev-python/requests-2.24.0-r1 python_targets_python3_6
=dev-python/chardet-3.0.4-r1 python_targets_python3_6
=dev-python/idna-2.10-r1 python_targets_python3_6
=dev-python/urllib3-1.25.11 python_targets_python3_6
=dev-python/cryptography-3.2.1 python_targets_python3_6
=dev-python/cffi-1.14.0-r3 python_targets_python3_6
=dev-python/pycparser-2.20-r1 python_targets_python3_6
=dev-python/ply-3.11-r1 python_targets_python3_6
=dev-python/PySocks-1.7.1-r1 python_targets_python3_6
=dev-python/pyopenssl-19.1.0-r1 python_targets_python3_6
=dev-python/setuptools-50.3.0 python_targets_python3_6
=dev-python/six-1.15.0-r1 python_targets_python3_6

Re: [gentoo-user] update fails, but I don't see why

2020-12-13 Thread Neil Bothwick

On Sun, 13 Dec 2020 08:14:04 +0100, n952162 wrote:

You sent this to me personally instead of the list.

> > There's a lot to trawl through here, it looks like you haven't updated
> > for quite some time.  
> 
> 
> The (compressed) log of  a system and world update from 20. October
> (2020!) is attached.

Nearly 2 months, quite a long time in Gentoo update terms.

> > A quick glance at some of the output suggests that you still have
> > PYTHON_TARGETS="python3_6" set somewhere.  
> 
> 
> Can there only be one version of python on the system?

No, but 3.6 should no longer be needed.
> 
> 
> >   What do
> >
> > grep -r python3_6 /etc/portage  
> 
> 
> That showed that the only references are in package.use

But what does it show. We need the output of commands, not some vague
reference to them. I suspected there was something in package.use, but we
need to know what. Those references should probably be removed but no one
can say for sure without seeing them.

-- 
Neil Bothwick

"Two things are infinite: the universe and human stupidity;
 and I'm not sure about the the universe."
 (Albert Einstein)

pgpfX6NSv3rV7.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update fails, but I don't see why

2020-12-12 Thread Dan Egli

Have to agree with Neil on this one. You've got a LOT of updates. World 
is great, but start with emerge -UDuv @system, after you find the 
culprit that is still setting python3_6 as a target. Once the system 
emerge is done then you can try world again and hopefully get a much 
smaller list. We can help you much better from there.


On 12/12/2020 3:35 PM, Neil Bothwick wrote:

On Sat, 12 Dec 2020 23:08:15 +0100, n952162 wrote:


I did a --depclean but that didn't help.  I'm not seeing where an error
is indicated.

This was done with this still installed:

   */* PYTHON_TARGETS: python3_7

I commented that out and tried again, and after a few USE flag
iterations, I ended up with what seems like the same situation. Log on
request.

There's a lot to trawl through here, it looks like you haven't updated
for quite some time. I'd suggest you try to cut down on the noise by
updating only @system instead of @world.

A quick glance at some of the output suggests that you still have
PYTHON_TARGETS="python3_6" set somewhere. What do

grep -r python3_6 /etc/portage
emerge --info | grep -i python

tell you?



--
Dan Egli
From my Test Server

Re: [gentoo-user] update fails, but I don't see why

2020-12-12 Thread Neil Bothwick

On Sat, 12 Dec 2020 23:08:15 +0100, n952162 wrote:

> I did a --depclean but that didn't help.  I'm not seeing where an error
> is indicated.
> 
> This was done with this still installed:
> 
>   */* PYTHON_TARGETS: python3_7
> 
> I commented that out and tried again, and after a few USE flag
> iterations, I ended up with what seems like the same situation. Log on
> request.

There's a lot to trawl through here, it looks like you haven't updated
for quite some time. I'd suggest you try to cut down on the noise by
updating only @system instead of @world.

A quick glance at some of the output suggests that you still have
PYTHON_TARGETS="python3_6" set somewhere. What do

grep -r python3_6 /etc/portage
emerge --info | grep -i python

tell you?

-- 
Neil Bothwick

Never argue with an idiot. First, they bring you down to their level.
Then they beat you with experience.

pgp9ukqmfDk8J.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update fails, but I don't see why

2020-12-07 Thread John Covici

On Mon, 07 Dec 2020 07:59:13 -0500,
Arve Barsnes wrote:
> 
> On Mon, 7 Dec 2020 at 13:31, John Covici  wrote:
> > dev-python/paramiko:0
> >
> >   (dev-python/paramiko-2.7.1:0/0::gentoo, installed) USE="-doc
> >   -examples (-server) -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7
> >   python3_7 -python3_6 -python3_8" pulled in by
> >   
> > dev-python/paramiko[python_targets_python2_7(-),-python_single_target_python2_7(-)]
> >   required by (dev-vcs/bzr-2.7.1_pre:0/0::gentoo, installed) USE="sftp
> >   -curl -doc -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7"
> 
> This seems to be the first problem to solve right now. You have
> dev-vcs/bzr installed, which only supports python 2.7, and it keeps
> you back at the last dev-python/paramiko version which supported
> python 2.7. None of which are in the tree any more. Do you use bzr? If
> not, simply uninstall it.

Thanks much, that did it!!  I also had to use the mailman overlay
mentioned in the bug report, but for now, at least I can continue with
the update.  We will have to see what happens in another month!

Thanks again.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Re: [gentoo-user] update fails, but I don't see why

2020-12-07 Thread Arve Barsnes

On Mon, 7 Dec 2020 at 13:31, John Covici  wrote:
> dev-python/paramiko:0
>
>   (dev-python/paramiko-2.7.1:0/0::gentoo, installed) USE="-doc
>   -examples (-server) -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7
>   python3_7 -python3_6 -python3_8" pulled in by
>   
> dev-python/paramiko[python_targets_python2_7(-),-python_single_target_python2_7(-)]
>   required by (dev-vcs/bzr-2.7.1_pre:0/0::gentoo, installed) USE="sftp
>   -curl -doc -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7"

This seems to be the first problem to solve right now. You have
dev-vcs/bzr installed, which only supports python 2.7, and it keeps
you back at the last dev-python/paramiko version which supported
python 2.7. None of which are in the tree any more. Do you use bzr? If
not, simply uninstall it.

emerge -C dev-vcs/bzr

Regards,
Arve

Re: [gentoo-user] update fails, but I don't see why

2020-12-07 Thread John Covici

On Fri, 04 Dec 2020 03:13:19 -0500,
n952162 wrote:
> 
> [1  ]
> On 12/3/20 10:11 PM, Adam Carter wrote:
> > On Fri, Dec 4, 2020 at 8:06 AM tastytea  > > wrote:
> > 
> > On 2020-12-03 21:33+0100 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?
> > 
> > Python 3.8 is the new default target and not all packages support it
> > yet. You can put
> >   */* PYTHON_TARGETS: python3_7
> > into /etc/portage/package.use as a workaround. Don't forget to remove
> > it in a month or so.
> > 
> > 
> > Try emerge -avuUD @world (the U is the critical bit). For me, it
> > pulled in a bunch of extra rebuilds (with -python3_7 and +python3_8).
> > After that depclean removed 3.7
> 
> 
> Here is the command I use (where target is @system @world) (somebody
> once said here it can be useful to first do @system):
> 
> time emerge \
>     $pretend \
>     -v \
>     --deep \
>     --update \
>     --changed-use \
>     --verbose-conflicts \
>     --keep-going \
>     --with-bdeps=y \
>     --changed-deps \
>     --backtrack=100 \
>     $target

hmm, so I put the following line in my package.use file at the end
*/* python_targets_python3_7 python_single_target_python_3_7

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

dev-python/paramiko:0

  (dev-python/paramiko-2.7.1:0/0::gentoo, installed) USE="-doc
  -examples (-server) -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7
  python3_7 -python3_6 -python3_8" pulled in by
  
dev-python/paramiko[python_targets_python2_7(-),-python_single_target_python2_7(-)]
  required by (dev-vcs/bzr-2.7.1_pre:0/0::gentoo, installed) USE="sftp
  -curl -doc -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7"


  (dev-python/paramiko-2.7.1:0/0::gentoo, ebuild scheduled for merge)
  USE="-doc -examples (-server) -test" ABI_X86="(64)"
  PYTHON_TARGETS="python3_7 python3_8 -python3_6 -python3_9" pulled in
  by
  
dev-python/paramiko[python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
  required by (app-admin/ansible-base-2.10.3:0/0::gentoo, ebuild
  scheduled for merge) USE="-doc -test" ABI_X86="(64)"
  PYTHON_TARGETS="python3_7 python3_8 -python3_6 -python3_9"



dev-python/paramiko[python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (app-admin/ansible-2.10.1:0/0::gentoo, ebuild
scheduled for merge) USE="-doc -test" ABI_X86="(64)"
PYTHON_TARGETS="python3_7 python3_8 -python3_6 -python3_9"



dev-python/paramiko[python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (app-emulation/docker-compose-1.28.0_rc1:0/0::gentoo,
ebuild scheduled for merge) USE="-test" ABI_X86="(64)"
PYTHON_TARGETS="python3_7 python3_8 -python3_6 -python3_9"




It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.


I  masked 2.7.2 in the hope that it would help, but it did not.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Re: [gentoo-user] update fails, but I don't see why

2020-12-06 Thread Neil Bothwick

On Sat, 5 Dec 2020 09:48:23 +0100, n952162 wrote:

> "You need to check this list carefully. "  I haven't a clue what to
> check for.  I didn't add any of those.  I presume that anything I
> explicitly added would be in the world file.

You check for packages that you want to use. Those should be in @world
but it sometimes happens that something you like is pulled in as a
dependency of something else, then you get rid of "something else".

> Is the point here that I should write a script that always ensures that
> nothing in my world file has crept into this list somehow?

depclean will never remove anything in your world file - unless you
specify the package on the command line, but we are looking at the global
usage of depclean here. Just thought I'd mention that as there are  other
pedants on this list :)

-- 
Neil Bothwick

Don't put all your hypes in one home page.

pgpLdBFHln2PZ.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update fails, but I don't see why

2020-12-06 Thread Neil Bothwick

On Sat, 5 Dec 2020 09:54:50 +0100, n952162 wrote:

> > Yes you should, t keep your system consistent. You should also heed
> > the messages about unread news items and updating config files as
> > these can also have a bearing on keeping your system running
> > smoothly.  
> 
> 
> I maintain at least 7 gentoo systems, the news will have gotten read
> (seen, at any rate ;-) ) on one system or another. 

I have a similar situation, but the news items vary from one system to
the next, depending on what is installed. You should at least check the
list of unread news on each computer and then mark them all as read.

> The config files I
> do by hand.  They're actually up-to-date.  I probably shouldn't let it
> create those ._cfg* files, but I do for safe-keeping.

It's generally easier to use a config update manager like dispatch-conf or
conf-update.

-- 
Neil Bothwick

Top Oxymorons Number 35: Legally drunk

pgpHwzTahJzax.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update fails, but I don't see why

2020-12-05 Thread Dale

Victor Ivanov wrote:
> On 05/12/2020 10:13, Dale wrote:
>> that as, I learned the hard way.  Once you get Gentoo installed and all
>> the packages you want installed completed, it is wise to add the
>> --oneshot option to the defaults in make.conf.  That helps keep the
>> world file clean since you won't have packages in the world file that
>> shouldn't be there.  If later you want to add a package to the world
>> file, you have to specify that you want it added.  If it is already
>> installed, you can do a emerge -n --select y  and it adds
>> it to the world file.  It will then be maintained automatically.
>
> Excellent pro-tip for keeping your world file clean! While I
> personally use the reverse of this (i.e. I manually add -1 to things I
> do not want to end up in my world file) this is a lot more of a sane
> approach for the every day person or those new to Gentoo.
>
> On a side note, '--select y' is not necessary as it is implied by '-n'.
>
> One thing I would add as well is that regular 'world' cleaning is good
> practice to have regardless of the above. Every couple of months (on
> average, I don't really keep track) I tend to look at my world file
> and take note of entries that may have found their way there either
> automatically (lack of -1) or something I used to use and no longer
> need. These can be cleaned up with --deselect, followed by --depclean
> e.g.:
>
>     # emerge --deselect ATOM [ATOM...]
>     # emerge -a --depclean
>
> Last time round I only deselected 2-3 packages but that removed about
> 30 or so unnecessary dependencies, so pretty chuffed. Disk space is
> cheap these days and there's little reason to be so pedantic, but I
> tend to get quite a satisfying feeling when my system becomes 'leaner'
> so I do it anyway. Having fewer packages installed also helps speed up
> portage's dependency resolution stage during updates which is already
> an incredibly slow process (depending on CPU's single thread
> performance ofc).
>
> - Victor
>

I'll try leaving off the --select part next time.  At one point, it
would work only when both were there.  Maybe something changed???  Maybe
I had another setting that had to be overridden??? Who knows. 

I've looked through my world file a few times but never found anything
that didn't belong there.  With --oneshot being the default, I don't
have to worry about forgetting to add -1 or anything.  It's there
already.  There is on occasion a package I no longer use that I remove. 
For some, especially those new to Gentoo, adding that --oneshot is a
good move.  I've often wondered why it isn't the default. 

Hope the advice helps someone.  Wish I had it way back then.  ;-)

Dale

:-)  :-)

Re: [gentoo-user] update fails, but I don't see why

2020-12-05 Thread Victor Ivanov


On 05/12/2020 10:13, Dale wrote:

that as, I learned the hard way.  Once you get Gentoo installed and all
the packages you want installed completed, it is wise to add the
--oneshot option to the defaults in make.conf.  That helps keep the
world file clean since you won't have packages in the world file that
shouldn't be there.  If later you want to add a package to the world
file, you have to specify that you want it added.  If it is already
installed, you can do a emerge -n --select y  and it adds
it to the world file.  It will then be maintained automatically.


Excellent pro-tip for keeping your world file clean! While I personally 
use the reverse of this (i.e. I manually add -1 to things I do not want 
to end up in my world file) this is a lot more of a sane approach for 
the every day person or those new to Gentoo.


On a side note, '--select y' is not necessary as it is implied by '-n'.

One thing I would add as well is that regular 'world' cleaning is good 
practice to have regardless of the above. Every couple of months (on 
average, I don't really keep track) I tend to look at my world file and 
take note of entries that may have found their way there either 
automatically (lack of -1) or something I used to use and no longer 
need. These can be cleaned up with --deselect, followed by --depclean e.g.:


# emerge --deselect ATOM [ATOM...]
# emerge -a --depclean

Last time round I only deselected 2-3 packages but that removed about 30 
or so unnecessary dependencies, so pretty chuffed. Disk space is cheap 
these days and there's little reason to be so pedantic, but I tend to 
get quite a satisfying feeling when my system becomes 'leaner' so I do 
it anyway. Having fewer packages installed also helps speed up portage's 
dependency resolution stage during updates which is already an 
incredibly slow process (depending on CPU's single thread performance ofc).


- Victor



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] update fails, but I don't see why


On 12/5/20 11:13 AM, Dale wrote:

n952162 wrote:

On 12/5/20 10:06 AM, n952162 wrote:

I understand now that you've checked this list for me.  That is really
helpful.  Thank you.


(in that it shows me how to go about it).




Advice from a long term user who didn't do this in the beginning.  Read
that as, I learned the hard way.  Once you get Gentoo installed and all
the packages you want installed completed, it is wise to add the
--oneshot option to the defaults in make.conf.  That helps keep the
world file clean since you won't have packages in the world file that
shouldn't be there.  If later you want to add a package to the world
file, you have to specify that you want it added.  If it is already
installed, you can do a emerge -n --select y  and it adds
it to the world file.  It will then be maintained automatically.

When you don't do this, you end up with packages in the world file that
shouldn't be there and it causes problems later.  The way this happens
is really simple and common.  Let's say you doing a update after syncing
and a dependency package is giving you trouble.  You need to install a
package individually so that you can help move emerge along with the
updates, perhaps due to a hard block.  Thing is, unless you remember to
include the --oneshot option, it adds that package to your world file.
 From then on, emerge wants to treat it like a package you installed and
not a dependency that something else originally pulled in.  When you
have to specify a version, it gets even worse because it can cause
blockages.

This is the line in my make.conf that you may want to consider:


EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=100 --keep-going -v -j5
--quiet-build=n --oneshot --unordered-display"


Also, there is times where you want a specific version to remain
installed.  One example of this, a currently in use kernel version.  I'm
currently running gentoo-sources 5.6.7.  Since I may need to rebuild the
kernel to add a driver or something, I want that version to remain when
running --depclean.  The way to do that is this:

emerge -n --select y =sys-kernel/gentoo-sources-5.6.7


That will tell --depclean to not remove that package version.  That same
tactic can be used for any slotted package.  You could use that with gcc
if for example some program will only compile with a earlier version of
gcc.  You can have the new version of gcc but also have a older
version.  I'm pretty sure there is a way to tell emerge to use the older
gcc for that one package too.  I think that can be done in a env file.

Hope that info helps.

Dale

:-)  :-)



Yeah, I'll give that a try.

Re: [gentoo-user] update fails, but I don't see why

2020-12-05 Thread Dale

n952162 wrote:
> On 12/5/20 10:06 AM, n952162 wrote:
>>
>> I understand now that you've checked this list for me.  That is really
>> helpful.  Thank you.
>>
> (in that it shows me how to go about it).
>
>


Advice from a long term user who didn't do this in the beginning.  Read
that as, I learned the hard way.  Once you get Gentoo installed and all
the packages you want installed completed, it is wise to add the
--oneshot option to the defaults in make.conf.  That helps keep the
world file clean since you won't have packages in the world file that
shouldn't be there.  If later you want to add a package to the world
file, you have to specify that you want it added.  If it is already
installed, you can do a emerge -n --select y  and it adds
it to the world file.  It will then be maintained automatically. 

When you don't do this, you end up with packages in the world file that
shouldn't be there and it causes problems later.  The way this happens
is really simple and common.  Let's say you doing a update after syncing
and a dependency package is giving you trouble.  You need to install a
package individually so that you can help move emerge along with the
updates, perhaps due to a hard block.  Thing is, unless you remember to
include the --oneshot option, it adds that package to your world file. 
>From then on, emerge wants to treat it like a package you installed and
not a dependency that something else originally pulled in.  When you
have to specify a version, it gets even worse because it can cause
blockages. 

This is the line in my make.conf that you may want to consider:


EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=100 --keep-going -v -j5
--quiet-build=n --oneshot --unordered-display"


Also, there is times where you want a specific version to remain
installed.  One example of this, a currently in use kernel version.  I'm
currently running gentoo-sources 5.6.7.  Since I may need to rebuild the
kernel to add a driver or something, I want that version to remain when
running --depclean.  The way to do that is this:

emerge -n --select y =sys-kernel/gentoo-sources-5.6.7


That will tell --depclean to not remove that package version.  That same
tactic can be used for any slotted package.  You could use that with gcc
if for example some program will only compile with a earlier version of
gcc.  You can have the new version of gcc but also have a older
version.  I'm pretty sure there is a way to tell emerge to use the older
gcc for that one package too.  I think that can be done in a env file.

Hope that info helps. 

Dale

:-)  :-)

Re: [gentoo-user] update fails, but I don't see why


On 12/5/20 10:06 AM, n952162 wrote:


I understand now that you've checked this list for me.  That is really
helpful.  Thank you.


(in that it shows me how to go about it).

Re: [gentoo-user] update fails, but I don't see why


On 12/4/20 11:40 PM, Jack wrote:



>>> These are the packages that would be unmerged:

 sys-kernel/gentoo-sources
    selected: 4.19.72
   protected: none
 omitted: 5.4.72

It's going to remove an old version and leave a newer version.  If you
really want the old one kept, you should explicitly add it to your
world file.  (check "emerge -n", don't actually edit the world file)



 sys-kernel/gentoo-sources
    selected: 5.4.66
   protected: none
 omitted: 5.4.72

Same as above, and no, I don't know why it didn't combine these into a
single entry with two selected and one omitted.




I understand now that you've checked this list for me.  That is really
helpful.  Thank you.




 app-editors/nano
*selected*: 4.2
   protected: *none *
 omitted: *none *

This seems a bit odd, unless you have a different app-editor package
installed.  Virutal/editor is there so you always have at least one
editor installed.  If you do have another editor installed, then this
is OK.


--depclean just won my heart!  :-)

Re: [gentoo-user] update fails, but I don't see why


On 12/4/20 11:46 PM, Neil Bothwick wrote:

On Fri, 4 Dec 2020 23:19:00 +0100, n952162 wrote:


Okay, I've never done a depclean.  Is that something I need to do?  I
mean, I'm always worried it'd remove something that I need, but given
all the problems I have, I guess that'd be the lesser of evils...

Yes you should, t keep your system consistent. You should also heed the
messages about unread news items and updating config files as these can
also have a bearing on keeping your system running smoothly.



I maintain at least 7 gentoo systems, the news will have gotten read
(seen, at any rate ;-) ) on one system or another.  The config files I
do by hand.  They're actually up-to-date.  I probably shouldn't let it
create those ._cfg* files, but I do for safe-keeping.




Oh that went fast.  But just as I expected ... it's going to remove
kernel/gentoo-sources?  gcc?  The llvm that took 5 hours to compile?

Read it again. It wants to remove some versions of those but not the
latest. When you install a new kernel or compiler, portage generally does
so in a separate slot, so you have access to both old and new versions.
If you are no longer using the old version, you should let it go.




okay, I'll give that a try.  Thank you.

Re: [gentoo-user] update fails, but I don't see why

On 12/4/20 11:40 PM, Jack wrote:

You seem to not really understand how gentoo works.

Yes, that's absolutely true.

Most of the time, yes, you do need to do a depclean.  It's pretty
common to do it after every world update.  In general, it gets rid of
things emerged as a dependency of something else, and no longer
needed, either because you explicitly removed what pulled them in, or
that package was modified to no longer need it.

Yes, I've read that many times.  It's just this line in emerge(1) that
unsettles:

 WARNING: Inexperienced users are advised to use --pretend or --ask
with this
  option in order to see a preview of which packages will
be uninstalled.  Al-
  ways study the list of packages to be cleaned for any
obvious mistakes. Note
  that packages listed in package.provided (see portage(5))
may be removed  by
  depclean, even if they are part of the world set.

Do you understand why it shows separate lines for "selected" and
"omitted"

No.  Did I miss that in my readings of the documentation?

You need to check this list carefully.  If it is going to remove
anything you really want to keep, add it to the world file.  In cases
where it is removing old version(s), you should be fine, unless you
know some reason the old one is still necessary for you, but this
seems unlikely.

All selected packages: =sys-kernel/gentoo-sources-5.4.66
=media-libs/glu-9.0.1 =sys-devel/llvm-8.0.1 =app-text/openjade-1.3.2-r9
=media-libs/portmidi-217-r3 =virtual/cargo-1.37.0
=dev-python/sqlalchemy-1.3.3 =sys-devel/gcc-8.3.0-r1
=sys-devel/llvm-9.0.1 =dev-python/sphinxcontrib-websupport-1.1.0
=sys-devel/clang-runtime-8.0.1 =x11-libs/wxGTK-3.0.4-r2
=media-gfx/potrace-1.15 =x11-drivers/xf86-video-dummy-0.3.8
=sys-apps/rescan-scsi-bus-1.57-r1 =dev-libs/libcroco-0.6.13
=dev-go/blackfriday-1.2_p20150720 =sys-devel/gcc-9.2.0-r2
=app-admin/metalog-20181125 =sys-libs/cracklib-2.9.7
=sys-kernel/gentoo-sources-5.4.60 =sys-devel/clang-runtime-10.0.0
=sys-kernel/gentoo-sources-5.4.38 =dev-python/typing-3.7.4.3
=dev-lang/vala-0.42.7 =media-libs/gegl-0.3.34
=media-gfx/mypaint-brushes-1.3.0-r1 =virtual/shadow-0
=dev-python/bz2file-0.98 =sys-libs/compiler-rt-10.0.0
=dev-python/asn1crypto-0.22.0 =virtual/glu-9.0-r2
=sys-devel/binutils-2.32-r1 =sys-apps/sg3_utils-1.42
=sys-kernel/gentoo-sources-4.19.72 =virtual/python-enum34-2
=x11-drivers/xf86-video-intel-2.99.917_p20190301 =dev-lang/mujs-1.0.5
=app-editors/nano-4.2 =dev-python/pyblake2-1.1.2
=app-admin/killproc-2.13-r1 =sys-libs/compiler-rt-sanitizers-10.0.0
=dev-python/whoosh-2.7.4 =x11-drivers/xf86-video-vesa-2.4.0
=sys-libs/compiler-rt-8.0.1 =dev-python/sphinx_rtd_theme-0.2.4
=sys-fs/btrfs-progs-4.19 =sys-devel/clang-8.0.1 =virtual/libffi-3.3_rc0
=sys-devel/clang-runtime-9.0.1 =x11-libs/libXScrnSaver-1.2.3
=sys-devel/clang-9.0.1 =virtual/modutils-0 =sys-apps/sdparm-1.10
=media-libs/freeglut-3.2.1 =dev-lang/vala-0.46.7
=x11-drivers/xf86-input-keyboard-1.9.0
=x11-drivers/xf86-video-nouveau-1.0.16
=dev-go/sanitized-anchor-name-0_pre20151027
=x11-drivers/xf86-video-fbdev-0.5.0 =x11-drivers/xf86-input-mouse-1.9.3
=app-text/docbook-sgml-dtd-3.0-r4 =sys-libs/compiler-rt-9.0.1
=dev-libs/iniparser-3.1-r1 =sys-devel/binutils-2.33.1-r1
=virtual/python-typing-0-r1 =sys-libs/compiler-rt-sanitizers-8.0.1
=dev-python/pyxattr-0.6.0-r1 =app-text/docbook-dsssl-stylesheets-1.79-r4
=dev-libs/libpthread-stubs-0.4-r1 =virtual/python-ipaddress-1.0-r1
=sys-libs/compiler-rt-sanitizers-9.0.1

"You need to check this list carefully. "  I haven't a clue what to
check for.  I didn't add any of those.  I presume that anything I
explicitly added would be in the world file.

Is the point here that I should write a script that always ensures that
nothing in my world file has crept into this list somehow?

I'm sure there's lots of things that I need that I didn't explicitly
add.  But I wouldn't know what they are, in order to check for them. 
... okay, I see gcc up there.  I know I need gcc.  Presumably, it's just
one slot that's going to be removed. So I need to check if another slot
will remain populated.  That's presumably in the previous emerge output
somewhere.  Is that the point?

I mean, at one point of time or another, everything there was needed,
whether I recognize it or not.  That's not a sufficient test - whether
it's obvious to me or not.

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

Explicitly stated, just so you know.

Okay, indeed, I did miss that and it's significance.  I'll look again
and see if I dare doing a depclean.

Jack

Re: [gentoo-user] update fails, but I don't see why

2020-12-04 Thread Neil Bothwick

On Fri, 4 Dec 2020 23:19:00 +0100, n952162 wrote:

> > Okay, I've never done a depclean.  Is that something I need to do?  I
> > mean, I'm always worried it'd remove something that I need, but given
> > all the problems I have, I guess that'd be the lesser of evils...

Yes you should, t keep your system consistent. You should also heed the
messages about unread news items and updating config files as these can
also have a bearing on keeping your system running smoothly.

> Oh that went fast.  But just as I expected ... it's going to remove
> kernel/gentoo-sources?  gcc?  The llvm that took 5 hours to compile?

Read it again. It wants to remove some versions of those but not the
latest. When you install a new kernel or compiler, portage generally does
so in a separate slot, so you have access to both old and new versions.
If you are no longer using the old version, you should let it go.

-- 
Neil Bothwick

"If you can't explain it simply, you don't understand it well enough."
 (Albert Einstein)

pgpnQhZgMKzjA.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] update fails, but I don't see why

2020-12-04 Thread Jack


You seem to not really understand how gentoo works.

On 2020.12.04 17:19, n952162 wrote:

On 12/4/20 11:13 PM, n952162 wrote:

On 12/4/20 10:49 PM, Arve Barsnes wrote:

On Fri, 4 Dec 2020 at 21:24, n952162  wrote:
I guess you mean, remove them all and then let emerge tell me  
which

ones
I need.  I'll try that.  But isn't '=' more restrictive than '>=',
promising me troubles earlier?

The earlier you encounter any conflicts, they're generally easier to
solve.



No, that didn't work.  After about 4 iterations of supplying newly
required USE flags, I ended up with this

(this after commenting out all the python dependencies in
/etc/portage/package.use/* and adding back in what emerge wanted):


Hard to say what the problem is when I don't know what you've added
back to USE, but I wonder what state your portage tree is in,  
because

it seems like many of the packages creating your conflicts, like the
two below, dev-python/ipaddress and dev-python/futures, don't exist  
at
all in my tree. They were removed several weeks ago. When did you  
last

sync? If recently, when did you last --depclean?


dev-python/setuptools[python_targets_python2_7(-),-python_single_target_python2_7(-)]

required by (dev-python/ipaddress-1.0.23:0/0::gentoo, installed)  
USE=""

ABI_X86="(64)" PYTHON_TARGETS="python2_7"

dev-python/setuptools[python_targets_python2_7(-),-python_single_target_python2_7(-)]

required by (dev-python/futures-3.1.1:0/0::gentoo, installed)
USE="-doc"
ABI_X86="(64)" PYTHON_TARGETS="python2_7"


Regards,
Arve



Okay, I've never done a depclean.  Is that something I need to do?  I
mean, I'm always worried it'd remove something that I need, but given
all the problems I have, I guess that'd be the lesser of evils...
Most of the time, yes, you do need to do a depclean.  It's pretty  
common to do it after every world update.  In general, it gets rid of  
things emerged as a dependency of something else, and no longer needed,  
either because you explicitly removed what pulled them in, or that  
package was modified to no longer need it.


I'll give that a go and go to bed.



Oh that went fast.  But just as I expected ... it's going to remove
kernel/gentoo-sources?  gcc?  The llvm that took 5 hours to compile?
Do you understand why it shows separate lines for "selected" and  
"omitted"


>>> These are the packages that would be unmerged:

 sys-kernel/gentoo-sources
    selected: 4.19.72
   protected: none
 omitted: 5.4.72
It's going to remove an old version and leave a newer version.  If you  
really want the old one kept, you should explicitly add it to your  
world file.  (check "emerge -n", don't actually edit the world file)


 dev-lang/mujs
    selected: 1.0.5
   protected: none
 omitted: none

 sys-fs/btrfs-progs
    selected: 4.19
   protected: none
 omitted: none

 virtual/shadow
    selected: 0
   protected: none
 omitted: none

 media-libs/gegl
    selected: 0.3.34
   protected: none
 omitted: 0.4.22

 dev-python/sphinx_rtd_theme
    selected: 0.2.4
   protected: none
 omitted: none

 dev-go/blackfriday
    selected: 1.2_p20150720
   protected: none
 omitted: none

 media-gfx/mypaint-brushes
    selected: 1.3.0-r1
   protected: none
 omitted: 2.0.2

 dev-lang/vala
    selected: 0.42.7
   protected: none
 omitted: 0.48.9

 x11-drivers/xf86-video-nouveau
    selected: 1.0.16
   protected: none
 omitted: none

 media-gfx/potrace
    selected: 1.15
   protected: none
 omitted: none

 x11-drivers/xf86-video-dummy
    selected: 0.3.8
   protected: none
 omitted: none

 sys-apps/sdparm
    selected: 1.10
   protected: none
 omitted: none

 dev-python/sphinxcontrib-websupport
    selected: 1.1.0
   protected: none
 omitted: none

 dev-lang/vala
    selected: 0.46.7
   protected: none
 omitted: 0.48.9

 virtual/python-ipaddress
    selected: 1.0-r1
   protected: none
 omitted: none

 sys-kernel/gentoo-sources
    selected: 5.4.66
   protected: none
 omitted: 5.4.72
Same as above, and no, I don't know why it didn't combine these into a  
single entry with two selected and one omitted.


 dev-python/bz2file
    selected: 0.98
   protected: none
 omitted: none

 dev-python/asn1crypto
    selected: 0.22.0
   protected: none
 omitted: none

 app-text/docbook-dsssl-stylesheets
    selected: 1.79-r4
   protected: none
 omitted: none

 x11-drivers/xf86-video-vesa
    selected: 2.4.0
   protected: none
 omitted: none

 x11-libs/wxGTK
    selected: 3.0.4-r2
   protected: none
 omitted: 3.0.4-r302


!!! 'app-editors/nano' (virtual/editor) is part of your system  
profile.

!!! Unmerging it may be damaging to your system.


 app-editors/nano
    selected: 4.2
   protected: none
 omitted: none
This seems a bit odd, unless you have a different app-editor package  
installed.  Virutal/editor is there so you always have at least one  
editor installed.  If you do have another editor installed, then this  
is OK.

Re: [gentoo-user] update fails, but I don't see why


On 12/4/20 11:13 PM, n952162 wrote:

On 12/4/20 10:49 PM, Arve Barsnes wrote:

On Fri, 4 Dec 2020 at 21:24, n952162  wrote:

I guess you mean, remove them all and then let emerge tell me which
ones
I need.  I'll try that.  But isn't '=' more restrictive than '>=',
promising me troubles earlier?

The earlier you encounter any conflicts, they're generally easier to
solve.



No, that didn't work.  After about 4 iterations of supplying newly
required USE flags, I ended up with this

(this after commenting out all the python dependencies in
/etc/portage/package.use/* and adding back in what emerge wanted):


Hard to say what the problem is when I don't know what you've added
back to USE, but I wonder what state your portage tree is in, because
it seems like many of the packages creating your conflicts, like the
two below, dev-python/ipaddress and dev-python/futures, don't exist at
all in my tree. They were removed several weeks ago. When did you last
sync? If recently, when did you last --depclean?


dev-python/setuptools[python_targets_python2_7(-),-python_single_target_python2_7(-)]

required by (dev-python/ipaddress-1.0.23:0/0::gentoo, installed) USE=""
ABI_X86="(64)" PYTHON_TARGETS="python2_7"

dev-python/setuptools[python_targets_python2_7(-),-python_single_target_python2_7(-)]

required by (dev-python/futures-3.1.1:0/0::gentoo, installed)
USE="-doc"
ABI_X86="(64)" PYTHON_TARGETS="python2_7"


Regards,
Arve



Okay, I've never done a depclean.  Is that something I need to do?  I
mean, I'm always worried it'd remove something that I need, but given
all the problems I have, I guess that'd be the lesser of evils...

I'll give that a go and go to bed.



Oh that went fast.  But just as I expected ... it's going to remove
kernel/gentoo-sources?  gcc?  The llvm that took 5 hours to compile?

>>> These are the packages that would be unmerged:

 sys-kernel/gentoo-sources
    selected: 4.19.72
   protected: none
 omitted: 5.4.72

 dev-lang/mujs
    selected: 1.0.5
   protected: none
 omitted: none

 sys-fs/btrfs-progs
    selected: 4.19
   protected: none
 omitted: none

 virtual/shadow
    selected: 0
   protected: none
 omitted: none

 media-libs/gegl
    selected: 0.3.34
   protected: none
 omitted: 0.4.22

 dev-python/sphinx_rtd_theme
    selected: 0.2.4
   protected: none
 omitted: none

 dev-go/blackfriday
    selected: 1.2_p20150720
   protected: none
 omitted: none

 media-gfx/mypaint-brushes
    selected: 1.3.0-r1
   protected: none
 omitted: 2.0.2

 dev-lang/vala
    selected: 0.42.7
   protected: none
 omitted: 0.48.9

 x11-drivers/xf86-video-nouveau
    selected: 1.0.16
   protected: none
 omitted: none

 media-gfx/potrace
    selected: 1.15
   protected: none
 omitted: none

 x11-drivers/xf86-video-dummy
    selected: 0.3.8
   protected: none
 omitted: none

 sys-apps/sdparm
    selected: 1.10
   protected: none
 omitted: none

 dev-python/sphinxcontrib-websupport
    selected: 1.1.0
   protected: none
 omitted: none

 dev-lang/vala
    selected: 0.46.7
   protected: none
 omitted: 0.48.9

 virtual/python-ipaddress
    selected: 1.0-r1
   protected: none
 omitted: none

 sys-kernel/gentoo-sources
    selected: 5.4.66
   protected: none
 omitted: 5.4.72

 dev-python/bz2file
    selected: 0.98
   protected: none
 omitted: none

 dev-python/asn1crypto
    selected: 0.22.0
   protected: none
 omitted: none

 app-text/docbook-dsssl-stylesheets
    selected: 1.79-r4
   protected: none
 omitted: none

 x11-drivers/xf86-video-vesa
    selected: 2.4.0
   protected: none
 omitted: none

 x11-libs/wxGTK
    selected: 3.0.4-r2
   protected: none
 omitted: 3.0.4-r302


!!! 'app-editors/nano' (virtual/editor) is part of your system profile.
!!! Unmerging it may be damaging to your system.


 app-editors/nano
    selected: 4.2
   protected: none
 omitted: none

 sys-kernel/gentoo-sources
    selected: 5.4.60
   protected: none
 omitted: 5.4.72

 x11-drivers/xf86-video-intel
    selected: 2.99.917_p20190301
   protected: none
 omitted: none

 dev-python/pyxattr
    selected: 0.6.0-r1
   protected: none
 omitted: none

 sys-devel/clang-runtime
    selected: 10.0.0
   protected: none
 omitted: 10.0.1

 app-admin/metalog
    selected: 20181125
   protected: none
 omitted: none

 sys-libs/cracklib
    selected: 2.9.7
   protected: none
 omitted: none

 dev-libs/iniparser
    selected: 3.1-r1
   protected: none
 omitted: none

 dev-libs/libcroco
    selected: 0.6.13
   protected: none
 omitted: none

 x11-drivers/xf86-input-mouse
    selected: 1.9.3
   protected: none
 omitted: none

 virtual/python-enum34
    selected: 2
   protected: none
 omitted: none

 x11-drivers/xf86-video-fbdev
    selected: 0.5.0
   protected: none
 omitted: none

 media-libs/freeglut
    selected: 3.2.1
   protected: none
 omitted: none

 x11-drivers/xf86-input-keyboard
    selected: 1.9.0
   protected:

Re: [gentoo-user] update fails, but I don't see why


On 12/4/20 10:49 PM, Arve Barsnes wrote:

On Fri, 4 Dec 2020 at 21:24, n952162  wrote:

I guess you mean, remove them all and then let emerge tell me which ones
I need.  I'll try that.  But isn't '=' more restrictive than '>=',
promising me troubles earlier?

The earlier you encounter any conflicts, they're generally easier to solve.



No, that didn't work.  After about 4 iterations of supplying newly
required USE flags, I ended up with this

(this after commenting out all the python dependencies in
/etc/portage/package.use/* and adding back in what emerge wanted):


Hard to say what the problem is when I don't know what you've added
back to USE, but I wonder what state your portage tree is in, because
it seems like many of the packages creating your conflicts, like the
two below, dev-python/ipaddress and dev-python/futures, don't exist at
all in my tree. They were removed several weeks ago. When did you last
sync? If recently, when did you last --depclean?


dev-python/setuptools[python_targets_python2_7(-),-python_single_target_python2_7(-)]
required by (dev-python/ipaddress-1.0.23:0/0::gentoo, installed) USE=""
ABI_X86="(64)" PYTHON_TARGETS="python2_7"

dev-python/setuptools[python_targets_python2_7(-),-python_single_target_python2_7(-)]
required by (dev-python/futures-3.1.1:0/0::gentoo, installed) USE="-doc"
ABI_X86="(64)" PYTHON_TARGETS="python2_7"


Regards,
Arve



Okay, I've never done a depclean.  Is that something I need to do?  I
mean, I'm always worried it'd remove something that I need, but given
all the problems I have, I guess that'd be the lesser of evils...

I'll give that a go and go to bed.

Re: [gentoo-user] update fails, but I don't see why

2020-12-04 Thread Arve Barsnes

On Fri, 4 Dec 2020 at 21:24, n952162  wrote:
> > I guess you mean, remove them all and then let emerge tell me which ones
> > I need.  I'll try that.  But isn't '=' more restrictive than '>=',
> > promising me troubles earlier?

The earlier you encounter any conflicts, they're generally easier to solve.

> No, that didn't work.  After about 4 iterations of supplying newly
> required USE flags, I ended up with this
>
> (this after commenting out all the python dependencies in
> /etc/portage/package.use/* and adding back in what emerge wanted):

Hard to say what the problem is when I don't know what you've added
back to USE, but I wonder what state your portage tree is in, because
it seems like many of the packages creating your conflicts, like the
two below, dev-python/ipaddress and dev-python/futures, don't exist at
all in my tree. They were removed several weeks ago. When did you last
sync? If recently, when did you last --depclean?

> dev-python/setuptools[python_targets_python2_7(-),-python_single_target_python2_7(-)]
> required by (dev-python/ipaddress-1.0.23:0/0::gentoo, installed) USE=""
> ABI_X86="(64)" PYTHON_TARGETS="python2_7"
>
> dev-python/setuptools[python_targets_python2_7(-),-python_single_target_python2_7(-)]
> required by (dev-python/futures-3.1.1:0/0::gentoo, installed) USE="-doc"
> ABI_X86="(64)" PYTHON_TARGETS="python2_7"

Regards,
Arve

Re: [gentoo-user] update fails, but I don't see why


On 12/4/20 9:00 PM, n952162 wrote:

On 12/4/20 8:52 PM, n952162 wrote:


On 12/4/20 11:07 AM, Arve Barsnes wrote:

On Fri, 4 Dec 2020 at 10:34, n952162  wrote:

Forgotten about?  I'm flattered!  That would imply I understood
something here ...

Here's my python situation:

$ sed -n -e '/^\s*#/d' -e '/python/Ip' * | sort -u
*/* PYTHON_TARGETS: python3_7
  >=dev-lang/python-2.7.16:2.7 sqlite
  >=dev-lang/python-3.6.9 sqlite
  >=dev-libs/libxml2-2.9.9-r1 python
  >=dev-python/PySocks-1.7.1 python_targets_python3_6
  >=dev-python/certifi-10001-r1 python_targets_python3_7
  >=dev-python/certifi-2019.11.28 python_targets_python3_6
  >=dev-python/cffi-1.14.0 python_targets_python3_6
  >=dev-python/chardet-3.0.4 python_targets_python3_6
  >=dev-python/cryptography-2.8-r1 python_targets_python3_6
  >=dev-python/docutils-0.16 -python_targets_python2_7
  >=dev-python/idna-2.8 python_targets_python3_6
  >=dev-python/isodate-0.6.0-r1 python_targets_python3_6
  >=dev-python/ply-3.11 python_targets_python3_6
  >=dev-python/pycparser-2.20 python_targets_python3_6
  >=dev-python/pycryptodome-3.9.4 python_targets_python3_6
  >=dev-python/pyopenssl-19.1.0 python_targets_python3_6
  >=dev-python/requests-2.23.0 python_targets_python3_6
  >=dev-python/setuptools-46.4.0-r1 python_targets_python3_6
  >=dev-python/setuptools-50.3.0 python_targets_python3_7
  >=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
  >=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_7
  >=dev-python/six-1.14.0 python_targets_python3_6
  >=dev-python/six-1.15.0-r1 python_targets_python3_7
  >=dev-python/urllib3-1.25.8 python_targets_python3_6
  >=virtual/python-cffi-0 python_targets_python3_6
dev-lang/python readline
net-print/cups X python


I would try simply removing all of those python_targets_python3_x
lines, and add back only those that you actually need, with an
explicit version (that is '=' instead of '>='). I had a long list of
packages on 3_6 for a while, but it's been several weeks/months since
I could remove them all.

Regards,
Arve



How would I know which ones I need?  Aren't those specified by the
package author based on special needs?  Otherwise, why would they be
specified, instead of left to default?

I can understand that if I have two packages depending on different
versions of the same dependency, the older one is probably left over
from an earlier update and could be removed ... although at first
glance, I don't see that situation here.



I guess you mean, remove them all and then let emerge tell me which ones
I need.  I'll try that.  But isn't '=' more restrictive than '>=',
promising me troubles earlier?




No, that didn't work.  After about 4 iterations of supplying newly
required USE flags, I ended up with this

(this after commenting out all the python dependencies in
/etc/portage/package.use/* and adding back in what emerge wanted):


These are the packages that would be merged, in order:

Calculating dependencies
 * IMPORTANT: 9 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.

 * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
 * sections of the emerge man page to learn how to update config files.
.. .. done!
[ebuild U  ] sys-libs/timezone-data-2020d::gentoo [2020a::gentoo]
USE="nls -leaps-timezone -zic-slim%" 647 KiB
[ebuild U  ] sys-devel/gcc-config-2.3.2-r1::gentoo [2.3.2::gentoo]
USE="(cc-wrappers%*) (native-symlinks)" 0 KiB
[ebuild U  ] dev-lang/go-1.15.5:0/1.15.5::gentoo
[1.14.9:0/1.14.9::gentoo] 22480 KiB
[ebuild U  ] app-text/poppler-data-0.4.10::gentoo [0.4.9::gentoo]
4393 KiB
[ebuild U  ] sys-devel/llvm-common-11.0.0::gentoo [10.0.1::gentoo]
119867 KiB
[ebuild  N ] acct-group/pcap-0::gentoo  0 KiB
[ebuild  r  U  ] dev-libs/liblinear-241:0/4::gentoo [210-r1:0/3::gentoo]
547 KiB
[ebuild U  ] x11-misc/util-macros-1.19.2-r2::gentoo
[1.19.2-r1::gentoo] 0 KiB
[ebuild U  ] dev-util/boost-build-1.74.0::gentoo [1.72.0::gentoo]
USE="-examples" 107032 KiB
[ebuild  N ] acct-user/pcap-0::gentoo  0 KiB
[ebuild U  ] app-shells/push-3.4::gentoo [2.0-r1::gentoo] 3 KiB
[ebuild U  ] app-emulation/docker-proxy-0.8.0_p20201105::gentoo
[0.8.0_p20200617::gentoo] 3307 KiB
[ebuild U  ] dev-lang/mujs-1.0.9:0/1.0.9::gentoo [1.0.5:0/0::gentoo]
USE="-static-libs" 121 KiB
[ebuild U  ] virtual/tmpfiles-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild U  ] app-admin/mcelog-173::gentoo [170::gentoo]
USE="(-selinux)" 306 KiB
[ebuild U  ] dev-libs/boost-1.74.0-r1:0/1.74.0::gentoo
[1.72.0-r2:0/1.72.0::gentoo] USE="bzip2 nls threads zlib -context -debug
-doc -icu -lzma -mpi (-numpy) -python -static-libs -tools -zstd"
ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_7 python3_8*
-python3_6 -python3_9%" 0 KiB
[ebuild U  ] media-libs/libpng-1.6.37-r2:0/16::gentoo
[1.6.37:0/16::gentoo] USE="apng -static-libs (-neon%)" ABI_X86="(64) -32
(-x32)" CPU_FLAGS_X86="sse" 0 KiB
[ebuild U  ]

Re: [gentoo-user] update fails, but I don't see why

On 12/4/20 8:52 PM, n952162 wrote:

On 12/4/20 11:07 AM, Arve Barsnes wrote:

On Fri, 4 Dec 2020 at 10:34, n952162  wrote:

Forgotten about?  I'm flattered!  That would imply I understood
something here ...

Here's my python situation:

$ sed -n -e '/^\s*#/d' -e '/python/Ip' * | sort -u
*/* PYTHON_TARGETS: python3_7
  >=dev-lang/python-2.7.16:2.7 sqlite
  >=dev-lang/python-3.6.9 sqlite
  >=dev-libs/libxml2-2.9.9-r1 python
  >=dev-python/PySocks-1.7.1 python_targets_python3_6
  >=dev-python/certifi-10001-r1 python_targets_python3_7
  >=dev-python/certifi-2019.11.28 python_targets_python3_6
  >=dev-python/cffi-1.14.0 python_targets_python3_6
  >=dev-python/chardet-3.0.4 python_targets_python3_6
  >=dev-python/cryptography-2.8-r1 python_targets_python3_6
  >=dev-python/docutils-0.16 -python_targets_python2_7
  >=dev-python/idna-2.8 python_targets_python3_6
  >=dev-python/isodate-0.6.0-r1 python_targets_python3_6
  >=dev-python/ply-3.11 python_targets_python3_6
  >=dev-python/pycparser-2.20 python_targets_python3_6
  >=dev-python/pycryptodome-3.9.4 python_targets_python3_6
  >=dev-python/pyopenssl-19.1.0 python_targets_python3_6
  >=dev-python/requests-2.23.0 python_targets_python3_6
  >=dev-python/setuptools-46.4.0-r1 python_targets_python3_6
  >=dev-python/setuptools-50.3.0 python_targets_python3_7
  >=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
  >=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_7
  >=dev-python/six-1.14.0 python_targets_python3_6
  >=dev-python/six-1.15.0-r1 python_targets_python3_7
  >=dev-python/urllib3-1.25.8 python_targets_python3_6
  >=virtual/python-cffi-0 python_targets_python3_6
dev-lang/python readline
net-print/cups X python

I would try simply removing all of those python_targets_python3_x
lines, and add back only those that you actually need, with an
explicit version (that is '=' instead of '>='). I had a long list of
packages on 3_6 for a while, but it's been several weeks/months since
I could remove them all.

Regards,
Arve

How would I know which ones I need?  Aren't those specified by the
package author based on special needs?  Otherwise, why would they be
specified, instead of left to default?

I can understand that if I have two packages depending on different
versions of the same dependency, the older one is probably left over
from an earlier update and could be removed ... although at first
glance, I don't see that situation here.

I guess you mean, remove them all and then let emerge tell me which ones
I need.  I'll try that.  But isn't '=' more restrictive than '>=',
promising me troubles earlier?

Re: [gentoo-user] update fails, but I don't see why

On 12/4/20 11:07 AM, Arve Barsnes wrote:

On Fri, 4 Dec 2020 at 10:34, n952162  wrote:

Forgotten about?  I'm flattered!  That would imply I understood
something here ...

Here's my python situation:

$ sed -n -e '/^\s*#/d' -e '/python/Ip' * | sort -u
*/* PYTHON_TARGETS: python3_7
  >=dev-lang/python-2.7.16:2.7 sqlite
  >=dev-lang/python-3.6.9 sqlite
  >=dev-libs/libxml2-2.9.9-r1 python
  >=dev-python/PySocks-1.7.1 python_targets_python3_6
  >=dev-python/certifi-10001-r1 python_targets_python3_7
  >=dev-python/certifi-2019.11.28 python_targets_python3_6
  >=dev-python/cffi-1.14.0 python_targets_python3_6
  >=dev-python/chardet-3.0.4 python_targets_python3_6
  >=dev-python/cryptography-2.8-r1 python_targets_python3_6
  >=dev-python/docutils-0.16 -python_targets_python2_7
  >=dev-python/idna-2.8 python_targets_python3_6
  >=dev-python/isodate-0.6.0-r1 python_targets_python3_6
  >=dev-python/ply-3.11 python_targets_python3_6
  >=dev-python/pycparser-2.20 python_targets_python3_6
  >=dev-python/pycryptodome-3.9.4 python_targets_python3_6
  >=dev-python/pyopenssl-19.1.0 python_targets_python3_6
  >=dev-python/requests-2.23.0 python_targets_python3_6
  >=dev-python/setuptools-46.4.0-r1 python_targets_python3_6
  >=dev-python/setuptools-50.3.0 python_targets_python3_7
  >=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
  >=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_7
  >=dev-python/six-1.14.0 python_targets_python3_6
  >=dev-python/six-1.15.0-r1 python_targets_python3_7
  >=dev-python/urllib3-1.25.8 python_targets_python3_6
  >=virtual/python-cffi-0 python_targets_python3_6
dev-lang/python readline
net-print/cups X python

I would try simply removing all of those python_targets_python3_x
lines, and add back only those that you actually need, with an
explicit version (that is '=' instead of '>='). I had a long list of
packages on 3_6 for a while, but it's been several weeks/months since
I could remove them all.

Regards,
Arve

How would I know which ones I need?  Aren't those specified by the
package author based on special needs?  Otherwise, why would they be
specified, instead of left to default?

I can understand that if I have two packages depending on different
versions of the same dependency, the older one is probably left over
from an earlier update and could be removed ... although at first
glance, I don't see that situation here.

Re: [gentoo-user] update fails, but I don't see why

2020-12-04 Thread Adam Carter

> There seems to be some python3_6 and even python2_7 in your error
> output, maybe you have set some older python targets somewhere that
> you've forgotten about?
>

Yeah I was thinking the same.

If 'grep -i python /etc/portage/*' is not empty, try making it that way. On
my system with 1323 packages, having these empty and running emerge -avuUD
world just worked. 3_7 went away and everything was 3_8.

Re: [gentoo-user] update fails, but I don't see why

2020-12-04 Thread Arve Barsnes

On Fri, 4 Dec 2020 at 10:34, n952162  wrote:
> Forgotten about?  I'm flattered!  That would imply I understood
> something here ...
>
> Here's my python situation:
>
> $ sed -n -e '/^\s*#/d' -e '/python/Ip' * | sort -u
> */* PYTHON_TARGETS: python3_7
>  >=dev-lang/python-2.7.16:2.7 sqlite
>  >=dev-lang/python-3.6.9 sqlite
>  >=dev-libs/libxml2-2.9.9-r1 python
>  >=dev-python/PySocks-1.7.1 python_targets_python3_6
>  >=dev-python/certifi-10001-r1 python_targets_python3_7
>  >=dev-python/certifi-2019.11.28 python_targets_python3_6
>  >=dev-python/cffi-1.14.0 python_targets_python3_6
>  >=dev-python/chardet-3.0.4 python_targets_python3_6
>  >=dev-python/cryptography-2.8-r1 python_targets_python3_6
>  >=dev-python/docutils-0.16 -python_targets_python2_7
>  >=dev-python/idna-2.8 python_targets_python3_6
>  >=dev-python/isodate-0.6.0-r1 python_targets_python3_6
>  >=dev-python/ply-3.11 python_targets_python3_6
>  >=dev-python/pycparser-2.20 python_targets_python3_6
>  >=dev-python/pycryptodome-3.9.4 python_targets_python3_6
>  >=dev-python/pyopenssl-19.1.0 python_targets_python3_6
>  >=dev-python/requests-2.23.0 python_targets_python3_6
>  >=dev-python/setuptools-46.4.0-r1 python_targets_python3_6
>  >=dev-python/setuptools-50.3.0 python_targets_python3_7
>  >=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
>  >=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_7
>  >=dev-python/six-1.14.0 python_targets_python3_6
>  >=dev-python/six-1.15.0-r1 python_targets_python3_7
>  >=dev-python/urllib3-1.25.8 python_targets_python3_6
>  >=virtual/python-cffi-0 python_targets_python3_6
> dev-lang/python readline
> net-print/cups X python


I would try simply removing all of those python_targets_python3_x
lines, and add back only those that you actually need, with an
explicit version (that is '=' instead of '>='). I had a long list of
packages on 3_6 for a while, but it's been several weeks/months since
I could remove them all.

Regards,
Arve

Re: [gentoo-user] update fails, but I don't see why


On 12/4/20 9:53 AM, Arve Barsnes wrote:

On Fri, 4 Dec 2020 at 09:40, n952162  wrote:

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

dev-python/requests:0

(dev-python/requests-2.24.0-r1:0/0::gentoo, ebuild scheduled for
merge) USE="ssl -socks5 -test" ABI_X86="(64)" PYTHON_TARGETS="python3_6
python3_7 python3_8 (-pypy3) -python3_9" pulled in by
dev-python/requests[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (app-portage/gemato-16.2:0/0::gentoo, ebuild scheduled for
merge) USE="gpg -test -tools" ABI_X86="(64)" PYTHON_TARGETS="python3_7
python3_8 (-pypy3) -python3_6 -python3_9"

dev-python/requests[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (dev-python/sphinx-3.2.1:0/0::gentoo, ebuild scheduled for
merge) USE="-doc -latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7
python3_8 (-pypy3) -python3_6 -python3_9"


(dev-python/requests-2.24.0:0/0::gentoo, installed) USE="ssl -socks5
-test" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 python3_7
(-pypy3) -python3_8 -python3_9" pulled in by
  
>dev-python/requests-2.21.0[python_targets_python2_7(-),python_targets_python3_6(-),-python_single_target_jython2_7(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python3_7(-),python_single_target_python3_6(+)]
 required by (net-misc/streamlink-1.1.1:0/0::gentoo, installed) USE="-doc -test" ABI_X86="(64)" 
PYTHON_SINGLE_TARGET="python3_6 -python2_7 -python3_5" PYTHON_TARGETS="python2_7 python3_6 -python3_5"


There seems to be some python3_6 and even python2_7 in your error
output, maybe you have set some older python targets somewhere that
you've forgotten about?

Regards,
Arve



Forgotten about?  I'm flattered!  That would imply I understood
something here ...

Here's my python situation:

$ sed -n -e '/^\s*#/d' -e '/python/Ip' * | sort -u
*/* PYTHON_TARGETS: python3_7
>=dev-lang/python-2.7.16:2.7 sqlite
>=dev-lang/python-3.6.9 sqlite
>=dev-libs/libxml2-2.9.9-r1 python
>=dev-python/PySocks-1.7.1 python_targets_python3_6
>=dev-python/certifi-10001-r1 python_targets_python3_7
>=dev-python/certifi-2019.11.28 python_targets_python3_6
>=dev-python/cffi-1.14.0 python_targets_python3_6
>=dev-python/chardet-3.0.4 python_targets_python3_6
>=dev-python/cryptography-2.8-r1 python_targets_python3_6
>=dev-python/docutils-0.16 -python_targets_python2_7
>=dev-python/idna-2.8 python_targets_python3_6
>=dev-python/isodate-0.6.0-r1 python_targets_python3_6
>=dev-python/ply-3.11 python_targets_python3_6
>=dev-python/pycparser-2.20 python_targets_python3_6
>=dev-python/pycryptodome-3.9.4 python_targets_python3_6
>=dev-python/pyopenssl-19.1.0 python_targets_python3_6
>=dev-python/requests-2.23.0 python_targets_python3_6
>=dev-python/setuptools-46.4.0-r1 python_targets_python3_6
>=dev-python/setuptools-50.3.0 python_targets_python3_7
>=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_6
>=dev-python/setuptools_scm-4.1.2-r1 python_targets_python3_7
>=dev-python/six-1.14.0 python_targets_python3_6
>=dev-python/six-1.15.0-r1 python_targets_python3_7
>=dev-python/urllib3-1.25.8 python_targets_python3_6
>=virtual/python-cffi-0 python_targets_python3_6
dev-lang/python readline
net-print/cups X python

Re: [gentoo-user] update fails, but I don't see why

2020-12-04 Thread antlists


On 04/12/2020 08:53, Arve Barsnes wrote:

There seems to be some python3_6 and even python2_7 in your error
output, maybe you have set some older python targets somewhere that
you've forgotten about?


Or maybe he hasn't set any and the defaults are wrong? I'm guessing 
that's the case with me.


Cheers,
Wol

Re: [gentoo-user] update fails, but I don't see why

2020-12-04 Thread Arve Barsnes

On Fri, 4 Dec 2020 at 09:40, n952162  wrote:
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
>
> dev-python/requests:0
>
>(dev-python/requests-2.24.0-r1:0/0::gentoo, ebuild scheduled for
> merge) USE="ssl -socks5 -test" ABI_X86="(64)" PYTHON_TARGETS="python3_6
> python3_7 python3_8 (-pypy3) -python3_9" pulled in by
> dev-python/requests[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
> required by (app-portage/gemato-16.2:0/0::gentoo, ebuild scheduled for
> merge) USE="gpg -test -tools" ABI_X86="(64)" PYTHON_TARGETS="python3_7
> python3_8 (-pypy3) -python3_6 -python3_9"
>
> dev-python/requests[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
> required by (dev-python/sphinx-3.2.1:0/0::gentoo, ebuild scheduled for
> merge) USE="-doc -latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7
> python3_8 (-pypy3) -python3_6 -python3_9"
>
>
>(dev-python/requests-2.24.0:0/0::gentoo, installed) USE="ssl -socks5
> -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 python3_7
> (-pypy3) -python3_8 -python3_9" pulled in by
>  
> >dev-python/requests-2.21.0[python_targets_python2_7(-),python_targets_python3_6(-),-python_single_target_jython2_7(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python3_7(-),python_single_target_python3_6(+)]
>  required by (net-misc/streamlink-1.1.1:0/0::gentoo, installed) USE="-doc 
> -test" ABI_X86="(64)" PYTHON_SINGLE_TARGET="python3_6 -python2_7 -python3_5" 
> PYTHON_TARGETS="python2_7 python3_6 -python3_5"


There seems to be some python3_6 and even python2_7 in your error
output, maybe you have set some older python targets somewhere that
you've forgotten about?

Regards,
Arve

Re: [gentoo-user] update fails, but I don't see why


On 12/3/20 10:06 PM, tastytea wrote:

On 2020-12-03 21:33+0100 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?

Python 3.8 is the new default target and not all packages support it
yet. You can put
   */* PYTHON_TARGETS: python3_7
into /etc/portage/package.use as a workaround. Don't forget to remove
it in a month or so.


!!! The following updates are masked by LICENSE changes:
- sys-kernel/linux-firmware-20201022-r3::gentoo (masked by: || ( )
linux-fw-redistributable no-source-code license(s))
A copy of the 'linux-fw-redistributable' license is located at
'/var/db/repos/gentoo/licenses/linux-fw-redistributable'.

A copy of the 'no-source-code' license is located at
'/var/db/repos/gentoo/licenses/no-source-code'.

- net-analyzer/nmap-7.91::gentoo (masked by: NPSL license(s))
A copy of the 'NPSL' license is located at
'/var/db/repos/gentoo/licenses/NPSL'.

See .

Kind regards, tastytea.



Thank you for the response.  Unfortunately, it didn't help.  I have this:

$ cat /etc/portage/package.use/RMME
#> 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?
#
#Python 3.8 is the new default target and not all packages support it
#yet. You can put
*/* PYTHON_TARGETS: python3_7
#into /etc/portage/package.use as a workaround. Don't forget to remove
#it in a month or so.

and get essentially the same result


These are the packages that would be merged, in order:

Calculating dependencies
 * IMPORTANT: 9 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.

 * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
 * sections of the emerge man page to learn how to update config files.
... .. done!
[ebuild U  ] sys-libs/timezone-data-2020d::gentoo [2020a::gentoo]
USE="nls -leaps-timezone -zic-slim%" 647 KiB
[ebuild U  ] sys-devel/gcc-config-2.3.2-r1::gentoo [2.3.2::gentoo]
USE="(cc-wrappers%*) (native-symlinks)" 0 KiB
[ebuild U  ] dev-lang/go-1.15.5:0/1.15.5::gentoo
[1.14.9:0/1.14.9::gentoo] 22480 KiB
[ebuild U  ] app-text/poppler-data-0.4.10::gentoo [0.4.9::gentoo]
4393 KiB
[ebuild U  ] sys-devel/llvm-common-11.0.0::gentoo [10.0.1::gentoo]
119867 KiB
[ebuild  N ] acct-group/pcap-0::gentoo  0 KiB
[ebuild  r  U  ] dev-libs/liblinear-241:0/4::gentoo [210-r1:0/3::gentoo]
547 KiB
[ebuild U  ] x11-misc/util-macros-1.19.2-r2::gentoo
[1.19.2-r1::gentoo] 0 KiB
[ebuild U  ] dev-util/boost-build-1.74.0::gentoo [1.72.0::gentoo]
USE="-examples" 107032 KiB
[ebuild  N ] acct-user/pcap-0::gentoo  0 KiB
[ebuild U  ] app-shells/push-3.4::gentoo [2.0-r1::gentoo] 3 KiB
[ebuild U  ] app-emulation/docker-proxy-0.8.0_p20201105::gentoo
[0.8.0_p20200617::gentoo] 3307 KiB
[ebuild U  ] dev-lang/mujs-1.0.9:0/1.0.9::gentoo [1.0.5:0/0::gentoo]
USE="-static-libs" 121 KiB
[ebuild U  ] virtual/tmpfiles-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild U  ] app-admin/mcelog-173::gentoo [170::gentoo]
USE="(-selinux)" 306 KiB
[ebuild U  ] dev-libs/boost-1.74.0-r1:0/1.74.0::gentoo
[1.72.0-r2:0/1.72.0::gentoo] USE="bzip2 nls threads zlib -context -debug
-doc -icu -lzma -mpi (-numpy) -python -static-libs -tools -zstd"
ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_7 python3_8*
-python3_6 -python3_9%" 0 KiB
[ebuild U  ] media-libs/libpng-1.6.37-r2:0/16::gentoo
[1.6.37:0/16::gentoo] USE="apng -static-libs (-neon%)" ABI_X86="(64) -32
(-x32)" CPU_FLAGS_X86="sse" 0 KiB
[ebuild U  ] dev-libs/mpc-1.2.1:0/3::gentoo [1.2.0:0/3::gentoo]
USE="-static-libs" ABI_X86="(64) -32 (-x32)" 820 KiB
[ebuild U  ] sys-libs/libseccomp-2.4.4::gentoo [2.4.3::gentoo]
USE="-static-libs" ABI_X86="(64) -32 (-x32)" 591 KiB
[ebuild   R    ] sys-apps/file-5.39-r3::gentoo  USE="bzip2 seccomp zlib
-lzma -python -static-libs" ABI_X86="(64) -32 (-x32)"
PYTHON_TARGETS="python3_7 python3_8* -python3_6 -python3_9" 0 KiB
[ebuild   R    ] app-misc/pax-utils-1.2.6::gentoo  USE="seccomp -caps
-debug -python" PYTHON_SINGLE_TARGET="python3_8* -python3_6 -python3_7*
-python3_9%" 0 KiB
[ebuild U  ] sys-apps/sandbox-2.20::gentoo [2.18::gentoo]
ABI_X86="(32) (64) (-x32)" 419 KiB
[ebuild U  ] app-emulation/containerd-1.3.9::gentoo [1.3.7::gentoo]
USE="cri seccomp -apparmor -btrfs -device-mapper -hardened (-selinux)
-test" 5584 KiB
[ebuild U  ] sys-apps/sysvinit-2.97::gentoo [2.93::gentoo]
USE="(-ibm) (-selinux) -static" 124 KiB
[ebuild U  ] dev-libs/libusb-1.0.23-r1:1::gentoo
[1.0.21-r1:1::gentoo] USE="(split-usr) -debug -doc -examples
-static-libs -test -udev" ABI_X86="(64) -32 (-x32)" 589 KiB
[ebuild U  ] net-analyzer/iptraf-ng-1.2.1::gentoo [1.1.4-r1::gentoo]
USE="-doc" 318 KiB
[ebuild U  ] sys-apps/less-563-r1::gentoo [551::gentoo] USE="pcre
unicode" 328 KiB
[ebuild U  ] media-libs/libsndfile-1.0.30::gentoo

Re: [gentoo-user] update fails, but I don't see why