Re: port diagnose and xcode

[xplora]

I forgot to ad, the reason, at a unix level, the Finder alias just just another 
boring file, not the intended alias. This is similar to how Windows shortcuts 
look on Macs, where they come through as a .lnk file that the Mac doesn’t 
understand.

-- 
Richard Smith
xpl...@wak.co.nz




> On 14/03/2022, at 09:43, xpl...@wak.co.nz wrote:
> 
> Is it a Mac Alias, or a unix ln ? (i.e. the former is created with a 
> drag-n-drop of the App holding down the Command & Option keys, while the 
> former is created with the command ln -s /path/to/app lnfile, and that is a 
> lowercase L, not an uppercase i). MacPorts will work better with the latter 
> ln alias, not the former finder created alias.
> 
> -- 
> Richard Smith
> xpl...@wak.co.nz 
> 
> 
> 
> 
>> On 14/03/2022, at 06:41, James Secan > > wrote:
>> 
>> I do have the full Xcode package installed (8.2.1) on the El Capitan system, 
>> although I have it as an alias in the Applications directory (on a smallish 
>> SSD) linking to the actual Xcode files on an internal HD because it requires 
>> a lot of disk real estate and I never use Xcode.  Would that confuse port 
>> diagnose?  (I just checked, and if I click on the Xcode alias it works just 
>> as one would expect, so the alias linkage is OK.)
>> 
>> Jim
>> 3222 NE 89th St
>> Seattle, WA 98115
>> (206) 430-0109
>> 
>>> On Mar 12, 2022, at 6:42 PM, Ryan Schmidt >> > wrote:
>>> 
>>> On Mar 10, 2022, at 18:40, James Secan wrote:
>>> 
 In working my way through my recent “phantom ports” issue I ran the 
 command “port diagnose” and was more than a bit surprised by the output 
 line:
 
 Error: currently installed version of Xcode, none, is not supported by 
 MacPorts.
 
 followed by a list of the version supported under my version of macOS (El 
 Capitan, in this case).  Where is port getting this information?  I have 
 Xcode 8.2.0 installed, and none of my attempts to install ports have run 
 into any trouble related to Xcode not being installed.  I ran "pkgutil -v 
 --pkg-info=com.apple.pkg.CLTools_Executables” which shows that I have 
 8.2.0 installed, and the appropriate MacOSX.sdk files are in 
 /Library/Developer/CommandLineTools/SDKs.  I also tried this on my test 
 Catalina system, with the same result.
 
 Is something wrong with my ports setup?
>>> 
>>> 
>>> Both com.apple.pkg.CLTools_Executables and 
>>> /Library/Developer/CommandLineTools/SDKs are related to the Xcode command 
>>> line tools, which are separate from Xcode. So I guess you have the Xcode 
>>> command line tools installed but do not have Xcode installed. For many 
>>> ports, this is fine. For those where it is not, they should tell you to 
>>> install Xcode.
>>> 
>> 
> 

2.7.1 -> 2.7.2 OK

[Dave Horsfall]

Smooth as the proverbial baby's bottom on an oldish MacBook Pro, High 
Sierra 10.13.6; well done, all.

I'm quite taken by the progress bar on "cmake"; it keeps changing its 
mind, just like a MacOS upgrade does :-)

-- Dave

Re: port diagnose and xcode

[xplora]

Is it a Mac Alias, or a unix ln ? (i.e. the former is created with a 
drag-n-drop of the App holding down the Command & Option keys, while the former 
is created with the command ln -s /path/to/app lnfile, and that is a lowercase 
L, not an uppercase i). MacPorts will work better with the latter ln alias, not 
the former finder created alias.

-- 
Richard Smith
xpl...@wak.co.nz




> On 14/03/2022, at 06:41, James Secan  wrote:
> 
> I do have the full Xcode package installed (8.2.1) on the El Capitan system, 
> although I have it as an alias in the Applications directory (on a smallish 
> SSD) linking to the actual Xcode files on an internal HD because it requires 
> a lot of disk real estate and I never use Xcode.  Would that confuse port 
> diagnose?  (I just checked, and if I click on the Xcode alias it works just 
> as one would expect, so the alias linkage is OK.)
> 
> Jim
> 3222 NE 89th St
> Seattle, WA 98115
> (206) 430-0109
> 
>> On Mar 12, 2022, at 6:42 PM, Ryan Schmidt  wrote:
>> 
>> On Mar 10, 2022, at 18:40, James Secan wrote:
>> 
>>> In working my way through my recent “phantom ports” issue I ran the command 
>>> “port diagnose” and was more than a bit surprised by the output line:
>>> 
>>> Error: currently installed version of Xcode, none, is not supported by 
>>> MacPorts.
>>> 
>>> followed by a list of the version supported under my version of macOS (El 
>>> Capitan, in this case).  Where is port getting this information?  I have 
>>> Xcode 8.2.0 installed, and none of my attempts to install ports have run 
>>> into any trouble related to Xcode not being installed.  I ran "pkgutil -v 
>>> --pkg-info=com.apple.pkg.CLTools_Executables” which shows that I have 8.2.0 
>>> installed, and the appropriate MacOSX.sdk files are in 
>>> /Library/Developer/CommandLineTools/SDKs.  I also tried this on my test 
>>> Catalina system, with the same result.
>>> 
>>> Is something wrong with my ports setup?
>> 
>> 
>> Both com.apple.pkg.CLTools_Executables and 
>> /Library/Developer/CommandLineTools/SDKs are related to the Xcode command 
>> line tools, which are separate from Xcode. So I guess you have the Xcode 
>> command line tools installed but do not have Xcode installed. For many 
>> ports, this is fine. For those where it is not, they should tell you to 
>> install Xcode.
>> 
> 

Re: 2.7.1 -> 2.7.2 OK

[Ryan Schmidt]

(resending from correct address)

On Mar 13, 2022, at 16:34, Dave Horsfall wrote:

> Smooth as the proverbial baby's bottom on an oldish MacBook Pro, High 
> Sierra 10.13.6; well done, all.
> 
> I'm quite taken by the progress bar on "cmake"; it keeps changing its 
> mind, just like a MacOS upgrade does :-)

The most common way that you might see a port build progress bar not behave 
correctly is if you are using the universal variant and the port uses the 
muniversal portgroup. In that case, you'll see the progress for building one 
architecture, and then the progress bar will reset and show you the progress of 
building the next architecture, etc. Other than that it should be pretty 
accurate, provided that the port's build system provides accurate progress 
information.

Re: port diagnose and xcode

[James Secan]

I do have the full Xcode package installed (8.2.1) on the El Capitan system, 
although I have it as an alias in the Applications directory (on a smallish 
SSD) linking to the actual Xcode files on an internal HD because it requires a 
lot of disk real estate and I never use Xcode.  Would that confuse port 
diagnose?  (I just checked, and if I click on the Xcode alias it works just as 
one would expect, so the alias linkage is OK.)

Jim
3222 NE 89th St
Seattle, WA 98115
(206) 430-0109

> On Mar 12, 2022, at 6:42 PM, Ryan Schmidt  wrote:
> 
> On Mar 10, 2022, at 18:40, James Secan wrote:
> 
>> In working my way through my recent “phantom ports” issue I ran the command 
>> “port diagnose” and was more than a bit surprised by the output line:
>> 
>> Error: currently installed version of Xcode, none, is not supported by 
>> MacPorts.
>> 
>> followed by a list of the version supported under my version of macOS (El 
>> Capitan, in this case).  Where is port getting this information?  I have 
>> Xcode 8.2.0 installed, and none of my attempts to install ports have run 
>> into any trouble related to Xcode not being installed.  I ran "pkgutil -v 
>> --pkg-info=com.apple.pkg.CLTools_Executables” which shows that I have 8.2.0 
>> installed, and the appropriate MacOSX.sdk files are in 
>> /Library/Developer/CommandLineTools/SDKs.  I also tried this on my test 
>> Catalina system, with the same result.
>> 
>> Is something wrong with my ports setup?
> 
> 
> Both com.apple.pkg.CLTools_Executables and 
> /Library/Developer/CommandLineTools/SDKs are related to the Xcode command 
> line tools, which are separate from Xcode. So I guess you have the Xcode 
> command line tools installed but do not have Xcode installed. For many ports, 
> this is fine. For those where it is not, they should tell you to install 
> Xcode.
> 

Re: code signing and the future of MacPorts

[Rainer Müller]

Hello,

here is an older concept from 2016 I had written for gdb/lldb as Apple began to 
require code-signing for debuggers. This applies to more actions by now, but 
with the same requirements. The replies are also relevant and discuss 
alternatives.

https://lists.macports.org/pipermail/macports-dev/2016-September/033518.html

I still think adding a local private key to the trust store for code-signing at 
install/activation time is the only option. I do not see that code-signing 
binary archives created on the buildbots would be a feasible approach. This 
would essentially turn MacPorts into a binary-only distribution. Most parts are 
not ready for that and features like rev-upgrade rely on local rebuilds.

Rainer