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 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.
. . .
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 .
===
Mark Millard
marklmi at yahoo.com
