Re: [GRASS-dev] g.extension, svn, and Mac

2020-08-03 Thread Steven Pawley 
Perhaps a different issue,  but I can install extensions, but only pure 
python-based extensions. Anything that requires compilation of C code fails.

For example, when using the latest GRASS GIS binary (7.9, 25th July 2020 
build), this works with r.texture.tiled:

Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
Installing...
Updating extensions metadata file...
Updating extension modules metadata file...
Installation of  successfully finished

But for example, r.fill.gaps does not:

g.extension extension=r.fill.gaps   
Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
clang-10: warning: no such sysroot directory:
'/Users/cmbarton/SDKs/MacOSX10.14.sdk' [-Wmissing-sysroot]
cell_funcs.c:21:10: fatal error: 'math.h' file not found
#include 
 ^~~~
1 error generated.
make: *** [OBJ.x86_64-apple-darwin19.5.0/cell_funcs.o] Error
1
ERROR: Compilation failed, sorry. Please check above error messages.

The 7.9-dev build throws an error because it appears to be still looking for 
components based on your system, specifically.,The 7.8.4 binary (16th July 2020 
build) also throws the same error. I’m running the MacOS 10.15.6.

Steve 


> On Aug 2, 2020, at 4:44 PM, Michael Barton  wrote:
> 
> I just learned yesterday, when I tried to install something from g.extension 
> that:
> 
> 1. g.extension uses svn to download packages, and
> 2. Apple stopped including svn with the current OS (10.15.x) and its 
> developer tools
> 
> I don't know if anyone else has run into this yet, but it could be an 
> increasingly sticky issue going forward. Unless there are plans to change how 
> g.extension gets packages, I suppose I need to include it in the Mac app 
> bundle. 
> 
> Has anyone else hit this yet?
> 
> Michael 
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity 
> Director, Network for Computational Modeling in Social & Ecological Sciences
> Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
> Arizona State University
> 
> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: 'http://www.public.asu.edu/~cmbarton 
> , https://complexity.asu.edu/csdc' 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] packagers' guidance on inclusion of small dataset into the GRASS GIS installation

2020-08-03 Thread Moritz Lennert 



On 3/08/20 17:44, Sebastiaan Couwenberg wrote:

On 8/3/20 4:59 PM, Moritz Lennert wrote:



On 3/08/20 16:37, Sebastiaan Couwenberg wrote:

On 8/3/20 4:16 PM, Moritz Lennert wrote:

I have a small question concerning the best way to include a very small
dataset into the distribution of GRASS GIS. We are currently working on
the revamping of the GRASS GIS GUI startup experience, and have the
currently proposed solution is that GRASS GIS could start up
automatically creating a grassdata database and a default lat-long
location which would contain just a simple NaturalEarth world country
boundaries dataset.

In some OS (e.g. MS Windows), such a demolocation is included in the
distribution, but in Debian it is deleted before installation (IIUC what
happens in the rules file at [1]).

IIRC, Debian does normally not allow data to be distributed with
binaries. One option would be to put the data directly into the Python
code creating this location. Would that be acceptable for Debian ? What
kind of solution would you recommend ?


If the database can be built from source as part of the build process
e.g. like proj.db in PROJ, it can be included in the package (assuming
its license is DFSG compatible).

Where is "this location"?

If it's usr/lib/grassXY/demolocation, that's problematic because it's
not writable by unprivileged users. A subdirectory of $XDG_DATA_HOME
(e.g. $HOME/.local/share/grass) would be more suitable.


Actually, the idea currently is that a new user without any grassdata
will just get a grassdata directory automagically created during startup
and the /usr/lib/grassXY/demolocation would simply be copied into that
new grassdata directory. GRASS GIS would then directly start up into
that location.

So, the idea would be that during build /usr/lib/grassXY/demolocation is
created.


I don't know why the demolocation was never included in the package,
looking at the repo history it has always been like that since way
before I got involved.

I've pushed a change to include the directory in the grass-core package:

  
https://salsa.debian.org/debian-gis-team/grass/-/commit/faa570fd3357b1267d237fc0ee9b3386ce83479d

That can be used as the source for the user writable copy.


Thanks !

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] packagers' guidance on inclusion of small dataset into the GRASS GIS installation

2020-08-03 Thread Sebastiaan Couwenberg 
On 8/3/20 4:59 PM, Moritz Lennert wrote:
> 
> 
> On 3/08/20 16:37, Sebastiaan Couwenberg wrote:
>> On 8/3/20 4:16 PM, Moritz Lennert wrote:
>>> I have a small question concerning the best way to include a very small
>>> dataset into the distribution of GRASS GIS. We are currently working on
>>> the revamping of the GRASS GIS GUI startup experience, and have the
>>> currently proposed solution is that GRASS GIS could start up
>>> automatically creating a grassdata database and a default lat-long
>>> location which would contain just a simple NaturalEarth world country
>>> boundaries dataset.
>>>
>>> In some OS (e.g. MS Windows), such a demolocation is included in the
>>> distribution, but in Debian it is deleted before installation (IIUC what
>>> happens in the rules file at [1]).
>>>
>>> IIRC, Debian does normally not allow data to be distributed with
>>> binaries. One option would be to put the data directly into the Python
>>> code creating this location. Would that be acceptable for Debian ? What
>>> kind of solution would you recommend ?
>>
>> If the database can be built from source as part of the build process
>> e.g. like proj.db in PROJ, it can be included in the package (assuming
>> its license is DFSG compatible).
>>
>> Where is "this location"?
>>
>> If it's usr/lib/grassXY/demolocation, that's problematic because it's
>> not writable by unprivileged users. A subdirectory of $XDG_DATA_HOME
>> (e.g. $HOME/.local/share/grass) would be more suitable.
> 
> Actually, the idea currently is that a new user without any grassdata
> will just get a grassdata directory automagically created during startup
> and the /usr/lib/grassXY/demolocation would simply be copied into that
> new grassdata directory. GRASS GIS would then directly start up into
> that location.
> 
> So, the idea would be that during build /usr/lib/grassXY/demolocation is
> created.

I don't know why the demolocation was never included in the package,
looking at the repo history it has always been like that since way
before I got involved.

I've pushed a change to include the directory in the grass-core package:

 
https://salsa.debian.org/debian-gis-team/grass/-/commit/faa570fd3357b1267d237fc0ee9b3386ce83479d

That can be used as the source for the user writable copy.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] packagers' guidance on inclusion of small dataset into the GRASS GIS installation

2020-08-03 Thread Moritz Lennert 



On 3/08/20 16:37, Sebastiaan Couwenberg wrote:

On 8/3/20 4:16 PM, Moritz Lennert wrote:

I have a small question concerning the best way to include a very small
dataset into the distribution of GRASS GIS. We are currently working on
the revamping of the GRASS GIS GUI startup experience, and have the
currently proposed solution is that GRASS GIS could start up
automatically creating a grassdata database and a default lat-long
location which would contain just a simple NaturalEarth world country
boundaries dataset.

In some OS (e.g. MS Windows), such a demolocation is included in the
distribution, but in Debian it is deleted before installation (IIUC what
happens in the rules file at [1]).

IIRC, Debian does normally not allow data to be distributed with
binaries. One option would be to put the data directly into the Python
code creating this location. Would that be acceptable for Debian ? What
kind of solution would you recommend ?


If the database can be built from source as part of the build process
e.g. like proj.db in PROJ, it can be included in the package (assuming
its license is DFSG compatible).

Where is "this location"?

If it's usr/lib/grassXY/demolocation, that's problematic because it's
not writable by unprivileged users. A subdirectory of $XDG_DATA_HOME
(e.g. $HOME/.local/share/grass) would be more suitable.


Actually, the idea currently is that a new user without any grassdata 
will just get a grassdata directory automagically created during startup 
and the /usr/lib/grassXY/demolocation would simply be copied into that 
new grassdata directory. GRASS GIS would then directly start up into 
that location.


So, the idea would be that during build /usr/lib/grassXY/demolocation is 
created.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] packagers' guidance on inclusion of small dataset into the GRASS GIS installation

2020-08-03 Thread Sebastiaan Couwenberg 
On 8/3/20 4:16 PM, Moritz Lennert wrote:
> I have a small question concerning the best way to include a very small
> dataset into the distribution of GRASS GIS. We are currently working on
> the revamping of the GRASS GIS GUI startup experience, and have the
> currently proposed solution is that GRASS GIS could start up
> automatically creating a grassdata database and a default lat-long
> location which would contain just a simple NaturalEarth world country
> boundaries dataset.
> 
> In some OS (e.g. MS Windows), such a demolocation is included in the
> distribution, but in Debian it is deleted before installation (IIUC what
> happens in the rules file at [1]).
> 
> IIRC, Debian does normally not allow data to be distributed with
> binaries. One option would be to put the data directly into the Python
> code creating this location. Would that be acceptable for Debian ? What
> kind of solution would you recommend ?

If the database can be built from source as part of the build process
e.g. like proj.db in PROJ, it can be included in the package (assuming
its license is DFSG compatible).

Where is "this location"?

If it's usr/lib/grassXY/demolocation, that's problematic because it's
not writable by unprivileged users. A subdirectory of $XDG_DATA_HOME
(e.g. $HOME/.local/share/grass) would be more suitable.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] packagers' guidance on inclusion of small dataset into the GRASS GIS installation

2020-08-03 Thread Moritz Lennert 

Hi Bas, Hi any other packages who might want to weigh in,

I have a small question concerning the best way to include a very small 
dataset into the distribution of GRASS GIS. We are currently working on 
the revamping of the GRASS GIS GUI startup experience, and have the 
currently proposed solution is that GRASS GIS could start up 
automatically creating a grassdata database and a default lat-long 
location which would contain just a simple NaturalEarth world country 
boundaries dataset.


In some OS (e.g. MS Windows), such a demolocation is included in the 
distribution, but in Debian it is deleted before installation (IIUC what 
happens in the rules file at [1]).


IIRC, Debian does normally not allow data to be distributed with 
binaries. One option would be to put the data directly into the Python 
code creating this location. Would that be acceptable for Debian ? What 
kind of solution would you recommend ?


Thanks for any hints you can give us !

Moritz



[1] 
https://salsa.debian.org/debian-gis-team/grass/-/blob/master/debian/rules#L199

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] GRASS GIS Birthday Virtual Celebration

2020-08-03 Thread Nikos Alexandris 

Dear all,

Happy Birthday for GRASS GIS!

Sad I missed the 'gathering'.

Cheers :-)


* Vaclav Petras  [2020-07-27 21:48:29 -0400]:


Dear GRASS GIS users and developers,

On Wednesday, July 29, we will celebrate GRASS GIS birthday!

Please, join us in a video call at 19:00 UTC. I will send a link to the call
here right before the meeting. We will use Zoom.

https://www.timeanddate.com/worldclock/converter.html?iso=20200729T19&p1=1440&p2=204&p3=195&p4=51&p5=207&p6=671

We will ponder the long history, perhaps question some technological
decisions, discuss some current issues, and think about the future of GRASS
GIS.

If you think this is not enough celebratory, bring your most complicated
GRASS GIS workflow. What would be a better way to celebrate than to explain
an obscure command from 10 years ago?

Best,
Vashek

PS: You can let me know privately if you have any questions or concerns
about joining this video call.



___
grass-user mailing list
grass-u...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user



--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 
___

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev