date:20150921

Re: [GRASS-dev] [GRASS GIS] #2748: ctype.POINTER function overloading prevents automatic byref() conversion

2015-09-21 Thread GRASS GIS

#2748: ctype.POINTER function overloading prevents automatic byref() conversion
+-
  Reporter:  artegion   |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Python ctypes  |Version:  7.0.1
Resolution: |   Keywords:
   CPU:  Unspecified|   Platform:  Unspecified
+-

Comment (by artegion):

 It seems a known bug of ctypesgen
 [https://github.com/davidjamesca/ctypesgen/issues/26]

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#288 (master - 865c724)

2015-09-21 Thread Travis CI

Build Update for GRASS-GIS/grass-ci
-

Build: #288
Status: Still Failing

Duration: 6 minutes and 56 seconds
Commit: 865c724 (master)
Author: Moritz Lennert
Message: added missing import of array library (fix #2688)


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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/4be5c5e2915d...865c7247bc5c

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

--

You can configure recipients for build notifications in your .travis.yml file. 
See http://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] table with the parser standard options

2015-09-21 Thread Moritz Lennert


On 19/09/15 06:37, Luca Delucchi wrote:

On 2 July 2015 at 09:49, Pietro  wrote:

Dear Luca and Moritz,



Dear All,


On Wed, Jul 1, 2015 at 11:58 AM, Moritz Lennert
 wrote:

May I just suggest the following small modification


ok, added.


I believe we should add the generated table somewhere in the manual docs.
Should I add this python script to grass_addons/tools?



Wouldn't it be better in tools/ directly in the source code ?


ok, committed in r65534.

Some examples:

{{{
$ python2 tools/parser_standard_options.py -t
lib/gis/parser_standard_options.c -f csv -o
parser_standard_options.csv

$ tail parser_standard_options.csv
G_OPT_STR3DS_INPUT;;Name of the input space time raster3d
dataset;;old,str3ds,str3ds;input;nameYES;TYPE_STRING
G_OPT_STR3DS_INPUTS;;Name of the input space time raster3d
datasets;;old,str3ds,str3ds;inputs;name;;YES;;YES;TYPE_STRING
G_OPT_STR3DS_OUTPUT;;Name of the output space time raster3d
dataset;;new,str3ds,str3ds;output;nameYES;TYPE_STRING
G_OPT_STDS_TYPE;strds;Type of the input space time
dataset;;;type;name;;;strds,stvds,str3ds;NO;TYPE_STRING
G_OPT_MAP_INPUT;;Name of the input map;;old,map,map;map;nameYES;TYPE_STRING
G_OPT_MAP_INPUTS;;Name of the input
maps;;old,map,map;maps;name;;YES;;YES;TYPE_STRING
G_OPT_MAP_TYPE;raster;Type of the input
map;;;type;name;;;raster,vector,raster_3d;NO;TYPE_STRING
G_OPT_T_TYPE;absolute;The temporal type of the space time
dataset;;;temporaltype;name;;;absolute,relative;NO;TYPE_STRING
G_OPT_T_WHERE;;Example: start_time > '2001-01-01
12:30:00';;;where;sql_query;WHERE conditions of SQL statement without
'where' keyword used in the temporal GIS framework;;;NO;TYPE_STRING
G_OPT_T_SAMPLE;start;The method to be used for sampling the input
dataset;;;sampling;name;;YES;start,during,overlap,contain,equal,follows,precedes;NO;TYPE_STRING

$ python2 tools/parser_standard_options.py -t
lib/gis/parser_standard_options.c -f html -o
parser_standard_options.html

$ head parser_standard_options.html

   
 option
 answer
 description
 descriptions
 gisprompt
 key
 key_desc
 label

$ python2 tools/parser_standard_options.py -t
lib/gis/parser_standard_options.c -f csv -o
parser_standard_options.csv -s Flg

$  tail parser_standard_options.csv
description;key
G_FLG_V_TABLE;Do not create attribute table;'t'
G_FLG_V_TOPO;Do not build topology;'b'
}}}



In r66263 I improved the tools of Pietro (specially I added a new
GRASS output), moved it in man directory and added it to Makefile.
It now return a batter table, you should see it at this link [0] after
next manual compilation. Until now this page is not linked in any
other manual's page, let me know where do you think should be
better...


Great job, thanks !

It should certainly be linked to from the g.parser man page (in 
replacement of the link to the programmer's manual).


Maybe there could also be a direct link in the "Miscellaneous & 
Variables" section ?


Moritz


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

[GRASS-dev] How to get data from a location where the user does not own any mapset?

2015-09-21 Thread Radim Blazek

Is it possible to access data through GRASS modules in a location
where the user does not own any mapset? Each GRASS module calls first
G_gisinit() which checks if current mapset returned by G_mapset() is
owned by current user. If it is not, it ends with fatal error. How to
get around this for locations where the user does not own any mapset?

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

Re: [GRASS-dev] [GRASS GIS] #2746: g.gui.vdigit fails to start with "PyAssertionError: C++ assertion "GetEventHandler() == this" failed at ../src/common/wincmn.cpp(478) in ~wxWindowBase(): any pushed

2015-09-21 Thread GRASS GIS

#2746: g.gui.vdigit fails to start with "PyAssertionError: C++ assertion
"GetEventHandler() == this" failed at ../src/common/wincmn.cpp(478) in
~wxWindowBase(): any pushed event handlers must have been removed"
--+
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.1.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  g.gui.vdigit digitizer
   CPU:  Unspecified  |   Platform:  Linux
--+
Changes (by mlennert):

 * keywords:  g.gui wxgui => g.gui.vdigit digitizer
 * version:  svn-releasebranch70 => svn-trunk
 * milestone:  7.0.2 => 7.1.0


Comment:

 Replying to [comment:2 annakrat]:
 > Do you have anything in ~/.grass7/toolboxes? I suspect you have there
 menu xml file generated for trunk, which fails because tplot is not in
 G70.


 That's it for the g.gui issue in g70. Thanks !

 However, the error when launching g.gui.vdigit in trunk remains (with
 fresh check out at r66264). I don't have this problem in g70.

 I've changed the title and parameters of this ticket to reflect that.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Planning of 7.0.2 release

2015-09-21 Thread Moritz Lennert


On 20/09/15 21:36, Laurent C. wrote:

Hi,

May I suggest to include a fix to r2688:
https://trac.osgeo.org/grass/ticket/2688

I don't think it can break anything. And it will prevent me to patch
GRASS each time I make an update ;)


I've just committed your patch to trunk (66267) and releasebranch70 
(r66268).


Moritz

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

Re: [GRASS-dev] TGRASS: mapset management question

2015-09-21 Thread Vaclav Petras

On Mon, Sep 21, 2015 at 5:06 PM, Markus Neteler  wrote:

>
> Is there a way to add an extra condition within the case 0. Or do we
> need a new G_mapset_permissions3() being less picky about ownership?

I'm not completely following the discussion but if there is a need to test
Mapset permissions for read-only in GRASS way (not just system
permissions), there should be a function to do that.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#289 (master - df4ce5c)

2015-09-21 Thread Travis CI

Build Update for GRASS-GIS/grass-ci
-

Build: #289
Status: Still Failing

Duration: 9 minutes and 3 seconds
Commit: df4ce5c (master)
Author: Markus Neteler
Message: v.kernel: always show target raster resolution; fix dangling curly 
braces -Wdangling-else

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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/865c7247bc5c...df4ce5cf6f36

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

--

You can configure recipients for build notifications in your .travis.yml file. 
See http://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] table with the parser standard options

2015-09-21 Thread Markus Neteler

Hi,

in r66271 I have submitted an attempt to fix the Travis issue.

On Mon, Sep 21, 2015 at 1:11 PM, Moritz Lennert
 wrote:
> Great job, thanks !
>
> It should certainly be linked to from the g.parser man page (in replacement
> of the link to the programmer's manual).
>
> Maybe there could also be a direct link in the "Miscellaneous & Variables"
> section ?

Yes, would be nice.

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

[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#290 (master - b8a43e2)

2015-09-21 Thread Travis CI

Build Update for GRASS-GIS/grass-ci
-

Build: #290
Status: Still Failing

Duration: 6 minutes and 50 seconds
Commit: b8a43e2 (master)
Author: Markus Neteler
Message: man: attempt to fix Travis CI issue with relative path

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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/df4ce5cf6f36...b8a43e29b2d6

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

--

You can configure recipients for build notifications in your .travis.yml file. 
See http://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] Still Failing: GRASS-GIS/grass-ci#289 (master - df4ce5c)

2015-09-21 Thread Markus Neteler

Hi,

one has to check the *raw* log to find it:
https://travis-ci.org/GRASS-GIS/grass-ci/builds/81415377
--> Build Jobs
 --> 289.1
  --> scroll down!
   --> This log is too long to be displayed. Please reduce
the verbosity
of your build or download the *raw log*

==> https://s3.amazonaws.com/archive.travis-ci.org/jobs/81415379/log.txt

...

make[3]: Entering directory `/home/travis/build/GRASS-GIS/grass-ci/man'
GISBASE="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
ARCH="x86_64-pc-linux-gnu"
ARCH_DISTDIR="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
VERSION_NUMBER=7.1.svn VERSION_DATE=2015 python ./build_full_index.py
GISBASE="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
ARCH="x86_64-pc-linux-gnu"
ARCH_DISTDIR="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
VERSION_NUMBER=7.1.svn VERSION_DATE=2015 python ./build_index.py
touch 
/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html/index.html
GISBASE="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
ARCH="x86_64-pc-linux-gnu"
ARCH_DISTDIR="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
VERSION_NUMBER=7.1.svn VERSION_DATE=2015 python ./build_topics.py
/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html
touch 
/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html/full_index.html
GISBASE="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
ARCH="x86_64-pc-linux-gnu"
ARCH_DISTDIR="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
VERSION_NUMBER=7.1.svn VERSION_DATE=2015 python ./build_keywords.py
/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html
touch 
/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html/topics.html
GISBASE="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
ARCH="x86_64-pc-linux-gnu"
ARCH_DISTDIR="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
VERSION_NUMBER=7.1.svn VERSION_DATE=2015 python
./build_graphical_index.py
/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html
touch 
/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html/graphical_index.html
GISBASE="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
ARCH="x86_64-pc-linux-gnu"
ARCH_DISTDIR="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
VERSION_NUMBER=7.1.svn VERSION_DATE=2015 python
./build_manual_gallery.py
/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html
touch 
/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html/keywords.html
GISBASE="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
ARCH="x86_64-pc-linux-gnu"
ARCH_DISTDIR="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
VERSION_NUMBER=7.1.svn VERSION_DATE=2015 python
./build_class_graphical.py
/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html
touch 
/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html/class_graphical.html
GISBASE="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
ARCH="x86_64-pc-linux-gnu"
ARCH_DISTDIR="/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu"
VERSION_NUMBER=7.1.svn VERSION_DATE=2015 python
./parser_standard_options.py -t ../lib/gis/parser_standard_options.c
-f grass -o 
/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html/parser_standard_options.html
-p 'id="opts_table" class="scroolTable"'
Traceback (most recent call last):
  File "./parser_standard_options.py", line 157, in 
args = parser.parse_args()
  File "/usr/lib/python2.7/argparse.py", line 1688, in parse_args
args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1710, in parse_known_args
default = self._get_value(action, default)
  File "/usr/lib/python2.7/argparse.py", line 2239, in _get_value
raise ArgumentError(action, msg)
argparse.ArgumentError: argument -t/--text: can't open '': [Errno 2]
No such file or directory: ''
make[3]: *** 
[/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html/parser_standard_options.html]
Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory `/home/travis/build/GRASS-GIS/grass-ci/man'
make[2]: *** [default] Error 2


(anyone editing this may also fix the typo "scroolTable" --> "scrollTable")

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

Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#289 (master - df4ce5c)

2015-09-21 Thread Martin Landa

Hi,

2015-09-21 18:47 GMT+02:00 Markus Neteler :
> ./parser_standard_options.py -t ../lib/gis/parser_standard_options.c
> -f grass -o 
> /home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html/parser_standard_options.html
> -p 'id="opts_table" class="scroolTable"'
> Traceback (most recent call last):
>   File "./parser_standard_options.py", line 157, in 
> args = parser.parse_args()
>   File "/usr/lib/python2.7/argparse.py", line 1688, in parse_args
> args, argv = self.parse_known_args(args, namespace)
>   File "/usr/lib/python2.7/argparse.py", line 1710, in parse_known_args
> default = self._get_value(action, default)
>   File "/usr/lib/python2.7/argparse.py", line 2239, in _get_value
> raise ArgumentError(action, msg)
> argparse.ArgumentError: argument -t/--text: can't open '': [Errno 2]
> No such file or directory: ''
> make[3]: *** 
> [/home/travis/build/GRASS-GIS/grass-ci/dist.x86_64-pc-linux-gnu/docs/html/parser_standard_options.html]
> Error 1
> make[3]: *** Waiting for unfinished jobs
> make[3]: Leaving directory `/home/travis/build/GRASS-GIS/grass-ci/man'
> make[2]: *** [default] Error 2

right, this is a know issue [1]. Martin

[1] https://lists.osgeo.org/pipermail/grass-dev/2015-September/076392.html

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

Re: [GRASS-dev] [GRASS GIS] #2448: Fontconfig error with cairo on Windows

2015-09-21 Thread GRASS GIS

#2448: Fontconfig error with cairo on Windows
--+---
  Reporter:  annakrat |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.2
 Component:  Display  |Version:  7.0.0
Resolution:   |   Keywords:  font, text, legend, scale bar
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+---

Comment (by hellik):

 Replying to [comment:58 annakrat]:
 > Replying to [comment:57 hellik]:
 > > Replying to [comment:56 hellik]:
 > > >
 > > > r66254 or higher
 > >
 > > in the show detail log, setting folder/file permission success should
 now be indicated by twice ''ok''
 > >
 > > {{{
 > > [...]
 > > Output folder: C:\Program Files\GRASS GIS 7.1.svn
 > > ok
 > > ok
 > > Execute: "C:\Program Files\GRASS GIS 7.1.svn\etc\run_gmkfontcap.bat"
 > > [...]
 > > }}}
 > >
 >
 > where should I see this log? I still can't see any text in the legend...

 if the installer runs, a button called "show Detail" (or similar) is shown
 ; press this button and the installer activities are shown.

 near the end this lines mentioned are listed.

 the "fixes" are only in trunk ; the latest daily installer is tested in
 win 7 32/64 bit and win 8.1 64 bit ; it is working correctly on all this
 tested win boxes.

 What is your exact win version and bitness?

--
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] #2448: Fontconfig error with cairo on Windows

2015-09-21 Thread GRASS GIS

#2448: Fontconfig error with cairo on Windows
--+---
  Reporter:  annakrat |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.2
 Component:  Display  |Version:  7.0.0
Resolution:   |   Keywords:  font, text, legend, scale bar
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+---

Comment (by hellik):

 Replying to [comment:58 annakrat]:
 > Replying to [comment:57 hellik]:
 > > Replying to [comment:56 hellik]:
 > > >
 > > > r66254 or higher
 > >
 > > in the show detail log, setting folder/file permission success should
 now be indicated by twice ''ok''
 > >
 > > {{{
 > > [...]
 > > Output folder: C:\Program Files\GRASS GIS 7.1.svn
 > > ok
 > > ok
 > > Execute: "C:\Program Files\GRASS GIS 7.1.svn\etc\run_gmkfontcap.bat"
 > > [...]
 > > }}}
 > >
 >
 > where should I see this log? I still can't see any text in the legend...

 some special security rules?  antivirus sw? virtual windows or real
 windows box?

--
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] #2448: Fontconfig error with cairo on Windows

2015-09-21 Thread GRASS GIS

#2448: Fontconfig error with cairo on Windows
--+---
  Reporter:  annakrat |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.2
 Component:  Display  |Version:  7.0.0
Resolution:   |   Keywords:  font, text, legend, scale bar
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+---

Comment (by annakrat):

 Replying to [comment:57 hellik]:
 > Replying to [comment:56 hellik]:
 > >
 > > r66254 or higher
 >
 > in the show detail log, setting folder/file permission success should
 now be indicated by twice ''ok''
 >
 > {{{
 > [...]
 > Output folder: C:\Program Files\GRASS GIS 7.1.svn
 > ok
 > ok
 > Execute: "C:\Program Files\GRASS GIS 7.1.svn\etc\run_gmkfontcap.bat"
 > [...]
 > }}}
 >

 where should I see this log? I still can't see any text in the legend...

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#291 (master - d4b94ae)

2015-09-21 Thread Travis CI

Build Update for GRASS-GIS/grass-ci
-

Build: #291
Status: Still Failing

Duration: 8 minutes and 5 seconds
Commit: d4b94ae (master)
Author: Markus Neteler
Message: temporal lib: clarify G_mapset_permissions2() output

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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/b8a43e29b2d6...d4b94ae7128c

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

--

You can configure recipients for build notifications in your .travis.yml file. 
See http://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] TGRASS: mapset management question

2015-09-21 Thread Markus Neteler

On Thu, Sep 17, 2015 at 11:19 PM, Markus Neteler  wrote:
> On Thu, Sep 17, 2015 at 1:53 PM, Markus Neteler  wrote:
...
> So, multiple mapset support backported.
>
> Thanks again to Soeren to figure it out.
...
> PS: Now we only need to shut up the warnings there :)

Found it:
lib/temporal/lib/connect.c

static char *get_mapset_connection_name(const char *mapset, int contype)
{
const char *val = NULL;
char *ret_val = NULL;;
const char *gisdbase = G_getenv_nofatal("GISDBASE");
const char *location = G_getenv_nofatal("LOCATION_NAME");
int ret;

G_debug(1,"Checking mapset <%s>", mapset);
ret = G_mapset_permissions2(gisdbase, location, mapset);
switch (ret) {
case 0: /* Check if the mapset exists and user is owner */
//G_warning(_("You don't have permission to access the mapset <%s>"),
// mapset);
break;
case -1:
G_warning(_("Mapset <%s> does not exist."),
  mapset);
break;
default:
break;
}
...

The problem is that in case of e.g. t.rast.list the
G_mapset_permissions2() test is too "agressive" since it checks if I
am the *owner* of another mapset (I am not in my case) while I just
want to read data from there.

Since we have 160+ mapsets in our EU LAEA location generated and owned
by a series of owners, I get spammed with messages of above case 0.
In the end the result of e.g. t.rast.list is almost invisible.

Is there a way to add an extra condition within the case 0. Or do we
need a new G_mapset_permissions3() being less picky about ownership?

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

Re: [GRASS-dev] [GRASS GIS] #2448: Fontconfig error with cairo on Windows

2015-09-21 Thread GRASS GIS

#2448: Fontconfig error with cairo on Windows
--+---
  Reporter:  annakrat |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.2
 Component:  Display  |Version:  7.0.0
Resolution:   |   Keywords:  font, text, legend, scale bar
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+---

Comment (by annakrat):

 Replying to [comment:60 hellik]:
 > Replying to [comment:58 annakrat]:
 > > Replying to [comment:57 hellik]:
 > > > Replying to [comment:56 hellik]:
 > > > >
 > > > > r66254 or higher
 > > >
 > > > in the show detail log, setting folder/file permission success
 should now be indicated by twice ''ok''
 > > >
 > > > {{{
 > > > [...]
 > > > Output folder: C:\Program Files\GRASS GIS 7.1.svn
 > > > ok
 > > > ok
 > > > Execute: "C:\Program Files\GRASS GIS 7.1.svn\etc\run_gmkfontcap.bat"
 > > > [...]
 > > > }}}
 > > >
 > >
 > > where should I see this log? I still can't see any text in the
 legend...

 Oh I see. Yes I can see there the 2 oks.
 >
 > some special security rules?  antivirus sw? virtual windows or real
 windows box?

 I am running windows 10 in a virtual machine, I didn't do anything
 special, I haven't installed any antivirus software. Sorry, I know it's
 frustrating...

--
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] #2748: ctype.POINTER function overloading prevents automatic byref() conversion

2015-09-21 Thread GRASS GIS

#2748: ctype.POINTER function overloading prevents automatic byref() conversion
+-
  Reporter:  artegion   |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Python ctypes  |Version:  7.0.1
Resolution: |   Keywords:
   CPU:  Unspecified|   Platform:  Unspecified
+-

Comment (by artegion):

 Not a real problem, just a bit disappointing: python ctypes documentation
 describes an interesting feature but our code presents a different
 behavior (it is far more pythonic do not care about byreference/byvalue if
 ctypes can do the dirty work).

 The odd thing is that happens unnoticed: while ctypes raises exceptions
 passing wrong argument type in this case only function return code (or
 segmentation fault exception) reveals troubles.

--
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] #2748: ctype.POINTER function overloading prevents automatic byref() conversion

2015-09-21 Thread GRASS GIS

#2748: ctype.POINTER function overloading prevents automatic byref() conversion
+-
  Reporter:  artegion   |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Python ctypes  |Version:  7.0.1
Resolution: |   Keywords:
   CPU:  Unspecified|   Platform:  Unspecified
+-

Comment (by artegion):

 Replying to [comment:1 glynn]:
 > Replying to [ticket:2748 artegion]:
 >
 > > grass.lib module overwrites ctype.POINTER function in ctypes_preamble
 module.
 >
 > The replacement POINTER function has the following comment:
 > {{{
 > # Convert None to a real NULL pointer to work around bugs
 > # in how ctypes handles None on 64-bit platforms
 > }}}
 > Have you tested whether this is still an issue (it might have been fixed
 since ctypesgen was last updated)?
 >
 > Having to use byref() explicitly seems less of an issue than not working
 on 64-bit systems.
 >
 > Actually, if an argument is a pointer, the caller should probably be
 using byref() explicitly regardless of whether or not ctypes has a
 workaround. What's the problem with needing to use byref()?

 Not a real problem, just a bit disappointing: python ctypes documentation
 describes an interesting feature but our code presents a different
 behavior (it is far more pythonic do not care about byreference/byvalue if
 ctypes can do the dirty work).

 The odd thing is that happens unnoticed: while ctypes raises exceptions
 passing wrong argument type in this case only function return code (or
 segmentation fault exception) reveals troubles.

--
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] #2748: ctype.POINTER function overloading prevents automatic byref() conversion

[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#288 (master - 865c724)

Re: [GRASS-dev] table with the parser standard options

[GRASS-dev] How to get data from a location where the user does not own any mapset?

Re: [GRASS-dev] [GRASS GIS] #2746: g.gui.vdigit fails to start with "PyAssertionError: C++ assertion "GetEventHandler() == this" failed at ../src/common/wincmn.cpp(478) in ~wxWindowBase(): any pushed

Re: [GRASS-dev] Planning of 7.0.2 release

Re: [GRASS-dev] TGRASS: mapset management question

[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#289 (master - df4ce5c)

Re: [GRASS-dev] table with the parser standard options

[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#290 (master - b8a43e2)

Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#289 (master - df4ce5c)

Re: [GRASS-dev] Still Failing: GRASS-GIS/grass-ci#289 (master - df4ce5c)

Re: [GRASS-dev] [GRASS GIS] #2448: Fontconfig error with cairo on Windows

Re: [GRASS-dev] [GRASS GIS] #2448: Fontconfig error with cairo on Windows

Re: [GRASS-dev] [GRASS GIS] #2448: Fontconfig error with cairo on Windows

[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#291 (master - d4b94ae)

Re: [GRASS-dev] TGRASS: mapset management question

Re: [GRASS-dev] [GRASS GIS] #2448: Fontconfig error with cairo on Windows

Re: [GRASS-dev] [GRASS GIS] #2748: ctype.POINTER function overloading prevents automatic byref() conversion

Re: [GRASS-dev] [GRASS GIS] #2748: ctype.POINTER function overloading prevents automatic byref() conversion

20 matches

Site Navigation

Mail list logo

Footer information