Re: [GRASS-dev] grass-addons on github

[Markus Metz]

The main advantage of having all grass-addons in one repo is that they are
easy to manage (for core devs).

The main disadvantage of having all grass-addons in one repo is that a
contributor concerned about his single addon needs to get the whole repo,
wasting disk space.

There are probably two different scenarios regarding contributions to
grass-addons:
1. a new addon: needs IMHO a PR, also if the contributor has write access
to the addons repo
2. modifications to an existing addon (bug fix, updated manual, new
functionality, etc): if the contributor has properly validated the changes,
the modifications could be pushed directly to the repo, without a PR. But
since even people (more or less) familiar with git have different opinions
on how to use git the correct way (as many correct ways as people having an
opinion on it), it is probably safer to go through a PR.

my0.2cents,

Markus M

On Fri, May 24, 2019 at 4:25 PM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:
>
> Hi,
>
> Collecting addons in a central repo seems very valuable to me too, for
all the reasons Vacslav mentioned.
>
> 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?
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 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...
>
> Cheers
> Stefan
>
>
> From: Anna Petrášová
> Sent: Friday 24 May 15:57
> Subject: Re: [GRASS-dev] grass-addons on github
> To: Martin Landa
> Cc: Paulo van Breugel, GRASS developers email list
>
>
>
>
> On Fri, May 24, 2019 at 3:55 AM Martin Landa 
wrote:
>
> Hi,
>
> pá 24. 5. 2019 v 8:48 odesílatel Paulo van Breugel
>  napsal:
> > I have read about the procedure for contributors to the main grass
repository. Question is, how are we going to deal with add-ons?
> >
> > Are we working with a central repository (OSGeo/grass-addons) and
follow the same protocol as for OSGEO/grass. If so, who will be responsible
for approving pull requests? An alternative more like the old situation is
that authors will be able to directly commit to the addon repository.
>
> in my opinion requesting PRs for `grass-addons` is maybe overkill. It
>
>
>
> If we don't care about the history and any mess in the grass-addons
repository, then yes, we don't need pull requests.
> But a lot of people who might be contributing there might not be familiar
with the peculiarities of git (since even most core grass devs including me
aren't), so eventually we will end up with a lot of mess, which somebody
will need to clean up. PR is a standard way to work on GitHub, so let's use
it. The same approach as for the main grass repo could be used.
>
>
> must be somehow discussed anyway. If we suggest direct commits it's
> important to avoid not needed 'merge from master' commits [1]. The
> workflow must be clear (rebase always) to avoid such situations. It
>
>
> I don't quite get how to use rebase yet, but that's the issue, it seems
that if you use it incorrectly, it can be dangerous.
>
>
> was not defined yet. Even suggested workflow related to the main
> repository is not clearly defined [2]. This must be improved in a near
> future.
>
> > Or should add-on authors maintain their own repositories, and will
there be a way to provide links to the authors repositories in a central
place?
>
>
> We did this with couple more complicated addons, we do internal
development in our git and then push it to the main repo when we want. I
like the idea of having all addons in one repository, then you can provide
the Windows binaries for them, that is also an incentive for contributers
to put it there (you get windows binary, hosting of manuals, simple
installation). But I get people want the distributed approach too.
>
> Anna
>
>
> Would be nice if g.extension (wingrass builds) supports distributed
> personal repos. I can imagine that it could be driven by a metadata
> file stored in central `grass-addons` repo. But someone need to
> implement it (g.extension, manual pages builds and wingrass builds).
> Would be cool.
>
> > With a central repository for all add-ons I guess it will be easier to
maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/
and to create the windows binaries?
>
> Sure. But see my notes above.
>
> Ma
>
> [1] https://lists.osgeo.org/pipermail/grass-dev/2019-May/092663.html
> [2] https://trac.osgeo.org/grass/wiki/HowToGit
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>

Re: [GRASS-dev] [GRASS GIS] #3851: r.out.mpeg always fails because the output file name is empty

[GRASS GIS]

#3851: r.out.mpeg always fails because the output file name is empty
--+
  Reporter:  paoloz   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  mpeg animation
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by mmetz):

 Replying to [comment:1 neteler]:
 > Would you mind to submit your fix as a pull request here?
 > https://github.com/OSGeo/grass/pulls

 For the time being; i would regard a patch as a pull request. If people
 are more comfortable providing a patch, that's fine.

 I have applied the patch to master, relbr76, and relbr74:

 https://github.com/OSGeo/grass/commit/78e9da1af300035ab1dbe4135ab79d1068aadd58

 https://github.com/OSGeo/grass/commit/2340b9dc9612535a6f249557a6175c98128a7451

 https://github.com/OSGeo/grass/commit/3ab95ff7a1781317dcca969c13cfe4fc6cb024df

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] (no subject)

[Paulo van Breugel]

Hi devs

I just did a completely fresh install of grass 7.6.2. The whole compilation
is completed without issues. But when starting grass up, I am getting the
following message.

GRASS 7.6.2svn (nc_spm_08_grass7):~ > ERROR 1: libgrass_raster.7.5.svn.so:
cannot open shared object file: No such file or directory
ERROR 1: libgrass_raster.7.5.svn.so: cannot open shared object file: No
such file or directory

I started completely anew, removed everything before compiling (as far as I
know), including the .grass7 folder, so I wonder what else I could have
done wrong? Any idea how I can find out where the problem lies?

Cheers,

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

Re: [GRASS-dev] grass-addons on github

[Stefan Blumentrath]

Hi,

Collecting addons in a central repo seems very valuable to me too, for all the 
reasons Vacslav mentioned.

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? 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 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...

Cheers
Stefan


From: Anna Petrášová
Sent: Friday 24 May 15:57
Subject: Re: [GRASS-dev] grass-addons on github
To: Martin Landa
Cc: Paulo van Breugel, GRASS developers email list




On Fri, May 24, 2019 at 3:55 AM Martin Landa 
mailto:landa.mar...@gmail.com>> wrote:
Hi,

pá 24. 5. 2019 v 8:48 odesílatel Paulo van Breugel
mailto:p.vanbreu...@gmail.com>> napsal:
> I have read about the procedure for contributors to the main grass 
> repository. Question is, how are we going to deal with add-ons?
>
> Are we working with a central repository (OSGeo/grass-addons) and follow the 
> same protocol as for OSGEO/grass. If so, who will be responsible for 
> approving pull requests? An alternative more like the old situation is that 
> authors will be able to directly commit to the addon repository.

in my opinion requesting PRs for `grass-addons` is maybe overkill. It


If we don't care about the history and any mess in the grass-addons repository, 
then yes, we don't need pull requests.
But a lot of people who might be contributing there might not be familiar with 
the peculiarities of git (since even most core grass devs including me aren't), 
so eventually we will end up with a lot of mess, which somebody will need to 
clean up. PR is a standard way to work on GitHub, so let's use it. The same 
approach as for the main grass repo could be used.

must be somehow discussed anyway. If we suggest direct commits it's
important to avoid not needed 'merge from master' commits [1]. The
workflow must be clear (rebase always) to avoid such situations. It

I don't quite get how to use rebase yet, but that's the issue, it seems that if 
you use it incorrectly, it can be dangerous.

was not defined yet. Even suggested workflow related to the main
repository is not clearly defined [2]. This must be improved in a near
future.

> Or should add-on authors maintain their own repositories, and will there be a 
> way to provide links to the authors repositories in a central place?

We did this with couple more complicated addons, we do internal development in 
our git and then push it to the main repo when we want. I like the idea of 
having all addons in one repository, then you can provide the Windows binaries 
for them, that is also an incentive for contributers to put it there (you get 
windows binary, hosting of manuals, simple installation). But I get people want 
the distributed approach too.

Anna

Would be nice if g.extension (wingrass builds) supports distributed
personal repos. I can imagine that it could be driven by a metadata
file stored in central `grass-addons` repo. But someone need to
implement it (g.extension, manual pages builds and wingrass builds).
Would be cool.

> With a central repository for all add-ons I guess it will be easier to 
> maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/ and 
> to create the windows binaries?

Sure. But see my notes above.

Ma

[1] https://lists.osgeo.org/pipermail/grass-dev/2019-May/092663.html
[2] https://trac.osgeo.org/grass/wiki/HowToGit

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


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

Re: [GRASS-dev] grass-addons on github

[Paulo van Breugel]

On Fri, May 24, 2019 at 3:57 PM Anna Petrášová 
wrote:

>
>
> On Fri, May 24, 2019 at 3:55 AM Martin Landa 
> wrote:
>
>> Hi,
>>
>> pá 24. 5. 2019 v 8:48 odesílatel Paulo van Breugel
>>  napsal:
>> > I have read about the procedure for contributors to the main grass
>> repository. Question is, how are we going to deal with add-ons?
>> >
>> > Are we working with a central repository (OSGeo/grass-addons) and
>> follow the same protocol as for OSGEO/grass. If so, who will be responsible
>> for approving pull requests? An alternative more like the old situation is
>> that authors will be able to directly commit to the addon repository.
>>
>> in my opinion requesting PRs for `grass-addons` is maybe overkill. It
>>
>
>
> If we don't care about the history and any mess in the grass-addons
> repository, then yes, we don't need pull requests.
> But a lot of people who might be contributing there might not be familiar
> with the peculiarities of git (since even most core grass devs including me
> aren't), so eventually we will end up with a lot of mess, which somebody
> will need to clean up. PR is a standard way to work on GitHub, so let's use
> it. The same approach as for the main grass repo could be used.
>
>
>> must be somehow discussed anyway. If we suggest direct commits it's
>> important to avoid not needed 'merge from master' commits [1]. The
>> workflow must be clear (rebase always) to avoid such situations. It
>>
>
> I don't quite get how to use rebase yet, but that's the issue, it seems
> that if you use it incorrectly, it can be dangerous.
>
>
>> was not defined yet. Even suggested workflow related to the main
>> repository is not clearly defined [2]. This must be improved in a near
>> future.
>>
>> > Or should add-on authors maintain their own repositories, and will
>> there be a way to provide links to the authors repositories in a central
>> place?
>>
>
> We did this with couple more complicated addons, we do internal
> development in our git and then push it to the main repo when we want. I
> like the idea of having all addons in one repository, then you can provide
> the Windows binaries for them, that is also an incentive for contributers
> to put it there (you get windows binary, hosting of manuals, simple
> installation). But I get people want the distributed approach too.
>

I am personally in favor of a central repository, and I think you provided
some important arguments in favor. It will require (for me) some time to
get to know the peculiarities of git, especially as it seems it is easy to
do something wrong.


>
> Anna
>
>>
>> Would be nice if g.extension (wingrass builds) supports distributed
>> personal repos. I can imagine that it could be driven by a metadata
>> file stored in central `grass-addons` repo. But someone need to
>> implement it (g.extension, manual pages builds and wingrass builds).
>> Would be cool.
>>
>> > With a central repository for all add-ons I guess it will be easier to
>> maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/
>> and to create the windows binaries?
>>
>> Sure. But see my notes above.
>>
>> Ma
>>
>> [1] https://lists.osgeo.org/pipermail/grass-dev/2019-May/092663.html
>> [2] https://trac.osgeo.org/grass/wiki/HowToGit
>>
>> --
>> Martin Landa
>> http://geo.fsv.cvut.cz/gwiki/Landa
>> http://gismentors.cz/mentors/landa
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass-addons on github

[Anna Petrášová]

On Fri, May 24, 2019 at 3:55 AM Martin Landa  wrote:

> Hi,
>
> pá 24. 5. 2019 v 8:48 odesílatel Paulo van Breugel
>  napsal:
> > I have read about the procedure for contributors to the main grass
> repository. Question is, how are we going to deal with add-ons?
> >
> > Are we working with a central repository (OSGeo/grass-addons) and follow
> the same protocol as for OSGEO/grass. If so, who will be responsible for
> approving pull requests? An alternative more like the old situation is that
> authors will be able to directly commit to the addon repository.
>
> in my opinion requesting PRs for `grass-addons` is maybe overkill. It
>


If we don't care about the history and any mess in the grass-addons
repository, then yes, we don't need pull requests.
But a lot of people who might be contributing there might not be familiar
with the peculiarities of git (since even most core grass devs including me
aren't), so eventually we will end up with a lot of mess, which somebody
will need to clean up. PR is a standard way to work on GitHub, so let's use
it. The same approach as for the main grass repo could be used.


> must be somehow discussed anyway. If we suggest direct commits it's
> important to avoid not needed 'merge from master' commits [1]. The
> workflow must be clear (rebase always) to avoid such situations. It
>

I don't quite get how to use rebase yet, but that's the issue, it seems
that if you use it incorrectly, it can be dangerous.


> was not defined yet. Even suggested workflow related to the main
> repository is not clearly defined [2]. This must be improved in a near
> future.
>
> > Or should add-on authors maintain their own repositories, and will there
> be a way to provide links to the authors repositories in a central place?
>

We did this with couple more complicated addons, we do internal development
in our git and then push it to the main repo when we want. I like the idea
of having all addons in one repository, then you can provide the Windows
binaries for them, that is also an incentive for contributers to put it
there (you get windows binary, hosting of manuals, simple installation).
But I get people want the distributed approach too.

Anna

>
> Would be nice if g.extension (wingrass builds) supports distributed
> personal repos. I can imagine that it could be driven by a metadata
> file stored in central `grass-addons` repo. But someone need to
> implement it (g.extension, manual pages builds and wingrass builds).
> Would be cool.
>
> > With a central repository for all add-ons I guess it will be easier to
> maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/
> and to create the windows binaries?
>
> Sure. But see my notes above.
>
> Ma
>
> [1] https://lists.osgeo.org/pipermail/grass-dev/2019-May/092663.html
> [2] https://trac.osgeo.org/grass/wiki/HowToGit
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass-addons on github

[Vaclav Petras]

On Fri, May 24, 2019 at 2:48 AM Paulo van Breugel 
wrote:

>
> Are we working with a central repository (OSGeo/grass-addons) and follow
> the same protocol as for OSGEO/grass. If so, who will be responsible for
> approving pull requests? An alternative more like the old situation is that
> authors will be able to directly commit to the addon repository.
>
> Or should add-on authors maintain their own repositories, and will there
> be a way to provide links to the authors repositories in a central place?
>
> With a central repository for all add-ons I guess it will be easier to
> maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/
> and to create the windows binaries?
>


I think the first question to ask is if there are other reasons than
technical ones to have all* addons in one repo. Having it in one
(Subversion) repo meant that core devs can do general changes in all addons
at once if needed and that all people can contribute to any other addon
even when the original author doesn't make any changes anymore** to the
code. If the addons are individual repos, this would work only if
maintainers are given access to them, e.g. by transferring ownership to the
organization (which is what e.g. LANDIS-II seems to be doing [1]).


* Not all 3rd party modules are of course there, just those from authors
who choose to do that.
** Because of code was abandoned or the author simply does not have any
time.

[1] https://github.com/LANDIS-II-Foundation
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3852: PyGRASS GridModule silently ignores when module has no output defined

[GRASS GIS]

#3852: PyGRASS GridModule silently ignores when module has no output defined
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.2
 Component:  PyGRASS  |Version:  unspecified
Resolution:   |   Keywords:  GridModule
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by martinl):

 See https://github.com/OSGeo/grass/pull/21

-- 
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] #3852: PyGRASS GridModule silently ignores when module has no output defined

[GRASS GIS]

#3852: PyGRASS GridModule silently ignores when module has no output defined
-+-
 Reporter:  martinl  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.6.2
Component:  PyGRASS  |Version:  unspecified
 Keywords:  GridModule   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 For modules like G7:r.mapcalc PyGRASS !GridModule class fails to work. No
 output is patched since the module has no output option defined.

 {{{
 from grass.pygrass.modules import Module
 from grass.pygrass.modules.grid import GridModule
 from grass.pygrass.utils import findmaps
 from grass.pygrass.gis import Mapset

 Module('g.region', n=1000, s=0, e=1000, w=0, res=1)

 grd = GridModule('r.mapcalc',
  width=250, height=250, overlap=0,
  processes=4, split=False,
  expression='out = 1')
 grd.run()

 print (findmaps('raster', 'out', mapset=str(Mapset(
 }}}

 Prints

 {{{
  100%
  100%
  100%
  100%
  100%
  100%
  100%
  100%
  100%
  100%
  100%
  100%
  100%
  100%
  100%
  100%
 []
 }}}

 -> no raster map created. The !GridModule should fail at least when no
 output option is defined.

-- 
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-addons on github

[Martin Landa]

Hi,

pá 24. 5. 2019 v 9:54 odesílatel Martin Landa  napsal:
> in my opinion requesting PRs for `grass-addons` is maybe overkill. It
> must be somehow discussed anyway. If we suggest direct commits it's
> important to avoid not needed 'merge from master' commits [1]. The
> workflow must be clear (rebase always) to avoid such situations. It
> was not defined yet. Even suggested workflow related to the main
> repository is not clearly defined [2]. This must be improved in a near
> future.

draft added [1]. Ma

[1] https://trac.osgeo.org/grass/wiki/HowToGit#Workflowforgrass-addonsrepository

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] install addons/extensions on GRASS

[Martin Landa]

Hi,

pá 24. 5. 2019 v 8:07 odesílatel Paulo van Breugel
 napsal:
> I was afraid that would be the case. Is there any way to get the executables 
> and install them manually?

last successful build (from 18/5) seems to be still available [1].

Ma

[1] https://wingrass.fsv.cvut.cz/grass76/x86_64/addons/grass-7.6.1/

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass-addons on github

[Martin Landa]

Hi,

pá 24. 5. 2019 v 8:48 odesílatel Paulo van Breugel
 napsal:
> I have read about the procedure for contributors to the main grass 
> repository. Question is, how are we going to deal with add-ons?
>
> Are we working with a central repository (OSGeo/grass-addons) and follow the 
> same protocol as for OSGEO/grass. If so, who will be responsible for 
> approving pull requests? An alternative more like the old situation is that 
> authors will be able to directly commit to the addon repository.

in my opinion requesting PRs for `grass-addons` is maybe overkill. It
must be somehow discussed anyway. If we suggest direct commits it's
important to avoid not needed 'merge from master' commits [1]. The
workflow must be clear (rebase always) to avoid such situations. It
was not defined yet. Even suggested workflow related to the main
repository is not clearly defined [2]. This must be improved in a near
future.

> Or should add-on authors maintain their own repositories, and will there be a 
> way to provide links to the authors repositories in a central place?

Would be nice if g.extension (wingrass builds) supports distributed
personal repos. I can imagine that it could be driven by a metadata
file stored in central `grass-addons` repo. But someone need to
implement it (g.extension, manual pages builds and wingrass builds).
Would be cool.

> With a central repository for all add-ons I guess it will be easier to 
> maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/ and 
> to create the windows binaries?

Sure. But see my notes above.

Ma

[1] https://lists.osgeo.org/pipermail/grass-dev/2019-May/092663.html
[2] https://trac.osgeo.org/grass/wiki/HowToGit

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] grass-addons on github

[Paulo van Breugel]

Dear devs,

I have read about the procedure for contributors to the main grass
repository. Question is, how are we going to deal with add-ons?

Are we working with a central repository (OSGeo/grass-addons) and follow
the same protocol as for OSGEO/grass. If so, who will be responsible for
approving pull requests? An alternative more like the old situation is that
authors will be able to directly commit to the addon repository.

Or should add-on authors maintain their own repositories, and will there be
a way to provide links to the authors repositories in a central place?

With a central repository for all add-ons I guess it will be easier to
maintain an overview like https://grass.osgeo.org/grass76/manuals/addons/
and to create the windows binaries?

Best regards,

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

Re: [GRASS-dev] install addons/extensions on GRASS

[Paulo van Breugel]

Hi Martin,

I was afraid that would be the case. Is there any way to get the
executables and install them manually?

Gr. Paulo



On Fri, May 24, 2019 at 12:02 AM Martin Landa 
wrote:

> Hi,
>
> pá 24. 5. 2019 v 0:00 odesílatel Paulo van Breugel
>  napsal:
> > I am trying to install an extension in GRASS on Windows, but the
> g.extension function is not finding addons; it get's stuck at fetching the
> list it seems.
>
> wingrass builds (and addons) are down due to git migration. It will
> take some time to update the whole workflow. Sorry. Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev