From nobody Thu Mar 26 23:37:47 2026 X-Original-To: freebsd-pkgbase@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 4fhgF43dMmz6WK1Z for ; Thu, 26 Mar 2026 23:38:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 4fhgF25948z3lYV for ; Thu, 26 Mar 2026 23:37:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=um6WUjJS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1774568275; bh=v/cHI1LBWqx6/V+8RtM1CeTO50NlnZvfuSm53e9oj5M=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=um6WUjJSFTx0/hZGsTWBjNTxlcwz1+nrsyTmXkULQ7gp2Y8dpdLEau86TUD0F83/vXKNmKIGvEkwHD9dU4SjEX5xDSsfTE7jQNWPnM7FRcNU9RPsh4DtEfnUum5YcT8tsp+Iwg662kQqs9y8d1qQAjUy2JGr2ka8hqEl/ydSygEEuiZ8Q3aOKFn/hVtgyxN6aQMgfnekfaLbd5l8Szk35YFtay3wv4Ou8DvIk3V2pA4SptIQfWERS9S4kMoYXY5K0GblPe4MygU0wwKG25V4KB0xVm6Q7pEQA5NxSbDFCf1X/jFBKzSHqfinL6K5y+5v5maFYdIYxnoU3fACN9XXKQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1774568275; bh=b60pM5th7EYU8qRJ7jeppzgK4bAJQSLBul9tqy4hGfN=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=WIwmcv0BqLB6IfkxdN/qF60JRZlMNpQQhba1KAc5BOkFOzupzz5I+xKye5zspnFu6lZi5qnP8CCzrbZYJr1GZ5AQrblYeKw4KoOZL+69Ed3IwgFcSaThif3fwsX9xEmk9npkFqd27kWHDQc6GDa8lFzVvYZManOQZjfHWwgA4Tgl/StqAeTPkgJ/W6bUc76gKnvqdQpGZ+44C8dRIk1a1XJC65vo4GUdGzv1343g5LmjqjtP85ci5yYx2pLD06oF/gahWIuAMnHfYadisJJZurEOHJ0+Qm9yAjEyAJhNhsJ2ciPHRRGOsXipsQABdCw9LHA1wiH1OiahxTXhvbfbSQ== X-YMail-OSG: Y_IyBJYVM1mEqynYBGfovW58b19kLewjLc7drzTeZrR9dq6lMChoK.yxl25LO0M s.V3bw6PXKs4Kxu8OieoQCCHWOGm_1TjuVVNNSm887mg2rHn.p7_jATTE3b9MhLq53ka7VkLVm.f P_V9Ma8Va0z99V.v92pObXio1eOjStOAgtgUuszNdtBn3C68fViEVVJh0sFKTlzyBS9qJZtj2O41 fesWTVl.erdnUlCx_CYTrbFcZ9SyeGdrWTLm__zAOLb7693yiHLoXsnqHtT8LdMaDh24MRHq1i2T gcuvswXnj9ZMXJ3o.HLFkW3H9EfFg9d8ADv9i_FvJhphaXQzRTzUY8JeEBuLAUDj4f1V0zgyyN3g 2Si5QHqbT3SZcBSbuyptfjUsv8r1qAy1uYI5uFiITAQN_Vxg.mVEbhFxCho5iCe2RsNe49OeOwEq O0GHAA9ZgmWtAOIWvD.5u98eJ7hmT309XA_igIgKYMfzrB4nFEjtKuUAMhm6cGKAOvGsiZeD2V0d IO6USEn_qBxEd3x5p3juqS6QCQCX2OVUfqprxYsEw.lEIjfM9LaxOD9SwcvpcthStz7RnfvvvESs OX4vKHvbQ4rXUyWwp7NQQBVTWfu39d_CaBCC.GFAk3FFva0RiIEdqLqgQZFPCd1MEM3YWYDDmGuJ C7X1qZlClY7YGktGu2menpIXT0FqFs0K7bqJzyeT1pYNB5P1hYoR.UUmoStBb80uTXn4ylzhUTYw OKn.Q2M5nj.46mlDIgvgSo6SUGdqqcJ7LoFcePy_FJfhvDG_y6LV9mfnL5iV6MsfgDojiPGa3UeQ klTTd0PACTBpr6lmscXL0yWkVYufMDsUFGdYHIB4zynfDop5NBeJs8qcGeVapSkW_Saq.Hk0G0vj PwhV7Z15X9uMo9qXUNpx88Nsgze2UtFw_vb49QzdKE0TRQ1wM67xq.JrOrHtPDtOJo7PbzWD_MT0 BuYjtduDF448q__iSn_l92mom1LDag2CWUmbisJWtOIJMMNFDaH1RUAwWopyqXcBJxotOS26UGmI IymyLYDJ4OnAoVVYyGzrdk9RXXWODyHqeBdBrddoz.xQDDwuwJ5Ph21KBL3SUPscWAir.t0os2jY OCmrCl2N2XPZz0kkSyuSmRPI7fcU.P5.14OCe.M7mrsPCezyZfSjySHAy_ZlOyZGJxUrqEOeYoZ3 BdbY46KCklzyY64REXWUPCKcb_v76YvylaCOA8gneFZ8nr11uApwHHXz7JamNCpLoNIEZU2zu8vA 2JKk1WnuPvR4w6HmDB9rZvhb_QO9PC33Nu0N3PuLZz0hi0ajD0v6LYQfQWXfQnh861d5Mfb.3xAg im10QhAD55V3SsE82HlCsa_VmtOO_bt1B6CaL0dmQBw10mMqeDRbxSyhyPKLf00fxGH3qjjHpA9X mGL_ZFumXXwboyliHi6MyYZXa7KVodN0cPfizLTfZkNXJNu85j0Aa4O8kNtV4YwVszwubGSmuSMb gl8oWqDLDfbnDdb07RnuoB4QWVFaRm86dnF_oH_Z1cDvZaw.1bJcujUaq5Okzau.0HeVtZucCBeN KVRwTiNGiLCmh0DfblY2WHcv6GtpIUzf9AVMG4e0pJcD_bBL7cLcuw_9kyv4STF8D_NPaDVxO1m6 Q2bM6pc7.Fhkx19X7Eq6I3_mAFORG_jB_NHj3p2KO9uurDXk__SnMX53vVEtpGQod5ScekDD9q3s 1X1Eam71dN5Gu3pp_rSfDDVIkbN0OPtndP6Q0e0.AagyxlmP.4HE9zloGEzjiVGt4UeVqZj22lIl TP3auW7SMpUE13_qmQezFcgcGWvVp5lwzqgF9SmTyFa6K84b7gcaonnufHdWwSyQbIIuJ.T_IKVs or7j1Qnv9B0XU_ShBVSclGwN9P1daLlWlWJcZuTGBmxd.uvgT9C6BBLAao6q9ENr_qRnYwbztM7y npPcBjbP.E1v7bl0ZU6sEOO16D7c0m9tYA7CN396.zdVbebUZguLJZhzgZ2H4n33wQCbMXM3ZckM xqWrlktNaUKre6vIbHKzLLqNsXg2OJGq1gvf9dC3iQ3SGnwUyk3PW7me4HP1974ZMbleRH66wZgM ejColptb2P.J_Wj0KQCoedLQebUzK1FCrX_XiWAef8VnH0oqd8vGVo_npQyLC8Xf3b6YfcwUiosi SHnc4pIQwJrs_UZhO49pRHfdU_bMNrfo0kM9_ranuB_Tum9SlSg43vn5IPbuWNMvgfS1fOPLgDJT E4fI8afti7j7eoaBYByj7Y72AwAcjE4aZD6HzhYOgiUgOKI22vacfdZrZM6ebfCjPg3Rm17EYxVQ NXOFYHAejJw6YDcouK5hdzTE4B97fKIOhG4IDLPJCaUms6dSB1c9ZVI4YpVpt9lX0 X-Sonic-MF: X-Sonic-ID: 2470f946-f47e-4c26-8f25-ad4133f34eed Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 26 Mar 2026 23:37:55 +0000 Received: by hermes--production-gq1-6dfcf9f8b-x2pwf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b27a04c476bd8004a13abaab6cfa71b2; Thu, 26 Mar 2026 23:37:48 +0000 (UTC) Message-ID: Date: Thu, 26 Mar 2026 16:37:47 -0700 List-Id: Packaging the FreeBSD base system List-Archive: https://lists.freebsd.org/archives/freebsd-pkgbase List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkgbase@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: installing world from src on a pkgbase system From: Mark Millard To: Pat Maddox Cc: freebsd-pkgbase@freebsd.org References: <0802ab25-0509-44d1-929e-2bb81108fa38@app.fastmail.com> <82e40b37-64b2-4dc2-b304-5002bacf4dc2@yahoo.com> Content-Language: en-US In-Reply-To: <82e40b37-64b2-4dc2-b304-5002bacf4dc2@yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25449 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.987]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-pkgbase@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from] X-Rspamd-Queue-Id: 4fhgF25948z3lYV X-Spamd-Bar: --- On 3/26/26 13:59, Mark Millard wrote: > On 3/26/26 12:05, Pat Maddox wrote: >> On Thu, Mar 26, 2026, at 9:52 AM, Mark Millard wrote: >>> On 3/26/26 04:30, polyduekes@proton.me wrote: >>>> On Thursday, March 26th, 2026 at 3:26 AM, Lexi Winter wrote: >>>> >>>>> polyduekes@proton.me wrote in : >>>>>> is needing to do both buildworld and buildkernel to create a pkg repo >>>>>> the intended behaviour or is that planned to change >>>>> >>>>> right now i don't believe there are any plans to change that. i suppose >>>>> it might change in the future. usually people want to build both the >>>>> world and the kernel, so this isn't an oft-requested feature. >>>>> >>>>> could you elaborate on why you want to build world but not kernel? >>>>> this would help inform development efforts in that area. >>>>> >>>> i usually make my own changes to base code to test some things and learn a few others,and most of the time the changes i make touch only world and dont touch kernel at all,so i like to avoid unnecessary compilation of the binaries and things i didn't change and doing only make buildworld and not make buildkernel buildworld is part of that reason >>> >>> Are you aware of META_MODE for buildworld and buildkernel (with its use >>> of filemon.ko)? Its purpose is to keep track of things and so generally >>> rebuild what is necessary but avoid rebuilding what is not. For example, >>> back to back rebuilds have the second one not taking very long based on >>> the lack of changes. >> >> How long is "not very long" in your experience? > > I happen to have been doing builds as part of a long overdue update of > my context. The below builds were executed from an official pkgbase > distribution of main that was booted, using the non-debug kernel that > was distributed. (Only a debug world is distributed for main.) But I was > building non-debug worlds and kernels of nearly the same source code, > with other tailoring involved, such as static linking of the llvm > related toolchain. > > I've access to a wide range of system performance, from old armv7 RPi*'s > to a 7950X3D amd64 system with Optane 1.4T media on PCIe. > > First picking an aarch64 system likely slow compared to common amd64 > hardware, but faster than a RP* aarch64 system, showing both > from-scratch build time and then the rebuild, not having changed > anything, showing both World and Kernel. . . > > Microsoft Dev Kit 2023 from-scratch build sequence, USB3 based media, 8 > core, 32 GiByTes of RAM: (I have reordered lines to have the world's > together and the kernels together and used extra end-of-lines to group > things and some leading spaces to avoid misformatting) > > # grep "built.*ncpu:" > /usr/obj/BUILDs/main-CA76-nodbg-clang/sys-typescripts/typescript-make-main-*.2026-03-2[56]* > > /usr/obj/BUILDs/main-CA76-nodbg-clang/sys-typescripts/typescript-make-main-CA76-nodbg-clang.aarch64-host.2026-03-25:23:12:00: > >>> World built in 10909 seconds, ncpu: 8, make -j12 > /usr/obj/BUILDs/main-CA76-nodbg-clang/sys-typescripts/typescript-make-main-CA76-nodbg-clang.aarch64-host.2026-03-26:13:04:35: > >>> World built in 146 seconds, ncpu: 8, make -j12 > > /usr/obj/BUILDs/main-CA76-nodbg-clang/sys-typescripts/typescript-make-main-CA76-nodbg-clang.aarch64-host.2026-03-26:02:13:50: > >>> Kernel(s) GENERIC-NODBG-CA76 built in 632 seconds, ncpu: 8, make -j12 > /usr/obj/BUILDs/main-CA76-nodbg-clang/sys-typescripts/typescript-make-main-CA76-nodbg-clang.aarch64-host.2026-03-26:13:07:02: > >>> Kernel(s) GENERIC-NODBG-CA76 built in 11 seconds, ncpu: 8, make -j12 > > > A faster system . . . > > amd64 7950X3D with Optane 1.4T media on PCIe, 32 freebsd CPUs (16 SMT > cores);, 192 GiBytes of RAM: > > # grep 'built.*ncpu:' > /usr/obj/BUILDs/main-ZNV4-*-clang/sys-typescripts/typescript-make-ZNV4-*-clang-amd64-host-2026-03-2[56]* > > /usr/obj/BUILDs/main-ZNV4-nodbg-clang/sys-typescripts/typescript-make-ZNV4-nodbg-clang-amd64-host-2026-03-25:15:50:07: > >>> World built in 1048 seconds, ncpu: 32, make -j48 > /usr/obj/BUILDs/main-ZNV4-nodbg-clang/sys-typescripts/typescript-make-ZNV4-nodbg-clang-amd64-host-2026-03-26:13:10:20: > >>> World built in 34 seconds, ncpu: 32, make -j48 > > /usr/obj/BUILDs/main-ZNV4-nodbg-clang/sys-typescripts/typescript-make-ZNV4-nodbg-clang-amd64-host-2026-03-25:15:47:41: > >>> Kernel(s) GENERIC-NODBG built in 91 seconds, ncpu: 32, make -j48 > /usr/obj/BUILDs/main-ZNV4-nodbg-clang/sys-typescripts/typescript-make-ZNV4-nodbg-clang-amd64-host-2026-03-26:13:10:54: > >>> Kernel(s) GENERIC-NODBG built in 2 seconds, ncpu: 32, make -j48 > > > So the example ratios span: > 10909/146 approx.= 74.7 > 1048/34 approx.= 30.8 I should have pointed out that back-to-back builds (no changes) have the 2nd build being about as fast as it can get: otherwise changes lead to more being rebuilt. Even back to back builds [no changes] do some build/linking activity. It is difficult to make everything perfectly minimal while always rebuilding when it is important. For some aspects there are tradeoffs for false positive vs. false negative handling for things not likely to actually need a rebuild. For the most part, where possible, the bias has been for uncertainty to lead to some rebuild activity that might not have been necessary --instead of having potential broken builds. An example context is: buildworld reboot installworld reboot buildworld The install activity leads to more rebuild activity later --from the install updating programs (and other files) to be technically newer than they were during the prior buildworld, despite lack of changes in those files that might be relevant to worrying about the program results being different for the use in the build sequence. For example, if echo contributed to a file's content (say, via >> use), how likely is it that an updated echo's output would be any different for that file in the rebuild? Arbitrary changes touching common usage results is unlikely for something like echo at this point. > > I'll not get into the details of my builds. The builds are personal > builds in various ways. > >> >> Pat >> >> > > Note: I'm not set up to send to freebsd-questions. > -- === Mark Millard marklmi at yahoo.com