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: > >> 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.) >
. . . [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 Fetching packagesite.txz: 100% 140 KiB 143.5kB/s 00:01 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. === 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"
