Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On 2021-May-19, at 14:17, Mark Millard wrote: > On 2021-May-19, at 10:29, Mark Millard 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=p338d8ba0f777_s5a89498d19 >> Apr 13: >> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p46fc7df8540c_s1f64f32a4c >> Apr 17: >> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p9d5f4ef1a469_s86046cf55f >> >> Built with python38: >> May 11: >> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p0c0a4f4b9148_scb07628d9e >> May 15: >> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p6ffbcd54bf8c_s91f251b2ab >> May 18: >> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p7bfc2c072607_s8d2b4b2e7c >> May 6: >> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=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
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On 2021-May-19, at 10:29, Mark Millard 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=p338d8ba0f777_s5a89498d19 > Apr 13: > http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p46fc7df8540c_s1f64f32a4c > Apr 17: > http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p9d5f4ef1a469_s86046cf55f > > Built with python38: > May 11: > http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p0c0a4f4b9148_scb07628d9e > May 15: > http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p6ffbcd54bf8c_s91f251b2ab > May 18: > http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p7bfc2c072607_s8d2b4b2e7c > May 6: > http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=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
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
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: Built with python37: Apr 20: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p338d8ba0f777_s5a89498d19 Apr 13: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p46fc7df8540c_s1f64f32a4c Apr 17: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p9d5f4ef1a469_s86046cf55f Built with python38: May 11: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p0c0a4f4b9148_scb07628d9e May 15: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p6ffbcd54bf8c_s91f251b2ab May 18: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p7bfc2c072607_s8d2b4b2e7c May 6: http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=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. === 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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
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. 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. At this point I'm stuck. Thanks for reading and your offer of help! bob prohaska ___ 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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
bob prohaska fbsd at www.zefox.net wrote on Mon May 17 23:46:38 UTC 2021 : > On Mon, May 17, 2021 at 12:28:24PM -0700, Mark Millard via freebsd-ports > wrote: > > bob prohaska fbsd at www.zefox.net wrote on > > Mon May 17 15:55:21 UTC 2021 : > > > > > The existing conflict between versions of python strikes me as more of a > > > planning problem than a software bug. It may be naive, but I don't see > > > why python37 and python38 can't use distinct names for files placed in > > > system directories. > > > > You seem to be under the impression that absent having > > any common file paths, things would just work. This > > seems unlikely. A simplified presentation of why > > follows. > > > > I'm under the impression that absence of common paths would help > reduce conflicts. True: possibly necessary, even if not sufficient. > In the case at hand it might be sufficient. I do not know: I do not have a very complete understanding of the full status of your environment after the problem. (Nor of just what specifically lead to the problem.) I do know that I do not deal with the issue in my context --but that is because I use procedures that avoid the general type of issue (tolerating any other tradeoffs involved). (I have worked via portmaster and just plain make in the past before using poudriere as well.) > > Imagine two programs: > > > > p37 that is set up for python37 > > p38 that is set up for python38 > > > > imagine that both use a library plib that is > > not internal to each but external to both. > > > > So should plib be built/present for python37? > > python38? Both? > > > > If both: it suggests building a huge set of python > > software multiple times, once per supported version > > in the range of to-be-supported python versions. (I > > do assume python versions make for some degree of > > incompatibility distinctions. It might be only only > > some version changes have that property. But such > > would not change the basic point.) > > > > It suggests that p37 (installed first) would install > its preferred version of plib. When p38 is installed, it > would test for a compatible version of plib So now p38 is required to classify all prior combinations of versions of external libraries it might use (such plib), and to put in tests for handling all the combinations. And what if p38 is installed first and p37 second? p37 must do similarly --but has no way to well classify combinations involving library versions that did not exist when it was released. One alternative in the industry is having each package fully self contained (up to the interfacong with the OS or whatever the kind of context is). The package-build builds everything required and bundles what is needed at run time all together so the package does not depend on any other packages: its installer and installation results are self sufficient (up to the "OS"). This makes other tradeoffs. There are examples that are similar in ports, some tied to bootstrapping issues. For example, building ports-mgmt/pkg builds far more internally because pkg can not depend on other ports/packages that would need pkg to already be operational to get things setup. https://github.com/freebsd/pkg/tree/master/external/ lists: blake2/ libelf/ libfetch/ liblua/ libmachista/ libucl/ linenoise/ lua/ msgpuck/ picosat/ sqlite/ uthash/ yxml/ As I understand lang/rust contains and builds its own (subset of?) some llvm version instead of depending on one of llvm10/llvm11/llvm12. Its build time and resource use may be illustrations of some of the tradeoffs in this style: its build of an llvm does no good at saving time for any other port build that involves the same vintage of llvm. > and add a new > one, with a different name, if the prior version isn't > satisfactory. Libraries already seem to have a variety of > suffixes on their names, so it appears something of the sort > is already going on. Am I completely missing the point? See notes above. > > I know, for example, python39 invalidated code in > > something I've built in a non-FreeBSD context. The > > software had to be modified to be compatible with > > both older python's and python39 (if they wanted > > to support the older versions as well going > > forward). (It was not a context of wanting to take > > advantage of new things in the newer python. But > > that kind of context is not universal.) > > Not sure I see a fundamental problem here. Python > 38 remaining useful/necessary after introduction of > 39 doesn't seem so bad. It seems the norm. How far back are the pre-supplied older versions supposed to go? On operating system A? B? C? (Likely differing choices will be made.) How many old versions continue to get bug fixes and security updates and the like? How much less effort is put into creating new versions (supposed improvements) as a consequence? To again use p37 and p38: how do they deal with the varying range of old versions on A vs. B vs. C? Some of this is or can be
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On Mon, May 17, 2021 at 12:28:24PM -0700, Mark Millard via freebsd-ports wrote: > bob prohaska fbsd at www.zefox.net wrote on > Mon May 17 15:55:21 UTC 2021 : > > > The existing conflict between versions of python strikes me as more of a > > planning problem than a software bug. It may be naive, but I don't see > > why python37 and python38 can't use distinct names for files placed in > > system directories. > > You seem to be under the impression that absent having > any common file paths, things would just work. This > seems unlikely. A simplified presentation of why > follows. > I'm under the impression that absence of common paths would help reduce conflicts. In the case at hand it might be sufficient. > Imagine two programs: > > p37 that is set up for python37 > p38 that is set up for python38 > > imagine that both use a library plib that is > not internal to each but external to both. > > So should plib be built/present for python37? > python38? Both? > > If both: it suggests building a huge set of python > software multiple times, once per supported version > in the range of to-be-supported python versions. (I > do assume python versions make for some degree of > incompatibility distinctions. It might be only only > some version changes have that property. But such > would not change the basic point.) > It suggests that p37 (installed first) would install its preferred version of plib. When p38 is installed, it would test for a compatible version of plib and add a new one, with a different name, if the prior version isn't satisfactory. Libraries already seem to have a variety of suffixes on their names, so it appears something of the sort is already going on. Am I completely missing the point? > I know, for example, python39 invalidated code in > something I've built in a non-FreeBSD context. The > software had to be modified to be compatible with > both older python's and python39 (if they wanted > to support the older versions as well going > forward). (It was not a context of wanting to take > advantage of new things in the newer python. But > that kind of context is not universal.) Not sure I see a fundamental problem here. Python 38 remaining useful/necessary after introduction of 39 doesn't seem so bad. It seems the norm. > Most ports having a separate upstream to deal with > and having a huge number of ports makes for > port-developer and upstream-developer coordination > based solutions having great difficulties overall. > Indeed, and they're getting worse over time. > No technical-content has been presented to make these > sorts of problems disappear. With the problems being > present, it is a matter of working in a way that > avoids running into the problems or with dealing with > fixing things when the problems occur. I've wondered from time to time if it's possible, even only in principle, to make the entire ports tree build in one invocation. At the moment, the answer seems to be "no". But is it "no" on first principles? > I've done both > basic styles over the years and recognize tradeoffs. > I'm happy to help someone explore one of the ways > in which poudriere can be an alternative. It is not > for me to declare how well it would end up fitting > their goals, context, preferences, and so on vs. > other alternatives overall. > I'll continue to explore poudriere. Your efforts are much appreciated, but also rather daunting. The learning curve is steep and resource requirements are high. If there's some larger point I'm missing please give a hint. Thanks for writing! bob prohaska ___ 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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
bob prohaska fbsd at www.zefox.net wrote on Mon May 17 15:55:21 UTC 2021 : > The existing conflict between versions of python strikes me as more of a > planning problem than a software bug. It may be naive, but I don't see > why python37 and python38 can't use distinct names for files placed in > system directories. You seem to be under the impression that absent having any common file paths, things would just work. This seems unlikely. A simplified presentation of why follows. Imagine two programs: p37 that is set up for python37 p38 that is set up for python38 imagine that both use a library plib that is not internal to each but external to both. So should plib be built/present for python37? python38? Both? If both: it suggests building a huge set of python software multiple times, once per supported version in the range of to-be-supported python versions. (I do assume python versions make for some degree of incompatibility distinctions. It might be only only some version changes have that property. But such would not change the basic point.) I know, for example, python39 invalidated code in something I've built in a non-FreeBSD context. The software had to be modified to be compatible with both older python's and python39 (if they wanted to support the older versions as well going forward). (It was not a context of wanting to take advantage of new things in the newer python. But that kind of context is not universal.) Most ports having a separate upstream to deal with and having a huge number of ports makes for port-developer and upstream-developer coordination based solutions having great difficulties overall. No technical-content has been presented to make these sorts of problems disappear. With the problems being present, it is a matter of working in a way that avoids running into the problems or with dealing with fixing things when the problems occur. I've done both basic styles over the years and recognize tradeoffs. I'm happy to help someone explore one of the ways in which poudriere can be an alternative. It is not for me to declare how well it would end up fitting their goals, context, preferences, and so on vs. other alternatives overall. === 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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On Mon, May 17, 2021 at 09:37:07AM -0400, George Mitchell wrote: > On 5/16/21 10:19 PM, bob prohaska wrote: > > [...] > > I'd like to see the ports system keep working as it has in the past, but > > that seemingly > > requires a kind of machine intelligence that hasn't evolved yet. Poudriere > > seems like > > a brute force approach. [...] > > You'll find quite a few remaining fans of portmaster. Occasionally it > puts you in dependency hell if you don't run "pkg check -ad" and "pkg > check -aB" often enough, but I've given up on poudriere more than once. 8-) Poudriere seems adapted to a closed-source system where the primary goal is expedient production of binary-only software. It doesn't explicitly close the source, but does discourage access. I fiddled with portmaster some time ago while trying to compile www/chromium on a Raspberry Pi3. It seemed more prone to getting stuck than a simple make -DBATCH when all the dust settled. A large fraction of stoppages were related to refusal to upgrade old ports that were already installed. Since portmaster was advertised as a way to "upgrade" existing ports that was surprising. The existing conflict between versions of python strikes me as more of a planning problem than a software bug. It may be naive, but I don't see why python37 and python38 can't use distinct names for files placed in system directories. It's rather more peculiar that deinstalling python37 does not solve the problem. Nor does deleting the offending file (link). Still, poudriere seems a huge hammer for a small tack. Thanks for reading, bob prohaska ___ 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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On 5/16/21 10:19 PM, bob prohaska wrote: [...] I'd like to see the ports system keep working as it has in the past, but that seemingly requires a kind of machine intelligence that hasn't evolved yet. Poudriere seems like a brute force approach. [...] You'll find quite a few remaining fans of portmaster. Occasionally it puts you in dependency hell if you don't run "pkg check -ad" and "pkg check -aB" often enough, but I've given up on poudriere more than once. -- George OpenPGP_signature Description: OpenPGP digital signature
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On Mon, May 17, 2021 at 04:44:04AM +, Thomas Mueller wrote: > > My question, Bob, is, if you are dissatisfied with poudriere, what do you use > for FreeBSD ports? I'm not dissatisfied, I'm overwhelmed. Usually, a simple make -DBATCH > make.log & works. hth, bob prohaska ___ 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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
> No real favorites. In emergencies I tend to pick up the telephone. > This doesn't seem like an emergency, and in any case the phone is a poor > medium for a problem like this. There are some ports under /usr/ports/irc, > if you have suggestions I could try one or more. If a phone call is useful, > my number is 530 753 2005, California PDT. The answering machine screens > calls, I pick up if I recognize the caller's message. I can return calls > anywhere in the lower 48. > It's important to remember that even if the comms delay is zero my > comprehension > delay is much greater than zero. Sometimes infinite. That's apt to either > bore or > frustrate experts. > Mark Millard is trying to give me an inkling of how poudriere works. It's a > stunningly > complex process, apparently approximating individual virtual hosts compiling > each port. > I'd like to see the ports system keep working as it has in the past, but that > seemingly > requires a kind of machine intelligence that hasn't evolved yet. Poudriere > seems like > a brute force approach. Persuading ports (and porters) to cooperate is more > efficient > if it's possible. > Thanks for reading, and any thoughts you might have! > bob prohaska I've been thinking about what to use to build FreeBSD ports, if I go ahead and build FreeBSD 13.0-STABLE or -current: portmaster, poudriere (I am reluctant), synth (seems to have fallen out of favor), or NetBSD pkgsrc. I don't like the dialog4ports, and much prefer the way NetBSD pkgsrc or Gentoo Linux portage keep the options in /etc/mk.conf or /etc/make.conf . I haven't updated FreeBSD since May 2019 because of troubles with network connectivity in releng-12 and 13 (May 2019), though that may possibly be better now. My question, Bob, is, if you are dissatisfied with poudriere, what do you use for FreeBSD ports? Tom ___ 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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On Sun, May 16, 2021 at 12:24:49PM +1000, Kubilay Kocak wrote: > On 15/05/2021 2:35 am, bob prohaska wrote: > > > > I've never used IRC, is it somehow better than this list? > > Quicker isolation of root causes over async back and forth. Happy to go over > it with you at your favourite 'real-time medium' No real favorites. In emergencies I tend to pick up the telephone. This doesn't seem like an emergency, and in any case the phone is a poor medium for a problem like this. There are some ports under /usr/ports/irc, if you have suggestions I could try one or more. If a phone call is useful, my number is 530 753 2005, California PDT. The answering machine screens calls, I pick up if I recognize the caller's message. I can return calls anywhere in the lower 48. It's important to remember that even if the comms delay is zero my comprehension delay is much greater than zero. Sometimes infinite. That's apt to either bore or frustrate experts. Mark Millard is trying to give me an inkling of how poudriere works. It's a stunningly complex process, apparently approximating individual virtual hosts compiling each port. I'd like to see the ports system keep working as it has in the past, but that seemingly requires a kind of machine intelligence that hasn't evolved yet. Poudriere seems like a brute force approach. Persuading ports (and porters) to cooperate is more efficient if it's possible. Thanks for reading, and any thoughts you might have! bob prohaska ___ 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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On 2021-May-16, at 15:33, Tatsuki Makino wrote:
> Mark Millard wrote on 2021/05/16 17:11:
>> On 2021-May-16, at 00:16, Tatsuki Makino
>> wrote:
>>
>>> poudriere jail -c -j main -m 'src=/usr/src' -v `make -C /usr/src/release/
>>> -V VERSION VERSION=\$\{REVISION:Q\}-\$\{BRANCH:Q\}`
>>>
>> Bob already does a buildworld based on /usr/src for other
>> reasons/uses than poudriere. My suggestions are targeted
>> to resusing that buildworld result instead of involving
>> doing another buildworld for poudriere. It is also biased
>> to not changing how he does that buildworld (out of scope
>> to what he was asking about). So far as I know he does
>> not use /usr/src/release to do builds. Bob's system is
>> not fast, each buildworld is time consuming.
I will note that in my context I use MAKEOBJDIRPREFIX=
to use unusual paths instead of the default /usr/obj/
paths. (I'll not get into why I choose to do this.)
Such need not be a problem for Bob's environment and I've
avoided telling Bob about my odd conventions or otherwise
involving them.
>> Would your command suggestion reuse his already-existing
>> buildworld?
>>
>
> The /usr/src/release that appeared here is just to create a version string.
> `make -C /usr/src/release/ -V VERSION
> VERSION=\$\{REVISION:Q\}-\$\{BRANCH:Q\}` will create a string exactly like
> 12.2-STABLE, no matter when /usr/src is.
Sounds good.
>> In my own use the same is true: I buildworld separately
>> before any poudriere activity (for other reasons/uses)
>> and then I reuse the buildworld that resulted for
>> also setting up poudriere later.
>>
>
> This one of mine is also a reuse of built world.
> The main idea of my buildworld, buildkernel, installkernel, and installworld
> is as follows. (There are some commands mixed in that cannot be executed
> directly.)
>
> rm -rf -- /usr/obj/{*,.[^.]*,..?*}
I use WITH_META_MODE=yes and only clear out prior builds
as-needed/on-occasion.
> git -C /usr/src/ pull && git -C /usr/src/ reset --hard && git -C /usr/src/
> clean -dfx
> cat somepatches*.diff | patch -Nt -d /usr/src/
I was avoiding getting into Bob's buildworld
installworld details. I have some minor differences
in how I operate for the above sorts of things.
(I've actually explored more than one style
with git involved, two still in use.)
> cd /usr/src/
> make buildworld && make buildkernel
> mergemaster -p
Since git, I use etcupdate instead of merge master.
> make installkernel
Sometimes a shutdown -r now is required here
because the new world would not work with the
old kernel that is still live. On rare powerpc64
or powerpc updates I've had to installworld
and shutdown -r now first (announced/documented
at the time).
> make installworld
> make delete-old delete-old-libs
Doing delete-old-libs before installing updated
ports can break things: existing installed ports
might fail to work. Some configurations might
not be able to avoid having such a port's use
attempted before updates can be made. I do
the delete-old-libs later when such might be an
issue in my context.
I normally use BATCH_DELETE_OLD_FILES=yes with
the delete-old*'s.
> mergemaster
Again, since git, I use etcupdate instead of merge
master.
> reboot
I use "shutdown -r now" instead. "man reboot" reports:
QUOTE
Normally, the shutdown(8) utility is used when the system needs to be
halted or restarted, giving users advance warning of their impending doom
and cleanly terminating specific programs.
END QUOTE
In my context it is only the "cleanly terminating
specific programs" part that leads to my making the
distinction. I've not explored the details.
Past this point in your sequence is not a type of
sequence that I've used.
> poudriere jail -u -j main# -j name is matched to above command.
> poudriere's jail -u will take care of everything from installworld to the
> /etc installation.
> For poudriere-jail, buildworld will not run without -b option.
Good to know.
> A copy of /usr/src for jail will be made, but it is required to retain the
> original source files for jail.
No such /usr/src copy is made with my sequence: /usr/src is
null mounted instead and used in the port builds that need
/usr/src/ access. Bob had indicated wanting to avoid extra
storage use that was unnecessary.
For my style of use, I'm not aware of any need for the older
/usr/src/ files in the jail at any point after updating
/usr/src/ . The same seemed to apply for Bob's context.
> And just to make things a little more interesting...
> The jail can be started with the following command.
> poudriere jail -s -j main -p default
> This jail will be logged in with the following command.
> jexec main-default-n env -i "TERM=$TERM" /usr/bin/login -f -p root
> This is where you can debug, etc. in a mostly clean environment.
I've only used -i to get in the session at the end of a
bulk build. Someday I may experiment with the above sort
of sequence. Thanks for the notes.
> If you break that environment too much,
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
Mark Millard wrote on 2021/05/16 17:11:
> On 2021-May-16, at 00:16, Tatsuki Makino
> wrote:
>
>> poudriere jail -c -j main -m 'src=/usr/src' -v `make -C /usr/src/release/ -V
>> VERSION VERSION=\$\{REVISION:Q\}-\$\{BRANCH:Q\}`
>>
> Bob already does a buildworld based on /usr/src for other
> reasons/uses than poudriere. My suggestions are targeted
> to resusing that buildworld result instead of involving
> doing another buildworld for poudriere. It is also biased
> to not changing how he does that buildworld (out of scope
> to what he was asking about). So far as I know he does
> not use /usr/src/release to do builds. Bob's system is
> not fast, each buildworld is time consuming.
>
> Would your command suggestion reuse his already-existing
> buildworld?
>
The /usr/src/release that appeared here is just to create a version string.
`make -C /usr/src/release/ -V VERSION VERSION=\$\{REVISION:Q\}-\$\{BRANCH:Q\}`
will create a string exactly like 12.2-STABLE, no matter when /usr/src is.
>
> In my own use the same is true: I buildworld separately
> before any poudriere activity (for other reasons/uses)
> and then I reuse the buildworld that resulted for
> also setting up poudriere later.
>
This one of mine is also a reuse of built world.
The main idea of my buildworld, buildkernel, installkernel, and installworld is
as follows. (There are some commands mixed in that cannot be executed directly.)
rm -rf -- /usr/obj/{*,.[^.]*,..?*}
git -C /usr/src/ pull && git -C /usr/src/ reset --hard && git -C /usr/src/
clean -dfx
cat somepatches*.diff | patch -Nt -d /usr/src/
cd /usr/src/
make buildworld && make buildkernel
mergemaster -p
make installkernel
make installworld
make delete-old delete-old-libs
mergemaster
reboot
poudriere jail -u -j main # -j name is matched to above command.
poudriere's jail -u will take care of everything from installworld to the /etc
installation.
For poudriere-jail, buildworld will not run without -b option.
A copy of /usr/src for jail will be made, but it is required to retain the
original source files for jail.
And just to make things a little more interesting...
The jail can be started with the following command.
poudriere jail -s -j main -p default
This jail will be logged in with the following command.
jexec main-default-n env -i "TERM=$TERM" /usr/bin/login -f -p root
This is where you can debug, etc. in a mostly clean environment.
If you break that environment too much, you can use the following command to
get it back to normal.
poudriere jail -k -j main -p default
# Regardless of which person's method is more efficient, I am releasing my
method in a similar topic area to let people know that there are different
types of methods.
Any jails other than -m null will be cleanly removed by poudriere jail -d, so
try different ones :)
Regards.
___
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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On 2021-May-16, at 00:16, Tatsuki Makino wrote:
> Mark Millard via freebsd-ports wrote on 2021/05/16 10:57:
>> In the form that I use poudriere I use something
>> like the following. I presume here that /usr/src
>> is populated and has the source for the system
>> involved. (I do not remember your describing its
>> status.)
> (Omitted below)
>
> I was just wondering...
> If you want to use the sources in /usr/src and collect the files in /usr/obj
> to make a jail, the following is easier.
>
> poudriere jail -c -j main -m 'src=/usr/src' -v `make -C /usr/src/release/ -V
> VERSION VERSION=\$\{REVISION:Q\}-\$\{BRANCH:Q\}`
>
> Updating it can be done with just the following.
>
> poudriere jail -u -j main
Bob already does a buildworld based on /usr/src for other
reasons/uses than poudriere. My suggestions are targeted
to resusing that buildworld result instead of involving
doing another buildworld for poudriere. It is also biased
to not changing how he does that buildworld (out of scope
to what he was asking about). So far as I know he does
not use /usr/src/release to do builds. Bob's system is
not fast, each buildworld is time consuming.
Would your command suggestion reuse his already-existing
buildworld?
In my own use the same is true: I buildworld separately
before any poudriere activity (for other reasons/uses)
and then I reuse the buildworld that resulted for
also setting up poudriere later.
In essence, the same buildworld that generates what I
boot is later also used to set up (or update) a
poudriere. In other contexts, I set up (or update) an
independent chroot directory tree first and later a
poudriere directory tree --via one buildworld used
for setting up (or updating) both.
I do not use /usr/src/release to do buildworld or
installworld activities.
As most of the systems involved for my activity are
far from fast, avoiding extra buildworlds and reusing
buildworld results saves time. It also saves storage.
(I choose to work the same way on the fast
ThreadRipper 1950X for uniformity of procedure.)
===
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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
Mark Millard via freebsd-ports wrote on 2021/05/16 10:57:
> In the form that I use poudriere I use something
> like the following. I presume here that /usr/src
> is populated and has the source for the system
> involved. (I do not remember your describing its
> status.)
(Omitted below)
I was just wondering...
If you want to use the sources in /usr/src and collect the files in /usr/obj to
make a jail, the following is easier.
poudriere jail -c -j main -m 'src=/usr/src' -v `make -C /usr/src/release/ -V
VERSION VERSION=\$\{REVISION:Q\}-\$\{BRANCH:Q\}`
Updating it can be done with just the following.
poudriere jail -u -j main
Regards.
___
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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
Something I've not asked about or otherwise referenced is if you use non-default port options for any of the ports that you build. There is: poudriere options -jmain -c -f ~root/origins/main-origins.txt or: poudriere options -jmain -C -f ~root/origins/main-origins.txt where -c vs. -C is: QUOTE -c Use 'config' target, which will always show the dialog for the given ports. -C Use 'config-conditional' target, which will only bring up the dialog on new options for the given ports. (This is the default) END QUOTE There is also: QUOTE -n Do not be recursive -r Remove port options instead of configuring them -s Show port options instead of configuring them END QUOTE See: man poudriere-options === 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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On 15/05/2021 2:35 am, bob prohaska wrote: On Fri, May 14, 2021 at 12:24:06PM +1000, Kubilay Kocak wrote: happy to help identify the root cause if you can jump on IRC (#freebsd-python @ freenode) If sorting out the conflict between python versions helps the community in general I'm willing to try. I simply use make in the ports tree, not wanting the disk and cpu overhead imposed by ports management software. But, that approach seems to be getting obsolete. I don't mind being a Luddite, but there's no profit in being the _last_ Luddite. 8-) I've never used IRC, is it somehow better than this list? Thanks for writing, bob prohaska Quicker isolation of root causes over async back and forth. Happy to go over it with you at your favourite 'real-time medium' ___ 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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On 2021-May-15, at 16:37, bob prohaska wrote: > On Fri, May 14, 2021 at 07:29:15PM -0700, Mark Millard wrote: >> bob prohaska fbsd at www.zefox.net 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. Good to know. >> 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. Good to know. > >> 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 / . [I use some of your later notes in making choices here.] poudriere works in its own world in for a builder's jail (no separate kernel involved). Otherwise it would not being making a clean build of the ports (producing packages for later installation). In the form that I use poudriere I use something like the following. I presume here that /usr/src is populated and has the source for the system involved. (I do not remember your describing its status.) First, per "man poudriere-jail" and its description of using "-m method" for method "null", the later poudriere commands are based on already having set up via something like (and picking a path for the system poudriere is to use): # cd /usr/src # make installworld DESTDIR=/usr/obj/poudriere-system DB_FROM_SRC=1 # make distrib-dirs DESTDIR=/usr/obj/poudriere-system DB_FROM_SRC=1 # make distribution DESTDIR=/usr/obj/poudriere-system DB_FROM_SRC=1 Note that this system does not have any tailoring or any pre-installed packages/ports. Having ports installed messes up poudriere's operation: no longer clean. poudriere only uses ports that it has built packages for: it installs such packages in its system, but only as needed for each port builder. (It cleans up between ports.) It does not touch your live system's packages or installed ports during the build. (I'll not list deatils for updating /usr/obj/poudriere-system as the system progresses over time. The above is initial installation. But delete-old and delete-old-libs can be involved. distrib-dirs and distribution are instead of etcupdate or the like.) As for setting up a ports binding and a jail: # poudriere ports -c -m null -M /usr/ports # poudriere jail -c -jmain -m null -M /usr/obj/poudriere-system -S /usr/src -v 14.0-CURRENT Note: the above picks the name "main" for the poudriere jail and sets up to use /usr/src and is told the context is to be 14.0-CURRENT . Neither of these commands do the build: they instead establish context for doing builds in the future. Note: the cd and 3 "DESTDIR=" lines are the kind of activity that I called a "prebuild" of the system that poudriere is to use. (So: poudriere itself is not building or installing a system.) This style avoid having another system build involved, just an install. (I avoid the complications of describing alternatives to this particular style.) > If it's particular to the > port being built please clarify. Not particular to a port, but to a poudriere jail. A poudriere jail does not have your installed packages already installed, for example. (I'll not try to list all
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On Fri, May 14, 2021 at 07:29:15PM -0700, Mark Millard wrote: > bob prohaska fbsd at www.zefox.net 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
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
bob prohaska fbsd at www.zefox.net wrote on Fri May 14 01:35:28 UTC 2021 : > On Thu, May 13, 2021 at 01:35:50PM -0700, Mark Millard wrote: > > You have apparently chosen to build/update ports via a > > technique that requires you to manage the dependencies, at > > least some of the time. (Not that when is necessarily > > obvious up front.) > > > > You give me too much credit 8-) > > > Your environment is now based on a mix of python37 and > > python 38 related materials. You are likely going to > > need to rework/rebuild/reinstall things to avoid that. > > > > Hints may come from that UPDATING that I quoted but > > things are more broken overall than what UPDATING is > > intended to cover. You might end up needing to > > uninstall a bunch of stuff until python is unused > > (or only one python is used) and then follow the > > notes if you have only python37 use and want to > > get to python38. Finally rebuild/reinstall what > > was uninstalled, based on python38 as a context. > > > Trying to deinstall both python37 and python38 didn't > suffice. Python38's reinstall fails with the same > conflict. Deleting the offending file doesn't help > If other things need to be deinstalled it's not clear > what they might be. > > > Due to how I build/install ports, I've not had to deal > > with ending up with the mix so I'm not familiar with > > the details for recovering from a messy mix. > > > > 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.) 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. Some basic questions will be: A) ZFS vs. UFS? (There are some configuration setting(s) dependent on which.) 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 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. 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. 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. 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. 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. 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
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On Fri, May 14, 2021 at 12:24:06PM +1000, Kubilay Kocak wrote: > > happy to help identify the root cause if you can jump on IRC > (#freebsd-python @ freenode) If sorting out the conflict between python versions helps the community in general I'm willing to try. I simply use make in the ports tree, not wanting the disk and cpu overhead imposed by ports management software. But, that approach seems to be getting obsolete. I don't mind being a Luddite, but there's no profit in being the _last_ Luddite. 8-) I've never used IRC, is it somehow better than this list? Thanks for writing, bob prohaska ___ 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"
Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On 14/05/2021 11:35 am, bob prohaska wrote: On Thu, May 13, 2021 at 01:35:50PM -0700, Mark Millard wrote: You have apparently chosen to build/update ports via a technique that requires you to manage the dependencies, at least some of the time. (Not that when is necessarily obvious up front.) You give me too much credit 8-) Your environment is now based on a mix of python37 and python 38 related materials. You are likely going to need to rework/rebuild/reinstall things to avoid that. Hints may come from that UPDATING that I quoted but things are more broken overall than what UPDATING is intended to cover. You might end up needing to uninstall a bunch of stuff until python is unused (or only one python is used) and then follow the notes if you have only python37 use and want to get to python38. Finally rebuild/reinstall what was uninstalled, based on python38 as a context. Trying to deinstall both python37 and python38 didn't suffice. Python38's reinstall fails with the same conflict. Deleting the offending file doesn't help If other things need to be deinstalled it's not clear what they might be. Due to how I build/install ports, I've not had to deal with ending up with the mix so I'm not familiar with the details for recovering from a messy mix. 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. Many thanks for patient counsel! bob prohaska ___ 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" happy to help identify the root cause if you can jump on IRC (#freebsd-python @ freenode) ___ 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"
