On Dec 23, 2025, at 08:04, Mark Millard <[email protected]> wrote: > On Dec 23, 2025, at 01:50, Alastair Hogge <[email protected]> wrote: > >> On 2025-12-23 12:22, Mark Millard wrote: >>> Alastair Hogge <agh_at_riseup.net> wrote on >>> Date: Tue, 23 Dec 2025 02:54:09 UTC : >>> >>> My notes here are limited in their coverage. I've >>> not done the type of thing you are trying to do. >>> >>>> 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. >>>> >>>> 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: >>>> >>>> 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 >>>> >>>> I have no debug enabled options, and am not interested in debug builds. >>> >>> 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. >> >> 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.) >>> >>> 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. >>> >>>> 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. >>> >>> Of course, you may not want even backtrace information. >>> >>>> What is the method for using release.sh to custom build a pkgbase, that >>>> also supports tarballs, and install images? >>> >>> 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.) >>> >>> Related to such, root/release/Makefile reports: >>> >>> # 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. >>> . . . >> >> 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=yes ASSUME_ALWAYS_YES=yes pkg -o METALOG=METALOG -o >> ABI= -r disc1 -o REPOS_DIR=/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 >> >> make: stopped making "release" in /usr/src/release >> >> Or, >> >> 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:
.pkg (not /pkg). > /boot/kernel.GENERIC-NODEBUG/ > > (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] > > /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. 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. > > 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: >> ▸ [C]: in function 'assert' >> ▸ /usr/src/release/scripts/pkgbase-stage.lua:47: in upvalue >> 'select_packages' >> ▸ /usr/src/release/scripts/pkgbase-stage.lua:101: in local 'main' >> ▸ /usr/src/release/scripts/pkgbase-stage.lua:107: in main chunk >> ▸ [C]: in ? >> *** [disc1] Error code 1 >> >> make: stopped making "release" in /usr/src/release >> --- bootonly --- >> --- installconfig_subdir_share --- >> --- installconfig_subdir_share/timedef --- >> >> make[4]: stopped making "installconfig" in /usr/src/share >> >> make[3]: stopped making "installconfig" in /usr/src >> >> make[2]: stopped making "distribution" in /usr/src >> >> make[1]: stopped making "installworld installkernel distribution" in >> /usr/src >> *** [bootonly] Error code 2 >> >> make: stopped making "release" in /usr/src/release >> make: 2 errors >> >> make: stopped making "release" in /usr/src/release >> >>> 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. >>> >>> (You were not explicit about dist sets or their >>> MANIFEST but I listed the line for that as well.) >>> >>> 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 . >> >> I want to move to pkgbase over dists, however, it seems I can not manage >> either yet. === Mark Millard marklmi at yahoo.com
