Date: Sun, 18 Feb 2024 09:50:45 -0800 From: Mark Millard <marklmi@yahoo.com> To: aryehfriedman@gmail.com, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: FreeBSD ports community is broken [port building configuration notes] Message-ID: <B623B102-F70D-4FD5-99F3-6E60B9D31187@yahoo.com> In-Reply-To: <C2D38005-534B-44D6-8C1B-88756A946229@yahoo.com> References: <87B38D6C-1D83-4158-B03B-F4C8EA396DD1@yahoo.com> <C2D38005-534B-44D6-8C1B-88756A946229@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[I also forgot to mention an important FreeBSD configuration setting as well. It is not specific to poudriere use.] > On Feb 18, 2024, at 09:13, Mark Millard <marklmi@yahoo.com> wrote: > > [I forgot to mention the armv7 core count involved: 4] > > On Feb 18, 2024, at 08:52, Mark Millard <marklmi@yahoo.com> wrote: > >> Aryeh Friedman <aryehfriedman_at_gmail.com> wrote on >> Date: Sun, 18 Feb 2024 10:37:06 UTC : >> >>> It should not require >>> prodiere running on a supermassive machine to work (in many cases >>> portmaster and make install recursion fail where prodiere works). >> >> As for configuring for small, slow systems relative to >> resource use, I provide some settings that I've >> historically used below. Then I have some other notes >> after that material. >> >> For a 2 GiByte RAM armv7 system with 3 GiByte swap space >> and a UFS file system, no use of tmpfs in normal operation >> (since it competes for RAM+SWAP generally): > > FYI: The armv7 has 4 cores. > >> /usr/local/etc/poudriere.conf has . . . >> >> NO_ZFS=yes >> USE_TMPFS=no >> PARALLEL_JOBS=2 >> ALLOW_MAKE_JOBS=yes >> MAX_EXECUTION_TIME=432000 >> NOHANG_TIME=432000 >> MAX_EXECUTION_TIME_EXTRACT=14400 >> MAX_EXECUTION_TIME_INSTALL=14400 >> MAX_EXECUTION_TIME_PACKAGE=57600 >> MAX_EXECUTION_TIME_DEINSTALL=14400 >> >> /usr/local/etc/poudriere.d/make.conf has . . . >> >> MAKE_JOBS_NUMBER=2 >> >> /etc/fstab does not specify any tmpfs use or the >> like: avoids competing for RAM+SWAP. >> >> The 3 GiBytes of swap space is deliberate: RAM+SWAP >> is important for all means of building in such a >> context: there are a bunch of ports that have >> large memory use for building in all cases. >> >> [armv7 allows around RAM+SWAP=2.5*RAM before >> tradeoff/mistuning notices are generated. aarch64 >> and amd64 allow more like RAM+SWAP=3.4*RAM before >> such notices are reported. The detailed multiplier >> changes some from build to build, so I leave >> margin in my figures to avoid the notices.] >> >> I also historically use USB SSD/NVMe media, no >> spinning rust, no microsd cards or such. /boot/loader.conf has . . . # # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=120 This is important to allowing various things to complete. (The default is 12. 120 is not the maximum but has been appropriate in my context. The figure is not in time units but larger increases the observed delay so more work gets done before OOM activity starts.) Using vm.pageout_oom_seq is not specific to poudriere use. >> As far as more ports building in poudriere than in >> "portmaster and make install recursion" in other >> respects than resources: it is easier to make ports >> build in poudriere. It provides the simpler/cleaner >> context for the individual builders. More things >> lead to failure outside poudriere that are just not >> issues when poudriere is used so more care is needed >> setting up the ports for the likes of portmaster use. >> (And, yes, I used to use portmaster.) The required >> range of testing contexts is wider for use of the >> likes of portmaster to know that the port build will >> just work in the full range of contexts. >> >> Such issues adds to the port maintainer/committer >> development burdens when portmaster or the like are >> the target level/type of support. >> >> (Note: synth may be more like poudriere for this >> but I've historically had use of platforms that >> synth did not support and so have not looked into >> the details.) === Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B623B102-F70D-4FD5-99F3-6E60B9D31187>