how do you guys handle qtwebengine

[jpsollie]

*EDIT* : I assume you meant --builtpkgonly.

Code: Select all

       --buildpkg [ y | n ], -b
              Tells emerge to build binary packages for all ebuilds processed in addition to actually merging the packages.  Useful for maintainers or if you administrate multiple  Gentoo  Linux  systems  (build
              once,  emerge  tbz2s or gpkgs everywhere) as well as disaster recovery. The package will be created in the PKGDIR directory (see make.conf(5)).  An alternative for already-merged packages is to use
              quickpkg(1) which creates a tbz2 or gpkg from the live filesystem.
...
       --buildpkgonly, -B
              Creates binary packages for all ebuilds processed without actually merging the packages.  This comes with the caveat that all build-time dependencies must already be emerged on the system.

Buildpkgonly will break because portage needs the packages merged to link against them. Essentially you'll have almost identical copy of your laptop's system in that chroot. I think you could even synchronize it with rsync but it would be easier if you used binary packages.

Also, why are you not able to run emerge or compile distcc on the build server? How did you built it first place? It doesn't require gui. Only ssh.

Best Regards,
Georgi

The build server is fine. However: it has no GUI and I'd like to keep it that way.
Compiling qtwebengine into a binary package requires some compile-time dependencies which need to be installed before the package can be compiled, eg qtbase.
If I need to install all this junk onto a no-gui system, binary packages may indeed be the fastest way out

[jpsollie]

Code: Select all

distcc[3974] (dcc_execvp) ERROR: failed to exec x86_64-pc-linux-gnu-g++: Argument list too long

I think this a is bug. Bug in the upstream build process or in distcc.
It's quite rare to reach this limit. I mean, I think it's something like 2 megabytes or more arguments until this error is triggered.

building without distcc took 6hrs, but compiled.
so far, so good.
Can the feature flag for distcc be turned off for a specific package?

[Goverp]

<Aside - as I've not followed this discussion - the problems with command line too long might be down to jumbo-build.
It might be worth creating an env file specifying:

Code: Select all

EXTRA_GN='jumbo_file_merge_limit=16'

The law of diminishing returns applies for this>

[jpsollie]

<Aside - as I've not followed this discussion - the problems with command line too long might be down to jumbo-build.
It might be worth creating an env file specifying:

Code: Select all

EXTRA_GN='jumbo_file_merge_limit=16'

The law of diminishing returns applies for this>

would this also be useful when the jumbo_build flag isn't set?

[logrusx]

<Aside - as I've not followed this discussion - the problems with command line too long might be down to jumbo-build.
It might be worth creating an env file specifying:

Code: Select all

EXTRA_GN='jumbo_file_merge_limit=16'

The law of diminishing returns applies for this>

would this also be useful when the jumbo_build flag isn't set?

This is a parameter to jumbo built. It won't matter when jumbo is not enabled.

I'm curious, what are your arguments against building in a chroot. What are your arguments against using the binhost.

You're running circles around those and very rarely state your reasons.

Best Regards,
Georgi

[jpsollie]

<Aside - as I've not followed this discussion - the problems with command line too long might be down to jumbo-build.
It might be worth creating an env file specifying:

Code: Select all

EXTRA_GN='jumbo_file_merge_limit=16'

The law of diminishing returns applies for this>

would this also be useful when the jumbo_build flag isn't set?

This is a parameter to jumbo built. It won't matter when jumbo is not enabled.

I'm curious, what are your arguments against building in a chroot. What are your arguments against using the binhost.

You're running circles around those and very rarely state your reasons.

Best Regards,
Georgi

Not much, actually:
1) for the chroot solution: I am considering it right now as it looks like a clean setup.
I got experience with it for cross-compiling for a nanopi neo3 board running on gentoo. So yes, I'm thinking about it.
2) I'm somewhat concerned about my own binpkg NFS share:
The purpose of my ryzen 5 desktop PC is to build new GUI packages, store them on NFS fileshare and check if they work
If they are working in the config I built (deps, use flags, ...) I can push them to my laptops using usepkgonly.
I'm somewhat concerned that use flags I didn't want are sneaking through, ending with a completely different setup

[logrusx]

1) for the chroot solution: I am considering it right now as it looks like a clean setup.
I got experience with it for cross-compiling for a nanopi neo3 board running on gentoo. So yes, I'm thinking about it.

I don't think you need to cross compile. I should be very much like an installation. Just copy your world, make.conf and package.* and you should be good to go, given that your compile server CPU covers the CPU_FLAGS from make.conf.

2) I'm somewhat concerned about my own binpkg NFS share:
The purpose of my ryzen 5 desktop PC is to build new GUI packages, store them on NFS fileshare and check if they work
If they are working in the config I built (deps, use flags, ...) I can push them to my laptops using usepkgonly.
I'm somewhat concerned that use flags I didn't want are sneaking through, ending with a completely different setup

I think you can have both binhosts, yours with higher priority over Gentoo binhost and this way use some of the packages, but at a first glance it might prove to be more complicated than it's worth.

On the other hand you can:

Code: Select all

emerge -gvf

the ones you want from Gentoo binhost and then run emerge with k switch which will use the ones in the local cache. Unfortunately there's no easy way to enable/disable one host or another. Maybe manage some symlinks in /etc/portage/binrepos.conf as a way to switch them on or off.

The packages which will benefit you the most are not that many. The problematic qtwebengine, libreoffice, chromium, the compiles and toolchains... You can isolate them to a handful or even just a few. Those will make the biggest difference.

Best Regards,
Georgi

[eschwartz]

Is it not possible to ssh into the "compiling server" and spawn an emerge job there? If necessary you can even unpack a fresh stage3 tarball, chroot into it, configure it with the same make.conf as you have on your PC, and then use emerge --buildpkg qtwebengine. This is actually more or less what the official binhost does too, except you get to choose exactly what CFLAGS and USE flags you want. Then simply sync (or serve over https) the resulting binaries in /var/cache/binpkgs and load them on the PC.

ok ... but what about dependencies like eq qtcore?

*EDIT* : I assume you meant --builtpkgonly. It would be nice if you can pull everything into a chroot for compiling, otherwise you end up with a lot of use flags for dependencies compile-time dependencies on the no-GUI system you don't want...

buildpkgonly will avoid installing the binpackage into the chroot, which means it doesn't have to satisfy RDEPEND. It doesn't help satisfy build dependencies such as qtcore.

If you install it into a chroot, it is "just" files on disk, and doesn't end up running a GUI on your server, nor starting system services of any sort, etc.

I'm curious, what are your arguments against building in a chroot. What are your arguments against using the binhost.

You're running circles around those and very rarely state your reasons.

Not much, actually:
1) for the chroot solution: I am considering it right now as it looks like a clean setup.
I got experience with it for cross-compiling for a nanopi neo3 board running on gentoo. So yes, I'm thinking about it.
2) I'm somewhat concerned about my own binpkg NFS share:
The purpose of my ryzen 5 desktop PC is to build new GUI packages, store them on NFS fileshare and check if they work
If they are working in the config I built (deps, use flags, ...) I can push them to my laptops using usepkgonly.
I'm somewhat concerned that use flags I didn't want are sneaking through, ending with a completely different setup

FWIW, USE flags that you don't want can't sneak through since portage treats a binhost as a cache for actions it is already taking and packages it is already intending to install. The cache key consists of all your configured USE flags as well as things like SLOT dependencies. It does *not* include the CFLAGS used -- the binhost project builds two separate binhosts, one with generic -march=x86-64 and one with an optimized -march=x86-64-v3 (check if your system supports the latter, it will be listed in `ld.so --help` if so) -- so if precise CFLAGS matter to you then you may prefer building your own packages rather than use the binhost. But the technology for building your own binhost server and serving binpackages is the same either way, so you will get USE flag consistency either way, and just need to decide on your own CFLAGS compatibility.

If you want to test each package before you push it to laptops, then fetching Gentoo Binhost packages by installing them on the desktop PC would also allow you to test those packages and then re-host them yourself. Note as well that portage 3.0.66 (currently in ~arch) supports "location" in binrepos.conf, so that remotely downloaded *.gpkg.tar end up in a separate, isolated location by default. You could test a downloaded Gentoo Binhost package and then manually move that .gpkg.tar file into /var/cache/binpkgs and run emaint binhost --fix.


Then again, perhaps disabling jumbo builds is enough.

[freke]

Code: Select all

distcc[3974] (dcc_execvp) ERROR: failed to exec x86_64-pc-linux-gnu-g++: Argument list too long

I think this a is bug. Bug in the upstream build process or in distcc.
It's quite rare to reach this limit. I mean, I think it's something like 2 megabytes or more arguments until this error is triggered.

building without distcc took 6hrs, but compiled.
so far, so good.
Can the feature flag for distcc be turned off for a specific package?

via /etc/portage/package.env I believe https://wiki.gentoo.org/wiki//etc/portage/package.env
Never used/tried it for FEATURES myself.

[jpsollie]

I think this a is bug. Bug in the upstream build process or in distcc.
It's quite rare to reach this limit. I mean, I think it's something like 2 megabytes or more arguments until this error is triggered.

building without distcc took 6hrs, but compiled.
so far, so good.
Can the feature flag for distcc be turned off for a specific package?

via /etc/portage/package.env I believe https://wiki.gentoo.org/wiki//etc/portage/package.env
Never used/tried it for FEATURES myself.

I can work with that. Thank you!
Should I report this issue to the distcc or ninja devs?

[logrusx]

Can the feature flag for distcc be turned off for a specific package?

Here's what I used to do back in the days of struggling with old and very worked hardware: viewtopic-p-8195688.html#8195688

You can modify it for distcc.

Best Regards,
Georgi

[jpsollie]

Also, why are you not able to run emerge or compile distcc on the build server? How did you built it first place? It doesn't require gui. Only ssh.

Best Regards,
Georgi

You must have misunderstood:
The build server is 100% ok. Distcc and emerge are working fine.
I simply do not want to install all build-time dependencies.
That's why I like the idea of chroot so much

[Banana]

The build server is 100% ok. Distcc and emerge are working fine.
I simply do not want to install all build-time dependencies.

On the build server?

If yes: Isn't this the point of a build server to have everything needed to build?

[jpsollie]

The build server is 100% ok. Distcc and emerge are working fine.
I simply do not want to install all build-time dependencies.

On the build server?

If yes: Isn't this the point of a build server to have everything needed to build?

I also use it as a NAS, DNS, DHCP, qemu, cups forwarding and other server processes

[NichtDerHans]

I also thought of distcc this time ...
It's hard: the PC itself is only a ryzen 5 device while the "compiling server" is a 64 core threadripper with no gui.

[X] chroot

export the ryzen / to nfs
ssh to threadripper
mount the ryzen /
chroot into ryzen from threadripper over ssh

Faster as distcc

[logrusx]

I also thought of distcc this time ...
It's hard: the PC itself is only a ryzen 5 device while the "compiling server" is a 64 core threadripper with no gui.

[X] chroot

export the ryzen / to nfs
ssh to threadripper
mount the ryzen /
chroot into ryzen from threadripper over ssh

Faster as distcc

Is that OK on a live system? I think portage does practically the same, but I don't know if it takes additional measures against possible issues related to that.

Best Regards,
Georgi

[Zucca]

Just for "fun", I set my low-end box with dual core celeron to compile qtwebengine.
nodejs already took over 7h to complete…

EDIT: And after

Code: Select all

real    51m39.393s
user    92m7.575s
sys     6m10.725s

... it failed.

Code: Select all

Error: Cannot find module '/qtwebengine-everywhere-src-6.7.2/src/3rdparty/chromium/third_party/devtools-frontend/src/sc
ripts/build/ninja/copy-files.js'                                                                                       
    at Module._resolveFilename (node:internal/modules/cjs/loader:1219:15)
    at Module._load (node:internal/modules/cjs/loader:1045:27)
    at TracingChannel.traceSync (node:diagnostics_channel:315:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:215:24)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:158:5)
    at node:internal/main/run_main_module:30:49 {
  code: 'MODULE_NOT_FOUND',                                
  requireStack: []                                         
}                                                          

... seems like a relevant part of the log.

Yeah. I can see why it's so frustrating.

[jpsollie]

I also thought of distcc this time ...
It's hard: the PC itself is only a ryzen 5 device while the "compiling server" is a 64 core threadripper with no gui.

[X] chroot

export the ryzen / to nfs
ssh to threadripper
mount the ryzen /
chroot into ryzen from threadripper over ssh

Faster as distcc

yeah ... or simply rsync all relevant config files (package.use, package.accept_keywords, ...) into a stage 3 tarball at /usr/x86_64-compiler-linux-gnu/, and let the threadripper mirror the complete OS.
This magick will work:

Code: Select all

mount -o rbind /proc /usr/x86_64-compiler-linux-gnu/proc/
mount -o rbind /sys /usr/x86_64-compiler-linux-gnu/sys
mount -o rbind /dev /usr/x86_64-compiler-linux-gnu/dev
mount -o rbind var/cache/distfiles /usr/x86_64-compiler-linux-gnu/var/cache/distfiles
mount -o rbind var/cache/binpkgs /usr/x86_64-compiler-linux-gnu/var/cache/binpkgs
screen chroot /usr/x86_64-compiler-linux-gnu/ /bin/sh
emerge -eav @system @world

... and shutdown the client ryzen PC while the threadripper compiles everything painful (libreoffice, qtwebengine, firefox, thunderbird, you name it ...)
I think this is a better solution in a binpkg world, as you don't need to export / on a client (but off course /usr/x86_64-compiler-linux-gnu/ will be fat)

[NichtDerHans]

I also thought of distcc this time ...
It's hard: the PC itself is only a ryzen 5 device while the "compiling server" is a 64 core threadripper with no gui.

[X] chroot

export the ryzen / to nfs
ssh to threadripper
mount the ryzen /
chroot into ryzen from threadripper over ssh

Faster as distcc

Is that OK on a live system? I think portage does practically the same, but I don't know if it takes additional measures against possible issues related to that.

Best Regards,
Georgi

Do you mean live system on the compilemonster? That's fine, of course. I've been updating my little X220 laptop every two to four weeks, running a gentoo live CD in a VM on my fast computer.

[NichtDerHans]

I also thought of distcc this time ...
It's hard: the PC itself is only a ryzen 5 device while the "compiling server" is a 64 core threadripper with no gui.

[X] chroot

export the ryzen / to nfs
ssh to threadripper
mount the ryzen /
chroot into ryzen from threadripper over ssh

Faster as distcc

yeah ... or simply rsync all relevant config files (package.use, package.accept_keywords, ...) into a stage 3 tarball at /usr/x86_64-compiler-linux-gnu/, and let the threadripper mirror the complete OS.
This magick will work:

Code: Select all

mount -o rbind /proc /usr/x86_64-compiler-linux-gnu/proc/
mount -o rbind /sys /usr/x86_64-compiler-linux-gnu/sys
mount -o rbind /dev /usr/x86_64-compiler-linux-gnu/dev
mount -o rbind var/cache/distfiles /usr/x86_64-compiler-linux-gnu/var/cache/distfiles
mount -o rbind var/cache/binpkgs /usr/x86_64-compiler-linux-gnu/var/cache/binpkgs
screen chroot /usr/x86_64-compiler-linux-gnu/ /bin/sh
emerge -eav @system @world

... and shutdown the client ryzen PC while the threadripper compiles everything painful (libreoffice, qtwebengine, firefox, thunderbird, you name it ...)
I think this is a better solution in a binpkg world, as you don't need to export / on a client (but off course /usr/x86_64-compiler-linux-gnu/ will be fat)

That is also a possible way forward. If there are local ebuilds or other individual things involved, this must of course also be taken into the Treadripper.

If only one computer is involved, chroot is a good solution. At least that's how it looks to me.

[Zucca]

Code: Select all

2024-10-14T12:47:02 >>> dev-qt/qtwebengine: 9:19:17

on

Code: Select all

Intel(R) Core(TM) i5-7600T (4) @ 3.70 GHz

with 32GiB of RAM.

Holy compilation marathon, Batman!
I knew qtwebengine was big, but that big? Although I had USE=-jumbo-build.
Has anyone measured how much jumbo-build reduces the compilation time? In percents?

Also I always thought it was based on webkit and not the chromium (blink) fork.
I could then time compilation of webkit-gtk next...

[dmpogo]

Code: Select all

2024-10-14T12:47:02 >>> dev-qt/qtwebengine: 9:19:17

on

Code: Select all

Intel(R) Core(TM) i5-7600T (4) @ 3.70 GHz

with 32GiB of RAM.

Holy compilation marathon, Batman!
I knew qtwebengine was big, but that big? Although I had USE=-jumbo-build.
Has anyone measured how much jumbo-build reduces the compilation time? In percents?

Also I always thought it was based on webkit and not the chromium (blink) fork.
I could then time compilation of webkit-gtk next...

There is also an element that it seems modern compilers, while presumably being much smarter, are also much slower than compilers of the old days.

[Zucca]

There is also an element that it seems modern compilers, while presumably being much smarter, are also much slower than compilers of the old days.

Sure. I would assume -O0 would result faster compilation because it drops most of the "smart" things off.
Or by setting CC="tcc", but wouldn't even dream qtwebengine compiling with tcc... Also isn't qtwebengine mostly C++?

[eschwartz]

There is also an element that it seems modern compilers, while presumably being much smarter, are also much slower than compilers of the old days.

Sure. I would assume -O0 would result faster compilation because it drops most of the "smart" things off.
Or by setting CC="tcc", but wouldn't even dream qtwebengine compiling with tcc... Also isn't qtwebengine mostly C++?

Counterpoint: -O0 disables optimizations that lead to smaller code size, which means that the linker needs to do more work to link it all.

The extreme example is actually -ggdb, which actively adds loads of information to the program. Attempting to build very large programs like a browser with debug information is a nightmare, because linking already is a massive task that takes up tons of memory, and linking a debug-enabled version of a browser? Potentially terrifying. Maybe -O0 isn't so bad (I don't use it, I don't know) but I wouldn't be at all surprised to hear it actually increases the time and memory needed to finish linking.

[Chiitoo]

Code: Select all

2024-10-14T12:47:02 >>> dev-qt/qtwebengine: 9:19:17

on

Code: Select all

Intel(R) Core(TM) i5-7600T (4) @ 3.70 GHz

with 32GiB of RAM.

Holy compilation marathon, Batman!
I knew qtwebengine was big, but that big? Although I had USE=-jumbo-build.
Has anyone measured how much jumbo-build reduces the compilation time? In percents?

It's been a while since I actually tried, but I would still guess it should be about 50% of the time with 'jumbo-build' disabled (assuming the increased memory-use will not be a problem).

Also I always thought it was based on webkit and not the chromium (blink) fork.

There was Qt Webkit [1], which kind of fell into slumber, and eventually lost its outside-Qt maintainers as well.

1. https://code.qt.io/cgit/qt/qtwebkit.git/