Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4

bob prohaska fbsd at
Sat May 15 23:37:44 UTC 2021

On Fri, May 14, 2021 at 07:29:15PM -0700, Mark Millard wrote:
> bob prohaska fbsd at 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



Thanks for reading this far!

bob prohaska

More information about the freebsd-ports mailing list