From nobody Thu Aug 31 19:44:16 2023 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RcBSh3SH4z4rXCg for ; Thu, 31 Aug 2023 19:44:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RcBSg1CWfz4fWw for ; Thu, 31 Aug 2023 19:44:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=TIEDLf4d; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1693511074; bh=JVO0A1Jq26sTzw+z2/b4CNEb3sKfQADao9Lgz6M5W9A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TIEDLf4dTo3GvScMe+X3UU5Q2miowQaZ6mtEexaCtTq4AuA+x3wnIe1sLqx4nsbIkRZbWFlhOTZzuWlLbORELQeJHaJDhlakFJY+c7fcugOgzGNL4qxlE9jq2MyV+cg9XXqUYc7bgrrNNZz+g+A/Ra7a+eSvg/9Udwqgw/LL9Mr2MNcALfs+WBeqUJ6gX6aQKOWAaG0pFwFDSTu0tq7kQoPS34kq2OO2hoDyEvE9XkdSXuzDNURS/PL3ZhVKsWe/T2l9Wk/5yz/hIY8Ls4lIoWWjoV6vGfwyVc+KXkawKxUjRUipjOvpyObLKuZ9wQBTsZLDNKEU8aI93io12Ygmvg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1693511074; bh=LaeLXTJAVo5DY9iL5FQpE7swtMIEJp5x7s+hR4uqouL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eLvx2+w7nAZV6pp11LhcRQAF4NpWSbeh/xETIU3fIU9EszhgnZsOdPO1HoaRWUIreKLLU2ysmtyY6qDyt3TOoggZjlm6wuc4N8D4eM0Jjb21u9A0IkQ5oYVVDPYmEOGUixHhx8UQ7DnH9ZvJMDcxoBlCBXi5Un4avoAoGf48JyOefy2LQZlPiOP+6VKNQnTORAqhiNybcplrLfbIKRgemKmeZIzG7+hwW09RWjaToyJRy98raP3MGYUJpcAx8T4WCHqiXhmwrL9zJKCIlx62L9Btm8MqSl62h41eQLHxOdoSdhI8qTIbQnsMM0Fb/lI5m2xNk1lVeOtY9u2qZvZv+g== X-YMail-OSG: CrteR8gVM1lKM4C7nAEhHv7OnDzqId7OJu3OsiHOjE2svPsgGdgM8OiRQzc6OWi FrR0ME1KKOIlkVkBH8ADxlMQOTFN7TWJ5BWPHy6ZVZfnI_qHZ5pC205Lp94AJ8PK5eXZw.TdtnJr VfZnmqF7xMIu4spXc6AsciEhXDGseBhgX97Duo81zkL780SQchYxAnRBbsYOsxsyc2Qn7cKiYT.n SuAZ0y3L.Lf_0EnHOpak_IrC5jClmnyqPf4xJcBB_VW1BwwTJucIzkjxnSsSswA3agbihrC3XvgN bdVMimqUdMADLd6EZYy5kB0KRNPXCihduuQEI5V02iblpin9L_c1mMrXa4iPgzYH1knPOT18HlDj Bws4DFWgkeBKlk221UNYBXqZjLso8vXgl4zcMgynbBOFrQJVpk6C_rOLmddFUQjBjtBlw5Pcu3na 1JIy1Nytd4CFvhX9hpuE.nWtSjYmEbRJy2u63NV1KmjNrhELWrgp1tWa48GFn4fz6c6Vxn0f7dnJ jJr27foFLGPnMM8wcAZfK0EUcugGbykgNmlaWMfmEqeQj9GnPjf1NgYeNmxbSxMZPv8c_P3BBekX wxSWFN36GUKvRj33W0OpTA.72hRSM4rD.3ogZnX.54e7MDc1DumXppefwyVpJBX096mxvFVk7HqD 0X618KXIZKGSrSYbTo57whkCIcWmHiZOhnKawMExBauZN8R.MxSNjg9fJ5Ps7GHW0ivLsruyZthr 6KONzbrqiVwR.4XxvXBCDj6n5.U.qpNOdtlW5iMSezbi_p9SpbFAKXaStlcGkUlK3jmicA40xVus t6SW_ej.iox9ZnM7REqvFYsWc2ZvCDeDkQ9rW..ngXM9SBOgN5d7AtzmxnmwiqvPmBKLQAEKejso QDX0epaDLeelP1GN7waQ9YURf8vo5ia72U74dj8c.rpuZzUKfFEIxSYdmVovKRHH8SS2xjkvwpU1 DIyAwA588RnYEBBlDE7Ckk7WTSGPED4xwfPYuJk.h1n1_stxJ59HQrMqEAsWSYxxbQ_tyYOZ0Qy6 uOZwdpuvPdt7mR.iWYnpY9KwPni_.t1I5YxEigJvUipwehBe8SSnvZL7pRPMrjNO6g0dy9IeiFey hNBp1ikl8fBsuFolw2MnvyOi.IkRERo5vSXx3M422X0nFFNrt5xuGAlwSGJGQd69DgAbZ2U8xkoC xX.bcr8EaMfSFdcDWyMnncaSa0EgCSoKv8SdsSYgY3Kg7iYfmn3ZGPkTiLgCVeUvK_1zknItZoGJ V1bnWl2EEaeqw.dbaTXhRp60l4NmuhrrB9amnBe8fQv1byNszTwTCmVT_V0ZxwnwsGDygb82XjtQ _du3FMtzSCsTHeF8dWkcrFS6eJ78nWPVcizibLWsIPW2lDDK7keNcfAuMspVCS5hzrl5p2gmgNap xpPsnL5sbEnwiosCH_sQ.dmlt8OtgqMPJ2phXnSXcvdB6CyrE20apDwJ.kclQnKheebwmJ3qIYSR guz7DywxUdHZU1fa75LN1gwqxYOml2TAIAVd3B1IRBoyQB4DWdolmKXDvY5bFDw7iwIjLoL49vMH 5Xo6uHtz9IWPnv_Bj99BRysMFMgscFTZXjmNGuMv9yvLUttBhozFXVPKWGtRqZ.Zmse8m9C2xIqA nOz0l.nj88gXjFZr1oGj6f9NUfDwI0wX7dXlc_8Ds5ssm82fU3CFDG.6e0tH0rgVooo_BgKJ.oW9 T0TBBCPfQsyiNVK5WvpGAT28683BjRG41h0Z_yWM48HT4NMASzp3xmESbezI96ASj3lC8VN4BWuf aeUPJH_FGYCqmXLQsFzQjLILqiO2LVqS5QAeCDTWSvrIqaPwZlQQqw4.pmoucLE8MSf_P1E5EbtH nyFVE1wFM1p570OXDCBoPy7OmgBif.Yi8P8IcaiI7GRRoyPNu9Q6PBsJTS14GWWbAH9dZn.__Kgj 1SxlD7sHMst8lAcWt2smTKhTcMHu0QEJD0yOwYFh1MsnHfwWKmmehfTxLFmbIDb4nKxp_.7MBGL8 NXYwiX7ul2VOloj.Yab9_l3lXs8qGxPXlzk5X8mkbUhfk.86e4nRMn0U49I9HtII8LL6AHpJ_Cvj OkmNB1V7yVR9yk9nnk8m769ZkpspzP6QZke3OwPd2dKlkeEWcRm7axocDyDZAwzJx_JNG2uiHkAL TPMQzvOK8ukYj0dpfYY_O_rt3OU1VlO7KbkEjIdGKVkzEj_68r9rOi6a8dYTdRX_JoTxPp1cLBU9 bUn.wraPyQKt.WblyJlDMy_VDQpuWEStJwd9kMOoazE1EugCsgOMbZU77_IizwqnD7bfrcUWexrg - X-Sonic-MF: X-Sonic-ID: d445c8b6-bfa0-451b-acc4-4a1634b6ecc5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 31 Aug 2023 19:44:34 +0000 Received: by hermes--production-bf1-865889d799-7x4p2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 362843fa0cb5ed4fca6d2ae1eec5dae8; Thu, 31 Aug 2023 19:44:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: Bmake bad variable name From: Mark Millard In-Reply-To: Date: Thu, 31 Aug 2023 12:44:16 -0700 Cc: FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <26A4D82B-B09A-43F1-B485-E80D7528956E@yahoo.com> References: <9B530FC9-ED6B-4B75-A731-D8F7D7586A51.ref@yahoo.com> <9B530FC9-ED6B-4B75-A731-D8F7D7586A51@yahoo.com> <040CECBC-8A04-4049-91A7-0C1522000F5A@yahoo.com> <94FBA6B3-EA84-4B96-A87A-0A04C3E6EFE0@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from]; BLOCKLISTDE_FAIL(0.00)[98.137.65.83:server fail]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4RcBSg1CWfz4fWw [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