From nobody Thu Aug 31 01:08:06 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 4Rbjhp2DwLz4rTMw for ; Thu, 31 Aug 2023 01:08:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (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 4Rbjhn5g6Vz4qhK for ; Thu, 31 Aug 2023 01:08:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1693444102; bh=uHKDux/eBF7kEA+2dvYav9klHdGUQL7F4c1hYX0ePB4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=joBpF4UELkvYxjzc51g7c+eY38VMJYKFsgiJ62jo34CHmpwRVo9nh4Ejg3qlYPp0OFFlNkvXPT2Odg1s3aXE9ceXwpe8idJWhxOOnK9I4H7mwL3pUtU+ej7q5YdUL+nSkNJp4WVf2fxvlMVfQ8Yv5TCo8m1ES0Na9+tyLl5Bvk1yGemBNDT5zDRdS/YGMynFqcPurEaHRL1y/WxCCYlopRhcYsmWFhM90MVECGprGzK44mp9XK8STLeQsOBQFtDmGFzSmgN7sfwIr+Ca3ptXaR6s0UCnQmMMbjbVTzL+WTPWCUeFunT6XFP6dySk/KM7fmrsdg1rBC15UlyGDpkrHQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1693444102; bh=mSso03hK01tiv6MJt9hC/IX3fwD2jIGARPJOyqJo607=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Dv0UaXhGm5/MwNSt0BAVmmTtu+P1Bp3jTpn2r7o+2wZ4BngqCpzoo0vJavslUfH3Za4uqr0mxiZh+Nhsbsu2zG0NA8pKa5a3sO6O32YsAcLKAV0gEEYpDuOmbbEy5uVJGk6UAhbqr+Em2Fq921rqjTlSJC/zclO79IXfPe8GEMHeNG1Lvi2VTtWKL1VvEMszBxL/CnLvasufwFCzmqRfy2cxOJZsFFDJWc0FQJlny0dMOL0i/zenUSGXvoRwnPudIDLh5fp8xbfEJpQpfsffyj4TuTCnoYx6K4C8yGFuZxzY1MTl6C1pu8l/Z7ojXBtufRT5c8bUlTZBT9uYvVboUA== X-YMail-OSG: iw3tdQkVM1kEDxHeucv8m715dEEvk4x7.lywQKvRcH.rj_yL_chkdT_Gu3mSpIv _ibmjo5IZhOaRckq5sd_CcooG6LNBT0BUUJwHwCXSSKkAKI1ccqsHsz1Pk3.co4xX7q5rnaXad02 1Y9RfnrdscEJ2MohaWBo.0YBLDEn7KrkssQ1CoN3UU6ysKDFavvc7mwwD5LV1YcOuZTb5MyleZ22 qpxVi3Inakay9stbxrJpDlX67cy6G8EXGPOawo7GQFHNBvKkuOaqRgidK9zlFJhSt6m9HrK9jIoz _YN4namQUHeAjuXVG6jFFaXKBwVUtb6PIgXGbitvaNgwjgKUVQbyY6WWQPxZeJNeab66pC7gTo.S zBsQbSaJFtGUy8yJSUE.vJJ8VSiKPi_aTGJmL8dhtUTq.xzfwNmMN6m8W7N_cXnZdEtZX9kGXbFn QXXzEBl.NkC1ySTcW1y_ApeDvZtpe1Xafk_pHtS4g8Dm5rO5yLfOdKiQjiKr0mpEK6FaVnb5VDNr 0nKLqpvitoCSmGhHdLKTAhorEG1FTXnjR2LauCh9LDw.pnz75qilncuPvd7hsw19RURLNkbq_ztj K8Svp05mH6uJhahzl4CLlnkFuHlyiwA7dLb6.rU00kXU6owaAI6.7EyGjaqg_OZwuI5.zFlpdAEX 6_Yvs4XcgdAEj3yWi6yfYiJUpn.lDNR1hHqNEO27AYu813C9yUGE0_QND8uapFRTvdxcCdJbKdrw _j6gxJ.RVywNEb.ERsTXF44LmsgYzO128OptgguRBayJKBD1T3rYfSVSKF1tNyi4iNum_YfQLqbA 7CRps9Gy4kMe0e8YL2l5LG9SVJtG.Au4QrGUrR5jZUBJUVpVMXRomXI5AmbqneHc1x3HL_UWsNhZ mM9OtSGsOgwQl8afXQDGhuyGvM54LcE.40ie55P0nTzXEaI1cBPoS.Zmx9p.OfUnHB0Y8_oklgR. at0Tki2rs2CCYEVl8SMesPr30EP8xlEaJryZgoPmJ2mDjIJiCao2dvbVxS.r.cfIcyxFz._x.3nU jtQm1lYNyPlXvC50yXflizhTajbpQZszj4fuITgJaJbe7iobVzEcy0t8yxp4ktZXFBk_WbnrmR4C TgB6ZkDXuodfG4VYmmtr7ou0CFnSiZGiI6FfHQk1tLOTxJrsPQXznIUB_QVg6VOlGufebYy1p7KM fZn9onZ9fKAgu85xvzrau6YBz5ZaakTiY_XFIqpauFnKbOnzegWuqkwI.5U8O9Jkxa0AJKMHP6lS WCKMP7qEbRvpx6EzIiWVISk4NR9bjWbpAO9G5_zln1Pl6vqNnX5bmlR34fg_q4cy0XPbugQgoDGs CpOyBTEQADZYPxv.EhM64_NP2zkMlePqWFWPeu4BfDM2te_F26vvvBjWfLf3P0cWXtHF4h3E6L65 22Kq9GzqSRcg3tWKM_K.FxjzohrLDZC5K6bcur5eGcJLLAyk9YlOa8F63MzbRmFrUa1AX1Eoz0Qn YO404d_i.5uQVbh9dLkFOsulVcsjriidsDWqzS.XOV2QFpG1kAxQXB0uK7B9GrNsmcsTYCVVWTS7 52ZHgdDcegNeoV60pIaa9nEvp7hVEYr9pQeaVjsxywvDNYqYz4uK4biSzJ90Zo04Ca8181FNcjVy tCPXK6aAj0izP9Ld9s0.yqpnWHYHGJpa1M5g0lflgJtz24raONPb6EjansvRrz4zBm6DkrTnSSKl RpYyNcQs7Edi.ZxyQrSHhAtUWWsaNqcM9h4SkEikdd6ZxeeuS7RAUl2qk5PTIxa5jkJTEamhD0mq Npx3UjEpxK5Jpc3X7llUzLVLI3J2AFin.fk5RYb6YopX.wvIaIshQylBn.ZrMhncOHitpjISHMQz q8xKCRAjBKmYj_hwfUqtMcbwc6a7XRuaDzAtY6NhiDgtAHPU9H9g9464FDN5qlFLKcwxE_hhIyav cbguLJhjSr02aqcf6MV.O8hPUK340FCOiE.jQojmtGbrNITzj7K90GwGsTtUjTzwd65H2IKUbtxi YQ5JfCgst.dkihAuD9qNxozYQcGST_ZMJLBW2G6GKyru22IGuBanK1ioXkOqn5rJ2O1DtWIn5RHo EzdG8bgawQ9UZwM6_CBEwwhCzK8We38z77EJ0eR3Z7cc12jzpffB_gGM0K3AReYgwSP1tbkuOZCF 9Jla8AAmn9I_mdyfFrpfzowodzh0MCoJk6zRNFDz3gvO2wR5QJTLlt.8TSGiKZzPghKAHTh0kSGC xOworA2CSRVohaT9Oqq3fXUnr9Mge1Dj8YFW18Zp2YCYucEQzS_qF3y.cfC5nlhix8W8XqRE3szD T6g-- X-Sonic-MF: X-Sonic-ID: 344e7e75-c773-482f-85f0-b74d36ae4e30 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 31 Aug 2023 01:08:22 +0000 Received: by hermes--production-gq1-6b7c87dcf5-fl46l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 52771c4f6dde38dd8fddabdb8c60dcbd; Thu, 31 Aug 2023 01:08:17 +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: Wed, 30 Aug 2023 18:08:06 -0700 Cc: FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <94FBA6B3-EA84-4B96-A87A-0A04C3E6EFE0@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> To: bob prohaska X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4Rbjhn5g6Vz4qhK 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. 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