Re: [gentoo-user] Re: Dependencies and PYTHON_TARGETS

2018-04-23 Thread Neil Bothwick 
On Mon, 23 Apr 2018 18:10:08 -0400, Mike Gilbert wrote:

> You are incorrect; PYTHON_TARGETS is never calculated based on the
> versions of python you have installed.

Then how is it derived when not defined in make.conf? Is it set in the
profiles?


-- 
Neil Bothwick

The trouble with doing something right the first time is that nobody
appreciates how difficult it was.


pgpHmA_z7LhRB.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Dependencies and PYTHON_TARGETS

2018-04-23 Thread Mike Gilbert 
On Mon, Apr 23, 2018 at 3:15 PM, Neil Bothwick  wrote:
> On Mon, 23 Apr 2018 08:37:42 -0700, Ian Zimmerman wrote:
>
>> > > Why did portage remove my python-3.5?
>> >
>> > Because nothing that depends on it isn't also satisfied by
>> > python-3.6?
>>
>> But doesn't the PYTHON_TARGETS with which a package is built create a
>> strict dependency on those pythons?  If native code extensions are
>> present, the compiled code won't in general be compatible with other
>> versions.
>
> AIUI PYTHON_TARGETS determines which python version extension modules are
> installed for. If you don't set PYTHON_TARGETS explicitly, portage sets
> it according to the versions you have installed.
>

You are incorrect; PYTHON_TARGETS is never calculated based on the
versions of python you have installed.

Re: [gentoo-user] Re: Dependencies and PYTHON_TARGETS

2018-04-23 Thread Neil Bothwick 
On Mon, 23 Apr 2018 08:37:42 -0700, Ian Zimmerman wrote:

> > > Why did portage remove my python-3.5?  
> > 
> > Because nothing that depends on it isn't also satisfied by
> > python-3.6?  
> 
> But doesn't the PYTHON_TARGETS with which a package is built create a
> strict dependency on those pythons?  If native code extensions are
> present, the compiled code won't in general be compatible with other
> versions.

AIUI PYTHON_TARGETS determines which python version extension modules are
installed for. If you don't set PYTHON_TARGETS explicitly, portage sets
it according to the versions you have installed.


-- 
Neil Bothwick

Plagarism prohibited. Derive carefully.


pgptTZzJ4Wddp.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Can't fetch distfiles in chroot

2018-04-23 Thread Walter Dnes 
On Mon, Apr 23, 2018 at 04:23:18PM +0100, Peter Humphrey wrote

> Ah, that was it. My searching didn't turn that one up - thanks.
> 
> $ gcc -c -Q -march=native --help=target | grep march=
>   -march=   silvermont

  https://en.wikipedia.org/wiki/Celeron

> Celeron is a brand name given by Intel to a number of different
> low-end IA-32 and x86-64 computer microprocessor models targeted
> at budget personal computers.

  Looking at that page, "Celeron" can be a cheap, low end version any
one of a whole slew of Intel CPUs.  You have to check the cpu to get the
exact model that it's the low end version of.

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

Re: [gentoo-user] Re: Dependencies and PYTHON_TARGETS

2018-04-23 Thread Peter Humphrey 
On Monday, 23 April 2018 16:31:39 BST Ian Zimmerman wrote:

> I think before digging further, I should eliminate any guessing about
> what PYTHON_TARGETS is actually set to.  How can I list the environment
> portage sees, from all sources (profile, make.conf and whatever else)?

Doesn't "emerge --info | grep PYTHON_TARGETS" work for you? Here I get 
PYTHON_TARGETS="python2_7 python3_5".

-- 
Regards,
Peter.

[gentoo-user] Re: Dependencies and PYTHON_TARGETS

2018-04-23 Thread Ian Zimmerman 
On 2018-04-23 08:31, Neil Bothwick wrote:

> > Why did portage remove my python-3.5?
> 
> Because nothing that depends on it isn't also satisfied by python-3.6?

But doesn't the PYTHON_TARGETS with which a package is built create a
strict dependency on those pythons?  If native code extensions are
present, the compiled code won't in general be compatible with other
versions.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

[gentoo-user] Re: Dependencies and PYTHON_TARGETS

2018-04-23 Thread Ian Zimmerman 
On 2018-04-23 05:54, Alec Ten Harmsel wrote:

> > But do you ever --depclean?  Why did portage remove my python-2.5?
> 
> Yes, after every world update. I'm not sure why python-3.5 was removed.

Of course I meant python 3.5.  Thanks for reading my mind ;-)

> Before you set PYTHON_TARGETS in make.conf, had you run an `emerge
> --sync' in a while? It's possible the default PYTHON_TARGETS from your
> profile did not include python-3.5, so --depclean would have removed
> it.

In fact I never even changed PYTHON_TARGETS.  All I did was, after
--sync and rebuild but before --depclean, I removed the line from world.

I think before digging further, I should eliminate any guessing about
what PYTHON_TARGETS is actually set to.  How can I list the environment
portage sees, from all sources (profile, make.conf and whatever else)?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] Re: Can't fetch distfiles in chroot

2018-04-23 Thread Peter Humphrey 
On Monday, 23 April 2018 11:57:27 BST Mick wrote:
> On Monday, 23 April 2018 10:52:57 BST Peter Humphrey wrote:
> > On Sunday, 22 April 2018 12:13:53 BST Mick wrote:
> > > On Sunday, 22 April 2018 10:21:16 BST Peter Humphrey wrote:
> > > > That first thought was prompted by the instruction to "mount -o bind
> > > > /lib/
> > > > modules /foo/lib/modules" in this page:
> > > > 
> > > > https://wiki.gentoo.org/wiki/Project:X86/Chroot_Guide
> > > 
> > > I didn't do a detailed comparison, but you may want to take a look at
> > > the
> > > Handbook, the chroot mounts appear to be different.
> > 
> > I think I've found the problem. It's in the -march setting, which of
> > course
> > has to be specific in the chroot, not "native." I had it set to
> > "silvermont," but now I can't see why I did that. The target CPU is a
> > celeron N3150, which according to an Intel site is "Products formerly
> > Braswell" [1]. None of the Gentoo or GCC optimisation sites I could find
> > even mention braswell, silvermont or model 76.
> 
> If you check 'man gcc' you will find "silvermont" is mentioned as a cpu_type
> you could set for march, but not the graphics core Braswell.

Yes, so it is, but I couldn't tell which arch I needed for this CPU.

Thanks to you both.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: Can't fetch distfiles in chroot

2018-04-23 Thread Peter Humphrey 
On Monday, 23 April 2018 11:57:12 BST Walter Dnes wrote:
> > I think I've found the problem. It's in the -march setting, which of
> > course has to be specific in the chroot, not "native." I had it set
> > to "silvermont," but now I can't see why I did that. The target CPU
> > is a celeron N3150, which according to an Intel site is "Products
> > formerly Braswell" [1]. None of the Gentoo or GCC optimisation sites
> > I could find even mention braswell, silvermont or model 76.
> > 
> > So I changed make.conf to braswell, and now I get "error: bad
> > value (braswell) for -march= switch" from the compiler during any
> > emerge.
> 
>   Sounds like an invalid value.  To find out what gcc thinks the machine
> really is, *ON THE CELERON*, execute the command...
> 
> gcc -c -Q -march=native --help=target | grep march=

Ah, that was it. My searching didn't turn that one up - thanks.

$ gcc -c -Q -march=native --help=target | grep march=
  -march=   silvermont

>   On my ancient core2, I get...
> 
>   -march=   core2
> 
>   Use whatever value the above query returns on the Celeron.  Silvermont
> is a recent 64 bit Atom.  For a big list of gcc-7.3 supported cpus, see
> https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/x86-Options.html#x86-Options

-- 
Regards,
Peter.

Re: [gentoo-user] Re: Can't fetch distfiles in chroot

2018-04-23 Thread Mick 
On Monday, 23 April 2018 10:52:57 BST Peter Humphrey wrote:
> On Sunday, 22 April 2018 12:13:53 BST Mick wrote:
> > On Sunday, 22 April 2018 10:21:16 BST Peter Humphrey wrote:
> > > That first thought was prompted by the instruction to "mount -o bind
> > > /lib/
> > > modules /foo/lib/modules" in this page:
> > > 
> > > https://wiki.gentoo.org/wiki/Project:X86/Chroot_Guide
> > 
> > I didn't do a detailed comparison, but you may want to take a look at the
> > Handbook, the chroot mounts appear to be different.
> 
> I think I've found the problem. It's in the -march setting, which of course
> has to be specific in the chroot, not "native." I had it set to
> "silvermont," but now I can't see why I did that. The target CPU is a
> celeron N3150, which according to an Intel site is "Products formerly
> Braswell" [1]. None of the Gentoo or GCC optimisation sites I could find
> even mention braswell, silvermont or model 76.

If you check 'man gcc' you will find "silvermont" is mentioned as a cpu_type 
you could set for march, but not the graphics core Braswell.

-- 
Regards,
Mick

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

Re: [gentoo-user] Re: Can't fetch distfiles in chroot

2018-04-23 Thread Walter Dnes 
> I think I've found the problem. It's in the -march setting, which of
> course has to be specific in the chroot, not "native." I had it set
> to "silvermont," but now I can't see why I did that. The target CPU
> is a celeron N3150, which according to an Intel site is "Products
> formerly Braswell" [1]. None of the Gentoo or GCC optimisation sites
> I could find even mention braswell, silvermont or model 76.
> 
> So I changed make.conf to braswell, and now I get "error: bad
> value (braswell) for -march= switch" from the compiler during any
> emerge.

  Sounds like an invalid value.  To find out what gcc thinks the machine
really is, *ON THE CELERON*, execute the command...

gcc -c -Q -march=native --help=target | grep march=

  On my ancient core2, I get...

  -march=   core2

  Use whatever value the above query returns on the Celeron.  Silvermont
is a recent 64 bit Atom.  For a big list of gcc-7.3 supported cpus, see
https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/x86-Options.html#x86-Options

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

Re: [gentoo-user] Re: Dependencies and PYTHON_TARGETS

2018-04-23 Thread Alec Ten Harmsel 
On Sun, Apr 22, 2018 at 06:44:03PM -0700, Ian Zimmerman wrote:
> On 2018-04-22 15:08, Alec Ten Harmsel wrote:
> 
> > > * make sure dev-lang/python:3.6 stays in the world file, even if it
> > > is not needed by me directly
> > 
> > No, you shouldn't need any dev-lang/python entries in the world
> > file. I don't have any in my world file, but still have 2.7 and 3.5
> > installed on my system because I have some python programs installed.
> 
> But do you ever --depclean?  Why did portage remove my python-2.5?

Yes, after every world update. I'm not sure why python-3.5 was removed.

Before you set PYTHON_TARGETS in make.conf, had you run an `emerge
--sync' in a while? It's possible the default PYTHON_TARGETS from your
profile did not include python-3.5, so --depclean would have removed it.

Alec

Re: [gentoo-user] Re: Can't fetch distfiles in chroot

2018-04-23 Thread Peter Humphrey 
On Sunday, 22 April 2018 12:13:53 BST Mick wrote:
> On Sunday, 22 April 2018 10:21:16 BST Peter Humphrey wrote:
> > That first thought was prompted by the instruction to "mount -o bind /lib/
> > modules /foo/lib/modules" in this page:
> > 
> > https://wiki.gentoo.org/wiki/Project:X86/Chroot_Guide
> 
> I didn't do a detailed comparison, but you may want to take a look at the
> Handbook, the chroot mounts appear to be different.

I think I've found the problem. It's in the -march setting, which of course 
has to be specific in the chroot, not "native." I had it set to "silvermont," 
but now I can't see why I did that. The target CPU is a celeron N3150, which 
according to an Intel site is "Products formerly Braswell" [1]. None of the 
Gentoo or GCC optimisation sites I could find even mention braswell, 
silvermont or model 76.

So I changed make.conf to braswell, and now I get "error: bad value (braswell) 
for -march= switch" from the compiler during any emerge. Now, does that mean I 
can't switch from silvermont to braswell, or does it also imply that, if I 
start installing again from scratch, I won't be able to switch from whatever's 
in the stage-3 tarball to braswell either?

Perhaps I should just try it and see.

1.  https://ark.intel.com/products/codename/66094/Braswell

-- 
Regards,
Peter.

Re: [gentoo-user] Re: Dependencies and PYTHON_TARGETS

2018-04-23 Thread Neil Bothwick 
On Sun, 22 Apr 2018 18:44:03 -0700, Ian Zimmerman wrote:

> > No, you shouldn't need any dev-lang/python entries in the world
> > file. I don't have any in my world file, but still have 2.7 and 3.5
> > installed on my system because I have some python programs
> > installed.  
> 
> But do you ever --depclean?  Why did portage remove my python-2.5?

Because nothing that depends on it isn't also satisfied by python-3.6?


-- 
Neil Bothwick

SITCOM: Single Income, Two Children, Oppressive Mortgage


pgpYJhaervynS.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: Binaries in /root/bin (solved)

2018-04-23 Thread Klaus Ethgen 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Am Mo den 23. Apr 2018 um  2:50 schrieb Ian Zimmerman:
> On 2018-04-22 20:28, Klaus Ethgen wrote:
> 
> > 1. is net-im/psi-1.3-r1
> > 2. is app-admin/pass-1.7.1
> > 
> > both packages install their bin into /root/bin. All other packages are
> > installing correct, just that two packages did it wrong.
> 
> FWIW I also have pass installed (same version) and it is in the right
> places.
> 
> Was there anything special at all about your environment when you run
> emerge?  Both in the broad and narrow sense of "environment".  In fact I
> would try next with
> 
> env -i emerge ...

That did the trick.

For some Reason, I had $BINDIR set in my environment, pointing to
$HOME/bin. unsetting it made it work.

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlrdigYACgkQpnwKsYAZ
9qz4Gwv/fh0neRDVQ66Q+geIxbWjNFkE5pj4euNmx1j3ERACm5mJ1rlX94G86Xbv
5OVilsDwhJdtj//Ma55yLI+rk3uyZagag1O0FD/G4RgVpw+WnuFAJEcnnFW5lj6n
c8suKxFOlfyNkbD0O+L+0M/Kfx5r/aTJw1OJy9DeCTTZLmyMb9v32l+IVbr7H0Ce
C+XHbSwYJLC898UcYcElp/ZcwWuexSRk5cvJslqjFF40sxjEwh/zvlsvlfPcXhIf
+YGzC+W/ETOS0WYZ5ult++pZeKjQ9y4w8QkGucP3+Hg8C0tK8fxlwlnwYeKuMI1+
6wa23NZnfWpW6AhohuPtiUhiMEajGVurXEj42r7+cHGZ+19RAngVDrn4/gAEZrnz
BA2KZrSqTFYIbpCOfKzfB2JUE0rLtENqBk4bG6ZawgmdPd434yuOMqtJJkTjSAR1
ASry33os9knhWzGH297tf++MLJ+ep2NKS03YpqyMk+ymqqdZNWhQF8lSiMUWFh5n
bVPgS+db
=6a6F
-END PGP SIGNATURE-