Re: pkgbase and customised builds via ${SRC}/release/release.sh

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