python 2 deprecation

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

python 2 deprecation

james-3
So today I receive this message:

!!! The following installed packages are masked:
- dev-python/rtgraph-0.70-r1::gentoo (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Michał Górny <[hidden email]> (2020-01-18)
# The following Gentoo packages are Python 2-only and have no reverse
# dependencies.
# Removal in 30 days.  Bug #705762.


So, trying not to get too excited, is that the only one?

So I ran
# equery depends python:2.7
  * These packages depend on python:2.7:

is there a deeper, more through way to check?

I have removed all syntax/expressions from
/etc/portage/make.conf

related to python; hoping python-2 would just die a natural, slow and
painless (for me) death, on this ancient gentoo install.

Any and all comments related to what to check/do are most welcome,
related to removing python-2*


James




Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

Rich Freeman
On Sat, Jan 25, 2020 at 12:20 PM james <[hidden email]> wrote:
>
> I have removed all syntax/expressions from
> /etc/portage/make.conf
>
> related to python; hoping python-2 would just die a natural, slow and
> painless (for me) death, on this ancient gentoo install.
>
> Any and all comments related to what to check/do are most welcome,
> related to removing python-2*

Disclaimer: I'm not involved with the python team, so details could
change around this...

Right now that is your best bet.  If you don't care about python,
avoid specifying python-related flags in your config files.  Then
portage will just apply defaults wherever possible.  It doesn't always
work, but that is mainly when packages can only support one version of
python at a time (which isn't too many of them).

As long as you aren't going crazy with accepting keywords then the
profiles should be updated so that python versions are removed only
after all the packages that depend on them have been removed, ideally
with newer v3 packages having been stabilized.  I suspect this process
will drag out for months as everybody involved realizes that migrating
can be painful but it has to be done, so expect packages to steadily
get masked and to see v2 stuff start disappearing once the packages
that depend on them are gone.  Users can always do overlays if they
want to maintain their own v2 forks, but I suspect this will be a lot
of work.  Maybe somebody will step up and do it but I'm not seeing
many signs of it.

Some packages in Gentoo just aren't super well-maintained and so
upstream might have v3 packages that aren't in the repo.  Bugs and
especially pull requests will doubtless be welcomed in these cases.
Just about every major distro is pushing to get rid of v2 so upstreams
that are dragging their feet are going to have motivation to fix
things or they just won't have any users left.

I'm sure at some point there will be a news announcement if users
actually need to do anything.  I doubt the rug will just get pulled
out from under you.  Even the package masks can be unmasked for 30
days until the packages start getting pulled which gives you a bit of
pain-free time to deal with it.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

james-3
On 1/25/20 9:59 PM, Rich Freeman wrote:

> On Sat, Jan 25, 2020 at 12:20 PM james <[hidden email]> wrote:
>>
>> I have removed all syntax/expressions from
>> /etc/portage/make.conf
>>
>> related to python; hoping python-2 would just die a natural, slow and
>> painless (for me) death, on this ancient gentoo install.
>>
>> Any and all comments related to what to check/do are most welcome,
>> related to removing python-2*
>
> Disclaimer: I'm not involved with the python team, so details could
> change around this...
>
> Right now that is your best bet.  If you don't care about python,
> avoid specifying python-related flags in your config files.  Then
> portage will just apply defaults wherever possible.  It doesn't always
> work, but that is mainly when packages can only support one version of
> python at a time (which isn't too many of them).
>
> As long as you aren't going crazy with accepting keywords then the
> profiles should be updated so that python versions are removed only
> after all the packages that depend on them have been removed, ideally
> with newer v3 packages having been stabilized.  I suspect this process
> will drag out for months as everybody involved realizes that migrating
> can be painful but it has to be done, so expect packages to steadily
> get masked and to see v2 stuff start disappearing once the packages
> that depend on them are gone.  Users can always do overlays if they
> want to maintain their own v2 forks, but I suspect this will be a lot
> of work.  Maybe somebody will step up and do it but I'm not seeing
> many signs of it.
>
> Some packages in Gentoo just aren't super well-maintained and so
> upstream might have v3 packages that aren't in the repo.  Bugs and
> especially pull requests will doubtless be welcomed in these cases.
> Just about every major distro is pushing to get rid of v2 so upstreams
> that are dragging their feet are going to have motivation to fix
> things or they just won't have any users left.
>
> I'm sure at some point there will be a news announcement if users
> actually need to do anything.  I doubt the rug will just get pulled
> out from under you.  Even the package masks can be unmasked for 30
> days until the packages start getting pulled which gives you a bit of
> pain-free time to deal with it.
>

Thx Rich.

James

Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

james-3
In reply to this post by james-3
On 1/25/20 10:00 PM, Rich Freeman wrote:

> On Sat, Jan 25, 2020 at 12:20 PM james <[hidden email]> wrote:
>>
>> I have removed all syntax/expressions from
>> /etc/portage/make.conf
>>
>> related to python; hoping python-2 would just die a natural, slow and
>> painless (for me) death, on this ancient gentoo install.
>>
>> Any and all comments related to what to check/do are most welcome,
>> related to removing python-2*
>
> Disclaimer: I'm not involved with the python team, so details could
> change around this...
>
> Right now that is your best bet.  If you don't care about python,
> avoid specifying python-related flags in your config files.  Then
> portage will just apply defaults wherever possible.  It doesn't always
> work, but that is mainly when packages can only support one version of
> python at a time (which isn't too many of them).
>
> As long as you aren't going crazy with accepting keywords then the
> profiles should be updated so that python versions are removed only
> after all the packages that depend on them have been removed, ideally
> with newer v3 packages having been stabilized.  I suspect this process
> will drag out for months as everybody involved realizes that migrating
> can be painful but it has to be done, so expect packages to steadily
> get masked and to see v2 stuff start disappearing once the packages
> that depend on them are gone.  Users can always do overlays if they
> want to maintain their own v2 forks, but I suspect this will be a lot
> of work.  Maybe somebody will step up and do it but I'm not seeing
> many signs of it.
>
> Some packages in Gentoo just aren't super well-maintained and so
> upstream might have v3 packages that aren't in the repo.  Bugs and
> especially pull requests will doubtless be welcomed in these cases.
> Just about every major distro is pushing to get rid of v2 so upstreams
> that are dragging their feet are going to have motivation to fix
> things or they just won't have any users left.
>
> I'm sure at some point there will be a news announcement if users
> actually need to do anything.  I doubt the rug will just get pulled
> out from under you.  Even the package masks can be unmasked for 30
> days until the packages start getting pulled which gives you a bit of
> pain-free time to deal with it.
>


thx,

just a test via another mail-route. curious if it works

Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

Dale-46
james wrote:

> On 1/25/20 10:00 PM, Rich Freeman wrote:
>> On Sat, Jan 25, 2020 at 12:20 PM james <[hidden email]> wrote:
>>>
>>> I have removed all syntax/expressions from
>>> /etc/portage/make.conf
>>>
>>> related to python; hoping python-2 would just die a natural, slow and
>>> painless (for me) death, on this ancient gentoo install.
>>>
>>> Any and all comments related to what to check/do are most welcome,
>>> related to removing python-2*
>>
>> Disclaimer: I'm not involved with the python team, so details could
>> change around this...
>>
>> Right now that is your best bet.  If you don't care about python,
>> avoid specifying python-related flags in your config files.  Then
>> portage will just apply defaults wherever possible.  It doesn't always
>> work, but that is mainly when packages can only support one version of
>> python at a time (which isn't too many of them).
>>
>> As long as you aren't going crazy with accepting keywords then the
>> profiles should be updated so that python versions are removed only
>> after all the packages that depend on them have been removed, ideally
>> with newer v3 packages having been stabilized.  I suspect this process
>> will drag out for months as everybody involved realizes that migrating
>> can be painful but it has to be done, so expect packages to steadily
>> get masked and to see v2 stuff start disappearing once the packages
>> that depend on them are gone.  Users can always do overlays if they
>> want to maintain their own v2 forks, but I suspect this will be a lot
>> of work.  Maybe somebody will step up and do it but I'm not seeing
>> many signs of it.
>>
>> Some packages in Gentoo just aren't super well-maintained and so
>> upstream might have v3 packages that aren't in the repo.  Bugs and
>> especially pull requests will doubtless be welcomed in these cases.
>> Just about every major distro is pushing to get rid of v2 so upstreams
>> that are dragging their feet are going to have motivation to fix
>> things or they just won't have any users left.
>>
>> I'm sure at some point there will be a news announcement if users
>> actually need to do anything.  I doubt the rug will just get pulled
>> out from under you.  Even the package masks can be unmasked for 30
>> days until the packages start getting pulled which gives you a bit of
>> pain-free time to deal with it.
>>
>
>
> thx,
>
> just a test via another mail-route. curious if it works
>
>


FYI, it came through but the threading was broken.  It appeared here as
a new thread. 

Dale

:-)  :-) 

Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

Peter Humphrey-3
On Sunday, 26 January 2020 05:35:04 GMT Dale wrote:
> james wrote:

> > just a test via another mail-route. curious if it works
>
> FYI, it came through but the threading was broken.  It appeared here as
> a new thread.

Not so here. KMail threaded it right.

--
Regards,
Peter.




Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

Mick-10
On Sunday, 26 January 2020 08:36:15 GMT Peter Humphrey wrote:
> On Sunday, 26 January 2020 05:35:04 GMT Dale wrote:
> > james wrote:
> > > just a test via another mail-route. curious if it works
> >
> > FYI, it came through but the threading was broken.  It appeared here as
> > a new thread.
>
> Not so here. KMail threaded it right.

+1 on Kmail

Regarding the original post, do not forget the incantations:

eselect python list
eselect python update
eselect python cleanup

to update your python symlinks and cleanup any stragglers.

--
Regards,
Mick

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

james-3
On 1/26/20 3:58 AM, Mick wrote:

> On Sunday, 26 January 2020 08:36:15 GMT Peter Humphrey wrote:
>> On Sunday, 26 January 2020 05:35:04 GMT Dale wrote:
>>> james wrote:
>>>> just a test via another mail-route. curious if it works
>>>
>>> FYI, it came through but the threading was broken.  It appeared here as
>>> a new thread.
>>
>> Not so here. KMail threaded it right.
>
> +1 on Kmail

Hmmmmm.

Well I've contact several ISPs about a /29 set of static IPs (routed) as
part of an upgrade. We'll see how that pans out. Sure, I hate SendMail,
but it's an old system that can be configured, with fine-grain
semantics, and we have much history together.


KMail is an interesting alternative, should I decide against static IPs.
I need those statics to showcase
some embedded devices I'm been working; so why not fix these VERIZON
ahole mail issues, once and for all.

ls /usr/portage/mail-mta  yeilds 12 packages.
(suggestions/discussions on running a mail server are all welcome.

I'm tire of waisting all this time, only to discover that other folks
running mail services, are basically a bunch of ahole, anti-linux
bigots. So why not just run my own mail server? Besides, I've got to go
back to work, and mail_administration is always a good thing for a
resume, ymmv.




> Regarding the original post, do not forget the incantations:
> eselect python list
> eselect python update
> eselect python cleanup
> to update your python symlinks and cleanup any stragglers.

It switched me from python-3.6 to python-3.7 as the default; I'll see
how that goes....
They all ran nice and clean, except for this package::
that fails to build regardless of what I do/try.

dev-perl/Authen-SASL


I've tried deleting and other fixes, but it fails to compile, seems to
be necessary ::

  # equery depends dev-perl/Authen-SASL
  * These packages depend on dev-perl/Authen-SASL:
dev-vcs/git-2.24.0

dev-perl/Authen-SASL)
and many more depend on git.....


Any pointers on cleaning up this part of the perl upgrades?
NOTE:: (Installed versions:  5.30.1(0/5.30)(01:16:57 AM 01/26/2020)

Googling yielded little useful(gentoo) info.


Anyone else experiencing this dev-perl/Authen-SASL blocker ?
I blocked <perl-5.30.1 in package.mask   ...

???

James


Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

Mick-10
On Sunday, 26 January 2020 23:45:14 GMT james wrote:

> On 1/26/20 3:58 AM, Mick wrote:
> > On Sunday, 26 January 2020 08:36:15 GMT Peter Humphrey wrote:
> >> On Sunday, 26 January 2020 05:35:04 GMT Dale wrote:
> >>> james wrote:
> >>>> just a test via another mail-route. curious if it works
> >>>
> >>> FYI, it came through but the threading was broken.  It appeared here as
> >>> a new thread.
> >>
> >> Not so here. KMail threaded it right.
> >
> > +1 on Kmail
>
> Hmmmmm.
>
> Well I've contact several ISPs about a /29 set of static IPs (routed) as
> part of an upgrade. We'll see how that pans out. Sure, I hate SendMail,
> but it's an old system that can be configured, with fine-grain
> semantics, and we have much history together.
>
>
> KMail is an interesting alternative, should I decide against static IPs.
> I need those statics to showcase
> some embedded devices I'm been working; so why not fix these VERIZON
> ahole mail issues, once and for all.
Kmail is a desktop GUIfied email client, not a mail delivery mechanism.

I seem to always receive your messages to the list and Kmail threads them
correctly from what I have noticed.


> ls /usr/portage/mail-mta  yeilds 12 packages.
> (suggestions/discussions on running a mail server are all welcome.
>
> I'm tire of waisting all this time, only to discover that other folks
> running mail services, are basically a bunch of ahole, anti-linux
> bigots. So why not just run my own mail server? Besides, I've got to go
> back to work, and mail_administration is always a good thing for a
> resume, ymmv.

I'll leave others to comment on the workload which running your own mail
server could produce.  Besides using a suitable application to configure a
dynamically updated blacklist and virus checker to keep spammers and malware
out, you'll also need to configure SPF, DKIM & DMARK to make sure your emails
are delivered reliably to the mass market ISPs like hotmail, yahoo.com!, etc.  
Otherwise such ISPs may just drop them unseen and without warning.

Random google result:

https://www.csoonline.com/article/3254234/mastering-email-security-with-dmarc-spf-and-dkim.html


> > Regarding the original post, do not forget the incantations:
> > eselect python list
> > eselect python update
> > eselect python cleanup
> > to update your python symlinks and cleanup any stragglers.
>
> It switched me from python-3.6 to python-3.7 as the default; I'll see
> how that goes....
> They all ran nice and clean, except for this package::
> that fails to build regardless of what I do/try.
>
> dev-perl/Authen-SASL
The moment I come across a perl package emerge problem and before I try to
troubleshoot it further, I run:

perl-cleaner --reallyall

--
Regards,

Mick

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

james-3
On 1/26/20 7:06 PM, Mick wrote:

> On Sunday, 26 January 2020 23:45:14 GMT james wrote:
>> On 1/26/20 3:58 AM, Mick wrote:
>>> On Sunday, 26 January 2020 08:36:15 GMT Peter Humphrey wrote:
>>>> On Sunday, 26 January 2020 05:35:04 GMT Dale wrote:
>>>>> james wrote:
>>>>>> just a test via another mail-route. curious if it works
>>>>>
>>>>> FYI, it came through but the threading was broken.  It appeared here as
>>>>> a new thread.
>>>>
>>>> Not so here. KMail threaded it right.
>>>
>>> +1 on Kmail
>>
>> Hmmmmm.
>>
>> Well I've contact several ISPs about a /29 set of static IPs (routed) as
>> part of an upgrade. We'll see how that pans out. Sure, I hate SendMail,
>> but it's an old system that can be configured, with fine-grain
>> semantics, and we have much history together.
>>
>>
>> KMail is an interesting alternative, should I decide against static IPs.
>> I need those statics to showcase
>> some embedded devices I'm been working; so why not fix these VERIZON
>> ahole mail issues, once and for all.
>
> Kmail is a desktop GUIfied email client, not a mail delivery mechanism.
>
> I seem to always receive your messages to the list and Kmail threads them
> correctly from what I have noticed.
>
>
>> ls /usr/portage/mail-mta  yeilds 12 packages.
>> (suggestions/discussions on running a mail server are all welcome.
>>
>> I'm tire of waisting all this time, only to discover that other folks
>> running mail services, are basically a bunch of ahole, anti-linux
>> bigots. So why not just run my own mail server? Besides, I've got to go
>> back to work, and mail_administration is always a good thing for a
>> resume, ymmv.
>
> I'll leave others to comment on the workload which running your own mail
> server could produce.  Besides using a suitable application to configure a
> dynamically updated blacklist and virus checker to keep spammers and malware
> out, you'll also need to configure SPF, DKIM & DMARK to make sure your emails
> are delivered reliably to the mass market ISPs like hotmail, yahoo.com!, etc.
> Otherwise such ISPs may just drop them unseen and without warning.
>
> Random google result:
>
> https://www.csoonline.com/article/3254234/mastering-email-security-with-dmarc-spf-and-dkim.html
>
>
>>> Regarding the original post, do not forget the incantations:
>>> eselect python list
>>> eselect python update
>>> eselect python cleanup
>>> to update your python symlinks and cleanup any stragglers.
>>
>> It switched me from python-3.6 to python-3.7 as the default; I'll see
>> how that goes....
>> They all ran nice and clean, except for this package::
>> that fails to build regardless of what I do/try.
>>
>> dev-perl/Authen-SASL
>
> The moment I come across a perl package emerge problem and before I try to
> troubleshoot it further, I run:
>
> perl-cleaner --reallyall
>
So::
perl-cleaner --reallyall

It runs on 64/145 packages just fine, then, as always, fails on
"Emerging (65 of 145)dev-perl/Authen-SASL-2.160.0-r1::argent-main"

Any other ideas?  Maybe I need to download that package again, as it
somehow got corrupted?

Here's the first part of the error message::

Failed to emerge dev-perl/Authen-SASL-2.160.0-r1, Log file:
 >>>  '/var/log/portage/dev-perl:Authen-SASL-2.160.0-r1:20200127-044809.log'
 >>> Jobs: 64 of 145 complete, 1 failed              Load avg: 1.45,
1.62, 1.07
  * Package:    dev-perl/Authen-SASL-2.160.0-r1
  * Repository: argent-main
  * Maintainer: [hidden email]
  * USE:        abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU
  * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
 >>> Unpacking source...
 >>> Unpacking Authen-SASL-2.16.tar.gz to
/var/tmp/portage/dev-perl/Authen-SASL-2.160.0-r1/work
 >>> Source unpacked in
/var/tmp/portage/dev-perl/Authen-SASL-2.160.0-r1/work
 >>> Preparing source in
/var/tmp/portage/dev-perl/Authen-SASL-2.160.0-r1/work/Authen-SASL-2.16 ...
 >>> Source prepared.
 >>> Configuring source in
/var/tmp/portage/dev-perl/Authen-SASL-2.160.0-r1/work/Authen-SASL-2.16 ...
  * Using ExtUtils::MakeMaker
  * perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor INSTALLMAN3DIR=none
DESTDIR=/var/tmp/portage/dev-perl/Authen-SASL-2.160.0-r1/image/
Can't locate inc/Module/Install.pm in @INC (you may need to install the
inc::Module::Install module) (@INC contains: /etc/perl
/usr/local/lib64/perl5/5.30.1/x86_64-linux-thread-multi
/usr/local/lib64/perl5/5.30.1
/usr/lib64/perl5/vendor_perl/5.30.1/x86_64-linux-thread-multi
/usr/lib64/perl5/vendor_perl/5.30.1 /usr/local/lib64/perl5
/usr/lib64/perl5/vendor_perl/5.28.2 /usr/lib64/perl5/vendor_perl/5.26.2
/usr/lib64/perl5/vendor_perl/5.24.3 /usr/lib64/perl5/vendor_perl
/usr/lib64/perl5/5.30.1/x86_64-linux-thread-multi
/usr/lib64/perl5/5.30.1) at Makefile.PL line 6.
BEGIN failed--compilation aborted at Makefile.PL line 6.
  * ERROR: dev-perl/Authen-SASL-2.160.0-r1::argent-main failed
(configure phase):
  *   Unable to build!


*
  * Call stack:
  *     ebuild.sh, line  125:  Called src_configure
  *   environment, line 2482:  Called perl-module_src_configure
  *   environment, line 2104:  Called die
  * The specific snippet of code:
  *               perl Makefile.PL "$@" <<< "${pm_echovar}" || die
"Unable to build!";
  *


Any guidance or suggestion are welcome.
A specific list of files to purge and download again?

James

Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

Arve Barsnes
On Mon, 27 Jan 2020 at 05:57, james <[hidden email]> wrote:

> Can't locate inc/Module/Install.pm in @INC (you may need to install the
> inc::Module::Install module) (@INC contains: /etc/perl
> /usr/local/lib64/perl5/5.30.1/x86_64-linux-thread-multi
> /usr/local/lib64/perl5/5.30.1
> /usr/lib64/perl5/vendor_perl/5.30.1/x86_64-linux-thread-multi
> /usr/lib64/perl5/vendor_perl/5.30.1 /usr/local/lib64/perl5
> /usr/lib64/perl5/vendor_perl/5.28.2 /usr/lib64/perl5/vendor_perl/5.26.2
> /usr/lib64/perl5/vendor_perl/5.24.3 /usr/lib64/perl5/vendor_perl
> /usr/lib64/perl5/5.30.1/x86_64-linux-thread-multi
> /usr/lib64/perl5/5.30.1) at Makefile.PL line 6.
>
> Any guidance or suggestion are welcome.
> A specific list of files to purge and download again?

It seems like some package has a missing dependency, and that you
should install dev-perl/Module-Install

Cheers,
Arve

Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

Mick-10
On Monday, 27 January 2020 07:26:38 GMT Arve Barsnes wrote:

> On Mon, 27 Jan 2020 at 05:57, james <[hidden email]> wrote:
> > Can't locate inc/Module/Install.pm in @INC (you may need to install the
> > inc::Module::Install module) (@INC contains: /etc/perl
> > /usr/local/lib64/perl5/5.30.1/x86_64-linux-thread-multi
> > /usr/local/lib64/perl5/5.30.1
> > /usr/lib64/perl5/vendor_perl/5.30.1/x86_64-linux-thread-multi
> > /usr/lib64/perl5/vendor_perl/5.30.1 /usr/local/lib64/perl5
> > /usr/lib64/perl5/vendor_perl/5.28.2 /usr/lib64/perl5/vendor_perl/5.26.2
> > /usr/lib64/perl5/vendor_perl/5.24.3 /usr/lib64/perl5/vendor_perl
> > /usr/lib64/perl5/5.30.1/x86_64-linux-thread-multi
> > /usr/lib64/perl5/5.30.1) at Makefile.PL line 6.
> >
> > Any guidance or suggestion are welcome.
> > A specific list of files to purge and download again?
>
> It seems like some package has a missing dependency, and that you
> should install dev-perl/Module-Install
>
> Cheers,
> Arve
Hmm ... dev-perl/Module-Install is NOT installed here, but I do have dev-perl/
Authen-SASL-2.160.0-r1 installed fine with no emerge errors.

Of course James may have installed manually some perl packages, or added
(some) perl packages in his world file and they may require dev-perl/Module-
Install.  Either way such dependencies ought to be dealt with by portage,
rather than having to emerge packages manually.

I'm no perl expert to offer specific advice here.  To move on you could try
emerging '-1av dev-perl/Module-Install' as Arve recommends and see where this
gets you.

--
Regards,

Mick

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

james-3
On 1/27/20 3:18 AM, Mick wrote:

> On Monday, 27 January 2020 07:26:38 GMT Arve Barsnes wrote:
>> On Mon, 27 Jan 2020 at 05:57, james <[hidden email]> wrote:
>>> Can't locate inc/Module/Install.pm in @INC (you may need to install the
>>> inc::Module::Install module) (@INC contains: /etc/perl
>>> /usr/local/lib64/perl5/5.30.1/x86_64-linux-thread-multi
>>> /usr/local/lib64/perl5/5.30.1
>>> /usr/lib64/perl5/vendor_perl/5.30.1/x86_64-linux-thread-multi
>>> /usr/lib64/perl5/vendor_perl/5.30.1 /usr/local/lib64/perl5
>>> /usr/lib64/perl5/vendor_perl/5.28.2 /usr/lib64/perl5/vendor_perl/5.26.2
>>> /usr/lib64/perl5/vendor_perl/5.24.3 /usr/lib64/perl5/vendor_perl
>>> /usr/lib64/perl5/5.30.1/x86_64-linux-thread-multi
>>> /usr/lib64/perl5/5.30.1) at Makefile.PL line 6.
>>>
>>> Any guidance or suggestion are welcome.
>>> A specific list of files to purge and download again?
>>
>> It seems like some package has a missing dependency, and that you
>> should install dev-perl/Module-Install
>>
>> Cheers,
>> Arve
>
> Hmm ... dev-perl/Module-Install is NOT installed here, but I do have dev-perl/
> Authen-SASL-2.160.0-r1 installed fine with no emerge errors.
>
> Of course James may have installed manually some perl packages, or added
> (some) perl packages in his world file and they may require dev-perl/Module-
> Install.  Either way such dependencies ought to be dealt with by portage,
> rather than having to emerge packages manually.

Agreed.

>
> I'm no perl expert to offer specific advice here.  To move on you could try
> emerging '-1av dev-perl/Module-Install' as Arve recommends and see where this
> gets you.


So, allowing me to 'play stupid here', How was I suppose to know that ::

"Can't locate inc/Module/Install.pm in @INC (you may need to install the
 >>> inc::Module::Install module) (@INC contains: /etc/perl "

Is it an action item to go and look for a package I have never dealt
with. I'm not assuming this is not PEBCAK
'Problem Exist Between Chair And Keyboard'

But this is a new one for me....

Anyway, thanks Arve and Mick and Dale..... I hate to admit it, but this
one stumped me for over a week...


perl-cleaner --reallyall
ran flawlessly...


James


Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

Franz Fellner
In reply to this post by james-3
Quoting james (2020-01-27 06:57:24)
> It runs on 64/145 packages just fine, then, as always, fails on
> "Emerging (65 of 145)dev-perl/Authen-SASL-2.160.0-r1::argent-main"
>
> Any other ideas?  Maybe I need to download that package again, as it
> somehow got corrupted?

I assume "argent-main" repo is the main tree of argentlinux, correct?
So no Gentoo but a fork?
It is likely that they messed up some things, so normal Gentoo users
have no issues with that package.

Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

David Haller-5
In reply to this post by james-3
Hello,

On Sun, 26 Jan 2020, james wrote:
> * Package:    dev-perl/Authen-SASL-2.160.0-r1
> * Repository: argent-main
[..]
> * perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor INSTALLMAN3DIR=none
>DESTDIR=/var/tmp/portage/dev-perl/Authen-SASL-2.160.0-r1/image/
>Can't locate inc/Module/Install.pm in @INC (you may need to install the
>inc::Module::Install module) (@INC contains: /etc/perl

That is not the gentoo ebuild. The gentoo one builds just fine due to
this line in src_prepare() of the ebuild:

sed -i -e 's/use inc::Module::Install;/use lib q[.]; use inc::Module::Install;/' Makefile.PL

So, just mask the argent-main version or remove that overlay or ...

HTH,
-dnh

--
SMTP is cute, fluffy and goes Woof! When well treated she wags her tail, licks
your face and delivers your mail. When badly treated by spammers or people
running exchange/<insert other pseudo-SMTP systems here>/etc she tends to bite
back.                                                        -- Simon Burr

Reply | Threaded
Open this post in threaded view
|

Re: python 2 deprecation

james-3
In reply to this post by Franz Fellner
On 1/27/20 11:40 PM, Franz Fellner wrote:

> Quoting james (2020-01-27 06:57:24)
>> It runs on 64/145 packages just fine, then, as always, fails on
>> "Emerging (65 of 145)dev-perl/Authen-SASL-2.160.0-r1::argent-main"
>>
>> Any other ideas?  Maybe I need to download that package again, as it
>> somehow got corrupted?
>
> I assume "argent-main" repo is the main tree of argentlinux, correct?
> So no Gentoo but a fork?
> It is likely that they messed up some things, so normal Gentoo users
> have no issues with that package.
>

Probably correct. I often install packages not formally part of portage,
so I have over a dozen via layman. Nothing appears to be updated for a
year, many for 3 years, so I just deleted the layman files and now I
search for replacements..

thx,
James