Date: Wed, 19 May 2021 20:02:31 -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: <6257373F-C0DB-41A4-BD0A-BD1628345C29@yahoo.com> In-Reply-To: <CEE37E74-C521-4D3A-ADFA-4147689D9C8A@yahoo.com> References: <C1CBA631-5A70-4EA0-A4B4-6263545EEC3A@yahoo.com> <CEE37E74-C521-4D3A-ADFA-4147689D9C8A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-May-19, at 14:17, Mark Millard <marklmi at yahoo.com> wrote: > On 2021-May-19, at 10:29, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> 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: >=20 > 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. >=20 >> 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 >=20 > I started a: >=20 > # poudriere bulk -j13_0R-CA72 x11-wm/lxqt >=20 > 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): >=20 > . . . > [00:00:25] Building 99 packages using 4 builders > . . . > [00:00:38] [03] [00:00:00] Building lang/rust | rust-1.52.1 > . . . >=20 > 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.) >=20 > 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). >=20 > If it builds, I'll see if pkg can install it. >=20 > 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. >=20 > 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). >=20 > (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.) >=20 . . . [13_0R-CA72-default] [2021-05-19_10h44m58s] [committing:] Queued: 99 = Built: 99 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 0 Time: 08:30:14 . . . # pkg install x11-wm/lxqt Updating custom repository catalogue... Fetching meta.conf: 100% 163 B 0.2kB/s 00:01 =20 Fetching packagesite.txz: 100% 140 KiB 143.5kB/s 00:01 =20 Processing entries: 100% custom repository update completed. 612 packages processed. All repositories are up to date. Checking integrity... done (0 conflicting) The following 74 package(s) will be affected (of 0 checked): New packages to be INSTALLED: . . . . . . [1/74] Installing qt5-linguisttools-5.15.2... [1/74] Extracting qt5-linguisttools-5.15.2: 100% . . . [74/74] Installing lxqt-0.17.0... [74/74] Extracting lxqt-0.17.0: 100% So: It worked fine. (The system has no video hardware present, so lxqt is untested but installed at this point.) FYI: at one point just lang/rust was using about 17634 MiBytes of temporary storage space. That lang/rust requires such an amount of storage space to build is not specific to poudriere builds. =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?6257373F-C0DB-41A4-BD0A-BD1628345C29>