Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Aug 2023 18:08:06 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        bob prohaska <fbsd@www.zefox.net>
Cc:        FreeBSD Mailing List <freebsd-ports@freebsd.org>
Subject:   Re: Bmake bad variable name
Message-ID:  <94FBA6B3-EA84-4B96-A87A-0A04C3E6EFE0@yahoo.com>
In-Reply-To: <ZO/chSZgkn1SUXbp@www.zefox.net>
References:  <9B530FC9-ED6B-4B75-A731-D8F7D7586A51.ref@yahoo.com> <9B530FC9-ED6B-4B75-A731-D8F7D7586A51@yahoo.com> <ZO5EKKF9HVxhnCB3@www.zefox.net> <040CECBC-8A04-4049-91A7-0C1522000F5A@yahoo.com> <ZO/chSZgkn1SUXbp@www.zefox.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 30, 2023, at 17:19, bob prohaska <fbsd@www.zefox.net> 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.

Good.

> On Tue, Aug 29, 2023 at 10:50:40PM -0700, Mark Millard wrote:
>> My notes are . . .
>>=20
>> In:
>>=20
>> QUOTE
>> /usr/src contains a recent=20
>> buildworld/builkderel. /usr/ports contains a recently-updated ports =
tree.=20
>> END QUOTE
>>=20
>> 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.)
>>=20
>> So the wording in http://www.zefox.net/~fbsd/poudriere_on_rpi4 =
presumes
>> some things already done:
>>=20
>> A) cd /usr/src; git pull (or git fetch && git merge --ff-only).
>>=20
>> B) cd /usr/src ; make buildworld buildkernel
>>=20
>> (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.)
>>=20
>> 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=3D/usr/local/poudriere/poudriere-system
>>=20
>> D) cd /usr/src; \
>>   make ???? DESTDIR=3D/usr/local/poudriere/poudriere-system =
DB_FROM_SRC=3D1
>>   . . .
>>=20
>> (I do not show all the make commands.)
>=20
> 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.
>>=20
>> /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).
>=20
>=20
>> So far as I can see, the "cd /usr/local/poudriere" neither helps
>> nor hurts and is not required.
>=20
> 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.=20

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
levels.)

>> In:
>>=20
>> QUOTE
>> # poudriere jail -c -j main -m null -M =
/usr/local/poudriere/poudriere-system -S /usr/src -v 14.0-CURRENT
>> END QUOTE
>>=20
>> 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.)
>>=20
>> I've no evidence of my own how well the *_TIME* figures are working
>> for you. I presume that they are.
>=20
> 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.=20

Also: NOHANG_TIME

>> 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.
>>=20
> I've removed the reference to testport, adding an example of=20
> my usual practice.=20

http://www.zefox.net/~fbsd/poudriere_on_rpi4 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:
>>=20
>> QUOTE
>> After world/kernel update repeat steps in /usr/src.
>> END QUOTE
>>=20
>> 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.
>>=20
>=20
> AIUI, after an OS build/install cycle the material in=20
> /usr/local/poudriere/system must be updated to match the=20
> host system. That's basically a repeat of the setup=20
> process apart from  jail creation, is it not?=20

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

(Not gone in what I see.)

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

(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 http://www.zefox.net/~fbsd/poudriere_on_rpi4 .

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.

>> QUOTE
>> and /usr/local/etc/pkg/repos/FreeBSD.conf containing
>> FreeBSD: {
>>        enabled: no
>> }
>> END QUOTE
>=20
> 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.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?94FBA6B3-EA84-4B96-A87A-0A04C3E6EFE0>