Date: Thu, 31 Aug 2023 12:44:16 -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: <26A4D82B-B09A-43F1-B485-E80D7528956E@yahoo.com> In-Reply-To: <BABF15FE-9150-4E3F-97D7-A32B3235DC5C@yahoo.com> 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> <94FBA6B3-EA84-4B96-A87A-0A04C3E6EFE0@yahoo.com> <ZPAUAlS9dDGdjtnl@www.zefox.net> <BABF15FE-9150-4E3F-97D7-A32B3235DC5C@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Composed last night but accidentally not sent.] This is about some of the new text in: http://www.zefox.net/~fbsd/poudriere_on_rpi4 I originally took the "To set up poudriere, use" and "Next, construct one jail," as per-version upgrade activity, not notes about starting from scratch the first time. I understand now after also reading the later text that has a variation of some of the earlier material. Interpreting my prior message of notes for what I was (incorrectly) thinking requires deliberate use of my misinterpretation as context. Sorry. But one things that contributed to the misinterpretation was: QUOTE # make -DBATCH_DELETE_OLD_FILES delete-old = DESTDIR=3D/usr/local/poudriere/poudriere-system DB_FROM_SRC=3D1 # make -DBATCH_DELETE_OLD_FILES delete-old-libs = DESTDIR=3D/usr/local/poudriere/poudriere-system DB_FROM_SRC=3D1 END QUOTE Those 2 commands suggest that /usr/local/poudriere/poudriere-system may have had a prior build in it to clean out old material from. The line "cd /usr/local/poudriere" is still there. For some reason you have: # cd /usr/src # make installkernel DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 # make installworld DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 vs. (different order) make -j4 installworld DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 > poudup.log && \ make -j4 installkernel DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 >> poudup.log && \ When not updating the live boot media's live kernel the ordering does not matter. But it does for updating the running system's materials: Unless one is tracking detailed dependencies of world on new kernel ABI changes, the order of the installs for the booted system (self updating) should be: installkernel reboot so the updated kernel ABI is available for the new world to use etcupdate -p [so that installworld has access to potential new things] installworld etcupdate -B make delete-old reboot yet again so that no old world code is still executing SOMETIME LATER when the old libraries are no longer used by any installed ports: make delete-old-libs Note: the -B in "etcupdate -B" is only appropriate if the buildworld for the source code update was done previously: -B leads to using data from the build instead of having to regenerate that data for its own use. The other order (installworld installkernel) can lead to executing world programs that depend on the new ABI when it is not available yet: after installworld new process creations execute the new world code is executed even if you do not reboot. (dynamic loading also picks up the new materials.) In other words: QUOTE installscript contains: make -j4 installworld > installworld.log && make -j4 installkernel = KERNCONF=3DGENERIC > installkernel.log && etcupdate > etcupdate.log && = ./poudriereupscript END QUOTE seems odd for its installkernel vs. installworld ordering, as well as its etcupdate details. (The build order is buildworld then buildkernel instead: buildworld puts some things in place for buildkernel to use.) A transition from 15.0-CURRENT to 15.0-ALPHA1 also needs a jail update. But it would produce a different message than the error message that started this investigation. Going from 14 -> 15 does have some activity that is a unique to that renumbering but that activity is not the only reason that the jail update is appropriate for a change in the text. Other messages are possible as well. (It can simplifying things to wait and do the likes of 14.0-CURRENT -> 15.0-CURRENT without ever going through a 14.0-ALPHA* stage. ALPHA* changes the version text weekly.) This contributes to: QUOTE Occasionally FreeBSD's version will increment so the jail has to be = updated. I ended up deleting and re-creating the jail with the new -v value. END QUOTE being incomplete in its coverage (unless CURRENT -> ALPHA1 or the like are valid "increment"s). The "FreeBSD:" in /usr/local/etc/pkg/repos/FreeBSD.conf has a tab in front. But the "enabled: no" has spaces. I'll note that later poudriereupscript material does not suggest to ever have a delete-old-libs executed. Leaving old libaries around can lead to some being used when they should not be during port -> package building. But delete-old-libs may need to be later, only after the old library referencing ports have all been rebuilt into new packages, unless one first does something like: # poudriere pkgclean -jmain -A so there is nothing around that might try to use the older library materials. This is not usually an issue but when certain system libraries are updated to no longer be backwards compatible for older port builds to use (ABI/API changes), one hss to be sure that every use gets replaced with new build materials. I'll note that for main, for example, this can happen without a ??.?-???? textual change at the time. For: QUOTE After world/kernel update one must repeat the steps in /usr/src. It's convenient to place in /usr/src a few small scripts with the desired commands: END QUOTE Which steps? For example, doing another git pull (or fetch then merge --ff-only sequence) would not be appropriate. I expect that you mean just the steps that involve: make . . . DESTDIR=3D/usr/local/poudriere/poudriere-system . . . QUOTE For example, apache24script contains poudriere bulk -j main www/apache24 > apache24.log Redirecting output and running the command in the background ensures the job won't stop if the controlling terminal gets disconnected. END QUOTE If I understand right, a SIGHUP signal might still be possible for the controlling terminal ending up disconnected, even for the background processes. It might be that nohup use is required to avoid that in some contexts. Also, you only show redirection of stdout, not of stderr . =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?26A4D82B-B09A-43F1-B485-E80D7528956E>