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

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:

/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:
> ▸       [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