From nobody Tue Dec 23 16:04:00 2025 X-Original-To: freebsd-current@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 4dbKZW3xVpz6LfXP for ; Tue, 23 Dec 2025 16:04:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (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 4dbKZV6Kxmz3Kgr for ; Tue, 23 Dec 2025 16:04:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766505854; bh=kIXE3V1WKTnh1A2+m/m00hpdckLFkZEJL57G1zkxu1w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CqOEmjNRXDYP5O5WKu3uojEdugrNU52Jdgr11HkcjJdSIrIubA5CKG+V+bZ9sQ/Ce3cSwHdqG1rbUS/6awM9fDDHuGsxwH1fEJhFQjCrfNGHF/jOoUzahirgOfbTQlQCTI3JPZCc+GzVjLsqe1IuTtBd7OXbQ0GpFy0CGa/8LDc4bWxFW4+x7F2soZsNR0Ofb1bsM++Hue5hU+2sR4tnCBkizQ/Gsl8My+QMGCN0NtEwE4oLitPghNj/PLDzMJE23Zgv4tDDOD1xtEqFvgXvEJEduEPqnyAgV1mi/mFfGuM+18B2OOdg7hJe6FTSze/gx+gR++bfy6+LQQV6fYCIVw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766505854; bh=5VGPyZljefi4Ov/9bll3TAbz3ek/wLtH+d0duThMilS=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Nx3TqL0WwRr88SxJFTk3/a/NcmSnR/9GndVc+oiXo6DEYxqId6dUCro6q8soItURR3DgOlee/QR/Quomc8q5v5QvNm0TpLaKSAvDmrYn5A+0XJpZTIwiq24rG8i9Om/ufkLXZVxA7pfO7OiKI8R23OZ1rWLzutr4LPRWpJjpHQtnOYdE1Xz0Q8np861qR0dJGkowtFifxArR83CUjYFGwkgCak7/P1U4PU1nH1tCgoJ5ry5MpbsHfUqIvkvYQqFD2PIUe/qROD9H5feCQvFvqnwAyn+cqhxxWzbrQuAVgZAcqd0yqONl3pjgVVUvEOEUXALQL67S4qlgUgBk+4iECw== X-YMail-OSG: WHpJh5wVM1ndW5XkQWqEvD_7bb5sKLJSUgGYGVqe7YBQkiIXiD8meZl2y9odVhN NnMM3Kzh3QJwJsdAvwhQFGsS8ZqByQbi3e6HC3JdGO3oIWffMIxE2ImvE7J6HZph0OJB6F7CByyC .Q3YQVzsIn3vwQXVpFupURF.bWDCV1jv4elURWd75cergE_CKVA6ihrFzWxy.Gb6Sb_Fj4gXDBWb i6dBtXEfgESXom_RaccrhMZR3t6fJBT875BR3qFVqWoZ88mng22.KUW4Ewjr3.2xkFt3w_5bQYm7 Yrb0tH.2CIpU5ERMemiK6CxLISppiDRMbqDdBLN_eMhwHZ72ZpL_yWXBfgD3El6k60fBCXcgBeW7 8crmsCMz.XMW2p0GyHyTjiBg9Q6CZmr0C3FRwVPYkOiVeCI_RNJ4mevcLhMmrWFW6ETfseKHm6Dg ckaaWgk6X8B3ncff5QcIN_GKb4v52TGXeydyY7j9SKZnrCIbnPMQ1O4x3eisvPEgPux7Q.8cQ.x5 IJngxjU27Ia3kNu0eyvry1viNG5RCwx44Gby8ffA5SkOWQZFJPqtGUr5Xdu7YixrRnduoVlx7Xrn VEODPzrutQjr6pHig3g.HxFpIhs_Jx0rSshzPQZRZhYF5FvjOXu0B35w1MFnelmjyBATf2EapErC e.lN2TKZ1td1Ph2dev0GPvHpbrzE0xPuIFJqLkXSTwmwpiF7WS2N3UCasL8HiHmJR8a7xJa9NCOh SdhHv5CLpLQfrEU59D7te0hH887_5uSh8PdH5HKAdQLw49iaJ7OhHVd.OSlTii.a3qhNu_EOhwFJ Dt4p0LFmHdI5S2bnCL_DZhV.szlo1v3u30JHwIi9RJj0EOoKAgGmBwl4aPryrpBLi.bqfiEBHCW5 8_JRAs0anA.sEz_RbqlsYWRV3hM8RMDGLDrM0JHzAQCAbrryA.bRG3sZgdhGSMWzc8JCJhpqJFK0 pUyW1CckWx15nJSURbYvjsJQ5j_W_ZxoEBy7WFbBSAb758Hl4qmaIdT41geiXvRVAHr6bfoX39iU hWygW6piKCrXuT5ODQbHMWoHhrtEswIuauerF42DRl4PVnpzH2IQ2EHUrxPKYAyIl.cX6cBVap3q 6YOqkdfqOb8hOD7x44ekJfYv.oCDfxzm2aXygQ0EWJ6nseKxrVpqdU3W0KxDlZ5_Yv6YBSJbwO4j cJVZp9BpNEZGJc37.VkwsZLJfVB87rpw1pt91OVg1xOHEuU4vznGh2yAGdWaQLqT_tTg2NLCB6tX TxI4oWi43WaQOgFJNXPk.vFfSdR29FoAVE.dcmcwrloLbPQTkyBYp7UK08QgW6XnKEN67uQR1WXz DbI08cK5PnB3yGqgfhbTk17d6z5b_PjDkboaLJZk3HTXiZbUUxJ5Dea2BJWMAGkQIThm36.3LVOR u491N3_Y5db0TXLbZ8PttD2nLX8sANZavqnhNa_62Aj34InItGc2H6U79f0GO8MjQZQl.AZOrB1. oFqN3rAqENxc12rFE0AREjB02OemwMGissi.V1JtSM_jfXFIBrXGJFCJrW0fawcxQtT1gj.as8_u 7E02ENAEIvNK1vDKW4bxFc.yOBvk0r.AxI5nwOHLzqJqyWjPyaCmwrFtPfgsUY9h8RZ9htwlLFD8 TiiQRaOaiUZnomuvMt.bdXAAS1aOE.E6395BnSGOSTCyS46HwBdugBplJrrsfs9A0GLJilbW.O0n AkHjjD0j5EXiRbDUQ3Fh3npBmnYeCuzRAnGcJ9G4hZH0vxHzb4DLLR6M1iXw29taYecM0cFqE4As CKgf2qn9kG2sCGIPMAhhVX2QdzgZ3negfLoE6OYsyy1XUyiAjrtiLmtzWMVnVrUQ2LDN.Tt66owi gho8abf4xvJd4i5hE_oVs9whp4N2u2bPHqSta0Qu7iCeZUAsxliSFKtAnOqecQW7eqEh2_N9lNSI hHNL50p3EQUiOqeFWuHyENRkKxelQSahXgrE10RB0nSmojRvXiQFdhzcM7lLnowYmUawbL0OMFkN prJ538Pyus9pHxr0lxPhxHcSGN6Fx4rS9569sSy83V4FNRrngVdS5Slt4OsaN_4g4PTMSWpjgBgB .5kuCOtU3tkJAukJBk_xA8Yr2o_slzJYgXujqvJw.M4.JR85e3u9XbcWPsz4xKWpTueZj00RdNGO zcL0uTEEDA11n2DXm2RUM1U0ewDer4nCX3QtteNS7EXzfdC14WE4nsN7jXzs1QR5_9faDnR_NWDo z82qgrB49GR4WVq1SGbzk2A9nbUsu8pwpqqBL8OjgAW34cTzCSb53eLYSDkXU3F7.ys1zFG2NyrE yGw-- X-Sonic-MF: X-Sonic-ID: 1252b83e-55ec-4093-a7b4-1de3378dd4ff Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 23 Dec 2025 16:04:14 +0000 Received: by hermes--production-gq1-54bf57fc64-fqp47 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d34683351e8680442c76bf957eede111; Tue, 23 Dec 2025 16:04:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: pkgbase and customised builds via ${SRC}/release/release.sh From: Mark Millard In-Reply-To: <1c123424dfcd7f2091ba5109acff2b6d@riseup.net> Date: Tue, 23 Dec 2025 08:04:00 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <1c123424dfcd7f2091ba5109acff2b6d@riseup.net> To: Alastair Hogge X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dbKZV6Kxmz3Kgr On Dec 23, 2025, at 01:50, Alastair Hogge wrote: > On 2025-12-23 12:22, Mark Millard wrote: >> Alastair Hogge wrote on >> Date: Tue, 23 Dec 2025 02:54:09 UTC : >>=20 >> My notes here are limited in their coverage. I've >> not done the type of thing you are trying to do. >>=20 >>> For years, I have been using one host to build all customised USB >>> images, and tarballs for all other hosts at home. This is reached = via >>> custom make, and src.conf files, which are codified in a custom >>> release.conf. My custom release.conf redefines load_chroot_env() to >>> setup the environment with ${SRC}, ${PORTS}, and pkg related files. >>>=20 >>> On 16-CURRENT (2-3 weeks behind) I am able to use >>> ${SRC}/release/release.sh sans customisation, however, when I start = to >>> introduce customisations, the build never succeeds. At the moment, = the >>> build fails at: >>>=20 >>> make[5]: stopped making "create-kernel-packages" in /usr/src >>> make[5]: stopped making "create-world-packages" in /usr/src >>> make[5]: stopped making "create-world-packages" in /usr/src >>> make[4]: stopped making "real-packages" in /usr/src >>> make[5]: stopped making "create-kernel-packages" in /usr/src >>> make[4]: stopped making "real-packages" in /usr/src >>> make[4]: stopped making "real-packages" in /usr/src >>> make[3]: stopped making "real-packages" in /usr/src >>> make[2]: stopped making "packages" in /usr/src >>> make[2]: stopped making "packages" in /usr/src >>> make[1]: stopped making "packages" in /usr/src >>> make[1]: stopped making "packages" in /usr/src >>> make: stopped making "release" in /usr/src/release >>> make: stopped making "release" in /usr/src/release >>> pkg: Unable to open plist file: >>> = /usr/obj/usr/src/amd64.amd64/kernelstage/kernel/kernel.FAFNIR-dbg.plist >>>=20 >>> I have no debug enabled options, and am not interested in debug = builds. >>=20 >> pkgbase has been including debug symbol information >> even for non-debug builds. But they go in separate >> .pkg files that do not have to be installed. The >> bias seems to be to allow somewhat readable backtraces >> for failures without having to rebuild, just having >> chosen to have the information present by installing >> it. >=20 > I am all for it, right now I think I need a way to disable it. My guess is that pkgbase does not allow avoiding the debug symbol .pkg files' production/inclusion. The choice is likely at installation time only for if the debug symbols are installed. >> (I do not know if dist tarballs now do similarly for >> non-debug builds.) >>=20 >> Just having debug symbol information for backtrace >> or the like to use need not be considered a >> debug-build: no enabling of adding internal checking >> for problems, for example. >>=20 >>> In the past, when I needed debug features, I would edit the kernel >>> config, and src.conf files, and start the release build process from >>> there; I do not know how to parametrise debug build options. >>=20 >> Of course, you may not want even backtrace information. >>=20 >>> What is the method for using release.sh to custom build a pkgbase, = that >>> also supports tarballs, and install images? >>=20 >> pkgbase and dist tarballs are mutually exclusive ways >> of doing an install. pkgbase does not have to be >> involved at all for 15.* , for example. (pkgbase has >> its own way of dealing with doing updates as well.) >>=20 >> Related to such, root/release/Makefile reports: >>=20 >> # Variables affecting the build process: >> . . . >> # NODISTSETS: if set, do not include dist sets or MANIFEST >> # NOPKGBASE: if set, include dist tarballs rather than pkgbase = packages in >> # disc1 and dvd1 installation media and build VM/cloud = images using >> # make installkernel installworld. >> . . . >=20 > Whether it is a generic, or custom build, using ${NOPKGBASE} always > results in a pkg failure: > -------------------------------------------------------------- >>>> Install kernel(s) GENERIC completed in 6 seconds, ncpu: 64, make = -j32 > -------------------------------------------------------------- > [...] > --- disc1 --- > env INSTALL_AS_USER=3Dyes ASSUME_ALWAYS_YES=3Dyes pkg -o = METALOG=3DMETALOG -o > ABI=3D -r disc1 -o REPOS_DIR=3D/usr/src/release/pkg_repos install -f = pkg Its having set ABI empty . . . > Installing pkg-2.5.0... > Extracting pkg-2.5.0: .......... done > pkg: Unknown OS '' in ABI string the above complaint about would not be surprising at this point. ABI strings look like: FreeBSD:16:amd64 FreeBSD:15:aarch64 The FreeBSD part is the OS part of it. The 16 vs. 15 is the version part of it. The amd64 vs. aarch64 part is the architecture part of it. Not that I know why ABI is set empty as shown above. > pkg: Cannot parse configuration file! > *** [disc1] Error code 1 >=20 > make: stopped making "release" in /usr/src/release >=20 > Or, >=20 > FreeBSD-base repository update completed. 269 packages processed > All repositories are up to date. > pkg: Setting ABI requires setting OSVERSION, guessing the OSVERSION = as: > 1600000 That suggests that you are using main [so: 16]. In case that is true . . . I'll note that official pkgbase builds for main have a non-debug kernel prebuilt with its own /pkg file, that can be installed and ends up named: /boot/kernel.GENERIC-NODEBUG/ (This is the first type of official non-debug build of the kernel for main that I know of.) By contrast, for main [so: 16] /boot/kernel/ is the debug version of the kernel. (Those names are specific to main.) There are also for main what can be installed that end up as: /boot/kernel.GENERIC-MMCCAM/ /boot/kernel.MINIMAL/ However the official pkgbase build of main's world is a debug build that does validation activity. There is no pre-made non-debug alternate for that for main. In general, you can build and install your own kernels under your own names and have such booted instead of the official ones. Reusing official names with non-official content could lead to confusions when getting help --or at least require remembering to document the context explicitly. I'll also note that /usr/src/ and /usr/src/sys/ (if installed via pkgbase) do not contain git repositories. The two have separate .pkg files in pkgbase. The /usr/src/ and /usr/src/sys/ combination for main or a stable/* need not be an exact match to a single git commit hash's content last I knew: the two parts were generated at distinct times and commits can occur between. > /usr/libexec/flua: /usr/src/release/scripts/pkgbase-stage.lua:47: > assertion failed! That line is: assert(components["kernel"]) > stack traceback: > =E2=96=B8 [C]: in function 'assert' > =E2=96=B8 /usr/src/release/scripts/pkgbase-stage.lua:47: in = upvalue > 'select_packages' > =E2=96=B8 /usr/src/release/scripts/pkgbase-stage.lua:101: in = local 'main' > =E2=96=B8 /usr/src/release/scripts/pkgbase-stage.lua:107: in = main chunk > =E2=96=B8 [C]: in ? > *** [disc1] Error code 1 >=20 > make: stopped making "release" in /usr/src/release > --- bootonly --- > --- installconfig_subdir_share --- > --- installconfig_subdir_share/timedef --- >=20 > make[4]: stopped making "installconfig" in /usr/src/share >=20 > make[3]: stopped making "installconfig" in /usr/src >=20 > make[2]: stopped making "distribution" in /usr/src >=20 > make[1]: stopped making "installworld installkernel distribution" in > /usr/src > *** [bootonly] Error code 2 >=20 > make: stopped making "release" in /usr/src/release > make: 2 errors >=20 > make: stopped making "release" in /usr/src/release >=20 >> As stands, the above indicates that to get dist >> tarballs you turn off the generation of pkgbase >> files from the buildworld results: it does one >> or the other way, but not both in one run, for >> disc1 and dvd1. pkgbase generation does not have >> to be involved at all for those. >>=20 >> (You were not explicit about dist sets or their >> MANIFEST but I listed the line for that as well.) >>=20 >> I'm not sure if you might only want dist tarballs >> and not need pkgbase at all. pkgbase does not >> have to be involved at all until 16.0-STABLE . >=20 > I want to move to pkgbase over dists, however, it seems I can not = manage > either yet. =3D=3D=3D Mark Millard marklmi at yahoo.com