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

[Mark Millard via freebsd-ports]

On 2021-May-19, at 10:29, Mark Millard <marklmi at yahoo.com> wrote:

> bob prohaska fbsd at www.zefox.net wrote on
> Wed May 19 16:09:32 UTC 2021 :
> 
>> On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote:
>>> 
>> 
>> [portmaster background omitted] 
>> 
>>> If you want to give the attached port a try, it will install LUA and some
>> 
>> 
>> I tried ports-mgmt/portmaster, it got stuck the same as make.
>> Unless the new version behaves very differently I'm doubtful it'll
>> help.
>> 
>> At the moment it looks like lxqt requires both python37 and python38.
>> The needs seem to arise at different stages of the build, so perhaps
>> they can be invoked, used and removed sequentially, but at this point
>> deleting python37 causes enough collateral damage to make further
>> progress impossible, or at least non-obvious. 
>> 
>> If the conflict is really limited to merely naming two versions of 
>> /usr/local/bin/easy_install fixing the naming convention seems to be 
>> the obvious answer. I remain baffled why something called "easy_install" 
>> remains essential after installatiion.  Unless of course it's not really 
>> an installer. Even so, a more sensible naming scheme strikes me as helpful.
>> 
>> It isn't apparent to me that something like poudriere can solve this sort
>> of problem either. If poudriere attempts to build lxqt in a single jail
>> it looks like the conflict will emerge within the jail.
> 
> The FreeBSD port building servers use poudriere and are not having
> a problem. The problem is your messed up environment that already
> has the inappropriate mixed that poudriere and the package installers
> it makes would never produce.
> 
> The following show lxqt (10 ports have that in their names) as
> attempted to be built (not skipped) and all were successful
> instead of any failing:

It may not be obvious that I looked up builds on
ampere2.nyi.freebsd.org because that is the builder for
targeting arrch64 main [so: 14] builds. That is why the
url's below have: "mastername=main-arm64-default".
Thus the evidence includes aarch64 coverage.

> Built with python37:
> Apr 20:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default&build=p338d8ba0f777_s5a89498d19
> Apr 13:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default&build=p46fc7df8540c_s1f64f32a4c
> Apr 17:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default&build=p9d5f4ef1a469_s86046cf55f
> 
> Built with python38:
> May 11:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default&build=p0c0a4f4b9148_scb07628d9e
> May 15:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default&build=p6ffbcd54bf8c_s91f251b2ab
> May 18:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default&build=p7bfc2c072607_s8d2b4b2e7c
> May 6:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default&build=pcd62f0886c18_sd1cb8d11b0
> 
> These imply that all the prerequisite ports for the build
> were also built and working for doing so.
> 
>> It'd have to
>> split the build between two or more jails and then merge the (compatible)
>> executables into a third jail for completion, AIUI. 
> 
> No such problems in a correctly configured system.
> You are stuck trying to get out of a incorrect
> system configuration.
> 
> poudriere ignores your system configuration and uses
> its own separate one to do its builds.
> 
>> At this point I'm stuck. 
> 
> So you had a poudriere failure? If so, report the details,
> such as publishing someplace the log file showing the
> failure. Otherwise, you are not stuck.
> 
> Once poudriere has built the packages, you would set up
> pkg to use those builds and then force-(re)install all
> your ports to use the ones poudriere built. (Not just
> lxqt.) This would get all your ports back to being
> coherent with each other.
> 
> Presuming a file listing the packages that you want
> to be sure are installed (not needing to list
> dependencies) and that that pkg has arleady been
> redirected to use the poudriere-built packages:
> 
> # pkg delete -a
> # pkg install `cat file-listing-packages`
> 
> Technically, I do not know if your environment is so
> messed up that pkg delete -a would fail.
> 
> I'll note that if pkg instead still points to the
> FreeBSD servers (such as quarterly), the same 2
> command sequence should re-establish those builds.
> 

I started a:

# poudriere bulk -j13_0R-CA72 x11-wm/lxqt

on one of the aarch64 systems that I have access to
(cortex-a72 with 4 cores). It reports (based on prior
history of other ports building that might overlap and
so avoid some things needing to be built this time):

. . .
[00:00:25] Building 99 packages using 4 builders
. . .
[00:00:38] [03] [00:00:00] Building lang/rust | rust-1.52.1
. . .

so it looks like it will be hours from when I started
it before it will have finished, presuming that rust
builds to completion. (Rust takes longer and uses more
disk space and the like to build than any llvm* that
I normally build.)

I expect to later report that it built to completion, no
failure, so long as nothing else causes lxqt ports to
be skipped. But we will see if my context gets the same
results as the FreeBSD build server(s).

If it builds, I'll see if pkg can install it.

poudriere jail 13_0R-CA72 is based on a releng/13
release/13.0.0 installworld, instead of being based
on a main [so: 14] one. This should not matter for
the issues at hand. Technically, I could reboot into
main [so: 14] (so that kernel is running) and build
in jail main-CA72 that has an installation of main
--but I do not think it would provide significantly
different information.

The system is faster than an RPi4B, despite the
configurations using the same Cortex-A72 count
and clock rate. It has more RAM (16 GiByte) and
more RAM caching, and a RAM subsystem that is
faster overall for parallel activities (more than
size can matter for caching effectiveness for
parallel activities).

(The used system's single DIMM DDR4 RAM+RAM
caching was less effective for parallel jobs than
the OverDrive 1000's smaller but dual-DIMM RAM
subsystem [8 GiByte] and larger RAM-caches, despite
the OverDrive having 4 Cortex-A57s and a slower CPU
clock rate. Unfortunately, the OverDrive 1000
failed recently or I would have used it to cut
the time some. The used system is the faster one
for activities that are close to single threaded.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"