Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
The university won’t let me lag that long. But I never upgrade when a major version just comes out. Most people will want Rosetta for a little while at least. That will change with time of course But I’m concerned that there might be compiling problems. Michael Barton School of Human Evolution Change School of Complex Adaptive System Science Center for Social Dynamics & Complexity Arizona State University ...Sent from my iPad > On Sep 25, 2023, at 5:44 AM, Nicklas Larsson wrote: > > I think that would be wise. > > Personally I am very careful to update OS in general, just jumped to 13 from > 12 the other day. Lagging about one year. > > >> On 25 Sep 2023, at 14:38, Michael Barton wrote: >> >> Does this mean I should hole off upgrading to Sonoma for a bit? >> >> Michael Barton >> School of Human Evolution Change >> School of Complex Adaptive System Science >> Center for Social Dynamics & Complexity >> Arizona State University >> >> ...Sent from my iPad >> On Sep 25, 2023, at 4:12 AM, Nicklas Larsson wrote: >>> >>> On 25 Sep 2023, at 12:30, Gregor Hintner wrote: Niklas, thank you on the committed exploration of this issue, also independently verifying my own findings. >>> >>> I’m afraid this is a problem that will be a major issue in the time to >>> come, that we will have to deal with. Thank you for reporting! >>> >>> From a layperson perspective it does seem reasonable to me that macOS wanted apps to initialize through a conventionally made and signed binary, and would appreciate if your team would consider that. I hope Apple would offer free signing certificates, or even developer program memberships for open source projects. >>> >>> It will be difficult to make a “conventionally made” Mac application of >>> GRASS, but a "fully working as expected" and signed one is possible. We are >>> fully aware that the present solution isn’t optimal, but it has worked. So >>> far. Now, apparently we will have to invest the time and sweat for making >>> it right. >>> >>> By chance, did you check whether FreeCAD, the second app I encountered with an ARM release that caused the Rosetta dialog, has the same problem? >>> >>> Running `/Applications/FreeCAD.app/Contents/MacOS/FreeCAD` from Terminal >>> does work as well, so there is the same problem behind I guess. FreeCAD is >>> however code signed (so that’s not issue causing the Rosetta problem). >>> >>> >>> Nicklas >>> >>> >>> Their team never replied to my inquiry on X, but perhaps we could help get them started to fix this too. Cheers, Gregor >> On 2023-09-25, at 11:59 AM, Nicklas Larsson wrote: > > Gregor, > > I now had the opportunity to test on macOS 14 RC and I can confirm this > issue. The problem seems related somehow to being initialised by a script. > > I __did___ manage to start GRASS via Terminal: > > > 1. Run `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` > > 2. System will complain… > > 3. Go to 'System Settings > Privacy & Security > Security' > > 4. In the settings I enabled GRASS to be allowed > > 5. From now on `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` will > work > > > This is only a workaround, I will look into how this can be solved > properly. Maybe we have to make a binary that does the job the script now > does (that used to be the case some time ago). We should also invest some > time in creating a code signed app as well. > > > Nicklas > > > >> On 22 Sep 2023, at 11:01, Nicklas Larsson via grass-dev >> wrote: >> >> Gregor, thanks very much for the info! At least it ruled some things >> out, but I have still no idea what is causing this and it’s very >> difficult do the needed poking around without a similar setup (macOS 14 >> without Rosetta installed). I’ll have to ponder on this, if this really >> is caused by some change by macOS 14, a solution must be found sooner >> rather than later. >> >> An alternative way to install GRASS with native architecture for ARM is >> with MacPorts [1]. It does, however, involve some Terminal-batics! If >> you are in need for other GIS software like QGIS in particular, MacPorts >> is currently, in my experience, a most solid solution with available >> GRASS plugin (as there is no native official QGIS.app bundle for ARM). >> >> To be continued… >> >> Cheers, >> Nicklas >> >> [1] >> https://urldefense.com/v3/__https://grasswiki.osgeo.org/wiki/Compiling_on_macOS_using_MacPorts__;!!IKRxdwAv5BmarQ!dgVkpS9cztwvGGv-hsTRc5Vc0o6QJ28v5wxcBt3iZpXBnC-G0_E1qUasCdMvWceVKSW2z3TMfHwuQ7CtEnL2MQ$ >> >> >> On 20 Sep 2023, at 16:47,
Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
I think that would be wise. Personally I am very careful to update OS in general, just jumped to 13 from 12 the other day. Lagging about one year. > On 25 Sep 2023, at 14:38, Michael Barton wrote: > > Does this mean I should hole off upgrading to Sonoma for a bit? > > Michael Barton > School of Human Evolution Change > School of Complex Adaptive System Science > Center for Social Dynamics & Complexity > Arizona State University > > ...Sent from my iPad > >> On Sep 25, 2023, at 4:12 AM, Nicklas Larsson wrote: >> >> >>> On 25 Sep 2023, at 12:30, Gregor Hintner wrote: >>> >>> Niklas, >>> >>> >>> thank you on the committed exploration of this issue, also independently >>> verifying my own findings. >>> >> >> I’m afraid this is a problem that will be a major issue in the time to come, >> that we will have to deal with. Thank you for reporting! >> >> >>> From a layperson perspective it does seem reasonable to me that macOS >>> wanted apps to initialize through a conventionally made and signed binary, >>> and would appreciate if your team would consider that. I hope Apple would >>> offer free signing certificates, or even developer program memberships for >>> open source projects. >>> >> >> It will be difficult to make a “conventionally made” Mac application of >> GRASS, but a "fully working as expected" and signed one is possible. We are >> fully aware that the present solution isn’t optimal, but it has worked. So >> far. Now, apparently we will have to invest the time and sweat for making it >> right. >> >> >>> By chance, did you check whether FreeCAD, the second app I encountered with >>> an ARM release that caused the Rosetta dialog, has the same problem? >>> >> >> Running `/Applications/FreeCAD.app/Contents/MacOS/FreeCAD` from Terminal >> does work as well, so there is the same problem behind I guess. FreeCAD is >> however code signed (so that’s not issue causing the Rosetta problem). >> >> >> Nicklas >> >> >> >>> Their team never replied to my inquiry on X, but perhaps we could help get >>> them started to fix this too. >>> >>> >>> Cheers, >>> Gregor >>> >>> > On 2023-09-25, at 11:59 AM, Nicklas Larsson wrote: Gregor, I now had the opportunity to test on macOS 14 RC and I can confirm this issue. The problem seems related somehow to being initialised by a script. I __did___ manage to start GRASS via Terminal: 1. Run `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` 2. System will complain… 3. Go to 'System Settings > Privacy & Security > Security' 4. In the settings I enabled GRASS to be allowed 5. From now on `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` will work This is only a workaround, I will look into how this can be solved properly. Maybe we have to make a binary that does the job the script now does (that used to be the case some time ago). We should also invest some time in creating a code signed app as well. Nicklas > On 22 Sep 2023, at 11:01, Nicklas Larsson via grass-dev > wrote: > > Gregor, thanks very much for the info! At least it ruled some things out, > but I have still no idea what is causing this and it’s very difficult do > the needed poking around without a similar setup (macOS 14 without > Rosetta installed). I’ll have to ponder on this, if this really is caused > by some change by macOS 14, a solution must be found sooner rather than > later. > > An alternative way to install GRASS with native architecture for ARM is > with MacPorts [1]. It does, however, involve some Terminal-batics! If you > are in need for other GIS software like QGIS in particular, MacPorts is > currently, in my experience, a most solid solution with available GRASS > plugin (as there is no native official QGIS.app bundle for ARM). > > To be continued… > > Cheers, > Nicklas > > [1] > https://urldefense.com/v3/__https://grasswiki.osgeo.org/wiki/Compiling_on_macOS_using_MacPorts__;!!IKRxdwAv5BmarQ!dgVkpS9cztwvGGv-hsTRc5Vc0o6QJ28v5wxcBt3iZpXBnC-G0_E1qUasCdMvWceVKSW2z3TMfHwuQ7CtEnL2MQ$ > > > >>> On 20 Sep 2023, at 16:47, Gregor Hintner >>> wrote: >> >> Niklas, >> >> >> please find my answers below: >> >>> `file /usr/bin/osascript` >> >> evidently still a universal binary, see this screenshot >> >> >>> `osascript -i` >> >> worked with no noticeable issues >> >>> /Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh >> >> produced the unverified developer warning as expected. Logically I could >> and should probably override this, but with 10 years since my last time >> coding, and having never learned the basics of UNIX, I would prefer to >>
Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
Does this mean I should hole off upgrading to Sonoma for a bit? Michael Barton School of Human Evolution Change School of Complex Adaptive System Science Center for Social Dynamics & Complexity Arizona State University ...Sent from my iPad > On Sep 25, 2023, at 4:12 AM, Nicklas Larsson wrote: > > >> On 25 Sep 2023, at 12:30, Gregor Hintner wrote: >> >> Niklas, >> >> >> thank you on the committed exploration of this issue, also independently >> verifying my own findings. >> > > I’m afraid this is a problem that will be a major issue in the time to come, > that we will have to deal with. Thank you for reporting! > > >> From a layperson perspective it does seem reasonable to me that macOS wanted >> apps to initialize through a conventionally made and signed binary, and >> would appreciate if your team would consider that. I hope Apple would offer >> free signing certificates, or even developer program memberships for open >> source projects. >> > > It will be difficult to make a “conventionally made” Mac application of > GRASS, but a "fully working as expected" and signed one is possible. We are > fully aware that the present solution isn’t optimal, but it has worked. So > far. Now, apparently we will have to invest the time and sweat for making it > right. > > >> By chance, did you check whether FreeCAD, the second app I encountered with >> an ARM release that caused the Rosetta dialog, has the same problem? >> > > Running `/Applications/FreeCAD.app/Contents/MacOS/FreeCAD` from Terminal does > work as well, so there is the same problem behind I guess. FreeCAD is however > code signed (so that’s not issue causing the Rosetta problem). > > > Nicklas > > > >> Their team never replied to my inquiry on X, but perhaps we could help get >> them started to fix this too. >> >> >> Cheers, >> Gregor >> >> On 2023-09-25, at 11:59 AM, Nicklas Larsson wrote: >>> >>> Gregor, >>> >>> I now had the opportunity to test on macOS 14 RC and I can confirm this >>> issue. The problem seems related somehow to being initialised by a script. >>> >>> I __did___ manage to start GRASS via Terminal: >>> >>> >>> 1. Run `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` >>> >>> 2. System will complain… >>> >>> 3. Go to 'System Settings > Privacy & Security > Security' >>> >>> 4. In the settings I enabled GRASS to be allowed >>> >>> 5. From now on `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` will >>> work >>> >>> >>> This is only a workaround, I will look into how this can be solved >>> properly. Maybe we have to make a binary that does the job the script now >>> does (that used to be the case some time ago). We should also invest some >>> time in creating a code signed app as well. >>> >>> >>> Nicklas >>> >>> >>> On 22 Sep 2023, at 11:01, Nicklas Larsson via grass-dev wrote: Gregor, thanks very much for the info! At least it ruled some things out, but I have still no idea what is causing this and it’s very difficult do the needed poking around without a similar setup (macOS 14 without Rosetta installed). I’ll have to ponder on this, if this really is caused by some change by macOS 14, a solution must be found sooner rather than later. An alternative way to install GRASS with native architecture for ARM is with MacPorts [1]. It does, however, involve some Terminal-batics! If you are in need for other GIS software like QGIS in particular, MacPorts is currently, in my experience, a most solid solution with available GRASS plugin (as there is no native official QGIS.app bundle for ARM). To be continued… Cheers, Nicklas [1] https://urldefense.com/v3/__https://grasswiki.osgeo.org/wiki/Compiling_on_macOS_using_MacPorts__;!!IKRxdwAv5BmarQ!dgVkpS9cztwvGGv-hsTRc5Vc0o6QJ28v5wxcBt3iZpXBnC-G0_E1qUasCdMvWceVKSW2z3TMfHwuQ7CtEnL2MQ$ >> On 20 Sep 2023, at 16:47, Gregor Hintner >> wrote: > > Niklas, > > > please find my answers below: > >> `file /usr/bin/osascript` > > evidently still a universal binary, see this screenshot > > >> `osascript -i` > > worked with no noticeable issues > >> /Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh > > produced the unverified developer warning as expected. Logically I could > and should probably override this, but with 10 years since my last time > coding, and having never learned the basics of UNIX, I would prefer to > follow the strictest Apple security guidelines, or sometimes perhaps > theater, when possible. > > >> `sw_vers -productVersion` > 14.0 > > >> file /usr/bin/sw_vers > universal binary > > > > Hope this helps, > Gregor > > >> On 2023-09-20, at 9:52 AM, Nicklas Larsson wrote: >> >>
Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
> On 25 Sep 2023, at 12:30, Gregor Hintner wrote: > > Niklas, > > > thank you on the committed exploration of this issue, also independently > verifying my own findings. > I’m afraid this is a problem that will be a major issue in the time to come, that we will have to deal with. Thank you for reporting! > From a layperson perspective it does seem reasonable to me that macOS wanted > apps to initialize through a conventionally made and signed binary, and would > appreciate if your team would consider that. I hope Apple would offer free > signing certificates, or even developer program memberships for open source > projects. > It will be difficult to make a “conventionally made” Mac application of GRASS, but a "fully working as expected" and signed one is possible. We are fully aware that the present solution isn’t optimal, but it has worked. So far. Now, apparently we will have to invest the time and sweat for making it right. > By chance, did you check whether FreeCAD, the second app I encountered with > an ARM release that caused the Rosetta dialog, has the same problem? > Running `/Applications/FreeCAD.app/Contents/MacOS/FreeCAD` from Terminal does work as well, so there is the same problem behind I guess. FreeCAD is however code signed (so that’s not issue causing the Rosetta problem). Nicklas > Their team never replied to my inquiry on X, but perhaps we could help get > them started to fix this too. > > > Cheers, > Gregor > > >> On 2023-09-25, at 11:59 AM, Nicklas Larsson wrote: >> >> Gregor, >> >> I now had the opportunity to test on macOS 14 RC and I can confirm this >> issue. The problem seems related somehow to being initialised by a script. >> >> I __did___ manage to start GRASS via Terminal: >> >> >> 1. Run `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` >> >> 2. System will complain… >> >> 3. Go to 'System Settings > Privacy & Security > Security' >> >> 4. In the settings I enabled GRASS to be allowed >> >> 5. From now on `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` will >> work >> >> >> This is only a workaround, I will look into how this can be solved properly. >> Maybe we have to make a binary that does the job the script now does (that >> used to be the case some time ago). We should also invest some time in >> creating a code signed app as well. >> >> >> Nicklas >> >> >> >>> On 22 Sep 2023, at 11:01, Nicklas Larsson via grass-dev >>> wrote: >>> >>> Gregor, thanks very much for the info! At least it ruled some things out, >>> but I have still no idea what is causing this and it’s very difficult do >>> the needed poking around without a similar setup (macOS 14 without Rosetta >>> installed). I’ll have to ponder on this, if this really is caused by some >>> change by macOS 14, a solution must be found sooner rather than later. >>> >>> An alternative way to install GRASS with native architecture for ARM is >>> with MacPorts [1]. It does, however, involve some Terminal-batics! If you >>> are in need for other GIS software like QGIS in particular, MacPorts is >>> currently, in my experience, a most solid solution with available GRASS >>> plugin (as there is no native official QGIS.app bundle for ARM). >>> >>> To be continued… >>> >>> Cheers, >>> Nicklas >>> >>> [1] https://grasswiki.osgeo.org/wiki/Compiling_on_macOS_using_MacPorts >>> >>> > On 20 Sep 2023, at 16:47, Gregor Hintner wrote: Niklas, please find my answers below: > `file /usr/bin/osascript` evidently still a universal binary, see this screenshot > `osascript -i` worked with no noticeable issues > /Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh produced the unverified developer warning as expected. Logically I could and should probably override this, but with 10 years since my last time coding, and having never learned the basics of UNIX, I would prefer to follow the strictest Apple security guidelines, or sometimes perhaps theater, when possible. > `sw_vers -productVersion` 14.0 > file /usr/bin/sw_vers universal binary Hope this helps, Gregor > On 2023-09-20, at 9:52 AM, Nicklas Larsson wrote: > > Gregor, > > Browsing the content of both GRASS.app and the FreeCAD.app, they seem > correctly to have been built for arm machines. Both are based on conda > dependencies and both are initiated by shell script. > > The shell script initialising GRASS involves the use of > '/usr/bin/osascript', which on macOS 12 is a universal binary. Perhaps > something did change with this command, please test the following: > > `file /usr/bin/osascript` > > and > > `osascript -i` > > (which should enter interactive mode, you may exit with Ctrl-C). > >
Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
Gregor, I now had the opportunity to test on macOS 14 RC and I can confirm this issue. The problem seems related somehow to being initialised by a script. I __did___ manage to start GRASS via Terminal: 1. Run `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` 2. System will complain… 3. Go to 'System Settings > Privacy & Security > Security' 4. In the settings I enabled GRASS to be allowed 5. From now on `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` will work This is only a workaround, I will look into how this can be solved properly. Maybe we have to make a binary that does the job the script now does (that used to be the case some time ago). We should also invest some time in creating a code signed app as well. Nicklas > On 22 Sep 2023, at 11:01, Nicklas Larsson via grass-dev > wrote: > > Gregor, thanks very much for the info! At least it ruled some things out, but > I have still no idea what is causing this and it’s very difficult do the > needed poking around without a similar setup (macOS 14 without Rosetta > installed). I’ll have to ponder on this, if this really is caused by some > change by macOS 14, a solution must be found sooner rather than later. > > An alternative way to install GRASS with native architecture for ARM is with > MacPorts [1]. It does, however, involve some Terminal-batics! If you are in > need for other GIS software like QGIS in particular, MacPorts is currently, > in my experience, a most solid solution with available GRASS plugin (as there > is no native official QGIS.app bundle for ARM). > > To be continued… > > Cheers, > Nicklas > > [1] https://grasswiki.osgeo.org/wiki/Compiling_on_macOS_using_MacPorts > > >> On 20 Sep 2023, at 16:47, Gregor Hintner wrote: >> >> Niklas, >> >> >> please find my answers below: >> >>> `file /usr/bin/osascript` >> >> evidently still a universal binary, see this screenshot >> >> >>> `osascript -i` >> >> worked with no noticeable issues >> >>> /Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh >> >> produced the unverified developer warning as expected. Logically I could and >> should probably override this, but with 10 years since my last time coding, >> and having never learned the basics of UNIX, I would prefer to follow the >> strictest Apple security guidelines, or sometimes perhaps theater, when >> possible. >> >> >>> `sw_vers -productVersion` >> 14.0 >> >> >>> file /usr/bin/sw_vers >> universal binary >> >> >> >> Hope this helps, >> Gregor >> >> >>> On 2023-09-20, at 9:52 AM, Nicklas Larsson wrote: >>> >>> Gregor, >>> >>> Browsing the content of both GRASS.app and the FreeCAD.app, they seem >>> correctly to have been built for arm machines. Both are based on conda >>> dependencies and both are initiated by shell script. >>> >>> The shell script initialising GRASS involves the use of >>> '/usr/bin/osascript', which on macOS 12 is a universal binary. Perhaps >>> something did change with this command, please test the following: >>> >>> `file /usr/bin/osascript` >>> >>> and >>> >>> `osascript -i` >>> >>> (which should enter interactive mode, you may exit with Ctrl-C). >>> >>> >>> You could also try start GRASS manually from Terminal: >>> >>> `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` >>> >>> (That step may, however, be prevented because of the app being unsigned). >>> >>> >>> >>> For control, the FreeCAD shell script contains the following command: >>> >>> `sw_vers -productVersion` >>> >>> Could you try that? ’sw_vers' is also a universal binary on macOS 12. What >>> will the following give: >>> >>> `file /usr/bin/sw_vers` >>> >>> >>> Best, >>> Nicklas >>> >>> >>> >>> On 19 Sep 2023, at 20:54, Michael Barton wrote: I've been corresponding with this GRASS user about how the software works with the new Apple ARM processors. Nicklas and I have compiled GRASS for ARM processors successfully. These are posted on the GRASS for Mac site (https://cmbarton.github.io/grass-mac/). When Gregor tries to launch GRASS under the new MacOS 14 (Sonoma) he gets a notice that Rosetta (Intel processor emulator) is needed. They launch on my ARM MacBook Pro with no notice, but I am not using Sonoma yet. Does anyone have any suggestions about what might be triggering this notice at launch time? AFAIK, initialization only calls the following: 1. shell launch script 2. wxPython 3. Python Is there any other module or dependency that gets called at initial launch (no maps displayed)? Michael _ C. Michael Barton Associate Director, School of Complex Adaptive Systems (https://scas.asu.edu) Professor, School of Human Evolution & Social Change (https://shesc.asu.edu) Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu) Arizona State University
Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
Edouard, I have compiled this using ARM and am running it on an ARM M2 Mac with no problem. It is unsigned. This issue of requiring Rosetta is only showing up in the Sonoma beta so far. Michael _ C. Michael Barton Associate Director, School of Complex Adaptive Systems (https://scas.asu.edu<https://scas.asu.edu/>) Professor, School of Human Evolution & Social Change (https://shesc.asu.edu) Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu) Arizona State University Tempe, AZ 85287-2701 USA Executive Director, Open Modeling Foundation (https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>) Director, Network for Computational Modeling in Social & Ecological Sciences (https://comses.net) personal website: http://www.public.asu.edu/~cmbarton Today's Topics: 1. Re: GRASS GIS for Apple Silicon Macs (Edouard Choini?re) -- Message: 1 Date: Fri, 22 Sep 2023 18:33:29 + From: Edouard Choini?re To: Michael Barton Cc: GRASS developers list Subject: Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs Message-ID: Content-Type: text/plain; charset="utf-8" Well, it?s not new, it?s been like that since 2020 with Big Sur and the introduction of M1 (before that M1 isn?t supported). Big Sur (version 11), was followed by Monterey (version 12), then Ventura (version 13), then Sonoma (version 14), which is the beta you?re talking about and the expected General availability is on September 26, 2023, in a couple of days. Even homebrew had problems at that time, so we?re not alone. Edouard Choini?re Le 22 sept. 2023 ? 14:23, Michael Barton via grass-dev a ?crit : ? This would be a major change by Apple and a royal PITA. I hope it is only something in the current beta and not in the final release (which I have not yet installed). We can probably sign through OSGEO. But when I looked into signing, it seems difficult unless you use Apple XCode. That would be a big step back from the current ease of compiling Mac binaries with Conda. When I looked into it several years ago, I could not find any clear instructions about how to sign code without XCode, although it may be possible. Michael _ C. Michael Barton Associate Director, School of Complex Adaptive Systems (https://scas.asu.edu<https://scas.asu.edu/>) Professor, School of Human Evolution & Social Change (https://shesc.asu.edu) Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu) Arizona State University Tempe, AZ 85287-2701 USA Executive Director, Open Modeling Foundation (https://urldefense.com/v3/__https://openmodelingfoundation.github.io__;!!IKRxdwAv5BmarQ!d_7QGyS2wWCY4Q69NNo2TDwqFapnps75GRcC-gG_MQucJg8tG6jc9trxcINAP7bXqKRP6Py5kVyLxpw5mJy6tOwUuDicV79WYqU$ <https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!d_7QGyS2wWCY4Q69NNo2TDwqFapnps75GRcC-gG_MQucJg8tG6jc9trxcINAP7bXqKRP6Py5kVyLxpw5mJy6tOwUuDic47FvxW0$ >) Director, Network for Computational Modeling in Social & Ecological Sciences (https://urldefense.com/v3/__https://comses.net__;!!IKRxdwAv5BmarQ!d_7QGyS2wWCY4Q69NNo2TDwqFapnps75GRcC-gG_MQucJg8tG6jc9trxcINAP7bXqKRP6Py5kVyLxpw5mJy6tOwUuDicVwKRqQM$ ) personal website: http://www.public.asu.edu/~cmbarton On Sep 22, 2023, at 10:34 AM, grass-dev-requ...@lists.osgeo.org wrote: Date: Fri, 22 Sep 2023 17:33:54 + From: Edouard Choini?re mailto:e@outlook.com>> To: Nicklas Larsson mailto:n_lars...@yahoo.com>> Cc: GRASS developers mailto:grass-dev@lists.osgeo.org>> Subject: Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs Message-ID: mailto:sa1pr12mb73447ec8cde24093c1f2bd14ef...@sa1pr12mb7344.namprd12.prod.outlook.com>> Content-Type: text/plain; charset="utf-8" I think I figured out an explanation. I tried to read about CI for macOS, then on why there aren?t a lot of CI for macOS (especially Apple Silicon). I also couldn?t look into the build infrastructure used for your grass macOS builds since they don?t seem to be available on GitHub. Is it local only? Ok, so now to a possible explanation on why Rosetta 2 is asked to be installed. It seems that with Apple Silicon, arm64 code needs to be signed (which is new), while x86_64 doesn?t, like before. I think it was mentioned in the thread that the app might be unsigned. So I suspect that even if a universal binary contains arm64 and x86_64 binaries, if it is unable to use the arm64 binary, it will try using the intel ones. <https://urldefense.com/v3/__https://www.sentinelone.com/blog/why-your-macos-edr-solution-shouldnt-be-running-under-rosetta-2/__;!!IKRxdwAv5BmarQ!fsArQT1R77zoM9dYDuSYWa2EDSuZWXHf8RL6ndhUKVFs465WYl5KI24PM-gzQSn-C40Ow3bvU871smBGyyY33dx99byJwmGQB7Q$> [Apple-Silicon-Rosetta-2-and-the-Challenges-for-Endpoint-Securi
Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
Well, it’s not new, it’s been like that since 2020 with Big Sur and the introduction of M1 (before that M1 isn’t supported). Big Sur (version 11), was followed by Monterey (version 12), then Ventura (version 13), then Sonoma (version 14), which is the beta you’re talking about and the expected General availability is on September 26, 2023, in a couple of days. Even homebrew had problems at that time, so we’re not alone. Edouard Choinière Le 22 sept. 2023 à 14:23, Michael Barton via grass-dev a écrit : This would be a major change by Apple and a royal PITA. I hope it is only something in the current beta and not in the final release (which I have not yet installed). We can probably sign through OSGEO. But when I looked into signing, it seems difficult unless you use Apple XCode. That would be a big step back from the current ease of compiling Mac binaries with Conda. When I looked into it several years ago, I could not find any clear instructions about how to sign code without XCode, although it may be possible. Michael _ C. Michael Barton Associate Director, School of Complex Adaptive Systems (https://scas.asu.edu<https://scas.asu.edu/>) Professor, School of Human Evolution & Social Change (https://shesc.asu.edu) Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu) Arizona State University Tempe, AZ 85287-2701 USA Executive Director, Open Modeling Foundation (https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>) Director, Network for Computational Modeling in Social & Ecological Sciences (https://comses.net) personal website: http://www.public.asu.edu/~cmbarton On Sep 22, 2023, at 10:34 AM, grass-dev-requ...@lists.osgeo.org wrote: Date: Fri, 22 Sep 2023 17:33:54 + From: Edouard Choini?re mailto:e@outlook.com>> To: Nicklas Larsson mailto:n_lars...@yahoo.com>> Cc: GRASS developers mailto:grass-dev@lists.osgeo.org>> Subject: Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs Message-ID: mailto:sa1pr12mb73447ec8cde24093c1f2bd14ef...@sa1pr12mb7344.namprd12.prod.outlook.com>> Content-Type: text/plain; charset="utf-8" I think I figured out an explanation. I tried to read about CI for macOS, then on why there aren?t a lot of CI for macOS (especially Apple Silicon). I also couldn?t look into the build infrastructure used for your grass macOS builds since they don?t seem to be available on GitHub. Is it local only? Ok, so now to a possible explanation on why Rosetta 2 is asked to be installed. It seems that with Apple Silicon, arm64 code needs to be signed (which is new), while x86_64 doesn?t, like before. I think it was mentioned in the thread that the app might be unsigned. So I suspect that even if a universal binary contains arm64 and x86_64 binaries, if it is unable to use the arm64 binary, it will try using the intel ones. <https://urldefense.com/v3/__https://www.sentinelone.com/blog/why-your-macos-edr-solution-shouldnt-be-running-under-rosetta-2/__;!!IKRxdwAv5BmarQ!fsArQT1R77zoM9dYDuSYWa2EDSuZWXHf8RL6ndhUKVFs465WYl5KI24PM-gzQSn-C40Ow3bvU871smBGyyY33dx99byJwmGQB7Q$> [Apple-Silicon-Rosetta-2-and-the-Challenges-for-Endpoint-Security-7.jpg] Why Your macOS EDR Solution Shouldn't Be Running Under Rosetta 2<https://urldefense.com/v3/__https://www.sentinelone.com/blog/why-your-macos-edr-solution-shouldnt-be-running-under-rosetta-2/__;!!IKRxdwAv5BmarQ!fsArQT1R77zoM9dYDuSYWa2EDSuZWXHf8RL6ndhUKVFs465WYl5KI24PM-gzQSn-C40Ow3bvU871smBGyyY33dx99byJwmGQB7Q$> sentinelone.com<http://sentinelone.com/><https://urldefense.com/v3/__https://www.sentinelone.com/blog/why-your-macos-edr-solution-shouldnt-be-running-under-rosetta-2/__;!!IKRxdwAv5BmarQ!fsArQT1R77zoM9dYDuSYWa2EDSuZWXHf8RL6ndhUKVFs465WYl5KI24PM-gzQSn-C40Ow3bvU871smBGyyY33dx99byJwmGQB7Q$> In particular, see the part where it says: That?s because one of the changes Apple brought in with Big Sur<https://urldefense.com/v3/__https://www.sentinelone.com/blog/macos-big-sur-has-landed-10-essential-security-tips-you-should-know/__;!!IKRxdwAv5BmarQ!fsArQT1R77zoM9dYDuSYWa2EDSuZWXHf8RL6ndhUKVFs465WYl5KI24PM-gzQSn-C40Ow3bvU871smBGyyY33dx99byJLjqv1E8$ > that only applies to Apple silicon Macs is that native arm64 code cannot execute on an M1 Mac unless it has a valid code signature. An Apple silicon Mac doesn?t permit native arm64 code execution under any conditions unless a valid signature is attached. Translated x86_64 code, however, is not subject to this restriction<https://urldefense.com/v3/__https://support.apple.com/guide/security/rosetta-2-on-a-mac-with-apple-silicon-secebb113be1/web__;!!IKRxdwAv5BmarQ!fsArQT1R77zoM9dYDuSYWa2EDSuZWXHf8RL6ndhUKVFs465WYl5KI24PM-gzQSn-C40Ow3bvU871smBGyyY33dx99byJR3pAVfc$ >: translated x86_64 code is permitted to execute through Rosetta with no signature information at all. There?s also that thread th
Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
This would be a major change by Apple and a royal PITA. I hope it is only something in the current beta and not in the final release (which I have not yet installed). We can probably sign through OSGEO. But when I looked into signing, it seems difficult unless you use Apple XCode. That would be a big step back from the current ease of compiling Mac binaries with Conda. When I looked into it several years ago, I could not find any clear instructions about how to sign code without XCode, although it may be possible. Michael _ C. Michael Barton Associate Director, School of Complex Adaptive Systems (https://scas.asu.edu<https://scas.asu.edu/>) Professor, School of Human Evolution & Social Change (https://shesc.asu.edu) Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu) Arizona State University Tempe, AZ 85287-2701 USA Executive Director, Open Modeling Foundation (https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>) Director, Network for Computational Modeling in Social & Ecological Sciences (https://comses.net) personal website: http://www.public.asu.edu/~cmbarton On Sep 22, 2023, at 10:34 AM, grass-dev-requ...@lists.osgeo.org wrote: Date: Fri, 22 Sep 2023 17:33:54 + From: Edouard Choini?re mailto:e@outlook.com>> To: Nicklas Larsson mailto:n_lars...@yahoo.com>> Cc: GRASS developers mailto:grass-dev@lists.osgeo.org>> Subject: Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs Message-ID: mailto:sa1pr12mb73447ec8cde24093c1f2bd14ef...@sa1pr12mb7344.namprd12.prod.outlook.com>> Content-Type: text/plain; charset="utf-8" I think I figured out an explanation. I tried to read about CI for macOS, then on why there aren?t a lot of CI for macOS (especially Apple Silicon). I also couldn?t look into the build infrastructure used for your grass macOS builds since they don?t seem to be available on GitHub. Is it local only? Ok, so now to a possible explanation on why Rosetta 2 is asked to be installed. It seems that with Apple Silicon, arm64 code needs to be signed (which is new), while x86_64 doesn?t, like before. I think it was mentioned in the thread that the app might be unsigned. So I suspect that even if a universal binary contains arm64 and x86_64 binaries, if it is unable to use the arm64 binary, it will try using the intel ones. <https://urldefense.com/v3/__https://www.sentinelone.com/blog/why-your-macos-edr-solution-shouldnt-be-running-under-rosetta-2/__;!!IKRxdwAv5BmarQ!fsArQT1R77zoM9dYDuSYWa2EDSuZWXHf8RL6ndhUKVFs465WYl5KI24PM-gzQSn-C40Ow3bvU871smBGyyY33dx99byJwmGQB7Q$> [Apple-Silicon-Rosetta-2-and-the-Challenges-for-Endpoint-Security-7.jpg] Why Your macOS EDR Solution Shouldn't Be Running Under Rosetta 2<https://urldefense.com/v3/__https://www.sentinelone.com/blog/why-your-macos-edr-solution-shouldnt-be-running-under-rosetta-2/__;!!IKRxdwAv5BmarQ!fsArQT1R77zoM9dYDuSYWa2EDSuZWXHf8RL6ndhUKVFs465WYl5KI24PM-gzQSn-C40Ow3bvU871smBGyyY33dx99byJwmGQB7Q$> sentinelone.com<http://sentinelone.com/><https://urldefense.com/v3/__https://www.sentinelone.com/blog/why-your-macos-edr-solution-shouldnt-be-running-under-rosetta-2/__;!!IKRxdwAv5BmarQ!fsArQT1R77zoM9dYDuSYWa2EDSuZWXHf8RL6ndhUKVFs465WYl5KI24PM-gzQSn-C40Ow3bvU871smBGyyY33dx99byJwmGQB7Q$> In particular, see the part where it says: That?s because one of the changes Apple brought in with Big Sur<https://urldefense.com/v3/__https://www.sentinelone.com/blog/macos-big-sur-has-landed-10-essential-security-tips-you-should-know/__;!!IKRxdwAv5BmarQ!fsArQT1R77zoM9dYDuSYWa2EDSuZWXHf8RL6ndhUKVFs465WYl5KI24PM-gzQSn-C40Ow3bvU871smBGyyY33dx99byJLjqv1E8$ > that only applies to Apple silicon Macs is that native arm64 code cannot execute on an M1 Mac unless it has a valid code signature. An Apple silicon Mac doesn?t permit native arm64 code execution under any conditions unless a valid signature is attached. Translated x86_64 code, however, is not subject to this restriction<https://urldefense.com/v3/__https://support.apple.com/guide/security/rosetta-2-on-a-mac-with-apple-silicon-secebb113be1/web__;!!IKRxdwAv5BmarQ!fsArQT1R77zoM9dYDuSYWa2EDSuZWXHf8RL6ndhUKVFs465WYl5KI24PM-gzQSn-C40Ow3bvU871smBGyyY33dx99byJR3pAVfc$ >: translated x86_64 code is permitted to execute through Rosetta with no signature information at all. There?s also that thread that was linked to from my reading some Reddit threads (like https://urldefense.com/v3/__https://www.reddit.com/r/programming/comments/15njgdc/apple_doesnt_want_you_developing_hobby_apps/jvmvxv6/__;!!IKRxdwAv5BmarQ!fsArQT1R77zoM9dYDuSYWa2EDSuZWXHf8RL6ndhUKVFs465WYl5KI24PM-gzQSn-C40Ow3bvU871smBGyyY33dx99byJuQeo8wU$<https://urldefense.com/v3/__https://www.reddit.com/r/programming/comments/15njgdc/apple_doesnt_want_you_developing_hobby_apps/jvmvxv6/?utm_source=share_medium=mweb3x_name=mweb3xcss_term=1_conten
Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
Gregor, thanks very much for the info! At least it ruled some things out, but I have still no idea what is causing this and it’s very difficult do the needed poking around without a similar setup (macOS 14 without Rosetta installed). I’ll have to ponder on this, if this really is caused by some change by macOS 14, a solution must be found sooner rather than later. An alternative way to install GRASS with native architecture for ARM is with MacPorts [1]. It does, however, involve some Terminal-batics! If you are in need for other GIS software like QGIS in particular, MacPorts is currently, in my experience, a most solid solution with available GRASS plugin (as there is no native official QGIS.app bundle for ARM). To be continued… Cheers, Nicklas [1] https://grasswiki.osgeo.org/wiki/Compiling_on_macOS_using_MacPorts > On 20 Sep 2023, at 16:47, Gregor Hintner wrote: > > Niklas, > > > please find my answers below: > >> `file /usr/bin/osascript` > > evidently still a universal binary, see this screenshot > > >> `osascript -i` > > worked with no noticeable issues > >> /Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh > > produced the unverified developer warning as expected. Logically I could and > should probably override this, but with 10 years since my last time coding, > and having never learned the basics of UNIX, I would prefer to follow the > strictest Apple security guidelines, or sometimes perhaps theater, when > possible. > > >> `sw_vers -productVersion` > 14.0 > > >> file /usr/bin/sw_vers > universal binary > > > > Hope this helps, > Gregor > > >> On 2023-09-20, at 9:52 AM, Nicklas Larsson wrote: >> >> Gregor, >> >> Browsing the content of both GRASS.app and the FreeCAD.app, they seem >> correctly to have been built for arm machines. Both are based on conda >> dependencies and both are initiated by shell script. >> >> The shell script initialising GRASS involves the use of >> '/usr/bin/osascript', which on macOS 12 is a universal binary. Perhaps >> something did change with this command, please test the following: >> >> `file /usr/bin/osascript` >> >> and >> >> `osascript -i` >> >> (which should enter interactive mode, you may exit with Ctrl-C). >> >> >> You could also try start GRASS manually from Terminal: >> >> `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` >> >> (That step may, however, be prevented because of the app being unsigned). >> >> >> >> For control, the FreeCAD shell script contains the following command: >> >> `sw_vers -productVersion` >> >> Could you try that? ’sw_vers' is also a universal binary on macOS 12. What >> will the following give: >> >> `file /usr/bin/sw_vers` >> >> >> Best, >> Nicklas >> >> >> >> >>> On 19 Sep 2023, at 20:54, Michael Barton wrote: >>> >>> I've been corresponding with this GRASS user about how the software works >>> with the new Apple ARM processors. Nicklas and I have compiled GRASS for >>> ARM processors successfully. These are posted on the GRASS for Mac site >>> (https://cmbarton.github.io/grass-mac/). When Gregor tries to launch GRASS >>> under the new MacOS 14 (Sonoma) he gets a notice that Rosetta (Intel >>> processor emulator) is needed. They launch on my ARM MacBook Pro with no >>> notice, but I am not using Sonoma yet. >>> >>> Does anyone have any suggestions about what might be triggering this notice >>> at launch time? AFAIK, initialization only calls the following: >>> 1. shell launch script >>> 2. wxPython >>> 3. Python >>> >>> Is there any other module or dependency that gets called at initial launch >>> (no maps displayed)? >>> >>> Michael >>> _ >>> C. Michael Barton >>> Associate Director, School of Complex Adaptive Systems >>> (https://scas.asu.edu) >>> Professor, School of Human Evolution & Social Change (https://shesc.asu.edu) >>> Director, Center for Social Dynamics & Complexity >>> (https://complexity.asu.edu) >>> Arizona State University >>> Tempe, AZ 85287-2701 >>> USA >>> >>> Executive Director, Open Modeling Foundation >>> (https://openmodelingfoundation.github.io) >>> Director, Network for Computational Modeling in Social & Ecological >>> Sciences (https://comses.net) >>> >>> personal website: http://www.public.asu.edu/~cmbarton >>> >>> Begin forwarded message: From: Gregor Hintner Subject: Re: GRASS GIS for Apple Silicon Macs Date: September 18, 2023 at 11:34:02 AM MST To: Michael Barton Unfortunately I suspect we have had another miscommunication. Let me list the specific steps that lead to the Rosetta prompt: - Download GRASS 8.3.0 Apple ARM or GRASS 8.4dev from your webpage - mount either downloaded Diskimage - copy the GRASS application file from the mounted DMG to the Applications folder - double click and launch the GRASS application - macOS shows a prompt to install Rosetta to continue Obviously the
Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
Gregor, thanks very much for the info! At least it ruled some things out, but I have still no idea what is causing this and it’s very difficult do the needed poking around without a similar setup (macOS 14 without Rosetta installed). I’ll have to ponder on this, if this really is caused by some change by macOS 14, a solution must be found sooner rather than later. An alternative way to install GRASS with native architecture for ARM is with MacPorts [1]. It does, however, involve some Terminal-batics! If you are in need for other GIS software like QGIS in particular, MacPorts is currently, in my experience, a most solid solution with available GRASS plugin (as there is no native official QGIS.app bundle for ARM). To be continued… Cheers, Nicklas [1] https://grasswiki.osgeo.org/wiki/Compiling_on_macOS_using_MacPorts > On 20 Sep 2023, at 16:47, Gregor Hintner wrote: > > Niklas, > > > please find my answers below: > >> `file /usr/bin/osascript` > > evidently still a universal binary, see this screenshot > > >> `osascript -i` > > worked with no noticeable issues > >> /Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh > > produced the unverified developer warning as expected. Logically I could and > should probably override this, but with 10 years since my last time coding, > and having never learned the basics of UNIX, I would prefer to follow the > strictest Apple security guidelines, or sometimes perhaps theater, when > possible. > > >> `sw_vers -productVersion` > 14.0 > > >> file /usr/bin/sw_vers > universal binary > > > > Hope this helps, > Gregor > > >> On 2023-09-20, at 9:52 AM, Nicklas Larsson wrote: >> >> Gregor, >> >> Browsing the content of both GRASS.app and the FreeCAD.app, they seem >> correctly to have been built for arm machines. Both are based on conda >> dependencies and both are initiated by shell script. >> >> The shell script initialising GRASS involves the use of >> '/usr/bin/osascript', which on macOS 12 is a universal binary. Perhaps >> something did change with this command, please test the following: >> >> `file /usr/bin/osascript` >> >> and >> >> `osascript -i` >> >> (which should enter interactive mode, you may exit with Ctrl-C). >> >> >> You could also try start GRASS manually from Terminal: >> >> `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` >> >> (That step may, however, be prevented because of the app being unsigned). >> >> >> >> For control, the FreeCAD shell script contains the following command: >> >> `sw_vers -productVersion` >> >> Could you try that? ’sw_vers' is also a universal binary on macOS 12. What >> will the following give: >> >> `file /usr/bin/sw_vers` >> >> >> Best, >> Nicklas >> >> >> >> >>> On 19 Sep 2023, at 20:54, Michael Barton wrote: >>> >>> I've been corresponding with this GRASS user about how the software works >>> with the new Apple ARM processors. Nicklas and I have compiled GRASS for >>> ARM processors successfully. These are posted on the GRASS for Mac site >>> (https://cmbarton.github.io/grass-mac/). When Gregor tries to launch GRASS >>> under the new MacOS 14 (Sonoma) he gets a notice that Rosetta (Intel >>> processor emulator) is needed. They launch on my ARM MacBook Pro with no >>> notice, but I am not using Sonoma yet. >>> >>> Does anyone have any suggestions about what might be triggering this notice >>> at launch time? AFAIK, initialization only calls the following: >>> 1. shell launch script >>> 2. wxPython >>> 3. Python >>> >>> Is there any other module or dependency that gets called at initial launch >>> (no maps displayed)? >>> >>> Michael >>> _ >>> C. Michael Barton >>> Associate Director, School of Complex Adaptive Systems >>> (https://scas.asu.edu) >>> Professor, School of Human Evolution & Social Change (https://shesc.asu.edu) >>> Director, Center for Social Dynamics & Complexity >>> (https://complexity.asu.edu) >>> Arizona State University >>> Tempe, AZ 85287-2701 >>> USA >>> >>> Executive Director, Open Modeling Foundation >>> (https://openmodelingfoundation.github.io) >>> Director, Network for Computational Modeling in Social & Ecological >>> Sciences (https://comses.net) >>> >>> personal website: http://www.public.asu.edu/~cmbarton >>> >>> Begin forwarded message: From: Gregor Hintner Subject: Re: GRASS GIS for Apple Silicon Macs Date: September 18, 2023 at 11:34:02 AM MST To: Michael Barton Unfortunately I suspect we have had another miscommunication. Let me list the specific steps that lead to the Rosetta prompt: - Download GRASS 8.3.0 Apple ARM or GRASS 8.4dev from your webpage - mount either downloaded Diskimage - copy the GRASS application file from the mounted DMG to the Applications folder - double click and launch the GRASS application - macOS shows a prompt to install Rosetta to continue Obviously the
Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs
Gregor, Browsing the content of both GRASS.app and the FreeCAD.app, they seem correctly to have been built for arm machines. Both are based on conda dependencies and both are initiated by shell script. The shell script initialising GRASS involves the use of '/usr/bin/osascript', which on macOS 12 is a universal binary. Perhaps something did change with this command, please test the following: `file /usr/bin/osascript` and `osascript -i` (which should enter interactive mode, you may exit with Ctrl-C). You could also try start GRASS manually from Terminal: `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` (That step may, however, be prevented because of the app being unsigned). For control, the FreeCAD shell script contains the following command: `sw_vers -productVersion` Could you try that? ’sw_vers' is also a universal binary on macOS 12. What will the following give: `file /usr/bin/sw_vers` Best, Nicklas > On 19 Sep 2023, at 20:54, Michael Barton wrote: > > I've been corresponding with this GRASS user about how the software works > with the new Apple ARM processors. Nicklas and I have compiled GRASS for ARM > processors successfully. These are posted on the GRASS for Mac site > (https://cmbarton.github.io/grass-mac/). When Gregor tries to launch GRASS > under the new MacOS 14 (Sonoma) he gets a notice that Rosetta (Intel > processor emulator) is needed. They launch on my ARM MacBook Pro with no > notice, but I am not using Sonoma yet. > > Does anyone have any suggestions about what might be triggering this notice > at launch time? AFAIK, initialization only calls the following: > 1. shell launch script > 2. wxPython > 3. Python > > Is there any other module or dependency that gets called at initial launch > (no maps displayed)? > > Michael > _ > C. Michael Barton > Associate Director, School of Complex Adaptive Systems (https://scas.asu.edu) > Professor, School of Human Evolution & Social Change (https://shesc.asu.edu) > Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu) > Arizona State University > Tempe, AZ 85287-2701 > USA > > Executive Director, Open Modeling Foundation > (https://openmodelingfoundation.github.io) > Director, Network for Computational Modeling in Social & Ecological Sciences > (https://comses.net) > > personal website: http://www.public.asu.edu/~cmbarton > > >> Begin forwarded message: >> >> From: Gregor Hintner >> Subject: Re: GRASS GIS for Apple Silicon Macs >> Date: September 18, 2023 at 11:34:02 AM MST >> To: Michael Barton >> >> Unfortunately I suspect we have had another miscommunication. >> Let me list the specific steps that lead to the Rosetta prompt: >> - Download GRASS 8.3.0 Apple ARM or GRASS 8.4dev from your webpage >> - mount either downloaded Diskimage >> - copy the GRASS application file from the mounted DMG to the Applications >> folder >> - double click and launch the GRASS application >> - macOS shows a prompt to install Rosetta to continue >> >> Obviously the prompt only appears when actually launching GRASS, the launch >> just never progresses past it, and no console or GUI can appear. >> >> To my eyes the OS behavior seems credible in this case, though I obviously >> have no insights beyond the regular UI level. >> >> Could you send me an email contact to the GRASS dev list. I frankly never >> understood how these lists work, I assume some kind of e-mail chain, but I >> noticed no actual e-mail addresses on the main GRASS webpage, only on your >> Mac distribution site. >> >> >> Thanks, >> Gregor >> >> >>> On 2023-09-18, at 8:20 PM, Michael Barton wrote: >>> >>> Gregor, >>> >>> I lean toward this being a bug in the beta at the moment. The reason is >>> that installing GRASS should not raise a Rosetta request, at least until >>> you run GRASS. This is because GRASS is organized as a set of independent >>> modules, overlayed with an optional GUI. Running GRASS invokes a shell >>> script (that should not require Rosestta, since it launches an ARM >>> terminal) and than the GUI in Python 3 and wxPython. But these should also >>> be ARM compatible. It is possible that one or more of the >300 individual >>> modules or dependencies require Rosetta. But these should not call Rosetta >>> until they are launched. Also, they are mostly in C and Python, with some >>> C++ code--all of which was compiled under ARM tools. You might post this >>> question to the GRASS dev list. It is hard to say what is causing this >>> message to appear in your beta when nothing is launched. >>> >>> Michael >>> _ >>> C. Michael Barton >>> Associate Director, School of Complex Adaptive Systems >>> (https://scas.asu.edu) >>> Professor, School of Human Evolution & Social Change (https://shesc.asu.edu) >>> Director, Center for Social Dynamics & Complexity >>> (https://complexity.asu.edu) >>> Arizona State University >>>
