From owner-freebsd-ports@freebsd.org Sat May 15 23:37:43 2021 Return-Path: Delivered-To: freebsd-ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EA0D962AE5D for ; Sat, 15 May 2021 23:37:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FjMJQ54f2z4g43 for ; Sat, 15 May 2021 23:37:42 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 14FNbZJv058384 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 15 May 2021 16:37:35 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 14FNbZsT058383; Sat, 15 May 2021 16:37:35 -0700 (PDT) (envelope-from fbsd) Date: Sat, 15 May 2021 16:37:35 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD ports Subject: Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4 Message-ID: <20210515233735.GA58311@www.zefox.net> References: <0B407A98-E0D4-461E-BFD8-E02019E96757.ref@yahoo.com> <0B407A98-E0D4-461E-BFD8-E02019E96757@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0B407A98-E0D4-461E-BFD8-E02019E96757@yahoo.com> X-Rspamd-Queue-Id: 4FjMJQ54f2z4g43 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [3.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.80)[-0.803]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[0.999]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ports]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2021 23:37:44 -0000 On Fri, May 14, 2021 at 07:29:15PM -0700, Mark Millard wrote: > bob prohaska fbsd at www.zefox.net wrote on > Fri May 14 01:35:28 UTC 2021 : > > > Would use of poudriere help with this sort of problem? > > It isn't trivial to configure, but this sort of difficulty > > has been growing ever worse. I didn't want to deal with the > > complexity and overhead, but maybe it's time. > > > > I happen to use ports-mgmt/poudriere-devel and it > avoids such issues but does have build-time tradeoffs > and the like. (I'll note that I presume the sort of > sustem tuning to avoid Out Of Memory kills and I try > to scale to avoid a literal out of swap space > problems.) > So far, OOM problems haven't appeared on the 8GB Pi4. If they do, the problems will be recognizable & the solutions known. > I'll start with very overall background for port > building because I do not understand your context > or goals. Otherwise my material could end-up > implicitly be picking from the alternatives in > an inappropriate way. Some of this is relevant to > (all?) other forms of port building as well. > Build time is less a problem than completion. This is a single machine, self-hosting for kernel and world. The only installation target for ports is itself, at least for now. > Some basic questions will be: > > A) ZFS vs. UFS? (There are some configuration setting(s) > dependent on which.) > The machine uses UFS, on a 1 TB mechanical hard disk over USB3 Memory is 8GB, plus a like amount of swap. So far, no swap has been used. > I currently have examples of both: I've started > experimenting with ZFS again in some contexts, after > years of not using it. No individual context is using > a mix of both and I use ZFS in contexts with >= 8 > GiBytes of RAM. I do not try to tune it for small > memory contexts (small on ZFS's scale). > > > B) How a builder establishes a world-context to execute in? > For reasons of testing patches and such I build and > install a world into a directory tree and have poudriere > use that tree instead of poudriere installing or even > building its own world in a tree. (And I've never done it > any other way.) > I'm a bit confused here. I _think_ the world-context is the kernel and root directory, all living under / . If it's particular to the port being built please clarify. > I do this with separate world-trees for aarch64 vs. armv7 > on an aarch64 system so I build for armv7 in a faster > context with more RAM and then transfer materials to > the armv7 system for pkg to use for pkg commands. (I've > not set up a server/client context.) > > You could, of course, just deal with "native" and ignore > the RPi* aarch64's supporting doing armv7 builds. > For now the machine is building ports for itself. I'd guess that's native. > I use the same buildworld for updating the running kernel > and world and for installing the world used for poudriere > when the same OS vintage/variation is to be used for both. > > If you prebuild, there will be questions of what paths > you want to use to reference the for-poudriere build > trees. > I'm a bit confused here. I _think_ the world-context is the kernel and root directory, all living under / . If it's particular to the port being built please clarify. At this point there's only one OS, aarch64 -current. It's building the port and will run the finished port Not familiar with the term "prebuild". > > C) How a builder establishes a ports tree? For reasons of > testing patches and such I have a /usr/ports tree of my > own (sometimes under another name) and have poudriere use > that tree instead of making its own. (And I've never done > it any other way.) > > I use the same /usr/ports for both aarch64 and armv7, so > only the one copy. > > You might want a different path than /usr/ports if you > pre-establish the ports tree. > > There is presently a single ports tree, cloned via git, at /usr/ports. I'd prefer not to duplicate it, for sake of sanity and space, the disk being only 1 TB. Sanity's even scarcer. 8-) > D) What FreeBSD versions to target? I do not happen to > use ports that must track the kernel version in detail > so I can target a releng/13's release/13.?.? and use the > ports for stable/13 as well. In fact, I can generally > get away with using those same ports on main [so: 14], > being explicit about the ABI for the pkg commands. > The target is the host running poudriere, in this case 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-49c894ddc It appears to be a simpler case than intended for poudriere. > You might use ports to drive displays and such in a way > that leaves you required to track kernel versions more > closely. But if it is only RPi*'s, then may be not for > that. But there are other ports around that violate the > clean separation vs. kernel details. > > To some extent this gets into "how many builds to cover > all the systems?". That in turn can influence how the > systems are set up, such as to eliminate some builds > being needed. Your context might be simple, with only > one type of context to cover. > Just one build for each port, for the system it's built on. > > E) Build as root? As non-root? > > I happen to only have done build as root but the > systems are not used for other activities. There > could be ownership/permission issues that I've > not run into. > It isn't apparent that root vs non-root build matters, though in principle the less root activity the better. It looks like changes to the config file would include NO_ZFS=yes FREEBSD_HOST=https://download.FreeBSD.org RESOLV_CONF=/etc/resolv.conf USE_TMPFS=no NOHANG_TIME=28800 MAX_EXECUTION_TIME_EXTRACT=14400 MAX_EXECUTION_TIME_INSTALL=14400 MAX_EXECUTION_TIME_PACKAGE=28800 Thanks for reading this far! bob prohaska