Re: Forcing python39 on M1

2021-03-13 Thread Todd Doucet
Without intending to criticize any individual effort, I nevertheless 
respectfully suggest that something is less than ideal from a design & system 
standpoint, and I offer this because I think macports generally tries to get 
these high-level decisions architectural decisions right.

I think at core it is the assumption that to build successfully means, kind of, 
that it works.  This is much less true for complicated libraries, and 
more-or-less not true at all for libraries in languages like python, which 
rightly or wrongly push errors out to runtime instead of link time, or better 
yet, compile time.

In other words, that a python library like scipy "builds" is a nice first step, 
but means little by itself.  Python programmers know that that regression tests 
are not just a nice-to-have feature, but essential in their world.

Let us take the current scenario.  The Scipy library is (or was) broken on M1, 
and there is abundant discussion there about what the issue is and what the 
fixes might be, and people are implementing workarounds and redesigns, and what 
have you.

The problem, I respectfully suggest, is that somehow this gets all filtered out 
by the macports process and what you end up with is a "green" port that does 
not work.  And not because anybody is not doing, you say, what they are 
supposed to.  Because, apparently, a port maintainer is "not required" to run 
the regression test.

You might come to a different conclusion about what is desirable or practical 
for this, but I think you will agree that a well-known problem getting 
translated, by macports process, to a broken build that is advertised as 
working indicates that something is not quite right, and perhaps a tweak to the 
process could be considered.  And this is for something that is known not to 
work upstream.  If you see what I mean.

Thanks.



> On Mar 13, 2021, at 10:38, Todd Doucet wrote:
> 
> > At some point I might try to determine whether I can get a useful python3 
> > setup using Macports, but it is time-consuming and the status pages do not 
> > help, as the comments indicate.
> > 
> > When I tried a few weeks ago, I could install either py38 or py39, and that 
> > is fine if I want to write "hello world".  But to be useful, I need 
> > libraries like matplotlib, pandas, and and scipy.
> > 
> > But these packages were all available too, and marked happy green in the 
> > summary page.
> > 
> > But they do not actually work.  For example, scipy will quickly crash if 
> > you do most anything with it.
> > 
> > The cause is well understood upstream on the scipy site.  The bug is not 
> > caused by Macports.
> > 
> > But, really, it is hard for me to understand how these packages get a happy 
> > green label attached when all the build system, or the port maintainer, has 
> > to do is run the package-supplied regression test to see if it works.  And 
> > it does not.
> > 
> > As a user, it seems time-consuming and wasteful to install packages that do 
> > not work but claim to.  And it seems just too odd to file a bug report that 
> > essentially asks the port maintainer to run the regression test.
> > 
> > Maybe this all works now--I do not have the time to deal with it.  But 
> > perhaps my recent experience and frustration could be useful to others.
> > 
> > Here is what I presently do:  use the stock python from macOS and install 
> > local version of the libraries, then run all my code using the "arch 
> > -x86_64", which runs everything in x86 translation.  It actually works for 
> > everything I do and is only a bit slower than it would be otherwise (but 
> > still faster than my old x86).
> > 
> > It would be better to have a native arm64 version of the python stuff.  My 
> > understanding is that it is possible to cobble one together, and people 
> > have done that.  (Maybe the fratboys at brew have done that, not sure, I 
> > cannot bring myself to use brew.)
> > 
> > Eventually the upstream problems will be fixed and eventually there will be 
> > a macports version of it.  Until then, it would be useful to not report 
> > things working when they are not.
> 
> I understand this is frustrating.
> 
> Apple Silicon is a new platform, and macOS 11 is a new operating system. 
> Problems are bound to arise due to both. Each problem needs to be 
> investigated and fixed individually. File bug reports with upstream if it is 
> an upstream problem (i.e. if the software installs but doesn't work right). 
> File bug reports with us if it is our problem (i.e. if we need to update to a 
> new upstream version to fix a problem, or if upstream has fixed the problem 
&g

Re: Forcing python39 on M1

2021-03-13 Thread Todd Doucet
To be super-clear, the problems I am describing all relate to the M1 version of 
the python libraries.

> At some point I might try to determine whether I can get a useful python3 
> setup using Macports, but it is time-consuming and the status pages do not 
> help, as the comments indicate.
> 
> When I tried a few weeks ago, I could install either py38 or py39, and that 
> is fine if I want to write "hello world".  But to be useful, I need libraries 
> like matplotlib, pandas, and and scipy.
> 
> But these packages were all available too, and marked happy green in the 
> summary page.
> 
> But they do not actually work.  For example, scipy will quickly crash if you 
> do most anything with it.
> 
> The cause is well understood upstream on the scipy site.  The bug is not 
> caused by Macports.
> 
> But, really, it is hard for me to understand how these packages get a happy 
> green label attached when all the build system, or the port maintainer, has 
> to do is run the package-supplied regression test to see if it works.  And it 
> does not.
> 
> As a user, it seems time-consuming and wasteful to install packages that do 
> not work but claim to.  And it seems just too odd to file a bug report that 
> essentially asks the port maintainer to run the regression test.
> 
> Maybe this all works now--I do not have the time to deal with it.  But 
> perhaps my recent experience and frustration could be useful to others.
> 
> Here is what I presently do:  use the stock python from macOS and install 
> local version of the libraries, then run all my code using the "arch 
> -x86_64", which runs everything in x86 translation.  It actually works for 
> everything I do and is only a bit slower than it would be otherwise (but 
> still faster than my old x86).
> 
> It would be better to have a native arm64 version of the python stuff.  My 
> understanding is that it is possible to cobble one together, and people have 
> done that.  (Maybe the fratboys at brew have done that, not sure, I cannot 
> bring myself to use brew.)
> 
> Eventually the upstream problems will be fixed and eventually there will be a 
> macports version of it.  Until then, it would be useful to not report things 
> working when they are not.
> 
> 
>> *Sigh*.  The ports.macports.org site has not been getting updates since Feb 
>> 20.  See recent threads.  Yes, this is *usually* reliable.  Not this month.
>> 
>> 
>> On Sat, Mar 13, 2021 at 8:23 AM Ken Cunningham 
>>  wrote:
>>> > Having heard that python39 is the only one (so far) to compile natively 
>>> > on M1, I’m trying to force the python ports I use to python39
>>> 
>>> Hello Peter,
>>> 
>>> FYI, an arm64 version of python38 appears to be available:
>>> 
>>> http://packages.macports.org/python38/python38-3.8.8_0.darwin_20.arm64.tbz2
>>> 
>>> and is “green” on the ports review page:
>>> 
>>> https://ports.macports.org/port/python38/summary
>>> 
>>> 
>>> The ports.macports.org page can be misleading at times, unfortunately, as 
>>> it will show “green” if the port has been blocked from building even if it 
>>> can’t be built, which is no doubt confusing to people at times and there is 
>>> (I believe) a ticket about that somewhere.
>>> 
>>> The packages.macports.org site is pretty reliable, although to be 100% 
>>> certain, you do need to actually install the port and examine it with 
>>> “file” or “arch” or similar.
>>> 
>>> And the fact that the arm64 python38 exists doesn’t necessarily mean a 
>>> universal python38 exists for x86_64/arm64 or can be built. It might or 
>>> might not.
>>> 
>>> So there are some caveats to the presence of the python38 file there on 
>>> packages, but it is there.
>>> 
>>> Best,
>>> 
>>> Ken
> 


Re: Forcing python39 on M1

2021-03-13 Thread Todd Doucet
At some point I might try to determine whether I can get a useful python3 setup 
using Macports, but it is time-consuming and the status pages do not help, as 
the comments indicate.

When I tried a few weeks ago, I could install either py38 or py39, and that is 
fine if I want to write "hello world".  But to be useful, I need libraries like 
matplotlib, pandas, and and scipy.

But these packages were all available too, and marked happy green in the 
summary page.

But they do not actually work.  For example, scipy will quickly crash if you do 
most anything with it.

The cause is well understood upstream on the scipy site.  The bug is not caused 
by Macports.

But, really, it is hard for me to understand how these packages get a happy 
green label attached when all the build system, or the port maintainer, has to 
do is run the package-supplied regression test to see if it works.  And it does 
not.

As a user, it seems time-consuming and wasteful to install packages that do not 
work but claim to.  And it seems just too odd to file a bug report that 
essentially asks the port maintainer to run the regression test.

Maybe this all works now--I do not have the time to deal with it.  But perhaps 
my recent experience and frustration could be useful to others.

Here is what I presently do:  use the stock python from macOS and install local 
version of the libraries, then run all my code using the "arch -x86_64", which 
runs everything in x86 translation.  It actually works for everything I do and 
is only a bit slower than it would be otherwise (but still faster than my old 
x86).

It would be better to have a native arm64 version of the python stuff.  My 
understanding is that it is possible to cobble one together, and people have 
done that.  (Maybe the fratboys at brew have done that, not sure, I cannot 
bring myself to use brew.)

Eventually the upstream problems will be fixed and eventually there will be a 
macports version of it.  Until then, it would be useful to not report things 
working when they are not.


> *Sigh*.  The ports.macports.org site has not been getting updates since Feb 
> 20.  See recent threads.  Yes, this is *usually* reliable.  Not this month.
> 
> 
> On Sat, Mar 13, 2021 at 8:23 AM Ken Cunningham 
>  wrote:
>> > Having heard that python39 is the only one (so far) to compile natively on 
>> > M1, I’m trying to force the python ports I use to python39
>> 
>> Hello Peter,
>> 
>> FYI, an arm64 version of python38 appears to be available:
>> 
>> http://packages.macports.org/python38/python38-3.8.8_0.darwin_20.arm64.tbz2
>> 
>> and is “green” on the ports review page:
>> 
>> https://ports.macports.org/port/python38/summary
>> 
>> 
>> The ports.macports.org page can be misleading at times, unfortunately, as it 
>> will show “green” if the port has been blocked from building even if it 
>> can’t be built, which is no doubt confusing to people at times and there is 
>> (I believe) a ticket about that somewhere.
>> 
>> The packages.macports.org site is pretty reliable, although to be 100% 
>> certain, you do need to actually install the port and examine it with “file” 
>> or “arch” or similar.
>> 
>> And the fact that the arm64 python38 exists doesn’t necessarily mean a 
>> universal python38 exists for x86_64/arm64 or can be built. It might or 
>> might not.
>> 
>> So there are some caveats to the presence of the python38 file there on 
>> packages, but it is there.
>> 
>> Best,
>> 
>> Ken


Re: Build servers offline due to failed SSD

2021-03-07 Thread Todd Doucet
I think one can only get so far with purely qualitative analysis of the 
characteristics of SSDs and HDs and then the end of that analysis will be 
one-size-fits all advice, for example "recommended" or "not recommended" for 
servers.

Surely the answer might vary depending on the particular server usage pattern, 
the need for performance, the cost of routine maintenance (swapping out aging 
drives or SSDs), the cost of the devices themselves, etc.

It seems to me that a given server operator can tell how long a particular SSD 
is likely to last.  They do not fail randomly, at least not very much.  The 
fail when they are "used up" and you can figure out well in advance, usually, 
when you will need to swap the old ones out of service.

HDs fail also, obviously, but tend not to be so predictable about it.  Whether 
it makes sense for a given server to use an SSD really does depend on the 
numbers.  All drives will fail.  All drives will need to be rotated out of 
service.  It is a matter of cost, convenience, and performance.

The only caveat I can think of is that there might be an issue of malicious 
use--a server with SSDs might be vulnerable to a wear attack, depending on the 
server services offered, I suppose.




> To emphasize again, the reason SSDs aren’t recommended for servers is because 
> servers—by definition—see much heavier service, and these read/write cycles 
> are used up more quickly.
> 
> For personal use in a PC, or such, SSDs are proving to be the dream they were 
> promised to be.
> 
> As mentioned, given time, the technology will overcome this limitation for 
> use in servers and these comments will be just so much past history.
> 
> Dave C.
> 
> - - - 
> 
> > The “on/off” switches in SSD’s are fragile and essentially break after too 
> > many read/write cycles.  As pointed out, it’s a get what you pay for world 
> > and cheap SSD’s are just that… cheap.   The expensive ones are more 
> > reliable because they actually make available only a portion of their total 
> > capacity, reserving the rest as replacements for such failures.  
> > Intelligent software within the firmware manages this so that the end user 
> > experiences a much longer device lifespan.
> > 
> > There’s lots of technical documentation for such.  Google knows.
> > 
> > Regards,
> > 
> > 
> >>> On Mar 7, 2021, at 18:15, Michael A. Leonetti via macports-users 
> >>>  wrote:
> >> I’d really love to know more about what you’re saying here. Up until I 
> >> just read what you wrote, I thought SSDs were the savior of HDDs.
> >> Michael A. Leonetti
> >> As warm as green tea
> >>> 3/7/21 午後5:26、Dave Horsfall のメール:
> >>> On Sat, 6 Mar 2021, Dave C via macports-users wrote:
>  Isn’t SSD a bad choice for server duty? No server farms use them, 
>  apparently due to short lifespan.
> >>> If you knew how SSDs worked then you wouldn't use them at all without 
> >>> many backups.  Give me spinning rust any day...
> >>> -- Dave
> 
> 


Re: Build servers going offline due to inclement weather

2021-02-19 Thread Todd Doucet
Many new users, like me, might not know what the consequences of the build 
servers being down are, exactly.  I am speculating that this does not mean that 
MacPorts is not available generally, but instead that if I ask for a port it 
might build it on my machine instead of pulling a pre-built binary for me.

> Hello Ryan,
> 
> On 19/02/2021 16.38, Ryan Schmidt wrote:
> > Build servers remain offline. Since my last update, power was out here for 
> > 32 hours but is back on now. Power is restored in most of Austin but the 
> > Texas electric grid operator still asks us to conserve electricity.
> 
> Thank you for the update. I hope you are well and stay warm!
> 
> Rainer
> 


Re: Build servers going offline due to inclement weather

2021-02-16 Thread Todd Doucet


> The rest of the contiguous United States shares either the east or west power 
> grid, but most of Texas uses its own separate grid managed by ERCOT. 
> Unfortunately right now most of Texas is very cold and everybody is using 
> more electricity running their heaters. At the same time, the weather has 
> knocked out some power plants. And since our grid is separate, there's no way 
> to get surplus power from other states. Texas was not designed with such cold 
> temperatures in mind.

I read that Texas did import electrical power from Mexico a week or so ago.  I 
guess they threw the jumper cables over that "big, beautiful wall".

My understanding is that, also, there is a connection to the East US grid, but 
using it might subject Texas to dreaded Federal regulation of the power 
industry there.

Stay warm.



Re: wxMaxima crashes under Big Sur 11.2.1

2021-02-14 Thread Todd Doucet
Correction:

  port install depof:whatever

(This is a new machine and I have not yet turned off the obnoxious autospelling 
correction.

> 
> 
>> 
>> On 14 Feb2021, at 2:12 AM, Ryan Schmidt  wrote:
>>> 
>>> 
>>> On Feb 13, 2021, at 11:33, Murray Eisenberg wrote:
>>> 
 Without complaint, wxMaxima @20.04.0_0 installed (after maxima 
 @5.43.2_12+xmaxima and gnuplot 
 @5.4.1_2+aquaterm+luaterm+pangocairo+qt+wxwidgets+x11) under macOS Big Sur 
 11.2.1 using MacPorts 2.6.99 and Xcode CLT 12.4.
 
 Although the command-line maxima works, if I try to open 
 /Applications/MacPorts/wxMaxima.app, the app immediately crashes.
 
 Perhaps this is related to https://trac.macports.org/ticket/61933. 
 
 But exactly what log file should I provide? I examined the 
 wxMaxima_2021002-13-.crash file in ~/Library/Logs/DiagnosticReports 
 but find no “rootless” line there.
>>> 
>>> I'm not sure what "rootless8" mentioned in that ticket refers to. Maybe it 
>>> is the name of the user's computer. Probably irrelevant.
>>> 
>>> If you want to provide your crash log, you can do that, but it sounds like 
>>> we already figured out what the problem is.
>>> 
>>> Per the mailing list thread mentioned in that ticket, I think the problem 
>>> is an install_name_tool bug in Xcode 12.2. I don't know if the problem 
>>> remains in Xcode 12.4. If you did not build wxWidgets from source, you can 
>>> try doing that and see if it fixes the problem. Let us know whether or not 
>>> that fixed it. If 12.4 didn't fix the bug, then a workaround is given in 
>>> the mailing list thread linked in that ticket.
>> 
>> (1) There is no port “wxWidgets”, only:
>> 
>>   wxWidgets-3.0
>>   wxWidgets-common
>>   wxWidgets_select
>> 
>> Which one(s) do I need to build from source?
>> 
>> (2) And what about gnuplot, which will break if I uninstall wxWidgets-3.0?
>> 
>> (3) Is the build-from-source command “port -s [portname]? 
> 
> I am just a MacPorts user, not a maintainer or anything, but I can tell you 
> what I recently learned about building from source.  I also looked in the 
> Guide and found nothing, but "man ports" mentioned source mode (among many, 
> many, many other things).
> 
> Here is something to be aware of, though.  If you simply do
> 
>   port -s install whatever
> 
> then MacPorts wants to build all the prerequisites from source too, unless it 
> happens to be installed already.  This is usually not what you want, because 
> some of those prerequisites take a long time to build, and really, why do 
> that instead of just the binary install for those?
> 
> What I eventually figured out was that I could first tell MacPorts to install 
> the prerequisites, explicitly, and then after that do the source install of 
> just what I am after.   The incantation I used for the former was
> 
>   port install depot:whatever
> 
> (Put sudo before the installs, of course.)
> 
> Hope this helps.
> 
> 
> 
>> 
>> I’m not finding this documented at https://guide.macports.org.
>> 
>> 
>> ---
>> Murray Eisenberg murrayeisenb...@gmail.com
>> 503 King Farm Blvd #101 
>> Rockville, MD 20850-6667 Mobile (413)-427-5334
> 


Re: wxMaxima crashes under Big Sur 11.2.1

2021-02-14 Thread Todd Doucet


> 
> On 14 Feb2021, at 2:12 AM, Ryan Schmidt  wrote:
>> 
>> 
>> On Feb 13, 2021, at 11:33, Murray Eisenberg wrote:
>> 
>>> Without complaint, wxMaxima @20.04.0_0 installed (after maxima 
>>> @5.43.2_12+xmaxima and gnuplot 
>>> @5.4.1_2+aquaterm+luaterm+pangocairo+qt+wxwidgets+x11) under macOS Big Sur 
>>> 11.2.1 using MacPorts 2.6.99 and Xcode CLT 12.4.
>>> 
>>> Although the command-line maxima works, if I try to open 
>>> /Applications/MacPorts/wxMaxima.app, the app immediately crashes.
>>> 
>>> Perhaps this is related to https://trac.macports.org/ticket/61933. 
>>> 
>>> But exactly what log file should I provide? I examined the 
>>> wxMaxima_2021002-13-.crash file in ~/Library/Logs/DiagnosticReports but 
>>> find no “rootless” line there.
>> 
>> I'm not sure what "rootless8" mentioned in that ticket refers to. Maybe it 
>> is the name of the user's computer. Probably irrelevant.
>> 
>> If you want to provide your crash log, you can do that, but it sounds like 
>> we already figured out what the problem is.
>> 
>> Per the mailing list thread mentioned in that ticket, I think the problem is 
>> an install_name_tool bug in Xcode 12.2. I don't know if the problem remains 
>> in Xcode 12.4. If you did not build wxWidgets from source, you can try doing 
>> that and see if it fixes the problem. Let us know whether or not that fixed 
>> it. If 12.4 didn't fix the bug, then a workaround is given in the mailing 
>> list thread linked in that ticket.
> 
> (1) There is no port “wxWidgets”, only:
> 
>   wxWidgets-3.0
>   wxWidgets-common
>   wxWidgets_select
> 
> Which one(s) do I need to build from source?
> 
> (2) And what about gnuplot, which will break if I uninstall wxWidgets-3.0?
> 
> (3) Is the build-from-source command “port -s [portname]? 

I am just a MacPorts user, not a maintainer or anything, but I can tell you 
what I recently learned about building from source.  I also looked in the Guide 
and found nothing, but "man ports" mentioned source mode (among many, many, 
many other things).

Here is something to be aware of, though.  If you simply do

  port -s install whatever

then MacPorts wants to build all the prerequisites from source too, unless it 
happens to be installed already.  This is usually not what you want, because 
some of those prerequisites take a long time to build, and really, why do that 
instead of just the binary install for those?

What I eventually figured out was that I could first tell MacPorts to install 
the prerequisites, explicitly, and then after that do the source install of 
just what I am after.   The incantation I used for the former was

  port install depot:whatever

(Put sudo before the installs, of course.)

Hope this helps.



> 
> I’m not finding this documented at https://guide.macports.org.
> 
> 
> ---
> Murray Eisenberg murrayeisenb...@gmail.com
> 503 King Farm Blvd #101 
> Rockville, MD 20850-6667 Mobile (413)-427-5334


Re: macOS 11.1 SDK does not appear to be installed

2021-02-11 Thread Todd Doucet


> 
> 
> On Feb 11, 2021, at 19:32, Todd Doucet wrote:
> 
> > So I guess there is still a bit of a mystery.  If I get some time I will 
> > try to build the new MacPorts from source and see if there is still a 
> > warning.  (I presently do not rely on MacPorts for mainline code and it is 
> > very easy for me to nuke it and do a quick reinstall.)
> 
> No need to nuke anything. You can build MacPorts master and install it over 
> the top of what you currently have. It will not affect your installed ports 
> either.

Cool.  I built MacPorts from GitHub and installed it, and port says it is 
version 2.6.99, and it no longer issues the warning about the CLTs.

Thanks.

Re: macOS 11.1 SDK does not appear to be installed

2021-02-11 Thread Todd Doucet


> On Feb 11, 2021, at 18:47, Todd Doucet wrote:
> 
> > You can see that there are two SDKs here, including the one that you 
> > expect, and the name MacOSX.sdk links to it too:
> > 
> > % ls -l /Library/Developer/CommandLineTools/SDKs
> > 
> > lrwxr-xr-x  1 root  wheel   14 Feb  6 16:23 MacOSX.sdk -> MacOSX11.1.sdk
> > drwxr-xr-x  8 root  wheel  256 Jul  9  2020 MacOSX10.15.sdk
> > drwxr-xr-x  7 root  wheel  224 Nov 30 07:33 MacOSX11.1.sdk
> 
> This looks normal to me. As far as I can tell, it is normal for the Xcode 
> 12.4 command line tools installer to give you both the 10.15 SDK and the 11.1 
> SDK. Apple has changed their mind a few times about whether Xcode and the CLT 
> provide only the latest OS SDK or both the latest OS SDK and the previous OS 
> SDK, but right now they appear to be providing both latest and previous.
> 
> 
> > I am not sure which package receipt specifically is important, but I have 
> > these:
> > 
> > % pkgutil --pkgs | grep -i cltool
> > com.apple.pkg.CLTools_Executables
> > com.apple.pkg.CLTools_SDK_macOS110
> > com.apple.pkg.CLTools_SDK_macOS1015
> > com.apple.pkg.CLTools_macOS_SDK
> 
> The first one is the one that MacPorts checks for (on 10.9 and later; on 
> earlier OS versions it has different names) and the one that we believe 
> Apple's software update checks for. You can verify which version of the CLT 
> you have by running:
> 
> pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version
> 
> 
> > This machine is about one week old.  One of the very first things I did was 
> > type 'git' to the shell, which caused macOS to offer to install the Command 
> > Line Tools.  I said yes, and was happily using git and the compilers and 
> > other tools for several days.
> > 
> > Then later, when I decided to install MacPorts, I read that Xcode is 
> > required so I installed that.  When I ran Xcode once, Xcode itself offered 
> > to install Command Line Tools (or maybe it was during the installation 
> > process--not sure).  Anyway, I said yes again and still had command line 
> > tools.  And Xcode version 12.4 (12D4e) too.
> 
> I do not believe that Xcode offered you to install the CLT; I have never 
> known Xcode to do that. Xcode does ask you about installing additional 
> components when it is first opened, and if you do not allow it, Xcode quits, 
> so you probably allowed it. But "additional components" and "command line 
> tools" are unrelated things.

Yes, you are correct.  I remembered my interpretation of what it said, but not 
what it said ("additional components") until you reminded me!

> 
> > My conclusion is that I probably have what I am supposed to have.  If you 
> > think otherwise, please let me know.
> 
> You stated you are running macOS 11.1, and you appear to have the 11.1 SDK. 
> Therefore I cannot explain why you are seeing the warning.

I am looking at the About This Mac box and it says Version 11.1.  And for 
completeness:

% pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version

version: 12.4.0.0.1.1610135815



So I guess there is still a bit of a mystery.  If I get some time I will try to 
build the new MacPorts from source and see if there is still a warning.  (I 
presently do not rely on MacPorts for mainline code and it is very easy for me 
to nuke it and do a quick reinstall.)


> 
> 
> > I assume that MacPorts in the new version will also recognize that I have 
> > what I need and the spurious warning would go away.
> 
> I assume that as well. If you'd like to confirm it, you could install the 
> latest unreleased MacPorts from source.
> 
> 
> On Feb 11, 2021, at 19:07, Todd Doucet wrote:
> 
> > It is a little odd that one of the package receipts is not named
> > 
> > com.apple.pkg.CLTools_SDK_macOS111
> > 
> > but instead is named
> > 
> >   com.apple.pkg.CLTools_SDK_macOS110
> 
> I do not have enough experience with macOS Big Sur to be able to say whether 
> that is normal or unusual.
> 
> 


Re: macOS 11.1 SDK does not appear to be installed

2021-02-11 Thread Todd Doucet
It is a little odd that one of the package receipts is not named

com.apple.pkg.CLTools_SDK_macOS111

but instead is named

  com.apple.pkg.CLTools_SDK_macOS110



> 
>> MacPorts 2.6.4 was released before Apple released macOS 11.1. We did not yet 
>> know how the version numbers of macOS and the macOS SDK would progress under 
>> macOS 11. We made a guess based on what had happened in macOS 10.15 and 
>> earlier, and we guessed wrong. We have corrected the code already and it 
>> will be included in a future version of MacPorts.
>> 
>> macOS 11 users can ignore this warning until that future version of MacPorts 
>> is released, with the caveat that it is still important to have both Xcode 
>> and the command line tools installed, so users should manually verify that 
>> this is the case, not just once but periodically, especially after an OS 
>> update, since macOS has had a bug which deletes the CLT receipt, thus 
>> preventing the CLT from showing up in software update. Also do make sure 
>> that you have a matched set of Xcode and the command line tools -- and I 
>> think that perhaps you do not, possibly due to the aforementioned macOS bug. 
>> See https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt
>> 
>> The warning is occurring because you are using a version of macOS (11.1) 
>> with a version of Xcode and/or the command line tools that does not contain 
>> an SDK of that version. You say you are using Xcode 12.4 but Xcode 12.4 does 
>> contain the 11.1 SDK so if the port you are seeing the message with is using 
>> Xcode, then you should not see this warning.
>> 
>> Most ports do not use Xcode; they use the command line tools. So it is 
>> possible that you are using a version of the command line tools that does 
>> not contain the 11.1 SDK. You can check what SDK it contains by listing the 
>> contents of the directory /Library/Developer/CommandLineTools/SDKs. Assuming 
>> that MacOSX11.1.sdk is not in that directory, you should probably reinstall 
>> the Xcode 12.4 version of the command line tools per the link above (or by 
>> downloading from the Apple developer web site) so that you have a matched 
>> set, which will probably eliminate the warning.
> 
> I believe my machine has command-line tools and SDK which match the Xcode 
> version, and has a package receipt for them also.  I could be wrong, but I 
> will show you why I believe that, and the details of my case might be useful 
> to you because there is perhaps a little twist which I will get to.
> 
> You can see that there are two SDKs here, including the one that you expect, 
> and the name MacOSX.sdk links to it too:
> 
> % ls -l /Library/Developer/CommandLineTools/SDKs

> 

> lrwxr-xr-x  1 root  wheel   14 Feb  6 16:23 *MacOSX.sdk* -> MacOSX11.1.sdk

> drwxr-xr-x  8 root  wheel  256 Jul  9  2020 *MacOSX10.15.sdk*

> drwxr-xr-x  7 root  wheel  224 Nov 30 07:33 *MacOSX11.1.sdk*

> 
> I am not sure which package receipt specifically is important, but I have 
> these:
> 
> % pkgutil --pkgs | grep -i cltool

> com.apple.pkg.CLTools_Executables

> com.apple.pkg.CLTools_SDK_macOS110

> com.apple.pkg.CLTools_SDK_macOS1015

> com.apple.pkg.CLTools_macOS_SDK

> 
> This machine is about one week old.  One of the very first things I did was 
> type 'git' to the shell, which caused macOS to offer to install the Command 
> Line Tools.  I said yes, and was happily using git and the compilers and 
> other tools for several days.
> 
> Then later, when I decided to install MacPorts, I read that Xcode is required 
> so I installed that.  When I ran Xcode once, Xcode itself offered to install 
> Command Line Tools (or maybe it was during the installation process--not 
> sure).  Anyway, I said yes again and still had command line tools.  And Xcode 
> version 12.4 (12D4e) too.
> 
> So my guess is that the initial install of CLT, kicked off by trying to run 
> git, was maybe the 10.15 you see.  Then Xcode itself put CLT version 11.1, or 
> so it would seem.
> 
> My conclusion is that I probably have what I am supposed to have.  If you 
> think otherwise, please let me know.  I assume that MacPorts in the new 
> version will also recognize that I have what I need and the spurious warning 
> would go away.
> 
> Thanks for your detailed response, and I hope that these details of a typical 
> new use case might be useful to you in figuring out what MacOS looks like in 
> a non-upgrade situation.
> 
> 
> 
> 
> 
>> If you update to macOS 11.2, the warning will come back, since there is no 
>> version of Xcode or the command line tools that contains the 11.2 SDK.
>> 
>> If you wish, you could build MacPorts base from our git repository to 
>> receive the fix early.
>> 
>> 
> 


Re: macOS 11.1 SDK does not appear to be installed

2021-02-11 Thread Todd Doucet

> MacPorts 2.6.4 was released before Apple released macOS 11.1. We did not yet 
> know how the version numbers of macOS and the macOS SDK would progress under 
> macOS 11. We made a guess based on what had happened in macOS 10.15 and 
> earlier, and we guessed wrong. We have corrected the code already and it will 
> be included in a future version of MacPorts.
> 
> macOS 11 users can ignore this warning until that future version of MacPorts 
> is released, with the caveat that it is still important to have both Xcode 
> and the command line tools installed, so users should manually verify that 
> this is the case, not just once but periodically, especially after an OS 
> update, since macOS has had a bug which deletes the CLT receipt, thus 
> preventing the CLT from showing up in software update. Also do make sure that 
> you have a matched set of Xcode and the command line tools -- and I think 
> that perhaps you do not, possibly due to the aforementioned macOS bug. See 
> https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt
> 
> The warning is occurring because you are using a version of macOS (11.1) with 
> a version of Xcode and/or the command line tools that does not contain an SDK 
> of that version. You say you are using Xcode 12.4 but Xcode 12.4 does contain 
> the 11.1 SDK so if the port you are seeing the message with is using Xcode, 
> then you should not see this warning.
> 
> Most ports do not use Xcode; they use the command line tools. So it is 
> possible that you are using a version of the command line tools that does not 
> contain the 11.1 SDK. You can check what SDK it contains by listing the 
> contents of the directory /Library/Developer/CommandLineTools/SDKs. Assuming 
> that MacOSX11.1.sdk is not in that directory, you should probably reinstall 
> the Xcode 12.4 version of the command line tools per the link above (or by 
> downloading from the Apple developer web site) so that you have a matched 
> set, which will probably eliminate the warning.

I believe my machine has command-line tools and SDK which match the Xcode 
version, and has a package receipt for them also.  I could be wrong, but I will 
show you why I believe that, and the details of my case might be useful to you 
because there is perhaps a little twist which I will get to.

You can see that there are two SDKs here, including the one that you expect, 
and the name MacOSX.sdk links to it too:

% ls -l /Library/Developer/CommandLineTools/SDKs



lrwxr-xr-x  1 root  wheel   14 Feb  6 16:23 *MacOSX.sdk* -> MacOSX11.1.sdk

drwxr-xr-x  8 root  wheel  256 Jul  9  2020 *MacOSX10.15.sdk*

drwxr-xr-x  7 root  wheel  224 Nov 30 07:33 *MacOSX11.1.sdk*


I am not sure which package receipt specifically is important, but I have these:

% pkgutil --pkgs | grep -i cltool

com.apple.pkg.CLTools_Executables

com.apple.pkg.CLTools_SDK_macOS110

com.apple.pkg.CLTools_SDK_macOS1015

com.apple.pkg.CLTools_macOS_SDK


This machine is about one week old.  One of the very first things I did was 
type 'git' to the shell, which caused macOS to offer to install the Command 
Line Tools.  I said yes, and was happily using git and the compilers and other 
tools for several days.

Then later, when I decided to install MacPorts, I read that Xcode is required 
so I installed that.  When I ran Xcode once, Xcode itself offered to install 
Command Line Tools (or maybe it was during the installation process--not sure). 
 Anyway, I said yes again and still had command line tools.  And Xcode version 
12.4 (12D4e) too.

So my guess is that the initial install of CLT, kicked off by trying to run 
git, was maybe the 10.15 you see.  Then Xcode itself put CLT version 11.1, or 
so it would seem.

My conclusion is that I probably have what I am supposed to have.  If you think 
otherwise, please let me know.  I assume that MacPorts in the new version will 
also recognize that I have what I need and the spurious warning would go away.

Thanks for your detailed response, and I hope that these details of a typical 
new use case might be useful to you in figuring out what MacOS looks like in a 
non-upgrade situation.





> If you update to macOS 11.2, the warning will come back, since there is no 
> version of Xcode or the command line tools that contains the 11.2 SDK.
> 
> If you wish, you could build MacPorts base from our git repository to receive 
> the fix early.
> 
> 


macOS 11.1 SDK does not appear to be installed

2021-02-11 Thread Todd Doucet
I have read everything I can about this warning, but none of it corresponds to 
exactly my situation, hence this report.

I have a brand new Mac Mini M1, and a fresh MacPorts installation.  This is not 
an upgrade--I have never had MacPorts on this machine, ever.

I definitely have both Xcode 12.4 and the Command Line Tools that Xcode wanted 
to install.  I do not know the version number of those tools because I don't 
know how to find that out.  But it is whatever Apple provided by install a few 
days ago.  I have provided all the incantations that I have seen on your web 
pages to install, verify install, accept licenses, etc.  And this is Big Sur 
11.1.

Yet I see the following message when building various ports from source: 

  Warning: The macOS 11.1 SDK does not appear to be installed. Ports may not 
build correctly.


Reading other threads and guessing a little, maybe I am supposed to ignore the 
warning.  If that is not the case, I sure do not know what I am supposed to do 
instead.

I discovered this when I started to work on figuring out why the MacPorts 
py39.scipy port does not actually work, and maybe helping to fix it.  (It fails 
scipy.test(), for example, or even segfaults if you "import scipy.signal" among 
other things.)

I actually have a handle on the problem and would like to contribute a 
solution, but really first I would like there to be no uncertainty about 
whether I have a working MacPorts system itself.

I am reporting this because I imagine that the developers would want to know if 
a brand-new installation on a brand-new computer does not actually work, or at 
the very least generates specious warnings.  I know I would want to know that.

I know that this is early days and ports themselves are expected to be broken 
for a while.  But really I think MacPorts itself is supposed to install and 
work correctly on a fresh install on a new machine.