Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Sebastiaan Couwenberg]

On 9/6/19 5:18 AM, Vaclav Petras wrote:
> On Thu, Sep 5, 2019 at 7:18 AM Martin Landa  wrote:
>> čt 5. 9. 2019 v 12:48 odesílatel Sebastiaan Couwenberg
>>  napsal:
 that's wrong, g.extension is using 'svn export' (for official repo).
>>>
>>> Using `svn export` for git repositories makes no sense/is a horrible
>> hack.
>>
>> I agree, so please suggest better solution to avoid that g.extension
>> will clone whole repository to install only single addon. Personally I
>> have no better idea than to use `svn export`.
>>
> 
> Please also note that the latest pre-Git/GitHub g.extension was primarily
> not using Subversion, but it was using a nice Trac feature which allowed to
> download a zipped subdirectory of the repo, so Subversion was not a
> must-have dependency. The idea was to get rid of build tool dependencies
> for Python modules as well resulting in no dev packages needed for Python
> modules on Linux while possibly getting arbitrary Python GRASS module code
> on Windows from Trac or, e.g., from GitHub which supports downloading of a
> (whole) repo (without submodules) as a zip file.

`git archive` can create zip or tar.gz files from a repo, with
individual addon repos this can replace the Trac feature.

If you want to get rid of the build tools on the users system, provide
the archive creation as a service on e.g. grass.osgeo.org.

Kind Regards,

Bas

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Sebastiaan Couwenberg]

On 9/6/19 5:06 AM, Vaclav Petras wrote:
> On Thu, Sep 5, 2019 at 7:50 AM Sebastiaan Couwenberg 
> wrote:
>>
>> On 9/5/19 12:54 PM, Markus Neteler wrote:
>>> Would shallow clone not clone the entire repo?  But we only want a
>>> subdirectory out of it.
>>
>> `git clone --filter` may be an option, or restructure the repo with git
>> usage in mind instead of subversion, e.g. using submodules for every
>> extension which can then be checked out individually.
> 
> Do you have experience with submodules and some suggested workflow for
> updating the code in the submodules? I'm using one submodule in one project
> and from my experience, it is extra work comparing to a single repo and it
> is quite confusing at times, but I may not be using an optimal workflow.
> 
> What advantages would there be in submodules comparing to addons in
> individual repos with some list of modules in a file in another repo, i.e.
> something like requirements.txt or PyPI rather than repo subdirectories
> which are submodules.

I don't use submodules myself, but they would just serve to group the
individual repositories into the grass-addons repo.

Working on individual addons should be done in the working copy of that
specific repo, not the grass-addons one.

The idea is mostly to preserve a single point to fetch all for those
that want it. For everybody else there are the individual addon repos.

Kind Regards,

Bas

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

Re: [GRASS-dev] [GRASS GIS] #3896: d.legend: error when displaying raster legend

[GRASS GIS]

#3896: d.legend: error when displaying raster legend
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Display  |Version:  git-releasebranch78
Resolution:   |   Keywords:  d.legend
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by annakrat):

 Should be fixed in master. Please test, needs backport.

-- 
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] #3897: d.mon errors when closing

[GRASS GIS]

#3897: d.mon errors when closing
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Display  |Version:  git-releasebranch78
Resolution:   |   Keywords:  d.mon
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by annakrat):

 Should be fixed in master. Please test, needs backport.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Vaclav Petras]

On Thu, Sep 5, 2019 at 7:18 AM Martin Landa  wrote:

> Hi,
>
> čt 5. 9. 2019 v 12:48 odesílatel Sebastiaan Couwenberg
>  napsal:
> > > that's wrong, g.extension is using 'svn export' (for official repo).
> >
> > Using `svn export` for git repositories makes no sense/is a horrible
> hack.
>
> I agree, so please suggest better solution to avoid that g.extension
> will clone whole repository to install only single addon. Personally I
> have no better idea than to use `svn export`.
>

Please also note that the latest pre-Git/GitHub g.extension was primarily
not using Subversion, but it was using a nice Trac feature which allowed to
download a zipped subdirectory of the repo, so Subversion was not a
must-have dependency. The idea was to get rid of build tool dependencies
for Python modules as well resulting in no dev packages needed for Python
modules on Linux while possibly getting arbitrary Python GRASS module code
on Windows from Trac or, e.g., from GitHub which supports downloading of a
(whole) repo (without submodules) as a zip file.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Vaclav Petras]

On Thu, Sep 5, 2019 at 7:50 AM Sebastiaan Couwenberg 
wrote:
>
> On 9/5/19 12:54 PM, Markus Neteler wrote:
> > Would shallow clone not clone the entire repo?  But we only want a
> > subdirectory out of it.
>
> `git clone --filter` may be an option, or restructure the repo with git
> usage in mind instead of subversion, e.g. using submodules for every
> extension which can then be checked out individually.

Do you have experience with submodules and some suggested workflow for
updating the code in the submodules? I'm using one submodule in one project
and from my experience, it is extra work comparing to a single repo and it
is quite confusing at times, but I may not be using an optimal workflow.

What advantages would there be in submodules comparing to addons in
individual repos with some list of modules in a file in another repo, i.e.
something like requirements.txt or PyPI rather than repo subdirectories
which are submodules.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3904: 7.9.dev: startup warning

[GRASS GIS]

#3904: 7.9.dev: startup warning
---+-
 Reporter:  rshepard   |  Owner:  grass-dev@…
 Type:  defect | Status:  new
 Priority:  normal |  Milestone:
Component:  wxGUI  |Version:  svn-trunk
 Keywords:  startup, gui, warning  |CPU:  x86-64
 Platform:  Linux  |
---+-
 Invoking 'grass97 --gui' shows this warning:

 /usr/local/grass79/gui/wxpython/wxgui.py:101: DeprecationWarning: Yield()
 is deprecated
   wx.Yield()
 09:01:58: Debug: Adding duplicate image handler for 'Windows bitmap file'
 09:01:58: Debug: Adding duplicate image handler for 'Windows bitmap file'

 Hope this helps,

 Rich

-- 
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] #3903: Closing of d.mon crashes

[GRASS GIS]

#3903: Closing of d.mon crashes
+-
 Reporter:  neteler |  Owner:  grass-dev@…
 Type:  defect  | Status:  new
 Priority:  normal  |  Milestone:  7.8.0
Component:  Python  |Version:  git-releasebranch78
 Keywords:  python3, d.mon  |CPU:  Unspecified
 Platform:  Unspecified |
+-
 In G78/master simple closing of d.mon leads to this error messages:

 {{{
 GRASS 7.8.dev (nc_spm_08):~ > d.mon wx0
 GRASS 7.8.dev (nc_spm_08):~ > wx._core.wxAssertionError: C++ assertion
 "GetEventHandler() == this" failed at ../src/common/wincmn.cpp(477) in
 ~wxWindowBase(): any pushed event handlers must have been removed

 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "/home/mneteler/software/grass78_git/dist.x86_64-pc-linux-
 gnu/gui/wxpython/mapdisp/main.py", line 565, in OnExit
 for f in six.itervalues(monFile):
   File "/usr/local/lib/python3.7/site-packages/six.py", line 584, in
 itervalues
 return iter(d.values(**kw))
 SystemError: 
 returned a result with an error set
 }}}

-- 
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] #3902: g.extension problem: multiple entries, slowing down GRASS startup

[GRASS GIS]

#3902: g.extension problem: multiple entries, slowing down GRASS startup
-+-
 Reporter:  neteler  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  critical |  Milestone:  7.8.0
Component:  Python   |Version:  unspecified
 Keywords:  g.extension  |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Apparently something went wrong in the latest updates to g.extension:

 {{{
 GRASS 7.8.dev (nc_spm_08):~ > g.extension -a | sort
 List of installed extensions (modules):
 i.pysptools.unmix
 i.pysptools.unmix
 i.pysptools.unmix
 i.pysptools.unmix
 i.pysptools.unmix
 i.pysptools.unmix
 i.pysptools.unmix
 i.pysptools.unmix
 i.pysptools.unmix
 i.pysptools.unmix
 i.sentinel
 i.sentinel.download
 i.sentinel.download
 i.sentinel.download
 i.sentinel.import
 i.sentinel.import
 i.sentinel.import
 i.sentinel.mask
 i.sentinel.mask
 i.sentinel.mask
 i.sentinel.preproc
 i.sentinel.preproc
 i.sentinel.preproc
 ...
 }}}

 Somehow, there is a undesired loop.

 Since the list of local extensions is scanned at startup time, it is now
 REALLY slow when you have a number of extensions installed.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] unsupported temporal database in grass79-dev

[Veronica Andreo]

Hi Martin,

El jue., 5 sept. 2019 a las 15:47, Martin Landa ()
escribió:

> Hi,
>
> čt 5. 9. 2019 v 15:43 odesílatel Veronica Andreo 
> napsal:
> > I do not understand what this really means in terms of what I have to
> do. I have many many time series, some with tens of thousands of maps (Gb's
> of data) and I find it really annoying to be forced to export all of them
> to then import again. Is this really what I need to do?? Isn't there a
> simpler way??
>
> currently there is probably no better way.


This is really bad news...

It would be nice to implement automated upgrade logic. Something like
>
> t.connect -u
>
> would do magic upgrade of current TGIS DB from version 2 to 3
>

This would be great indeed; I was actually hoping for something like this.
I gues I won't be using grass79dev until such thing exists... :-(

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

Re: [GRASS-dev] unsupported temporal database in grass79-dev

[Martin Landa]

Hi,

čt 5. 9. 2019 v 15:43 odesílatel Veronica Andreo  napsal:
> I do not understand what this really means in terms of what I have to do. I 
> have many many time series, some with tens of thousands of maps (Gb's of 
> data) and I find it really annoying to be forced to export all of them to 
> then import again. Is this really what I need to do?? Isn't there a simpler 
> way??

currently there is probably no better way. It would be nice to
implement automated upgrade logic. Something like

t.connect -u

would do magic upgrade of current TGIS DB from version 2 to 3

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

[GRASS-dev] unsupported temporal database in grass79-dev

[Veronica Andreo]

Hi devs,

Since the inclusion of "image collections" in grass79dev, the temporal
database is broken, and I get the following message every time I run a t.*
command:

ERROR: Unsupported temporal database: version mismatch.
The format of your actual temporal database is not supported any more.
Solution: You need to export it by restoring the GRASS GIS version used for
creating this DB. From there, create a backup of your temporal database to
avoid the loss of your temporal data.
Notes: Use t.rast.export and t.vect.export to make a backup of your
existing space time datasets.To safe the timestamps of your existing maps
and space time datasets, use t.rast.list, t.vect.list and t.rast3d.list.
You can register the existing time stamped maps easily if you export
columns=id,start_time,end_time into text files and use t.register to
register them again in new created space time datasets (t.create). After
the backup remove the existing temporal database, a new one will be created
automatically.
Supported temporal database version is: 2
Current temporal database info:
DBMI interface:. sqlite3
Temporal database:..
/home/veroandreo/grassdata/eu_laea/italy_lst/tgis/sqlite.db

I do not understand what this really means in terms of what I have to do. I
have many many time series, some with tens of thousands of maps (Gb's of
data) and I find it really annoying to be forced to export all of them to
then import again. Is this really what I need to do?? Isn't there a simpler
way??

Can someone provide a more detailed explanation of steps to follow, please?

Thanks much in advance
Vero
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3901: Addons missing in Makefile

[GRASS GIS]

#3901: Addons missing in Makefile
-+-
 Reporter:  sbl  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  Addons   |Version:  unspecified
 Keywords:  Makefile |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Several addons are missing in at least in https://github.com/OSGeo/grass-
 addons/blob/master/grass7/raster/Makefile

 If there is no specific reason for excluding them, missing addons should
 be added so manuals are generated.

 Maybe even better do point to all subdirectories in raster, vector, ... by
 default?
 E.g. like here: https://stackoverflow.com/questions/17834582/run-make-in-
 each-subdirectory

 Then addon devs do not have to remember this...

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Sebastiaan Couwenberg]

On 9/5/19 12:54 PM, Markus Neteler wrote:
> Would shallow clone not clone the entire repo?  But we only want a
> subdirectory out of it.

`git clone --filter` may be an option, or restructure the repo with git
usage in mind instead of subversion, e.g. using submodules for every
extension which can then be checked out individually.

Kind Regards,

Bas

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Martin Landa]

Hi,

čt 5. 9. 2019 v 12:48 odesílatel Sebastiaan Couwenberg
 napsal:
> > that's wrong, g.extension is using 'svn export' (for official repo).
>
> Using `svn export` for git repositories makes no sense/is a horrible hack.

I agree, so please suggest better solution to avoid that g.extension
will clone whole repository to install only single addon. Personally I
have no better idea than to use `svn export`.

Thanks, 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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Markus Neteler]

On Thu, Sep 5, 2019 at 12:48 PM Sebastiaan Couwenberg
 wrote:
> On 9/5/19 12:15 PM, Martin Landa wrote:
> > čt 5. 9. 2019 v 11:56 odesílatel Sebastiaan Couwenberg
> >  napsal:
> >> There is still an issue with g.extension using svn export in
> >> download_source_code_official_github():
> >>
> >>  
> >> https://github.com/OSGeo/grass/blob/releasebranch_7_8/scripts/g.extension/g.extension.py#L1094
> >>
> >> REQUIREMENTS.html also only documents git as a dependency for g.extension:
> >
> > that's wrong, g.extension is using 'svn export' (for official repo).
>
> Using `svn export` for git repositories makes no sense/is a horrible hack.
>
> >>  
> >> https://github.com/OSGeo/grass/blob/releasebranch_7_8/REQUIREMENTS.html#L210
> >>
> >> But g.extension also uses svn in download_source_code_svn():
> >>
> >>  
> >> https://github.com/OSGeo/grass/blob/releasebranch_7_8/scripts/g.extension/g.extension.py#L1066
> >
> > download_source_code_svn() is used only when source is 'svn' [1].
> > Let's imagine that user/company has own repository with addons
> > maintained by svn.
>
> Hence the need for REQUIREMENTS.html to list both git & subversion for
> g.extension.

Yes, to be changed.

> > Note that for 'official' source (which is now
> > https://github.com/osgeo/grass-addons) [2] is used
> > download_source_code_official_github() which is based on 'svn export'
> > instead of 'git' [3]. With git the whole repository would need to be
> > cloned with full history and all addons modules. That's something we
> > would like to avoid. With github 'svn export' trick do the job. Only
> > single addons (directory) [which is requested by the user to be
> > installed] can be fetched. I hope that we will find better solution in
> > the future.
>
> As mentioned in the thread on the pkg-grass-devel lists [0], use shallow
> clone.
>
> [0]
> https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2019-August/079643.html

this is unclear to me:

Would shallow clone not clone the entire repo?  But we only want a
subdirectory out of it.

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Sebastiaan Couwenberg]

On 9/5/19 12:15 PM, Martin Landa wrote:
> čt 5. 9. 2019 v 11:56 odesílatel Sebastiaan Couwenberg
>  napsal:
>> There is still an issue with g.extension using svn export in
>> download_source_code_official_github():
>>
>>  
>> https://github.com/OSGeo/grass/blob/releasebranch_7_8/scripts/g.extension/g.extension.py#L1094
>>
>> REQUIREMENTS.html also only documents git as a dependency for g.extension:
> 
> that's wrong, g.extension is using 'svn export' (for official repo).

Using `svn export` for git repositories makes no sense/is a horrible hack.

>>  https://github.com/OSGeo/grass/blob/releasebranch_7_8/REQUIREMENTS.html#L210
>>
>> But g.extension also uses svn in download_source_code_svn():
>>
>>  
>> https://github.com/OSGeo/grass/blob/releasebranch_7_8/scripts/g.extension/g.extension.py#L1066
> 
> download_source_code_svn() is used only when source is 'svn' [1].
> Let's imagine that user/company has own repository with addons
> maintained by svn.

Hence the need for REQUIREMENTS.html to list both git & subversion for
g.extension.

> Note that for 'official' source (which is now
> https://github.com/osgeo/grass-addons) [2] is used
> download_source_code_official_github() which is based on 'svn export'
> instead of 'git' [3]. With git the whole repository would need to be
> cloned with full history and all addons modules. That's something we
> would like to avoid. With github 'svn export' trick do the job. Only
> single addons (directory) [which is requested by the user to be
> installed] can be fetched. I hope that we will find better solution in
> the future.

As mentioned in the thread on the pkg-grass-devel lists [0], use shallow
clone.

[0]
https://alioth-lists.debian.net/pipermail/pkg-grass-devel/2019-August/079643.html

Kind Regards,

Bas

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Martin Landa]

Hi,

čt 5. 9. 2019 v 11:56 odesílatel Sebastiaan Couwenberg
 napsal:
> There is still an issue with g.extension using svn export in
> download_source_code_official_github():
>
>  
> https://github.com/OSGeo/grass/blob/releasebranch_7_8/scripts/g.extension/g.extension.py#L1094
>
> REQUIREMENTS.html also only documents git as a dependency for g.extension:

that's wrong, g.extension is using 'svn export' (for official repo).

>  https://github.com/OSGeo/grass/blob/releasebranch_7_8/REQUIREMENTS.html#L210
>
> But g.extension also uses svn in download_source_code_svn():
>
>  
> https://github.com/OSGeo/grass/blob/releasebranch_7_8/scripts/g.extension/g.extension.py#L1066

download_source_code_svn() is used only when source is 'svn' [1].
Let's imagine that user/company has own repository with addons
maintained by svn.

Note that for 'official' source (which is now
https://github.com/osgeo/grass-addons) [2] is used
download_source_code_official_github() which is based on 'svn export'
instead of 'git' [3]. With git the whole repository would need to be
cloned with full history and all addons modules. That's something we
would like to avoid. With github 'svn export' trick do the job. Only
single addons (directory) [which is requested by the user to be
installed] can be fetched. I hope that we will find better solution in
the future.

Ma

[1] 
https://github.com/OSGeo/grass/blob/releasebranch_7_8/scripts/g.extension/g.extension.py#L1230
[2] 
https://github.com/OSGeo/grass/blob/releasebranch_7_8/scripts/g.extension/g.extension.py#L1228
[3] 
https://github.com/OSGeo/grass/blob/releasebranch_7_8/scripts/g.extension/g.extension.py#L1115

-- 
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] [release planning] GRASS GIS 7.8.0 with Python3 support

[Sebastiaan Couwenberg]

On 9/5/19 10:57 AM, Martin Landa wrote:
> út 3. 9. 2019 v 15:47 odesílatel Martin Landa  napsal:
>> btw, next qgis release is planned for 13.9. [1]. It would be cool to
>> release 7.8.0 before this date.
> 
> it's important whether we want RC2 or just go out with final
> release... I am expecting next point release 7.8.1 quite soon anyway.

There is still an issue with g.extension using svn export in
download_source_code_official_github():

 
https://github.com/OSGeo/grass/blob/releasebranch_7_8/scripts/g.extension/g.extension.py#L1094

REQUIREMENTS.html also only documents git as a dependency for g.extension:

 https://github.com/OSGeo/grass/blob/releasebranch_7_8/REQUIREMENTS.html#L210

But g.extension also uses svn in download_source_code_svn():

 
https://github.com/OSGeo/grass/blob/releasebranch_7_8/scripts/g.extension/g.extension.py#L1066

Kind Regards,

Bas

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Martin Landa]

Hi,

út 3. 9. 2019 v 15:47 odesílatel Martin Landa  napsal:
> btw, next qgis release is planned for 13.9. [1]. It would be cool to
> release 7.8.0 before this date.

it's important whether we want RC2 or just go out with final
release... I am expecting next point release 7.8.1 quite soon anyway.

Ma

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