Re: Bmake bad variable name
- Reply: bob prohaska : "Re: Bmake bad variable name"
- In reply to: bob prohaska : "Re: Bmake bad variable name"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 31 Aug 2023 01:08:06 UTC
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 . . . >> >> In: >> >> QUOTE >> /usr/src contains a recent >> buildworld/builkderel. /usr/ports contains a recently-updated ports tree. >> END QUOTE >> >> 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 http://www.zefox.net/~fbsd/poudriere_on_rpi4 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 levels.) >> In: >> >> QUOTE >> # poudriere jail -c -j main -m null -M /usr/local/poudriere/poudriere-system -S /usr/src -v 14.0-CURRENT >> END QUOTE >> >> 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. 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. >> > I've removed the reference to testport, adding an example of > my usual practice. 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: >> >> QUOTE >> After world/kernel update repeat steps in /usr/src. >> END QUOTE >> >> 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: >> >> 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 > > 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 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 > > 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 yahoo.com