On 2017-12-06 16:34, Alan McKinnon wrote:
And just to round off a mostly pointless discussion with little real
merit, the really stupid thing about portage is why oh why are ports
and
distfiles in /usr?
I'm really surprised that someone recognized this or may be does
question this.
On 06/12/17 15:34, Alan McKinnon wrote:
> Those guidelines you mention about what /tmp and /var/tmp are "for" are
> probably from the FHS. On the whole, I tend to agree they are good ideas
> but the proper wording is more like this (from memory, being far too
> lazy after a day's work to actually
On 06/12/17 15:34, Alan McKinnon wrote:
> - contents of /tmp are not expected to survive the invocation of the
> program that created them
> - contents of /var/tmp are not expected to survive a reboot
That sounds completely wrong, actually.
The contents of /var/tmp are expected to survive a
On 06/12/2017 15:29, Wols Lists wrote:
> On 05/12/17 21:56, Neil Bothwick wrote:
>> On Tue, 05 Dec 2017 10:09:56 +, Peter Humphrey wrote:
>>
>>> $ grep tmpfs /etc/fstab
>>> tmpfs /var/tmp/portage tmpfs
>>> noatime,uid=portage,gid=portage,mode=0775 0 0
>>> tmpfs /tmp
On 05/12/17 21:56, Neil Bothwick wrote:
> On Tue, 05 Dec 2017 10:09:56 +, Peter Humphrey wrote:
>
>> $ grep tmpfs /etc/fstab
>> tmpfs /var/tmp/portage tmpfs
>> noatime,uid=portage,gid=portage,mode=0775 0 0
>> tmpfs /tmp tmpfs
>> noatime,nosuid,nodev,noexec,mode=1777
On Tue, 05 Dec 2017 10:09:56 +, Peter Humphrey wrote:
> $ grep tmpfs /etc/fstab
> tmpfs /var/tmp/portage tmpfs
> noatime,uid=portage,gid=portage,mode=0775 0 0
> tmpfs /tmp tmpfs
> noatime,nosuid,nodev,noexec,mode=1777 0 0
Or you could set PORTAGE_TMPDIR to /tmp
On Tuesday, 5 December 2017 13:57:38 GMT Wols Lists wrote:
> I've just had a long thread with someone on the SUSE list who refuses to
> believe that the "twice ram" rule ever existed.
>
> This despite someone else actually describing the algorithm (from which
> one can see where the rule comes
On 05/12/17 13:07, Peter Humphrey wrote:
>> (My new system when I get it working maxes out at 64GB ram so I'll have
>> > 256GB swap and (currently) 16GB ram)
> I've halved my original 4GB swap to 2GB since it never seems to be used. I'm
> not brave enough to do away with it altogether though.
On Tuesday, 5 December 2017 10:46:43 GMT Wols Lists wrote:
> On 05/12/17 10:09, Peter Humphrey wrote:
> >> I assume using a ramdisk would help with this? I wouldn't want to do a
> >>
> >> > SSD as I assume it would excessively wear by doing compiles.
> >
> > I use tmpfs, like this:
> >
> > $
On Tuesday, 5 December 2017 11:13:53 GMT Raffaele Belardi wrote:
> Wols Lists wrote:
> >> If a tmpfs fills up, the excess gets swapped out, but with 32GB RAM here
> >> I
> >> haven't yet seen any swap used at all - not even in an emerge -e world.
> >
> > Same here. Note that tmpfs defaults to
Wols Lists wrote:
>>
>> If a tmpfs fills up, the excess gets swapped out, but with 32GB RAM here I
>> haven't yet seen any swap used at all - not even in an emerge -e world.
>
> Same here. Note that tmpfs defaults to half ram, so that would give you
> a 16GB /var/tmp/portage. With 16GB ram here,
On 05/12/17 10:09, Peter Humphrey wrote:
>> I assume using a ramdisk would help with this? I wouldn't want to do a
>> > SSD as I assume it would excessively wear by doing compiles.
> I use tmpfs, like this:
>
> $ grep tmpfs /etc/fstab
> tmpfs /var/tmp/portage tmpfs
On Tuesday, 5 December 2017 04:11:17 GMT taii...@gmx.com wrote:
> On my 16 core opteron I have to do -j32 or sometimes -j64 to be using
> everything all the time, is this normal? If I don't do this it won't be
> pegged at 100% all the time.
On my 12-thread i7 I have -j24 -l60. Most times it's
On Mon, Dec 4, 2017 at 10:11 PM, taii...@gmx.com wrote:
> On my 16 core opteron I have to do -j32 or sometimes -j64 to be using
> everything all the time, is this normal? If I don't do this it won't be
> pegged at 100% all the time.
>
I use a ramdisk and anything over -j${NCPU}
On my 16 core opteron I have to do -j32 or sometimes -j64 to be using
everything all the time, is this normal? If I don't do this it won't be
pegged at 100% all the time.
I assume using a ramdisk would help with this? I wouldn't want to do a
SSD as I assume it would excessively wear by doing
On Wed, 22 Nov 2017 09:57:29 +0100, David Haller wrote:
> Hm. What's this EMERGE_DEFAULT_OPTS though? ;)) And
> how can I override them if not wanted? .oO( gotta read up on that )Oo.
man make.conf
man emerge
emerge --ignore-default-opts
--
Neil Bothwick
The trouble with life is that you are
On Wednesday, November 22, 2017 3:34:56 PM CET Wols Lists wrote:
> On 22/11/17 14:11, Tsukasa Mcp_Reznor wrote:
> > You won't get build failures or dependency problems, portage is built to
> > handle emerging multiple packages that do not depend on each other
> > simultaneously.
> > it will not
On 22/11/17 14:11, Tsukasa Mcp_Reznor wrote:
>
> You won't get build failures or dependency problems, portage is built to
> handle emerging multiple packages that do not depend on each other
> simultaneously.
> it will not ever build a dependency and the main program at the same time.
Are you
From: Raffaele Belardi <raffaele.bela...@st.com>
Sent: Wednesday, November 22, 2017 8:12 AM
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] is multi-core really worth it?
Jeremi Piotrowski wrote:
> That being said: if you do a world rebuild you will have lots of packages
>
On Wednesday, November 22, 2017 2:12:31 PM CET Raffaele Belardi wrote:
> Jeremi Piotrowski wrote:
> > That being said: if you do a world rebuild you will have lots of packages
> > that spend ~40 seconds doing their autoconf run, only to build 2-3 sources
> > files. On an 8-core machine at work, I
Jeremi Piotrowski wrote:
> That being said: if you do a world rebuild you will have lots of packages
> that spend ~40 seconds doing their autoconf run, only to build 2-3 sources
> files. On an 8-core machine at work, I get good results using parallel
> emerge jobs (emerge -jX). For your 6-core AMD
On Wednesday, 22 November 2017 08:57:29 GMT David Haller wrote:
> Hello,
>
> On Wed, 22 Nov 2017, J. Roeleveld wrote:
> >On Wednesday, November 22, 2017 8:48:08 AM CET David Haller wrote:
> >> So, your emerge is mostly IO and "emerge"-threads bound. Solution:
> >> adjust your build-threads[1],
Hello,
On Wed, 22 Nov 2017, J. Roeleveld wrote:
>On Wednesday, November 22, 2017 8:48:08 AM CET David Haller wrote:
>> So, your emerge is mostly IO and "emerge"-threads bound. Solution:
>> adjust your build-threads[1], and then adjust your emerge jobs! See
>> '--jobs' in 'man emerge'. Can't find
Hello,
On Wed, 22 Nov 2017, Jeremi Piotrowski wrote:
>That being said: if you do a world rebuild you will have lots of packages
that (even without the fetch) spend 40 seconds setting up the emerge
(unpack, prepare (plus eautoreconf))...
>that spend ~40 seconds doing their autoconf run, only to
On Wednesday, November 22, 2017 8:48:08 AM CET David Haller wrote:
> Hello,
>
> On Wed, 22 Nov 2017, Raffaele Belardi wrote:
> >rebuilding system and world with gcc-7.2.0 on a 6-core AMD CPU I have
> >the impression that most of the ebuilds limit parallel builds to 1, 2
> >or 3 threads.
>
> Most
On Wed, 22 Nov 2017 08:26:01 +0100, Jeremi Piotrowski wrote:
> That being said: if you do a world rebuild you will have lots of
> packages that spend ~40 seconds doing their autoconf run, only to build
> 2-3 sources files. On an 8-core machine at work, I get good results
> using parallel emerge
Hello,
On Wed, 22 Nov 2017, Raffaele Belardi wrote:
>rebuilding system and world with gcc-7.2.0 on a 6-core AMD CPU I have
>the impression that most of the ebuilds limit parallel builds to 1, 2
>or 3 threads.
Most should build with "many" cores, but some might be limited, but ...
>I'm aware it
On Wed, Nov 22, 2017 at 07:52:54AM +0100, Raffaele Belardi wrote:
> Hi,
>
> rebuilding system and world with gcc-7.2.0 on a 6-core AMD CPU I have the
> impression that
> most of the ebuilds limit parallel builds to 1, 2 or 3 threads. I'm aware it
> is only an
> impression, I did not spend the
Hello,
On Wed, Nov 22, 2017 at 12:52 AM, Raffaele Belardi
wrote:
> Hi,
>
> rebuilding system and world with gcc-7.2.0 on a 6-core AMD CPU I have the
> impression that
> most of the ebuilds limit parallel builds to 1, 2 or 3 threads. I'm aware it
> is only an
>
29 matches
Mail list logo