From nobody Wed Mar 6 02:43:30 2024 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TqGw45RVdz5Dx5G for ; Wed, 6 Mar 2024 02:43:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TqGw353JHz4BqS for ; Wed, 6 Mar 2024 02:43:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="Ny71/79D"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1709693023; bh=2mcFLP9Hf6mC7HPE1IqCd+qqAeJSLiRD/BPs5dexSn8=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=Ny71/79D1J0j/eFMRKBFrWIRMszlVJF2G4d4cPpTxUa5zIEa61lXz8uw6S+9Ov8gtq5cjIWnGAyIj9u1oH+im2PMY3gFop38iNOXhLyYsbplgKRxuQz4VqYOicVM5Ohkm1mbixC0/fDQWKxEiIrQeTOX3NwFUvOLUMtJM7vqReTv/g15adQlaOW6yHqZWbm3f++r3neSlnUhhpb3BEuKT3GFtg+mg/kSBc0qRDcleIDaMNs+kHKQGpSpVgNvFUxqgmk/KJv6eBlGBirT9YN5u+k/hzS3CfoFoKILeqjly91Ypumgd/lEgObRXOYfmWk0wrUPydaiZaax7ibK7kNNQA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1709693023; bh=cwh2DyI+Mgw0328gz9ieq8TnsfbHal31jI1efyKrePp=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Xcp+RcKe0X+ES3wIEP7o2gGLH7WKtoeJCOE52+e44v3PNYvYqIJdA5nz4AkHqMMdtzcNp2ZH6Lss/fWIgVUBRwe5t2vaYM8+0cUVRwbeK2zciTEJ+sEZfmOr/lIjYPXpD7LlnfNnqQEKtmW+GzjOR3uxOKXTuxFSsxWpJWEq1FZRl8l6VKuiULfwLwiACuGIqV7bVy93t0aV/U+1O2PnmRtziKv1UPXTutYMDC3UkNhsFqI/oXIOS1NzV9oIJ/YoIaB8AvAeAsRusFtpjhV8uBCqhLU56xIbITR/xNPxJFwJ77j48vXfMfpYMc0pBNLBBRTV/TJPCizazVPRbeVJaA== X-YMail-OSG: 3aS_ZW4VM1lMq7bi46kdIRpWQRCTMDxGaBMIZub8VzxpAfuv7NjA_0olS5QulaX 44lsk6dt75bnOKbC0lngaki18QKkqtLQznZcPybBPVsnWp1rfjIWdQm.o3U_nl02oe8IIvGB5YLE TltNmikYh.LpF6bm6V7FDScNQcJLnRXQmRKVfwLKfhZB0LTUjyB.F0iA8DAq5hdf8PuKXGiqzAe. wWuBVsesEZLy34H912gtRN2mucESDc8fYw7GffzOg175phh8urqxTZt9mLCWqIZ..KcEiLOsL7PC DxZiQ1x9lednikKFD5CdcpHctSViZ.Skfb3vVcQ3MtlDvcuEknnUHYsUjBe1AcvuTYP.MRt3fYHM nHFbkFpGU5xFjun76xAoA6kI9haUDHnGZw43Nu2klPW00.I0WYBjx9VnLKNKd7uAh2u0WxQtX4wc ijm2ZMu9qVHJdAg4nipzwjQv8nvJns52Z.99jF7IfE_ST01ql2nDw7SY9HExYk9Ch2lt1RLEcDxY z4VmvNRK_0NFo1E67l3K0js0NY4VJgOmamBgfjtInB7lT00hlydH59QbROLi92UoikA8u5w_sDNZ _erchEEJzjcNym0t35qrgs6FsPxcNiopKSEYlXG93QU9jiTu6RwdkYmHeeY50HNTAI_RuaHkAlSt mJrHxnI0SsovhcqRVWGHBOQABQqkylrGbXXwJMpaVBaPjddxtUbnqpuDffC4uvzaWknFymwi7EW9 Hnqwd4NOFEh9cKBLnQCkV.8B5NypaJ7UBVIdeXPzY5ZDxaq.3WrBHB_FekBna.7S_H2GGDstWelk sYa_0qA9z4MC14yQQk0RJoTfsYB4oiodGU4c.3IjTF1W970Hlp9vMs1oUGD_4eLJm9FRaKeEdwLt H.P83U0UwAMTSFTPIGwj.ZhWD.yJc1D6jAXbpVW5srUMeEoGeV4jnv6EtuUX8x7AjDFmOq8QkzjJ 7TsvX402ZX0LU_DE3JFyW7fiL_lQXN03V6nuSl0fATsvLh3xdCrQ8.MRUC4F3GrAnA4RSg3VKigq lDNdbuXBXGOMMT5nXVX8RQ2tqCteLTwVZ6lL3T7aQH91hZhr3vQcfcg7Ka391YJH6B_9WG3cnZ.t 6xOjGgGn0sbOS7_ban2DrJ93o57G66HrDD55W5Jvp8hag__0ElOkorpNELbTjug3umBmPqQQK27J wPCBz16ACIYW3954I_HgfaYMjoJYv6GrvNN5ks7RewE2_TLDlVQaf0RosgxaBo0x8Yxil2BWZZVn LUaMwohCVxUX.Xg41U7cVOz87DiGSBdFgUE.JP6Whfb9_UvcAky3I130RopQ0qXiCqjQavnMRRHO zPtnRjtWzvY03jGJ9ZoK_c9iPC1mkBNliAasE2L7lfHwjg8aETT3._y4PuYeTLzlTjX1cd3ve2b9 vm3BZPN.L7KTzGTm_dGo5qY.4ndxJy3IvIY.eUNYmq.CJV_uCu0AoZ.8UNxnPk9Hs85iXJsxa2Hb knldnyhjC6Q9yb7c9VsciS5.VflrFJqH6whqhBc8ePFtzI1UNXckjocfWRySd8w53wPhbes_3p78 hPFem_liVrH1K5lsY0.YMB0XgMM1QiS2PZ1fpUHMyaTvQlHerc_UrRIv6wY53BoymP9k18apuXyr roGYOWrVT1aK0g4KiwS829GSKIOKRpCk9mQz5ZSj4UGxrBr4kQn5mhP0aPqCloNf7EaxTRsu5wCY XztM_BF1P8MJKytUr8Cz2XhqegxL0qxJbiBljy9L5hUwPXsYjuxBwyr5Zk7X3fIsJYj1eIR93.Ju LSARsZszYisSJipr5C57vOtq7uDTRCNxpy5UNhCbGVk3h8z48cqNRyqRPveWpKRb9BxKNKNbtUxX fITMV1QoLniOMqktZauW5_cbQzdcB_k14_MVTsRzQVOpMpedUhzgqaL8XTSuZrP3uxddMjCSVpHR Lx6P5huBx5uYfesd08DKpNd_Y3JSYjymCeDEfvYvEcDOLHV31WmiVY8WMo2Vh990B6ipRMHEXZJi mcmtCMLwoRSIDaAenFtoaFjCAMFsC5JbVU7LRV3E.bA6UkbpZJLZBY5tRDsHoyuJ0bGCKhO_SWtl Vc4CVuvV7Ku3j5KwmflqakCRTjqSYDaGMKGGPpZQYNR2AJMtYOVw073aXHxenZRee2uNLeMPw_7J .MclVDgIObChKL1gT5dfTwTRj.JTmstF3SDpMbh95fL1049A0ryG82NBEyh1Lv5ANHg2svk860VI z0hFkohNEyAgEYtdVTAywX9UbOqtf_uDdiNAhPY9OJI.bW.0YQJqXMyUyotk- X-Sonic-MF: X-Sonic-ID: f59e0b3c-6406-4e81-9573-33fb6c97f8df Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 Mar 2024 02:43:43 +0000 Received: by hermes--production-gq1-5c57879fdf-6xjwd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ec4a4cebb7eb2b3597299434a4a1c87f; Wed, 06 Mar 2024 02:43:41 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: FreeBSD ports community is broken [port building configuration notes] Date: Tue, 5 Mar 2024 18:43:30 -0800 References: <87B38D6C-1D83-4158-B03B-F4C8EA396DD1@yahoo.com> To: FreeBSD Mailing List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; APPLE_MAILER_COMMON(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from] X-Rspamd-Queue-Id: 4TqGw353JHz4BqS [I noticed that my SWAP figures were not self consistent for the armv7.] On Feb 18, 2024, at 09:50, Mark Millard wrote: > [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 wrote: >> >> [I forgot to mention the armv7 core count involved: 4] >> >> On Feb 18, 2024, at 08:52, Mark Millard wrote: >> >>> Aryeh Friedman 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): Actually: 2 GiByte RAM armv7 has 3.6 GiByte SWAP space, with some margin. Ever so slightly over 3.8 GiBytes got the mistuning warning but there is variability across builds so I try to avoid repeated adjustments by picking somewhat smaller. >> 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 That equation should have been RAM+SWAP==2.8*RAM (with margin considered), so SWAP==1.8*RAM. (With a small enough RAM 2.7*RAM might need to be used, for example.) So the 2 GiByte RAM leads to a 5.6 GiByte RAM+SWAP for the builders and other uses to share. I may set up a modern experiment to see if the combination: PARALLEL_JOBS=2 ALLOW_MAKE_JOBS=yes (with MAKE_JOBS_NUMBER=2) still completes for a build that would end up with llvm18 and rust likely building in parallel for much of the time (if it completed okay, anyway). Something like 265 ports would be queued, the last few of which include some use of llvm18 and of rust. If it failed, I'd revert to using PARALLEL_JOBS=1 and MAKE_JOBS_NUMBER=3 and see how that went. llvm18 and rust would no longer build in parallel. If that also failed, I'd revert to MAKE_JOBS_NUMBER=2 . The last option would be MAKE_JOBS_NUMBER=1 . It has been a notable time since I last did such an exploration on such a small configuration. >>> 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