Date: Wed, 19 May 2021 14:17:07 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net>, FreeBSD ports <freebsd-ports@freebsd.org> Subject: Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4 Message-ID: <CEE37E74-C521-4D3A-ADFA-4147689D9C8A@yahoo.com> In-Reply-To: <C1CBA631-5A70-4EA0-A4B4-6263545EEC3A@yahoo.com> References: <C1CBA631-5A70-4EA0-A4B4-6263545EEC3A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 : >=20 >> On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote: >>>=20 >>=20 >> [portmaster background omitted]=20 >>=20 >>> If you want to give the attached port a try, it will install LUA and = some >>=20 >>=20 >> 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. >>=20 >> 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.=20 >>=20 >> If the conflict is really limited to merely naming two versions of=20 >> /usr/local/bin/easy_install fixing the naming convention seems to be=20= >> the obvious answer. I remain baffled why something called = "easy_install"=20 >> remains essential after installatiion. Unless of course it's not = really=20 >> an installer. Even so, a more sensible naming scheme strikes me as = helpful. >>=20 >> 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. >=20 > 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. >=20 > 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=3Dmain-arm64-default". Thus the evidence includes aarch64 coverage. > Built with python37: > Apr 20: > = http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-arm64-default&= build=3Dp338d8ba0f777_s5a89498d19 > Apr 13: > = http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-arm64-default&= build=3Dp46fc7df8540c_s1f64f32a4c > Apr 17: > = http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-arm64-default&= build=3Dp9d5f4ef1a469_s86046cf55f >=20 > Built with python38: > May 11: > = http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-arm64-default&= build=3Dp0c0a4f4b9148_scb07628d9e > May 15: > = http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-arm64-default&= build=3Dp6ffbcd54bf8c_s91f251b2ab > May 18: > = http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-arm64-default&= build=3Dp7bfc2c072607_s8d2b4b2e7c > May 6: > = http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-arm64-default&= build=3Dpcd62f0886c18_sd1cb8d11b0 >=20 > These imply that all the prerequisite ports for the build > were also built and working for doing so. >=20 >> 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.=20 >=20 > No such problems in a correctly configured system. > You are stuck trying to get out of a incorrect > system configuration. >=20 > poudriere ignores your system configuration and uses > its own separate one to do its builds. >=20 >> At this point I'm stuck.=20 >=20 > 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. >=20 > 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. >=20 > 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: >=20 > # pkg delete -a > # pkg install `cat file-listing-packages` >=20 > Technically, I do not know if your environment is so > messed up that pkg delete -a would fail. >=20 > 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. >=20 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.) =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?CEE37E74-C521-4D3A-ADFA-4147689D9C8A>