[GRASS-dev] Passed: GRASS-GIS/grass-ci#1474 (master - df14c76)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #1474
Status: Passed

Duration: 15 minutes and 11 seconds
Commit: df14c76 (master)
Author: Václav Petráš
Message: more see also for lidar modules

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@69219 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/fb899ae6c542...df14c769b332

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/154334121

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications


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

[GRASS-dev] Errored: GRASS-GIS/grass-ci#1473 (master - fb899ae)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #1473
Status: Errored

Duration: 15 minutes and 20 seconds
Commit: fb899ae (master)
Author: Anna Petrášová
Message: wxGUI/datacatalog: fix needed for Windows

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@69218 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/7d9feb7bd92d...fb899ae6c542

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/154310157

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications


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

Re: [GRASS-dev] g.search.module: shell style output

[Blumentrath, Stefan]

Hi,

As a side note:
The shell script output of v.db.connect is not “parsable” like in g.region 
(n=...) either.
However, it is well formatted as a kind of table output...

Cheers
Stefan



From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Jachym 
Cepicky
Sent: 22. august 2016 22:43
To: Vaclav Petras 
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] g.search.module: shell style output

Vasku,

IIRC, "-g" flag was introduced first time in 2007 for g.region module and only 
reason for taking "g" letter was, that "s" for "shell script" was taken (or 
some similar reason). AFAIK there was never defined official GRASS rule for 
using -g flag for parsable output as well as how the output should look like - 
people simple started to adopt it (like usually in GRASS).

Putting rule to developer guidelines for parsable output as well as promoting 
the "-g" flag for all modules would certainly be an option

Jachym

po 22. 8. 2016 v 4:39 odesílatel Vaclav Petras 
> napsal:
On Fri, Aug 19, 2016 at 2:15 AM, Jachym Cepicky 
> wrote:
Hi,

no special reason for not listing the module description too, just did not came 
to my mind

Thanks. Good to know.


Just do it [1]

While using the modified version, I actually realized that "shell script style" 
usually produces key-value pairs which can which can be evaluated by shell's 
eval or grass.script.parse_command. Not all modules comply with this, e.g. 
`g.extension -g` produces multiple key-values with same keys and order matters, 
so this must be parsed in a special way. The result is actually exactly the 
information g.search.modules is producing:

$ g.extension -g
...
name=v.habitat.dem
description=Calculates DEM derived characteristics of habitats.
keywords=vector,raster,terrain,statistics,sun,zonal statistics
name=v.in.gbif
description=importing of GBIF species distribution data
keywords=vector,geometry
`g.extension -l` produces list of modules in the same way as currently 
`g.search.modules -g` produces:

$ g.extension -l

v.habitat.dem
v.in.gbif
As a result, I don't know what to do with -g, at this point I would just 
replace the letter by -n (names only) or -s (short output with names only) and 
add -t for table output (that's in the attached patch). -g can go to renamed 
options for compatibility reasons for now.
For the future, we should try to keep in mind that g.extension and 
g.search.module should have unified interfaces and/or outputs. And more 
generally, we should define what -g "shell script style" means.


J

[1] https://www.youtube.com/watch?v=ZXsQAXx_ao0

čt 18. 8. 2016 v 20:32 odesílatel Vaclav Petras 
> napsal:
Hi Jachym,
the g.search.module -g flag (shell style output) outputs just names. Do you 
have a particular reason for it? My use case is something like that:

g.search.modules keyword="support" -g | sed -e "s/|[^|]*$//g" | sed -e 
"s/|/\t/g"
with the following desired output (name + keywords, description removed by sed):

g.versiongeneral,support,citing,copyright,version,license
t.supporttemporal,metadata,time
r.supportraster,metadata
r.support.statsraster,statistics
r.out.gdalraster,export
v.out.ogrvector,export,OGR
r3.supportraster3d,metadata,voxel
g.findetcgeneral,map management,scripts
v.externalvector,import,external,OGR,PostGIS
g.messagegeneral,support,scripts
g.tempfilegeneral,support,scripts
v.supportvector,metadata
r.externalraster,import,external

I can actually see that outputting just module names can be advantageous in 
some cases. But I want to get something like, so I can throw sed and grep on it:

v.support|vector,metadata|Updates vector map metadata.
If we permit change of the interface, I think -g could do the output above. 
This would make the -g output more like the others: same information as by 
default and with -j, so we can even consider it fixing a bug.

The current output with -g can be generated with some other flag. -n* for 
"names only" perhaps?
Best,
Vaclav

* https://lists.osgeo.org/pipermail/grass-dev/2016-August/081556.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Passed: GRASS-GIS/grass-ci#1472 (master - 7d9feb7)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #1472
Status: Passed

Duration: 28 minutes and 45 seconds
Commit: 7d9feb7 (master)
Author: Martin Landa
Message: If GRASS_RANDOM_SEED is set, use it to seed the random generator when
G_srand48_auto is called. This helps makeing the build reproducible
(html/random.png)
Based on 04-srand48_auto-from-SOURCE_DATE_EPOCH.patch, see #3042


git-svn-id: https://svn.osgeo.org/grass/grass/trunk@69217 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/a939f1ccc59a...7d9feb7bd92d

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/154291565

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

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

Re: [GRASS-dev] [GRASS GIS] #3042: Patches to make the build reproducible (fileordering, randomness)

[GRASS GIS]

#3042: Patches to make the build reproducible (fileordering, randomness)
--+-
  Reporter:  sebastic |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.0.5
 Component:  Compiling|Version:  7.0.4
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by sebastic):

 No objection from me, I'm happy to drop these patches from the Debian
 package.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3042: Patches to make the build reproducible (fileordering, randomness)

[GRASS GIS]

#3042: Patches to make the build reproducible (fileordering, randomness)
--+-
  Reporter:  sebastic |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.0.5
 Component:  Compiling|Version:  7.0.4
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by martinl):

 Replying to [comment:9 sebastic]:
 > The variable should be renamed, because it now uses `GRASS_RANDOM_SEED`
 instead of `SOURCE_DATE_EPOCH`, i.e.
 `s/source_date_epoch/grass_random_seed/g`.

 right, modified version applied in trunk as r69217. If no objection I do
 backport to relbr72/70 in the next days.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Errored: GRASS-GIS/grass-ci#1471 (master - a939f1c)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #1471
Status: Errored

Duration: 23 minutes and 1 second
Commit: a939f1c (master)
Author: Martin Landa
Message: Patches to make the build reproducible (fileordering, randomness)
Patches applied: 01-sort-build-modules-list.patch, 02-sort-dbmscap.patch, 
03-sort-obj-files.patch (05-binary-nad-install.patch not needed any more)
To be solved: 04-srand48_auto-from-SOURCE_DATE_EPOCH.patch
(see #3042)


git-svn-id: https://svn.osgeo.org/grass/grass/trunk@69214 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/7cb2c7bb02ce...a939f1ccc59a

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/154284598

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

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

Re: [GRASS-dev] [GRASS GIS] #3042: Patches to make the build reproducible (fileordering, randomness)

[GRASS GIS]

#3042: Patches to make the build reproducible (fileordering, randomness)
--+-
  Reporter:  sebastic |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.0.5
 Component:  Compiling|Version:  7.0.4
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by martinl):

 In [changeset:"69217" 69217]:
 {{{
 #!CommitTicketReference repository="" revision="69217"
 If GRASS_RANDOM_SEED is set, use it to seed the random generator when
 G_srand48_auto is called. This helps makeing the build reproducible
 (html/random.png)
 Based on 04-srand48_auto-from-SOURCE_DATE_EPOCH.patch, see #3042
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3042: Patches to make the build reproducible (fileordering, randomness)

[GRASS GIS]

#3042: Patches to make the build reproducible (fileordering, randomness)
--+-
  Reporter:  sebastic |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.0.5
 Component:  Compiling|Version:  7.0.4
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by sebastic):

 Replying to [comment:8 martinl]:
 > Replying to [comment:3 glynn]:
 > > While I agree with the idea, G_srand48_auto() shouldn't be using this
 variable directly, but something more appropriate, e.g. GRASS_RANDOM_SEED
 (or GRASS_RND_SEED, which is what r.mapcalc used prior to the RNG
 changes).
 >
 > Updated patch attached - attachment:04-srand48_auto-from-
 GRASS_RANDOM_SEED.patch. Can be applied in this way?

 The variable should be renamed, because it now uses `GRASS_RANDOM_SEED`
 instead of `SOURCE_DATE_EPOCH`, i.e.
 `s/source_date_epoch/grass_random_seed/g`.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3042: Patches to make the build reproducible (fileordering, randomness)

[GRASS GIS]

#3042: Patches to make the build reproducible (fileordering, randomness)
--+-
  Reporter:  sebastic |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.0.5
 Component:  Compiling|Version:  7.0.4
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by martinl):

 Replying to [comment:3 glynn]:
 > While I agree with the idea, G_srand48_auto() shouldn't be using this
 variable directly, but something more appropriate, e.g. GRASS_RANDOM_SEED
 (or GRASS_RND_SEED, which is what r.mapcalc used prior to the RNG
 changes).

 Updated patch attached - attachment:04-srand48_auto-from-
 GRASS_RANDOM_SEED.patch. Can be applied in this way?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3042: Patches to make the build reproducible (fileordering, randomness)

[GRASS GIS]

#3042: Patches to make the build reproducible (fileordering, randomness)
--+-
  Reporter:  sebastic |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.0.5
 Component:  Compiling|Version:  7.0.4
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by martinl):

 * Attachment "04-srand48_auto-from-GRASS_RANDOM_SEED.patch" added.


--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3042: Patches to make the build reproducible (fileordering, randomness)

[GRASS GIS]

#3042: Patches to make the build reproducible (fileordering, randomness)
--+-
  Reporter:  sebastic |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.0.5
 Component:  Compiling|Version:  7.0.4
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by martinl):

 In [changeset:"69216" 69216]:
 {{{
 #!CommitTicketReference repository="" revision="69216"
 Patches to make the build reproducible (fileordering, randomness)
 Patches applied: 01-sort-build-modules-list.patch, 02-sort-dbmscap.patch,
 03-sort-obj-files.patch, 05-binary-nad-install.patch
 To be solved: 04-srand48_auto-from-SOURCE_DATE_EPOCH.patch
 (see #3042)
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3042: Patches to make the build reproducible (fileordering, randomness)

[GRASS GIS]

#3042: Patches to make the build reproducible (fileordering, randomness)
--+-
  Reporter:  sebastic |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.0.5
 Component:  Compiling|Version:  7.0.4
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by martinl):

 In [changeset:"69215" 69215]:
 {{{
 #!CommitTicketReference repository="" revision="69215"
 Patches to make the build reproducible (fileordering, randomness)
 Patches applied: 01-sort-build-modules-list.patch, 02-sort-dbmscap.patch,
 03-sort-obj-files.patch, 05-binary-nad-install.patch
 To be solved: 04-srand48_auto-from-SOURCE_DATE_EPOCH.patch
 (see #3042)
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3042: Patches to make the build reproducible (fileordering, randomness)

[GRASS GIS]

#3042: Patches to make the build reproducible (fileordering, randomness)
--+-
  Reporter:  sebastic |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.0.5
 Component:  Compiling|Version:  7.0.4
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by martinl):

 In [changeset:"69214" 69214]:
 {{{
 #!CommitTicketReference repository="" revision="69214"
 Patches to make the build reproducible (fileordering, randomness)
 Patches applied: 01-sort-build-modules-list.patch, 02-sort-dbmscap.patch,
 03-sort-obj-files.patch (05-binary-nad-install.patch not needed any more)
 To be solved: 04-srand48_auto-from-SOURCE_DATE_EPOCH.patch
 (see #3042)
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] 7.0.5 release planning

[Markus Neteler]

Hi,

we discussed here at the Code sprint Bonn
(https://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Bonn_2016) to
release RC1 next Saturday during the 2nd sprint part.

DRAFT news page to be updated:
https://trac.osgeo.org/grass/wiki/Release/7.0.5-News

Planning at
https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.0.5tobebackported

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

Re: [GRASS-dev] [GRASS GIS] #2456: read CSV from GDAL data directory

[GRASS GIS]

#2456: read CSV from GDAL data directory
-+-
  Reporter:  martinl |  Owner:  grass-dev@…
  Type:  task| Status:  new
  Priority:  blocker |  Milestone:  7.3.0
 Component:  Projections/Datums  |Version:  svn-releasebranch70
Resolution:  |   Keywords:  gdal, g.proj
   CPU:  Unspecified |   Platform:  Unspecified
-+-
Changes (by martinl):

 * milestone:  7.0.5 => 7.3.0


--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] g.search.module: shell style output

[Jachym Cepicky]

Vasku,

IIRC, "-g" flag was introduced first time in 2007 for g.region module and
only reason for taking "g" letter was, that "s" for "shell script" was
taken (or some similar reason). AFAIK there was never defined official
GRASS rule for using -g flag for parsable output as well as how the output
should look like - people simple started to adopt it (like usually in
GRASS).

Putting rule to developer guidelines for parsable output as well as
promoting the "-g" flag for all modules would certainly be an option

Jachym

po 22. 8. 2016 v 4:39 odesílatel Vaclav Petras 
napsal:

> On Fri, Aug 19, 2016 at 2:15 AM, Jachym Cepicky 
> wrote:
>
>> Hi,
>>
>> no special reason for not listing the module description too, just did
>> not came to my mind
>>
>
> Thanks. Good to know.
>
>
>>
>> Just do it [1]
>>
>
> While using the modified version, I actually realized that "shell script
> style" usually produces key-value pairs which can which can be evaluated by
> shell's eval or grass.script.parse_command. Not all modules comply with
> this, e.g. `g.extension -g` produces multiple key-values with same keys and
> order matters, so this must be parsed in a special way. The result is
> actually exactly the information g.search.modules is producing:
>
> $ g.extension -g
> ...
> name=v.habitat.dem
> description=Calculates DEM derived characteristics of habitats.
> keywords=vector,raster,terrain,statistics,sun,zonal statistics
> name=v.in.gbif
> description=importing of GBIF species distribution data
> keywords=vector,geometry
>
> `g.extension -l` produces list of modules in the same way as currently
> `g.search.modules -g` produces:
>
> $ g.extension -l
>
> v.habitat.dem
> v.in.gbif
>
> As a result, I don't know what to do with -g, at this point I would just
> replace the letter by -n (names only) or -s (short output with names only)
> and add -t for table output (that's in the attached patch). -g can go to
> renamed options for compatibility reasons for now.
>
> For the future, we should try to keep in mind that g.extension and
> g.search.module should have unified interfaces and/or outputs. And more
> generally, we should define what -g "shell script style" means.
>
>
>>
>> J
>>
>> [1] https://www.youtube.com/watch?v=ZXsQAXx_ao0
>>
>> čt 18. 8. 2016 v 20:32 odesílatel Vaclav Petras 
>> napsal:
>>
>>> Hi Jachym,
>>>
>>> the g.search.module -g flag (shell style output) outputs just names. Do
>>> you have a particular reason for it? My use case is something like that:
>>>
>>> g.search.modules keyword="support" -g | sed -e "s/|[^|]*$//g" | sed -e
>>> "s/|/\t/g"
>>>
>>> with the following desired output (name + keywords, description removed
>>> by sed):
>>>
>>> g.versiongeneral,support,citing,copyright,version,license
>>> t.supporttemporal,metadata,time
>>> r.supportraster,metadata
>>> r.support.statsraster,statistics
>>> r.out.gdalraster,export
>>> v.out.ogrvector,export,OGR
>>> r3.supportraster3d,metadata,voxel
>>> g.findetcgeneral,map management,scripts
>>> v.externalvector,import,external,OGR,PostGIS
>>> g.messagegeneral,support,scripts
>>> g.tempfilegeneral,support,scripts
>>> v.supportvector,metadata
>>> r.externalraster,import,external
>>>
>>> I can actually see that outputting just module names can be advantageous
>>> in some cases. But I want to get something like, so I can throw sed and
>>> grep on it:
>>>
>>> v.support|vector,metadata|Updates vector map metadata.
>>>
>>> If we permit change of the interface, I think -g could do the output
>>> above. This would make the -g output more like the others: same information
>>> as by default and with -j, so we can even consider it fixing a bug.
>>>
>>> The current output with -g can be generated with some other flag. -n*
>>> for "names only" perhaps?
>>>
>>> Best,
>>> Vaclav
>>>
>>> * https://lists.osgeo.org/pipermail/grass-dev/2016-August/081556.html
>>>
>>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3064: r.external gui does not display layer in list of layers when selected via browse button

[GRASS GIS]

#3064: r.external gui does not display layer in list of layers when selected via
browse button
--+--
  Reporter:  dnewcomb |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Default  |Version:  svn-releasebranch72
Resolution:   |   Keywords:  Windows 7 r.external
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+--

Comment (by dnewcomb):

 Just bumping for windows.  r.external works fine with respect to this
 issue on Linux as of Saturday, but this is still an issue on windows.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1699: language setting in wxGUI preferences does not work; could cause GUI crash

[GRASS GIS]

#1699: language setting in wxGUI preferences does not work; could cause GUI 
crash
--+--
  Reporter:  cmbarton |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  major|  Milestone:  6.4.6
 Component:  wxGUI|Version:  svn-releasebranch64
Resolution:  fixed|   Keywords:  internationalization
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by milenan):

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


Comment:

 Works in GRASS6.4.4 and 7.2svn (windows10)

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2558: wxgui: profile surface map, bivariate scatter plot, histogram of raster map broken with wxPython 3.0.2 but work fine fine with 2.8

[GRASS GIS]

#2558: wxgui: profile surface map, bivariate scatter plot, histogram of raster 
map
broken with wxPython 3.0.2 but work fine fine with 2.8
---+-
  Reporter:  humu2015  |  Owner:  grass-dev@…
  Type:  defect| Status:  closed
  Priority:  major |  Milestone:  6.4.6
 Component:  wxGUI |Version:  6.4.5
Resolution:  fixed |   Keywords:  wxgui
   CPU:  All   |   Platform:  All
---+-

Comment (by mlennert):

 Replying to [comment:20 annakrat]:
 > Replying to [comment:19 mlennert]:
 > >
 > > AFAIK, only profile is concerned by this in grass64.
 > >
 > > Applying the relevant patches to
 > > gui/wxpython/wxplot/base.py
 > > and
 > > gui/wxpython/wxplot/profile.py
 > >
 > > makes it work for me.
 > >
 > > Anna, AFAICT this should be safe, but what do you think ?
 >
 > I think so. Please go ahead and commit it.

 Done.

 Maciej, could you test ?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2558: wxgui: profile surface map, bivariate scatter plot, histogram of raster map broken with wxPython 3.0.2 but work fine fine with 2.8

[GRASS GIS]

#2558: wxgui: profile surface map, bivariate scatter plot, histogram of raster 
map
broken with wxPython 3.0.2 but work fine fine with 2.8
---+-
  Reporter:  humu2015  |  Owner:  grass-dev@…
  Type:  defect| Status:  closed
  Priority:  major |  Milestone:  6.4.6
 Component:  wxGUI |Version:  6.4.5
Resolution:  fixed |   Keywords:  wxgui
   CPU:  All   |   Platform:  All
---+-
Changes (by mlennert):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"69213" 69213]:
 {{{
 #!CommitTicketReference repository="" revision="69213"
 wxGUI: fix #2558 (backport from grass7)
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1683: error message v.db.addcol

[GRASS GIS]

#1683: error message v.db.addcol
+--
  Reporter:  jradinger  |  Owner:  hamish
  Type:  defect | Status:  closed
  Priority:  major  |  Milestone:  6.4.6
 Component:  Shell Scripts  |Version:  svn-develbranch6
Resolution:  fixed  |   Keywords:  v.db.addcol
   CPU:  Unspecified|   Platform:  All
+--
Changes (by mlennert):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:18 neteler]:
 > Replying to [comment:16 hamish]:
 > > scripts in devbr6 now updated with r55194:55226, but need testing
 > > before backport to the stable branch.
 >
 > For the record: Apparently are all r55194:55226 changes present in
 relbr6,
 > so they will go into GRASS 6.4.4, nice.
 >
 > Replying to [comment:17 hamish]:
 > > non-harmless cases listed in comment:16 backported to relbr64 in
 r55725.
 > > testing still welcomed.
 >
 > No issues reported so far.

 Still none reported, so closing.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2717: Add sensor Landsat8 to grass 6.4.4

[GRASS GIS]

#2717: Add sensor Landsat8 to grass 6.4.4
--+-
  Reporter:  pkameswari   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  minor|  Milestone:  6.4.7
 Component:  Imagery  |Version:  svn-releasebranch64
Resolution:  fixed|   Keywords:  i.atcorr
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by mlennert):

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


Comment:

 The patch was applied in r66615 10 months ago.

 Please note that there will be no more improvements of such modules in
 grass6. Please use grass7.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2558: wxgui: profile surface map, bivariate scatter plot, histogram of raster map broken with wxPython 3.0.2 but work fine fine with 2.8

[GRASS GIS]

#2558: wxgui: profile surface map, bivariate scatter plot, histogram of raster 
map
broken with wxPython 3.0.2 but work fine fine with 2.8
---+-
  Reporter:  humu2015  |  Owner:  grass-dev@…
  Type:  defect| Status:  reopened
  Priority:  major |  Milestone:  6.4.6
 Component:  wxGUI |Version:  6.4.5
Resolution:|   Keywords:  wxgui
   CPU:  All   |   Platform:  All
---+-

Comment (by annakrat):

 Replying to [comment:19 mlennert]:
 >
 > AFAIK, only profile is concerned by this in grass64.
 >
 > Applying the relevant patches to
 > gui/wxpython/wxplot/base.py
 > and
 > gui/wxpython/wxplot/profile.py
 >
 > makes it work for me.
 >
 > Anna, AFAICT this should be safe, but what do you think ?

 I think so. Please go ahead and commit it.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2066: wxGUI rendering fails with cairo driver

[GRASS GIS]

#2066: wxGUI rendering fails with cairo driver
--+--
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  major|  Milestone:  6.5.0
 Component:  wxGUI|Version:  svn-develbranch6
Resolution:  wontfix  |   Keywords:  cairo
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by mlennert):

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


Comment:

 Closing as wontfix as cairo driver is not available as a choice anymore
 and the issue is fixed in grass 7.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Errored: GRASS-GIS/grass-ci#1470 (master - 7cb2c7b)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #1470
Status: Errored

Duration: 23 minutes and 4 seconds
Commit: 7cb2c7b (master)
Author: Markus Neteler
Message: libproj: cleanup of local copies of NAD and datum shift files which 
are used from GDAL; extended documentation in README.txt (trac #2456)

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@69211 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/62ca68ef4fcb...7cb2c7bb02ce

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/154167048

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

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

Re: [GRASS-dev] [GRASS GIS] #2456: read CSV from GDAL data directory

[GRASS GIS]

#2456: read CSV from GDAL data directory
-+-
  Reporter:  martinl |  Owner:  grass-dev@…
  Type:  task| Status:  new
  Priority:  blocker |  Milestone:  7.0.5
 Component:  Projections/Datums  |Version:  svn-releasebranch70
Resolution:  |   Keywords:  gdal, g.proj
   CPU:  Unspecified |   Platform:  Unspecified
-+-

Comment (by martinl):

 I suggest to change milestone from 7.0.5 to 7.3.0. I don't feel that there
 is something what we can do for 7.0.5 release.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #943: wxpython gui hangs after switching to cairo display driver

[GRASS GIS]

#943: wxpython gui hangs after switching to cairo display driver
---+--
  Reporter:  epatton   |  Owner:  grass-dev@…
  Type:  defect| Status:  closed
  Priority:  critical  |  Milestone:  6.4.6
 Component:  wxGUI |Version:  svn-develbranch6
Resolution:  wontfix   |   Keywords:  cairo, driver, gui, wxpython
   CPU:  All   |   Platform:  Linux
---+--
Changes (by mlennert):

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


Comment:

 As the cairo driver is commented out for the GUI display, and so users
 will not be confronted with the issue and since it works well grass 7, I'm
 closing this as wontfix.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2456: read CSV from GDAL data directory

[GRASS GIS]

#2456: read CSV from GDAL data directory
-+-
  Reporter:  martinl |  Owner:  grass-dev@…
  Type:  task| Status:  new
  Priority:  blocker |  Milestone:  7.0.5
 Component:  Projections/Datums  |Version:  svn-releasebranch70
Resolution:  |   Keywords:  gdal, g.proj
   CPU:  Unspecified |   Platform:  Unspecified
-+-

Comment (by neteler):

 After discussion with Even Rouault at the FOSS4G 2016 code sprint and some
 testing with m.proj
  * removal of local copies of NAD and datum shift files which are indeed
 used from GDAL
  * extended documentation in lib/proj/README.txt

 Done in r69211.

 After extensive testing backport candidate. Test values available in
 https://github.com/OSGeo/proj.4/tree/master/nad . Test cases should be
 implemented with m.proj.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2008: grass.script's find_program() can't find modules

[GRASS GIS]

#2008: grass.script's find_program() can't find modules
---+-
  Reporter:  hamish|  Owner:  grass-dev@…
  Type:  defect| Status:  closed
  Priority:  critical  |  Milestone:  6.4.6
 Component:  Python|Version:  svn-releasebranch64
Resolution:  fixed |   Keywords:  find_program()
   CPU:  x86-64|   Platform:  All
---+-
Changes (by mlennert):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 It seems to be that the original issue is solved. I can even find addons.

 Closing as fixed. Please open another bug if some of the other issues
 discussed here are still valid.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1219: Integrate the IGNF register and the shift grid RGF93-NTF in grass

[GRASS GIS]

#1219: Integrate the IGNF register and the shift grid RGF93-NTF in grass
-+-
  Reporter:  lemaitret   |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  normal  |  Milestone:  7.2.0
 Component:  |Version:  svn-releasebranch70
  Projections/Datums |   Keywords:  nad, g.proj, IGNF register shift
Resolution:  |  grid NTF RGF93
   CPU:  All |   Platform:  All
-+-

Comment (by neteler):

 Here how to test which files are used (expected: via GDAL/PROJ):

 {{{
 PROJ_DEBUG=ON CPL_DEBUG=ON m.proj proj_in="+init=epsg:4326"
 proj_out="+proj=longlat +datum=NAD27" coordinates=-100,40 -d
 }}}

 The debug messages contain the datum shift file usage information.

 TODO: find test case for ntf_r93. Could be done by using the values from
  https://github.com/OSGeo/proj.4/blob/master/nad/testIGNF
 within m.proj.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1329: 3D view silently crashes in pl_PL.UTF-8

[GRASS GIS]

#1329: 3D view silently crashes in pl_PL.UTF-8
-+--
  Reporter:  msieczka|  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  critical|  Milestone:  6.4.6
 Component:  wxGUI   |Version:  svn-develbranch6
Resolution:  worksforme  |   Keywords:  3d view
   CPU:  x86-64  |   Platform:  Linux
-+--
Changes (by mlennert):

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


Comment:

 No new info for five years and no response to the question of 8 months
 ago, so closing this bug as worksforme.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1444: g.parser does not filter for duplicate output map statements

[GRASS GIS]

#1444: g.parser does not filter for duplicate output map statements
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  blocker  |  Milestone:  6.4.6
 Component:  LibGIS   |Version:  svn-releasebranch64
Resolution:  fixed|   Keywords:  parser
   CPU:  All  |   Platform:  All
--+-
Changes (by mlennert):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"69209" 69209]:
 {{{
 #!CommitTicketReference repository="" revision="69209"
 parser: fix #1444 (backport from devel6)
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3134: d.legend.vect and v.colors

[GRASS GIS]

#3134: d.legend.vect and v.colors
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.legend.vect, v.colors
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by annakrat):

 * type:  defect => enhancement
 * milestone:  7.2.0 => 7.3.0


Comment:

 It could work in the way that v.colors writes a legend information as a
 comment into the color file stored for that vector map. Then d.vect takes
 it and outputs it into the legend file. The problem is also that we need
 to draw a gradient in some cases depending on how many color rules are in
 there or if the attribute column (which the color table is based on) is of
 type integer or float.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3134: d.legend.vect and v.colors

[GRASS GIS]

#3134: d.legend.vect and v.colors
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.legend.vect, v.colors
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

 * Attachment "legend-colors.png" added.

 vector legend doesn't respect color tables

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3134: d.legend.vect and v.colors

[GRASS GIS]

#3134: d.legend.vect and v.colors
-+-
 Reporter:  martinl  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.2.0
Component:  Display  |Version:  unspecified
 Keywords:  d.legend.vect, v.colors  |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 d.legend.vect doesn't work properly (see attachment:legend-colors.png)
 when using color tables for vectors, eg.

 {{{
 v.colors map=geology use=attr column=GEOL250_ID color=rainbow
 }}}

--
Ticket URL: 
GRASS GIS 

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