[GRASS-dev] Update online addons manuals

[Panagiotis Mavrogiorgos]

Hi all,

The urls for the addons manuals indicate that they have not been updated
since 7.4. If possible and if there have been doc updates, it would be nice
if the newer versions were uploaded too.

with kind regards,
Panos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Fwd: New Coverity Scan report for GRASS GIS

[Markus Neteler]

Hi,

I finally got the Coverity Scan compilation running again. It offers
static compilation to catch code errors like dead code, unreachable
conditions and more.

After some time of struggling with the compilation I understood that
_Float128 was undefined. The trick: "cov-build" is still based on gcc6
while my system is more recent.
Hence, _Float128 has to be defined in an extra include file and given
to "cov-build" via CFLAGS:

CFLAGS="... -include /tmp/coverity.h ..."

For the latest Coverity Scan report, see below.

Cheers,
Markus


-- Forwarded  message -
From: 
Date: Mon, Apr 1, 2019 at 3:53 PM
Subject: New Defects reported by Coverity Scan for grass
To: 


Hi,

Please find the latest report on new defect(s) introduced to grass
found with Coverity Scan.

1 new defect(s) introduced to grass found with Coverity Scan.
1584 defect(s), reported by Coverity Scan earlier, were marked fixed
in the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)


** CID 1400466:(UNINIT)
/misc/m.nviz.image/surface.c: 127 in load_rasters()
/misc/m.nviz.image/surface.c: 143 in load_rasters()
/misc/m.nviz.image/surface.c: 150 in load_rasters()
/misc/m.nviz.image/surface.c: 164 in load_rasters()
/misc/m.nviz.image/surface.c: 178 in load_rasters()



*** CID 1400466:(UNINIT)
/misc/m.nviz.image/surface.c: 127 in load_rasters()
121   color_const->answers[i -
122
ncolor_map]),
123   data);
124 }
125 else {  /* use by default elevation
map for coloring */
126 if (nelev_map > 0) {
>>> CID 1400466:(UNINIT)
>>> Using uninitialized value "mapset" when calling 
>>> "G_fully_qualified_name".
127 Nviz_set_attr(id, MAP_OBJ_SURF, ATT_COLOR, MAP_ATT,
128   G_fully_qualified_name(params->elev_map->
129
answers[i], mapset),
130   -1.0, data);
131 G_verbose_message(_("Color attribute not
defined, using default <%s>"),
132   G_fully_qualified_name(params->
/misc/m.nviz.image/surface.c: 143 in load_rasters()
137 G_fatal_error(_("Missing color attribute for
surface %d"),
138   i + 1);
139 }
140 }
141 /* mask */
142 if (i < nmask_map && strcmp(params->mask_map->answers[i], "")) {
>>> CID 1400466:(UNINIT)
>>> Using uninitialized value "mapset" when calling 
>>> "G_fully_qualified_name".
143 Nviz_set_attr(id, MAP_OBJ_SURF, ATT_MASK, MAP_ATT,
144
G_fully_qualified_name(params->mask_map->answers[i],
145  mapset), -1.0, data);
146 }
147
148 /* transparency */
/misc/m.nviz.image/surface.c: 150 in load_rasters()
144
G_fully_qualified_name(params->mask_map->answers[i],
145  mapset), -1.0, data);
146 }
147
148 /* transparency */
149 if (i < ntransp_map &&
strcmp(params->transp_map->answers[i], "")) {
>>> CID 1400466:(UNINIT)
>>> Using uninitialized value "mapset" when calling 
>>> "G_fully_qualified_name".
150 Nviz_set_attr(id, MAP_OBJ_SURF, ATT_TRANSP, MAP_ATT,
151   G_fully_qualified_name(params->
152  transp_map->answers[i],
153  mapset), -1.0, data);
154 }
155 else if (i - ntransp_map < ntransp_const &&
/misc/m.nviz.image/surface.c: 164 in load_rasters()
158   atof(params->transp_const->
159answers[i - ntransp_map]), data);
160 }
161
162 /* shininess */
163 if (i < nshine_map &&
strcmp(params->shine_map->answers[i], "")) {
>>> CID 1400466:(UNINIT)
>>> Using uninitialized value "mapset" when calling 
>>> "G_fully_qualified_name".
164 Nviz_set_attr(id, MAP_OBJ_SURF, ATT_SHINE, MAP_ATT,
165   G_fully_qualified_name(params->
166  shine_map->answers[i],
167  mapset), -1.0, data);
168 }
169 else if (i - nshine_map < nshine_const &&
/misc/m.nviz.image/surface.c: 178 in load_rasters()
172   atof(params->shine_const->answers[i
- nshine_map]),
173   data);
174 }
175
176 /* emission */
177 if (i < nemit_map && strcmp(params->emit_map->answers[i], "")) {
>>> 

Re: [GRASS-dev] [GRASS GIS] #3721: d.title with d.text does not insert title

[GRASS GIS]

#3721: d.title with d.text does not insert title
--+---
  Reporter:  micha|  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.2
 Component:  Display  |Version:  7.4.0
Resolution:   |   Keywords:  title map display
   CPU:  Unspecified  |   Platform:  Linux
--+---
Changes (by micha):

 * milestone:  7.4.5 => 7.6.2


Comment:

 Checked on 7.6, the prob persists.

-- 
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-user] help with git migration

[Veronica Andreo]

Hi,

El lun., 1 abr. 2019 06:59, Martin Landa  escribió:

> Hi,
>
> po 1. 4. 2019 v 11:45 odesílatel Moritz Lennert
>  napsal:
> > I would suggest to alreay eliminate all enhancement requests that are
> > older than a certain age (1 year) ?
> >
> > I think that if these requests still correspond to user wishes, they
> > will reappear.
>
> make sense to me.
>

I went through all the tickets opened by me last week as it was requested.
I didn't change the feature request ones because that didn't change, i.e.,
they are still valid.

So, you say I should put 'I still want this, guys' to avoid the tickets
being closed just because they are older than 1 year?

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

Re: [GRASS-dev] [GRASS GIS] #3372: Export map display as vector file from GUI

[GRASS GIS]

#3372: Export map display as vector file from GUI
--+-
  Reporter:  baharmon |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.2.4
 Component:  Default  |Version:  svn-trunk
Resolution:  duplicate|   Keywords:  d.out.file, cairo, svg, gui
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by mlennert):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 I actually consider this a duplicate of #3033, so closing.

-- 
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-user] help with git migration

[Martin Landa]

Hi,

po 1. 4. 2019 v 11:45 odesílatel Moritz Lennert
 napsal:
> I would suggest to alreay eliminate all enhancement requests that are
> older than a certain age (1 year) ?
>
> I think that if these requests still correspond to user wishes, they
> will reappear.

make sense to me.

> I checked the actual bug tickets I reported and all of them still seem
> to be valid.

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

Re: [GRASS-dev] [GRASS-user] help with git migration

[Moritz Lennert]

On 1/04/19 11:24, Martin Landa wrote:

Hi,

út 26. 3. 2019 v 20:45 odesílatel Martin Landa  napsal:

Now I would like to ask to help with reducing number of open issues
with target 7.0+, see
https://trac.osgeo.org/grass/ticket/3789#comment:2.

Please go through [1] and close issues which are already fixed or will
be not fixed from given reason. The goal is to decrease number of
issues which will be migrated to target git-based platform, see [2].
[1] 
https://trac.osgeo.org/grass/query?status=assigned=new=reopened=8.0.0=7.8.0=7.6.1=7.4.5=7.2.4=7.0.7=id=summary=status=owner=type=priority=milestone=priority


first of all, thanks to all how did a review of open tickets
(especially of those which you have been reported [1] !). And also a
kind reminder for those who could do a review in order to close at
least part of open issues [1].


I would suggest to alreay eliminate all enhancement requests that are 
older than a certain age (1 year) ?


I think that if these requests still correspond to user wishes, they 
will reappear.


I checked the actual bug tickets I reported and all of them still seem 
to be valid.


Moritz



Thanks for help. Ma

[1] 
https://trac.osgeo.org/grass/query?status=assigned=new=reopened=7.8.0=7.6.2=8.0.0=7.0.7=7.2.4=7.4.5=reporter=3=id=summary=status=type=priority=milestone=component=priority



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

Re: [GRASS-dev] [GRASS-user] help with git migration

[Stefan Blumentrath]

Hi,

DBMI seems to be missing...
I guess that could be useful as well...

Cheers
Stefan

-Original Message-
From: grass-user  On Behalf Of Martin Landa
Sent: mandag 1. april 2019 11:24
To: GRASS users list ; GRASS developers list 

Subject: Re: [GRASS-user] help with git migration

Hi,

út 26. 3. 2019 v 20:45 odesílatel Martin Landa  napsal:
> Now I would like to ask to help with reducing number of open issues 
> with target 7.0+, see 
> https://trac.osgeo.org/grass/ticket/3789#comment:2.
>
> Please go through [1] and close issues which are already fixed or will 
> be not fixed from given reason. The goal is to decrease number of 
> issues which will be migrated to target git-based platform, see [2].
> [1] 
> https://trac.osgeo.org/grass/query?status=assigned=new=r
> eopened=8.0.0=7.8.0=7.6.1=7.4.
> 5=7.2.4=7.0.7=id=summary=status=ow
> ner=type=priority=milestone=priority

first of all, thanks to all how did a review of open tickets (especially of 
those which you have been reported [1] !). And also a kind reminder for those 
who could do a review in order to close at least part of open issues [1].

Thanks for help. Ma

[1] 
https://trac.osgeo.org/grass/query?status=assigned=new=reopened=7.8.0=7.6.2=8.0.0=7.0.7=7.2.4=7.4.5=reporter=3=id=summary=status=type=priority=milestone=component=priority

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

Re: [GRASS-dev] help with git migration

[Martin Landa]

Hi,

út 26. 3. 2019 v 20:45 odesílatel Martin Landa  napsal:
> Now I would like to ask to help with reducing number of open issues
> with target 7.0+, see
> https://trac.osgeo.org/grass/ticket/3789#comment:2.
>
> Please go through [1] and close issues which are already fixed or will
> be not fixed from given reason. The goal is to decrease number of
> issues which will be migrated to target git-based platform, see [2].
> [1] 
> https://trac.osgeo.org/grass/query?status=assigned=new=reopened=8.0.0=7.8.0=7.6.1=7.4.5=7.2.4=7.0.7=id=summary=status=owner=type=priority=milestone=priority

first of all, thanks to all how did a review of open tickets
(especially of those which you have been reported [1] !). And also a
kind reminder for those who could do a review in order to close at
least part of open issues [1].

Thanks for help. Ma

[1] 
https://trac.osgeo.org/grass/query?status=assigned=new=reopened=7.8.0=7.6.2=8.0.0=7.0.7=7.2.4=7.4.5=reporter=3=id=summary=status=type=priority=milestone=component=priority

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

[Moritz Lennert]

On 1/04/19 11:09, Martin Landa wrote:

Hi,

po 1. 4. 2019 v 10:10 odesílatel Moritz Lennert
 napsal:

How good is Python 3 support in trunk currently, especially for wxGui.
As would be expected, most errors I've seen in the past seem to be
linked either to wxGUI, or to lib/python.

Do you think it would be a good idea to create a 7.8 release branch
before having solved most of the Python 3 problems, or wouldn't it be
better to focus on that in trunk and create the realease branch only
once this has reached a reasonable state.


I would say that we are not expecting that 7.8.0 will be perfect and
all problems/bugs will be solved. If we plan a perfect release that we
will never release :-)


I obviously agree, but there is a difference between releasing a tech 
preview or a real release, i.e. something that we officially consider 
stable (but not perfect).



Moreover Python3 support will be widely tested
when there will be packages available to install. I would expect that
many problems will be discovered after release. Then we can come with
a more frequent point releases.


So, IIUC, the idea is to create an official release to get more testers 
? I'm a bit afraid that if we create an official release and many people 
hit upon errors that we will actually scare away potential users...


But all depends on the actual current usability for a normal user (i.e. 
someone relying on the GUI).


I'm sorry, I have been fairly absent from grass-dev in the last months, 
and the situation will not get much better in the near future, and so I 
don't want to block if others are for releasing quickly. Also, I'm not 
aware of the testing efforts that have already happened (except for 
Mundialis). Are the automatic tests run systematically in a Python 3 
environment ?


Moritz
___
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,

po 1. 4. 2019 v 10:10 odesílatel Moritz Lennert
 napsal:
> How good is Python 3 support in trunk currently, especially for wxGui.
> As would be expected, most errors I've seen in the past seem to be
> linked either to wxGUI, or to lib/python.
>
> Do you think it would be a good idea to create a 7.8 release branch
> before having solved most of the Python 3 problems, or wouldn't it be
> better to focus on that in trunk and create the realease branch only
> once this has reached a reasonable state.

I would say that we are not expecting that 7.8.0 will be perfect and
all problems/bugs will be solved. If we plan a perfect release that we
will never release :-) Moreover Python3 support will be widely tested
when there will be packages available to install. I would expect that
many problems will be discovered after release. Then we can come with
a more frequent point releases.

Just my two cents,

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

Re: [GRASS-dev] [GRASS GIS] #3772: Make the grass library importable outside of a GRASS session

[GRASS GIS]

#3772: Make the grass library importable outside of a GRASS session
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:8 pmav99]:
 > Added a patch that makes it possible to import the GRASS library even
 from a normal shell session.
 >
 > After applying the patch and compiling, the code can be tested with:
 > {{{
 > LD_LIBRARY_PATH=dist.x86_64-pc-linux-gnu/lib PYTHONPATH=dist.x86_64-pc-
 linux-gnu/etc/python python -c 'import grass.script' && echo 'OK!'
 > }}}


 >
 > The patch itself does 2 things:
 > 1. It does not resolve the path to {{{GISBASE}}} by using the ENV
 variable but by using the relative path from {{{dist.x86_64-pc-linux-
 gnu/etc/python/grass/__init__.py}}}

 I have to admit I don't really understand why all this code is necessary
 just to be able to do


 {{{
 LD_LIBRARY_PATH=/usr/lib/grass74/lib
 PYTHONPATH=/usr/lib/grass74/etc/python python -c 'import grass.script' &&
 echo 'OK!
 }}}

 instead of


 {{{
 GISBASE=/usr/lib/grass76 LD_LIBRARY_PATH=/usr/lib/grass76/lib
 PYTHONPATH=/usr/lib/grass76/etc/python python -c 'import grass.script' &&
 echo 'OK!
 }}}

 or even


 {{{
 GISBASE=/usr/lib/grass76 LD_LIBRARY_PATH=$GISBASE/lib
 PYTHONPATH=$GISBASE/etc/python python -c 'import grass.script' && echo
 'OK!'
 }}}

 Since you have to know the GISBASE path anyhow to be able to set
 LD_LIBRARY_PATH and PYTHONPATH ?

 Moritz

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

[Moritz Lennert]

On 1/04/19 10:04, Martin Landa wrote:

Hi,

ne 3. 3. 2019 v 19:33 odesílatel Martin Landa  napsal:

my +1 for creating 7.8 releasebranch. It's a first step which can be
done ASAP. Ma


based on original plan:

"""
* Proposal of release: 4 Feb 2019
* Soft freeze of release branch: 11 Feb 2019
* RC1: 11 Mar 2019
* RC2: 24 Mar 2019
* RC3: if needed
* Final release: 1 Apr 2019
"""

an updated plan below :-)

"""
* Proposal of release: 1 Apr 2019
* Soft freeze of release branch: 8 Apr 2019
* RC1: 6 May 2019
* RC2: 20 May 2019
* RC3: if needed
* Final release: 27 May 2019
"""

A new branch should be created between April 1 and 8. Make sense to you?


How good is Python 3 support in trunk currently, especially for wxGui. 
As would be expected, most errors I've seen in the past seem to be 
linked either to wxGUI, or to lib/python.


Do you think it would be a good idea to create a 7.8 release branch 
before having solved most of the Python 3 problems, or wouldn't it be 
better to focus on that in trunk and create the realease branch only 
once this has reached a reasonable state.


It's a big piece of work and would mean a lot of backporting if there is 
still a significant amount to do.


Moritz
___
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,

ne 3. 3. 2019 v 19:33 odesílatel Martin Landa  napsal:
> my +1 for creating 7.8 releasebranch. It's a first step which can be
> done ASAP. Ma

based on original plan:

"""
* Proposal of release: 4 Feb 2019
* Soft freeze of release branch: 11 Feb 2019
* RC1: 11 Mar 2019
* RC2: 24 Mar 2019
* RC3: if needed
* Final release: 1 Apr 2019
"""

an updated plan below :-)

"""
* Proposal of release: 1 Apr 2019
* Soft freeze of release branch: 8 Apr 2019
* RC1: 6 May 2019
* RC2: 20 May 2019
* RC3: if needed
* Final release: 27 May 2019
"""

A new branch should be created between April 1 and 8. Make sense to you?

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

[GRASS-dev] [GRASS GIS] Batch modify: #3375, #3401, #3454, #3512, #3516, #3547, ...

[GRASS GIS]

Batch modification to #3375, #3401, #3454, #3512, #3516, #3547, #3678, #3764, 
#412, #964, #1356, #2309, #2394, #2754, #3029, #3051, #3150, #3290, #3314, 
#290, #1434, #836, #1938, #2336, #3563, #3697, #2762 by martinl:
milestone to 7.6.2

Comment:
Ticket retargeted after milestone closed


-- 
Tickets URL: 

GRASS GIS 

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

[GRASS-dev] [GRASS GIS] Batch modify: #2459, #2464, #2465, #2487, #2499, #2526, ...

[GRASS GIS]

Batch modification to #2459, #2464, #2465, #2487, #2499, #2526, #2564, #2565, 
#2566, #2567, #2569, #2570, #2571, #2573, #2582, #2587, #2589, #2600, #2609, 
#2615, #2625, #2637, #2655, #2685, #2715, #2739, #2749, #2767, #2768, #2774, 
#2804, #2816, #2847, #2867, #2874, #2877, #2895, #2897, #2898, #2907, #2911, 
#2924, #2926, #2948, #2953, #2954, #2955, #2958, #2963, #2967, #2976, #2977, 
#2983, #2987, #2990, #3069, #3076, #3077, #3080, #3083, #3096, #3099, #3104, 
#3109, #3110, #3113, #3120, #3125, #3129, #3134, #3143, #3145, #3149, #3154, 
#3157, #3160, #3164, #3166, #3169, #3174, #3183, #3188, #3189, #3192, #3195, 
#3202, #3203, #3217, #3218, #3228, #3241, #3250, #3254, #3260, #3261, #3263, 
#3265, #3271, #3272, #3283 by martinl:
milestone to 7.6.2

Comment:
Ticket retargeted after milestone closed


-- 
Tickets URL: 

GRASS GIS 

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

[GRASS-dev] [GRASS GIS] Batch modify: #3286, #3292, #3293, #3309, #3310, #3313, ...

[GRASS GIS]

Batch modification to #3286, #3292, #3293, #3309, #3310, #3313, #3315, #3323, 
#3345, #3355, #3378, #3379, #3386, #3404, #3417, #3433, #3437, #3442, #3452, 
#3468, #3504, #3515, #3518, #3520, #3521, #3528, #3532, #3534, #3535, #3538, 
#3552, #3559, #3574, #3583, #3598, #3605, #3614, #3618, #3627, #3633, #3642, 
#3646, #3647, #3661, #3703, #3706, #3707, #3709, #3710, #3711, #3713, #3743, 
#3786, #3787, #3793, #3799, #3801, #32, #66, #193, #248, #320, #401, #446, 
#487, #517, #558, #578, #619, #645, #733, #794, #804, #977, #1002, #1031, 
#1075, #1144, #1350, #1669, #1906, #1908, #1979, #2049, #2106, #2142, #2233, 
#2620, #2675, #2982, #3005, #3050, #3082, #3111, #3177, #3180, #3299, #3312, 
#3364, #3366 by martinl:
milestone to 7.6.2

Comment:
Ticket retargeted after milestone closed


-- 
Tickets URL: 

GRASS GIS 

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

[GRASS-dev] [GRASS GIS] Batch modify: #1453, #1688, #2951, #3342, #899, #3487, ...

[GRASS GIS]

Batch modification to #1453, #1688, #2951, #3342, #899, #3487, #179, #410, 
#831, #1823, #2124, #2485, #2732, #2788, #3024, #3033, #3079, #3255, #3279, 
#3298, #3626, #250, #562, #603, #774, #790, #793, #857, #939, #1033, #1135, 
#1156, #1170, #1219, #1357, #1360, #1466, #1509, #1623, #1627, #1640, #1649, 
#1659, #1673, #1678, #1726, #1755, #1794, #1798, #1811, #1818, #1821, #1852, 
#1860, #1881, #1910, #1922, #1939, #1976, #1998, #2048, #2052, #2111, #2112, 
#2123, #2126, #2155, #2203, #2226, #2227, #2232, #2240, #2241, #2248, #2249, 
#2254, #2280, #2282, #2296, #2301, #2302, #2307, #2321, #2322, #2323, #2324, 
#2328, #2329, #2333, #2345, #2346, #2361, #2362, #2376, #2383, #2399, #2402, 
#2412, #2428, #2446 by martinl:
milestone to 7.6.2

Comment:
Ticket retargeted after milestone closed


-- 
Tickets URL: 

GRASS GIS 

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