[GRASS-dev] [Anouncement] Ansible role for installing GRASS GIS with Python 2/3

[Panagiotis Mavrogiorgos]

# Anouncement

Hello everyone,

I am happy to announce the creation of an "Ansible role" that can be used to
compile GRASS GIS on Ubuntu 18.04, using either of Python 2 or Python 3.

## Concerns of getting started

IMHV, one of the factors that prevent people from getting involved with the
development, of a rather complex project, like GRASS GIS, is the difficulty to
get started.  The procedure usually involves:

- reading various wiki pages, sometimes even outdated ones
- identifying software dependencies
- often trial-and-error attempts to successfully compile GRASS GIS

Casual power-users with the potential to bring-in positive contributions,
might be overwhelmed by this.  Furthermore, this procedure has to be repeated
by each and everyone willing to get involved.

## Kickstarting a development environment

A user's level of expertise shouldn't matter in getting involved.  With this in
mind, the goal is to create a _single-command_, easy to use, automated tool.
This tool will kickstart a GRASS GIS development environment within minutes.

## About Ansible

Ansible is one of the tools used by devops for automating IT tasks.  These
tasks can be actions like:

- install this package
- create this user
- rename this file
- start this service
- run this command
- etc

Ansible covers pretty much anything you can do with a computer.  In layman
terms, an "ansible role" is nothing more than a list of tasks to be executed.

## Ansible role to compile GRASS GIS

With the execution of a single command, this role will:

- install dependencies required for compiling and running GRASS GIS
- checkout the source code
- create a virtualenv and install all python dependencies
- compile GRASS GIS

The only requirements are an Ubuntu 18.04 installation and internet connection.

## Your support

Would you have some spare time and a VM available, I would be happy if you give
it a try. Even more, if you let me know what you think about it.

I am by no means a GRASS GIS expert, and I certainly have tested only a small
part of GRASS GIS' functionality.  Thus, there will be things not working as
expected. Some dependency might be missing or the documentation might not be
clear enough.

The code is hosted on github and you can find instructions how to use the role
on the README file.  No ansible knowledge is required and if you can't follow
the instructions on the first time you read them, then this is a bug!

Let me know :)

## A note about security

Dislaimer: Downloading and executing an ansible role entails all the dangers of
executing a random script from the internet. So all the usual warnings are in
order. Best to try this on a throwaway VM

Thank you and looking forward to hear from you

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

Re: [GRASS-dev] [GRASS GIS] #3771: Run tests on Travis

[GRASS GIS]

#3771: Run tests on Travis
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Tests|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by pmav99):

 Well for starters, #3769 needs to be merged.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3771: Run tests on Travis

[GRASS GIS]

#3771: Run tests on Travis
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Tests|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 Patches would be gratefully accepted!

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3722: migrate grass svn repositories to git

[GRASS GIS]

#3722: migrate grass svn repositories to git
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  major|  Milestone:
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:  svn, git, migration
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by pmav99):

 AFAI can tell, all the test git repos are currently down. Is there a link
 to a working one?

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3771: Run tests on Travis

[GRASS GIS]

#3771: Run tests on Travis
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  Tests|Version:  svn-trunk
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 At the moment, Travis only builds GRASS without running any tests. The
 tests should be running on Travis for each commit and there should be
 notifications on the list whenever a commit breaks the tests.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3770: [testsuite] The testsuite requires Location: "other_location"

[GRASS GIS]

#3770: [testsuite] The testsuite requires Location: "other_location"
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  Tests|Version:  svn-trunk
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 The testsuite requires Location: "other_location" which does not exist and
 does not get downloaded by the bootstrapping code. The relevant lines on
 {{{testsuite/examples/test_framework_GRASS_GIS_with_NC.sh}}} are:

 {{{
 # run tests for the current source code
 cd $REPORTS/$CURRENT_REPORTS_DIR
 $PYTHON $GRASS_MULTI_RUNNER \
 --grassbin $GRASSBIN \
 --grasssrc $GRASSSRC \
 --grassdata $GRASSDATA \
 --location nc_spm_08_grass7 --location-type nc \
 --location other_location --location-type other_type
 }}}

 If this is a well known location, then the bootstrapping code should
 download it as well. If it is not, the it should probably be removed.

 Updating the instructions at {{{
 lib/python/docs/src/gunittest_running_tests.rst }}} would be nice too.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3769: [testsuite] Do not hardcode the path of the GRASSSRC

[GRASS GIS]

#3769: [testsuite] Do not hardcode the path of the GRASSSRC
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  Tests|Version:  svn-trunk
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 The hardcoded path makes it difficult to run the testsuite without
 modifying the configuration file. By using a relative path, anyone can
 run the testuite without any modifications.

 Original PR: https://github.com/GRASS-GIS/grass-ci/pull/5

 {{{
 Index: testsuite/examples/test_framework_GRASS_GIS_with_NC.conf
 ===
 --- testsuite/examples/test_framework_GRASS_GIS_with_NC.conf(revision
 74152)
 +++ testsuite/examples/test_framework_GRASS_GIS_with_NC.conf(working
 copy)
 @@ -3,7 +3,7 @@
  # name of binary:
  GRASSBIN=grass77
  # source code directory as full path:
 -GRASSSRC="$HOME/software/grass77"
 +GRASSSRC="$(realpath ../../)"
  # temporary grassdata directory
  GRASSDATA="$HOME/grassdata/tests-grassdata"
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Switching addon manual pages to point to grass76 ?

[Markus Neteler]

On Wed, Feb 20, 2019 at 10:39 AM Markus Neteler  wrote:
> On Fri, Feb 15, 2019 at 10:18 PM Markus Neteler  wrote:
> > so far the addons still point to
> > https://grass.osgeo.org/grass74/manuals/addons/
> >
> > Besides an Apache server rule change I have to do server-side, what
> > else needs to be done?
>
> ping

ping again ...

I can easily switch it on the server but I am not sure if that would be
enough?

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

Re: [GRASS-dev] [GRASS GIS] #3768: g.remove and i.group

[GRASS GIS]

#3768: g.remove and i.group
-+-
  Reporter:  SteGobbi|  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  normal  |  Milestone:  7.8.0
 Component:  Raster  |Version:  unspecified
Resolution:  |   Keywords:  remove, general, group, file
   CPU:  |  managing
  Unspecified|   Platform:  All
-+-

Comment (by hcho):

 Hello,

 Could you please provide example commands to reproduce your issues in the
 NC sample dataset
 (https://grass.osgeo.org/sampledata/north_carolina/nc_spm_08_grass7.zip)?

 Thanks,\\
 Huidae

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3768: g.remove and i.group

[GRASS GIS]

#3768: g.remove and i.group
-+-
  Reporter:  SteGobbi|  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  normal  |  Milestone:  7.8.0
 Component:  Raster  |Version:  unspecified
Resolution:  |   Keywords:  remove, general, group, file
   CPU:  |  managing
  Unspecified|   Platform:  All
-+-
Changes (by SteGobbi):

 * keywords:   => remove, general, group, file managing


-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3768: g.remove and i.group

[GRASS GIS]

#3768: g.remove and i.group
-+-
 Reporter:  SteGobbi |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.8.0
Component:  Raster   |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  All  |
-+-
 Hello again.

 I have noticed that the g.remove command correctly removes all the raster
 files from the location folders, but it doesn't delete the name of the
 removed file from the ref list, if the map is in any group list.
 It could lead to errors in the execution of operation where the parameter
 "group" has to be set, for instance with 'i.ortho.photo' or 'i.maxlik' and
 so on.

 I was wondering if could be possible to add a line in the command g.remove
 to remove the name of the input map from the ref file of its group.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3767: A better i/o system for the r.li family

[GRASS GIS]

#3767: A better i/o system for the r.li family
-+-
 Reporter:  SteGobbi |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.8.0
Component:  Imagery  |Version:  unspecified
 Keywords:  Landscape analysis, r.li, patch  |CPU:  All
 Platform:  All  |
-+-
 Hello,
 in my research activity i'm currently working with the "suite" r.li.
 The output given by these commands is different if in the setup
 (g.gui.rlisetup) we chose the "moving window" or the "whole map" option.
 In the first case GRASS will write into the
 Users\user1\AppData\Roaming\GRASS7\rli subfolder a very simple parseable
 file containing the results of the landscape analysis. A first improvement
 would be to modify the daemon.h file of the r.li family and allow GRASS to
 write this file in the group folder of the raster image we are studying.
 Which raises another issue: should the daemon be allowed to create a group
 folder in the current location containing the ref to the analysed map and
 the output file of the r.li module (in case the user hasn't set up a group
 folder)?

 The second case is: whole map is set as count method.
 In this case a raster map is created which structure depends on the r.li
 module we are working on, but the file containing the numerical results is
 not generated. Another enhancement would be to generate anyway this file,
 since the landscape analysis is supposed to give as output a numerical
 index.

 I would propose these two improvements for these modules.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3487: vector digitizer unstable

[GRASS GIS]

#3487: vector digitizer unstable
+---
  Reporter:  cmbarton   |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  critical   |  Milestone:  7.6.1
 Component:  wxGUI  |Version:  7.2.2
Resolution: |   Keywords:  digitizer, ctypes
   CPU:  OSX/Intel  |   Platform:  MacOSX
+---

Comment (by cmbarton):

 Replying to [comment:17 neteler]:
 > Replying to [comment:15 cmbarton]:
 > > Unfortunately, I can't test this until we figure out why configure is
 looking for cpp and bombing when it doesn't find it now.
 >
 > I'd suggest to move this to the 7.8 milestone, with focus on Python-3.

 GRASS is compiling again. So I can test any fix.

  I disagree with kicking this can down the road even farther. Digitizing
 has been broken on the Mac since 7.2. And now we are at 7.7 in trunk. It
 is a serious problem if you can't digitize in a full-featured GIS. I am
 skeptical that it is something that Python 3 will magically solve.
 Previously, the thought was that moving from 32 bit wxPython 2.8.12 to 64
 bit wxPython 3 would fix it. We are now using wxPython 4.0.1 on the Mac
 and it still crashes.

 It has something to do with how interactive windows are being
 defined/created because the same problem affects the interactive
 supervised classification interface. But is does NOT affect other
 interactive window functions like measurement and selection. One clue to
 tracking the bug perhaps is the following. In the digitizer, it does not
 crash as soon as the digitizing functions are invoked, but only when a new
 vector layer to be digitized is defined and "OK" is pressed. For the
 supervised classification, it crashes as soon as the interface is called.

-- 
Ticket URL: 
GRASS GIS 

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