[gentoo-user] Question about compilation

[gentoo-user] Question about compilation

[Jacques Montier]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

 Hello everyone,

Is it possible to stop a compilation midway in the case of a very long
compilation and then resume it from the same point without having to start
over from the beginning ?

Thank you for your response.

Best regards,

--
Jacques Montier.

[-- Attachment #2: Type: text/html, Size: 489 bytes --]

Re: [gentoo-user] Question about compilation

[Filip Kobierski]

Hi Jacques,

I think you are looking for SIGSTP or SIGSTOP but I think that's
not exactly it. From what I know you cannot do that for emerge
easily. For similar results you might want to set up ccache.
https://wiki.gentoo.org/wiki/Ccache

Regards
Filip

On Saturday, February 8th, 2025 at 15:47, Jacques Montier <jmontier@gmail.com> wrote:

> Hello everyone,
> Is it possible to stop a compilation midway in the case of a very long compilation and then resume it from the same point without having to start over from the beginning ?
> Thank you for your response.
> Best regards,
> 
> --
> Jacques Montier.

Re: [gentoo-user] Question about compilation

[Jack]

On 2025.02.08 14:00, Filip Kobierski wrote:
> Hi Jacques,
> 
> I think you are looking for SIGSTP or SIGSTOP but I think that's
> not exactly it. From what I know you cannot do that for emerge
> easily. For similar results you might want to set up ccache.
> https://wiki.gentoo.org/wiki/Ccache
> 
> Regards
> Filip
> 
> On Saturday, February 8th, 2025 at 15:47, Jacques Montier  
> <jmontier@gmail.com> wrote:
> 
> > Hello everyone,
> > Is it possible to stop a compilation midway in the case of a very  
> long compilation and then resume it from the same point without  
> having to start over from the beginning ?
> > Thank you for your response.
> > Best regards,
> >
> > --
> > Jacques Montier.
> 
If you really mean just interrupting a compile, then you should be able  
to stop with Ctl-C, and then start/continue by running make or ninja  
again, assuming that is what is used for whatever you are compiling.   
Ccache can help since most of the results of the previous compile  
attempt will have been cached, and so will be completed more quickly  
the next time, but it's not the same as continuing from where it was  
interrupted.

If, as Filip implies, you are asking about interrupting emerge, it's  
easy enough to interrupt, but essentially impossible to continue from  
where it left off.  "emerge --continue" will just try to emerge every  
package from the interrupted emerge which was not completed, but it  
will start each one from scratch.  What has often, but not alwasy  
worked for me, is to use ebuild directly.  "ebuild  
.../path/to/package.ebuild compile" will figure out that everything  
prior to the compile was completed, and then issue the make or ninja  
commands, which will just pick up where they left off.  If that does  
work, then you need to repeat the ebuild, but with the install and then  
the qmerge commands.  The only problem with that (for me, at least) is  
that ebuild does not leave exactly the same lines in emerge.log, so a  
package installed that way will not show up in "gentlop -t package"  
output.

Re: [gentoo-user] Question about compilation

[Michael]

[-- Attachment #1: Type: text/plain, Size: 3163 bytes --]

On Saturday 8 February 2025 23:07:38 Greenwich Mean Time Jack wrote:
> On 2025.02.08 14:00, Filip Kobierski wrote:
> > Hi Jacques,
> > 
> > I think you are looking for SIGSTP or SIGSTOP but I think that's
> > not exactly it. From what I know you cannot do that for emerge
> > easily. For similar results you might want to set up ccache.
> > https://wiki.gentoo.org/wiki/Ccache
> > 
> > Regards
> > Filip
> > 
> > On Saturday, February 8th, 2025 at 15:47, Jacques Montier
> > 
> > <jmontier@gmail.com> wrote:
> > > Hello everyone,
> > > Is it possible to stop a compilation midway in the case of a very
> > 
> > long compilation and then resume it from the same point without
> > having to start over from the beginning ?
> > 
> > > Thank you for your response.
> > > Best regards,
> > > 
> > > --
> > > Jacques Montier.
> 
> If you really mean just interrupting a compile, then you should be able
> to stop with Ctl-C, and then start/continue by running make or ninja
> again, assuming that is what is used for whatever you are compiling.
> Ccache can help since most of the results of the previous compile
> attempt will have been cached, and so will be completed more quickly
> the next time, but it's not the same as continuing from where it was
> interrupted.
> 
> If, as Filip implies, you are asking about interrupting emerge, it's
> easy enough to interrupt, but essentially impossible to continue from
> where it left off.  "emerge --continue" will just try to emerge every
> package from the interrupted emerge which was not completed, but it
> will start each one from scratch.  What has often, but not alwasy
> worked for me, is to use ebuild directly.  "ebuild
> .../path/to/package.ebuild compile" will figure out that everything
> prior to the compile was completed, and then issue the make or ninja
> commands, which will just pick up where they left off.  If that does
> work, then you need to repeat the ebuild, but with the install and then
> the qmerge commands.  The only problem with that (for me, at least) is
> that ebuild does not leave exactly the same lines in emerge.log, so a
> package installed that way will not show up in "gentlop -t package"
> output.

You can run 'ebuild <package> merge', but this will only continue with the 
last package you were emerging when it was interrupted and it will continue 
from whatever stage the emerge was at the time it was interrupted.

If your intention is to suspend/hibernate the OS halfway through an emerge and 
continue later on, then you can suspend the emerge job with job control:

Ctrl+z

After you wake up the system from suspend or reboot from hibernate you can 
bring the emerge job back into the foreground, so it can continue running from 
where you left it, by invoking:

fg

NOTE:  Depending how many threads you were running before you suspended the 
emerge and how much swap was being used, you may need to wait for a few 
minutes for all the threads to pause.  Keep an eye on top to confirm this has 
taken place and the CPU is now idle, before you suspend/hibernate the OS.  If 
you don't you could discover the suspend/hibernate fails if you do not have 
enough RAM/space.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Question about compilation

[Dale]

[-- Attachment #1: Type: text/plain, Size: 3616 bytes --]

Michael wrote:
> On Saturday 8 February 2025 23:07:38 Greenwich Mean Time Jack wrote:
>> On 2025.02.08 14:00, Filip Kobierski wrote:
>>> Hi Jacques,
>>>
>>> I think you are looking for SIGSTP or SIGSTOP but I think that's
>>> not exactly it. From what I know you cannot do that for emerge
>>> easily. For similar results you might want to set up ccache.
>>> https://wiki.gentoo.org/wiki/Ccache
>>>
>>> Regards
>>> Filip
>>>
>>> On Saturday, February 8th, 2025 at 15:47, Jacques Montier
>>>
>>> <jmontier@gmail.com> wrote:
>>>> Hello everyone,
>>>> Is it possible to stop a compilation midway in the case of a very
>>> long compilation and then resume it from the same point without
>>> having to start over from the beginning ?
>>>
>>>> Thank you for your response.
>>>> Best regards,
>>>>
>>>> --
>>>> Jacques Montier.
>> If you really mean just interrupting a compile, then you should be able
>> to stop with Ctl-C, and then start/continue by running make or ninja
>> again, assuming that is what is used for whatever you are compiling.
>> Ccache can help since most of the results of the previous compile
>> attempt will have been cached, and so will be completed more quickly
>> the next time, but it's not the same as continuing from where it was
>> interrupted.
>>
>> If, as Filip implies, you are asking about interrupting emerge, it's
>> easy enough to interrupt, but essentially impossible to continue from
>> where it left off.  "emerge --continue" will just try to emerge every
>> package from the interrupted emerge which was not completed, but it
>> will start each one from scratch.  What has often, but not alwasy
>> worked for me, is to use ebuild directly.  "ebuild
>> .../path/to/package.ebuild compile" will figure out that everything
>> prior to the compile was completed, and then issue the make or ninja
>> commands, which will just pick up where they left off.  If that does
>> work, then you need to repeat the ebuild, but with the install and then
>> the qmerge commands.  The only problem with that (for me, at least) is
>> that ebuild does not leave exactly the same lines in emerge.log, so a
>> package installed that way will not show up in "gentlop -t package"
>> output.
> You can run 'ebuild <package> merge', but this will only continue with the 
> last package you were emerging when it was interrupted and it will continue 
> from whatever stage the emerge was at the time it was interrupted.
>
> If your intention is to suspend/hibernate the OS halfway through an emerge and 
> continue later on, then you can suspend the emerge job with job control:
>
> Ctrl+z
>
> After you wake up the system from suspend or reboot from hibernate you can 
> bring the emerge job back into the foreground, so it can continue running from 
> where you left it, by invoking:
>
> fg
>
> NOTE:  Depending how many threads you were running before you suspended the 
> emerge and how much swap was being used, you may need to wait for a few 
> minutes for all the threads to pause.  Keep an eye on top to confirm this has 
> taken place and the CPU is now idle, before you suspend/hibernate the OS.  If 
> you don't you could discover the suspend/hibernate fails if you do not have 
> enough RAM/space.


Would that survive a full reboot?  I'm asking about a regular desktop
top system.  It's rare but sometimes I am doing updates and have a power
failure and have to shutdown until power comes back.  I've always just
done a emerge --resume but that starts any unfinished emerges from
scratch.  Just curious if this would work.  If I can remember to do it
if it does.  ;-) 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 4922 bytes --]

Re: [gentoo-user] Question about compilation

[Matt Jolly]

Hi Dale,

On 9/2/25 10:20, Dale wrote:

> Would that survive a full reboot?  I'm asking about a regular desktop 
> top system.  It's rare but sometimes I am doing updates and have a power 
> failure and have to shutdown until power comes back. I've always just 
> done a emerge --resume but that starts any unfinished emerges from 
> scratch.  Just curious if this would work. If I can remember to do it if 
> it does.  ;-)

Provided that your /var/tmp/portage isn't a tmpfs this will survive
reboots and enable you to use `sudo ebuild foo-1.2.3 ebuild merge`
to continue for _that package only_.

The rest of the emerge will need to be restarted and the depgraph
recalculated to finish whatever upgrade you were doing.

If it's something big like Chromium though, by all means use
`ebuild` to save a bunch of time - it's a lot better than
global `ccache`. :)

Cheers,

Matt

[gentoo-user] Re: Question about compilation

[Nuno Silva]

On 2025-02-09, Dale wrote:

> Michael wrote:
>> On Saturday 8 February 2025 23:07:38 Greenwich Mean Time Jack wrote:
>>> On 2025.02.08 14:00, Filip Kobierski wrote:
>>>> On Saturday, February 8th, 2025 at 15:47,
>>>> Jacques Montier <jmontier@gmail.com> wrote:
>>>>
>>>>> Is it possible to stop a compilation midway in the case of a very
>>>>> long compilation and then resume it from the same point without
>>>>> having to start over from the beginning ?
>>>
>>>> I think you are looking for SIGSTP or SIGSTOP but I think that's
>>>> not exactly it. From what I know you cannot do that for emerge
>>>> easily. For similar results you might want to set up ccache.
>>>> https://wiki.gentoo.org/wiki/Ccache
>>>
>>> If you really mean just interrupting a compile, then you should be able
>>> to stop with Ctl-C, and then start/continue by running make or ninja
>>> again, assuming that is what is used for whatever you are compiling.
>>> Ccache can help since most of the results of the previous compile
>>> attempt will have been cached, and so will be completed more quickly
>>> the next time, but it's not the same as continuing from where it was
>>> interrupted.
>>>
>>> If, as Filip implies, you are asking about interrupting emerge, it's
>>> easy enough to interrupt, but essentially impossible to continue from
>>> where it left off.  "emerge --continue" will just try to emerge every
>>> package from the interrupted emerge which was not completed, but it
>>> will start each one from scratch.  What has often, but not alwasy
>>> worked for me, is to use ebuild directly.  "ebuild
>>> .../path/to/package.ebuild compile" will figure out that everything
>>> prior to the compile was completed, and then issue the make or ninja
>>> commands, which will just pick up where they left off.  If that does
>>> work, then you need to repeat the ebuild, but with the install and then
>>> the qmerge commands.  The only problem with that (for me, at least) is
>>> that ebuild does not leave exactly the same lines in emerge.log, so a
>>> package installed that way will not show up in "gentlop -t package"
>>> output.
>> You can run 'ebuild <package> merge', but this will only continue with the 
>> last package you were emerging when it was interrupted and it will continue 
>> from whatever stage the emerge was at the time it was interrupted.
>>
>> If your intention is to suspend/hibernate the OS halfway through an emerge and 
>> continue later on, then you can suspend the emerge job with job control:
>>
>> Ctrl+z
>>
>> After you wake up the system from suspend or reboot from hibernate you can 
>> bring the emerge job back into the foreground, so it can continue running from 
>> where you left it, by invoking:
>>
>> fg
>>
>> NOTE:  Depending how many threads you were running before you suspended the 
>> emerge and how much swap was being used, you may need to wait for a few 
>> minutes for all the threads to pause.  Keep an eye on top to confirm this has 
>> taken place and the CPU is now idle, before you suspend/hibernate the OS.  If 
>> you don't you could discover the suspend/hibernate fails if you do not have 
>> enough RAM/space.
>
>
> Would that survive a full reboot?  I'm asking about a regular desktop
> top system.  It's rare but sometimes I am doing updates and have a power
> failure and have to shutdown until power comes back.  I've always just
> done a emerge --resume but that starts any unfinished emerges from
> scratch.  Just curious if this would work.  If I can remember to do it
> if it does.  ;-) 
>
> Dale
>
> :-)  :-) 

No, that's shell job control, it will live only while the shell process
lives, so wouldn't survive a shutdown/reboot.

There were one or two FEATUREs that could be used to restart where it
stopped, was it FEATURE="keepwork"? (I guess it's a bit like invoking
the build system or ebuild directly on the partial build as mentioned
upthread, but with the comfort of doing it through emerge.)

-- 
Nuno Silva

Re: [gentoo-user] Question about compilation

[Dale]

Matt Jolly wrote:
> Hi Dale,
>
> On 9/2/25 10:20, Dale wrote:
>
>> Would that survive a full reboot?  I'm asking about a regular desktop
>> top system.  It's rare but sometimes I am doing updates and have a
>> power failure and have to shutdown until power comes back. I've
>> always just done a emerge --resume but that starts any unfinished
>> emerges from scratch.  Just curious if this would work. If I can
>> remember to do it if it does.  ;-)
>
> Provided that your /var/tmp/portage isn't a tmpfs this will survive
> reboots and enable you to use `sudo ebuild foo-1.2.3 ebuild merge`
> to continue for _that package only_.
>
> The rest of the emerge will need to be restarted and the depgraph
> recalculated to finish whatever upgrade you were doing.
>
> If it's something big like Chromium though, by all means use
> `ebuild` to save a bunch of time - it's a lot better than
> global `ccache`. :)
>
> Cheers,
>
> Matt
>
>



Oops.  I didn't think about it being on tmpfs.  Given I have 128GBs of
memory now, I have a lot on tmpfs.  So, after a reboot, it would be gone
anyway.  Still, it would be nice if emerge had this feature, especially
for some of the big ones.  My big ones are LOo, Firefox and that qtweb
thing.  Last one being the largest. 

Worth a thought.  ;-)

Dale

:-)  :-) 

Re: [gentoo-user] Question about compilation

[MLR]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

Hi,


use a VM to build binpkgs, you can suspend the VM. Or build over chroot
from the VM in the main computer (you can suspend the VM).

Best regards


On 08.02.25 15:47, Jacques Montier wrote:
>  Hello everyone,
>
> Is it possible to stop a compilation midway in the case of a very long
> compilation and then resume it from the same point without having to
> start over from the beginning ?
>
> Thank you for your response.
>
> Best regards,
>
> --
> Jacques Montier.

[-- Attachment #2: Type: text/html, Size: 1472 bytes --]

Re: [gentoo-user] Question about compilation

[Håkon Alstadheim]

Den 08.02.2025 15:47, skrev Jacques Montier:
>  Hello everyone,
>
> Is it possible to stop a compilation midway in the case of a very long 
> compilation and then resume it from the same point without having to 
> start over from the beginning ?
>
> Thank you for your response.
>
For the big compiles I set PORTAGE_TMPDIR=/pt/ , which I have created 
and which is NOT a tmpfs, so it will survive a reboot (and I don't have 
enough ram anyway) . You might also want to check FEATURES, either 
globally or on a per-package basis, make sure you don't have fail-clean. 
Watch out so your newly permanent tmpdir does not fill up.

Then, if it dies for some reason, I do for example:

<code> ebuild `equery w www-client/firefox ` merge. </code>

make  or cmake or whatever will do the best it can to pick up where it 
left off.

P.S: Search the web to find out to set FEATURES and PORTAGE_TMPDIR in 
the environment on a per-package basis, or just prepend the settings to 
your command-line.

Re: [gentoo-user] Question about compilation

[Jacques Montier]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

Le dim. 9 févr. 2025 à 15:36, Håkon Alstadheim <hakon@alstadheim.priv.no> a
écrit :

> Den 08.02.2025 15:47, skrev Jacques Montier:
> >  Hello everyone,
> >
> > Is it possible to stop a compilation midway in the case of a very long
> > compilation and then resume it from the same point without having to
> > start over from the beginning ?
> >
> > Thank you for your response.
> >
> For the big compiles I set PORTAGE_TMPDIR=/pt/ , which I have created
> and which is NOT a tmpfs, so it will survive a reboot (and I don't have
> enough ram anyway) . You might also want to check FEATURES, either
> globally or on a per-package basis, make sure you don't have fail-clean.
> Watch out so your newly permanent tmpdir does not fill up.
>
> Then, if it dies for some reason, I do for example:
>
> <code> ebuild `equery w www-client/firefox ` merge. </code>
>
> make  or cmake or whatever will do the best it can to pick up where it
> left off.
>
> P.S: Search the web to find out to set FEATURES and PORTAGE_TMPDIR in
> the environment on a per-package basis, or just prepend the settings to
> your command-line.
>
>
>
>
Thank you all for your feedback and advice.
For testing,
- emerge media-libs/opencv-4.10.0
- some time later CTRL+C to stop compilation

Then I followed Jack's advice
- ebuild /var/db/repos/gentoo/media-libs/opencv/opencv-4.10.0.ebuild compile
- ebuild /var/db/repos/gentoo/media-libs/opencv/opencv-4.10.0.ebuild install
- ebuild /var/db/repos/gentoo/media-libs/opencv/opencv-4.10.0.ebuild qmerge

Everything worked fine, thanks a lot.

Good evening to all,

Best regards,

--
Jacques

[-- Attachment #2: Type: text/html, Size: 2337 bytes --]

Re: [gentoo-user] Question about compilation

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

On Sunday 9 February 2025 16:44:55 Greenwich Mean Time Jacques Montier wrote:
> Le dim. 9 févr. 2025 à 15:36, Håkon Alstadheim <hakon@alstadheim.priv.no> a
> 
> écrit :
> > Den 08.02.2025 15:47, skrev Jacques Montier:
> > >  Hello everyone,
> > > 
> > > Is it possible to stop a compilation midway in the case of a very long
> > > compilation and then resume it from the same point without having to
> > > start over from the beginning ?
> > > 
> > > Thank you for your response.
> > 
> > For the big compiles I set PORTAGE_TMPDIR=/pt/ , which I have created
> > and which is NOT a tmpfs, so it will survive a reboot (and I don't have
> > enough ram anyway) . You might also want to check FEATURES, either
> > globally or on a per-package basis, make sure you don't have fail-clean.
> > Watch out so your newly permanent tmpdir does not fill up.
> > 
> > Then, if it dies for some reason, I do for example:
> > 
> > <code> ebuild `equery w www-client/firefox ` merge. </code>
> > 
> > make  or cmake or whatever will do the best it can to pick up where it
> > left off.
> > 
> > P.S: Search the web to find out to set FEATURES and PORTAGE_TMPDIR in
> > the environment on a per-package basis, or just prepend the settings to
> > your command-line.
> 
> Thank you all for your feedback and advice.
> For testing,
> - emerge media-libs/opencv-4.10.0
> - some time later CTRL+C to stop compilation
> 
> Then I followed Jack's advice
> - ebuild /var/db/repos/gentoo/media-libs/opencv/opencv-4.10.0.ebuild compile
> - ebuild /var/db/repos/gentoo/media-libs/opencv/opencv-4.10.0.ebuild
> install - ebuild
> /var/db/repos/gentoo/media-libs/opencv/opencv-4.10.0.ebuild qmerge
> 
> Everything worked fine, thanks a lot.
> 
> Good evening to all,
> 
> Best regards,
> 
> --
> Jacques

Unless you have a good reason to run each emerge stage separately, you can 
just use 'merge' for all of them - you can check 'man ebuild' for an 
explanation.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Question about compilation

[Jacques Montier]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

Le dim. 9 févr. 2025 à 18:07, Michael <confabulate@kintzios.com> a écrit :

> On Sunday 9 February 2025 16:44:55 Greenwich Mean Time Jacques Montier
> wrote:
> > Le dim. 9 févr. 2025 à 15:36, Håkon Alstadheim <hakon@alstadheim.priv.no>
> a
> >
> > écrit :
> > > Den 08.02.2025 15:47, skrev Jacques Montier:
> > > >  Hello everyone,
> > > >
> > > > Is it possible to stop a compilation midway in the case of a very
> long
> > > > compilation and then resume it from the same point without having to
> > > > start over from the beginning ?
> > > >
> > > > Thank you for your response.
> > >
> > > For the big compiles I set PORTAGE_TMPDIR=/pt/ , which I have created
> > > and which is NOT a tmpfs, so it will survive a reboot (and I don't have
> > > enough ram anyway) . You might also want to check FEATURES, either
> > > globally or on a per-package basis, make sure you don't have
> fail-clean.
> > > Watch out so your newly permanent tmpdir does not fill up.
> > >
> > > Then, if it dies for some reason, I do for example:
> > >
> > > <code> ebuild `equery w www-client/firefox ` merge. </code>
> > >
> > > make  or cmake or whatever will do the best it can to pick up where it
> > > left off.
> > >
> > > P.S: Search the web to find out to set FEATURES and PORTAGE_TMPDIR in
> > > the environment on a per-package basis, or just prepend the settings to
> > > your command-line.
> >
> > Thank you all for your feedback and advice.
> > For testing,
> > - emerge media-libs/opencv-4.10.0
> > - some time later CTRL+C to stop compilation
> >
> > Then I followed Jack's advice
> > - ebuild /var/db/repos/gentoo/media-libs/opencv/opencv-4.10.0.ebuild
> compile
> > - ebuild /var/db/repos/gentoo/media-libs/opencv/opencv-4.10.0.ebuild
> > install - ebuild
> > /var/db/repos/gentoo/media-libs/opencv/opencv-4.10.0.ebuild qmerge
> >
> > Everything worked fine, thanks a lot.
> >
> > Good evening to all,
> >
> > Best regards,
> >
> > --
> > Jacques
>
> Unless you have a good reason to run each emerge stage separately, you can
> just use 'merge' for all of them - you can check 'man ebuild' for an
> explanation.
>


OK Thank you Michael !

--
Jacques

[-- Attachment #2: Type: text/html, Size: 3092 bytes --]

Re: [gentoo-user] Question about compilation

[Wols Lists]

On 09/02/2025 05:28, Dale wrote:
> Oops.  I didn't think about it being on tmpfs.

/var/tmp should not be on tmpfs. /tmp may or may not survive a reboot, 
/var/tmp is exlicitly where applications are supposed to store their 
crash recovery stuff, and so it is explicitly defined as surviving a reboot.

Doesn't stop people who don't know this from setting their systems up 
wrong - I did that initially :-)

Cheers,
Wol

Re: [gentoo-user] Question about compilation

[Dale]

Wols Lists wrote:
> On 09/02/2025 05:28, Dale wrote:
>> Oops.  I didn't think about it being on tmpfs.
>
> /var/tmp should not be on tmpfs. /tmp may or may not survive a reboot,
> /var/tmp is exlicitly where applications are supposed to store their
> crash recovery stuff, and so it is explicitly defined as surviving a
> reboot.
>
> Doesn't stop people who don't know this from setting their systems up
> wrong - I did that initially :-)
>
> Cheers,
> Wol
>
>


I have mine set up this way. 


tmpfs on /var/tmp/portage type tmpfs (rw,noatime,size=73400320k)


It's not /var/tmp that is on tmpfs but /var/tmp/portage that is.  That
way OS related stuff is fine but portage stuff that isn't really needed
in most cases is gone.  I also manually clean it sometimes because
failures can sometimes build up and take up to much space.  On my old
rig, this is really true since it is more limited on memory than the new
rig.  Going from 32GBs to 128GBs is a big increase in options. 

Good thing to check and mention tho.  If not done correctly, it could
cause issues. 

Dale

:-)  :-)