Re: [GRASS-dev] GRASS Docker container - new website ?
Thanks Markus for the info. I have no need for GRASS at the moment, so I likely won’t look into this, but it sounded intriguing. My thought was to run R normal, and have GRASS in a docker container. Will think about it, when I have time. Cheers, Rainer > On 3 Jul 2020, at 16:15, Markus Neteler wrote: > > Hi Rainer, > > On Fri, Jul 3, 2020 at 10:58 AM Rainer M Krug wrote: >> >> I just found the docker images, and am happy, that they are there! >> >> But I am have three questions: >> >> There is limited info on how they can be used on >> https://hub.docker.com/r/mundialis/grass-py3-pdal > > There is more info here but dockerhub isn't showing it... > >> but there is no mention of the GUI (I assume it is not working?) > > An attempt with GUI is here: > > https://hub.docker.com/r/neteler/docker-alpine-grass-gis-gui > > based on > https://github.com/OSGeo/grass/blob/master/docker/alpine/Dockerfile_alpine_wxgui > >> or examples on how the image can be used. It would eb useful, if some more >> info could be provided by somebody who uses / knows these images. >> It would be useful, to include a link to the documentations itself in the >> new website. > > Agreed... it is all due to lack of time but writing documentation > could be done by "anyone". > >> The second questions concerns the R integration - it sounds intriguing, to >> consider that R interfaces with the GRASS docker container. Is this >> possible? Has somebody tried it? > > I haven't but others likely yes. > I'd suggest a multi-stage docker build approach to "blend" the > different images together. > >> The third question concerns AddOns - are they installed in the container, or >> outside? > > We do that inside while building it (in this case "actinia" which uses > above docker images as the basis) with a convenient CSV file listing > the addons and their respective repos: > see > https://github.com/mundialis/actinia_core/blob/master/docker/actinia-core/Dockerfile#L73 > > HTH, > > Markus > > -- > Markus Neteler, PhD > https://www.mundialis.de - free data with free software > https://grass.osgeo.org > https://courses.neteler.org/blog -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Orcid ID: -0002-7490-0066 Department of Evolutionary Biology and Environmental Studies University of Zürich Office Y34-J-74 Winterthurerstrasse 190 8075 Zürich Switzerland Office: +41 (0)44 635 47 64 Cell: +41 (0)78 630 66 57 email: rainer.k...@uzh.ch rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS Docker container - new website ?
I just found the docker images, and am happy, that they are there! But I am have three questions: There is limited info on how they can be used on https://hub.docker.com/r/mundialis/grass-py3-pdal but there is no mention of the GUI (I assume it is not working?) or examples on how the image can be used. It would eb useful, if some more info could be provided by somebody who uses / knows these images. It would be useful, to include a link to the documentations itself in the new website. The second questions concerns the R integration - it sounds intriguing, to consider that R interfaces with the GRASS docker container. Is this possible? Has somebody tried it? The third question concerns AddOns - are they installed in the container, or outside? Thanks, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Orcid ID: -0002-7490-0066 Department of Evolutionary Biology and Environmental Studies University of Zürich Office Y34-J-74 Winterthurerstrasse 190 8075 Zürich Switzerland Office: +41 (0)44 635 47 64 Cell: +41 (0)78 630 66 57 email: rainer.k...@uzh.ch rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Testing the new GRASS GIS website: please help
Done - #194, #195 & #196 Just for discussion, wold it be possible to, at least, use the colour scheme (and font if they are different?) from the GRASS site for the WIKI as well? Cheers, Rainer > On 2 Jul 2020, at 19:45, Markus Neteler wrote: > > On Thu, Jul 2, 2020 at 8:59 AM Rainer Krug wrote: >> >> It looks really I=nice - good job. > > That is the great design work done by Nicolas Bozon (in cc)! > > @all: > Please be so kind to open issues here as they are much easier to deal > with than through emails: > https://github.com/OSGeo/grass-website/issues > > thanks > Markus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Orcid ID: -0002-7490-0066 Department of Evolutionary Biology and Environmental Studies University of Zürich Office Y34-J-74 Winterthurerstrasse 190 8075 Zürich Switzerland Office: +41 (0)44 635 47 64 Cell: +41 (0)78 630 66 57 email: rainer.k...@uzh.ch rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Automatic/CI compilation on macOS
Thanks Vaclav I will wait and see.If you could please post here if something happens, as I am not following grass-user? Thanks, Rainer > On 31 Mar 2020, at 03:50, Vaclav Petras wrote: > > Hi Rainer, > > Unfortunately, I don't have any update for this, but I thought I will > (inter-)link a detailed analysis on grass-user by Veronika and related PR: > > [GRASS-user] Problems on MacOS Catalina Installation via Homebrew "Cannot > find proj.db" > https://lists.osgeo.org/pipermail/grass-user/2020-March/081377.html > <https://lists.osgeo.org/pipermail/grass-user/2020-March/081377.html> > > [Bug] Update build GRASS as macOS application #457 (linked comment and below) > https://github.com/OSGeo/grass/issues/457#issuecomment-603575140 > <https://github.com/OSGeo/grass/issues/457#issuecomment-603575140> > > Vaclav > > On Sun, Mar 8, 2020 at 12:35 PM Rainer M Krug <mailto:rai...@krugs.de>> wrote: > > >> On 6 Mar 2020, at 18:40, Markus Metz > <mailto:markus.metz.gisw...@gmail.com>> wrote: >> >> >> >> On Fri, Mar 6, 2020 at 8:50 AM Rainer M Krug > <mailto:rai...@krugs.de>> wrote: >> > >> > OK. Looking at the parameters GRASS is compiled with (grass78 —config), I >> > get the following proj related parameter (the complete output at the end >> > of the email): >> > >> > --with-proj-includes=/usr/local/opt/osgeo-proj/include >> > --with-proj-libs=/usr/local/opt/osgeo-proj/lib >> > --with-proj-share=/usr/local/opt/osgeo-proj/share/proj >> > >> > Which seem to be correct, and proj.db is in the proj-share directory. >> > >> > >> > 08:37 $ ls -la /usr/local/opt/osgeo-proj/share/proj >> > total 12408 >> > drwxr-xr-x 15 rainerkrug staff 480 Feb 10 11:16 . >> > drwxr-xr-x 4 rainerkrug staff 128 Feb 10 11:16 .. >> > -rw-r--r-- 1 rainerkrug staff 1183 Feb 10 11:16 CH >> > -rw-r--r-- 1 rainerkrug staff 728 Feb 10 11:16 GL27 >> > -rw-r--r-- 1 rainerkrug staff 2099 Feb 10 11:16 ITRF2000 >> > -rw-r--r-- 1 rainerkrug staff 3660 Feb 10 11:16 ITRF2008 >> > -rw-r--r-- 1 rainerkrug staff 3468 Feb 10 11:16 ITRF2014 >> > -rw-r--r-- 1 rainerkrug staff 6385 Feb 10 11:16 nad.lst >> > -rw-r--r-- 1 rainerkrug staff19535 Feb 10 11:16 nad27 >> > -rw-r--r-- 1 rainerkrug staff16593 Feb 10 11:16 nad83 >> > -rw-r--r-- 1 rainerkrug staff 232 Feb 10 11:16 null >> > -rw-r--r-- 1 rainerkrug staff 3915 Feb 10 11:16 other.extra >> > -rw-r--r-- 1 rainerkrug staff 6234112 Feb 10 11:16 proj.db >> > -rw-r--r-- 1 rainerkrug staff32060 Feb 10 11:16 projjson.schema.json >> > -rw-r--r-- 1 rainerkrug staff 7079 Feb 10 11:16 world >> > >> > >> > So it looks fine, but I, even locally, get the following error when >> > running the simple test: >> > >> > 08:40 $ grass78 --tmp-location EPSG:4326 --exec g.region res=0.1 -p >> > Starting GRASS GIS... >> > Creating new GRASS GIS location ... >> > ERROR: b'proj_get_authorities_from_database: Cannot find proj.db >> >> This error comes directly from PROJ. >> Try >> export PROJ_LIB="usr/local/opt/osgeo-proj/share/proj" >> >> before starting GRASS. This will tell PROJ where its own share data are. > > > > Does not work: > > 17:03 $ export PROJ_LIB="/usr/local/opt/osgeo-proj/share/proj" > ✔ ~ > 17:03 $ grass78 --tmp-location EPSG:4326 --exec g.region res=0.1 -p > Starting GRASS GIS... > Creating new GRASS GIS location ... > ERROR: b'proj_get_authorities_from_database: Cannot find proj.db > > Exiting... > ✘-1 ~ > 17:03 $ ls -la /usr/local/opt/osgeo-proj/share/proj > total 12408 > drwxr-xr-x 15 rainerkrug staff 480 Feb 10 11:16 . > drwxr-xr-x 4 rainerkrug staff 128 Feb 10 11:16 .. > -rw-r--r-- 1 rainerkrug staff 1183 Feb 10 11:16 CH > -rw-r--r-- 1 rainerkrug staff 728 Feb 10 11:16 GL27 > -rw-r--r-- 1 rainerkrug staff 2099 Feb 10 11:16 ITRF2000 > -rw-r--r-- 1 rainerkrug staff 3660 Feb 10 11:16 ITRF2008 > -rw-r--r-- 1 rainerkrug staff 3468 Feb 10 11:16 ITRF2014 > -rw-r--r-- 1 rainerkrug staff 6385 Feb 10 11:16 nad.lst > -rw-r--r-- 1 rainerkrug staff19535 Feb 10 11:16 nad27 > -rw-r--r-- 1 rainerkrug staff16593 Feb 10 11:16 nad83 > -rw-r--r-- 1 rainerkrug staff 232 Feb 10 11:16 null > -rw-r--r-- 1 rainerkrug staff 3915 Feb 10 11:16 other.extra > -rw-r--r-- 1 rainerkrug staff 6234112
Re: [GRASS-dev] Automatic/CI compilation on macOS
> On 6 Mar 2020, at 18:40, Markus Metz wrote: > > > > On Fri, Mar 6, 2020 at 8:50 AM Rainer M Krug <mailto:rai...@krugs.de>> wrote: > > > > OK. Looking at the parameters GRASS is compiled with (grass78 —config), I > > get the following proj related parameter (the complete output at the end of > > the email): > > > > --with-proj-includes=/usr/local/opt/osgeo-proj/include > > --with-proj-libs=/usr/local/opt/osgeo-proj/lib > > --with-proj-share=/usr/local/opt/osgeo-proj/share/proj > > > > Which seem to be correct, and proj.db is in the proj-share directory. > > > > > > 08:37 $ ls -la /usr/local/opt/osgeo-proj/share/proj > > total 12408 > > drwxr-xr-x 15 rainerkrug staff 480 Feb 10 11:16 . > > drwxr-xr-x 4 rainerkrug staff 128 Feb 10 11:16 .. > > -rw-r--r-- 1 rainerkrug staff 1183 Feb 10 11:16 CH > > -rw-r--r-- 1 rainerkrug staff 728 Feb 10 11:16 GL27 > > -rw-r--r-- 1 rainerkrug staff 2099 Feb 10 11:16 ITRF2000 > > -rw-r--r-- 1 rainerkrug staff 3660 Feb 10 11:16 ITRF2008 > > -rw-r--r-- 1 rainerkrug staff 3468 Feb 10 11:16 ITRF2014 > > -rw-r--r-- 1 rainerkrug staff 6385 Feb 10 11:16 nad.lst > > -rw-r--r-- 1 rainerkrug staff19535 Feb 10 11:16 nad27 > > -rw-r--r-- 1 rainerkrug staff16593 Feb 10 11:16 nad83 > > -rw-r--r-- 1 rainerkrug staff 232 Feb 10 11:16 null > > -rw-r--r-- 1 rainerkrug staff 3915 Feb 10 11:16 other.extra > > -rw-r--r-- 1 rainerkrug staff 6234112 Feb 10 11:16 proj.db > > -rw-r--r-- 1 rainerkrug staff32060 Feb 10 11:16 projjson.schema.json > > -rw-r--r-- 1 rainerkrug staff 7079 Feb 10 11:16 world > > > > > > So it looks fine, but I, even locally, get the following error when running > > the simple test: > > > > 08:40 $ grass78 --tmp-location EPSG:4326 --exec g.region res=0.1 -p > > Starting GRASS GIS... > > Creating new GRASS GIS location ... > > ERROR: b'proj_get_authorities_from_database: Cannot find proj.db > > This error comes directly from PROJ. > Try > export PROJ_LIB="usr/local/opt/osgeo-proj/share/proj" > > before starting GRASS. This will tell PROJ where its own share data are. Does not work: 17:03 $ export PROJ_LIB="/usr/local/opt/osgeo-proj/share/proj" ✔ ~ 17:03 $ grass78 --tmp-location EPSG:4326 --exec g.region res=0.1 -p Starting GRASS GIS... Creating new GRASS GIS location ... ERROR: b'proj_get_authorities_from_database: Cannot find proj.db Exiting... ✘-1 ~ 17:03 $ ls -la /usr/local/opt/osgeo-proj/share/proj total 12408 drwxr-xr-x 15 rainerkrug staff 480 Feb 10 11:16 . drwxr-xr-x 4 rainerkrug staff 128 Feb 10 11:16 .. -rw-r--r-- 1 rainerkrug staff 1183 Feb 10 11:16 CH -rw-r--r-- 1 rainerkrug staff 728 Feb 10 11:16 GL27 -rw-r--r-- 1 rainerkrug staff 2099 Feb 10 11:16 ITRF2000 -rw-r--r-- 1 rainerkrug staff 3660 Feb 10 11:16 ITRF2008 -rw-r--r-- 1 rainerkrug staff 3468 Feb 10 11:16 ITRF2014 -rw-r--r-- 1 rainerkrug staff 6385 Feb 10 11:16 nad.lst -rw-r--r-- 1 rainerkrug staff19535 Feb 10 11:16 nad27 -rw-r--r-- 1 rainerkrug staff16593 Feb 10 11:16 nad83 -rw-r--r-- 1 rainerkrug staff 232 Feb 10 11:16 null -rw-r--r-- 1 rainerkrug staff 3915 Feb 10 11:16 other.extra -rw-r--r-- 1 rainerkrug staff 6234112 Feb 10 11:16 proj.db -rw-r--r-- 1 rainerkrug staff32060 Feb 10 11:16 projjson.schema.json -rw-r--r-- 1 rainerkrug staff 7079 Feb 10 11:16 world Any other suggestion? > > Markus M > > > > > > > > > Here is the complete output from --config: > > > > 08:35 $ grass78 --config > > x86_64-apple-darwin17.7.0 > > ./configure --prefix=/usr/local/Cellar/osgeo-grass/7.8.2_3 --with-cxx > > --enable-shared --enable-largefile --with-nls > > --with-includes=/usr/local/include --with-libs=/usr/local/LIB > > --with-python=/usr/local/Cellar/osgeo-grass/7.8.2_3/libexec/vendor/bin/python-config > > --with-tcltk --with-netcdf=/usr/local/opt/osgeo-netcdf/bin/nc-config > > --with-zstd --with-zstd-includes=/usr/local/opt/zstd/include > > --with-zstd-libs=/usr/local/opt/zstd/lib --with-readline > > --with-readline-includes=/usr/local/opt/readline/include > > --with-readline-libs=/usr/local/opt/readline/lib --with-blas > > --with-blas-includes=/usr/local/opt/openblas/include > > --with-blas-libs=/usr/local/opt/openblas/lib --with-lapack > > --with-lapack-includes=/usr/local/opt/lapack/include > > --with-lapack-libs=/usr/local/opt/lapack/lib > > --with-geos=/usr/local/opt/geos/bin/geos-config > > --with-geos-includes=/usr/local/opt/geos/include >
Re: [GRASS-dev] Automatic/CI compilation on macOS
line 2025,
in main
index = sys.argv.index(batch_exec_param)
ValueError: '--exec' is not in list
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/Cellar/osgeo-grass/7.8.2_3/libexec/bin/grass78", line 2216,
in
main()
File "/usr/local/Cellar/osgeo-grass/7.8.2_3/libexec/bin/grass78", line 2030,
in main
params = parse_cmdline(sys.argv[1:], default_gui=default_gui)
File "/usr/local/Cellar/osgeo-grass/7.8.2_3/libexec/bin/grass78", line 1951,
in parse_cmdline
print_params()
File "/usr/local/Cellar/osgeo-grass/7.8.2_3/libexec/bin/grass78", line 1862,
in print_params
"%s\n" % val[0].split(':')[1].rstrip('$"\n').strip())
IndexError: list index out of range
Any suggestions what the problem is?
Rainer
> On 5 Mar 2020, at 21:38, Vaclav Petras wrote:
>
>
>
> On Thu, Mar 5, 2020 at 1:52 PM Rainer M Krug <mailto:rai...@krugs.de>> wrote:
>
>
>> On 5 Mar 2020, at 17:53, Vaclav Petras > <mailto:wenzesl...@gmail.com>> wrote:
>>
>>
>>
>> On Thu, Mar 5, 2020 at 11:37 AM Rainer M Krug > <mailto:rai...@krugs.de>> wrote:
>> OK - one step closer to success. Now I just have to know the location where
>> the data for the tests can be downloaded from (I guess).
>>
>> Everything is in the repo, well, it needs to be, I guess the only question
>> is where in the repo, so:
>>
>> https://github.com/GRASS-GIS/grass-gis-experimental-ci/blob/homebrew-osgeo4mac/test_thorough.sh
>>
>> <https://github.com/GRASS-GIS/grass-gis-experimental-ci/blob/homebrew-osgeo4mac/test_thorough.sh>
>>
>> Please check the log to at
>> https://github.com/GRASS-GIS/grass-gis-experimental-ci/runs/487969965?check_suite_focus=true
>>
>> <https://github.com/GRASS-GIS/grass-gis-experimental-ci/runs/487969965?check_suite_focus=true>
>> for the Basic test and the Thorough test. I will look at the return code
>> later, when the tests are running.
>>
>> The problem there is probably a bad/missing path to PROJ db. I think it
>> complains during the configuration already, so perhaps correct
>> --with-proj-share will fix it. The runtime way of setting it is PROJ_LIB
>> environmental variable. You can try something along these lines.
>
> I am trying to find the file `proj.db` but can’t find it - can you give me
> any indication, where it can be found in Linux (home-brew should use similar
> locations)?
>
> Often it is in `/usr/share/proj`. Now you can find things like that in the
> Docker/Singularity/Vagrant configurations included in GRASS GIS source code
> or in the CIs, e.g., here:
>
> https://github.com/GRASS-GIS/grass-gis-experimental-ci/blob/master/build.sh#L39
>
> <https://github.com/GRASS-GIS/grass-gis-experimental-ci/blob/master/build.sh#L39>
>
>
>
>
>>
>>
>> Rainer
>>
>>
>>
>>> On 5 Mar 2020, at 16:28, Rainer M Krug >> <mailto:rai...@krugs.de>> wrote:
>>>
>>>
>>>
>>>> On 5 Mar 2020, at 16:22, Rainer M Krug >>> <mailto:rai...@krugs.de>> wrote:
>>>>
>>>>
>>>>
>>>>> On 5 Mar 2020, at 14:52, Vaclav Petras >>>> <mailto:wenzesl...@gmail.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 5, 2020 at 4:27 AM Rainer M Krug >>>> <mailto:rai...@krugs.de>> wrote:
>>>>> OK - found the ci.
>>>>>
>>>>> The formula installs, but I get a warning at the end, which results in a
>>>>> warning, which is than interpreted as an error. The warning (which I also
>>>>> get locally) is the following:
>>>>>
>>>>> If it is the case that you can change the shebang at the beginning of
>>>>>
>>>>> he script to enforce Python 3 usage.
>>>>>
>>>>> #!/usr/bin/env python
>>>>>
>>>>> Should be changed into
>>>>>
>>>>> #!/usr/bin/env python3
>>>>>
>>>>>
>>>>> I suspect that this needs to be done in GRASS itself?
>>>>>
>>>>> Hi, thanks for looking into this. 7.8.2 (and also above) has python3
>>>>> everywhere in shebang. See e.g.:
>>>>>
>>>>> $ grep -Irn "/usr/bin/env python[^3]"
>>>>> scripts/g.extension/g.extension.py:1059 <http://g.extension.py:1059/>:
>>>>
Re: [GRASS-dev] Automatic/CI compilation on macOS
> On 5 Mar 2020, at 17:53, Vaclav Petras wrote: > > > > On Thu, Mar 5, 2020 at 11:37 AM Rainer M Krug <mailto:rai...@krugs.de>> wrote: > OK - one step closer to success. Now I just have to know the location where > the data for the tests can be downloaded from (I guess). > > Everything is in the repo, well, it needs to be, I guess the only question is > where in the repo, so: > > https://github.com/GRASS-GIS/grass-gis-experimental-ci/blob/homebrew-osgeo4mac/test_thorough.sh > > <https://github.com/GRASS-GIS/grass-gis-experimental-ci/blob/homebrew-osgeo4mac/test_thorough.sh> > > Please check the log to at > https://github.com/GRASS-GIS/grass-gis-experimental-ci/runs/487969965?check_suite_focus=true > > <https://github.com/GRASS-GIS/grass-gis-experimental-ci/runs/487969965?check_suite_focus=true> > for the Basic test and the Thorough test. I will look at the return code > later, when the tests are running. > > The problem there is probably a bad/missing path to PROJ db. I think it > complains during the configuration already, so perhaps correct > --with-proj-share will fix it. The runtime way of setting it is PROJ_LIB > environmental variable. You can try something along these lines. I am trying to find the file `proj.db` but can’t find it - can you give me any indication, where it can be found in Linux (home-brew should use similar locations)? Thanks, Rainer > > > Rainer > > > >> On 5 Mar 2020, at 16:28, Rainer M Krug > <mailto:rai...@krugs.de>> wrote: >> >> >> >>> On 5 Mar 2020, at 16:22, Rainer M Krug >> <mailto:rai...@krugs.de>> wrote: >>> >>> >>> >>>> On 5 Mar 2020, at 14:52, Vaclav Petras >>> <mailto:wenzesl...@gmail.com>> wrote: >>>> >>>> >>>> >>>> On Thu, Mar 5, 2020 at 4:27 AM Rainer M Krug >>> <mailto:rai...@krugs.de>> wrote: >>>> OK - found the ci. >>>> >>>> The formula installs, but I get a warning at the end, which results in a >>>> warning, which is than interpreted as an error. The warning (which I also >>>> get locally) is the following: >>>> >>>> If it is the case that you can change the shebang at the beginning of >>>> >>>> he script to enforce Python 3 usage. >>>> >>>> #!/usr/bin/env python >>>> >>>> Should be changed into >>>> >>>> #!/usr/bin/env python3 >>>> >>>> >>>> I suspect that this needs to be done in GRASS itself? >>>> >>>> Hi, thanks for looking into this. 7.8.2 (and also above) has python3 >>>> everywhere in shebang. See e.g.: >>>> >>>> $ grep -Irn "/usr/bin/env python[^3]" >>>> scripts/g.extension/g.extension.py:1059 <http://g.extension.py:1059/>: >>>>"#!/usr/bin/env python\n", >>>> scripts/g.extension/g.extension.py:1308 <http://g.extension.py:1308/>: >>>>"#!/usr/bin/env python\n", >>>> # (these two are in fact code which is doing the replacement to python3) >>>> >>>> Can you please investigate locally where the message coming from? >>> >>> The message comes from the formula as a Caveat. I *think* it is always >>> displayed. But at the moment, I am not to sure where the error code comes >>> from, as I get an error code at the end of the brew command of 0 locally. >>> >>> I will look into this. >> >> Please ignore the following about the checkout. >> >> Found it. >> >>> >>> Do you know, why there is a >>> >>> - uses: actions/checkout@v2 >>> >>> In the action? >>> >>> It seems, that it will be executed last, and there is no checkout needed. >>> >>> Rainer >>> >>> >>>> >>>> Vaclav >>> >>> -- >>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, >>> UCT), Dipl. Phys. (Germany) >>> >>> Orcid ID: -0002-7490-0066 >>> >>> Department of Evolutionary Biology and Environmental Studies >>> University of Zürich >>> Office Y34-J-74 >>> Winterthurerstrasse 190 >>> 8075 Zürich >>> Switzerland >>> >>> Office: +41 (0)44 635 47 64 >>> Cell: +41 (0)78 630 66 57 >>&
Re: [GRASS-dev] Automatic/CI compilation on macOS
OK - one step closer to success. Now I just have to know the location where the data for the tests can be downloaded from (I guess). Please check the log to at https://github.com/GRASS-GIS/grass-gis-experimental-ci/runs/487969965?check_suite_focus=true <https://github.com/GRASS-GIS/grass-gis-experimental-ci/runs/487969965?check_suite_focus=true> for the Basic test and the Thorough test. I will look at the return code later, when the tests are running. Rainer > On 5 Mar 2020, at 16:28, Rainer M Krug wrote: > > > >> On 5 Mar 2020, at 16:22, Rainer M Krug > <mailto:rai...@krugs.de>> wrote: >> >> >> >>> On 5 Mar 2020, at 14:52, Vaclav Petras >> <mailto:wenzesl...@gmail.com>> wrote: >>> >>> >>> >>> On Thu, Mar 5, 2020 at 4:27 AM Rainer M Krug >> <mailto:rai...@krugs.de>> wrote: >>> OK - found the ci. >>> >>> The formula installs, but I get a warning at the end, which results in a >>> warning, which is than interpreted as an error. The warning (which I also >>> get locally) is the following: >>> >>> If it is the case that you can change the shebang at the beginning of >>> >>> he script to enforce Python 3 usage. >>> >>> #!/usr/bin/env python >>> >>> Should be changed into >>> >>> #!/usr/bin/env python3 >>> >>> >>> I suspect that this needs to be done in GRASS itself? >>> >>> Hi, thanks for looking into this. 7.8.2 (and also above) has python3 >>> everywhere in shebang. See e.g.: >>> >>> $ grep -Irn "/usr/bin/env python[^3]" >>> scripts/g.extension/g.extension.py:1059 <http://g.extension.py:1059/>: >>> "#!/usr/bin/env python\n", >>> scripts/g.extension/g.extension.py:1308 <http://g.extension.py:1308/>: >>> "#!/usr/bin/env python\n", >>> # (these two are in fact code which is doing the replacement to python3) >>> >>> Can you please investigate locally where the message coming from? >> >> The message comes from the formula as a Caveat. I *think* it is always >> displayed. But at the moment, I am not to sure where the error code comes >> from, as I get an error code at the end of the brew command of 0 locally. >> >> I will look into this. > > Please ignore the following about the checkout. > > Found it. > >> >> Do you know, why there is a >> >> - uses: actions/checkout@v2 >> >> In the action? >> >> It seems, that it will be executed last, and there is no checkout needed. >> >> Rainer >> >> >>> >>> Vaclav >> >> -- >> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, >> UCT), Dipl. Phys. (Germany) >> >> Orcid ID: -0002-7490-0066 >> >> Department of Evolutionary Biology and Environmental Studies >> University of Zürich >> Office Y34-J-74 >> Winterthurerstrasse 190 >> 8075 Zürich >> Switzerland >> >> Office: +41 (0)44 635 47 64 >> Cell:+41 (0)78 630 66 57 >> email: rainer.k...@uzh.ch <mailto:rainer.k...@uzh.ch> >> rai...@krugs.de <mailto:rai...@krugs.de> >> Skype: RMkrug >> >> PGP: 0x0F52F982 >> >> >> > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, > UCT), Dipl. Phys. (Germany) > > Orcid ID: -0002-7490-0066 > > Department of Evolutionary Biology and Environmental Studies > University of Zürich > Office Y34-J-74 > Winterthurerstrasse 190 > 8075 Zürich > Switzerland > > Office: +41 (0)44 635 47 64 > Cell: +41 (0)78 630 66 57 > email: rainer.k...@uzh.ch <mailto:rainer.k...@uzh.ch> > rai...@krugs.de <mailto:rai...@krugs.de> > Skype: RMkrug > > PGP: 0x0F52F982 -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Orcid ID: -0002-7490-0066 Department of Evolutionary Biology and Environmental Studies University of Zürich Office Y34-J-74 Winterthurerstrasse 190 8075 Zürich Switzerland Office: +41 (0)44 635 47 64 Cell: +41 (0)78 630 66 57 email: rainer.k...@uzh.ch rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Automatic/CI compilation on macOS
> On 5 Mar 2020, at 16:22, Rainer M Krug wrote: > > > >> On 5 Mar 2020, at 14:52, Vaclav Petras > <mailto:wenzesl...@gmail.com>> wrote: >> >> >> >> On Thu, Mar 5, 2020 at 4:27 AM Rainer M Krug > <mailto:rai...@krugs.de>> wrote: >> OK - found the ci. >> >> The formula installs, but I get a warning at the end, which results in a >> warning, which is than interpreted as an error. The warning (which I also >> get locally) is the following: >> >> If it is the case that you can change the shebang at the beginning of >> >> he script to enforce Python 3 usage. >> >> #!/usr/bin/env python >> >> Should be changed into >> >> #!/usr/bin/env python3 >> >> >> I suspect that this needs to be done in GRASS itself? >> >> Hi, thanks for looking into this. 7.8.2 (and also above) has python3 >> everywhere in shebang. See e.g.: >> >> $ grep -Irn "/usr/bin/env python[^3]" >> scripts/g.extension/g.extension.py:1059 <http://g.extension.py:1059/>: >> "#!/usr/bin/env python\n", >> scripts/g.extension/g.extension.py:1308 <http://g.extension.py:1308/>: >> "#!/usr/bin/env python\n", >> # (these two are in fact code which is doing the replacement to python3) >> >> Can you please investigate locally where the message coming from? > > The message comes from the formula as a Caveat. I *think* it is always > displayed. But at the moment, I am not to sure where the error code comes > from, as I get an error code at the end of the brew command of 0 locally. > > I will look into this. Please ignore the following about the checkout. Found it. > > Do you know, why there is a > > - uses: actions/checkout@v2 > > In the action? > > It seems, that it will be executed last, and there is no checkout needed. > > Rainer > > >> >> Vaclav > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, > UCT), Dipl. Phys. (Germany) > > Orcid ID: -0002-7490-0066 > > Department of Evolutionary Biology and Environmental Studies > University of Zürich > Office Y34-J-74 > Winterthurerstrasse 190 > 8075 Zürich > Switzerland > > Office: +41 (0)44 635 47 64 > Cell: +41 (0)78 630 66 57 > email: rainer.k...@uzh.ch <mailto:rainer.k...@uzh.ch> > rai...@krugs.de <mailto:rai...@krugs.de> > Skype: RMkrug > > PGP: 0x0F52F982 > > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Orcid ID: -0002-7490-0066 Department of Evolutionary Biology and Environmental Studies University of Zürich Office Y34-J-74 Winterthurerstrasse 190 8075 Zürich Switzerland Office: +41 (0)44 635 47 64 Cell: +41 (0)78 630 66 57 email: rainer.k...@uzh.ch rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Automatic/CI compilation on macOS
> On 5 Mar 2020, at 14:52, Vaclav Petras wrote:
>
>
>
> On Thu, Mar 5, 2020 at 4:27 AM Rainer M Krug <mailto:rai...@krugs.de>> wrote:
> OK - found the ci.
>
> The formula installs, but I get a warning at the end, which results in a
> warning, which is than interpreted as an error. The warning (which I also get
> locally) is the following:
>
> If it is the case that you can change the shebang at the beginning of
>
> he script to enforce Python 3 usage.
>
> #!/usr/bin/env python
>
> Should be changed into
>
> #!/usr/bin/env python3
>
>
> I suspect that this needs to be done in GRASS itself?
>
> Hi, thanks for looking into this. 7.8.2 (and also above) has python3
> everywhere in shebang. See e.g.:
>
> $ grep -Irn "/usr/bin/env python[^3]"
> scripts/g.extension/g.extension.py:1059 <http://g.extension.py:1059/>:
> "#!/usr/bin/env python\n",
> scripts/g.extension/g.extension.py:1308 <http://g.extension.py:1308/>:
> "#!/usr/bin/env python\n",
> # (these two are in fact code which is doing the replacement to python3)
>
> Can you please investigate locally where the message coming from?
The message comes from the formula as a Caveat. I *think* it is always
displayed. But at the moment, I am not to sure where the error code comes from,
as I get an error code at the end of the brew command of 0 locally.
I will look into this.
Do you know, why there is a
- uses: actions/checkout@v2
In the action?
It seems, that it will be executed last, and there is no checkout needed.
Rainer
>
> Vaclav
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)
Orcid ID: -0002-7490-0066
Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland
Office: +41 (0)44 635 47 64
Cell: +41 (0)78 630 66 57
email: rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug
PGP: 0x0F52F982
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Automatic/CI compilation on macOS
OK - found the ci. The formula installs, but I get a warning at the end, which results in a warning, which is than interpreted as an error. The warning (which I also get locally) is the following: If it is the case that you can change the shebang at the beginning of he script to enforce Python 3 usage. #!/usr/bin/env python Should be changed into #!/usr/bin/env python3 I suspect that this needs to be done in GRASS itself? Rainer > On 5 Mar 2020, at 09:40, Rainer Krug wrote: > > Sorry for chiming in so late - haven’t followed GRASS closely and I might > raise points which have already been discussed. > > I can not comment on conda, as I never used it. > > > I made a fix on the home-brew-osgeo4mac branch as the test using for the brew > test needs the name of the formula. I tried the installation and the brew > test locally, and it works. > > > Where can I see the log from the ci? > > > There were also discussions on the R mailing list to support Conda, and it > definitely has its user base, but O don’t think it is as widely used as > home-brew. So supporting both would be the best option. > > Especially, if I am not mistaken, the support for the osgeo4mac-grass formula > for home-brew is already taken care of by osgeo4mac. > > Cheers, > > Rainer > > > >> On 5 Mar 2020, at 04:58, Vaclav Petras > <mailto:wenzesl...@gmail.com>> wrote: >> >> Dear all, >> >> I made some updates towards updating the conda recipe for GRASS GIS on macOS >> by Eric Hutton, but it is not working yet. You can find the WIP PR here: >> >> https://github.com/csdms-stack/grass-recipe/pull/1 >> <https://github.com/csdms-stack/grass-recipe/pull/1> >> >> You can see the current state in Travis linked from the PR or in GitHub >> Actions of my fork: >> >> https://github.com/wenzeslaus/grass-recipe/tree/updates-for-7.8-and-above >> <https://github.com/wenzeslaus/grass-recipe/tree/updates-for-7.8-and-above> >> https://github.com/wenzeslaus/grass-recipe/actions >> <https://github.com/wenzeslaus/grass-recipe/actions> >> >> If you think a different approach is more appropriate and want to try it >> out, you can consider contributing to the following repository which now, >> for example, contains a homebrew-osgeo4mac based branch. Again see the >> current state in GitHub Actions: >> >> https://github.com/GRASS-GIS/grass-gis-experimental-ci/tree/homebrew-osgeo4mac >> >> <https://github.com/GRASS-GIS/grass-gis-experimental-ci/tree/homebrew-osgeo4mac> >> >> If you have some ideas for fixing the errors, please let me know, here, by >> PRs, issues, or links to other repos. >> >> Thanks, >> Vaclav >> >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org> >> https://lists.osgeo.org/mailman/listinfo/grass-dev > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, > UCT), Dipl. Phys. (Germany) > > Orcid ID: -0002-7490-0066 > > Department of Evolutionary Biology and Environmental Studies > University of Zürich > Office Y34-J-74 > Winterthurerstrasse 190 > 8075 Zürich > Switzerland > > Office: +41 (0)44 635 47 64 > Cell: +41 (0)78 630 66 57 > email: rainer.k...@uzh.ch <mailto:rainer.k...@uzh.ch> > rai...@krugs.de <mailto:rai...@krugs.de> > Skype: RMkrug > > PGP: 0x0F52F982 > > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Orcid ID: -0002-7490-0066 Department of Evolutionary Biology and Environmental Studies University of Zürich Office Y34-J-74 Winterthurerstrasse 190 8075 Zürich Switzerland Office: +41 (0)44 635 47 64 Cell: +41 (0)78 630 66 57 email: rainer.k...@uzh.ch rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass-addons on github
Disadvantage: From the GitHub blog: Managing dynamic, rapidly evolving or heavily co-dependent repositories with submodules can quickly become frustrating. This post was focused on simple, relatively static parent-child repository relationships. A future follow-up post will detail some strategies to help manage more complex submodule workflows. Probably not the easiest and most stable solution… > On 27 May 2019, at 08:55, Rainer M Krug wrote: > > I am no git expert, so this could be completely off. But as far as I > understand it, git submodules > (https://git-scm.com/book/en/v2/Git-Tools-Submodules > <https://git-scm.com/book/en/v2/Git-Tools-Submodules>) are exactly for this > purpose. > > From their description: > > It often happens that while working on one project, you need to use another > project from within it. Perhaps it’s a library that a third party developed > or that you’re developing separately and using in multiple parent projects. A > common issue arises in these scenarios: you want to be able to treat the two > projects as separate yet still be able to use one from within the other. > > Here’s an example. Suppose you’re developing a website and creating Atom > feeds. Instead of writing your own Atom-generating code, you decide to use a > library. You’re likely to have to either include this code from a shared > library like a CPAN install or Ruby gem, or copy the source code into your > own project tree. The issue with including the library is that it’s difficult > to customize the library in any way and often more difficult to deploy it, > because you need to make sure every client has that library available. The > issue with copying the code into your own project is that any custom changes > you make are difficult to merge when upstream changes become available. > > Git addresses this issue using submodules. Submodules allow you to keep a Git > repository as a subdirectory of another Git repository. This lets you clone > another repository into your project and keep your commits separate. > > > The different add-ons could be added as submodules, so they > would be in separate repos, > you don’t have to download all if you are only working on one, > the core team can exclude them easily if they do not work anymore from the > general build process (and re-add them as easy), > Are treated, when complaint (as mentioned the windows binaries) as one single > repo. > Developers of add-ons do not need write access to the core repo > > Here is another link to the GitHub blog on how they can be used: > https://github.blog/2016-02-01-working-with-submodules/ > <https://github.blog/2016-02-01-working-with-submodules/> > > Cheers, > > Rainer > > > > >> On 25 May 2019, at 17:04, Markus Neteler > <mailto:nete...@osgeo.org>> wrote: >> >> On Fri, May 24, 2019 at 4:25 PM Stefan Blumentrath >> mailto:stefan.blumentr...@nina.no>> wrote: >>> >>> Hi, >>> >>> Collecting addons in a central repo seems very valuable to me too, for all >>> the reasons Vacslav mentioned. >> >> +1 >> >>> I am no git expert either, but PRs should not be a big issue to do (unless >>> you are VERY productive). People could merge their own PRs, no? >> >> Exactly. >> >>> Creating a PR, does not mean it has to be reviewed by another dev, right? >>> In my organization colleagues even usr PRs for repos where they are the >>> only contributor... >> >> I also prefer PRs. At least the changes have a chance to be reviewed >> and appear more traceable. >> >>> I would argue having procedures as equal as possible between addons and >>> core is just beneficial. Less confusion, fewer guidelines to maimtain, >>> possibility to have CI before things are merged, and training for new devs >>> that evolve from addon-dev to core-dev... >> >> +1^2 >> >> Cheers, >> Markus >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org> >> https://lists.osgeo.org/mailman/listinfo/grass-dev > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, > UCT), Dipl. Phys. (Germany) > > Orcid ID: -0002-7490-0066 > > Department of Evolutionary Biology and Environmental Studies > University of Zürich > Office Y34-J-74 > Winterthurerstrasse 190 > 8075 Zürich > Switzerland > > Office: +41 (0)44 635 47 64 > Cell: +41 (0)78 630 66 57 > email: rainer.k...@uzh.ch <mailto:rainer.k.
Re: [GRASS-dev] grass-addons on github
I am no git expert, so this could be completely off. But as far as I understand it, git submodules (https://git-scm.com/book/en/v2/Git-Tools-Submodules <https://git-scm.com/book/en/v2/Git-Tools-Submodules>) are exactly for this purpose. From their description: It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other. Here’s an example. Suppose you’re developing a website and creating Atom feeds. Instead of writing your own Atom-generating code, you decide to use a library. You’re likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. The issue with including the library is that it’s difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available. The issue with copying the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available. Git addresses this issue using submodules. Submodules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project and keep your commits separate. The different add-ons could be added as submodules, so they would be in separate repos, you don’t have to download all if you are only working on one, the core team can exclude them easily if they do not work anymore from the general build process (and re-add them as easy), Are treated, when complaint (as mentioned the windows binaries) as one single repo. Developers of add-ons do not need write access to the core repo Here is another link to the GitHub blog on how they can be used: https://github.blog/2016-02-01-working-with-submodules/ <https://github.blog/2016-02-01-working-with-submodules/> Cheers, Rainer > On 25 May 2019, at 17:04, Markus Neteler wrote: > > On Fri, May 24, 2019 at 4:25 PM Stefan Blumentrath > wrote: >> >> Hi, >> >> Collecting addons in a central repo seems very valuable to me too, for all >> the reasons Vacslav mentioned. > > +1 > >> I am no git expert either, but PRs should not be a big issue to do (unless >> you are VERY productive). People could merge their own PRs, no? > > Exactly. > >> Creating a PR, does not mean it has to be reviewed by another dev, right? In >> my organization colleagues even usr PRs for repos where they are the only >> contributor... > > I also prefer PRs. At least the changes have a chance to be reviewed > and appear more traceable. > >> I would argue having procedures as equal as possible between addons and core >> is just beneficial. Less confusion, fewer guidelines to maimtain, >> possibility to have CI before things are merged, and training for new devs >> that evolve from addon-dev to core-dev... > > +1^2 > > Cheers, > Markus > ___________ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Orcid ID: -0002-7490-0066 Department of Evolutionary Biology and Environmental Studies University of Zürich Office Y34-J-74 Winterthurerstrasse 190 8075 Zürich Switzerland Office: +41 (0)44 635 47 64 Cell: +41 (0)78 630 66 57 email: rainer.k...@uzh.ch rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] github / travis sync - push file to grass-gis/homebrew-grass-dev repo when grass-gis is synsed to svn?
Hi Would it be possible to push a file containing e.g. the time to grass-gis/homebrew-grass-dev? The content of the file does not matter, but e.g. the time would be fine. I have just created a travis-ci test for the homebrew-grass-dev repo and if it would be possible to push a file to this repo whenever the github grass-gis/grass-ci is updated, we would have tests of the Mac build via homebrew which is separate from the test for Linux. Cheers, Rainer -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1898 (master - 7fa0125)
Vaclav Petras <wenzesl...@gmail.com> writes: > On Mon, Feb 6, 2017 at 8:50 AM, Markus Neteler <nete...@osgeo.org> wrote: > > > Otherwise, there is no problem at all with using the git repo. > > Perhaps yes if that brings back the Mac tests at lowest cost > > Assuming that the Homebrew repo will be tested separately, the question is if > we want to bring in another dependency - OSGeo Subversion to GitHub sync - or > if we want to keep > dependencies to minimum. For now, getting code from GitHub is the only way it > works because of the broken SSL certificates, so sure we can use it, but > that's for now. > I can look into these issues beginning of March but I agree that that using the github would be the best solution and the homebrew should be tested separately. Rainer -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1898 (master - 7fa0125)
Markus Neteler <nete...@osgeo.org> writes: > On Mon, Feb 6, 2017 at 8:52 AM, Rainer M Krug <rai...@krugs.de> wrote: >> Markus Neteler <nete...@osgeo.org> writes: >> How do you mean? The script is in the folder .travis (hidden to be >> in line with the naming of the .travis.yml file and as it is of no >> importance for GRASS itself). There were the scripts (see changeset >> https://trac.osgeo.org/grass/changeset/70483 ) > > Yes - I was just wondering where the "svn" call is located which I > cannot see in these scripts. There is some magic involved - there are the lines , | head do | url "https://svn.osgeo.org/grass/grass/trunk; | end ` which specify the URL and homebrew is "doing the right thing" to download the repo for compilation. Rainer > > Markus -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1898 (master - 7fa0125)
Markus Neteler <nete...@osgeo.org> writes: > On Thu, Feb 2, 2017 at 11:03 AM, Markus Neteler <nete...@osgeo.org> wrote: >> On Mon, Jan 30, 2017 at 11:20 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: >> ... >>> Daily build of the Homebrew formula repo seems more appropriate for testing >>> than the workaround in the code. >>> >>> Since Travis CI is not 100% reliable for Mac, it will also separate all the >>> false positives. It still can send messages to grass-dev (all Travis is >>> already white listed, right?) but more people should get access to the repo >>> if that's the case. >> >> Silly question: why does our Mac script fetch from SVN and not from >> git? This would solve it. > > Extra question: where is the script actually doing this job? How do you mean? The script is in the folder .travis (hidden to be in line with the naming of the .travis.yml file and as it is of no importance for GRASS itself). There were the scripts (see changeset https://trac.osgeo.org/grass/changeset/70483 ) Rainer > > Markus -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1898 (master - 7fa0125)
Markus Neteler <nete...@osgeo.org> writes: > On Mon, Jan 30, 2017 at 11:20 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > ... >> Daily build of the Homebrew formula repo seems more appropriate for testing >> than the workaround in the code. >> >> Since Travis CI is not 100% reliable for Mac, it will also separate all the >> false positives. It still can send messages to grass-dev (all Travis is >> already white listed, right?) but more people should get access to the repo >> if that's the case. > > Silly question: why does our Mac script fetch from SVN and not from > git? This would solve it. It is using the svn repo, as it is the original GRASS repo. Technically, there would be no problem at all to use the git repo, but I thought it makes more sense to rely on the original authoritative repo. Otherwise, there is no problem at all with using the git repo. Rainer > > Markus -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Adding an expert mode to the parser
Moritz Lennert <mlenn...@club.worldonline.be> writes: > On 26/09/16 23:50, Vaclav Petras wrote: >> >> On Mon, Sep 26, 2016 at 5:24 PM, Veronica Andreo <veroand...@gmail.com >> <mailto:veroand...@gmail.com>> wrote: >> >> I'm with MaDi in that if I see a very long list of flags and >> parameters in the terminal when using --h, i just go to the >> manual... I just use --h in CLI for a quick recalling of >> flags/options... A reduced list of most commonly used flags would be >> nice, but still keep the possibility to get the advanced >> flags/parameters as well, if the user needs more info... >> >> >> If the --help is just for scanning and the issue is that it simply too >> long, hiding some parameters is not the only option we have. For many >> (and more in the future hopefully) parameters we have (short) label and >> (longer) description. --help prints both (if both are present, that's at >> least 2 lines per parameter). Additionally, if the option has predefined >> values which have descriptions, there is one line for each of those. So, >> the question is would it be helpful (at least as a first step) if --help >> would print less information for each parameter but still provided all >> parameters? > > In line with your other mail where you caution about "hiding" useful > information, how about not changing the --help output, but rather > adding a "--simple-help" or somthing like this which would output a > simplified help. Although: Everybody is so used to using --help (or -h) that I don't think that an --simple-help would do any good. Instead, possibly -hh (as in -vv for more verbose) and mention this in the first line of the help? This would open even for -hhh if most advanced options are there. Concerning --help, this should possibly change to displaying the basic -h Rainer > >> and manual pages then (a tab or section for advanced >> flags/parameters)... >> >> >> Considering that we have currently as system of (gui) sections which >> place the options to individual tabs in GUI, isn't showing the different >> sections in the manual the right thing to do? > > I would prefer this: show everything, but structure it differently, > i.e. possibly introduce a new parser keyword (advanced: yes) which > would put the option into a specific section of the manual. IMHO, this > should be independent of the GUI sections logic as one might to group > less advanced and advanced options in the same thematic tab... > >> IMHO, a major issue however is the lack of examples for the usage of >> more advanced flags or options (or even the required and more common >> ones). Take the case of several i.* modules, for example... but maybe >> this should go in a separate thread :-) >> >> >> Good point. If you have an explanation and example for a flag, perhaps >> you can understand it and it is not so advanced at the end. > > I think this is actually a major issue: man pages without description, > notes and example sections are almost useless IMHO. At the foss4g.be > last week someone presented a simple use of GRASS GIS (to create this > map [1] for television) and explained how he actually found the GRASS > GIS manual system extremely well done and useful, because of the > explanations and examples... > > Moritz > > [1] http://www.rtbf.be/services/meteo/apere > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core
Markus Neteler <nete...@osgeo.org> writes: > On Mon, Jul 4, 2016 at 11:00 AM, Rainer M Krug <rai...@krugs.de> wrote: >> Vaclav Petras <wenzesl...@gmail.com> writes: >>> This is out-of-topic here, but similarly we might want to introduce >>> something like [deprecated] for modules, options and flags. >>> > ... >>> Related to that, I wonder if we should create some standard >>> mechanism for introducing experimental things - things which might >>> later show as unstable, >>> not useful or buggy. For example, I introduced v.decimate which is >>> now in 7.2 branch. It has its merit but I started to think that >>> perhaps a different set of >>> functions or interface can be more useful there. I wonder if I >>> should just put [experimental - use with care] at the end of the >>> module description. >> >> I would add the following: >> >> 1) add [experimental] / [beta] / ... behind the in the menu >> 2) disable the experimental / beta / ... addons >> 3) add an option to enable all the experimental / beta / ... addons, which >> can than state >> "experimental, might make your computer explode, use at own risk and only in >> well ventilated rooms"... >> >> Cheers, >> >> Rainer > > Please open a dedicated ticket for this. Done: https://trac.osgeo.org/grass/ticket/3092 Rainer > > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core
Vaclav Petras <wenzesl...@gmail.com> writes: > On Sun, Jul 3, 2016 at 6:32 PM, Markus Neteler <nete...@osgeo.org> wrote: > > The general criteria are > - code follows submission standards > - must be portable > - must be well documented with examples > - must be of interest to a wider audience > > I would add "well tested (i.e. very mature) or having somebody willing to fix > it (soon) if needed". > > Related to that, I wonder if we should create some standard mechanism for > introducing experimental things - things which might later show as unstable, > not useful or buggy. For example, I introduced v.decimate which is now in 7.2 > branch. It has its merit but I started to think that perhaps a different set > of > functions or interface can be more useful there. I wonder if I should just > put [experimental - use with care] at the end of the module description. I would add the following: 1) add [experimental] / [beta] / ... behind the in the menu 2) disable the experimental / beta / ... addons 3) add an option to enable all the experimental / beta / ... addons, which can than state "experimental, might make your computer explode, use at own risk and only in well ventilated rooms"... Cheers, Rainer > > This is out-of-topic here, but similarly we might want to introduce something > like [deprecated] for modules, options and flags. > > Vaclav > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Towards SVN - git integration
Jachym Cepicky <jachym.cepi...@gmail.com> writes: > Hi, > > (after a while) > > I agree with Rainer - and I understand the conservative point of view > - and still remember last change from cvs to svn. Meanwhile, couple of > you might have custom scripts which do enable similar magic in svn, > which are natural to git (without any need for hacking). Git really > makes it *very* easy to merge code and solve conflicts, not to mention > possibility of forking and pulling from various repos (more organised > way of accepting someone's code). Just to clearify - forking and pull and push requests are github features - not git. Nowadays github is so sexy, that its features are often confused with being git features. > I think, it's possible to have the main repo in Git and access it with > svn client, if I'm not mistaken. But moving to git as main repo would > be wise option IMHO. > > Github certainly is great service. Custom GitLab instance on (OSGeo?) > server should certainly be considered. In the long run would a GitLab server possibly be the best option. But in the meantime a move to github would be the easiest and all features for which github is famous are there. > But what is the difference between GitHub and Intevation (for those, > who remember)? Just the scale business model IMHO, but the principal > is the same - private companies hosting infrastructure for open source > projects. This is exactly why many dislike github. But as you said, gitlab is also an option which has very nice features (also CI for testing). Cheers, Rainer > > Just my 2 cents > > J > > čt 9. 6. 2016 v 11:37 odesílatel Rainer M Krug <rai...@krugs.de> napsal: > > Markus Neteler <nete...@osgeo.org> writes: > > > Hi devs, > > > > at time I am aware of two GRASS GIS related git instances: > > > > * https://github.com/GRASS-GIS (used for Travis CI, in sync) > > * https://git.osgeo.org/gogs/grass/grassgis (slighly outdated) > > > > It would be nice to go towards a bidirectional SVN <--> git(hub) > > integration in order to collect easily contributions. > > > > Any suggestions how to proceed? > > I know there are many who prefer svn to git, but the question is if the > main repo should migrate from svn to git. > > If the decision is to have a git(hub) repo, I would suggest completely > moving to git. > > I don't think one can reliably and automatically keep two repos in sync. > > As it looks now, grass-ci seems to be updated automatically. > > Cheers, > > Rainer > > > > > Markus > > ___ > > grass-dev mailing list > > grass-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/grass-dev > > -- > Rainer M. Krug > email: Rainerkrugsde > PGP: 0x0F52F982 > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Travis-ci and tests of grass 7
Markus Neteler <nete...@osgeo.org> writes: > On Thu, Jun 9, 2016 at 11:14 AM, Rainer M Krug <rai...@krugs.de> wrote: > ... >> Just realized the on-failure notification=s are still disabled - please >> see my pull request where I enabled them again. >> >> https://github.com/GRASS-GIS/grass-ci/pull/2 > > Done in r68656. Thanks Rainer > > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Towards SVN - git integration
Markus Neteler <nete...@osgeo.org> writes: > Hi devs, > > at time I am aware of two GRASS GIS related git instances: > > * https://github.com/GRASS-GIS (used for Travis CI, in sync) > * https://git.osgeo.org/gogs/grass/grassgis (slighly outdated) > > It would be nice to go towards a bidirectional SVN <--> git(hub) > integration in order to collect easily contributions. > > Any suggestions how to proceed? I know there are many who prefer svn to git, but the question is if the main repo should migrate from svn to git. If the decision is to have a git(hub) repo, I would suggest completely moving to git. I don't think one can reliably and automatically keep two repos in sync. As it looks now, grass-ci seems to be updated automatically. Cheers, Rainer > > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Travis-ci and tests of grass 7
Rainer M Krug <rai...@krugs.de> writes: > Markus Neteler <nete...@osgeo.org> writes: > >> On Fri, Jun 3, 2016 at 1:43 PM, Rainer M Krug <rai...@krugs.de> wrote: >>> Markus Neteler <nete...@osgeo.org> writes: >>> >>>> On Thu, Jun 2, 2016 at 7:59 PM, Rainer M Krug <rai...@krugs.de> wrote: >>>>> Markus Neteler <nete...@osgeo.org> writes: >>>> ... >>>>>> Anything to be done there? Was it integrated? Or stuck at >>>>>> >>>>>> https://trac.osgeo.org/grass/ticket/2733 >>>>> >>>>> I think it was stuck - but I haven't looked at it since and I have no >>>>> idea if it still works. I think there were some changes on travis >>>>> concerning OS X? >>>>> >>>>> If you are interested, I could look at it again. >>>> >>>> Interested yes, but I cannot help with the Travis CI things. >>>> Just don't like efforts potentially lost :) >>> >>> That's why I didn't continue looking into this - no response. >>> >>> OK. I checked the travis testing, updated the OS X config options to use the >>> same as Linux, usage of gdal 1... as gdal 2.0 is not compiling at the >>> moment in OS X, and the tests passed. >>> >>> Pull request is at: >>> >>> https://github.com/GRASS-GIS/grass-ci/pull/1 >>> >>> travis tests at >>> >>> https://travis-ci.org/rkrug/grass-ci >> >> While I don't know if we have a bidirectional SVN <--> git(hub) >> integration, I have committed it now in SVN trunk as r68652. > > Thanks for committing. Just realized the on-failure notification=s are still disabled - please see my pull request where I enabled them again. https://github.com/GRASS-GIS/grass-ci/pull/2 Cheers, Rainer > >> >>> Who is actually maintaining the travis integration? >> >> No idea - AFAIK Ivan, Martin, Vaclav were involved. > > Thanks. > >> >>> One question: what is the relationship between the grass-ci on github >>> and the svn repo? Are they kept in sync? >> >> I have no clue! I'll bring that up in a separate thread. > > Thanks - would be good to know. > > Cheers, > > Rainer >> >> Markus >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Travis-ci and tests of grass 7
Markus Neteler <nete...@osgeo.org> writes: > On Fri, Jun 3, 2016 at 1:43 PM, Rainer M Krug <rai...@krugs.de> wrote: >> Markus Neteler <nete...@osgeo.org> writes: >> >>> On Thu, Jun 2, 2016 at 7:59 PM, Rainer M Krug <rai...@krugs.de> wrote: >>>> Markus Neteler <nete...@osgeo.org> writes: >>> ... >>>>> Anything to be done there? Was it integrated? Or stuck at >>>>> >>>>> https://trac.osgeo.org/grass/ticket/2733 >>>> >>>> I think it was stuck - but I haven't looked at it since and I have no >>>> idea if it still works. I think there were some changes on travis >>>> concerning OS X? >>>> >>>> If you are interested, I could look at it again. >>> >>> Interested yes, but I cannot help with the Travis CI things. >>> Just don't like efforts potentially lost :) >> >> That's why I didn't continue looking into this - no response. >> >> OK. I checked the travis testing, updated the OS X config options to use the >> same as Linux, usage of gdal 1... as gdal 2.0 is not compiling at the >> moment in OS X, and the tests passed. >> >> Pull request is at: >> >> https://github.com/GRASS-GIS/grass-ci/pull/1 >> >> travis tests at >> >> https://travis-ci.org/rkrug/grass-ci > > While I don't know if we have a bidirectional SVN <--> git(hub) > integration, I have committed it now in SVN trunk as r68652. Thanks for committing. > >> Who is actually maintaining the travis integration? > > No idea - AFAIK Ivan, Martin, Vaclav were involved. Thanks. > >> One question: what is the relationship between the grass-ci on github >> and the svn repo? Are they kept in sync? > > I have no clue! I'll bring that up in a separate thread. Thanks - would be good to know. Cheers, Rainer > > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Travis-ci and tests of grass 7
Just to make sure that this doesn't get lost again. Rainer Rainer M Krug <rai...@krugs.de> writes: > Markus Neteler <nete...@osgeo.org> writes: > >> On Thu, Jun 2, 2016 at 7:59 PM, Rainer M Krug <rai...@krugs.de> wrote: >>> Markus Neteler <nete...@osgeo.org> writes: >> ... >>>> Anything to be done there? Was it integrated? Or stuck at >>>> >>>> https://trac.osgeo.org/grass/ticket/2733 >>> >>> I think it was stuck - but I haven't looked at it since and I have no >>> idea if it still works. I think there were some changes on travis >>> concerning OS X? >>> >>> If you are interested, I could look at it again. >> >> Interested yes, but I cannot help with the Travis CI things. >> Just don't like efforts potentially lost :) > > That's why I didn't continue looking into this - no response. > > OK. I checked the travis testing, updated the OS X config options to use the > same as Linux, usage of gdal 1... as gdal 2.0 is not compiling at the > moment in OS X, and the tests passed. > > Pull request is at: > > https://github.com/GRASS-GIS/grass-ci/pull/1 > > travis tests at > > https://travis-ci.org/rkrug/grass-ci > > Who is actually maintaining the travis integration? > > One question: what is the relationship between the grass-ci on github > and the svn repo? Are they kept in sync? > > Rainer > > > >> >> Markus >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Travis-ci and tests of grass 7
Markus Neteler <nete...@osgeo.org> writes: > On Thu, Jun 2, 2016 at 7:59 PM, Rainer M Krug <rai...@krugs.de> wrote: >> Markus Neteler <nete...@osgeo.org> writes: > ... >>> Anything to be done there? Was it integrated? Or stuck at >>> >>> https://trac.osgeo.org/grass/ticket/2733 >> >> I think it was stuck - but I haven't looked at it since and I have no >> idea if it still works. I think there were some changes on travis >> concerning OS X? >> >> If you are interested, I could look at it again. > > Interested yes, but I cannot help with the Travis CI things. > Just don't like efforts potentially lost :) That's why I didn't continue looking into this - no response. OK. I checked the travis testing, updated the OS X config options to use the same as Linux, usage of gdal 1... as gdal 2.0 is not compiling at the moment in OS X, and the tests passed. Pull request is at: https://github.com/GRASS-GIS/grass-ci/pull/1 travis tests at https://travis-ci.org/rkrug/grass-ci Who is actually maintaining the travis integration? One question: what is the relationship between the grass-ci on github and the svn repo? Are they kept in sync? Rainer > > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Travis-ci and tests of grass 7
Markus Neteler <nete...@osgeo.org> writes: > Hi, > > back to this topic: > > On Thu, Sep 3, 2015 at 5:24 PM, Rainer M Krug <rai...@krugs.de> wrote: >> Hi >> >> is anything happening in regards to the travis-ci integration? I did not >> get any feedback or how I can submit it to the svn. >> >> In regards to testing: I know about the python gunit tests [1]. Are >> there any other tests which should be included in the scripts? Should >> detailed results generated by the tests be uploaded somewhere in case of >> an error? Or always? If yes, where? >> >> Also, should the same tests be done for other versions? >> >> Cheers, >> >> Rainer >> >> >> >> Rainer M Krug <rai...@krugs.de> writes: >> >>> Quick update: the tests are running, the forked github repo is >>> >>> https://github.com/rkrug/grass-ci >>> >>> and the travis-ci is here (the actually running one) >>> >>> https://travis-ci.org/rkrug/grass-ci/builds/77509876 >>> >>> It looks good now. > > I see the open pull request: > > https://github.com/GRASS-GIS/grass-ci/pull/1 > > Anything to be done there? Was it integrated? Or stuck at > > https://trac.osgeo.org/grass/ticket/2733 I think it was stuck - but I haven't looked at it since and I have no idea if it still works. I think there were some changes on travis concerning OS X? If you are interested, I could look at it again. Cheers, Rainer > > ? > > thanks, > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass 7.2 planning
Martin Landa <landa.mar...@gmail.com> writes: > 2016-04-29 13:35 GMT+02:00 Rainer M Krug <rai...@krugs.de>: >> Just to be sure - that would be the version at the moment named 7.1 ? > > yes, Martin Thanks. I will than make a homebrew grass 7.2 formula as soon as the branch has been created. Cheers, Rainer -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass 7.2 planning
Just to be sure - that would be the version at the moment named 7.1 ? Rainer Martin Landa <landa.mar...@gmail.com> writes: > Hi all, > > personally I would like to see GRASS 7.2.0 released somewhere in July. > Do you think that it's realistic? If so I would suggest roadmap > bellow: > > 1) to create releasebranch 7_2 ASAP (in the beginning of May) > 1) soft freeze in releasebranch_7_2 ~ 16 May > 2) GRASS 7.2.0RC1 ~ 16 June > 3) GRASS 7.2.0RC2 ~ 30 June > 4) GRASS 7.2.0 ~ 7 July > > What do you think? Martin -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS 7.0.3 for El Capitan without disabling SIP!
Hi I just received the news, that the new homebrew recipe for GRASS 7.0 does install on El Capitan with SIP enabled! This is thanks to Larry Shaffer. See https://github.com/OSGeo/homebrew-osgeo4mac/issues/118#issuecomment-200278686 The recipe is part of the Homebrew-osgeo4mac tap, see https://github.com/OSGeo/homebrew-osgeo4mac for info on how to use them. I will see that I can port the changes to my grass-71 formula as well - will keep you posted when it works. Thanks a lot Larry, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] split GRASS (lib / cli / modules / wx / qt / web / etc.)
Pietro <peter.z...@gmail.com> writes:
> Dear devs,
>
> stimulated by the GSOC idea of Ondřej I would like to revive again this topic.
> I know that this has been already discussed in the past, I found this
> (CLI1=GUI [0]) but it is focused on users and packagers prospective.
> Here I would like to face this point from a developer point of view.
> As point out in previous threads GRASS it is already modular, but
> (imho) there is duplicate code/functionalities and often things and
> levels are mixed.
>
> Let's start with a simple example: most of the GRASS modules, mix
> nicely logic and cli, several of them have a single main function with
> everything inside. I think could be useful to have a more clear
> distinction between logic/algorithms and their public interface
> (cli/gui). If we clearly split these two things the GRASS modules
> became just an interface to some functions inside the GRASS libraries.
>
> Another example is GRASS GUI that have internally a lot of
> functionalities that (imho) should be moved|integrated to a
> dedicated|existing python library, because their are independent by
> the library (wx|qt|javascript+html5) used to render the final GUI, and
> again to me it seems that a lot of things are mixed.
>
> Split these main functionalities in different repository can help
> developers, because they can focus/work on a smaller base of code.
>
> So how to split GRASS. It would be nice to open a dedicate repository
> (git?) for each of this projects:
>
> - grass-lib: provides only C and Python API. This component should be
> a python citizen, I mean that should be available at the PyPI - the
> Python Package Index [1] and of course install-able as python package
> through pip;
> - grass-cli: provides a shell (with no modules!), also available as a
> pure python package;
> - grass-modules: provides all the GRASS core modules (this could be
> also a pure python interface calling functions in the C/Python
> libraries), and could be split in other sub categories (e.g. imagery,
> temporal, terrain, etc).
> - grass-wx: provides a WxPython/Phoenix interface for GRASS
> - (grass-qt: provides a PyQt/PySide interface for GRASS)
> - (grass-jupyther: provides a Jupyther interface to GRASS)
> - (grass-rest: provides a RESTful API for GRASS)
> - (add your idea here... :-D)
> - etc.
>
> Each point is characterize by a different use-case and this things are
> generally developed by different person with different backgrounds and
> needs and to me it make sense to split them.
>
> We could have a greater granularity and a clear focus for each
> repository and could help to acquire new developers because it open
> new GRASS' development possibilities.
> Enlarging the use-case of GRASS. Separate things in dedicated
> repository force developers to respect the distinction, and force them
> to think where the code should be put/published.
> Such subdivision could help has to reduce the total amount of code
> making things more general and abstract. It should also help making
> independent and well isolated tests.
>
>
> It should also help the development cycle since we can release things
> in a independently way, it requires only to specify in the
> requirements.txt file a working tested combinations of python packages
> versions.
>
> {{{
> numpy>=1.10
> grass-lib>=8
> grass-cli==8.1
> grass-modules>=8
> grass-wx=8.1.3
> }}}
>
> I think this idea could help mainly developers making things clear and
> well organized in different sub-projects.
> Opening the possibility to integrate GRASS functionalities to other
> open-source projects.
>
> This solution could help also in making things easier also for
> packager and users, for example users could install GRASS on all the
> system (win/Mac/*nix) running a single command:
>
> {{{
> $ pip install --user grass-lib grass-cli grass-modules grass-wx
> }}}
>
> What do you think?
I am not a developer of GRASS but in my experience, it is very
advantageous to split one large package into smaller ones and I think
this is definitely a step into the right direction.
Just for clarifications: GRASS will still be available as a deb package
for Debian and derivatives, dmg, ... I hope? (pip makes me always a
little bit nervous - no idea why. Possibky it is another package manager
in addition to deb, rpm, dmg, homebrew, Macports, ...).
Also: It would see it as very important that grass can be installed on
all systems (as you mention - win, mac, *nix, ...?).
Cheers,
Rainer
>
> All the best.
>
> Pietro
>
> [0] https://lists.osgeo.org/pipermail/grass-dev/2010-November/052661.html
> [1] https://pypi.python.org/pypi
> ___
>
Re: [GRASS-dev] Interest in GSoC 2016
Pietro <peter.z...@gmail.com> writes:
> Hi Ondřej,
>
> On Thu, Mar 17, 2016 at 7:45 PM, <ondra.l...@seznam.cz> wrote:
>> My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt) is
>> increasingly used (look at QGis, for example) and I think it would be better
>> to have minimally the roots of GUI in Qt. It’s also much easier to maintain
>> with new features. Work with design is also much more user-friendly. It
>> seems that in the future, it can be nice shortcut to change something in the
>> GUI.
>
> I like the idea, and I think could be strategic for the long run,
> especially because it is not clear to me if and when Phoenix (the
> wxPython for python3) will be ready (and from my superficial
> understanding of the GRASS problem on OS X El Captain Wx it seems part
> of the issue),
With my limited grasp of the grass internals and wxpython:
The main issue For El Capitan is the use of DYNLD_LIBRARY_PATH when
running binaries in /usr/bin or /bin directories (e.g. make). In the
case of homebrew (presumibly Macports as well), during compilation (I
can turn of SIP (System Integrity Progtection) on El Capitan, compile and
install, and enable it again, and it works) and in the case of the
binary compilation and running (as GRASS uses the shell which is in
/usr/local/bin).
> instead both pyQt and pySide support python3 (I think
> we should build a GUI compatible with both binding. Consider that
> GRASS is already working with Python3 (with except of the ctype stuff)
> what it is critical (imho) it is the GUI.
>
> I do like the idea of Vaclav to share a core of functionalities of the
> GUI (between Wx, Qt, Jupyhter, etc). This shared functionalities
> should go in /lib/python/grass/{gui|somethingelse}. This should allow
> us to reduce duplication and the number of code that must be
> maintained.
>
> I think that we should also consider to split GRASS and its
> functionalities, but I open a separate thread on this.
>
> Best regards
>
> Pietro
> _______
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982
signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] is it time to release GRASS71?
Luca Delucchi <lucadel...@gmail.com> writes: > On 25 February 2016 at 07:08, Pietro <peter.z...@gmail.com> wrote: >> Dear devs, >> >> I saw the discussion on https://trac.osgeo.org/grass/ticket/2750#comment:48 >> >> Perhaps is time to think to release the next stable release of GRASS >> before that the stable release and trunk start to diverge too much... >> >> What do you think? >> > > I support this, but I think it should be 7.2 not 7.1. Usually stable > version is even number > https://trac.osgeo.org/grass/wiki/Release > only 6.3 was an exception I would very much like to see OS X El Capitan support to return to 7.2. Any chance of pushing this a bit? Rainer > >> Pietro >> -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS and vagrant
Martin Landa <landa.mar...@gmail.com> writes: > Hi, > > recently I have added Vagrantfile [1] to trunk which enables you > easily create a new virtual machine using vagrant, and compile/install > GRASS on that machine. Detailed description is available on wiki [2]. > Enjoy! Martin Thanks - this sounds very interesting. If my googling gave the right answers, one can use Vagrant together with docker, which would make the resulting instance much more lightweight than a full blown VM (e.g Virtual Box). Has anyone tried this? Rainer > > [1] https://trac.osgeo.org/grass/browser/grass/trunk/Vagrantfile > [2] https://grasswiki.osgeo.org/wiki/Vagrant -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS on OS X El Capitan - slowly dying or is something happening?
First of all thanks a lot for the positive responses from William and Michael that GRASS on OS X is not dying - this makes me feel much better. Furthewr responses below in text. Michael Barton <michael.bar...@asu.edu> writes: > AFAICT, the binaries I am compiling under Mavericks work with El > Capitan IF you turn off System Integrity Protection (to get to the > same level of security available in Mavericks). That is good to know. > > I have not yet updated to El Capitan because I'm hoping someone can > tell me if they can compile GRASS with it. I don't want to get to > situation where I can't produce binaries for the community. But I > would like to upgrade pretty soon. I upgraded and apart from GRASS and the bash variables which are not passed on to new processes started via Finder (sorry - no reference for this at hand) did not regret it - but as you say, your binaries are quite important for the community. > > There are several things in process right now. William, Brian Miles, > and I have talked about how to deal with the SIP problem. William has > an idea of why it is a problem. Fixing it will require significant > change for how dependencies are packaged and referenced. This related > to the second thing. Good to know. > > We've had to compile GRASS with dual 32 bit/64 bit architecture for > several years because v. 2.8.x of wxPython is 32 bit and subsequent > versions of wxPython did not work well or did not work with GRASS. > We've started trying again to get GRASS working with 64 bit wxPython 3 > and are having some success. (If anyone wants to test a version, > please let me know and I'll provide a link to a binary). Because we > have to package wxPython with GRASS, and the 32/64 bit dual > architecture compilation is causing increasing problems, we need to > solve that. > > If we can get these things worked out, I hope someone can try to > compile GRASS with El Capitan and stock Mac Python, etc. to make sure > it all works. I must say I am a homebrew user, and I compiled GRASS from source on El Capitan. Following the steps described in earlier emails, I was able to compile and install GRASS, although it still needs the source directory where it is compiled to run (I guess this is what you are referring above). I am happy to try to compile it and try it out (although I am not using GRASS directly, only from R). But I have python 2.7.11 from homebrew. I have also python 3.5.1 installed via homebrew. Let me know if I can help with compiling / testing as I would like to have it running again in homebrew as well. Cheers, Rainer > > Michael > > C. Michael Barton > Director, Center for Social Dynamics & Complexity > 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, http://csdc.asu.edu > > On Jan 21, 2016, at 6:51 AM, grass-dev-requ...@lists.osgeo.org > wrote: > > > > From: Rainer M Krug <rai...@krugs.de> > > Subject: Re: [GRASS-dev] GRASS on OS X El Capitan - slowly dying > or is something happening? > > Date: January 21, 2016 at 2:01:56 AM MST > > To: William Kyngesburye <wokl...@kyngchaos.com> > > Cc: <grass-dev@lists.osgeo.org>, William Kyngesburye > <kyngch...@kyngchaos.com> > > > > William Kyngesburye <wokl...@kyngchaos.com> writes: > > There are a couple ideas floating around. > > I'm surprised Homebrew has a problem. Since it would leave > everything > in the configured location (/usr/local), there should not be > library > paths pointing somewhere else that would need > DYLD_LIBRARY_PATH to > divert. > > > homebrew is compiling in a temporary location, and than installing > it to > /usr/local/Cellar/. > > The problem is the same why I had to install and than compile > again: > > , > | bash-4.3$ make > | if [ > > "/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/scripts/d.out.file" > != "" ] ; then > > GISRC=/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/demolocation/.grassrc70 > > GISBASE=/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0 > > PATH="/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64
[GRASS-dev] List of make targets and their description?
Hi I remember that I saw somewhere a list of the different make targets and their description of GRASS but I can't find them again. Can somebody point me into the right direction? Thanks, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS on OS X El Capitan - slowly dying or is something happening?
William Kyngesburye <wokl...@kyngchaos.com> writes: > There are a couple ideas floating around. > > I'm surprised Homebrew has a problem. Since it would leave everything > in the configured location (/usr/local), there should not be library > paths pointing somewhere else that would need DYLD_LIBRARY_PATH to > divert. homebrew is compiling in a temporary location, and than installing it to /usr/local/Cellar/. The problem is the same why I had to install and than compile again: , | bash-4.3$ make | if [ "/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/scripts/d.out.file" != "" ] ; then GISRC=/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/demolocation/.grassrc70 GISBASE=/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0 PATH="/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/bin:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/bin:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/scripts:$PATH" PYTHONPATH="/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/etc/python:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/gui/wxpython:$PYTHONPATH" DYLD_LIBRARY_PATH="/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/bin:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/scripts:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib:" LC_ALL=C /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/scripts/d.out.file --html-description < /dev/null | grep -v '\|' > d.out.file.tmp.html ; fi | dyld: Library not loaded: /usr/local/Cellar/grass-70/7.0.1/grass-7.0.1/lib/libgrass_gis.7.0.1.dylib | Referenced from: /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/bin/g.parser | Reason: image not found | make: *** [d.out.file.tmp.html] Error 1 | rm d.out.file.tmp.html | bash-4.3$ ` During make, the html documentation is created. For this, libgrass_gis.7.0.1.dylib is needed. It is already compiled, but not installed. It is in , | bash-4.3$ ls -la /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib/libgrass_gis* | -rwxr-xr-x 1 rainerkrug wheel 218244 Jan 21 09:37 /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib/libgrass_gis.7.0.1.dylib | lrwxr-xr-x 1 rainerkrug wheel 24 Jan 21 09:37 /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib/libgrass_gis.dylib -> libgrass_gis.7.0.1.dylib | bash-4.3$ ` And I assume the path where it is located is in the DYNLIB_ variable which is ignored. This problem should be solvable, when somehow the path to the compiled (but not installed) could be temporarily added during the make. Any suggestions how this could be done? Rainer > >> On Jan 20, 2016, at 8:37 AM, Rainer M Krug <rai...@krugs.de> wrote: >> >> Hi >> >> Sorry for this blunt subject - but I am wondering if anybody is looking >> at supporting El Capitan without having to disable SIP (System Integrity >> Protection). SIP is likely to stay, and for many (including myself) >> disabling SIP is not really an option as it goes to deep into the OS. >> >> >> So my personal opinion: if GRASS want's to stay relevant on OS X, a >> solution needs to be found to compile and install it on a mac as easy >> as it was before (homebrew, which I relly like, and also the frameworks >> From William Kyngesburye and michael Barton?) >> >> I mean - I have found a way of compiling GRASS 7.1 (see my post from the >> 07 January in the topic "SUCCESS (running): Compiling grass 7 svn trunk >> on OS X El Capitan") which gives me a working GRASS GIS including GUI, >> but this is not really a solution. >> >> I asked for help but did not get any response (subject "grass 7 svn >> trunk on OS X El Capitan - need help"). >> >> So I would like to know if somebody would be prepared to help or at >> least tell me if I am following the wrong track. I am not very >> experienced in compiling / linking / make files but I have a basic >> understanding. >> >> I simply refuse to accept that GRASS will die for OSX users (>= El >> Capitan). >> >> Cheers, >> >> Rainer >> >> -- >> Rainer M. Krug, PhD (Conservation Ecol
Re: [GRASS-dev] GRASS on OS X El Capitan - slowly dying or is something happening?
William Kyngesburye <wokl...@kyngchaos.com> writes: > Right, forgot about that part in make (even though I pointed it out > previously). > > Yeah, that would be messy - it would have to compile with the > temporary path, then use install_name_tool at install to change all > the paths. This is where I got stalled with figuring out loops and > lists of modules and libraries in make. > > Another option that may be simpler is to move the doc generation to > install, then everything runs from the install path. This should work, but I have to check it. This is would be the simplest solution, even though I don't know how I can compile without doc generation? What would be the make target than? I assume that the console help would still be htere as it is inherent in the module's executable. Rainer > >> On Jan 21, 2016, at 3:01 AM, Rainer M Krug <rai...@krugs.de> wrote: >> >> William Kyngesburye <wokl...@kyngchaos.com> writes: >> >>> There are a couple ideas floating around. >>> >>> I'm surprised Homebrew has a problem. Since it would leave everything >>> in the configured location (/usr/local), there should not be library >>> paths pointing somewhere else that would need DYLD_LIBRARY_PATH to >>> divert. >> >> homebrew is compiling in a temporary location, and than installing it to >> /usr/local/Cellar/. >> >> The problem is the same why I had to install and than compile again: >> >> , >> | bash-4.3$ make >> | if [ >> | >> "/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/scripts/d.out.file" >> | != "" ] ; then >> | >> GISRC=/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/demolocation/.grassrc70 >> | >> GISBASE=/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0 >> | >> PATH="/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/bin:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/bin:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/scripts:$PATH" >> | >> PYTHONPATH="/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/etc/python:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/gui/wxpython:$PYTHONPATH" >> | >> DYLD_LIBRARY_PATH="/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/bin:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/scripts:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib:/private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib:" >> | LC_ALL=C >> | >> /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/scripts/d.out.file >> | --html-description < /dev/null | grep -v '\|' > >> | d.out.file.tmp.html ; fi >> | dyld: Library not loaded: >> /usr/local/Cellar/grass-70/7.0.1/grass-7.0.1/lib/libgrass_gis.7.0.1.dylib >> | Referenced from: >> | >> /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/bin/g.parser >> | Reason: image not found >> | make: *** [d.out.file.tmp.html] Error 1 >> | rm d.out.file.tmp.html >> | bash-4.3$ >> ` >> >> During make, the html documentation is created. For this, >> libgrass_gis.7.0.1.dylib is needed. It is already compiled, but not >> installed. >> >> It is in >> >> , >> | bash-4.3$ ls -la >> | >> /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib/libgrass_gis* >> | -rwxr-xr-x 1 rainerkrug wheel 218244 Jan 21 09:37 >> | >> /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib/libgrass_gis.7.0.1.dylib >> | lrwxr-xr-x 1 rainerkrug wheel 24 Jan 21 09:37 >> | >> /private/tmp/grass-7020160121-38274-ed29gx/grass-7.0.1/dist.x86_64-apple-darwin15.2.0/lib/libgrass_gis.dylib >> | -> libgrass_gis.7.0.1.dylib >> | bash-4.3$ >> ` >> >> And I assume the path where it is located is in the DYNLIB_ variable >> which is ignored. >> >> This problem should be solvable, when somehow the path to the compiled >> (but not installed) could be temporarily added during the make. >> >> Any suggestions how this could be done? >> >> Rainer >> >>> >>>> On Jan 20, 2016, at 8:37 AM,
[GRASS-dev] GRASS on OS X El Capitan - slowly dying or is something happening?
Hi Sorry for this blunt subject - but I am wondering if anybody is looking at supporting El Capitan without having to disable SIP (System Integrity Protection). SIP is likely to stay, and for many (including myself) disabling SIP is not really an option as it goes to deep into the OS. So my personal opinion: if GRASS want's to stay relevant on OS X, a solution needs to be found to compile and install it on a mac as easy as it was before (homebrew, which I relly like, and also the frameworks From William Kyngesburye and michael Barton?) I mean - I have found a way of compiling GRASS 7.1 (see my post from the 07 January in the topic "SUCCESS (running): Compiling grass 7 svn trunk on OS X El Capitan") which gives me a working GRASS GIS including GUI, but this is not really a solution. I asked for help but did not get any response (subject "grass 7 svn trunk on OS X El Capitan - need help"). So I would like to know if somebody would be prepared to help or at least tell me if I am following the wrong track. I am not very experienced in compiling / linking / make files but I have a basic understanding. I simply refuse to accept that GRASS will die for OSX users (>= El Capitan). Cheers, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] grass 7 svn trunk on OS X El Capitan - need help
Hi as I mentioned in the thread "Compiling grass 7 svn trunk on OS X El Capitan", I managed to compile grass 7 trunc and I am using it at the moment, so everything including the gui are working. But at the moment the directory where it is compiled and the directory where it it=s installed is needed. This is obviously not satisfying and no solution for a OS X El Capitan package or homebrew recipe. But I have no idea how I can solve this or how I can look to solve this. I must say I have not much experience with makefiles and compiling / linking, so any help is welcome. Cheers, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] SUCCESS (running): Compiling grass 7 svn trunk on OS X El Capitan
g/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/etc/python/grass/lib/gis.py",
line 23, in
| _libs["grass_gis.7.1.svn"] = load_library("grass_gis.7.1.svn")
| File
"/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/etc/python/grass/lib/ctypes_loader.py",
line 57, in load_library
| raise ImportError,"%s not found." % libname
| ImportError: grass_gis.7.1.svn not found.
| make: *** [v.what.strds.tmp.html] Error 1
| rm v.what.strds.tmp.html
`
This seems to me like a python thing and I don't know much about
python (actually nearly nothing). I will ignore these and leave them
as I don't use the t.* commands.
6) Just to be sure, I run install again
#+begin_src sh
make install
#+end_src
7) If I now copy the original grass71 to the new bin directory
#+begin_src sh
cp ./bin.x86_64-apple-darwin15.2.0/grass71 ./../bin/
#+end_src
I can run grass71 by running
#+begin_src sh
./ownCompiled/grass/bin/grass71
#+end_src
and everything works, including the GUI. But it is still needs both
directories (the one where it was compiled in and the on where it is
installed to) to run. But I think as it is running, it should be
possible by adjusting some paths?
If somebody could give me some hints I can look further into this.
Hope this helps,
Rainer
>
>> On Jan 6, 2016, at 11:06 AM, Rainer M Krug <rai...@krugs.de> wrote:
>>
>> Hi
>>
>> I am trying to compile GRASS 7 from svn on OS X El Capitan. I have
> ...
>> ,
>> | 5:37:13 ~/ownCompiled/grass/grass7_trunk/scripts/d.correlate$ make
>> | if [
>> |
>> "/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts/d.correlate"
>> | != "" ] ; then
>> |
>> GISRC=/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/demolocation/.grassrc71
>> |
>> GISBASE=/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0
>> |
>> PATH="/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts:$PATH"
>> |
>> PYTHONPATH="/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/etc/python:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/gui/wxpython:$PYTHONPATH"
>> |
>> DYLD_LIBRARY_PATH="/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/lib:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/lib:"
>> | LC_ALL=C
>> |
>> /Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts/d.correlate
>> | --html-description < /dev/null | grep -v '\|' >
>> | d.correlate.tmp.html ; fi
>> | dyld: Library not loaded:
>> /Applications/GRASS-7.1.app/Contents/MacOS/lib/libgrass_gis.7.1.svn.dylib
>> | Referenced from:
>> |
>> /Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin/g.parser
>> | Reason: image not found
>> | make: *** [d.correlate.tmp.html] Error 1
>> | rm d.correlate.tmp.html
>> `
>>
>> What irritates me is the error message concerning not being able to
>> load - which is obvious, as I am still compiling GRASS and haven't
>> installed it yet.
>
> -
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
> http://www.kyngchaos.com/
>
> "History is an illusion caused by the passage of time, and time is an
> illusion caused by the passage of history."
>
> - Hitchhiker's Guide to the Galaxy
>
>
--
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982
signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] R and GRASS integration
(and others >>>> have used before) is a bit unwieldy and makes maintaining such modules a >>>> bit of a pain. >>>> >>>> So, I'm curious to hear the opinions of others... >>> See [1] for a related issue. >>> >>> Moritz >>> >>> [1] https://trac.osgeo.org/grass/ticket/1290 >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] R and GRASS integration
Paulo van Breugel <p.vanbreu...@gmail.com> writes: > On Wed, Jan 6, 2016 at 10:27 AM, Rainer M Krug <rai...@krugs.de> > wrote: > > Paulo van Breugel <p.vanbreu...@gmail.com> writes: > > > I by any stretch of imagination a developer, but I did use the > > combination of shell or pythons script with R, basically > following the > > approach you described, having a python or shell script write a > R > > script to a text file and run it. I think it can work well, and > not > > that much harder to maintain. But I also would be very > interested to > > learn how to do this better. I also would be interested to see > the > > randomForest scripts you mentioned Steven, are you already > sharing it > > somewhere? > > > > As you mentioned, there are probably many people using / writing > R > > scripts that interact with GRASS. For some it will be easier, or > it > > may be more logical for them, to turn these into R packages > rather > > than writing a GRASS addon. > > I am one of those. I have thought about making a GRASS (or QGIS) > addon / > plugin, but I stayed with the R package. I have a complete > simulation > written in R which uses spatial data from GRASS, does simulations, > and > returns the results to GRASS. > > > To run the simulations in itself is a three liner in R. > > > It would be nice if there would be some kind of repository where > > people share such code (github perhaps?). I am sure there are > existing > > ones on e.g., github, so perhaps just a GRASS-wiki page listing > > existing repositories would be enough. I know there is > > https://grasswiki.osgeo.org/wiki/R_statistics, but I don't think > there > > is an place on the GRASS website, wiki or trac to share/list R > code? > > Would this be of interest to create such page (on the Wiki > perhaps?). > > Different people use different repos (I use e.g. github and > gitlab) so > creating another place where I should publish my code would be not > really an option. What would be an idea to make it easy (probably > even > easier even than editing a wiki page?) to add a repo to a list of > projects which integrate R in GRASS or GRASS in R, and which could > indicate the last commit to aser if the repos are current or just > archives from e.g. papers or finished projects. > > > +1 That would be something quick to implement. However, what form did > you have in mind, if not a wiki page? I wouldn't mind creating such > page, but perhaps first some further ideas on the best form from > others as well. I thought about a field, where I just add the link to the repository and some info (Author, short description, possibly License type, ...) and this is automatically added to the page including information from the repo like last updated, link to the README, ... But this might be getting to complicated. But I know it from my side - editing a wiki page is often a "will do later" thing. Also a system where there is an form where one fills in the info and it is emailed to somebody to add it to the wiki would work. > > My repo is private at the moment, but I plan to make it open in > the next > few weeks. > > A brief presentation about a very similar simulation model can be > found at > > https://github.com/rkrug/INTECOL_2013_Optimizing > > > > > Thanks for sharing, interesting. Looking forwards seeing some further > code Thanks - I will keep you posted. Coming back to the initial question: What we would need in the meantime is possibly a discussion, on how R functions could be used in an automated way - i.e. something along the lines of an R package, which contains a set of defined functions like: getFunctionNames() :: which returns the function names which can be called from GRASS getFunctionInterface(functionName) :: which returns the arguments of the function functionName (similar to the interfaceDescription (I think it is called differently) in GRASS commands) would make it possible to just 1) load any R package which has these functions 2) and get all function names and arguments needed 3) and just call the R function in an easy way like g.call.R package=PACKAGENAME function=FUNCTIONNAME arguments="arguments for the R function) The function could than be executed by using either a relatively simple python or direct Rscript approach. Also, one could even dynamically load an R package and construct all the calls including hel
[GRASS-dev] Compiling grass 7 svn trunk on OS X
d from:
/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin/g.parser
| Reason: image not found
| make: *** [d.correlate.tmp.html] Error 1
| rm d.correlate.tmp.html
`
What irritates me is the error message concerning not being able to
load - which is obvious, as I am still compiling GRASS and haven't
installed it yet.
The file is in
,
|
/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/lib
`
Any suggestions what is going on here?
grass71 compiles fine and I can launch it, but the
I am now trying it with
--8<---cut here---start->8---
export LDFLAGS='-L/usr/local/lib -L/usr/local/opt/sqlite/lib'
export CPPFLAGS='-I/usr/local/include -I/usr/local/opt/sqlite/include'
./configure --with-opengl=aqua --with-freetype=no --with-cxx --with-sqlite
--prefix=~/ownCompiled/
--8<---cut here---end--->8---
which results in
,
| GRASS is now configured for: x86_64-apple-darwin15.2.0
|
| Source directory: /Users/rainerkrug/ownCompiled/grass/grass7_trunk
| Build directory:/Users/rainerkrug/ownCompiled/grass/grass7_trunk
| Installation directory: ${prefix}/grass-7.1.svn
| Startup script in directory:${exec_prefix}/bin
| C compiler: gcc -g -O2
| C++ compiler: c++ -g -O2
| Building shared libraries: yes
| OpenGL platform:Aqua
|
| MacOSX application: no
| MacOSX architectures:
| MacOSX SDK:
|
| BLAS support: no
| BZIP2 support: no
| C++ support:yes
| Cairo support: yes
| DWG support:no
| FFTW support: yes
| FreeType support: no
| GDAL support: yes
| GEOS support: no
| LAPACK support: no
| Large File support (LFS): yes
| libLAS support: no
| MySQL support: no
| NetCDF support: no
| NLS support:no
| ODBC support: no
| OGR support:yes
| OpenCL support: no
| OpenGL support: yes
| OpenMP support: no
| PDAL support: no
| PNG support:yes
| POSIX thread support: no
| PostgreSQL support: no
| Readline support: no
| Regex support: yes
| SQLite support: yes
| TIFF support: yes
| X11 support:no
`
--8<---cut here---start->8---
make -j 8
--8<---cut here---end--->8---
results in many errors, where the first one is in d.frame, where, when
compiling from there, I get
,
| 05:49:58 ~/ownCompiled/grass/grass7_trunk/scripts/d.frame$ make
| if [
"/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts/d.frame"
!= "" ] ; then
GISRC=/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/demolocation/.grassrc71
GISBASE=/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0
PATH="/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts:$PATH"
PYTHONPATH="/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/etc/python:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/gui/wxpython:$PYTHONPATH"
DYLD_LIBRARY_PATH="/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/lib:/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/lib:"
LC_ALL=C
/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/scripts/d.frame
--html-description < /dev/null | grep -v '\|' > d.frame.tmp.html
; fi
| dyld: Library not loaded:
/Users/rainerkrug/ownCompiled//grass-7.1.svn/lib/libgrass_gis.7.1.svn.dylib
| Referenced from:
/Users/rainerkrug/ownCompiled/grass/grass7_trunk/dist.x86_64-apple-darwin15.2.0/bin/g.parser
| Reason: image not found
| make: *** [d.frame.tmp.html] Error 1
| rm d.frame.tmp.html
| 05:50:00 ~/ownCompiled/grass/grass7_trunk/scripts/d.frame$
`
So the same.
What is going on here? Why is it trying to load during compilation a
dynamic library from a location where it will be installed *after* it
has been compiled?
Any help appreciated,
Rainer
--
Raine
Re: [GRASS-dev] Return value from g.copy is one when --overwrite - bug or feature?
Markus Neteler <nete...@osgeo.org> writes: > On Sun, Nov 8, 2015 at 11:22 AM, Rainer M Krug <rai...@krugs.de> wrote: >> Huidae Cho <gras...@gmail.com> writes: >> >>> Rainer, >>> >>> I cannot seem to replicate your issue: >>> >>> G srorg6630/tmp ~> g.version >>> GRASS 7.1.svn (2015) >>> >>> G srorg6630/tmp ~> g.list region >>> tmp >>> tmp.d.rast.edit.6753 >>> tmp1 >>> >>> G srorg6630/tmp ~> g.copy region=tmp,tmp1 --overwrite >>> Copy region definition <tmp@tmp> to current mapset as >>> >>> G srorg6630/tmp ~> echo $? >>> 0 >>> >>> g.copy returns 1 when it cannot either read the source or write to the >>> target. Please check your permissions on your region files in >>> LOCATION/MAPSET/windows/. >> >> You are correct - they are read only. >> >> So the return value is correct - but an error should be raised - or is >> there a reason why this should silently fail? > > It should probably not silently fail. Absolutely not - this can lead to errors as one assumes that no error message means that the command was successful - I usually don't check the return codes when I am working in a terminal. > > The code in question is in > lib/manage/do_copy.c > > and potentially there to be added strerror(errno) as for example in > lib/gis/mapset_msc.c I don't know the inner workings of GRASS - but it looks like a good place? On a related note - are the return codes documented somewhere (apart From the source code)? OK - 0 is evident, but the others? They seem to have specific meanings in GRASS? Thanks, Rainer > > ? > > Markus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Return value from g.copy is one when --overwrite - bug or feature?
Huidae Cho <gras...@gmail.com> writes: > Rainer, > > I cannot seem to replicate your issue: > > G srorg6630/tmp ~> g.version > GRASS 7.1.svn (2015) > > G srorg6630/tmp ~> g.list region > tmp > tmp.d.rast.edit.6753 > tmp1 > > G srorg6630/tmp ~> g.copy region=tmp,tmp1 --overwrite > Copy region definition <tmp@tmp> to current mapset as > > G srorg6630/tmp ~> echo $? > 0 > > g.copy returns 1 when it cannot either read the source or write to the > target. Please check your permissions on your region files in > LOCATION/MAPSET/windows/. You are correct - they are read only. So the return value is correct - but an error should be raised - or is there a reason why this should silently fail? Cheers, Rainer > > Regards, > Huidae > > > On Fri, Nov 6, 2015 at 8:21 AM, Rainer M Krug <rai...@krugs.de> wrote: > >> When copying via g.copy and specifying --overwrite and the target object >> already exists, the return value is 1 but no error message is returned: >> >> , >> | simASM:grassAnalysis> g.copy --overwrite region=region1,region2 >> | simASM:grassAnalysis> echo $? >> | 1 >> | simASM:grassAnalysis> g.version >> | GRASS 7.0.1 (2015) >> | simASM:grassAnalysis> >> ` >> >> From http://tldp.org/LDP/abs/html/exit-status.html: >> >> , >> | A successful command returns a 0, while an unsuccessful one returns a >> | non-zero value that usually can be interpreted as an error code. >> ` >> >> So shouldn't the return value be 0 in this case, as the command did what >> it was told? >> >> Cheers, >> >> Rainer >> >> -- >> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation >> Biology, UCT), Dipl. Phys. (Germany) >> >> Centre of Excellence for Invasion Biology >> Stellenbosch University >> South Africa >> >> Tel : +33 - (0)9 53 10 27 44 >> Cell: +33 - (0)6 85 62 59 98 >> Fax : +33 - (0)9 58 10 27 44 >> >> Fax (D):+49 - (0)3 21 21 25 22 44 >> >> email: rai...@krugs.de >> >> Skype: RMkrug >> >> PGP: 0x0F52F982 >> >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev >> -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Return value from g.copy is one when --overwrite - bug or feature?
When copying via g.copy and specifying --overwrite and the target object already exists, the return value is 1 but no error message is returned: , | simASM:grassAnalysis> g.copy --overwrite region=region1,region2 | simASM:grassAnalysis> echo $? | 1 | simASM:grassAnalysis> g.version | GRASS 7.0.1 (2015) | simASM:grassAnalysis> ` From http://tldp.org/LDP/abs/html/exit-status.html: , | A successful command returns a 0, while an unsuccessful one returns a | non-zero value that usually can be interpreted as an error code. ` So shouldn't the return value be 0 in this case, as the command did what it was told? Cheers, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [BUG] or at least unclear error message
Rainer M Krug <rai...@krugs.de> writes: > Markus Neteler <nete...@osgeo.org> writes: > >> On Mon, Nov 2, 2015 at 11:50 AM, Rainer M Krug <rai...@krugs.de> wrote: >>> Hi >>> >>> OS: OS X, El Capitan, grass installed via homebrew. >>> >>> I have a mega location with 532 read-only mapsets with each around 2500 >>> mapsets >>> (plus PERMANENT and an read-write analysis mapset). >>> >>> When using g.list type=rast mapset=* I get the following error: "Unable >>> to open directory". I guess this is caused by to many open files as I >>> can execute the command g.list type=rast mapset=... for this mapset >>> without problems. >> >> You likely hit the current setting of open files. See e.g. this page >> how to set a higher limit: >> >> https://grass.osgeo.org/grass70/manuals/r.series.html#management-of-open-file-limits > Just to add and possibly to be invcluded in the manual: on OS X the hard limit is unlimited and the soft limit is 256. Cheers, Rainer > Yes - that solved the issue. But I am wondering, if it really is > necessary to keep all these files open just to list the maps? > > Thanks, > > Rainer > > >> >> Please let us know how it goes. >> >> Markus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [BUG] or at least unclear error message
Markus Neteler <nete...@osgeo.org> writes: > On Thu, Nov 5, 2015 at 9:07 AM, Rainer M Krug <rai...@krugs.de> wrote: >> Just to add and possibly to be invcluded in the manual: on OS X the hard >> limit is unlimited and the soft limit is 256. > > maybe we should modify that part and refer to an overview page > describing the various operating systems? I think that would be a good idea as this likely can affect many scripts and commands. Apart from the offline documentation, this might even a candidate for the wiki. Rainer > > Markus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [BUG] or at least unclear error message
Markus Neteler <nete...@osgeo.org> writes: > On Tue, Nov 3, 2015 at 1:09 PM, Rainer M Krug <rai...@krugs.de> wrote: >> Glynn Clements <gl...@gclements.plus.com> writes: >>> G_ls2() doesn't call closedir() when it has finished reading the >>> directory. >>> >>> Fixed in trunk with r66719. >> >> Thanks. >> >> I assume this will not be included in 7.0.2? > > It will, already backported. Great - thanks Rainer > (but it didn't make it by some minutes into RC2). > > Markus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [BUG] or at least unclear error message
Markus Neteler <nete...@osgeo.org> writes: > On Mon, Nov 2, 2015 at 11:50 AM, Rainer M Krug <rai...@krugs.de> wrote: >> Hi >> >> OS: OS X, El Capitan, grass installed via homebrew. >> >> I have a mega location with 532 read-only mapsets with each around 2500 >> mapsets >> (plus PERMANENT and an read-write analysis mapset). >> >> When using g.list type=rast mapset=* I get the following error: "Unable >> to open directory". I guess this is caused by to many open files as I >> can execute the command g.list type=rast mapset=... for this mapset >> without problems. > > You likely hit the current setting of open files. See e.g. this page > how to set a higher limit: > > https://grass.osgeo.org/grass70/manuals/r.series.html#management-of-open-file-limits Yes - that solved the issue. But I am wondering, if it really is necessary to keep all these files open just to list the maps? Thanks, Rainer > > Please let us know how it goes. > > Markus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [BUG] or at least unclear error message
Hi OS: OS X, El Capitan, grass installed via homebrew. I have a mega location with 532 read-only mapsets with each around 2500 mapsets (plus PERMANENT and an read-write analysis mapset). When using g.list type=rast mapset=* I get the following error: "Unable to open directory". I guess this is caused by to many open files as I can execute the command g.list type=rast mapset=... for this mapset without problems. (transcript below) Is this the case? Could the error message be clarified (I fear not) or a different approach be used to list the maps? Thanks, Rainer , | simASM:grassAnalysis> g.list type=rast mapset=* | ERROR: Unable to open directory | /Users/rainerkrug/grassdata/simASM/simASM.CapePeninsula.Past.CapePeninsula_0_1.CapePeninsula.47712.2/cell | simASM:grassAnalysis> g.list type=rast mapset=simASM.CapePeninsula.Past.CapePeninsula_0_1.CapePeninsula.47712.2 | wc -l | 2615 | simASM:grassAnalysis> g.version -b -r -e --v | GRASS 7.0.1 (2015) | | ./configure --prefix=/usr/local/Cellar/grass-70/7.0.1 --disable-debug --disable-dependency-tracking --enable-shared --with-cxx --with-python --with-blas --with-lapack --with-sqlite --with-odbc --with-geos=/usr/local/opt/geos/bin/geos-config --with-proj-share=/usr/local/opt/proj/share/proj --with-png --with-readline-includes=/usr/local/opt/readline/include --with-readline-libs=/usr/local/opt/readline/lib --with-readline --with-nls-includes=/usr/local/opt/gettext/include --with-nls-libs=/usr/local/opt/gettext/lib --with-nls --with-freetype --without-tcltk --with-includes=/usr/local/opt/gettext/include --with-wxwidgets=/usr/local/opt/wxmac/bin/wx-config --enable-64bit --with-macos-archs=x86_64 --with-cairo-includes=/usr/local/opt/cairo/include/cairo --with-cairo-libs=/usr/local/opt/cairo/lib --with-cairo --with-postgres --with-mysql-includes=/usr/local/opt/mysql/include/mysql --with-mysql-libs=/usr/local/opt/mysql/lib --with-mysql --with-liblas=/usr/local/opt/liblas/bin/liblas-config | libgis Revision: 64733 | libgis Date: 2015-02-25 01:56:29 +0100 (Wed, 25 Feb 2015) | PROJ.4: 4.9.1 | GDAL/OGR: 1.11.2 | GEOS: 3.4.2 | SQLite: 3.8.11.1 `---- -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS and Mac OS X El Capitan
Michael Barton <michael.bar...@asu.edu> writes: > But it was never clear what was and was not working. We have this > working fine in Yosemite. So far, you are the only ones to report a > problem with Yosemite. The problem we are reporting now is that it was > running on Yosemite and not running on El Capitan. Maybe that is the > same thing, but maybe not. That said, I plan on a recompile, but have > been stuck on the laslib problem. I hope to have time to get that > compiled on Thursday. I haven’t had much input so it has been a lot of > trial and error. Once it is working with current gdal, I can recompile > new binaries. Just to add an (unrelated?) datapoint: I installed grass 70 and 71 under Yosemite using homebrew and tried just now unde El Capitan, and both still run the gui. Rainer > > Michael > > C. Michael Barton > Director, Center for Social Dynamics & Complexity > 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, http://csdc.asu.edu > > > > > > > > > > > > > > > > On Oct 6, 2015, at 2:11 PM, Anna Petrášová > <kratocha...@gmail.com<mailto:kratocha...@gmail.com>> wrote: > > > > On Tue, Oct 6, 2015 at 4:56 PM, Michael Barton > <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>> wrote: > This is a binary I created and posted to my web site not too long > ago. It worked fine before upgrading and works fine on people’s > machines that have not upgraded. So this worries me. > > I informed you couple of weeks ago when you posted them that they are > not working on my and Helena's Mac with the exact same problem (we > have Yosemite). As I said before couple of times and as Markus said > now, this error suggests that fresh recompilation could help. > > BTW I fixed import order couple of weeks ago, so this shouldn't happen again. > > > > I’m hoping soon to have time to complete the complicated effort to > recompile laslib so I can make new binaries before I think about > upgrading to the new OS X. But I will be compiling them on the > penultimate version of the OS (prior to El Capitan, released a few > days ago). > > We are able to compile GRASS on Mac, although we haven't tried to compile > liblas. > > Anna > > Michael > > C. Michael Barton > Director, Center for Social Dynamics & Complexity > 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, > http://csdc.asu.edu<http://csdc.asu.edu/> > > > > > > > > > > > > > > > >> On Oct 6, 2015, at 12:02 PM, Markus Neteler >> <nete...@osgeo.org<mailto:nete...@osgeo.org>> wrote: >> >> On Tue, Oct 6, 2015 at 8:56 PM, Michael Barton >> <michael.bar...@asu.edu<mailto:michael.bar...@asu.edu>> wrote: >>> A couple of my students upgraded to the new Mac OS, El Capitan, and can no >>> longer run GRASS. >>> >>> We tried a work around that disabled one of the new security settings. This >>> got the launch process further, but it still bombed. Has anyone had any luck >>> with this yet? >>> >>> Here is the error: >>> >>> Launching GUI in the background, please wait... >>> >>> GRASS 7.0.1 (MedLambertA):~ > Traceback (most recent call last): >> ... >>> File >>> "/Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py", >>> line 30, in >>>from iclass.digit import IClassVDigit >>> >>> File >>> "/Applications/GRASS-7.0.app/Contents/MacOS/gui/wxpython/iclass/digit.py", >>> line 23, in >>>from vdigit.wxdisplay import DisplayDriver, TYPE_AREA >>> >>> ImportError: cannot import name TYPE_AREA >> >> There is a (closed) ticket: >> https://trac.osgeo.org/grass/ticket/2538 >> >> and an email >> https://lists.osgeo.org/pipermail/grass-dev/2013-September/065580.html >> >> ... both indicating the same solution: >> * "Ok. Don't know what happened to my source tree, but with a fresh >> checkout
Re: [GRASS-dev] Travis-ci and tests of grass 7
Vaclav Petras <wenzesl...@gmail.com> writes: > Hi Rainer, > > On Thu, Sep 3, 2015 at 11:24 AM, Rainer M Krug <rai...@krugs.de> wrote: >> >> Hi >> >> is anything happening in regards to the travis-ci integration? I did not >> get any feedback or how I can submit it to the svn. > > Ideally open a ticket a submit a diff. That's what I do (although I can > actually commit) for things which are unclear, unfinished or need > discussion, see e.g. #2732. > > https://trac.osgeo.org/grass/ticket/2732 Done. see https://trac.osgeo.org/grass/ticket/2733 > >> In regards to testing: I know about the python gunit tests [1]. Are >> there any other tests which should be included in the scripts? Should >> detailed results generated by the tests be uploaded somewhere in case of >> an error? Or always? If yes, where? > > The tests should run as well. We probably cannot upload the detailed > results anywhere. There is some basic text output however. Perhaps we > should add option to gunittest to not generate the detailed output at all. From the travis-ci side, this is not a problem as far as I know, but it obviously would be good to avoid upload of unnecessary data. Yes - a summary outout and, in the case of failed tests, uploading detailed results of this individual test, would be an option? > > The other issues that it takes much more time then compilation and it needs > to download data. The download of the data is already in the script - so that is no problem. Running time is, as far as I know, not that restricted, but I would have to investigate. > > Finally, the tests are still not at 100%, although we are pretty close: > > http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html This looks impressive. > >> Also, should the same tests be done for other versions? > > Probably yes. I don't know how difficult would be to sync Git repo also for > release branch. No idea - but I assume only a script which is mirroring the grass svn to github. At the moment it seems only trunc is mirrored. There is also the option to not mirror anything at all, but get the branch from the svn when the tests on travis-ci are started, and only to have a github repo for the actual travis files - but the mirroring would be cleaner. > I'm also not sure about differences for Travis between Git solution in > comparison to Homebrew but I suppose you do :) What do you mean by "Git solution"? Homebrew downloads the grass repo (svn or github, at the moment from svn) when run and installs it. For the normal travis-ci (Linux) approach, the github repo is used (which is a mirror of the svn repo). Cheers, Rainer > > Vaclav -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Travis-ci and tests of grass 7
Hi is anything happening in regards to the travis-ci integration? I did not get any feedback or how I can submit it to the svn. In regards to testing: I know about the python gunit tests [1]. Are there any other tests which should be included in the scripts? Should detailed results generated by the tests be uploaded somewhere in case of an error? Or always? If yes, where? Also, should the same tests be done for other versions? Cheers, Rainer Rainer M Krug <rai...@krugs.de> writes: > Quick update: the tests are running, the forked github repo is > > https://github.com/rkrug/grass-ci > > and the travis-ci is here (the actually running one) > > https://travis-ci.org/rkrug/grass-ci/builds/77509876 > > It looks good now. > > Cheers, > > Rainer > > Rainer M Krug <rai...@krugs.de> writes: > >> Hi Ivan, Hi Markus, >> >> I have looked at the .travis.yml at >> [https://trac.osgeo.org/grass/browser/grass/trunk/.travis.ym]l >> and merged it with mine by >> >> 1) moving the sections of the .travis.yml fiole into scripts: >> >>- before_install :: .travis.$TRAVIS_OS_NAME.before_install.sh >>- install:: .travis.$TRAVIS_OS_NAME.install.sh >>- script :: .travis.$TRAVIS_OS_NAME.script.sh >> >> 2) using a travis multiple OS [http://docs.travis-ci.com/user/multi-os/] >> which sets the variable $TRAVIS_OS_NAME to "osx" or "linux" (hopefully >> "windows" in the future as well) >> >> So when testing on linux, the scripts with *.linux.*.sh are called, when >> testing osx the one=s with *.osx.*.sh get called >> >> 3) adding the different compiler to the matrix >> >> So I end up with three separate test scenarios: >> >> , >> | - os: linux >> | language: c >> | compiler: gcc >> | >> | - os: linux >> | language: c >> | compiler: clang >> | >> | - os: osx >> | compiler: objective-c >> ` >> >> I forked [https://github.com/GRASS-GIS/grass-ci] and am running the test >> at the moment - see [https://travis-ci.org/rkrug/grass-ci/builds/77484863] >> for the tests. >> >> They completed successful. >> >> There is still some fine tuning which could be done, especially with >> including of tests - which should not be to difficult. >> >> What would be the easiest to get the new files into the grass repo, id=f >> you are happy with it? >> >> Cheers, >> >> Rainer >> >> Markus Neteler <nete...@osgeo.org> writes: >> >>> Hi Ivan, >>> >>> I asked Rainer who is willing to contribute the MacOSX part (end of the >>> month). >>> >>> See below. >>> >>> Thanks, Rainer! >>> >>> Markus >>> >>> On Fri, Aug 14, 2015 at 10:09 AM, Rainer M Krug <r.m.k...@gmail.com> wrote: >>>> >>>> >>>> Envoyé de mon iPhone >>>> >>>>> Le 14 août 2015 à 09:45, Markus Neteler <nete...@osgeo.org> a écrit : >>>>> >>>>> Hi Rainer, >>>> >>>> Hi Markus, >>>> >>>>> >>>>> given your experience with homebrew, I wondered if you would be >>>>> willing to assist in setting up a Travis-CI instance for OSX here: >>>> >>>> Yes - That is my idea. To have a Travis-CI instance for all major OS >>>> should be the aim. >>>> >>>>> >>>>>> On Tue, Jul 21, 2015 at 11:52 AM, Ivan Minčík <ivan.min...@gmail.com> >>>>>> wrote: >>>>>> Hi all, >>>>>> we have just integrated Travis Continuous Integration system [1] to the >>>>>> GRASS source code. Every commit is now build in Travis [2] using gcc and >>>>>> clang. In case the build fails, error message should go to GRASS-dev >>>>>> list. >>>>>> >>>>>> >>>>>> 1 - https://trac.osgeo.org/grass/browser/grass/trunk/.travis.yml >>>>>> 2 - https://travis-ci.org/GRASS-GIS/grass-ci >>>>>> >>>>>> -- >>>>>> Ivan Minčík >>>>>> ivan.min...@gmail.com GPG: 0x79529A1E >>>>>> http://imincik.github.io/0x79529A1E.key >>>>>> ivan.min...@gista.sk GPG: 0xD714B02C >>>>>> http://imincik.github.io/0xD714B02C.key >>>>> >>>>> >>>>> This works well for Linux now. >>&g
Re: [GRASS-dev] Travis CI
Hi Ivan, Hi Markus, I have looked at the .travis.yml at [https://trac.osgeo.org/grass/browser/grass/trunk/.travis.ym]l and merged it with mine by 1) moving the sections of the .travis.yml fiole into scripts: - before_install :: .travis.$TRAVIS_OS_NAME.before_install.sh - install:: .travis.$TRAVIS_OS_NAME.install.sh - script :: .travis.$TRAVIS_OS_NAME.script.sh 2) using a travis multiple OS [http://docs.travis-ci.com/user/multi-os/] which sets the variable $TRAVIS_OS_NAME to osx or linux (hopefully windows in the future as well) So when testing on linux, the scripts with *.linux.*.sh are called, when testing osx the one=s with *.osx.*.sh get called 3) adding the different compiler to the matrix So I end up with three separate test scenarios: , | - os: linux | language: c | compiler: gcc | | - os: linux | language: c | compiler: clang | | - os: osx | compiler: objective-c ` I forked [https://github.com/GRASS-GIS/grass-ci] and am running the test at the moment - see [https://travis-ci.org/rkrug/grass-ci/builds/77484863] for the tests. They completed successful. There is still some fine tuning which could be done, especially with including of tests - which should not be to difficult. What would be the easiest to get the new files into the grass repo, id=f you are happy with it? Cheers, Rainer Markus Neteler nete...@osgeo.org writes: Hi Ivan, I asked Rainer who is willing to contribute the MacOSX part (end of the month). See below. Thanks, Rainer! Markus On Fri, Aug 14, 2015 at 10:09 AM, Rainer M Krug r.m.k...@gmail.com wrote: Envoyé de mon iPhone Le 14 août 2015 à 09:45, Markus Neteler nete...@osgeo.org a écrit : Hi Rainer, Hi Markus, given your experience with homebrew, I wondered if you would be willing to assist in setting up a Travis-CI instance for OSX here: Yes - That is my idea. To have a Travis-CI instance for all major OS should be the aim. On Tue, Jul 21, 2015 at 11:52 AM, Ivan Minčík ivan.min...@gmail.com wrote: Hi all, we have just integrated Travis Continuous Integration system [1] to the GRASS source code. Every commit is now build in Travis [2] using gcc and clang. In case the build fails, error message should go to GRASS-dev list. 1 - https://trac.osgeo.org/grass/browser/grass/trunk/.travis.yml 2 - https://travis-ci.org/GRASS-GIS/grass-ci -- Ivan Minčík ivan.min...@gmail.com GPG: 0x79529A1E http://imincik.github.io/0x79529A1E.key ivan.min...@gista.sk GPG: 0xD714B02C http://imincik.github.io/0xD714B02C.key This works well for Linux now. Reading this email on qgis-psc, I got the impression that it is simple also for OSX: On Fri, Aug 14, 2015 at 7:31 AM, Nyall Dawson nyall.daw...@gmail.com wrote: On 13 August 2015 at 04:32, Tim Sutton t...@qgis.org wrote: Awesome stuff Nyall - can you give any notes on what specifically you had to do to enable OS X testing? Not much really... all the ground work was already in place and were just waiting on Travis to open up multi OS builds again. Whoever setup the homebrew install package (Larry?) made it super easy to install the dependencies, and we already had 99% of the tests passing without error on OSX. Michael Kirk had also already given this a shot so I was able to borrow parts of his attempts which also helped a lot. Nyall ___ Qgis-psc mailing list qgis-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-psc Ivan does not have time for it but he's maybe willing to tell you how to log into the system. What do you think? As you probably know, I have a running Travis-ci for OS X and it could be integrated there. The homebrew recipe needs some alignment in this case (and possibly a new more official home) but that should be relatively straight forward. At the moment I am on holiday but should be able to look at it in the last week of August. Please remind me of you don't hear from me by end of August. Cheers and thanks for the offer, Rainer Markus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Travis CI
Quick update: the tests are running, the forked github repo is https://github.com/rkrug/grass-ci and the travis-ci is here (the actually running one) https://travis-ci.org/rkrug/grass-ci/builds/77509876 It looks good now. Cheers, Rainer Rainer M Krug rai...@krugs.de writes: Hi Ivan, Hi Markus, I have looked at the .travis.yml at [https://trac.osgeo.org/grass/browser/grass/trunk/.travis.ym]l and merged it with mine by 1) moving the sections of the .travis.yml fiole into scripts: - before_install :: .travis.$TRAVIS_OS_NAME.before_install.sh - install:: .travis.$TRAVIS_OS_NAME.install.sh - script :: .travis.$TRAVIS_OS_NAME.script.sh 2) using a travis multiple OS [http://docs.travis-ci.com/user/multi-os/] which sets the variable $TRAVIS_OS_NAME to osx or linux (hopefully windows in the future as well) So when testing on linux, the scripts with *.linux.*.sh are called, when testing osx the one=s with *.osx.*.sh get called 3) adding the different compiler to the matrix So I end up with three separate test scenarios: , | - os: linux | language: c | compiler: gcc | | - os: linux | language: c | compiler: clang | | - os: osx | compiler: objective-c ` I forked [https://github.com/GRASS-GIS/grass-ci] and am running the test at the moment - see [https://travis-ci.org/rkrug/grass-ci/builds/77484863] for the tests. They completed successful. There is still some fine tuning which could be done, especially with including of tests - which should not be to difficult. What would be the easiest to get the new files into the grass repo, id=f you are happy with it? Cheers, Rainer Markus Neteler nete...@osgeo.org writes: Hi Ivan, I asked Rainer who is willing to contribute the MacOSX part (end of the month). See below. Thanks, Rainer! Markus On Fri, Aug 14, 2015 at 10:09 AM, Rainer M Krug r.m.k...@gmail.com wrote: Envoyé de mon iPhone Le 14 août 2015 à 09:45, Markus Neteler nete...@osgeo.org a écrit : Hi Rainer, Hi Markus, given your experience with homebrew, I wondered if you would be willing to assist in setting up a Travis-CI instance for OSX here: Yes - That is my idea. To have a Travis-CI instance for all major OS should be the aim. On Tue, Jul 21, 2015 at 11:52 AM, Ivan Minčík ivan.min...@gmail.com wrote: Hi all, we have just integrated Travis Continuous Integration system [1] to the GRASS source code. Every commit is now build in Travis [2] using gcc and clang. In case the build fails, error message should go to GRASS-dev list. 1 - https://trac.osgeo.org/grass/browser/grass/trunk/.travis.yml 2 - https://travis-ci.org/GRASS-GIS/grass-ci -- Ivan Minčík ivan.min...@gmail.com GPG: 0x79529A1E http://imincik.github.io/0x79529A1E.key ivan.min...@gista.sk GPG: 0xD714B02C http://imincik.github.io/0xD714B02C.key This works well for Linux now. Reading this email on qgis-psc, I got the impression that it is simple also for OSX: On Fri, Aug 14, 2015 at 7:31 AM, Nyall Dawson nyall.daw...@gmail.com wrote: On 13 August 2015 at 04:32, Tim Sutton t...@qgis.org wrote: Awesome stuff Nyall - can you give any notes on what specifically you had to do to enable OS X testing? Not much really... all the ground work was already in place and were just waiting on Travis to open up multi OS builds again. Whoever setup the homebrew install package (Larry?) made it super easy to install the dependencies, and we already had 99% of the tests passing without error on OSX. Michael Kirk had also already given this a shot so I was able to borrow parts of his attempts which also helped a lot. Nyall ___ Qgis-psc mailing list qgis-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-psc Ivan does not have time for it but he's maybe willing to tell you how to log into the system. What do you think? As you probably know, I have a running Travis-ci for OS X and it could be integrated there. The homebrew recipe needs some alignment in this case (and possibly a new more official home) but that should be relatively straight forward. At the moment I am on holiday but should be able to look at it in the last week of August. Please remind me of you don't hear from me by end of August. Cheers and thanks for the offer, Rainer Markus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman
Re: [GRASS-dev] Running python test: why are they not running?
Vaclav Petras wenzesl...@gmail.com writes: On Thu, Aug 20, 2015 at 10:25 AM, Rainer M Krug rai...@krugs.de wrote: The easiest might be to checkout the tests before usage. How can I check them out from svn and in which folder are they located? But I assume they have to be compiled before usage? What needs to be compiled should (i.e. is) compiled during compilation (not ideal actually, but good enough). Most of the tests code is written in Python. The tests are part of the main source code. If you have source code from Subversion, browse it and look for testsuite directories. Every testsuite directory is a set of tests for its parent directory. Examples: https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/testsuite https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.viewshed/testsuite https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/script/testsuite Thanks for the info - much clearer now. I also found [1] and the script - as I assume that it runs the same tests, only that the I have a little bit more control about the locations, I think I will go with the script and adapt it to my needs. Thanks a lot, Rainer Footnotes: [1] https://grass.osgeo.org/grass71/manuals/libpython/gunittest_running_tests.html -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Running python test: why are they not running?
Vaclav Petras wenzesl...@gmail.com writes: On Wed, Aug 19, 2015 at 11:02 AM, Rainer M Krug rai...@krugs.de wrote: Hi I am working on the homebrew script for OS X and am trying to implement the tests. I download the test dataset, extract it, and run --8---cut here---start-8--- grass71 ./nc_basic_spm_grass7/PERMANENT --exec python -m grass.gunittest.main --location './nc_basic_spm_grass7' --location-type nc --8---cut here---end---8--- But I get the following: , | == tar xzf ./nc_basic_spm_grass7.tar.gz | == ls -l ./nc_basic_spm_grass7/ | total 24 | -rw-r--r-- 1 rainerkrug wheel 1035 Nov 3 2008 CREDITS.txt | -rw-r--r-- 1 rainerkrug wheel 2710 Jul 25 2013 HISTORY.txt | drwxr-xr-x 18 rainerkrug wheel 612 Feb 13 2013 PERMANENT | -rw-r--r-- 1 rainerkrug wheel 130 Nov 26 2012 VERSION.txt | drwxr-xr-- 16 rainerkrug wheel 544 Jul 25 2013 user1 | == grass71 ./nc_basic_spm_grass7/PERMANENT --exec python -m grass.gunittest.main --location './nc_basic_spm_grass7' --location-type nc | WARNING: Default locale settings are missing. GRASS running with C locale. | Starting GRASS GIS... | Executing python -m grass.gunittest.main --location ./nc_basic_spm_grass7 --location-type nc ... | | Executed 0 test files in 0:00:00.046629. | From them 0 files (unknown percentage) were successful and 0 files (unknown percentage) failed. | Execution of python -m grass.gunittest.main --location ./nc_basic_spm_grass7 --location-type nc finished. | Cleaning up temporary files... | 04:57:47 ~$ ` If I run the same command in my home directory, where the dataset is also installed, the tests run as expected. Any suggestions why the tests do not run? The data is downloaded, and extracted (see the ls -l above). Any suggestions? Do you run it from the directory with the source code? The tests are only in the source code. `python -m grass.gunittest.main` will find all tests in all subdirectories of the current directory. OK - this explains,as the tests are run in a temporary directory. The easiest might be to checkout the tests before usage. How can I check them out from svn and in which folder are they located? But I assume they have to be compiled before usage? Thanks, Rainer Vaclav https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#testing-with-gunittest-package-in-general https://grass.osgeo.org/grass71/manuals/libpython/gunittest_running_tests.html#running-tests-report Thanks, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] OSX 10.11 Compiling
OK - I tried the installation of grass 70 from osgeo4mac and it has the same error. I have reported it on their website (see https://github.com/OSGeo/homebrew-osgeo4mac/issues/102) So it is not a 7.1 issue. Cheers, Rainer Rainer M Krug rai...@krugs.de writes: Carlos Grohmann carlos.grohm...@gmail.com writes: Hi I never installed OS X on a virtual machine, can't help much there.. (I'm using yosemite as primary machine and El Capitan on a secondary one) OK - I will see how it goes. Maybe a second HDD is the easiest option. While we are here, I tried the homebrew tap for 7.1svn on a Yosemite machine and it didn't worked. Could you give me the options you used for , | brew install --HEAD grass-71 ` so that I can check? because on Travis-ci the default installation is installing without errors - I am trying it just now at https://travis-ci.org/rkrug/homebrew-experimental First I tried to install with libLas, add although it installed libels correctly, it can't find the library when running GRASS'configure :== ./configure --prefix=/usr/local/Cellar/grass-71/HEAD --enable-shared --with- checking for gdal-config... /usr/local/opt/gdal/bin/gdal-config rm: conftest.dSYM: is a directory checking whether to use libLAS... yes checking for liblas-config... /usr/local/opt/liblas/bin/liblas-config configure: error: *** Unable to locate libLAS library. Then I tried with libels and it went OK, but when I run: Serenity:~ guano$ /usr/local/bin/grass71 Traceback (most recent call last): File /usr/local/bin/grass71, line 54, in module ENCODING = locale.getdefaultlocale()[1] File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py, line 511, in getdefaultlocale return _parse_localename(localename) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py, line 443, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: UTF-8 Serenity:~ guano$ I have everything (including python) in homebrew and I can install it, although I have not tested any additional options. I just added two more test cases / envelopes on travis-ci (--with-liblas and --with-openblas) to test this and they are running at the moment ... You can see them at https://travis-ci.org/rkrug/homebrew-experimental/builds/74242734 And the --with-liblas fails there as well. OK. I added the -v for the v=compile to get a better picture ... https://travis-ci.org/rkrug/homebrew-experimental/builds/74248159 same errors. I found the following: grass70 not detecting latest source build of libLAS (1.7.0) https://trac.osgeo.org/grass/ticket/2065 And the only reference I see is that liblas newer than 1.7 is installed, but homebrew installs 1.8 - so this is not the problem. OK - I think I narrowed it down: it seems that the problem is gdal. I will open another subject with this. Cheers, Rainer any ideas? thanks Carlos On Tue, Aug 4, 2015 at 10:52 AM, Rainer M Krug rai...@krugs.de wrote: Carlos Grohmann carlos.grohm...@gmail.com writes: Hello Rainer (and devs) I think you only need to join the beta program (although I have the free developer account, just to be able to download xcode-related tools like the comand line tools). Thanks - I registered for the beta program an I am downloading El Capitan at the moment. Can you give any pointers how I can install it in Virtual Box as I do not want to interfere with my production machine and do prefer the flexibility of a virtual machine. I'll take a look at the errors when I have it installed - which might be in two weeks time as I will be on holiday next week. Thanks, Rainer I'll summarise what I know so far about these issues: - When compiling, I get a lot of errors. These are related to creating html docs. As Glynn said, at this pint of compilation, the module is run with --html-description switch to get a list of its options. Any problems with wxpython will cause an error here. - Running make in the module directory show a call to libgrass_gis.7.0.1svn.dylib, but with the wrong path. It tries to load the library from the final package path (after installation), which doesn't exists yet.. see the last lines of this output: cd scripts/d.correlate/ GuanoAFBIOTA:d.correlate guano$ make if [ /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts/d.correlate != ] ; then GISRC=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/demolocation/.grassrc70 GISBASE=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0 PATH=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release
Re: [GRASS-dev] Error when compiling using homebrew - says liblas but is gdal???
Glynn Clements gl...@gclements.plus.com writes: Rainer M Krug wrote: | configure:6181: checking for liblas-config | configure:6238: clang -o conftest -g -O2 | -I/usr/local/opt/gettext/include | -I/usr/local/Cellar/liblas/1.8.0/include -I/usr/local/include | -I/usr/local/include -I/usr/local/include conftest.c | -L/usr/local/Cellar/liblas/1.8.0/lib -llas -llas_c | -L/usr/local/lib /usr/local/lib/libboost_program_options-mt.dylib | /usr/local/lib/libboost_thread-mt.dylib | /usr/local/Cellar/gdal/1.11.1_2/lib/libgdal.dylib | /usr/local/lib/libgeotiff.dylib /usr/local/lib/libtiff.dylib 15 | clang: error: no such file or directory: '/usr/local/Cellar/gdal/1.11.1_2/lib/libgdal.dylib' The configure script runs liblas-config --libs to obtain the libraries. liblas-config is saying that it needs /usr/local/Cellar/gdal/1.11.1_2/lib/libgdal.dylib but the linker complains that the file doesn't exist. It may be that libLAS was built against a GDAL library which has since been removed. In which case, you need to either restore that library or re-build libLAS to use and existing version of GDAL (or without GDAL; the dependency is optional). You are spot on! Great. Thanks a lot. This solved the problem. I will add this to the test and to the WIKI page. -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] OSX 10.11 Compiling
Thanks to Glenn, this should be working now: --8---cut here---start-8--- brew install -build-from-source liblas brew install --with-liblas HEAD grass-71 --8---cut here---end---8--- I also updated the wiki at --8---cut here---start-8--- http://grasswiki.osgeo.org/wiki/Compiling_on_MacOSX_using_homebrew#How_to_install_GRASS_GIS_7.1_SVN_Head --8---cut here---end---8--- Cheers, Rainer Rainer M Krug rai...@krugs.de writes: OK - I tried the installation of grass 70 from osgeo4mac and it has the same error. I have reported it on their website (see https://github.com/OSGeo/homebrew-osgeo4mac/issues/102) So it is not a 7.1 issue. Cheers, Rainer Rainer M Krug rai...@krugs.de writes: Carlos Grohmann carlos.grohm...@gmail.com writes: Hi I never installed OS X on a virtual machine, can't help much there.. (I'm using yosemite as primary machine and El Capitan on a secondary one) OK - I will see how it goes. Maybe a second HDD is the easiest option. While we are here, I tried the homebrew tap for 7.1svn on a Yosemite machine and it didn't worked. Could you give me the options you used for , | brew install --HEAD grass-71 ` so that I can check? because on Travis-ci the default installation is installing without errors - I am trying it just now at https://travis-ci.org/rkrug/homebrew-experimental First I tried to install with libLas, add although it installed libels correctly, it can't find the library when running GRASS'configure :== ./configure --prefix=/usr/local/Cellar/grass-71/HEAD --enable-shared --with- checking for gdal-config... /usr/local/opt/gdal/bin/gdal-config rm: conftest.dSYM: is a directory checking whether to use libLAS... yes checking for liblas-config... /usr/local/opt/liblas/bin/liblas-config configure: error: *** Unable to locate libLAS library. Then I tried with libels and it went OK, but when I run: Serenity:~ guano$ /usr/local/bin/grass71 Traceback (most recent call last): File /usr/local/bin/grass71, line 54, in module ENCODING = locale.getdefaultlocale()[1] File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py, line 511, in getdefaultlocale return _parse_localename(localename) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py, line 443, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: UTF-8 Serenity:~ guano$ I have everything (including python) in homebrew and I can install it, although I have not tested any additional options. I just added two more test cases / envelopes on travis-ci (--with-liblas and --with-openblas) to test this and they are running at the moment ... You can see them at https://travis-ci.org/rkrug/homebrew-experimental/builds/74242734 And the --with-liblas fails there as well. OK. I added the -v for the v=compile to get a better picture ... https://travis-ci.org/rkrug/homebrew-experimental/builds/74248159 same errors. I found the following: grass70 not detecting latest source build of libLAS (1.7.0) https://trac.osgeo.org/grass/ticket/2065 And the only reference I see is that liblas newer than 1.7 is installed, but homebrew installs 1.8 - so this is not the problem. OK - I think I narrowed it down: it seems that the problem is gdal. I will open another subject with this. Cheers, Rainer any ideas? thanks Carlos On Tue, Aug 4, 2015 at 10:52 AM, Rainer M Krug rai...@krugs.de wrote: Carlos Grohmann carlos.grohm...@gmail.com writes: Hello Rainer (and devs) I think you only need to join the beta program (although I have the free developer account, just to be able to download xcode-related tools like the comand line tools). Thanks - I registered for the beta program an I am downloading El Capitan at the moment. Can you give any pointers how I can install it in Virtual Box as I do not want to interfere with my production machine and do prefer the flexibility of a virtual machine. I'll take a look at the errors when I have it installed - which might be in two weeks time as I will be on holiday next week. Thanks, Rainer I'll summarise what I know so far about these issues: - When compiling, I get a lot of errors. These are related to creating html docs. As Glynn said, at this pint of compilation, the module is run with --html-description switch to get a list of its options. Any problems with wxpython will cause an error here. - Running make in the module directory show a call to libgrass_gis.7.0.1svn.dylib, but with the wrong path. It tries to load the library from the final package path (after installation), which doesn't exists yet.. see the last lines of this output: cd scripts/d.correlate
Re: [GRASS-dev] OSX 10.11 Compiling
Carlos Grohmann carlos.grohm...@gmail.com writes: Yes, worked fine now. Great Rainer thanks Carlos On Thu, Aug 6, 2015 at 10:49 AM, Rainer M Krug rai...@krugs.de wrote: Thanks to Glenn, this should be working now: --8---cut here---start-8--- brew install -build-from-source liblas brew install --with-liblas HEAD grass-71 --8---cut here---end---8--- I also updated the wiki at --8---cut here---start-8--- http://grasswiki.osgeo.org/wiki/Compiling_on_MacOSX_using_homebrew#How_to_install_GRASS_GIS_7.1_SVN_Head --8---cut here---end---8--- Cheers, Rainer Rainer M Krug rai...@krugs.de writes: OK - I tried the installation of grass 70 from osgeo4mac and it has the same error. I have reported it on their website (see https://github.com/OSGeo/homebrew-osgeo4mac/issues/102) So it is not a 7.1 issue. Cheers, Rainer Rainer M Krug rai...@krugs.de writes: Carlos Grohmann carlos.grohm...@gmail.com writes: Hi I never installed OS X on a virtual machine, can't help much there.. (I'm using yosemite as primary machine and El Capitan on a secondary one) OK - I will see how it goes. Maybe a second HDD is the easiest option. While we are here, I tried the homebrew tap for 7.1svn on a Yosemite machine and it didn't worked. Could you give me the options you used for , | brew install --HEAD grass-71 ` so that I can check? because on Travis-ci the default installation is installing without errors - I am trying it just now at https://travis-ci.org/rkrug/homebrew-experimental First I tried to install with libLas, add although it installed libels correctly, it can't find the library when running GRASS'configure :== ./configure --prefix=/usr/local/Cellar/grass-71/HEAD --enable-shared --with- checking for gdal-config... /usr/local/opt/gdal/bin/gdal-config rm: conftest.dSYM: is a directory checking whether to use libLAS... yes checking for liblas-config... /usr/local/opt/liblas/bin/liblas-config configure: error: *** Unable to locate libLAS library. Then I tried with libels and it went OK, but when I run: Serenity:~ guano$ /usr/local/bin/grass71 Traceback (most recent call last): File /usr/local/bin/grass71, line 54, in module ENCODING = locale.getdefaultlocale()[1] File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py, line 511, in getdefaultlocale return _parse_localename(localename) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py, line 443, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: UTF-8 Serenity:~ guano$ I have everything (including python) in homebrew and I can install it, although I have not tested any additional options. I just added two more test cases / envelopes on travis-ci (--with-liblas and --with-openblas) to test this and they are running at the moment ... You can see them at https://travis-ci.org/rkrug/homebrew-experimental/builds/74242734 And the --with-liblas fails there as well. OK. I added the -v for the v=compile to get a better picture ... https://travis-ci.org/rkrug/homebrew-experimental/builds/74248159 same errors. I found the following: grass70 not detecting latest source build of libLAS (1.7.0) https://trac.osgeo.org/grass/ticket/2065 And the only reference I see is that liblas newer than 1.7 is installed, but homebrew installs 1.8 - so this is not the problem. OK - I think I narrowed it down: it seems that the problem is gdal. I will open another subject with this. Cheers, Rainer any ideas? thanks Carlos On Tue, Aug 4, 2015 at 10:52 AM, Rainer M Krug rai...@krugs.de wrote: Carlos Grohmann carlos.grohm...@gmail.com writes: Hello Rainer (and devs) I think you only need to join the beta program (although I have the free developer account, just to be able to download xcode-related tools like the comand line tools). Thanks - I registered for the beta program an I am downloading El Capitan at the moment. Can you give any pointers how I can install it in Virtual Box as I do not want to interfere with my production machine and do prefer the flexibility of a virtual machine. I'll take a look at the errors when I have it installed - which might be in two weeks time as I will be on holiday next week. Thanks, Rainer I'll summarise what I know so far about these issues: - When compiling, I get a lot of errors. These are related to creating html docs. As Glynn said, at this pint of compilation, the module is run with --html-description switch to get a list of its
Re: [GRASS-dev] OSX 10.11 Compiling
Carlos Grohmann carlos.grohm...@gmail.com writes: Hi I never installed OS X on a virtual machine, can't help much there.. (I'm using yosemite as primary machine and El Capitan on a secondary one) OK - I will see how it goes. Maybe a second HDD is the easiest option. While we are here, I tried the homebrew tap for 7.1svn on a Yosemite machine and it didn't worked. Could you give me the options you used for , | brew install --HEAD grass-71 ` so that I can check? because on Travis-ci the default installation is installing without errors - I am trying it just now at --8---cut here---start-8--- https://travis-ci.org/rkrug/homebrew-experimental --8---cut here---end---8--- First I tried to install with libLas, add although it installed libels correctly, it can't find the library when running GRASS'configure :== ./configure --prefix=/usr/local/Cellar/grass-71/HEAD --enable-shared --with- checking for gdal-config... /usr/local/opt/gdal/bin/gdal-config rm: conftest.dSYM: is a directory checking whether to use libLAS... yes checking for liblas-config... /usr/local/opt/liblas/bin/liblas-config configure: error: *** Unable to locate libLAS library. Then I tried with libels and it went OK, but when I run: Serenity:~ guano$ /usr/local/bin/grass71 Traceback (most recent call last): File /usr/local/bin/grass71, line 54, in module ENCODING = locale.getdefaultlocale()[1] File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py, line 511, in getdefaultlocale return _parse_localename(localename) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py, line 443, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: UTF-8 Serenity:~ guano$ I have everything (including python) in homebrew and I can install it, although I have not tested any additional options. I just added two more test cases / envelopes on travis-ci (--with-liblas and --with-openblas) to test this and they are running at the moment ... You can see them at --8---cut here---start-8--- https://travis-ci.org/rkrug/homebrew-experimental/builds/74242734 --8---cut here---end---8--- And the --with-liblas fails there as well. OK. I added the -v for the v=compile to get a better picture ... --8---cut here---start-8--- https://travis-ci.org/rkrug/homebrew-experimental/builds/74248159 --8---cut here---end---8--- same errors. I found the following: grass70 not detecting latest source build of libLAS (1.7.0) --8---cut here---start-8--- https://trac.osgeo.org/grass/ticket/2065 --8---cut here---end---8--- And the only reference I see is that liblas newer than 1.7 is installed, but homebrew installs 1.8 - so this is not the problem. OK - I think I narrowed it down: it seems that the problem is gdal. I will open another subject with this. Cheers, Rainer any ideas? thanks Carlos On Tue, Aug 4, 2015 at 10:52 AM, Rainer M Krug rai...@krugs.de wrote: Carlos Grohmann carlos.grohm...@gmail.com writes: Hello Rainer (and devs) I think you only need to join the beta program (although I have the free developer account, just to be able to download xcode-related tools like the comand line tools). Thanks - I registered for the beta program an I am downloading El Capitan at the moment. Can you give any pointers how I can install it in Virtual Box as I do not want to interfere with my production machine and do prefer the flexibility of a virtual machine. I'll take a look at the errors when I have it installed - which might be in two weeks time as I will be on holiday next week. Thanks, Rainer I'll summarise what I know so far about these issues: - When compiling, I get a lot of errors. These are related to creating html docs. As Glynn said, at this pint of compilation, the module is run with --html-description switch to get a list of its options. Any problems with wxpython will cause an error here. - Running make in the module directory show a call to libgrass_gis.7.0.1svn.dylib, but with the wrong path. It tries to load the library from the final package path (after installation), which doesn't exists yet.. see the last lines of this output: cd scripts/d.correlate/ GuanoAFBIOTA:d.correlate guano$ make if [ /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts/d.correlate != ] ; then GISRC=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/demolocation/.grassrc70 GISBASE=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0 PATH
[GRASS-dev] Error when compiling using homebrew - says liblas but is gdal???
Mac OS X Yosemite, homebrew recipe.
,
| Checking for gdal-config... /usr/local/opt/gdal/bin/gdal-config
| rm: conftest.dSYM: is a directory
| checking whether to use libLAS... yes
| checking for liblas-config... /usr/local/opt/liblas/bin/liblas-config
| configure: error: *** Unable to locate libLAS library.
`
The config.log says:
,
| ...
| onfigure:6164: checking whether to use libLAS
| configure:6181: checking for liblas-config
| configure:6238: clang -o conftest -g -O2 -I/usr/local/opt/gettext/include
-I/usr/local/Cellar/liblas/1.8.0/include -I/usr/local/include
-I/usr/local/include -I/usr/local/include conftest.c
-L/usr/local/Cellar/liblas/1.8.0/lib -llas -llas_c -L/usr/local/lib
/usr/local/lib/libboost_program_options-mt.dylib
/usr/local/lib/libboost_thread-mt.dylib
/usr/local/Cellar/gdal/1.11.1_2/lib/libgdal.dylib
/usr/local/lib/libgeotiff.dylib /usr/local/lib/libtiff.dylib 15
| clang: error: no such file or directory:
'/usr/local/Cellar/gdal/1.11.1_2/lib/libgdal.dylib'
| configure: failed program was:
| #line 6231 configure
| #include confdefs.h
| #include liblas/capi/liblas.h
| int main() {
| LASReader_Create(foo);
| ; return 0; }
| configure:6253: clang -o conftest -g -O2 -I/usr/local/opt/gettext/include
-I/usr/local/Cellar/liblas/1.8.0/include -I/usr/local/include
-I/usr/local/include -I/usr/local/include conftest.c
-L/usr/local/Cellar/liblas/1.8.0/lib -llas -llas_c -L/usr/local/lib
/usr/local/lib/libboost_program_options-mt.dylib
/usr/local/lib/libboost_thread-mt.dylib
/usr/local/Cellar/gdal/1.11.1_2/lib/libgdal.dylib
/usr/local/lib/libgeotiff.dylib /usr/local/lib/libtiff.dylib 15
| clang: error: no such file or directory:
'/usr/local/Cellar/gdal/1.11.1_2/lib/libgdal.dylib'
| configure: failed program was:
| #line 6246 configure
| #include confdefs.h
| #include liblas/capi/liblas.h
| int main() {
| LASReader_Create(foo);
| ; return 0; }
`
So the error is somewhere in the config logic and gdal?
gdal is installed - but /usr/local/Cellar/gdal/1.11.2_2
The installation works when I install without liblas.
Any suggestions on how to proceed?
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa
Tel : +33 - (0)9 53 10 27 44
Cell: +33 - (0)6 85 62 59 98
Fax : +33 - (0)9 58 10 27 44
Fax (D):+49 - (0)3 21 21 25 22 44
email: rai...@krugs.de
Skype: RMkrug
PGP: 0x0F52F982
signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] OSX 10.11 Compiling
Carlos Grohmann carlos.grohm...@gmail.com writes: Hello Rainer (and devs) I think you only need to join the beta program (although I have the free developer account, just to be able to download xcode-related tools like the comand line tools). Thanks - I registered for the beta program an I am downloading El Capitan at the moment. Can you give any pointers how I can install it in Virtual Box as I do not want to interfere with my production machine and do prefer the flexibility of a virtual machine. I'll take a look at the errors when I have it installed - which might be in two weeks time as I will be on holiday next week. Thanks, Rainer I'll summarise what I know so far about these issues: - When compiling, I get a lot of errors. These are related to creating html docs. As Glynn said, at this pint of compilation, the module is run with --html-description switch to get a list of its options. Any problems with wxpython will cause an error here. - Running make in the module directory show a call to libgrass_gis.7.0.1svn.dylib, but with the wrong path. It tries to load the library from the final package path (after installation), which doesn't exists yet.. see the last lines of this output: cd scripts/d.correlate/ GuanoAFBIOTA:d.correlate guano$ make if [ /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts/d.correlate != ] ; then GISRC=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/demolocation/.grassrc70 GISBASE=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0 PATH=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts:$PATH PYTHONPATH=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/etc/python:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/gui/wxpython:$PYTHONPATH DYLD_LIBRARY_PATH=/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/lib:/Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/lib: LC_ALL=C /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/scripts/d.correlate --html-description /dev/null | grep -v '/body\|/html' d.correlate.tmp.html ; fi dyld: Library not loaded: /Applications/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1svn.dylib Referenced from: /Users/guano/Documents/installs/grass70_release/dist.x86_64-apple-darwin15.0.0/bin/g.parser Reason: image not found make: *** [d.correlate.tmp.html] Error 1 rm d.correlate.tmp.html - Ignoring the error and creating the package will work, and the package will install, although when run, the GUI will fail: from grass.pygrass import messages Traceback (most recent call last): File stdin, line 1, in module File /Applications/GRASS-7.0.app/Contents/MacOS/etc/python/grass/pygrass/messages/__init__.py, line 19, in module import grass.lib.gis as libgis File /Applications/GRASS-7.0.app/Contents/MacOS/etc/python/grass/lib/gis.py, line 23, in module _libs[grass_gis.7.0.1RC2] = load_library(grass_gis.7.0.1RC2) File /Applications/GRASS-7.0.app/Contents/MacOS/etc/python/grass/lib/ctypes_loader.py, line 57, in load_library raise ImportError,%s not found. % libname ImportError: grass_gis.7.0.1RC2 not found. cheers Carlos On Sun, Aug 2, 2015 at 7:51 AM, Rainer M Krug r.m.k...@gmail.com wrote: Envoyé de mon iPhone Le 31 juil. 2015 à 23:07, Carlos Grohmann carlos.grohm...@gmail.com a écrit : Hi The homebrew formula doesn't really work on OSX 10.11 beta. In the log file (attached) I can see the same errors in compilation I got when tried to compile svn. They are related to html manual pages, but prevent installation from continue. As I do not have 10.11 beta I can't check it. But please let me (and osgeo4mac) know when you found a solution as I think it will also affect 6.4x and 7.0x versions. Do I have to have a developer account with apple to have access to the beta? Cheers Rainer Carlos brew tap rkrug/head-only == Tapping rkrug/head-only Cloning into '/usr/local/Library/Taps/rkrug/homebrew-head-only'... remote: Counting objects: 4, done. remote: Compressing objects: 100% (4/4), done. remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0 Unpacking objects: 100% (4/4), done. Checking connectivity... done. Tapped 1 formula (27 files, 116K) brew install grass-71 Error: rkrug/head-only/grass-71 is a head-only formula Install with `brew install --HEAD rkrug/head-only/grass-71` brew install --HEAD rkrug
Re: [GRASS-dev] New section in GRASS wiki for installation under Mac using homebrew
Anna Petrášová kratocha...@gmail.com writes: On Thu, Jul 30, 2015 at 6:38 AM, Rainer M Krug rai...@krugs.de wrote: Hi I just added a section / new page in the WIKI for installation of GRASS using homebrew. Please see http://grasswiki.osgeo.org/wiki/Compile_and_Install#Mac_OSX and http://grasswiki.osgeo.org/wiki/Compiling_on_MacOSX_using_homebrew It would be great if some Mac / homebrew users would see if it works and give me comments here. I will try to test it next week. Thank you for your efforts! Great - let me know how it goes, although I don't know if I will be able to reply as I am away and possibly only have very limited internet access. Thanks, Rainer Anna Cheers, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Travis CI
Markus Neteler nete...@osgeo.org writes: On Tue, Jul 28, 2015 at 3:39 PM, Rainer M Krug rai...@krugs.de wrote: ... If you tell me where (on which page in the wiki or on a new page?), I could probably add it this evening - Oh - do I need write access to the wiki? Yes. Thanks to the spammers we cannot avoid that. There is a related registration link as in any Mediawiki instance. Would http://grasswiki.osgeo.org/wiki/Compile_and_Install#Mac_OSX be appropriate? It seems that I can just edit it and do not need special access there? You need to register. Perhaps you want to write it up in a separate page and link there in order to avoid that the main Compile_and_Install page gets too long. Good idea. I just started this. Thanks, Rainer Markus Rainer Thanks, Rainer Markus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Travis CI
Markus Neteler nete...@osgeo.org writes: Hi Rainer, On Jul 28, 2015 10:11 AM, Rainer M Krug rai...@krugs.de wrote: Ivan Mincik ivan.min...@gmail.com writes: ... I am using homebrew, a package manager for OSX. This simplifies the compilation significantly as it takes care of all dependencies. So the installation script (called recipe) is at [1] and adapted from the 7.0 of osgeo4mac [2]. The travis script uses my recipe from [1] and installs GRASS 7.1 from HEAD. I'll walk you quickly through the .travis.yml at [3]: ... Maybe these explanations should go into a wiki or trac page? To not get lost? I would be happy to write the installation steps down for GRASS for OSX using homebrew with the recipe in my repository. If you tell me where (on which page in the wiki or on a new page?), I could probably add it this evening - Oh - do I need write access to the wiki? Thanks, Rainer Markus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Travis CI
Rainer M Krug rai...@krugs.de writes: Markus Neteler nete...@osgeo.org writes: Hi Rainer, On Jul 28, 2015 10:11 AM, Rainer M Krug rai...@krugs.de wrote: Ivan Mincik ivan.min...@gmail.com writes: ... I am using homebrew, a package manager for OSX. This simplifies the compilation significantly as it takes care of all dependencies. So the installation script (called recipe) is at [1] and adapted from the 7.0 of osgeo4mac [2]. The travis script uses my recipe from [1] and installs GRASS 7.1 from HEAD. I'll walk you quickly through the .travis.yml at [3]: ... Maybe these explanations should go into a wiki or trac page? To not get lost? I would be happy to write the installation steps down for GRASS for OSX using homebrew with the recipe in my repository. If you tell me where (on which page in the wiki or on a new page?), I could probably add it this evening - Oh - do I need write access to the wiki? Would http://grasswiki.osgeo.org/wiki/Compile_and_Install#Mac_OSX be appropriate? It seems that I can just edit it and do not need special access there? Rainer Thanks, Rainer Markus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Travis CI
Ivan Minčík ivan.min...@gmail.com writes: Hi all, we have just integrated Travis Continuous Integration system [1] to the GRASS source code. Every commit is now build in Travis [2] using gcc and clang. In case the build fails, error message should go to GRASS-dev list. This looks very nice - great. But I see it only =compiles under Linux. I have a .travis.yml [1] and a homebrew formula [2] to install 7.1 from head under OSX which is also running the tests (although the test are not running at the moment - I have to investigate why). I would suggest to merge the check for Mac into your .travis.yml so that Mac builds are also checked automatically. Cheers, Rainer 1 - https://trac.osgeo.org/grass/browser/grass/trunk/.travis.yml 2 - https://travis-ci.org/GRASS-GIS/grass-ci Footnotes: [1] https://github.com/rkrug/homebrew-experimental/blob/master/.travis.yml [2] https://github.com/rkrug/homebrew-head-only -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Weekly snapshot - link with non-changing name?
Vaclav Petras wenzesl...@gmail.com writes: On Fri, Jun 26, 2015 at 4:52 AM, Rainer M Krug rai...@krugs.de wrote: Hi Vaclav, Vaclav Petras wenzesl...@gmail.com writes: On Mon, Jun 22, 2015 at 9:40 AM, Rainer M Krug rai...@krugs.de wrote: Markus Neteler nete...@osgeo.org writes: On Jun 20, 2015 5:16 PM, Rainer M Krug rai...@krugs.de wrote: Vaclav Petras wenzesl...@gmail.com writes: It is really just a automatic snapshot, not a tested release. Thanks - so I will then use HEAD of the svn - easier to do in homebrew, as no sha hash is needed of the downloaded file. You want me to generate that? No - no need. I just tell homebrew to download head from svn and than to compile it - it works. I will post a link to the recipe later this week. This will make testing of GRASS 7.1 easy on OS X. And it can be combined with: cd /grass/source/code/root ./bin.../grass71 ~/grassdata/nc_spm_08/PERMANENT/ \ --exec python -m grass.gunittest.main \ --location nc_spm_08 --location-type nc That is a brilliant idea. But as the tests will be run automatically, I need to download the data. The download could be added to test execution but I'm not sure about that. It would just make it more complex. I assume this is the dataset to be used: http://grass.osgeo.org/sampledata/north_carolina/nc_spm_08_grass7.tar.gz Is this correct? Yes. Although, there are some inconsistencies (some test fail because they expect the basic nc spm). However, this all should change because we should switch to the new sample dataset naming scheme [1]. Needless to say, volunteers needed. Is (or will) the dataset be on a svn or git? This would make always using the latest one very easy. Cheers, Rainer Vaclav [1] https://trac.osgeo.org/grass/wiki/SampleDataset Rainer Thanks a lot, Rainer Markus Thanks, Rainer Vaclav Thanks, Rainer Rainer Markus -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Weekly snapshot - link with non-changing name?
Hi Vaclav, Vaclav Petras wenzesl...@gmail.com writes: On Mon, Jun 22, 2015 at 9:40 AM, Rainer M Krug rai...@krugs.de wrote: Markus Neteler nete...@osgeo.org writes: On Jun 20, 2015 5:16 PM, Rainer M Krug rai...@krugs.de wrote: Vaclav Petras wenzesl...@gmail.com writes: It is really just a automatic snapshot, not a tested release. Thanks - so I will then use HEAD of the svn - easier to do in homebrew, as no sha hash is needed of the downloaded file. You want me to generate that? No - no need. I just tell homebrew to download head from svn and than to compile it - it works. I will post a link to the recipe later this week. This will make testing of GRASS 7.1 easy on OS X. And it can be combined with: cd /grass/source/code/root ./bin.../grass71 ~/grassdata/nc_spm_08/PERMANENT/ \ --exec python -m grass.gunittest.main \ --location nc_spm_08 --location-type nc That is a brilliant idea. But as the tests will be run automatically, I need to download the data. I assume this is the dataset to be used: http://grass.osgeo.org/sampledata/north_carolina/nc_spm_08_grass7.tar.gz Is this correct? Rainer Thanks a lot, Rainer Markus Thanks, Rainer Vaclav Thanks, Rainer Rainer Markus -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] For OS X: homebrew tap to install and test grass 7.1 from HEAD
Hi This is for OS X. I have created a homebrew [1] tap to make installing and testing of GRASS 7.1 (HEAD from svn) easier. You can find it here: https://github.com/rkrug/homebrew-experimental It uses homebrew [1] and installs 1) homebrew 2) North Carolina sample data set The grass-71 recipe includes a test , | brew test grass-71 ` which uses the dataset to run unit tests as suggested by Vaclav (with paths adjusted according to the location of the sample dataset as installed using homebrew): , | ./bin.../grass71 ~/grassdata/nc_spm_08/PERMANENT/ \ | --exec python -m grass.gunittest.main \ | --location nc_spm_08 --location-type nc ` These are my first steps into homebrew - so please check the recipes and let me know if something does not work (preferably via the issue tracker if it is a bug so that nothing gets lost). Hope this helps, Rainer Footnotes: [1] http://brew.sh -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Weekly snapshot - link with non-changing name?
Markus Neteler nete...@osgeo.org writes: On Jun 20, 2015 5:16 PM, Rainer M Krug rai...@krugs.de wrote: Vaclav Petras wenzesl...@gmail.com writes: It is really just a automatic snapshot, not a tested release. Thanks - so I will then use HEAD of the svn - easier to do in homebrew, as no sha hash is needed of the downloaded file. You want me to generate that? No - no need. I just tell homebrew to download head from svn and than to compile it - it works. I will post a link to the recipe later this week. This will make testing of GRASS 7.1 easy on OS X. Thanks a lot, Rainer Markus Thanks, Rainer Vaclav Thanks, Rainer Rainer Markus -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Weekly snapshot - link with non-changing name?
Rainer M Krug rai...@krugs.de writes: Markus Neteler nete...@osgeo.org writes: On Fri, Jun 19, 2015 at 10:42 AM, Rainer M Krug rai...@krugs.de wrote: Hi I have a homebrew recipe for installing grass 7.1 on a Mac. But whenever I want to update to a new weekly snapshot, I have to change the URL from which to download the weekly snapshot. Would it be possible to add a link, e,g, , | http://grass.osgeo.org/grass71/source/snapshot/grass-7.1.weekly_snapshot.tar.gz ` so that the URL used can stay the same? Yes, done: http://grass.osgeo.org/grass71/source/snapshot/ -- grass-7.1.svn_src_snapshot_latest.tar.gz this is a link to the latest snashot file. Perfect - thanks. Quick follow up - is the weekly snapshot supposed to be more stable than the svn version, or is is simply a snapshot taken automatically once a week? Thanks, Rainer Rainer Markus -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Weekly snapshot - link with non-changing name?
Vaclav Petras wenzesl...@gmail.com writes: On Sat, Jun 20, 2015 at 9:02 AM, Rainer M Krug rai...@krugs.de wrote: Rainer M Krug rai...@krugs.de writes: Markus Neteler nete...@osgeo.org writes: On Fri, Jun 19, 2015 at 10:42 AM, Rainer M Krug rai...@krugs.de wrote: Hi I have a homebrew recipe for installing grass 7.1 on a Mac. But whenever I want to update to a new weekly snapshot, I have to change the URL from which to download the weekly snapshot. Would it be possible to add a link, e,g, , | http://grass.osgeo.org/grass71/source/snapshot/grass-7.1.weekly_snapshot.tar.gz ` so that the URL used can stay the same? Yes, done: http://grass.osgeo.org/grass71/source/snapshot/ -- grass-7.1.svn_src_snapshot_latest.tar.gz this is a link to the latest snashot file. Perfect - thanks. Quick follow up - is the weekly snapshot supposed to be more stable than the svn version, or is is simply a snapshot taken automatically once a week? The latter. It is really just a automatic snapshot, not a tested release. Thanks - so I will then use HEAD of the svn - easier to do in homebrew, as no sha hash is needed of the downloaded file. Thanks, Rainer Vaclav Thanks, Rainer Rainer Markus -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Weekly snapshot - link with non-changing name?
Hi I have a homebrew recipe for installing grass 7.1 on a Mac. But whenever I want to update to a new weekly snapshot, I have to change the URL from which to download the weekly snapshot. Would it be possible to add a link, e,g, , | http://grass.osgeo.org/grass71/source/snapshot/grass-7.1.weekly_snapshot.tar.gz ` so that the URL used can stay the same? Thanks, Rainer -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Weekly snapshot - link with non-changing name?
Markus Neteler nete...@osgeo.org writes: On Fri, Jun 19, 2015 at 10:42 AM, Rainer M Krug rai...@krugs.de wrote: Hi I have a homebrew recipe for installing grass 7.1 on a Mac. But whenever I want to update to a new weekly snapshot, I have to change the URL from which to download the weekly snapshot. Would it be possible to add a link, e,g, , | http://grass.osgeo.org/grass71/source/snapshot/grass-7.1.weekly_snapshot.tar.gz ` so that the URL used can stay the same? Yes, done: http://grass.osgeo.org/grass71/source/snapshot/ -- grass-7.1.svn_src_snapshot_latest.tar.gz this is a link to the latest snashot file. Perfect - thanks. Rainer Markus -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Getting version number *before* starting
Vaclav Petras wenzesl...@gmail.com writes:
On Thu, Jan 29, 2015 at 9:51 AM, Rainer M Krug rai...@krugs.de wrote:
Hi
I would, for implementation in spgrass7 in R, to be able to get the version
number of GRASS GIS before starting GRASS.
I know about the --version parameter of grass command.
This is for human consumption and, as you point out below, has changed
quite a bit - actually I think that the version info is just plainly
missing from GRASS GIS 7.0.0RC1 as I think it should be before the
license?
{{{
$ grass64 --version
GRASS GIS 6.4.4
Geographic Resources Analysis Support System (GRASS) is Copyright,
1999-2014 by the GRASS Development Team, and licensed under terms of the
GNU General Public License (GPL) version =2.
This GRASS 6.4.4 release is coordinated and produced by the...
}}}
Unfortunately for GRASS GIS 7 it is giving more the license and about then
the version:
{{{
$ grass71 --version
Geographic Resources Analysis Support System (GRASS) is Copyright,
1999-2014 by the GRASS Development Team, and licensed under terms of the
GNU General Public License (GPL) version =2.
This GRASS 7.1.svn release is coordinated and produced by
}}}
Although, I'm running 71 from source code, so it might be different.
To get general idea, here are examples what other projects have in
--version:
{{{
gcc --version
gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
...
}}}
{{{
pandoc --version
pandoc 1.12.2.1
Compiled with texmath 0.6.5.2, highlighting-kate 0.5.5.1.
Syntax highlighting is supported for the following languages:
...
}}}
Yup - they all have the version in the first line, bur RC1 has it not -
I think this is a bug?
Thanks,
Rainer
I know that in the file
,
| GRASS_BASE_DIRECTORY/etc/VERSIONNUMBER
`
the version number is stored, but I have two questions:
1) is this the same between systems (I saw it in Mac Linux and Windows)?
2) I assume the location of this file is very un-likely to change?
3) can the internal structure of the GDRASS_BASE_DIRECTORY be configured
during the build process (particularly the bin/ and the location of
VERSIONNUMBER), and if yes, how can I obtain the location of these folders?
So: would there be any downside in just reading this file to determine
the version of GRASS GIS, as the grass startup script seems to be
reading from that file as well?
Thanks,
Rainer
--
Rainer M. Krug
email: Raineratkrugsdotde
PGP: 0x0F52F982
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Rainer M. Krug
email: Raineratkrugsdotde
PGP: 0x0F52F982
signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers
Yann Chemin yche...@gmail.com writes: +1 for a button, but I am not sure sure a data download is that necessary... I think a download button would be useful as the demo location should be in the home directory so that the user can play with it. The disadvantage would be that the user has to be online for this. A compromise could be to have a) an archived location in package form, so that the archive is installed but not the location. This would be an optional package. b) A button which, depending on whether the grass-demodata package has been installed, extracts the archived location into the home directory or, if it has not been installed, suggests to download it. Cheers, Rainer The button might just be a script creating a (several?) empty Location(s?) in a directory that the user can choose. On 30 January 2015 at 15:20, Moritz Lennert mlenn...@club.worldonline.be wrote: On 29/01/15 17:43, Vaclav Petras wrote: On the MS Windows installer takes care of that by copying demo Location to newly created grassdata dir in Documents and creating the rc file. Is this enough? If not why? And do we want to do something similar for cases when installation is not done by GRASS GIS? If startup detects no grassdata it could just create the dir and copy the demo Location there, so the only thing needed is to press Start button. Don't forget that in many GNU/Linux distributions data is separated from applications in the packaging. So, either we have to tell users to install a specific data package (e.g. grass-demodata) or the startup screen needs a button: Download and unpack demo data. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Getting version number *before* starting
Vaclav Petras wenzesl...@gmail.com writes:
On Thu, Jan 29, 2015 at 5:20 PM, Blumentrath, Stefan
stefan.blumentr...@nina.no wrote:
What about grass70 --config?
Cheers
Stefan
--config does not work for 64.
unfortunately not - but one could always make an exception for 64.
For 70 it does not give version, only revision (of library I think). We
should probably change the format to be more parseable. The line order is
really not stable, I'm not sure what other do.
$ grass71 --config
x86_64-unknown-linux-gnu
./configure --enable-largefile=yes --with-nls --with-cxx --with-readline
--with-pthread --with-proj-share=/usr/share/proj
--with-geos=/usr/bin/geos-config --with-wxwidgets --with-cairo
--with-opengl-libs=/usr/include/GL --with-freetype=yes
--with-freetype-includes=/usr/include/freetype2/ --with-postgresql=yes
--with-postgres-includes=/usr/include/postgresql --with-sqlite=yes
--with-mysql=yes --with-mysql-includes=/usr/include/mysql --with-odbc=no
--with-liblas=yes --with-liblas-config=/usr/bin/liblas-config
gcc
/home/vasek/dev/grass/gcc_trunk/dist.x86_64-unknown-linux-gnu
63639
}}}
70 --help has actually version number on the first line as 64 --version has
but 64 --help does not have the version, except for usage (at least the one
from Ubuntu package).
I'm afraid we have to implement something better. What would it be?
A parsable format would be really nice here, as most of the information
needed is here.
Some standard fields as
- MAJOR version (e.g. 7)
- MINOR version (e.g. 1)
- PATCH version (e.g. 0)
- version EXTENSION (e.g. alpha)
- REVISION
- PLATFORM (e.g. x86_64-unknown-linux-gnu)
- grass BASE directory (e.g.
/home/vasek/dev/grass/gcc_trunk/dist.x86_64-unknown-linux-gnu) (I
assume the bin/ is in the base directory?)
- the CONFIGURE options - possibly split into separate and multiple
entries
A format like the Debian Control Files Syntax [1], which is defined and
easily parsable from different languages, would be the easiest.
I don't know if something like this can be still incorporated into
7.0.0?
This would be really nice and useful.
Thanks,
Rainer
*From:* grass-dev-boun...@lists.osgeo.org [mailto:
grass-dev-boun...@lists.osgeo.org] *On Behalf Of *Vaclav Petras
*Sent:* 29. januar 2015 23:10
*To:* Rainer M Krug
*Cc:* grass-dev@lists.osgeo.org
*Subject:* Re: [GRASS-dev] Getting version number *before* starting
On Thu, Jan 29, 2015 at 9:51 AM, Rainer M Krug rai...@krugs.de wrote:
Hi
I would, for implementation in spgrass7 in R, to be able to get the version
number of GRASS GIS before starting GRASS.
I know about the --version parameter of grass command.
{{{
$ grass64 --version
GRASS GIS 6.4.4
Geographic Resources Analysis Support System (GRASS) is Copyright,
1999-2014 by the GRASS Development Team, and licensed under terms of the
GNU General Public License (GPL) version =2.
This GRASS 6.4.4 release is coordinated and produced by the...
}}}
Unfortunately for GRASS GIS 7 it is giving more the license and about then
the version:
{{{
$ grass71 --version
Geographic Resources Analysis Support System (GRASS) is Copyright,
1999-2014 by the GRASS Development Team, and licensed under terms of the
GNU General Public License (GPL) version =2.
This GRASS 7.1.svn release is coordinated and produced by
}}}
Although, I'm running 71 from source code, so it might be different.
To get general idea, here are examples what other projects have in
--version:
{{{
gcc --version
gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
...
}}}
{{{
pandoc --version
pandoc 1.12.2.1
Compiled with texmath 0.6.5.2, highlighting-kate 0.5.5.1.
Syntax highlighting is supported for the following languages:
...
}}}
I know that in the file
,
| GRASS_BASE_DIRECTORY/etc/VERSIONNUMBER
`
the version number is stored, but I have two questions:
1) is this the same between systems (I saw it in Mac Linux and Windows)?
2) I assume the location of this file is very un-likely to change?
3) can the internal structure of the GDRASS_BASE_DIRECTORY be configured
during the build process (particularly the bin/ and the location of
VERSIONNUMBER), and if yes, how can I obtain the location of these folders?
So: would there be any downside in just reading this file to determine
the version of GRASS GIS, as the grass startup script seems to be
reading from that file as well?
Thanks,
Rainer
--
Rainer M. Krug
email: Raineratkrugsdotde
PGP: 0x0F52F982
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Footnotes:
[1] http://www.debian.org/doc/debian
[GRASS-dev] [BUG 7.0.90RC1] Version not stated explicitly in RC1
The version info of GRASS GIS 7.0.0RC1 is missing the explicit statement of the version number - see output below. It is mentioned in the contributions section, but not explicitly as the first line as in GRASS GIS 6.4.4 Thanks, Rainer , | $ grass70 --version | | Geographic Resources Analysis Support System (GRASS) is Copyright, | 1999-2015 by the GRASS Development Team, and licensed under terms of the | GNU General Public License (GPL) version =2. | | This GRASS 7.0.0RC1 release is coordinated and produced by | the GRASS Development Team with contributions from all over the world. | | This program is distributed in the hope that it will be useful, but | WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | General Public License for more details. | | $ grass64 --version | GRASS GIS 6.4.4 | | Geographic Resources Analysis Support System (GRASS) is Copyright, | 1999-2014 by the GRASS Development Team, and licensed under terms of the | GNU General Public License (GPL) version =2. | | This GRASS 6.4.4 release is coordinated and produced by the | GRASS Development Team with contributions from all over the world. | | This program is distributed in the hope that it will be useful, but | WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | General Public License for more details. | 10:46:06 ~/Documents/Projects/R-Packages/spgrass/pkg$ ` -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [BUG 7.0.90RC1] Version not stated explicitly in RC1
Markus Neteler nete...@osgeo.org writes: On Fri, Jan 30, 2015 at 10:49 AM, Rainer M Krug rai...@krugs.de wrote: The version info of GRASS GIS 7.0.0RC1 is missing the explicit statement of the version number - see output below. It is mentioned in the contributions section, but not explicitly as the first line as in GRASS GIS 6.4.4 Thanks, Rainer , | $ grass70 --version | | Geographic Resources Analysis Support System (GRASS) is Copyright, Fixed in r64361. + r64362. Thanks Rainer grass71 --version GRASS GIS 7.1.svn Geographic Resources Analysis Support System (GRASS) is Copyright, 1999-2015 by the GRASS Development Team, and licensed under terms of the GNU General Public License (GPL) version =2. This GRASS GIS 7.1.svn release is coordinated and produced by the GRASS Development Team with contributions from all over the world. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. (likewise done for 7.0.x) Markus -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Getting version number *before* starting
Hi I would, for implementation in spgrass7 in R, to be able to get the version number of GRASS GIS before starting GRASS. I know that in the file , | GRASS_BASE_DIRECTORY/etc/VERSIONNUMBER ` the version number is stored, but I have two questions: 1) is this the same between systems (I saw it in Mac Linux and Windows)? 2) I assume the location of this file is very un-likely to change? 3) can the internal structure of the GDRASS_BASE_DIRECTORY be configured during the build process (particularly the bin/ and the location of VERSIONNUMBER), and if yes, how can I obtain the location of these folders? So: would there be any downside in just reading this file to determine the version of GRASS GIS, as the grass startup script seems to be reading from that file as well? Thanks, Rainer -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers
Yann Chemin yche...@gmail.com writes: On 23 January 2015 at 15:46, Martin Landa landa.mar...@gmail.com wrote: Hi, 2015-01-23 9:20 GMT+01:00 Markus Neteler nete...@osgeo.org: my motivation to discuss the current welcome screen is that too many potential new users try to launch GRASS, do not get past that screen and walk away (too difficult). Yes, and they will likely not read the manual but just take another GIS. This is a multiple times reported fact. I have met a lot of GIS specialists who told me: I tried several times to use GRASS in different decades and I end up with the same result, I didn't managed to get my data in, so I gave up. Yes, I also had those experiences told to me. Is it possible to open GRASS GIS wxGUI without setting the GISDB/Location/mapset yet? Then from inside the opened software you will need to go through those steps anyway before doing anything... Would that make any psychological difference? I think this would make a huge difference - especially if the creation could be done by triggerd upon import and - asking for a directory (for the db), - name of the location, - name of the mapset, and - taking the other parameter (projection, extend) from the data to be imported. Until a mapset is opened, the non-usable menu items could be greyed out. Rainer It' a sign in my eyes that we should think how to simplify this step ;-) Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers
Nikos Alexandris n...@nikosalexandris.net writes: On 22.01.2015 09:51, Yann Chemin wrote: http://docs.qgis.org/2.2/ko/docs/training_manual/grass/grass_setup.html http://docs.qgis.org/2.2/ko/_images/grass_folder.png Spanish text https://ecoslackware.wordpress.com/tag/grass-qgis-plugin/ Italian text http://qgis4dummies.wikidot.com/grass-plugin Right, I forgot the global map indicating the Extent with a red-bordered box. This is an absolute winner! Absolutely - Quite often, I used QGIS to create the location, then left QGIS and continued working in GRASS GIS. Nikos -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers
Markus Metz markus.metz.gisw...@gmail.com writes: On Wed, Jan 21, 2015 at 11:15 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Wed, Jan 21, 2015 at 4:55 PM, Markus Neteler nete...@osgeo.org wrote: On Wed, Jan 21, 2015 at 8:16 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 21/01/15 19:35, Markus Neteler wrote: In my opinion we should not have the location selection dialog at all. Revolution! We should start GRASS right away in latlong like most GIS in the world. Then let the user open the dialog to change projection if desired from inside. This would avoid a lot of questions right away. Please don't do this ! OK, now being back from phone to a real keyboard, I can write a few more lines. I am thinking about this issue for seeral years meanwhile (hint: I started in 1993 to use the software, getting stuck at the text start screen not having a manual :-). So my full suggestions are - beautify the actual screen (hence my recent suggestion which is lively discussed here), - optionally (!) allow to start GRASS without welcome/loc/mapset screen but to open it in LatLong as described above. Again, as an option. We could implement that in trunk and see how it goes. All the tools to select locations, projections and such are there. I think that you have to go all the work anyway and the dummy location is there just to show that it is possible. There are some potential problems, for example how it works now with the .bash_history file? I find the fact that GRASS does not provide a default projection system, but forces the user to think about projection from the start, one of its strengths, both for work and for teaching. On of it strenghts, yes. But I have been teaching GRASS a lot to GIS professionals who got trained on different systems. And many asked why this screen? why cannot you just start like the other GIS? And I tend to agree (again: optionally). The point is that we, on the contrary to many other GIS, still have all the control mechanisms in place which avoid that the user mixes projections. So that's all fine. And what will you do after 'just starting'? Do you have your data as LL? Or will you use -o flag to ignore the projection check? Also in Portland at the FOSS4G conf (where I showcased GRASS GIS 7) people suggested to let 'em get into the system right away. They explained to me that a newcomer wants to see the menu to understand how powerful the system is. But they would get stuck at the welcome screen... Yes, and they don't want to think before they open the program but just try, out of curiosity. This is a good point. I can see that. However, manual is also useful for this. This is what I use. Works for command line programs too. To satisfy everybody, I suggest to provide a buttons with something like Take me to LL, Take me to default location and Take me to XY. What do you think about that? But the real improvement should be the messages which would guide you through the process. A suggestion for a compromise: Have a minimal welcome screen that says something like Starting GRASS GIS in location X, mapset Y Which would be the last opened mapset or, if opened for the first time, the demo mapset? nothing else, no list of all the available locations and mapsets Only two buttons: OK, Change Make OK the default, Change will bring up the current welcome screen. I would add a third button which says Start in demo location to make it easier to return to the demo location after having already used GRASS GIS - for e.g. running examples and tests of other applications which use the demo dataset. The user has then just to hit enter and GRASS is running. This would reduce the (confusing) amount of information on the current welcome screen. It would also give more space for a little graphic ;-) Location and mapset can be taken from GISRC, if that does not exist, create a new GISDBASE in the user's home, put the demolocation in it and use this (I think the wingrass installer is already doing that). This sounds like a good compromise. And if then there is a nice QGIS like dialog to create a new location / mapset including projections, to start GRASS would be much easier. Thinking of it - a history of recently used mapsets on the welcome screen, which shows the projection, extent and the file path, is something which would be really useful. Cheers, Rainer Markus M -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
Luca Delucchi lucadel...@gmail.com writes: On 18 April 2014 11:15, Pietro peter.z...@gmail.com wrote: Hi Vaclav, actually I'm a bit more extremist... :-) I would like to split GRASS in three main parts: - grass-lib - grass-cli - grass-gui I also like this idea... I think this would be a very good idea as it would make the whole GRASS ecosystem more transparent and easier (in my opinion) to maintain and to use certain aspects from different applications. Re functionality in the GUI: The question would be if the split is lib--cli--gui or |--cli lib| |--gui in other words, if the cli is just a non graphical UI or THE interface to the lib, through which the gui operates. I think the first design approach would be the better one. Cheers, Rainer At least should be possible to build these parts separately, leaving the decision to split in several packages to the package maintainer of each distribution (Debian, Fedora, etc.). I think that someone is already doing something like this. But I don't know more because I usually compile myself GRASS Regards Pietro -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
Radim Blazek radim.bla...@gmail.com writes: On Tue, Apr 8, 2014 at 2:18 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 28/03/14 15:16, Paolo Cavallini wrote: Il 28/03/2014 15:04, Martin Dobias ha scritto: On Fri, Mar 28, 2014 at 11:48 AM, Paolo Cavallini cavall...@faunalia.it wrote: * to add GRASS browsing capabilities in QGIS file browser The support for GRASS is already in the browser - if you enter a directory that is a GRASS database, it will detect it and show locations/mapsets/maps/layers. That's great news, never tried. Works beautifully, thanks. I cannot reproduce this. How does it work exactly ? When I browse into a GRASS database directory, it just shows up like any other directory. The GRASS location is added as another item with GRASS icon in the tree on the same level where is the location dir. It means that the location will appear twice, first as regular dir and then as a GRASS location. The items do not seem to be sorted by name, so maybe you have to scroll down. Hm - I think I also need a step-by-step guide. I am using QGIS 2.2.0 on OSX Maverick and I don't get it to work. 0) Open QGIS 1) I open the browser (View - Panels - Browser) 2) Then I go via the Home folder (top entry) to a GRASS database 3) and now, where should I see what? What is the root in the tree structure? I can only see the folder structure. Rainer Radim Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Compiling GRASS under homebrew
Following the thread on compiling GRASS 7 where homebrew was mentioned, I would like to ask two questions about GRASS and homebrew: 1) When installing GRASS from homebrew (stable, not HEAD) I can't launch the WXgui - when I try it from GRASS, I get: , | g.gui wxpython | Launching 'wxpython' GUI in the background, please wait ... | wxgui: realpath couldn't resolve /usr/bin/wxgui ` Any ideas on how I can solve this (the tcltk gui works) 2) Is anybody implementing a recipe for GRASS 7 so that installation will be easier (and testing could start at the same time as for Linux)? Cheers, Rainer -- Rainer M. Krug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Installation of r.mcda.ahp extensions on GRASS 7 OS X fails
Hi I am trying to install some the mcda extensions in GRASS 7, but I get the following error message: , | g.extension extension=r.mcda.ahp svnurl=http://svn.osgeo.org/grass/grass-addons/grass7 | Fetching r.mcda.ahp from GRASS-Addons SVN (be patient)... | Compiling... | access: No such file or directory | ERROR: LOCATION | /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.4.0/demolocation |not available | make: *** [r.mcda.ahp.py.tmp.html] Error 1 | ERROR: Compilation failed, sorry. Please check above error messages. ` I installed the frameworks and GRASS 7 from http://grassmac.wikidot.com/downloads Compilations work (xtools installed, can install R packages from source and I am using macports and homebrew) Any suggestions how I can fix this? Thanks, Rainer -- Rainer M. Krug email: RMKrugatgmaildotcom ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Resources about compiling on Mac OS X
William Kyngesburye wokl...@kyngchaos.com writes: The macosx readme in the source is meant to be the main build instructions, but I have been lax in maintaining them. I think they are still generally good. The other in the macosx/pkg folder is just for the insaller package and has no build instructions. The wiki just looks like some random stuff, and does say that the source instructions are the place to start. While we are at compiling GRASS on OS X - is somb On Sep 5, 2013, at 9:32 PM, Vaclav Petras wrote: My problem actually was that I don't know what is the valid documentation for compilation on Mac OS X. Is there some up-to-date document? Thanks, Vaclav Unrelated: Since there was several discussions about problems with compilation on Mac OS X, I've updated the ticket #2034 with some links and info. [1] https://trac.osgeo.org/grass/ticket/2034 - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Those people who most want to rule people are, ipso-facto, those least suited to do it. - A rule of the universe, from the HitchHiker's Guide to the Galaxy #secure method=pgpmime mode=sign -- Rainer M. Krug email: RMKrugatgmaildotcom ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Resources about compiling on Mac OS X
Sorry - didn't want to send it Rainer M Krug rai...@krugs.de writes: William Kyngesburye wokl...@kyngchaos.com writes: The macosx readme in the source is meant to be the main build instructions, but I have been lax in maintaining them. I think they are still generally good. The other in the macosx/pkg folder is just for the insaller package and has no build instructions. The wiki just looks like some random stuff, and does say that the source instructions are the place to start. While we are at compiling GRASS on OS X - is somb On Sep 5, 2013, at 9:32 PM, Vaclav Petras wrote: My problem actually was that I don't know what is the valid documentation for compilation on Mac OS X. Is there some up-to-date document? Thanks, Vaclav Unrelated: Since there was several discussions about problems with compilation on Mac OS X, I've updated the ticket #2034 with some links and info. [1] https://trac.osgeo.org/grass/ticket/2034 - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Those people who most want to rule people are, ipso-facto, those least suited to do it. - A rule of the universe, from the HitchHiker's Guide to the Galaxy #secure method=pgpmime mode=sign #secure method=pgpmime mode=sign -- Rainer M. Krug email: RMKrugatgmaildotcom ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] start grass with only initializing the environment
Markus Neteler nete...@osgeo.org writes: On Mon, Jul 15, 2013 at 5:44 PM, Rainer M Krug rai...@krugs.de wrote: ... I would therefore suggest an additional startup argument for grass, which only sets the environmental variables, including library paths, so that GRASS commands can be executed afterwards, and if the LOCATION_NAME and MAPSET are not provided, they will be null and *have to be set manualy afterwards*. This could e.g. have the name -noui indicating that no ui will be started. I wonder what the difference to starting GRASS 7 with -text is... Maybe that's already enough? No - this doesn't work. The idea is to use this from R to set the environmental parameter when using spgrass6. If I call grass -text from R (all in the terminal), the grass session opens and I am in grass, but I can not do anything from R, which I want to do. So it seems that the grass startup script recognises that it is not in a shell, and then starts one? If this starting of the shell could be suppressed, I would expect that starting grass with the -text option should work. I would assume that this would be similar to setting GRASS_BATCH_JOB, only that GRASS does not exit automatically. Something like a GRASS_BATCH_MODE - or one could call it a GRASS_SERVER_MODE? Cheers, Rainer Markus -- Rainer M. Krug email: RMKrugatgmaildotcom ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] start grass with only initializing the environment
Hamish hamis...@yahoo.com writes:
Rainer wrote:
I would therefore suggest an additional startup argument for grass,
which only sets the environmental variables, including library paths,
so that GRASS commands can be executed afterwards,
just make your own batch file or function(){} for /etc/bash.bashrc?
Sure - that is how it works at the moment, but I ran into problems: the
problem were library paths, which were not set (on Mac OS X).
Background: the idea is to use in spgrass6 to make it more robust to
different versions and platforms on which it is used.
and if the LOCATION_NAME and MAPSET are not provided, they will be
null and *have to be set manualy afterwards*.
that doesn't sound like a practice we should promote.
what part of the start up are you trying to avoid? ('grass64 -text'
works in 6 too, or 'g.gui text' to avoid the gui at startup)
Please see my other email, in which I explained why -text does not help
here.
see also the usage for GRASS_BATCH_JOB, which basically does that in
a non-interactive environment.
Exactly - what would be needed, is that GRASS does not exit, but rather
stays in the background and can be used via the spgrass6 command
execGRASS().
Cheers,
Rainer
Hamish
--
Rainer M. Krug
email: RMKrugatgmaildotcom
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Direct link from GRASS to R via C
The following message is a courtesy copy of an article that has been posted to gmane.comp.gis.grass.devel as well. Hi I posted on my blog an outline of an idea of how spatial data could be easily loaded from GRASS into R and written back. (see http://rmkrug.wordpress.com/2013/07/15/grassrlink-1/) In a nutshell, the idea would be to use the C functions in GRASS to write a function which returns a single column, column range or whole raster. This function could then be called from R (via Rcpp) to get the data into R without having to worry about intermittent exports and imports via the hdd. I would ike to have some input from the GRASS developer community what they think about such a function. This function should be usable as stand alone, and not requiring the opening and buffer allocations et al as in the r.example, but rather simply take the mapset, raster name, column(s) to read, if MASK should be respected, ... arguments. I was thinking that it would be useful to have such a function in GRASS, as the compilation together with GRASS, in the same line as a module, would be quite easy. Initially, I was thinking about read and write support for rasters, which then could be extended to vectors and 3d-rasters and possibly even the temporal data. Could you give feedback on what y9ou think about the idea, and how you think it could be realized (simplicity to install would be important). Cheers and thanks, Rainer -- Rainer M. Krug email: RMKrugatgmaildotcom ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] start grass with only initializing the environment
The following message is a courtesy copy of an article that has been posted to gmane.comp.gis.grass.devel as well. Hi During the recent useR conference I had a discussion with Roger Bivand about the usage of GRASS from R on a Mac. I got it to work, but I manually had to adjust library paths as these depend on the way GRASS is installed (framework, homebrew, MacPorts, which version of GRASS). So to get GRASS 7 to work from within R, it was required to identify the paths of the libraries by going through the grass startup script. AS mentioned above, these paths are not easily portable and to include in the the spgrass6 startup mechanism. Therefore the idea occurred, if it would be possible to use the grass startup script to only set the environmental variables to be able to run the grass commands. As other applications do set these environmental variables as well (cluster, http://osgeo.org/wiki/GRASS_and_Shell , ...) this would be of wider use the simply when linking R and GRASS. I would therefore suggest an additional startup argument for grass, which only sets the environmental variables, including library paths, so that GRASS commands can be executed afterwards, and if the LOCATION_NAME and MAPSET are not provided, they will be null and *have to be set manualy afterwards*. This could e.g. have the name -noui indicating that no ui will be started. I think this would be a useful addition and make GRASS easier to use from other programs via scripting. Cheers, Rainer -- Rainer M. Krug email: RMKrugatgmaildotcom ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
