Re: dns/bind916 builds rust unexpectedly
- In reply to: Dan Mahoney : "Re: dns/bind916 builds rust unexpectedly"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 26 Sep 2023 07:05:18 UTC
On 25/09/23 23:58, Dan Mahoney wrote: > > >> On Sep 25, 2023, at 14:41, Robert Clausecker <fuz@fuz.su> wrote: >> >> Am Mon, Sep 25, 2023 at 02:15:19PM -0700 schrieb Edward Sanford Sutton, III: >>> Poudriere still causes crashes in my experience depending on hardware, >>> poudriere configuration, and what you tell it to build; I have to change >>> defaults to use it and then it is fine. With only 32GB of RAM, if I have it >>> operate the whole build process in RAM >>> (USE_TMPFS=all>/usr/local/etc/poudriere) then I have to limit myself to 2 >>> build jobs (PARALLEL_JOBS=2, though I specify it on the poudriere command >>> line) or I 'may' have issues. Within that I can have multiple jobs per build >>> (ALLOW_MAKE_JOBS=yes>/usr/local/etc/poudriere, >>> MAKE_JOBS_NUMBER=4>/usr/local/etc/poudriere.d/make.conf) which gets through >>> each compile job much faster so no one job is as likely to be running >>> 'alone' holding up other jobs while cores sit idle. >> >> Ports tend to eat more and more storage for their source and dependencies these >> days. I encountered the same issue you had. A simple fix is to switch to >> USE_TMPFS="data localbase" which keeps the source code and objects of the package >> to be built on disk while placing dependencies into RAM. This does not actually >> reduce performance by much as the biggest spike in disk usage is when dependencies >> are installed and the distfile is extracted. This setting helps with the former >> while not doing much to the latter. During the build, compilers infrequently >> write small objects to disk, which gets handled very well by the write cache, so >> having the WRKDIR on disk doesn't hurt. The cache also quickly picks up on >> frequently needed source files, so there's little penalty in having to read them >> from disk every once in a while. > > I really, really wish the ports tree supported the option of: > > "I am building package X, but it requires dependency A, B, and C, which I will build as completely standard, so pretty friggin please, just pkg install them." > > So often have I done the dance of "Make...crap, ^c^c^c, pkg install autoconf...Make, ...dammit... pkg install dialog4ports....make....dammit, crap install bison...." > > pkg, as far as I know, has no concept of tracking the build-dependencies of a thing, but I would love the option of pkg --install-all-build-deps-for foo. > > "Just run poudriere" is a really crappy option when you just have a single box on an AWS t2-tiny install. > There is work in poudriere development to support using binary packages for dependencies. [1] Poudriere already has a -S flag to avoid rebuilding things when a run dependency changes. I see there is ongoing work related with this flag, but it should be usable most of the time, although it exposes to some of the same risks that building manually causes. [2] DISLAIMER: Everyone is free to manage his own machines as he sees fit, there is really no sanctioned way to do that, and building ports on live machines is supported, and I have fixed bugs in the ports I maintain that failed to build properly in such an environment, and will keep doing that to the best of my abilities. But I also must state that doing things like that is a way to look for unnecessary trouble. Poudriere is resource hungry, because building software is resource hungry and will get even hungrier. I started computing on a Spectrum 48K and am still baffled by how we got to a condition where 48K is not even enough for a simple configuration file, but here we are. [1] https://github.com/freebsd/poudriere/commit/a587ae7a3741d56a3991d030a8d08b6e9e619f07 [2] https://github.com/freebsd/poudriere/issues/806 -- Guido Falsi <madpilot@FreeBSD.org>