Re: Bmake bad variable name

bob prohaska <fbsd_at_www.zefox.net> wrote on
Date: Tue, 29 Aug 2023 02:23:30 UTC :

> A Pi4 running 
> 
> FreeBSD nemesis.zefox.com 15.0-CURRENT FreeBSD 15.0-CURRENT aarch64 1500000 #79 main-n265053-315ee00fa961: Mon Aug 28 12:30:35 PDT 2023 bob@nemesis.zefox.com:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
> 
> seems to have trouble
> with bmake in poudriere:
> 
> root@nemesis:/usr/local/poudriere # bmake: "/usr/ports/Mk/bsd.port.mk" line 1213: UNAME_r (15.0-CURRENT) and OSVERSION (1400096) do not agree on major version number.
> bmake: "/usr/share/mk/sys.mk" line 187: Unknown modifier ":Q"
> bmake: "/usr/share/mk/sys.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/bsd.port.mk" line 1213: UNAME_r (15.0-CURRENT) and OSVERSION (1400096) do not agree on major version number.
> [00:01:33] Error: Error looking up pre-build ports vars
> 
> The first line seems related to the version number jump from 14 to 15, but the 
> two following appear unrelated.
> 
> Poudriere was executing 
> poudriere bulk -j main www/chromium > chromium.log
> which has been working (apart from source problems)
> without difficulty.

You can not mix and match older aarch64-unknown-freebsd14.0
materials and aarch64-unknown-freebsd15.0 materials in the
poudriere jail. The transition has to be handled cleanly.

The sys/param.h it checked had __FreeBSD_version starting with 14
but uname -r started with 15 : old system source in use. The
change in the major version number for main is a full re-build
context, even building the bootrap compiler/tools. For one the
default triple (such as aarch64-unknown-freebsd15.0) needs to be
different than the prior default (aarch64-unknown-freebsd14.0
here) for general use of the compiler/tools.

I'm not sure what the normal/expected procedure is. It likely
depends on how you handle system builds for poudriere's jail
activity to use. (I do my own builds/local-extra-tree-installs
and have poudriere null mount such. This is likely not the most
common style.) I do not know which style of world handling
you use for the poudriere jail.

(I do know how to get my context working but I likely do
not do the expected style of doing so. I doubt details
are appropriate to other style of handling the world in
the jail. This only happens once every couple/few years.)

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.


As for the other messages, it is common for /usr/share/mk/sys.mk
and the like to assume prior activity did not get errors that
left things empty/undefined. Such errors can lead to additional
error messages from the unexpected substitutions not making an
overall command syntactically correct. (But I've not analyzed
the details for the messages that you got.)


> A quick re-run of git pull in /usr/ports reported up to date,
> is there something else to try? Poudriere reports status of
> stopped; crashed on the web page.



===
Mark Millard
marklmi at yahoo.com