From nobody Tue Dec 23 16:34:51 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 4dbLGD1y4Gz6Lhkb for ; Tue, 23 Dec 2025 16:35:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-19.consmr.mail.gq1.yahoo.com (sonic313-19.consmr.mail.gq1.yahoo.com [98.137.65.82]) (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 4dbLGC3CxVz3QTV for ; Tue, 23 Dec 2025 16:35:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=rbdrxQzZ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766507708; bh=LZiRhv/8fgDRgQcM08IyC4iEyT1m6lImjo+JWmmf8p4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=rbdrxQzZenbTB0sm1EhgBbg22JMbNBsK2vb+HVUvKD79a8gh1pGvhsa1qxja9uv7GMlaC2Azwfe9vaKhKrrU7aQnetxPq6puoEqtJSGi1Qv7rLSseuM3PyDJYDLZ7476FNStWXkFugLiMNGVuBRjO1o1YPMsHeQowB25mo09IvRnxZVr5vN0Qzudi4tMmAgD5hPHPH59CVPC1niwLP8FQoAgyoF3WtpDTioEI8hZDpxzJHt3G8Uzv0L1BloOhk9F47jnZKqs4+zcYBOiJw5AE25qFmlu1mcJZMJR+JMbCD2yrHv2KrXZtXzoVv4xgPRtwlEEsEErXf/fS2hlrTL4Og== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1766507708; bh=zqKrRw3F5/uyD115eqVlCIVu1M66cx6KV/LfdvFQzRX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=X7iYtGMTTvGmnKsPZTvpK+qSg5ZOdS4f182+WkwwijLEt/mtUQ9GuUr6JNyfOJyrrICUCV5Ua0hREE1OvIG1ozRDZRjt+aY3JT4NmcJP3nU1PjoMGt2uJ9BLO91YnbwJnQ8d/Bct2hjbX34Kb7W1xwwrzqUT9NIU78jnih2dfUoNx6WuxCJurg0wBGd50D0zoTDxK3sjwj/dkE9AWTV/wGwsoQi8u90iwGwK8PCPo7TP/OhaeCC6PagkHFyz4qvuVziflnuIM6CNabOuaHOtoX3zaZxzGZkyQ4rTdqR8U1+YIKJfcjewVKBlyRXyCY34DJlDt/Sk7ic52QE9E5CHWw== X-YMail-OSG: 97XcLh8VM1ngx2sUUKJc8c50RYL1OTaAijqy5ph4j82cnfk9JuD4iKYNKid1Xyd 94jv62JRvPutePZHWxoELla87GwkuKV.TeyADbQi4Qkmcm4r0Va6fqRp2L21RKqBNtJOUS3v8Kot pjk8UcNVd.3VT8FFlDrsx13Bta2o3jN664ssJJKB31nVxvzZ3WjPDBW0be441xF6D614FC7hgS5b upSgm2sLu8Ca7tdX_sTyakw.fquWGDXAQZLwBI5CKLpZ.fb1EZgPsp9Uo1owU63brndpS0XR3AML eWBMH6znTdbdz_5uez_jSEctPcbqsxlraavWX1ofH_29_9N75poWp1KlctPZ2UlaGiX8OSEcek7m 7tAtpvDydcVaUnITpuDNRg7FJf2QLZz7PRFvh4StkiV1qkkkYExXB1e12ogYMnbkU0VAfS3ENG5c VssoGkvCNiyMjQky7J2P9UfwqJrKGVBrXg62WR0LVgMpOysnBGDrmKoNeKEVOHECNU8AJp9orJ99 2OOZ_YORQFN0AtP71bgOAthg.hgJT8xB158luq1aQCoqkOzp2NgzOcdusb00h6HPTjJ0wsJuXI8e EMpGuEAs7pqjIhWAijpc2wfteWwi9HnMNt8dYTuOFQ4LXC..sd5h6iKtXaS9BSEeMsfuJLmbG4Ib Z7v779Xc_8D5pNqqPgaHaJEuH7J3wisrW_mt13zpIUfHHysIpqzeLVS8oJNmjyXqbJpORlJdGSft xw5E5zrFFF.gtkhaQ6m5MrSXLHtyEClIzRN1gnsaVcrQT6IoeR3Gva4kbUiHnGWTjWSSNJnAcHh_ dRGSiJ3z15s7Al2sb9REx1JKxkIgKauNoQWgcX9V8aGPeaZT2aw4AzBqRKEUYax30yqR1F1U2oEv HiskYA7k9nkk1c7yBt.GdTUydm5uPKGHMeo7gdBuuq41a7t9tNZzLqrCTTggEOQ99mOv2YaHxfxI 9v.67.cdMAqz5yUlN.Ki4RCH229iHI0CesrVjl11ASuj3AjWhqMJJbzu11Lff8wboQx2AKnb9I9d 9n4tO8NYvPi7vhARoQ8qcW0y9NN9QN1X27fRILAW9TppwTecC2gDq_UOEtuoLVZeU2WrzHKZrnG2 WpQOmXBqTQ2p57K9VBZ6MvuW9nupIjxAcms4XO1_GYK0MOJfUt7R4xy.a1mvxZKQj_bup2OyK.bQ w8JhcJm1iWoQCY0rCuOZMSEIHAVa1JDnWAOK_aIcOgCxTCTj6ri89wKWHXZezXAS1dcXypI39ipu o1zXgTeCTyTqFrwbpMKcO9D3y7xAHwQmPOwdb7F8J9JcwOKZ6tHqkjSEKW2rNVDhf.UZGKmO17oj dacMsg3Yt_pbx6P1Ta0Sl9JP1VTtglFLVH9xu7YKYyW.69Ka3h_OUMICfuPF4e5C5bvlObeY74P2 XLkDX2dUKzHZVedRRPQRszW9glCt72aRyfxYCOXvLHsqfb89n1vguz04Tq9Vhdt5nFcjwr_7ZMHq iIs6Q.UAy2fTs4W9Cm2ELbutDd4sSFpKoBz88rpxl.q9nxNN57JVtnFn4YM9p_ZKhpoSQUmf6sxi GQM3IFPl2H7ogVWX84uca5dkNDCql8yip5Jmc1CQqKq1YYO7TGJ8PGKJO9XFoZhFiOf.f_tUOpXK oaeKPZsOkERqt2yrd4mHAyYRELjCARmt6zlSOGvycnMWWvWnFLCHdb33YzmzV2dG_bMkXQH1ohR4 Jo5tQ5u6BhwRNB.TVNrg94NYYS5fK45t9nW_oRNlCz9KhoON..j2QUkZwJcJJvIc2J3siMqwCMGB .n56YxCuF4NDXi5H2iVXEkkX_IcRM2iBa7f9FO_.qrOUieysxZwlGAVFnJKvcdpocR0E4PGkWdPc n9j4zOWZRBr9IUUDcXoEOaJwn.pKDjbox80Tzkz9MGozry_f797aLFRgyYinnxHRsWxdxCEga.8j rnlH16LnkSXuvQpkgtbnHRDS_pJ9M4CXMk2Xbn9th7KDtwxLl.jvQwUoxkuzgJjx2Qc9ZVxqkKdf L7xQ6VAqKwyzwWvcMv8JCNVc62JF.PnWNvnmDmCgy_cXFiRJrsJ1IA4mYdhAyvWU9MTQjZWHeQ25 rjmo4zvfUtEVvMxqGaJ_k7tGvlxUnSxAha8GP0gB_2vTrNCOet0om1e6FMF8GZxRenYGd3J6ivPQ H9d4hRAqBXwQNipk0fcxrwUOPN475pqC1PG7taO8aWh4RX0G1HQ4G5oTQuxki1YGtDSzQnjaNqzE u05Msnb.zY1yF4_mDuS9M1areHpJAvlWecGaa.rJu6qKVezgQeBmKGcF6kNaF77u3qf0vnb5JZT5 4kw-- X-Sonic-MF: X-Sonic-ID: 49600287-2093-4ba8-bdc9-7dcee51b430b Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 23 Dec 2025 16:35:08 +0000 Received: by hermes--production-gq1-54bf57fc64-7shwr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 194a14d90870ea8c907547baa3727546; Tue, 23 Dec 2025 16:35:02 +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: Date: Tue, 23 Dec 2025 08:34:51 -0800 Cc: FreeBSD Current , Lexi Winter 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 [-2.98 / 15.00]; SUBJECT_HAS_CURRENCY(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; NEURAL_HAM_SHORT(-0.99)[-0.988]; 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_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; BLOCKLISTDE_FAIL(0.00)[98.137.65.82:server fail]; MID_RHS_MATCH_FROM(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.82:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.82:from] X-Rspamd-Queue-Id: 4dbLGC3CxVz3QTV On Dec 23, 2025, at 08:04, Mark Millard wrote: > On Dec 23, 2025, at 01:50, Alastair Hogge wrote: >=20 >> 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. >=20 > 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. >=20 >>> (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 >=20 > Its having set ABI empty . . . >=20 >> Installing pkg-2.5.0... >> Extracting pkg-2.5.0: .......... done >> pkg: Unknown OS '' in ABI string >=20 > the above complaint about would not be surprising at this > point. >=20 > ABI strings look like: >=20 > FreeBSD:16:amd64 > FreeBSD:15:aarch64 >=20 > 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. >=20 > Not that I know why ABI is set empty as shown > above. >=20 >> 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 >=20 > That suggests that you are using main [so: 16]. > In case that is true . . . >=20 > 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: .pkg (not /pkg). > /boot/kernel.GENERIC-NODEBUG/ >=20 > (This is the first type of official non-debug > build of the kernel for main that I know of.) My wording is likely confusing for not making an explicit distinction between pkgbase in general and the subset of that the release procedures deal with releasing. I was not trying to claim that attempting a release build of main would provide more than /boot/kernel/ (GENERIC), even if the pkgbase activity internally produced a GENERIC-NODEBUG as well. I'm not even sure that a release build of main is something that the release procedures are currently intended to be able to do. > By contrast, for main [so: 16] >=20 > /boot/kernel/ >=20 > 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: >=20 > /boot/kernel.GENERIC-MMCCAM/ > /boot/kernel.MINIMAL/ >=20 > 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. The above might mean that you want more world tailoring of main if you are building 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. >=20 > 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. >=20 >> /usr/libexec/flua: /usr/src/release/scripts/pkgbase-stage.lua:47: >> assertion failed! >=20 > That line is: assert(components["kernel"]) >=20 >> 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