Re: Bmake bad variable name

From: Mark Millard <>
Date: Thu, 31 Aug 2023 01:08:06 UTC
On Aug 30, 2023, at 17:19, bob prohaska <> wrote:

> First off, the problem seems to have gone away after a second
> cycle of updating world, kernel and poudriere. No idea why.
> The Pi4 is building www/chromium now, it'll take about four
> days to finish.


> On Tue, Aug 29, 2023 at 10:50:40PM -0700, Mark Millard wrote:
>> My notes are . . .
>> In:
>> /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:
>>   DESTDIR=/usr/local/poudriere/poudriere-system
>> D) cd /usr/src; \
>>   make ???? DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1
>>   . . .
>> (I do not show all the make commands.)
> The idea was to collect a minimal set of instructions to let poudriere
> replace use of make in /usr/ports on a self-hosting computer. Sort of
> like how to drive thumbtacks with a hydraulic excavator 8-)

Because I could not tell about stages that were not explicit,
I had some notes about context that likely would be overkill
for notes to yourself.

>> 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.
> At the time I thought the poudriere commands would write to the
> working directory some output from their execution. Apparently
> they don't, leaving me puzzled as to how and where the results of
> poudriere ports and poudriere jail are recorded. 

Do some "df -m" commands while poudriere bulk has some
builder(s) running. You will see where things are
temporarily during the running build(s) each time.

/usr/local/poudriere/data/packages/main-default/ ends up
as the long term storage area for packages for your
"main" jail builds of packages --at least by default.

/usr/local/poudriere/data/logs/bulk/main-default/ ends
up as the long term storage area for the logs for your
"main" jail builds of packages --at least by default.

If you have thigns configured to save build failures,
/usr/local/poudriere/data/packages/main-default/ ends
up as the long term storage area for the saved failures
--at least by default.

(I'm not showing the detailed substruture below those

>> In:
>> # 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.
> If you're referring to the MAX_...TIMEs, I've added the actual times used
> on the running system. Not optimal, but what's worked. 


>> 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've removed the reference to testport, adding an example of 
> my usual practice. looks unchanged
just now, not just for this but for any changes. May be some
other copy was changed or the old content is cached someplace?

>> 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.
> AIUI, after an OS build/install cycle the material in 
> /usr/local/poudriere/system must be updated to match the 
> host system. That's basically a repeat of the setup 
> process apart from  jail creation, is it not? 

But that buildworld buildkernel activity and rebooting to
the new installed system and updating
/usr/local/poudriere/poudriere-system should be done before
even the "poudriere jail -c". The quoted material may be
just out of order?

>> In:
>> 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.
> Even I don't remember what I was trying to get at. Gone.

(Not gone in what I see.)

>> 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?
> Again, I'm confused too. It's gone. 

(Not gone in what I see.)

>> The "FreeBSD" in the below is intended funny:

Late night operator error: "indented oddly" would
be what I was intending.

In what I saw, "FreeBSD:" left hand side was aligned
with the "enabled:" left hand side, both being indented
--or at least that is what showed up in the browser when
I looked at .

Whitespace may not have been well preserved in what I
sent out so the indentation detail might not have looked
the same in my note.

>> and /usr/local/etc/pkg/repos/FreeBSD.conf containing
>> FreeBSD: {
>>        enabled: no
>> }
> I'm a great believer in comic relief, but it certainly
> wasn't intended here. Please explain (yes, I know
> explaining spoils any joke)

No joke. Just an error on my part.

Mark Millard
marklmi at