Re: [GRASS-dev] [EXTERNAL] [release planning] GRASS GIS 8.3.1
On Mon, Sep 25, 2023 at 3:23 PM Tomas Zigo via grass-dev < grass-dev@lists.osgeo.org> wrote: > Citát Markus Neteler : > > In addition, we have plenty of wxGUI fixes, which might well go in: > > > > https://github.com/OSGeo/grass/labels/backport%20to%208.3 > > > > Markus > > I am in favor of including all necessary wxGUI fixes soon as possible > in the 8.3.1 release. > > https://github.com/OSGeo/grass/labels/backport%20to%208.3 > > Tomas > Thanks for all the fixes, I started to go through them and will continue the reviews. Anna > > > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [EXTERNAL] [release planning] GRASS GIS 8.3.1
Citát Markus Neteler : In addition, we have plenty of wxGUI fixes, which might well go in: https://github.com/OSGeo/grass/labels/backport%20to%208.3 Markus I am in favor of including all necessary wxGUI fixes soon as possible in the 8.3.1 release. https://github.com/OSGeo/grass/labels/backport%20to%208.3 Tomas ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
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] Learn more about NSF funded project for GRASS ecosystem
Hi Anna, I was away last week and missed both sessions. Will you make a recording available at some point? Thank you. -- Luís Sent with [Proton Mail](https://proton.me/) secure email. --- Original Message --- On Thursday, September 21st, 2023 at 9:36 PM, Anna Petrášová via grass-dev wrote: > We just successfully finished the first session and the second one is coming > up tomorrow (EST/New York at 10am, CEST/Brussels at 4pm). > We recorded the presentation part, for those who joined late or can't join > tomorrow, I can privately share the recording. > > Best, > Anna > > On Tue, Sep 19, 2023 at 10:33 AM Anna Petrášová wrote: > >> For those interested to join us, the first session is coming up this >> Thursday (EST/New York at 2pm, CEST/Brussels at 8pm). You can join with a >> zoom link: >> https://ncsu.zoom.us/j/97419521476?pwd=cmx3TitGYjZiYWxzd241U0J0TzVUdz09 >> >> If you can't make it, you can join the second session on Friday (EST/New >> York at 10am, CEST/Brussels at 4pm). >> >> Looking forward to seeing you there! >> >> Anna >> >> On Mon, Sep 11, 2023 at 4:57 PM Anna Petrášová wrote: >> >>> As a follow up on our announcement about the NSF funded project to enhance >>> GRASS ecosystem [1] I would like to invite everybody interested to an info >>> session! We will briefly explain what we hope to achieve in this project >>> and how you can get involved. There will be time for Q as well. >>> To allow as many people to join, we plan two 1-hour info sessions at >>> different days and times: >>> >>> * [Thursday, September >>> 21](https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023=9=21=18=0=0=207=51=48=197=3703) >>> (EST 2pm, Europe 8pm) >>> * [Friday, September >>> 22](https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023=9=22=14=0=0=207=51=48=197=3703) >>> (EST 10am, Europe 4pm) >>> >>> The content of both sessions will be the same. I will send zoom links a day >>> before each event. >>> Hope to see you there! >>> >>> Anna >>> >>> [1] https://grass.osgeo.org/news/2023_09_06_nsf_grant_awarded/___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [EXTERNAL] [release planning] GRASS GIS 8.3.1
On Wed, Sep 20, 2023 at 5:31 PM Nicklas Larsson wrote: > > https://github.com/OSGeo/grass/issues/3077 > _is_ the one and only blocker for 8.3.1. : > > https://github.com/OSGeo/grass/issues?q=is%3Aopen+is%3Aissue+label%3A%22backport+to+8.3%22+label%3Ablocker In addition, we have plenty of wxGUI fixes, which might well go in: https://github.com/OSGeo/grass/labels/backport%20to%208.3 Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
