Re: config / NOTES "profile 2" and main -> stable/13 fails universe for me?

From: Bjoern A. Zeeb <>
Date: Mon, 28 Mar 2022 09:26:30 UTC
On 28 Mar 2022, at 2:28, Warner Losh wrote:

> On Sun, Mar 27, 2022, 8:15 PM Kyle Evans <> wrote:
>> On Sun, Mar 27, 2022 at 2:01 PM Bjoern A. Zeeb
>> <> wrote:
>>> Hi,
>>> I am building on a stable/13 machine (updated a few days ago but I 
>>> had
>>> that before in the last months).
>>> I have git clone and am mostly working on main or main-derived
>>> branches.
>>> Once in a while I switch in-place (not a worktree) to a stable 
>>> branch,
>>> e.g., git checkout stable/13 based on freebsd/stable/13 for MFCs.
>>> When I do that and start to build an amd64-only universe my kernel
>>> builds immediately fail with a dubious error message from a 
>>> top-level
>>> Makefile:
>>> # nice make -s -j30 tinderbox TARGETS=amd64 [..]
>>> make[2]: ".../freebsd-src/Makefile" line 731: "Target architecture 
>>> for
>> amd64/conf/LINT unknown.  config(8) likely too old."
>>> I tracked it down to the profile 2 line sys/amd64/conf/NOTES which 
>>> makes
>>> config fail apparently.
>>> When I apply the below change things work flawlessly.
>>> I do not fully understand where the problem comes from, but given I
>>> haven't seen other reports I wonder what it is that I am doing that
>>> makes things go wrong here?
>>> Anyone an idea?
>> Whoops, we ripped 'profile' support out of config(8) so now it can't
>> config older kernels.

Where did that happen?  Oh, I see it in “main” a year ago.  I 
couldn’t see it in stable/13?

>> I think the cheapest/easiest fix would be to
>> just re-add the keyword as a nop so we can still parse it, maybe emit
>> a warning that it's been removed in newer config(8).
> Yea. It would be trivial to do so. But what about the version issue?

config is a bootstrap tool.   So the real problem could be that when I 
switch branches from main to stable/13 it is not rebuilt and so I get 
the version from main which then fails on stable as it no longer knows 
how to handle “profile”?  Or something like this?

I see 1 config binary in two directories in a freebsd13-amd64/ subtree 
in my obj dir (5 days old).  One directory is ${HOST_OBJTOP} so first in 
path for this call in Makefile.   Sadly we don’t have idents ..

Seems to be a build system problem and not a config problem of some 
Note that my builds in this case are not using WITHOUT_CLEAN or similar.

I am trying to figure out how to force a rebuild of the freebsd13-amd64 
obj subtree to see if that really makes the problem go away..