| View previous topic :: View next topic |
| Author |
Message |
jpsollie
Guru
Joined: 17 Aug 2013
Posts: 318
|
 Posted: Mon Sep 30, 2024 7:55 am Post subject: |
 |
|
| logrusx wrote: | | jpsollie wrote: |
*EDIT* : I assume you meant --builtpkgonly. |
| man emerge: | --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
_________________
The power of Gentoo optimization (not overclocked): [img]https://www.passmark.com/baselines/V10/images/503714802842.png[/img] |
|
| Back to top |
|
 |
jpsollie
Guru
Joined: 17 Aug 2013
Posts: 318
|
| Posted: Mon Sep 30, 2024 10:09 am Post subject: |
|
|
| Zucca wrote: | | Quote: | | Code: | | 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?
_________________
The power of Gentoo optimization (not overclocked): [img]https://www.passmark.com/baselines/V10/images/503714802842.png[/img] |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2128
|
| Posted: Mon Sep 30, 2024 10:48 am Post subject: |
|
|
<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: | | EXTRA_GN='jumbo_file_merge_limit=16' |
The law of diminishing returns applies for this>
_________________
Greybeard |
|
| Back to top |
|
|
jpsollie
Guru
Joined: 17 Aug 2013
Posts: 318
|
| Posted: Mon Sep 30, 2024 11:02 am Post subject: |
|
|
| Goverp wrote: | <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: | | 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?
_________________
The power of Gentoo optimization (not overclocked): [img]https://www.passmark.com/baselines/V10/images/503714802842.png[/img] |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2250
|
| Posted: Mon Sep 30, 2024 12:05 pm Post subject: |
|
|
| jpsollie wrote: | | Goverp wrote: | <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: | | 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 |
|
| Back to top |
|
|
jpsollie
Guru
Joined: 17 Aug 2013
Posts: 318
|
| Posted: Mon Sep 30, 2024 1:26 pm Post subject: |
|
|
| logrusx wrote: | | jpsollie wrote: | | Goverp wrote: | <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: | | 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
_________________
The power of Gentoo optimization (not overclocked): [img]https://www.passmark.com/baselines/V10/images/503714802842.png[/img] |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2250
|
| Posted: Mon Sep 30, 2024 1:42 pm Post subject: |
|
|
| jpsollie wrote: |
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.
| jpsollie wrote: | 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:
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 |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 181
|
| Posted: Mon Sep 30, 2024 2:13 pm Post subject: |
|
|
| jpsollie wrote: | | eschwartz wrote: |
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.
| jpsollie wrote: | | logrusx wrote: |
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.  |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
