Re: MacPorts and /opt/local on Catalina and Big Sur read only volumes
Maybe the pkg installer software looks to see if an installation is trying to mkdir in root and it automatically creates /etc/synthetic.conf with an entry. That would be quintessential Apple to do something like that. Thank you Apple, it just works. On Fri, Jun 25, 2021 at 5:20 PM Ryan Schmidt wrote: > On Jun 25, 2021, at 21:03, Tabitha McNerney wrote: > > > On a fresh Catalina or Big Sure system, if you cd to root / then sudo > then try mkdir /opt or something else such as mkdir /hello the system won't > allow it, I get this: > > > > mkdir: /hello: Read-only file system > > > > note: the MacBook I just tried this on also has FileVault enabled and > its got one of those Apple T2 chips with a touch bar > > > > How does the MacPorts Catalina or Big Sur pkg installer work around this > restriction? > > I don't know that we're doing anything. It just works. > > There is some mechanism, that I don't understand, by which the system > volume and the data volume are combined into a single presentation. > Presumably the Installer app knows that you cannot install to the system > volume, so it installs MacPorts to the data volume. > >
Re: MacPorts and /opt/local on Catalina and Big Sur read only volumes
On Jun 25, 2021, at 21:03, Tabitha McNerney wrote: > On a fresh Catalina or Big Sure system, if you cd to root / then sudo then > try mkdir /opt or something else such as mkdir /hello the system won't allow > it, I get this: > > mkdir: /hello: Read-only file system > > note: the MacBook I just tried this on also has FileVault enabled and its got > one of those Apple T2 chips with a touch bar > > How does the MacPorts Catalina or Big Sur pkg installer work around this > restriction? I don't know that we're doing anything. It just works. There is some mechanism, that I don't understand, by which the system volume and the data volume are combined into a single presentation. Presumably the Installer app knows that you cannot install to the system volume, so it installs MacPorts to the data volume.
Re: MacPorts and /opt/local on Catalina and Big Sur read only volumes
On a fresh Catalina or Big Sure system, if you cd to root / then sudo then try mkdir /opt or something else such as mkdir /hello the system won't allow it, I get this: mkdir: /hello: Read-only file system note: the MacBook I just tried this on also has FileVault enabled and its got one of those Apple T2 chips with a touch bar How does the MacPorts Catalina or Big Sur pkg installer work around this restriction? On Fri, Jun 25, 2021 at 3:26 PM Ryan Schmidt wrote: > > > On Jun 25, 2021, at 18:07, Tabitha McNerney wrote: > > > Hi all, > > > > I haven't installed a fresh MacPorts system in quite some time but will > soon be doing so on a few Macs one running Catalina and the other Big Sur. > Starting with Catalina, the root volume / is read-only so how do the > MacPorts package installers set things up such that /opt/local can remain > the default path to MacPorts for both read and write functionality on > Catalina and Big Sur? Do the MacPorts package installers make use of > Apple's new bi-directional firmlinks capability defined in > /etc/synthetic.conf as also described on this page? > > > > > https://derflounder.wordpress.com/2020/01/18/creating-root-level-directories-and-symbolic-links-on-macos-catalina/ > > > > Thank you. > > I'm not aware of MacPorts doing anything special for this. It just works? > > >
Re: MacPorts and /opt/local on Catalina and Big Sur read only volumes
On Jun 25, 2021, at 18:07, Tabitha McNerney wrote: > Hi all, > > I haven't installed a fresh MacPorts system in quite some time but will soon > be doing so on a few Macs one running Catalina and the other Big Sur. > Starting with Catalina, the root volume / is read-only so how do the MacPorts > package installers set things up such that /opt/local can remain the default > path to MacPorts for both read and write functionality on Catalina and Big > Sur? Do the MacPorts package installers make use of Apple's new > bi-directional firmlinks capability defined in /etc/synthetic.conf as also > described on this page? > > https://derflounder.wordpress.com/2020/01/18/creating-root-level-directories-and-symbolic-links-on-macos-catalina/ > > Thank you. I'm not aware of MacPorts doing anything special for this. It just works?
Re: Clean install of Big Sur and MacPorts but old Xcode
On 26/06/21 3:39 pm, Ryan Schmidt wrote: On Jun 25, 2021, at 16:39, ChrisF wrote: I've upgraded to Big Sur (11.4) using a clean install followed by a restore of all users( except MacPorts) from a Time Machine backup. I also restored apps. When I went do a clean install of MacPorts I saw that XCode was still present in Applications, had a bit of a brain fade and assumed that it had been updated like the other Apple apps, and went ahead an installed MacPorts without further ado. (I have not installed any ports yet.) So now I think I have MacPorts linked to a 10.x version of XCode. I've downloaded the latest version of XCode from the App Store, and I was just about to uninstall MacPorts when I read the first para of 2.4 of the User Guide, which suggests that I seek advice here. So, do I need to completely uninstall and reinstall MacPorts or is there an easier path to a reliable MacPorts? I would say just update Xcode and leave MacPorts and the installed ports as-is. They're probably fine. MacPorts itself doesn't record or remember what version of Xcode you used when you installed it. If you were able to install MacPorts, then MacPorts itself is fine. A small minority of individual ports do remember what SDK version was used when you built them. And even if you installed any of those ports while having the wrong version of Xcode, in many cases this problem won't affect you since in many cases you receive a binary from our server. However on macOS 11 SDK versions are changing much more rapidly than they did with macOS 10.x so even if you receive a binary from us it may still have the wrong SDK version baked in. (See for example https://trac.macports.org/ticket/62440.) This is an ongoing problem that we still need to fix in several ports (for example by making those ports not bake in an SDK at all or by making them bake in a more generic SDK such as MacOSX11.sdk (which exists for any Xcode version 12.5 or later) or MacOSX.sdk (which exists for any Xcode version of the past many years) instead of e.g. MacOSX11.0.sdk (which only exists in Xcode 12.2 and not in later or earlier versions). Thanks, Ryan. I went ahead and installed and tested a few ports and all is fine so far. Cheers Chris F
MacPorts and /opt/local on Catalina and Big Sur read only volumes
Hi all, I haven't installed a fresh MacPorts system in quite some time but will soon be doing so on a few Macs one running Catalina and the other Big Sur. Starting with Catalina, the root volume / is read-only so how do the MacPorts package installers set things up such that /opt/local can remain the default path to MacPorts for both read and write functionality on Catalina and Big Sur? Do the MacPorts package installers make use of Apple's new bi-directional firmlinks capability defined in /etc/synthetic.conf as also described on this page? https://derflounder.wordpress.com/2020/01/18/creating-root-level-directories-and-symbolic-links-on-macos-catalina/ Thank you. -TM
Re: Why don't p5-* ports mark their dependencies?
On Jun 12, 2021, at 13:07, Bill Cole wrote: > On 2021-06-12 at 12:55:24 UTC-0400 (Sat, 12 Jun 2021 09:55:24 -0700) > Ken Cunningham is rumored to have said: > >> macports recommended perl is still 5.28 > > Which has been unsupported upstream for just over a year. The point Ken was making is that we select a specific perl (python, php, etc.) version to be the default, both in the portgroups and in default variants of individual ports. The version that is selected is typically the latest stable version at the time the selection is made. Indeed we could and should select a newer version for perl by now, but changing the selection takes effort, so someone will have to expend the effort to make that happen. Typically it has been Mojca who has done this work for previous versions, and she has begun the process of adding p5.32 modules and will presumably move on to p5.34 modules after that, and perhaps after that on to changing the default. >> $ port info perl5 >> perl5 @5.28.3 (lang) >> Sub-ports:perl5.16, perl5.18, perl5.20, perl5.22, perl5.24, >> perl5.26, perl5.28, perl5.30, perl5.32 >> Variants: perl5_26, [+]perl5_28, perl5_30 > > Odd that perl5.32 is a sub-port but perl5_32 isn't a variant. It's not odd, in that nothing in MacPorts gets done until someone does it. Nobody has yet added a perl5_32 variant, therefore none exists. The p5.32 module ports were just added en masse to MacPorts some days ago (some days after you wrote your message). There are so many of them that it will still take many days before the automated build system is finished building them. Until that's done, there's little point to offer a variant for that perl version for the perl5 port. > Someone could make a full-time+ job of maintaining just the Perl packages in > MacPorts. Or indeed any other sufficiently large subset of ports. Many of our maintainers do spend a great deal of time maintaining a great many ports, for which I thank them! :)
Re: Why don't p5-* ports mark their dependencies?
On Jun 12, 2021, at 12:39, Kastus Shchuka wrote: >> sudo port upgrade --enforce-variants git -perl5_28 +perl5_30 > > Thank you, that worked and allowed me to uninstall all p5.28 modules. > > What puzzles me still, why port info shows that git depends on perl 5.28 > modules: > > $ port info git > git @2.32.0 (devel) > Variants: [+]credential_osxkeychain, [+]diff_highlight, [+]doc, > gitweb, [+]pcre, perl5_26, [+]perl5_28, > perl5_30, python, svn, universal > > Description: Git is a fast, scalable, distributed open source > version control system focusing on speed and > efficiency. > Homepage: https://git-scm.com/ > > Extract Dependencies: xz > Library Dependencies: perl5.28, curl, zlib, openssl, expat, libiconv, pcre2 > Runtime Dependencies: p5.28-authen-sasl, p5.28-error, p5.28-net-smtp-ssl, > p5.28-term-readkey, p5.28-cgi, rsync > Platforms:darwin > License: GPL-2 and LGPL-2.1+ > Maintainers: Email: ciserl...@macports.org, GitHub: ci42 > Policy: openmaintainer > $ port installed and git > The following ports are currently installed: > git @2.31.1_2+credential_osxkeychain+diff_highlight+doc+pcre+perl5_30 > git @2.32.0_0+credential_osxkeychain+diff_highlight+doc+pcre+perl5_30 > (active) Because git, with its default perl5_28 variant, does depend on p5.28 modules. "port info" does not take into account the variants you have selected when installing the port. Rather, it shows you the info of the port with its default variants. If you want to see the info with a different set of variants you can specify them, e.g. "port info git +perl5_30"
Re: Warning: invalid universal_archs configured (should contain at least 2 archs)
On Jun 16, 2021, at 03:17, André-John Mas wrote: > I have recently started getting the following warning: > > "Warning: invalid universal_archs configured (should contain at least 2 > archs)" > > I have looked through the FAQ, a web search and what might seem to be > relevant documentation, but I am not sure how to resolve this? Edit macports.conf and set universal_archs to a value that is two or more valid architectures for your OS version, or comment that line out (by putting a # in front of it) to let MacPorts do so by default. > My operating environment: > > - 2019 16" MacBook Pro (Intel processor) > - macOS 11.4 > - MacPorts 2.7.1 > > What I have done: > > - Run `sudo port platform`, which gives: > > Warning: invalid universal_archs configured (should contain at least 2 archs) > Platform: darwin 20 i386 > > - Run `sudo port -d platform`, which gives: > > Warning: invalid universal_archs configured (should contain at least 2 archs) > DEBUG: Copying /Users/ajmas/Library/Preferences/com.apple.dt.Xcode.plist to > /opt/local/var/macports/home/Library/Preferences > Platform: darwin 20 i386 > > - Tried modifying `/opt/local/etc/macports/macports.conf` adding the > following, but no change in behaviour: > > build_arch arm64 x86_64 Setting build_arch to more than one architecture is invalid. Set it to the single architecture that you want to build for when not building universal, i.e. x86_64. > universal_archs arm64 x86_64 This is the correct setting for universal_archs on your OS version. Having it set to this value should prevent the warning you see from appearing.
Re: Clean install of Big Sur and MacPorts but old Xcode
On Jun 25, 2021, at 16:39, ChrisF wrote: > I've upgraded to Big Sur (11.4) using a clean install followed by a restore > of all users( except MacPorts) from a Time Machine backup. I also restored > apps. > > When I went do a clean install of MacPorts I saw that XCode was still present > in Applications, had a bit of a brain fade and assumed that it had been > updated like the other Apple apps, and went ahead an installed MacPorts > without further ado. (I have not installed any ports yet.) > > So now I think I have MacPorts linked to a 10.x version of XCode. I've > downloaded the latest version of XCode from the App Store, and I was just > about to uninstall MacPorts when I read the first para of 2.4 of the User > Guide, which suggests that I seek advice here. > > So, do I need to completely uninstall and reinstall MacPorts or is there an > easier path to a reliable MacPorts? > I would say just update Xcode and leave MacPorts and the installed ports as-is. They're probably fine. MacPorts itself doesn't record or remember what version of Xcode you used when you installed it. If you were able to install MacPorts, then MacPorts itself is fine. A small minority of individual ports do remember what SDK version was used when you built them. And even if you installed any of those ports while having the wrong version of Xcode, in many cases this problem won't affect you since in many cases you receive a binary from our server. However on macOS 11 SDK versions are changing much more rapidly than they did with macOS 10.x so even if you receive a binary from us it may still have the wrong SDK version baked in. (See for example https://trac.macports.org/ticket/62440.) This is an ongoing problem that we still need to fix in several ports (for example by making those ports not bake in an SDK at all or by making them bake in a more generic SDK such as MacOSX11.sdk (which exists for any Xcode version 12.5 or later) or MacOSX.sdk (which exists for any Xcode version of the past many years) instead of e.g. MacOSX11.0.sdk (which only exists in Xcode 12.2 and not in later or earlier versions).
Clean install of Big Sur and MacPorts but old Xcode
I've upgraded to Big Sur (11.4) using a clean install followed by a restore of all users( except MacPorts) from a Time Machine backup. I also restored apps. When I went do a clean install of MacPorts I saw that XCode was still present in Applications, had a bit of a brain fade and assumed that it had been updated like the other Apple apps, and went ahead an installed MacPorts without further ado. (I have not installed any ports yet.) So now I think I have MacPorts linked to a 10.x version of XCode. I've downloaded the latest version of XCode from the App Store, and I was just about to uninstall MacPorts when I read the first para of 2.4 of the User Guide, which suggests that I seek advice here. So, do I need to completely uninstall and reinstall MacPorts or is there an easier path to a reliable MacPorts?
