That is an unusually manual way of implementing a binhost server, but yes, that should work. The only caveat is that your binary package needs to meet all of Portage's criteria for the secondary machines: correct version, acceptable keywords, matching USE flags and subslots, etc. I expect the realistic failure modes to be that Portage shows an error message and refuses to proceed, so this should be a safe experiment even if it takes you a few tries to get right.wrc1944 wrote:Can I avoid building qtwebengine 3 times, by building it once and then make a binary withand copy it to the other 2 installs to their /usr/portage/packages/dev-qt/ directories, and then emerge it withCode: Select all
quickpkg qtwebenginewhenever portage wants to rebuild or update it on an @world update?Code: Select all
emerge -K qtwebengine
Quite the opposite, actually. If much had changed, ccache would have failed to get many/any cache hits, and you would have rebuilt almost everything. As it is, you got lucky that -r1 made very few changes to central files, so most of the source files were eligible to be retrieved from cache instead of being rebuilt.DarkAudit wrote:Something's changed in the r1 package, hasn't it? There's no other way to explain how a package that takes 12 hours or more to build on an A10-8700P laptop suddenly is taking just over an hour.
Yes, qtwebengine needs very much memory to compile: With 4gByte RAM I need another 4bB on swap and I cannot run anything else during compilation. Another malfunction could be due to bad memory at regions normally not used that much.Tony0945 wrote:I leave my 2700X at -j16 I have 32G memory, no swap.pd1986 wrote:Everytime i complied qtwebengine, I had to reduce the thread from -j12 to -j6. otherwise, it would fail. Does anyone know why? Much appreciated.
Maybe you need more memory.

If you run out of memory for it to build it will fail so by reducing the parallel builds you use less memory. Most of it would probably build at the higher -j but there are few parts that eat up the memory.pd1986 wrote:Everytime i complied qtwebengine, I had to reduce the thread from -j12 to -j6. otherwise, it would fail. Does anyone know why? Much appreciated.
Code: Select all
Sun Oct 10 22:09:39 2021 >>> dev-qt/qtwebengine-5.15.2_p20210824-r1
merge time: 43 minutes and 50 seconds.

Code: Select all
#!/bin/bash
# If root partition is more than 50% full, delete any temporary directories and
# files that were left in /var/tmp/portage/ instead of being deleted.
#
# My root partition is on /dev/sda6 and the emerge command must not be running.
#
if [ `pgrep -c emerge` -eq 0 ] && [ `df | awk '/sda6/ {print $5}' | awk -F% '{print $1}'` -gt 50 ]; then
rm -rf /usr/tmp/portage/*
fiIf you would prefer rapid cleanup, there is FEATURES=fail-clean.Fitzcarraldo wrote:If the root partition is more than 50% full when I shut down the laptop, the script will automatically empty that directory. One less thing to think about.
Code: Select all
fail-clean
Clean up temporary files after a build failure. This is
particularly useful if you have PORTAGE_TMPDIR on tmpfs.
If this feature is enabled, you probably also want to en‐
able PORTAGE_LOGDIR in order to save the build log. Both
the ebuild(1) command and the noclean feature cause the
fail-clean feature to be automatically disabled.Tony0945 wrote:I leave my 2700X at -j16 I have 32G memory, no swap.pd1986 wrote:Everytime i complied qtwebengine, I had to reduce the thread from -j12 to -j6. otherwise, it would fail. Does anyone know why? Much appreciated.
Maybe you need more memory.
ulenrich wrote:Yes, qtwebengine needs very much memory to compile: With 4gByte RAM I need another 4bB on swap and I cannot run anything else during compilation. Another malfunction could be due to bad memory at regions normally not used that much.Tony0945 wrote:I leave my 2700X at -j16 I have 32G memory, no swap.pd1986 wrote:Everytime i complied qtwebengine, I had to reduce the thread from -j12 to -j6. otherwise, it would fail. Does anyone know why? Much appreciated.
Maybe you need more memory.
Understood. I never paid attention to the memory usage. I have 16G memory without setting swap. Thanks for pointing it outfirephoto wrote:If you run out of memory for it to build it will fail so by reducing the parallel builds you use less memory. Most of it would probably build at the higher -j but there are few parts that eat up the memory.pd1986 wrote:Everytime i complied qtwebengine, I had to reduce the thread from -j12 to -j6. otherwise, it would fail. Does anyone know why? Much appreciated.
I have MAKEOPTS="-j13 -l23" for qtwebengine with 24 cores and 32G ram and tmp/portage on tmpfs up to 16G. Higher -j just had me hitting swap and I still get the same compile times. It did fail the other day but I had like 20 tabs open in firefox and some in chrome, and firefox and wine ended up building at the same time, and I wasn't paying attention to all the memory going away until it went oom when I was restarting firefox because I had been trying to fix emojis (critical things). Waited a few minutes to be able to do anything, qtwebengine failed, firefox and wine were done building. Using zswap too if it matters. If tmp wasn't on ram it wouldn't happen and it might be slower but it would also just be thrashing the ssd more than is necessary.
This is on a 5900X I upgraded from a 2700X.
Code: Select all
Sun Oct 10 22:09:39 2021 >>> dev-qt/qtwebengine-5.15.2_p20210824-r1 merge time: 43 minutes and 50 seconds.
Compile fails when jumbo-build is enabled, it doesn't matter how low the value is. It's been like this since last year, it used to work just fine before.Ionen wrote:But it's already there? qtwebengine has USE=jumbo-build and it's enabled by default.Hund wrote:Does anyone know anything about the jumbo-build feature, if it's coming back or if we're doomed at long compile times forever now?
It used to work fine. It took me 'only' 2 hours to compile it then. Unfortunately, it was later completely removed and the time went up to 4-5 hours for me. It was then later added back, but it has never worked for me since it came back.Hu wrote:Your first question reads to me like:If it is present, but does not work, then that is a different problem. Since Ionen says it is enabled by default, I expect that it works by default for whoever tested it. If it does not work for you, we should understand why.
- USE=jumbo-build previously existed.
- It no longer exists, but I want to use it.
- Does anyone know if it will come back so that I can use it?
Here's the emerge log for it: https://cloud.operationtulip.com/s/x99Aw5mY3sZnZYdasturm wrote:So, when did it last not work, and how did it fail?

Does it really fail that way for you when using the default 'jumbo_file_merge_limit' as well?Hund wrote:Here's the emerge log for it: https://cloud.operationtulip.com/s/x99Aw5mY3sZnZYdasturm wrote:So, when did it last not work, and how did it fail?
What's the default? I have tried setting it to 100 and 50. I can't remember if I tried as low as 25.Chiitoo wrote:Does it really fail that way for you when using the default 'jumbo_file_merge_limit' as well?Hund wrote:Here's the emerge log for it: https://cloud.operationtulip.com/s/x99Aw5mY3sZnZYdasturm wrote:So, when did it last not work, and how did it fail?