Re: Timing of MacPorts Support for New macOS Versions
I’m curious if you’ve revisited the NDA recently, since a skim of the verbiage makes it seem to me that discussing the new OSes should be OK, assuming we don’t review it or post screenshots. Fromhttps://developer.apple.com/support/terms/apple-developer-program-license-agreement/#ADPLA9.1: > Further, Apple agrees that You will not be bound by the foregoing confidentiality terms with regard to technical information about pre-release Apple Software and services disclosed by Apple at WWDC (Apple’s Worldwide Developers Conference), except that You may not post screenshots of, write public reviews of, or redistribute any pre-release Apple Software, Apple Services or hardware. IANAL and all, but this clause is fairly new and if you haven’t re-evaluated that policy for a while it might be worth doing so again. That seems like a badly-written clause to me because there are at least two ways you can parse it, and it greatly changes the meaning. But in any case, I think it's important to point out that we are not attempting to give anyone advice about which actions do or don't violate their NDA. If you have an agreement with Apple, it's your responsibility to ensure that you are keeping your side of it. The statements in the documentation and links to them in ticket comments are meant to be (a) a courtesy reminder that pre-release OS versions tend to be under NDA, since users sometimes forget this; and (b) a way to find out about project members that are permitted to see any information that is not allowed to be posted publicly. But again, it's up to the person who signed the NDA to determine which information that is. If the docs are not making this sufficiently clear, please feel free to propose improvements or make PRs. - Josh
Re: Timing of MacPorts Support for New macOS Versions
I’m curious if you’ve revisited the NDA recently, since a skim of the verbiage makes it seem to me that discussing the new OSes should be OK, assuming we don’t review it or post screenshots. From https://developer.apple.com/support/terms/apple-developer-program-license-agreement/#ADPLA9.1: > Further, Apple agrees that You will not be bound by the foregoing > confidentiality terms with regard to technical information about pre-release > Apple Software and services disclosed by Apple at WWDC (Apple’s Worldwide > Developers Conference), except that You may not post screenshots of, write > public reviews of, or redistribute any pre-release Apple Software, Apple > Services or hardware. IANAL and all, but this clause is fairly new and if you haven’t re-evaluated that policy for a while it might be worth doing so again. Saagar Jha > On Sep 21, 2023, at 01:36, Ryan Schmidt wrote: > > On Sep 21, 2023, at 00:26, Bryan Jones wrote: >> >> Dear MacPorts: >> >> I write to propose a policy change: a MacPorts release for a new macOS major >> version should be publicly available by the time Apple publishes the final >> Release Candidate version of macOS. >> >> Rationale: MacPorts is an annual problem for me. I’m a Mac developer who >> needs to install beta versions of macOS for testing my apps. But once I do >> that, I can’t use MacPorts to build dependencies. Even if I install the >> macOS betas on a clean partition, I *need* MacPorts to re-build those >> dependencies (or I have to switch back to an older partition and copy the >> files manually into /opt/, etc.) >> >> The lag between the release of a new major macOS version and the release of >> a supported MacPorts version should be eliminated. MacPorts is a key part of >> the development environment and each year it essentially goes AWOL just when >> developers need it most: when we’re updating apps to support the new macOS >> release! No one expects MacPorts to be ready when the first beta comes out. >> But there are five months between the first beta and the release of macOS, >> which seems like enough time to at least have an “RC” version of MacPorts >> ready for developers. >> >> Thank you. > > Hi Brian. There are a number of pieces to supporting a new macOS version in > MacPorts. I didn't quite follow the problem you were reporting (you said you > "can't use MacPorts to build dependencies" but didn't say why) so I'm not > 100% sure which of these pieces you're talking about, so let me say some > things which may or may not already be obvious to you and you can reply to > whichever of these you're concerned about. > > You should be able to install MacPorts on macOS Sonoma right now, as you > could at any time since the first beta was released. There is no MacPorts > installer package for Sonoma yet so you would have to build it from source. > Instructions are in the documentation. You can try both building the current > version, 2.8.1, and the latest code in the git master. > > You can then test whether MacPorts works on Sonoma. I don't think we've > received any reports of it not working, but if it doesn't work, and you know > the fix, you can submit a pull request. If you don't know the fix and want to > report it somewhere, then the issue is that pre-release versions of macOS are > made available to you under an NDA, so you shouldn't file a public bug > report, but should discuss the bug privately with others who have agreed to > that NDA. The list of those people is in the wiki. Maybe one of them can fix > the problem. > > Eventually, once we believe MacPorts works on Sonoma, hopefully not long > after the public release of Sonoma, Josh will create an installer package. If > MacPorts 2.8.1 works on Sonoma, he'll make an installer package of 2.8.1 for > Sonoma; otherwise, fixes will have to be committed to macports-base first and > then he'll release MacPorts 2.8.2 for all OS versions. Making the Sonoma > installer package would require that Josh have access to a machine that can > run Sonoma. I don't know if he has that. > > There are some server-side components to new macOS version support as well. > The master build server generates portindexes for each OS version. I already > added macOS 14 to that list two months ago, so portindexes for Sonoma have > been available for awhile. Had I not done that, you would still be able to > use MacPorts on Sonoma, you would just be generating the portindex locally, > which due to the large number of ports we now have in our collection can take > several dozen minutes. > > I need to set up build machines for Sonoma on x86_64 and arm64. Until I do > that, installing any port will build it from source on your system. It > typically takes several weeks to do the initial builds of all ports on a new > macOS version. Of course, many of those builds might fail, depending on what > Apple changed in the new OS. It will take time for any interested members of
Re: [unable to compile and link C++ code with g++ 12.3]
On Sep 20, 2023, at 11:57, Maxim Abalenkov wrote: > > I’m unable to run the ‘xcodebuild —version’. It complains: > > xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer > directory '/Library/Developer/CommandLineTools' is a command line tools > instance Use xcode-select to select Xcode rather than the command line tools.
Re: Timing of MacPorts Support for New macOS Versions
On Sep 21, 2023, at 00:26, Bryan Jones wrote: > > Dear MacPorts: > > I write to propose a policy change: a MacPorts release for a new macOS major > version should be publicly available by the time Apple publishes the final > Release Candidate version of macOS. > > Rationale: MacPorts is an annual problem for me. I’m a Mac developer who > needs to install beta versions of macOS for testing my apps. But once I do > that, I can’t use MacPorts to build dependencies. Even if I install the macOS > betas on a clean partition, I *need* MacPorts to re-build those dependencies > (or I have to switch back to an older partition and copy the files manually > into /opt/, etc.) > > The lag between the release of a new major macOS version and the release of a > supported MacPorts version should be eliminated. MacPorts is a key part of > the development environment and each year it essentially goes AWOL just when > developers need it most: when we’re updating apps to support the new macOS > release! No one expects MacPorts to be ready when the first beta comes out. > But there are five months between the first beta and the release of macOS, > which seems like enough time to at least have an “RC” version of MacPorts > ready for developers. > > Thank you. Hi Brian. There are a number of pieces to supporting a new macOS version in MacPorts. I didn't quite follow the problem you were reporting (you said you "can't use MacPorts to build dependencies" but didn't say why) so I'm not 100% sure which of these pieces you're talking about, so let me say some things which may or may not already be obvious to you and you can reply to whichever of these you're concerned about. You should be able to install MacPorts on macOS Sonoma right now, as you could at any time since the first beta was released. There is no MacPorts installer package for Sonoma yet so you would have to build it from source. Instructions are in the documentation. You can try both building the current version, 2.8.1, and the latest code in the git master. You can then test whether MacPorts works on Sonoma. I don't think we've received any reports of it not working, but if it doesn't work, and you know the fix, you can submit a pull request. If you don't know the fix and want to report it somewhere, then the issue is that pre-release versions of macOS are made available to you under an NDA, so you shouldn't file a public bug report, but should discuss the bug privately with others who have agreed to that NDA. The list of those people is in the wiki. Maybe one of them can fix the problem. Eventually, once we believe MacPorts works on Sonoma, hopefully not long after the public release of Sonoma, Josh will create an installer package. If MacPorts 2.8.1 works on Sonoma, he'll make an installer package of 2.8.1 for Sonoma; otherwise, fixes will have to be committed to macports-base first and then he'll release MacPorts 2.8.2 for all OS versions. Making the Sonoma installer package would require that Josh have access to a machine that can run Sonoma. I don't know if he has that. There are some server-side components to new macOS version support as well. The master build server generates portindexes for each OS version. I already added macOS 14 to that list two months ago, so portindexes for Sonoma have been available for awhile. Had I not done that, you would still be able to use MacPorts on Sonoma, you would just be generating the portindex locally, which due to the large number of ports we now have in our collection can take several dozen minutes. I need to set up build machines for Sonoma on x86_64 and arm64. Until I do that, installing any port will build it from source on your system. It typically takes several weeks to do the initial builds of all ports on a new macOS version. Of course, many of those builds might fail, depending on what Apple changed in the new OS. It will take time for any interested members of the community to notice, investigate, and fix such problems. For arm64, we have only one Apple Silicon Mac mini donated to us by Mac Stadium that switches between macOS 11, 12, and 13, and the disk is full; there is no room to add macOS 14. I could eliminate the macOS 11 environment and replace it with macOS 14. Or I could ask Mac Stadium if there is a way to swap our machine for one with a bigger disk. Or I could follow up with another party who has offered MacPorts the use of another Apple Silicon Mac mini. For x86_64, I don't have any hardware that can officially run Sonoma (or Ventura). The hardware I have that runs Ventura unofficially may run Sonoma unofficially as well, but it will depend on the OpenCore Legacy Patcher project releasing a Sonoma-compatible version which they anticipate will happen at an unspecified time later this year. Or I would have to get a supported Mac, like a 2018 Mac mini. If I did that, I would probably use it for Ventura builds as well. Possibly, either
