Re: Bmake bad variable name

From: Mark Millard <>
Date: Wed, 30 Aug 2023 05:50:40 UTC
On Aug 29, 2023, at 12:16, bob prohaska <> wrote:

> On Tue, Aug 29, 2023 at 12:41:04AM -0700, Mark Millard wrote:
> [huge snip]
>> One procedure involved might be to run the poudriere command to
>> delete the jail and then the poudriere command to create the
>> jail with -v version also explicitly set correctly:
>> # man poudriere-jail
>> . . .
>>     -v version       Specify the version of FreeBSD to use in the jail.  For
>>                      most methods, and by default if no -m is specified,
>>                      version should in the form of ???12.0-RELEASE???.  If you
>>                      are using -m git, or -m svn, then the version should be
>>                      in the form of Git or SVN branches, which is usually in
>>                      the form of ???stable/9??? or ???main??? for CURRENT from git.
>>                      Other methods only use the version value for display.
>> . . .
>> (The delete does not remove everything so context is preserved
>> across the steps. The jail information kept is rather limited.)
>> Make sure the jail sees the right vintage of FreeBSD source code
>> as well.
> Deleting the old jail and creating a new one seemed to work:
> root@nemesis:/usr/local/poudriere # poudriere jail -d -j main -m null -M /usr/local/poudriere/poudriere-system -S /usr/src -v 14.0-CURRENT
> [00:00:01] Are you sure you want to delete the jail? [y/N] y
> [00:00:05] Removing main jail... done
> [00:00:53] Cleaning main data... done
> Next,
> root@nemesis:/usr/local/poudriere # poudriere jail -c -j main -m null -M /usr/local/poudriere/poudriere-system -S /usr/src -v 15.0-CURRENT
> [00:00:00] Recording filesystem state for clean... done
> [00:00:00] Jail main 15.0-CURRENT arm64.aarch64 is ready to be used
> Alas, the problem remains:
> root@nemesis:/usr/local/poudriere # ./chromiumscript &
> [1] 5879
> root@nemesis:/usr/local/poudriere # bmake: "/usr/ports/Mk/" line 1213: UNAME_r (15.0-CURRENT) and OSVERSION (1400096) do not agree on major version number.
> bmake: "/usr/share/mk/" line 187: Unknown modifier ":Q"
> bmake: "/usr/share/mk/" line 201: Unknown modifier ":Q"
> bmake: Fatal errors encountered -- cannot continue
> eval: bmake:: not found
> export: bmake:: bad variable name
> make: "/usr/ports/Mk/" line 1213: UNAME_r (15.0-CURRENT) and OSVERSION (1400096) do not agree on major version number.
> [00:01:29] Error: Error looking up pre-build ports vars
> Next, I tried removing and re-creating /usr/local/poudriere-system,
> using notes at
> To my surprise, that failed with an error:
> ...
> --- realinstall_subdir_lib/libc/tests/stdio ---
> install -N /usr/src/etc  -s -o root -g wheel -m 555   snprintf_test /usr/local/poudriere/poudriere-system/usr/tests/lib/libc/stdio/snprintf_test
> --- realinstall_subdir_lib/libc/tests/string ---
> (cd /usr/src/lib/libc/tests/string &&  DEPENDFILE=.depend.wcscoll_test  NO_SUBDIR=1 make -f /usr/src/lib/libc/tests/string/Makefile _RECURSING_PROGS=t   PROG=wcscoll_test  install)
> --- realinstall_subdir_lib/libc/tests/stdio ---
> install: snprintf_test: No such file or directory
> *** [_proginstall] Error code 71
> make[8]: stopped in /usr/src/lib/libc/tests/stdio
> --- maninstall ---
> ...
> Make installworld for the host system ran successfully,
> which suggests there is an error in my notes. They were 
> prepared somewhat after the fact, so it wouldn't be a 
> huge surprise if a unique initial step got lost.  
> If you could take a look at the steps listed at
> it would be much appreciated!

My notes are . . .


/usr/src contains a recent 
buildworld/builkderel. /usr/ports contains a recently-updated ports tree. 

I'll note that /usr/src only contains source code normally, not build
materials. A tree under /usr/obj/ normally is where building materials
go. /usr/src/ is associated with git fetch and merge --ff-only (or pull)
as far as its updates go. But that does not do a buildworld or
buildkernel that updates materials that are typically under /usr/obj/
someplace. (I ignore here having to deal with resolving conflicts if
there are local /usr/src/ changes.)

So the wording in presumes
some things already done:

A) cd /usr/src; git pull (or git fetch && git merge --ff-only).

B) cd /usr/src ; make buildworld buildkernel

(I'll not get into variations of the command line details
that may be appropriate for various types of contexts.
Presume the above is incomplete but suggestive.)

C) installkernel installworld to the live system then rebooting
   into the updated system installation. (This wording is only
   suggestive and documented steps should be followed that may
   involve multiple reboots and other steps not mentioned here.)
   Note that (C) does not involve:

D) cd /usr/src; \
   make ???? DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1
   . . .

(I do not show all the make commands.)

Below I use my knowledge that you do poudriere-devel style
port builds. I only cover that limited context.

/usr/ports is, like /usr/src , source code. But from the ports git
repository, other than /usr/ports/distfiles/ which is basically
for materials from elsewhere (from various upstreams).

So far as I can see, the "cd /usr/local/poudriere" neither helps
nor hurts and is not required.


# poudriere jail -c -j main -m null -M /usr/local/poudriere/poudriere-system -S /usr/src -v 14.0-CURRENT

the -v 14.0-CURRENT is over specific over time. "14" is no longer
correct for progressing to 15.0-CURRENT . You might want text that
reminds you to make the appropriate substitution for the time frame
you are using the instructions for. (There are years between these
sorts of updates to main.)

I've no evidence of my own how well the *_TIME* figures are working
for you. I presume that they are.

poudriere "builds" are normally via "bulk" instead of "testport".
testport serves extra/special purposes. Official port->package
builds are via bulk use, for example, not via testport use.

I'm confused over:

After world/kernel update repeat steps in /usr/src.

Is this for handling issues around ports that access kernel internals
and the like? It is unclear what is spanned of buildworld, buildkernel,
installkernel, installworld, distrib-dirs, delete-old, delete-old-libs,
and such. Ultimately, I'm not sure what to say about that quoted text.


Buildworld and buildkernel are best run on a clean source
tree, or with -DWITH_META_MODE on the command line. Old
binaries, even if correct, seem to cause trouble.

there is again the confusion of /usr/src/ (source) vs.
/usr/obj/ ("binaries") types of materials. Do you intend
"clean source tree" to refer to doing something like
"rm -fr /usr/obj/*" in order to force a from-scratch build
(even if WITH_META_MODE is also later specified)? If not,
what does "clean source tree" correspond to?

The "FreeBSD" in the below is intended funny:

and /usr/local/etc/pkg/repos/FreeBSD.conf containing
	FreeBSD: {
        enabled: no

Mark Millard
marklmi at