Date: Sat, 15 May 2021 18:57:31 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: FreeBSD ports <freebsd-ports@freebsd.org> Subject: Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4 Message-ID: <A43A154A-FB52-45DB-B3BB-DE1740128B14@yahoo.com> In-Reply-To: <20210515233735.GA58311@www.zefox.net> References: <0B407A98-E0D4-461E-BFD8-E02019E96757.ref@yahoo.com> <0B407A98-E0D4-461E-BFD8-E02019E96757@yahoo.com> <20210515233735.GA58311@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-May-15, at 16:37, bob prohaska <fbsd at www.zefox.net> wrote: > 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 : >>=20 >>> 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=20 >>> complexity and overhead, but maybe it's time.=20 >>>=20 >>=20 >> 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.) >>=20 > So far, OOM problems haven't appeared on the 8GB Pi4. If they > do, the problems will be recognizable & the solutions known. >=20 >> 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. >>=20 >=20 > Build time is less a problem than completion. This is a single = machine,=20 > self-hosting for kernel and world. The only installation target for = ports=20 > is itself, at least for now. Good to know. >> Some basic questions will be: >>=20 >> A) ZFS vs. UFS? (There are some configuration setting(s) >> dependent on which.) >>=20 >=20 > 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. Good to know. >=20 >> 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 >=3D 8 >> GiBytes of RAM. I do not try to tune it for small >> memory contexts (small on ZFS's scale). >>=20 >>=20 >> 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.) >>=20 >=20 > I'm a bit confused here. I _think_ the world-context is the kernel > and root directory, all living under / . [I use some of your later notes in making choices here.] poudriere works in its own world in for a builder's jail (no separate kernel involved). Otherwise it would not being making a clean build of the ports (producing packages for later installation). In the form that I use poudriere I use something like the following. I presume here that /usr/src is populated and has the source for the system involved. (I do not remember your describing its status.) First, per "man poudriere-jail" and its description of using "-m method" for method "null", the later poudriere commands are based on already having set up via something like (and picking a path for the system poudriere is to use): # cd /usr/src # make installworld DESTDIR=3D/usr/obj/poudriere-system DB_FROM_SRC=3D1 # make distrib-dirs DESTDIR=3D/usr/obj/poudriere-system DB_FROM_SRC=3D1 # make distribution DESTDIR=3D/usr/obj/poudriere-system DB_FROM_SRC=3D1 Note that this system does not have any tailoring or any pre-installed packages/ports. Having ports installed messes up poudriere's operation: no longer clean. poudriere only uses ports that it has built packages for: it installs such packages in its system, but only as needed for each port builder. (It cleans up between ports.) It does not touch your live system's packages or installed ports during the build. (I'll not list deatils for updating /usr/obj/poudriere-system as the system progresses over time. The above is initial installation. But delete-old and delete-old-libs can be involved. distrib-dirs and distribution are instead of etcupdate or the like.) As for setting up a ports binding and a jail: # poudriere ports -c -m null -M /usr/ports # poudriere jail -c -jmain -m null -M /usr/obj/poudriere-system -S = /usr/src -v 14.0-CURRENT Note: the above picks the name "main" for the poudriere jail and sets up to use /usr/src and is told the context is to be 14.0-CURRENT . Neither of these commands do the build: they instead establish context for doing builds in the future. Note: the cd and 3 "DESTDIR=3D" lines are the kind of activity that I called a "prebuild" of the system that poudriere is to use. (So: poudriere itself is not building or installing a system.) This style avoid having another system build involved, just an install. (I avoid the complications of describing alternatives to this particular style.) > If it's particular to the > port being built please clarify. Not particular to a port, but to a poudriere jail. A poudriere jail does not have your installed packages already installed, for example. (I'll not try to list all the types of potentially dirty/problematical that this allows avoiding.) >> 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.) >>=20 >> You could, of course, just deal with "native" and ignore >> the RPi* aarch64's supporting doing armv7 builds. >>=20 > For now the machine is building ports for itself. I'd guess > that's native.=20 So I'll ignore setting up for targeting armv7 on the RPi4B as well: just aarch64 . >> 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. >>=20 >=20 >=20 >> If you prebuild, there will be questions of what paths >> you want to use to reference the for-poudriere build >> trees. >>=20 > I'm a bit confused here. I _think_ the world-context is the kernel > and root directory, all living under / . That is not a clean environment. For example: already installed packages/ports. Avoiding depending on such is how odd mixes of, for example, python37 and python38 are avoided: the builds never see anything old. Also, the builds do not touch your running systems installations, so build failures leave your system as it was. Installing what poudriere built is a separate step after the whole build's overall status is known. > If it's particular to the > port being built please clarify. Again: Not particular to a port, but to a poudriere jail. > 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". See the earlier note about the 3 make "DESTDIR=3D" lines. >>=20 >> 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.) >>=20 >> I use the same /usr/ports for both aarch64 and armv7, so >> only the one copy. >>=20 >> You might want a different path than /usr/ports if you >> pre-establish the ports tree. >>=20 >>=20 > 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-) The: # poudriere ports -c -m null -M /usr/ports that I listed earlier reuses your /usr/ports without duplicating it. The: # poudriere jail -c -jmain -m null -M /usr/obj/poudriere-system -S = /usr/src -v 14.0-CURRENT that I listed earlier reuses your /usr/src without duplicating it. >> 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. >>=20 > The target is the host running poudriere, in this case=20 > 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-49c894ddc > It appears to be a simpler case than intended for poudriere. poudriere allows a lot of alternatives, your is just a special, limiting case. But your case is covered. Things appear more complicated because of all the alternatives poudriere allows covering that you happen to not have involved. I'm trying to help isolate the subset that you need to pay attention to. Also it may help in being able to look at poudriere materials and identification of what you can ignore. >> 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. >>=20 >> 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. >>=20 > Just one build for each port, for the system it's built on.=20 poudriere does the builds of the packages, not the installs of the packages it builds. You configure pkg to reference the packages that poudriere builds and then use pkg to do the installs (instead of getting packages from FreeBSD servers). For now I'm ignoring the pkg configuration. I figure getting a poudriere build that completes should come first. Afterwards you can point pkg to use it and then install. >> E) Build as root? As non-root? >>=20 >> 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. >>=20 >=20 > It isn't apparent that root vs non-root build matters, > though in principle the less root activity the better. Simply because I've only used root, you may want to match what I've been doing, avoiding any extra issues that I've not seen. > It looks like changes to the config file would include >=20 > NO_ZFS=3Dyes > FREEBSD_HOST=3Dhttps://download.FreeBSD.org > RESOLV_CONF=3D/etc/resolv.conf As I remember, RESOVE_CONF is in the poudriere.conf.sample already. I suggest duplicating that and just editing in differences/additions. That is part of why I supplied a diff output. It also avoids needing to explain every option in the sample: just "what do you need to tailor" needs some description. > USE_TMPFS=3Dno > NOHANG_TIME=3D28800 > MAX_EXECUTION_TIME_EXTRACT=3D14400 > MAX_EXECUTION_TIME_INSTALL=3D14400 > MAX_EXECUTION_TIME_PACKAGE=3D28800 You may want MAX_EXECUTION_TIME=3D432000 like I showed (or some figure). But things like ALLOW_MAKE_JOBS=3Dyes feedback into how long builds take. Other than reporting what combination I've used, I can not help much with exploring and judging the ALLOW_MAKE_JOBS=3Dyes vs. not tradeoffs (and other such). Setting numbers large and then backing off towards observed elapsed times (with margins) is probably better than failing builds and doing retries from not having set big enough figures. poudriere's defaults are not designed for this class of machine. Every time constraint that I explicitly set it was because I ran into a failure at 1/2 of value I use. But that spans doing builds on cortex-A53 (4 GiByte RAM) and cortex-A7 (2 GiByte RAM), not just cortex-A72 (4 GiByte or 8 GiBYte). I did not try to keep track of figures for each arm machine separately. I list the ports (that I want to have installed eventually) in a file in origin form. For example: # more ~root/origins/main-origins.txt archivers/unzip archivers/zip base/binutils #base/gcc6 benchmarks/bonnie benchmarks/bonnie++ benchmarks/iorate benchmarks/iozone benchmarks/iperf3 benchmarks/randomio benchmarks/stream devel/binutils devel/binutils@aarch64 devel/dwarfdump devel/freebsd-gcc6@aarch64 devel/freebsd-gcc9@aarch64 devel/gdb devel/git@lite devel/llvm11 devel/llvm12 devel/patch ftp/wget lang/gcc10 math/gnuplot-lite net/rsync ports-mgmt/bsdadminscripts2 ports-mgmt/portlint ports-mgmt/portmaster ports-mgmt/poudriere-devel security/sudo sysutils/acpica-tools sysutils/dmidecode sysutils/dtrace-toolkit sysutils/edk2@macchiatobin sysutils/edk2@rpi3 sysutils/edk2@rpi4 sysutils/i2c-tools sysutils/mmc-utils sysutils/py-diffoscope sysutils/rpi-firmware sysutils/smartmontools sysutils/stress sysutils/u-boot-orangepi-plus-2e sysutils/u-boot-pine64 sysutils/u-boot-rock64 sysutils/u-boot-rpi-arm64 sysutils/u-boot-rpi2 sysutils/u-boot-rpi3 sysutils/u-boot-rpi4 sysutils/u-boot-sinovoip-bpi-m3 x11-drivers/xf86-video-scfb x11/lumina x11/xorg-minimal x11/xterm I then reference the file on the poudriere build command: # poudriere bulk -jmain -f ~root/origins/main-origins.txt (Again: that I use an "as root" context is visible. You might want an explicit full path or some such.) poudriere deals with building and using dependencies. It also deals with updated dependencies causing the more overall ports to rebuild. This only does the builds, not installing to your running system at all. I'll note that pkg uses different notation for those lines that have a "@" in them above. An example is that devel/binutils@aarch64 is named aarch64-binutils as far as pkg is concerned. So I have a file listing the pkg notation as well: # more ~root/origins/main-pkgs.txt archivers/unzip archivers/zip benchmarks/bonnie benchmarks/bonnie++ benchmarks/iorate benchmarks/iozone benchmarks/iperf3 benchmarks/randomio benchmarks/stream binutils aarch64-binutils devel/dwarfdump aarch64-gcc6 aarch64-gcc9 gdb git-lite devel/llvm11 devel/llvm12 devel/patch ftp/wget lang/gcc10 math/gnuplot-lite net/rsync ports-mgmt/bsdadminscripts2 ports-mgmt/portlint ports-mgmt/portmaster ports-mgmt/poudriere-devel security/sudo sysutils/acpica-tools sysutils/dmidecode sysutils/dtrace-toolkit edk2-macchiatobin edk2-rpi3 edk2-rpi4 sysutils/i2c-tools sysutils/mmc-utils py38-diffoscope sysutils/rpi-firmware sysutils/smartmontools sysutils/stress sysutils/u-boot-orangepi-plus-2e sysutils/u-boot-pine64 sysutils/u-boot-rock64 sysutils/u-boot-rpi-arm64 sysutils/u-boot-rpi2 sysutils/u-boot-rpi3 sysutils/u-boot-rpi4 sysutils/u-boot-sinovoip-bpi-m3 x11-drivers/xf86-video-scfb x11/lumina x11/xorg-minimal x11/xterm The files that configure pkg to use what poudriere has built are: # ls -Tld /usr/local/etc/pkg/repos/* -rw-r--r-- 1 root wheel 25 Apr 25 20:35:22 2021 = /usr/local/etc/pkg/repos/FreeBSD.conf -rw-r--r-- 1 root wheel 111 Apr 25 20:39:38 2021 = /usr/local/etc/pkg/repos/custom.conf (Again: that I use an "as root" context is visible. Adjust as needed.) Example content for this is as shown: # more /usr/local/etc/pkg/repos/FreeBSD.conf FreeBSD: { enabled: no } # more /usr/local/etc/pkg/repos/custom.conf custom: { url: "file:///usr/local/poudriere/data/packages/main-default", enabled: yes, } With those, something like: # pkg install `cat ~root/origins/main-pkgs.txt` would try installing the packages that had been built. pkg has a -f option but it means "force", not "file": thus the use of cat. With pre-existing ports installed, -f may be required to replace them all with poudriere's builds. The command will install other ports needed at run-time, not just what you explicitly list. The command will not install ports only needed at build time. Given the initial problem that you are starting from, you likely want to do: # pkg delete -a # pkg install `cat ~root/origins/main-pkgs.txt` so that no cruft is left installed, ending up with just what poudriere built. Hopefully the above material helps. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A43A154A-FB52-45DB-B3BB-DE1740128B14>