Re: [gentoo-user] Plasmashell consuming huge amounts of memory.

2017-10-11 Thread Dale
Hi,

It's trying to install dev-qt/qtdeclarative-5.9.2.  I went back and sort
of started from the start.  Figured out where I made a boo boo.  Now it
tries to apply the patch but fails to apply properly.  This is the error
I get. 



>>> Emerging (1 of 1) dev-qt/qtdeclarative-5.9.2::gentoo
 * qtdeclarative-opensource-src-5.9.2.tar.xz SHA256 SHA512 WHIRLPOOL
size ;-)
... 
  
[ ok ]
>>> Unpacking source...
>>> Unpacking qtdeclarative-opensource-src-5.9.2.tar.xz to
/var/tmp/portage/dev-qt/qtdeclarative-5.9.2/work
>>> Source unpacked in /var/tmp/portage/dev-qt/qtdeclarative-5.9.2/work
>>> Preparing source in
/var/tmp/portage/dev-qt/qtdeclarative-5.9.2/work/qtdeclarative-opensource-src-5.9.2
...
 * Applying memory.patch ...
1 out of 1 hunk FAILED -- saving rejects to file
src/quick/scenegraph/qsgthreadedrenderloop.cpp.rej
2 out of 2 hunks FAILED -- saving rejects to file
src/quick/scenegraph/util/qsgatlastexture.cpp.rej
1 out of 1 hunk FAILED -- saving rejects to file
src/quick/scenegraph/util/qsgatlastexture_p.h.rej   
   
[ !! ]
 * ERROR: dev-qt/qtdeclarative-5.9.2::gentoo failed (prepare phase):
 *   patch -p1  failed with
/etc/portage/patches/dev-qt/qtdeclarative-5.9.2/memory.patch
 *
 * Call stack:
 *   ebuild.sh, line  115:  Called src_prepare
 * environment, line 3798:  Called qt5-build_src_prepare
 * environment, line 3432:  Called default
 *  phase-functions.sh, line  808:  Called default_src_prepare
 *  phase-functions.sh, line  873:  Called __eapi6_src_prepare
 * environment, line  273:  Called eapply_user
 * environment, line  979:  Called eapply
'/etc/portage/patches/dev-qt/qtdeclarative-5.9.2/memory.patch'
 * environment, line  949:  Called _eapply_patch
'/etc/portage/patches/dev-qt/qtdeclarative-5.9.2/memory.patch'
 * environment, line  887:  Called __helpers_die 'patch -p1 
failed with /etc/portage/patches/dev-qt/qtdeclarative-5.9.2/memory.patch'
 *   isolated-functions.sh, line  117:  Called die
 * The specific snippet of code:
 *  die "$@"
 *
 * If you need support, post the output of `emerge --info
'=dev-qt/qtdeclarative-5.9.2::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=dev-qt/qtdeclarative-5.9.2::gentoo'`.
 * The complete build log is located at
'/var/log/portage/dev-qt:qtdeclarative-5.9.2:20171012-043431.log'.
 * For convenience, a symlink to the build log is located at
'/var/tmp/portage/dev-qt/qtdeclarative-5.9.2/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/dev-qt/qtdeclarative-5.9.2/temp/environment'.
 * Working directory:
'/var/tmp/portage/dev-qt/qtdeclarative-5.9.2/work/qtdeclarative-opensource-src-5.9.2'
 * S:
'/var/tmp/portage/dev-qt/qtdeclarative-5.9.2/work/qtdeclarative-opensource-src-5.9.2'

>>> Failed to emerge dev-qt/qtdeclarative-5.9.2, Log file:

>>>  '/var/log/portage/dev-qt:qtdeclarative-5.9.2:20171012-043431.log'
 *
 * The following package has failed to build, install, or execute postinst:
 *
 *  (dev-qt/qtdeclarative-5.9.2:5/5.9::gentoo, ebuild scheduled for
merge), Log file:
 *   '/var/log/portage/dev-qt:qtdeclarative-5.9.2:20171012-043431.log'
 *
root@fireball / #


Maybe this is due to it being for a different version or something.  I
dunno. 

If needed, I may go back to a older version for a bit but suspect it to
be a bit of a hassle. 

Dale

:-)  :-) 



P Levine wrote:
> What version of dev-qt/qtdeclarative is being installed?
>
>
> On Wed, Oct 11, 2017 at 11:09 PM, Dale  > wrote:
>
> P Levine wrote:
>> ​
>> On Wed, Oct 11, 2017 at 7:28 PM, Dale > >wrote:
>>
>> Howdy,
>>
>> I did a upgrade recently and after that, plasmashell is
>> consuming a huge
>> amount of memory. 
>>
>>
>> ​Probably related to
>> https://forum.kde.org/viewtopic.php?f=309=141169
>>  and
>> https://bugreports.qt.io/browse/QTBUG-62117
>> ​.
>>
>> Try seeing if this patch applies cleanly to dev-qt/qtdeclarative
>> and if merging it resolves the issue: 
>> 
>> https://codereview.qt-project.org/gitweb?p=qt/qtdeclarative.git;a=patch;h=768f606cd3cd37c235e85225127201a42d272946
>> 
>> .
>>
>
>
> I followed the directions here:
>
> https://wiki.gentoo.org/wiki//etc/portage/patches
> 
>
> I've done it a couple times before, still have some patches there
> now, but wanted to be sure I didn't miss anything.  However, when
> I tell it to 

Re: [gentoo-user] why zfs and friends want to update to 9999?

2017-10-11 Thread J. Roeleveld
On Wednesday, October 11, 2017 10:26:20 PM CEST Walter Dnes wrote:
> On Wed, Oct 11, 2017 at 05:34:48AM -0400, John Covici wrote
> 
> > Yep, I think you are correct, I had the  in package.keywords and
> > I think this is what made portage do that.  When I commented them out,
> > things are back to normal.
> 
>   Maybe portage inserted that entry itself.  If you want to prevent that
> in future, add the following line to make.conf ...
> 
> EMERGE_DEFAULT_OPTS="--autounmask=n"

This should be off by default.
My systems always ask me and I don't have the above set.

--
Joost




Re: [gentoo-user] Plasmashell consuming huge amounts of memory.

2017-10-11 Thread P Levine
What version of dev-qt/qtdeclarative is being installed?


On Wed, Oct 11, 2017 at 11:09 PM, Dale  wrote:

> P Levine wrote:
>
> ​
> On Wed, Oct 11, 2017 at 7:28 PM, Dale  wrote:
>
>> Howdy,
>>
>> I did a upgrade recently and after that, plasmashell is consuming a huge
>> amount of memory.
>
>
> ​Probably related to https://forum.kde.org/viewtopic.php?f=309=141169 and
> https://bugreports.qt.io/browse/QTBUG-62117​.
>
> Try seeing if this patch applies cleanly to dev-qt/qtdeclarative and if
> merging it resolves the issue:
> https://codereview.qt-project.org/gitweb?p=qt/qtdeclarative.git;a=patch;h=
> 768f606cd3cd37c235e85225127201a42d272946.
>
>
>
> I followed the directions here:
>
> https://wiki.gentoo.org/wiki//etc/portage/patches
>
> I've done it a couple times before, still have some patches there now, but
> wanted to be sure I didn't miss anything.  However, when I tell it to
> reemerge dev-qt/qtdeclarative, it doesn't apply the patch.  Usually it has
> a line that the patch was applied early on but I never seen it.  Odds are,
> I'm missing something somewhere.  I'll look into it more later.
>
> Thanks much.
>
> Dale
>
> :-)  :-)
>


Re: [gentoo-user] Plasmashell consuming huge amounts of memory.

2017-10-11 Thread Dale
P Levine wrote:
> ​
> On Wed, Oct 11, 2017 at 7:28 PM, Dale  >wrote:
>
> Howdy,
>
> I did a upgrade recently and after that, plasmashell is consuming
> a huge
> amount of memory. 
>
>
> ​Probably related to
> https://forum.kde.org/viewtopic.php?f=309=141169 and
> https://bugreports.qt.io/browse/QTBUG-62117​.
>
> Try seeing if this patch applies cleanly to dev-qt/qtdeclarative and
> if merging it resolves the issue: 
> https://codereview.qt-project.org/gitweb?p=qt/qtdeclarative.git;a=patch;h=768f606cd3cd37c235e85225127201a42d272946.
>


I followed the directions here:

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

I've done it a couple times before, still have some patches there now,
but wanted to be sure I didn't miss anything.  However, when I tell it
to reemerge dev-qt/qtdeclarative, it doesn't apply the patch.  Usually
it has a line that the patch was applied early on but I never seen it. 
Odds are, I'm missing something somewhere.  I'll look into it more later. 

Thanks much.

Dale

:-)  :-) 


Re: [gentoo-user] why zfs and friends want to update to 9999?

2017-10-11 Thread John Covici
On Wed, 11 Oct 2017 16:26:20 -0400,
Walter Dnes wrote:
> 
> On Wed, Oct 11, 2017 at 05:34:48AM -0400, John Covici wrote
> 
> > Yep, I think you are correct, I had the  in package.keywords and
> > I think this is what made portage do that.  When I commented them out,
> > things are back to normal.
> 
>   Maybe portage inserted that entry itself.  If you want to prevent that
> in future, add the following line to make.conf ...
> 
> EMERGE_DEFAULT_OPTS="--autounmask=n"

Good point, thanks.

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

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



Re: [gentoo-user] python build fail; undefined reference to pthread_* and sem_*

2017-10-11 Thread Walter Dnes
On Wed, Oct 11, 2017 at 11:56:21AM -0400, Mike Gilbert wrote

> I can reproduce the issue by adding -fopenmp to my CFLAGS. You can
> work around it by adding -fopenmp to LDFLAGS as well.

  Thanks.  The following workaround makes python build properly.

LDFLAGS="-fopenmp" emerge =dev-lang/python-2.7.12 =dev-lang/python-3.4.5

> This is probably a bug in the Python build system; it should probably
> be passing CFLAGS to gcc when linking libpython.

  Bug https://bugs.gentoo.org/634064 filed.

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



Re: [gentoo-user] Plasmashell consuming huge amounts of memory.

2017-10-11 Thread P Levine
​
On Wed, Oct 11, 2017 at 7:28 PM, Dale  wrote:

> Howdy,
>
> I did a upgrade recently and after that, plasmashell is consuming a huge
> amount of memory.


​Probably related to https://forum.kde.org/viewtopic.php?f=309=141169 and
https://bugreports.qt.io/browse/QTBUG-62117​.

Try seeing if this patch applies cleanly to dev-qt/qtdeclarative and if
merging it resolves the issue:
https://codereview.qt-project.org/gitweb?p=qt/qtdeclarative.git;a=patch;h=768f606cd3cd37c235e85225127201a42d272946
.


[gentoo-user] Plasmashell consuming huge amounts of memory.

2017-10-11 Thread Dale
Howdy,

I did a upgrade recently and after that, plasmashell is consuming a huge
amount of memory.  I noticed it at one point and it was taking about
8GBs.  I killed it and restarted but it seems to keep happening after a
few hours.  After I took a nap, I nudged the monitor back to the on
state only to notice it had eaten so much memory that the system killed
plasmashell and I had to restart it then.  It also made other programs
go to swap since it was full as well.  Glad the system dealt with it
instead of just crashing the whole thing. 

After I restart it, it goes back to normal, a few hundred megabytes, but
slowly starts increasing again.  It gets old having to either logout or
restart the thing. 

Has anyone else noticed this happening on their systems?  If not, I may
rename .kde4 and see if that helps.  Maybe a bad or outdated config. 

Currently on:

kde-plasma/plasma-workspace-5.10.5-r1

Was on:

kde-plasma/plasma-workspace-5.10.5

It seems it was a Gentoo upgrade based on the -r1. 

Thanks.

Dale

:-)  :-) 



Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

2017-10-11 Thread mad.scientist.at.large
it's worth noting that a failing power supply can produce what seem to be ram 
problems.  it happened to me, swapping ram, a motherboard and then a power 
supply made it clear.

--
Note the right side (his right) of Mr. Trumps face, He's clearly had a major 
stroke or similar neurological insult.   The eye always droops, and that side 
of his mouth hardly moves when he speaks.  I try not to throw stones from 
inside my glass house, others obviously don't mind hypocrisy.


8. Oct 2017 18:14 by r03...@gmail.com:


> On Sun, Oct 8, 2017 at 4:53 PM, Grant Edwards <> grant.b.edwa...@gmail.com> > 
> wrote:
>> On 2017-10-08, R0b0t1 <>> r03...@gmail.com>> > wrote:
>>
>>> Usually what happens is it will be corrupted in RAM after being
>>> verified on disk, and faulty results will be saved to disk from RAM. A
>>> user on the forums recently had this issue compiling dev-lang/vala,
>>> and I have had related issues.
>>
>> I've had failing RAM corrupt files and cause compile failures (and
>> various other odd problems). But, the exact symptoms tend to be pretty
>> random.  The chances are infinitesmal that a HW problem would corrupt
>> the download (or the compile itself) in an identical manner a second
>> time.
>>
>
> Right, redownloading or rerunning the compilation usually fixes such
> issues. At the same time, I have seen people hit bad areas of RAM
> repeatedly and have it look like other errors.
> --snip
> Cheers,
> R0b0t1

Re: [gentoo-user] why zfs and friends want to update to 9999?

2017-10-11 Thread Walter Dnes
On Wed, Oct 11, 2017 at 05:34:48AM -0400, John Covici wrote

> Yep, I think you are correct, I had the  in package.keywords and
> I think this is what made portage do that.  When I commented them out,
> things are back to normal.

  Maybe portage inserted that entry itself.  If you want to prevent that
in future, add the following line to make.conf ...

EMERGE_DEFAULT_OPTS="--autounmask=n"

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



Re: [gentoo-user] python build fail; undefined reference to pthread_* and sem_*

2017-10-11 Thread Mike Gilbert
On Wed, Oct 11, 2017 at 11:50 AM, Mike Gilbert  wrote:
> On Wed, Oct 11, 2017 at 12:16 AM, Walter Dnes  wrote:
>>   This is happening with both python 2.7.12 and 3.4.5 on a 32-bit x86
>> system.  Build logs are attached, along with "emerge --info" output.  I
>> can't find anything relevant in bugzilla.
>
> From the build log for 3.4.5:
>
> checking whether pthreads are available without options... yes
>
> This is clearly a lie; glibc requires that you pass "-pthread" to gcc
> to enable pthreads. For some reason, configure is mis-detecting this.
>
> I would try rebuilding with minimal CFLAGS.

I can reproduce the issue by adding -fopenmp to my CFLAGS. You can
work around it by adding -fopenmp to LDFLAGS as well.

This is probably a bug in the Python build system; it should probably
be passing CFLAGS to gcc when linking libpython.



Re: [gentoo-user] python build fail; undefined reference to pthread_* and sem_*

2017-10-11 Thread Mike Gilbert
On Wed, Oct 11, 2017 at 12:16 AM, Walter Dnes  wrote:
>   This is happening with both python 2.7.12 and 3.4.5 on a 32-bit x86
> system.  Build logs are attached, along with "emerge --info" output.  I
> can't find anything relevant in bugzilla.

>From the build log for 3.4.5:

checking whether pthreads are available without options... yes

This is clearly a lie; glibc requires that you pass "-pthread" to gcc
to enable pthreads. For some reason, configure is mis-detecting this.

I would try rebuilding with minimal CFLAGS.



Re: [gentoo-user] why zfs and friends want to update to 9999?

2017-10-11 Thread J. Roeleveld
On Wednesday, October 11, 2017 11:34:48 AM CEST John Covici wrote:
> On Wed, 11 Oct 2017 04:50:20 -0400,
> 
> J. Roeleveld wrote:
> > On Wednesday, October 11, 2017 9:54:05 AM CEST John Covici wrote:
> > > Hi.  In my latest world update, I have sys-fs/zfs and friends at
> > > 0.7.1 and they all want to update to .  Does anyone know why this
> > > should be -- normally  is not in the normal update sequence.
> > > 
> > > I am using the unstable gentoo, updated about 3 weeks ago.  No harm
> > > has come yet, but I have not done the update till I can figure out
> > > what is happening here -- particularly if I need a rescue cd which is
> > > using zfs 0.7.1.
> > > 
> > > Thanks in advance for any ideas.
> > 
> > check your keywords, how did you unmask zfs?
> > 
> > Here are mine:
> > 
> > $ grep -r zfs /etc/portage
> > /etc/portage/sets/zfs:sys-fs/zfs
> > /etc/portage/sets/zfs:sys-fs/zfs-kmod
> > /etc/portage/package.keywords/zfs:=sys-fs/zfs-kmod-0.7.1 ~amd64
> > /etc/portage/package.keywords/zfs:=sys-fs/zfs-0.7.1 ~amd64
> > $ grep -r spl /etc/portage
> > /etc/portage/sets/zfs:sys-kernel/spl
> > /etc/portage/package.keywords/zfs:=sys-kernel/spl-0.7.1 ~amd64
> 
> Yep, I think you are correct, I had the  in package.keywords and I
> think this is what made portage do that.
> When I commented them out, things are back to normal.
> 
> Thanks again.

That might have happened automatically as portage tends to want to unmask the 
latest version if it can't find an unmasked version that matches requirements.

I always answer "no" to those requests and copy/paste the actual lines myself 
after checking they are really what I want.

--
Joost




[gentoo-user] Re: emerge firefox-52.4.0 compile failure

2017-10-11 Thread Grant Edwards
On 2017-10-11, R0b0t1  wrote:
> On Tue, Oct 10, 2017 at 6:30 PM, Peter Humphrey  wrote:
>> What's called Management in ISO9000.
>
> ISO9000 still lets you shoot yourself in the foot. You just wrote
> down that you were going to shoot yourself in the foot well in
> advance.

Yep.  As somebody involved in the ISO9000 effort at a large
manufacturer once told me: "Being ISO9000 compliant doesn't prevent
you from shipping low-quality crap products.  It just means that you
_know_ you're shipping low-quality crap products."

The assumption presumably being that your _customers_ could also
figure that out from reviewing your ISO9000 documentation.  I have no
idea how many customers actually do a good enough review of their
vendors' ISO9000 documents to figure it out...

-- 
Grant Edwards   grant.b.edwardsYow! Inside, I'm already
  at   SOBBING!
  gmail.com




Re: [gentoo-user] why zfs and friends want to update to 9999?

2017-10-11 Thread John Covici
On Wed, 11 Oct 2017 04:50:20 -0400,
J. Roeleveld wrote:
> 
> On Wednesday, October 11, 2017 9:54:05 AM CEST John Covici wrote:
> > Hi.  In my latest world update, I have sys-fs/zfs and friends at
> > 0.7.1 and they all want to update to .  Does anyone know why this
> > should be -- normally  is not in the normal update sequence.
> > 
> > I am using the unstable gentoo, updated about 3 weeks ago.  No harm
> > has come yet, but I have not done the update till I can figure out
> > what is happening here -- particularly if I need a rescue cd which is
> > using zfs 0.7.1.
> > 
> > Thanks in advance for any ideas.
> 
> check your keywords, how did you unmask zfs?
> 
> Here are mine:
> 
> $ grep -r zfs /etc/portage
> /etc/portage/sets/zfs:sys-fs/zfs
> /etc/portage/sets/zfs:sys-fs/zfs-kmod
> /etc/portage/package.keywords/zfs:=sys-fs/zfs-kmod-0.7.1 ~amd64
> /etc/portage/package.keywords/zfs:=sys-fs/zfs-0.7.1 ~amd64
> $ grep -r spl /etc/portage
> /etc/portage/sets/zfs:sys-kernel/spl
> /etc/portage/package.keywords/zfs:=sys-kernel/spl-0.7.1 ~amd64

Yep, I think you are correct, I had the  in package.keywords and I
think this is what made portage do that.
When I commented them out, things are back to normal.

Thanks again.

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

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



Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

2017-10-11 Thread Peter Humphrey
On Wednesday, 11 October 2017 04:02:36 BST R0b0t1 wrote:
> On Tue, Oct 10, 2017 at 6:30 PM, Peter Humphrey  
> wrote:
> > What's called Management in ISO9000.
> 
> ISO9000 still lets you shoot yourself in the foot. You just wrote down
> that you were going to shoot yourself in the foot well in advance.

It aims to ensure that what is produced is exactly what is intended. If 
shooting yourself in the foot is a credible business objective, so be it, 
but you'd have trouble showing how the business would benefit from it, or in 
persuading an auditor. Or the shareholders in the business, for that matter.

ISO9000 operates at company management level, not programmer level.

Actually, I can't be authoritative on ISO 9000 today; my experience dates 
back 20 years, to when I got a varied group of 100 software people through 
an audit against ISO 9001 (long story, not relevant here). I don't suppose 
the principles will have changed much though.

-- 
Regards,
Peter.




Re: [gentoo-user] why zfs and friends want to update to 9999?

2017-10-11 Thread J. Roeleveld
On Wednesday, October 11, 2017 9:54:05 AM CEST John Covici wrote:
> Hi.  In my latest world update, I have sys-fs/zfs and friends at
> 0.7.1 and they all want to update to .  Does anyone know why this
> should be -- normally  is not in the normal update sequence.
> 
> I am using the unstable gentoo, updated about 3 weeks ago.  No harm
> has come yet, but I have not done the update till I can figure out
> what is happening here -- particularly if I need a rescue cd which is
> using zfs 0.7.1.
> 
> Thanks in advance for any ideas.

check your keywords, how did you unmask zfs?

Here are mine:

$ grep -r zfs /etc/portage
/etc/portage/sets/zfs:sys-fs/zfs
/etc/portage/sets/zfs:sys-fs/zfs-kmod
/etc/portage/package.keywords/zfs:=sys-fs/zfs-kmod-0.7.1 ~amd64
/etc/portage/package.keywords/zfs:=sys-fs/zfs-0.7.1 ~amd64
$ grep -r spl /etc/portage
/etc/portage/sets/zfs:sys-kernel/spl
/etc/portage/package.keywords/zfs:=sys-kernel/spl-0.7.1 ~amd64

--
Joost



[gentoo-user] why zfs and friends want to update to 9999?

2017-10-11 Thread John Covici
Hi.  In my latest world update, I have sys-fs/zfs and friends at
0.7.1 and they all want to update to .  Does anyone know why this
should be -- normally  is not in the normal update sequence.

I am using the unstable gentoo, updated about 3 weeks ago.  No harm
has come yet, but I have not done the update till I can figure out
what is happening here -- particularly if I need a rescue cd which is
using zfs 0.7.1.

Thanks in advance for any ideas.

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

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



Re: [gentoo-user] python build fail; undefined reference to pthread_* and sem_*

2017-10-11 Thread Walter Dnes
> ‹ӖÝYinfo.txt
> FÃþÅL
> (£)–QŽ@J=ŽRÊ%¥4ò•>#:Ӥȩ½ØnuŽÎ;k„ĉÎXö;©0¿K‡

  Something failed there.  I'll attach as plain text and hopefully the
"emerge --info" output will get through



-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications
Portage 2.3.8 (python 2.7.12-final-0, default/linux/x86/13.0, gcc-6.3.0, 
glibc-2.23-r4, 4.9.16-gentoo i686)
=
System uname: 
Linux-4.9.16-gentoo-i686-Intel-R-_Core-TM-2_Duo_CPU_E4600_@_2.40GHz-with-gentoo-2.4.1
KiB Mem: 3100240 total,391064 free
KiB Swap:9186324 total,   6902452 free
Timestamp of repository gentoo: Tue, 10 Oct 2017 21:00:01 +
Head commit of repository gentoo: 7b19294d5a0188d9fa4b4e948acb2683ee3c41e8
sh bash 4.3_p48-r1
ld GNU ld (Gentoo 2.28 p1.2) 2.28
app-shells/bash:  4.3_p48-r1::gentoo
dev-lang/perl:5.24.1-r2::gentoo
dev-lang/python:  2.7.12::gentoo, 3.4.5::gentoo
dev-util/cmake:   3.7.2::gentoo
dev-util/pkgconfig:   0.28-r2::gentoo
sys-apps/baselayout:  2.4.1-r2::gentoo
sys-apps/openrc:  0.28::gentoo
sys-apps/sandbox: 2.10-r3::gentoo
sys-devel/autoconf:   2.13::gentoo, 2.69::gentoo
sys-devel/automake:   1.9.6-r4::gentoo, 1.11.6-r1::gentoo, 1.15-r2::gentoo
sys-devel/binutils:   2.28-r2::gentoo, 2.28.1::gentoo
sys-devel/gcc:6.3.0::gentoo
sys-devel/gcc-config: 1.8-r1::gentoo
sys-devel/libtool:2.4.6-r3::gentoo
sys-devel/make:   4.2.1::gentoo
sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers)
sys-libs/glibc:   2.23-r4::gentoo
Repositories:

gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000

Installed sets: @dillo
ACCEPT_KEYWORDS="x86"
ACCEPT_LICENSE="*"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=native -mfpmath=sse -fopenmp -fomit-frame-pointer -pipe 
-fno-unwind-tables -fno-asynchronous-unwind-tables"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf 
/etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -march=native -mfpmath=sse -fopenmp -fomit-frame-pointer -pipe 
-fno-unwind-tables -fno-asynchronous-unwind-tables"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--autounmask=n"
FCFLAGS="-O2 -march=i686 -pipe"
FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles 
merge-sync multilib-strict news parallel-fetch protect-owned sandbox sfperms 
strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv 
usersandbox usersync xattr"
FFLAGS="-O2 -march=i686 -pipe"
GENTOO_MIRRORS="ftp://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ 
http://gentoo.netnitco.net;
INSTALL_MASK="/lib/systemd/system /usr/lib/systemd/system"
LANG="en_US.iso88591"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j1"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times 
--omit-dir-times --compress --force --whole-file --delete --stats 
--human-readable --timeout=180 --exclude=/distfiles --exclude=/local 
--exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X apng bzip2 cli cxx dri ffmpeg fortran gif jpeg modules ncurses nptl 
opengl openmp pcre png readline seccomp session ssl szip threads truetype webp 
x264 x265 x86 xattr xorg zlib" ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp 
atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 
fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx 
via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb 
unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default 
authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner 
authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache 
env expires ext_filter file_cache filter headers include info log_config logio 
mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id 
userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets 
stage tables krita karbon braindump author" COLLECTD_PLUGINS="df interface irq 
load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3" 
CURL_SSL="openssl" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate 
evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom 
oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing 
tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse" KERNEL="linux" 
L10N="en en-US" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 
mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console 
presenter-minimizer" LINGUAS="en en_US" OFFICE_IMPLEMENTATION="libreoffice" 
PHP_TARGETS="php5-6"