Re: [GRASS-dev] r.stream: Incompatible library version for module.

2012-01-31 Thread Margherita Di Leo
Markus,

On Mon, Jan 30, 2012 at 11:57 PM, Markus Neteler nete...@osgeo.org wrote:

 On Mon, Jan 30, 2012 at 9:18 PM, Margherita Di Leo
 dileomargher...@gmail.com wrote:
  Hi,
 
  I just recompiled grass7 and installed r.stream modules by g.extension.
 But
  when i try to use them I get error:
 
  GRASS 7.0.svn (nc_spm_08):~  r.stream.extract
  ERROR: Incompatible library version for module. You need to rebuild GRASS
 or untangle multiple installations.
  GRASS 7.0.svn (nc_spm_08):~  r.stream.basins
  ERROR: Incompatible library version for module. You need to rebuild GRASS
 or untangle multiple installations.
  GRASS 7.0.svn (nc_spm_08):~ 
 
  What's wrong?

 you need to run
 make distclean

 and reconfigure etc.


I did it, but just to be sure, did it again, but error is still there.
Thanks,

madi


 ciao
 Markus




-- 
Eng. Margherita Di Leo
Ph.D. Candidate
Methods and Technologies for Environmental Monitoring
Department of Environmental Engineering and Physics (DIFA)

University of Basilicata
Campus Macchia Romana
85100 - Potenza
Italy

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

Re: [GRASS-dev] r.stream: Incompatible library version for module.

2012-01-31 Thread Luca Delucchi
2012/1/31 Margherita Di Leo dileomargher...@gmail.com:

 I did it, but just to be sure, did it again, but error is still there.

for me it works

 Thanks,

 madi

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] in trunk png/cairo d.vect overwrites previous images?

2012-01-31 Thread Moritz Lennert

On 31/01/12 00:20, Patrice Dumas wrote:

Hello,

I ask here first before because this seems a bit weird that nobody else
reported it, but maybe I missed a bug report or something changed in grass
7?

When doing more than one d.vect after a d.mon start=png (or cairo) the
last one overwrite completly the previous one.  With wx0 or 6.4 the
vector was on top but did not remove the previous vector.

Should I report that or is it known?


This behaviour is controlled by the GRASS_PNG_READ environment variable. 
If you set it to TRUE, then GRASS will lay the new d.vect on top of the 
already drawn vectors, otherwise it overwrites with the new. See 
http://grass.osgeo.org/grass70/manuals/html70_user/cairodriver.html.


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


[GRASS-dev] Re: [GRASS GIS] #1555: python-scripts in wingrass64svn

2012-01-31 Thread GRASS GIS
#1555: python-scripts in wingrass64svn
--+-
 Reporter:  hellik|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.2
Component:  Python| Version:  6.4.2 RCs
 Keywords:  wingrass, python scripts  |Platform:  MSWindows Vista  
  Cpu:  x86-32|  
--+-

Comment(by glynn):

 Replying to [comment:3 hellik]:

  just a very quick but not complete look for references to a (bundled)
 python here on my winvista-box regarding the windows side of python-life:
 
 {{{
 C:\Program Files\Inkscape\python\
 C:\Program Files\LibreOffice 3.4\Basis\program\python-core-2.6.1
 C:\Program Files\OpenOffice.org 3\Basis\program\python-core-2.6.1
 }}}

 The situation for a monolithic GUI application isn't comparable. These
 programs embed a Python interpreter in order to provide scripting
 capabilities within the application, in the same way that a web browser
 embeds a !JavaScript interpreter.

 GRASS' Python scripts are meant to fulfil the same role as Unix shell
 scripts or Windows batch files, but portably (and without the ANSI/OEM-
 codepage nonsense that batch files have).

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1555#comment:4
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] in trunk png/cairo d.vect overwrites previous images?

2012-01-31 Thread Patrice Dumas
On Tue, Jan 31, 2012 at 10:36:01AM +0100, Moritz Lennert wrote:
 
 This behaviour is controlled by the GRASS_PNG_READ environment variable. 
 If you set it to TRUE, then GRASS will lay the new d.vect on top of the 
 already drawn vectors, otherwise it overwrites with the new. See 
 http://grass.osgeo.org/grass70/manuals/html70_user/cairodriver.html.

Thanks.  I was pretty sure I missed something although I did read the
Fine Manual before asking...  Maybe the GRASS_PNG_READ description
could be enhanced by adding

  Otherwise the GRASS_PNGFILE file content is overwritten each time 
  a new display command is used.

Also I think that the Example should also set 

  export GRASS_PNG_READ=TRUE

otherwise it doesn't really make sense as the elevation raster will not
appear on map.png.

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


[GRASS-dev] Re: [GRASS GIS] #1558: make error in gui/images no directory created because of wrong pattern matching

2012-01-31 Thread GRASS GIS
#1558: make error in gui/images no directory created because of wrong pattern
matching
---+
 Reporter:  pertusus   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  normal |   Milestone:  6.4.2
Component:  Compiling  | Version:  svn-trunk
 Keywords: |Platform:  Linux
  Cpu:  x86-64 |  
---+

Comment(by glynn):

 Replying to [ticket:1558 pertusus]:

 I don't get this behaviour (with 3.82). I encountered a different bug,
 namely that it matched the subdirectory rule:
 {{{
 $(ETCDIR)/symbols/%: | $(ETCDIR)/symbols
 }}}

 and created directories named .../symbols/base/arrow.png/ etc; fixed in
 r50581.

  When the target pattern does not contain a slash (and it usually does
 not), directory names in the file names are removed from the file name
 before it is compared with the target prefix and suffix.

 This doesn't apply, as all of the pattern rules contain at least one
 slash.

  And also I believe that the second rule is chosen because all the
 prerequisites exist:
 
  Note however, that a rule whose prerequisites actually exist or are
 mentioned always takes priority over a rule with prerequisites that must
 be made by chaining other implicit rules.

 It isn't clear what mentioned means, but r50581 might fix this, as it
 adds a non-pattern rule for each of the category subdirectories.

-- 
Ticket URL: http://trac.osgeo.org/grass/ticket/1558#comment:1
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] in trunk png/cairo d.vect overwrites previous images?

2012-01-31 Thread Moritz Lennert

On 31/01/12 11:01, Patrice Dumas wrote:

On Tue, Jan 31, 2012 at 10:36:01AM +0100, Moritz Lennert wrote:


This behaviour is controlled by the GRASS_PNG_READ environment variable.
If you set it to TRUE, then GRASS will lay the new d.vect on top of the
already drawn vectors, otherwise it overwrites with the new. See
http://grass.osgeo.org/grass70/manuals/html70_user/cairodriver.html.


Thanks.  I was pretty sure I missed something although I did read the
Fine Manual before asking...  Maybe the GRASS_PNG_READ description
could be enhanced by adding

   Otherwise the GRASS_PNGFILE file content is overwritten each time
   a new display command is used.


Will do, thanks for the suggestion.



Also I think that the Example should also set

   export GRASS_PNG_READ=TRUE

otherwise it doesn't really make sense as the elevation raster will not
appear on map.png.


Here's what I see as example on the page:

export GRASS_RENDER_IMMEDIATE=cairo
export GRASS_PNGFILE=nc_spm.png
export GRASS_WIDTH=800
export GRASS_HEIGHT=800
export GRASS_PNG_READ=TRUE

g.region rast=elevation
d.rast map=elevation
d.vect map=streams width=1 color=blue fcolor=aqua type=area,line
d.vect map=roadsmajor width=2


i.e. GRASS_PNG_READ is set... :-)

Moritz



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


Re: [GRASS-dev] patch for grass_trunk d.vect.thematic

2012-01-31 Thread Moritz Lennert

On 30/01/12 23:10, Patrice Dumas wrote:

Hello,

A little patch for d.vect.thematic.py in trunk.  It shows up if you use
   d.vect.thematic themetype=graduated_points

It fixes 2 things.  An unquoted string graduated_lines.  f_psmap not
being initialized although it is used line 1049.  I moved the f_psmap
initialization before.


Thanks, I'll apply it in SVN.

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


Re: [GRASS-dev] patch for grass_trunk d.vect.thematic

2012-01-31 Thread Moritz Lennert

On 31/01/12 11:24, Moritz Lennert wrote:

On 30/01/12 23:10, Patrice Dumas wrote:

Hello,

A little patch for d.vect.thematic.py in trunk. It shows up if you use
d.vect.thematic themetype=graduated_points

It fixes 2 things. An unquoted string graduated_lines. f_psmap not
being initialized although it is used line 1049. I moved the f_psmap
initialization before.


Thanks, I'll apply it in SVN.


Done.

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


Re: [GRASS-dev] in trunk png/cairo d.vect overwrites previous images?

2012-01-31 Thread Patrice Dumas
On Tue, Jan 31, 2012 at 11:15:47AM +0100, Moritz Lennert wrote:
 otherwise it doesn't really make sense as the elevation raster will not
 appear on map.png.
 
 Here's what I see as example on the page:
 
 export GRASS_RENDER_IMMEDIATE=cairo
 export GRASS_PNGFILE=nc_spm.png
 export GRASS_WIDTH=800
 export GRASS_HEIGHT=800
 export GRASS_PNG_READ=TRUE
 
 g.region rast=elevation
 d.rast map=elevation
 d.vect map=streams width=1 color=blue fcolor=aqua type=area,line
 d.vect map=roadsmajor width=2
 
 
 i.e. GRASS_PNG_READ is set... :-)

Ah, ok, I was looking at 
http://grass.osgeo.org/grass70/manuals/html70_user/pngdriver.html
There it is not set.

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


Re: [GRASS-dev] r.stream: Incompatible library version for module.

2012-01-31 Thread Margherita Di Leo
I recompiled grass7 again, making svn checkout instead of svn up, and
solved.

Thanks,
madi

On Tue, Jan 31, 2012 at 10:31 AM, Luca Delucchi lucadel...@gmail.comwrote:

 2012/1/31 Margherita Di Leo dileomargher...@gmail.com:
 
  I did it, but just to be sure, did it again, but error is still there.

 for me it works

  Thanks,
 
  madi

 --
 ciao
 Luca

 http://gis.cri.fmach.it/delucchi/
 www.lucadelu.org




-- 
Eng. Margherita Di Leo
Ph.D. Candidate
Methods and Technologies for Environmental Monitoring
Department of Environmental Engineering and Physics (DIFA)

University of Basilicata
Campus Macchia Romana
85100 - Potenza
Italy

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

Re: [GRASS-dev] patch for grass_trunk d.vect.thematic

2012-01-31 Thread Patrice Dumas
On Tue, Jan 31, 2012 at 11:36:51AM +0100, Moritz Lennert wrote:
 On 31/01/12 11:24, Moritz Lennert wrote:
 On 30/01/12 23:10, Patrice Dumas wrote:
 Hello,
 
 A little patch for d.vect.thematic.py in trunk. It shows up if you use
 d.vect.thematic themetype=graduated_points
 
 It fixes 2 things. An unquoted string graduated_lines. f_psmap not
 being initialized although it is used line 1049. I moved the f_psmap
 initialization before.
 
 Thanks, I'll apply it in SVN.
 
 Done.

Thanks !

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


[GRASS-dev] Re: [GRASS GIS] #1558: make error in gui/images no directory created because of wrong pattern matching

2012-01-31 Thread GRASS GIS
#1558: make error in gui/images no directory created because of wrong pattern
matching
---+
 Reporter:  pertusus   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  normal |   Milestone:  6.5.0
Component:  Compiling  | Version:  svn-trunk
 Keywords: |Platform:  Linux
  Cpu:  x86-64 |  
---+
Changes (by annakrat):

  * milestone:  6.4.2 = 6.5.0


Comment:

 Please, backport any bugfixes to 6.5

 Thanks

-- 
Ticket URL: http://trac.osgeo.org/grass/ticket/1558#comment:2
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] [GRASS GIS] #1559: v.in.ogr segfault with CSV file

2012-01-31 Thread GRASS GIS
#1559: v.in.ogr segfault with CSV file
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.5.0
Component:  Vector   | Version:  svn-develbranch6 
 Keywords:   |Platform:  Linux
  Cpu:  x86-64   |  
-+--
 Using db.in.ogr on a CSV file, the internal call to v.in.ogr fails:

 {{{
 GRASS 6.5.svn (piemonte_utm32_wgs84):~/compilati/grass65  v.in.ogr --q
 dsn=/incoming/dati_piemonte/vector_piemonte/Torino_1jan2010.csv
 out=Torino_1jan2010_csv -o
 Segmentation fault

 GRASS 6.5.svn (piemonte_utm32_wgs84):~/compilati/grass65  v.in.ogr
 dsn=/incoming/dati_piemonte/vector_piemonte/Torino_1jan2010.csv
 out=Torino_1jan2010_csv -o
 Over-riding projection check
 Segmentation fault


 GRASS 6.5.svn (piemonte_utm32_wgs84):~/compilati/grass65  gdb v.in.ogr
 GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2

 ...
 Reading symbols from /home/luca/compilati/grass6_devel/dist.x86_64
 -unknown-linux-gnu/bin/v.in.ogr...done.
 (gdb) r dsn=/incoming/dati_piemonte/vector_piemonte/Torino_1jan2010.csv
 out=Torino_1jan2010_csv -o
 Starting program: /home/luca/compilati/grass6_devel/dist.x86_64-unknown-
 linux-gnu/bin/v.in.ogr
 dsn=/incoming/dati_piemonte/vector_piemonte/Torino_1jan2010.csv
 out=Torino_1jan2010_csv -o
 [Thread debugging using libthread_db enabled]
 Over-riding projection check

 Program received signal SIGSEGV, Segmentation fault.
 __libc_free (mem=0x1) at malloc.c:3709
 3709malloc.c: No such file or directory.
 in malloc.c
 (gdb) bt full
 #0  __libc_free (mem=0x1) at malloc.c:3709
 ar_ptr = value optimised out
 p = value optimised out
 hook = 0
 #1  0x77bb9960 in Vect_set_organization (Map=0x7fffd5c0,
 str=0x77bce88d ) at header.c:257
 No locals.
 #2  0x77bba830 in Vect__init_head (Map=0x1) at
 init_head.c:40
 buf =
 
\000\000\000\000\000\000\000\000\340\222\377\377\377\177\000\000\240$a\000\000\000\000\000\225\a\337\367\377\177\000\000\001\000\000\000\000\000\000\000\200\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\345%\275\367\377\177\000
 #3  0x77bc4328 in Vect_open_new (Map=0x7fffd5c0, name=0x6124a0
 Torino_1jan2010_csv, with_z=0) at open.c:525
 ret = value optimised out
 ferror = value optimised out
 errmsg =
 
LC_MESSAGES/grasslibs.mo\000\232\061\365\377\177\000\000\000\000\000\000\000\000\000\000\300\231V\365\377\177\000\000\300\231V\365\377\177\000\000\000\000\000\000\000\000\000\000\034,
 '\000' repeats 15 times,
 
\001\000\000\000\000\000\000\000Ȋ-\365\377\177\000\000\030\000\000\000\060\000\000\000`\213\377\377\377\177\000\000\220\212\377\377\377\177\000\000s\347$\365\377\177\000\000PO%\000\000\000\000\000\300\231V\365\377\177\000\000\300\231V\365\377\177\000\000\000\000\000\000\000\000\000\000`\261V\365\377\177\000\000`\267\372\367\377\177\000\000\377\377\377\377\000\000\000\000\005\000\000\000\000\000\000\000\300\231V\365\377\177\000\000\005\000\000\000\000\000\000\000\005\000\000\000\000\000\000\000\376\346$\365\377\177\000\000\200\213\377\377\377\177\000\000\300\231V\365\377\177\000\000\005\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\005\000\000\000\000\000\000\000\034,
 '\000' repeats 15 times...
 buf =
 
ȿ\271\367\377\177\000\000\060\246\377\367\377\177\000\000@\314a\000\000\000\000\000\000\344t\367\377\177\000\000\377\377\377\377\000\000\000\000\t\000\000\000\000\000\000\000Г\377\377\377\177\000\000\020\227\377\377\377\177\000\000P\244`,
 '\000' repeats 19 times\360,
 
?\200p\230\367\377\177\000\000\000\000\000\000\000\000\000\000$\235\336\367\377\177\000\000\001,
 '\000' repeats 15 times,
 
ȿ\271\367\377\177\000\000\005\000\000\000\377\177\000\000Г\377\377\377\177\000\000\020\227\377\377\377\177\000\000\000\205a\000\000\000\000\000@\314a\000\000\000\000\000`\307a\000\000\000\000\000\225\a\337\367\377\177\000\000\320\fa\000\000\000\000
 xname = \221\222Y\032\000\000\000\000\354_\336\367\377\177,
 '\000' repeats 18 times,
 
\001\000\000\000\377\177\000\000\000\000\000\000\000\000\000\000\001\000\000\000\377\177\000\000\350\342\377\367\377\177\000\000\377\277\377\377\377\177\000\000\060\270\377\377\377\177\000\000\377\277\377\377\377\177,
 '\000' repeats 18 times, 7~@, '\000' repeats 13 times,
 @\346\377\367\377\177\000\000\006\000\000\000\001\000\000\000
 
\336`\000\000\000\000\000\340\224\377\377\377\177\000\000J\027@\000\000\000\000\000C\000_GB.UTF-8\000\377\177\000\000\002\000\000\000\000\000\000\000\361\245
 
\365\377\177\000\000LC_MESSAGES/grassmods.mo\000\232\061\365\377\177\000\000\200p\230\367\377\177\000\000\231\245
 \365\377\177\000\000en_GB.UTF-8\000\000\000\000
 xmapset =
 

[GRASS-dev] Re: [GRASS GIS] #1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong 'sort'

2012-01-31 Thread GRASS GIS
#1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong
'sort'
-+--
 Reporter:  sbl  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.2
Component:  Packaging| Version:  6.4.2 RCs
 Keywords:  wingrass, osgeo4w, qgis  |Platform:  MSWindows XP 
  Cpu:  Unspecified  |  
-+--

Comment(by sbl):

 Replying to [comment:5 hamish]:
  Replying to [comment:4 sbl]:
   I can confirm that:
   v.db.select --verbose map=grid columns=cat where=cat10
   works on a fresh installation of OSGeo4W, though, v.report
   and sort do not.
 
  what does `which sort` say? how about `which echo`?
 `which sort` says:
 'which' is not recognized as an internal or external
 command,
 operable program or batch file.
 Both, from the GRASS Text GUI, and the WX-GUI commandline interface
 Invoked from Msys it says:
 /bin/sort.exe

 
  do /bin/sort.exe and /bin/echo.exe exist?
 Not in C:\OSGeo4W\bin, but in C:\OSGeo4W\apps\msys\bin
 
  are you running the commands from a MSys rxvt terminal prompt, a cmd.exe
 DOS box, or the wxGUI command-line entry box?
 I tried the DOS box (GRASS Text GUI), the Wx-GUIs commandline, and Msys.
 The commands work only on Msys.
 
  In your $PATH /bin comes before /c/WINDOWS/system32, so I'm not sure why
 it wouldn't pick up /bin/sort.exe if it was there.
 Really strange, but when I write C:\OSGeo4W\apps\msys\bin\sort in GRASS
 CMD it works also from there.

 
 
  thanks,
  Hamish

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1553#comment:6
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] Re: [GRASS GIS] #1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong 'sort'

2012-01-31 Thread GRASS GIS
#1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong
'sort'
-+--
 Reporter:  sbl  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.2
Component:  Packaging| Version:  6.4.2 RCs
 Keywords:  wingrass, osgeo4w, qgis  |Platform:  MSWindows XP 
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:6 sbl]:
  I tried the DOS box (GRASS Text GUI), the Wx-GUIs commandline, and Msys.
  The commands work only on Msys.

 right, extra unix-like tools have been recently moved from `extrabin` to
 `msys/bin` (standalone installer). This was not reflected in `PATH`.
 Speaking about GRASS OSGeo4W package I am not sure if the original `msys`
 package from OSGeo4W framework contains all required unix-like tools.

 Ideally standalone installer should contain original `msys` package from
 OSGeo4W framework with all required tools, not locally extended msys
 installation, see
 [wiki:CompileOnWindows#InstalltheenvironmentforcompilationMingW here].

 It requires to collect list of required unix-line tools for GRASS and add
 `grass-msys` or update `msys` package in OSGeo4W framework.

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1553#comment:7
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] Re: [GRASS GIS] #1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong 'sort'

2012-01-31 Thread GRASS GIS
#1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong
'sort'
-+--
 Reporter:  sbl  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.2
Component:  Packaging| Version:  6.4.2 RCs
 Keywords:  wingrass, osgeo4w, qgis  |Platform:  MSWindows XP 
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:7 martinl]:
  (standalone installer). This was not reflected in `PATH`. Speaking about
 GRASS OSGeo4W package

 not right, seems to be OK for standalone and osgeo4w installer. Anyway for
 OSGeo4W `msys/bin` is the last item in `PATH`.

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1553#comment:8
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] Re: [GRASS GIS] #1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong 'sort'

2012-01-31 Thread GRASS GIS
#1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong
'sort'
-+--
 Reporter:  sbl  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.2
Component:  Packaging| Version:  6.4.2 RCs
 Keywords:  wingrass, osgeo4w, qgis  |Platform:  MSWindows XP 
  Cpu:  Unspecified  |  
-+--

Comment(by jef):

 Replying to [comment:7 martinl]:
  It requires to collect list of required unix-line tools for GRASS and
 add `grass-msys` or update `msys` package in OSGeo4W framework.

 GRASS is the only dependant on `msys`.  So `msys` should either be
 extended or replaced by `grass-msys`.

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1553#comment:9
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] [GRASS GIS] #1560: v.db.connect failed

2012-01-31 Thread GRASS GIS
#1560: v.db.connect failed
--+-
 Reporter:  lucadelu  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.5.0
Component:  Database  | Version:  svn-develbranch6 
 Keywords:|Platform:  Unspecified  
  Cpu:  x86-64|  
--+-
 Using v.db.join I obtain this error related to v.db.connect

 {{{
 + v.db.connect -gl map=comuni fs=| layer=1
 + cut -d| -f4
 *** glibc detected *** v.db.connect: free(): invalid pointer:
 0x7fdd364c33d8 ***
 === Backtrace: =
 /lib/x86_64-linux-gnu/libc.so.6(+0x78a8f)[0x7fdd33ba2a8f]
 /lib/x86_64-linux-gnu/libc.so.6(cfree+0x73)[0x7fdd33ba68e3]
 /home/luca/compilati/grass6_devel/dist.x86_64-unknown-linux-
 gnu/lib/libgrass_vect.6.5.svn.so(Vect_set_organization+0x20)[0x7fdd360ba960]
 /home/luca/compilati/grass6_devel/dist.x86_64-unknown-linux-
 gnu/lib/libgrass_vect.6.5.svn.so(Vect__init_head+0x30)[0x7fdd360bb830]
 /home/luca/compilati/grass6_devel/dist.x86_64-unknown-linux-
 gnu/lib/libgrass_vect.6.5.svn.so(Vect__open_old+0x85)[0x7fdd360c5705]
 v.db.connect(main+0x3af)[0x401ccf]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xff)[0x7fdd33b48eff]
 v.db.connect[0x401859]
 === Memory map: 
 0040-00403000 r-xp  09:02 29626241
 /home/luca/compilati/grass6_devel/dist.x86_64-unknown-linux-
 gnu/bin/v.db.connect
 00603000-00604000 r--p 3000 09:02 29626241
 /home/luca/compilati/grass6_devel/dist.x86_64-unknown-linux-
 gnu/bin/v.db.connect
 00604000-00605000 rw-p 4000 09:02 29626241
 /home/luca/compilati/grass6_devel/dist.x86_64-unknown-linux-
 gnu/bin/v.db.connect
 0136b000-0138c000 rw-p  00:00 0
 [heap]
 7fdd2400-7fdd24021000 rw-p  00:00 0
 7fdd24021000-7fdd2800 ---p  00:00 0
 7fdd2bedf000-7fdd2c186000 r--p  09:00 131627
 /usr/lib/locale/locale-archive
 7fdd2c186000-7fdd2c189000 r-xp  09:00 805048
 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
 7fdd2c189000-7fdd2c388000 ---p 3000 09:00 805048
 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
 7fdd2c388000-7fdd2c389000 r--p 2000 09:00 805048
 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
 7fdd2c389000-7fdd2c38a000 rw-p 3000 09:00 805048
 /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
 7fdd2c38a000-7fdd2c399000 r-xp  09:00 815083
 /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.9
 7fdd2c399000-7fdd2c599000 ---p f000 09:00 815083
 /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.9
 7fdd2c599000-7fdd2c59a000 r--p f000 09:00 815083
 /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.9
 7fdd2c59a000-7fdd2c59b000 rw-p 0001 09:00 815083
 /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.9
 7fdd2c59b000-7fdd2c611000 r-xp  09:00 805050
 /lib/x86_64-linux-gnu/libgcrypt.so.11.6.0
 7fdd2c611000-7fdd2c811000 ---p 00076000 09:00 805050
 /lib/x86_64-linux-gnu/libgcrypt.so.11.6.0
 7fdd2c811000-7fdd2c812000 r--p 00076000 09:00 805050
 /lib/x86_64-linux-gnu/libgcrypt.so.11.6.0
 7fdd2c812000-7fdd2c815000 rw-p 00077000 09:00 805050
 /lib/x86_64-linux-gnu/libgcrypt.so.11.6.0
 7fdd2c815000-7fdd2c8af000 r-xp  09:00 815089
 /usr/lib/x86_64-linux-gnu/libgnutls.so.26.14.12
 7fdd2c8af000-7fdd2caaf000 ---p 0009a000 09:00 815089
 /usr/lib/x86_64-linux-gnu/libgnutls.so.26.14.12
 7fdd2caaf000-7fdd2cab5000 r--p 0009a000 09:00 815089
 /usr/lib/x86_64-linux-gnu/libgnutls.so.26.14.12
 7fdd2cab5000-7fdd2cab6000 rw-p 000a 09:00 815089
 /usr/lib/x86_64-linux-gnu/libgnutls.so.26.14.12
 7fdd2cab6000-7fdd2cacf000 r-xp  09:00 133738
 /usr/lib/libsasl2.so.2.0.23
 7fdd2cacf000-7fdd2ccce000 ---p 00019000 09:00 133738
 /usr/lib/libsasl2.so.2.0.23
 7fdd2ccce000-7fdd2cccf000 r--p 00018000 09:00 133738
 /usr/lib/libsasl2.so.2.0.23
 7fdd2cccf000-7fdd2ccd rw-p 00019000 09:00 133738
 /usr/lib/libsasl2.so.2.0.23
 7fdd2ccd-7fdd2cce7000 r-xp  09:00 787026
 /lib/x86_64-linux-gnu/libresolv-2.13.so
 7fdd2cce7000-7fdd2cee7000 ---p 00017000 09:00 787026
 /lib/x86_64-linux-gnu/libresolv-2.13.so
 7fdd2cee7000-7fdd2cee8000 r--p 00017000 09:00 787026
 /lib/x86_64-linux-gnu/libresolv-2.13.so
 7fdd2cee8000-7fdd2cee9000 rw-p 00018000 09:00 787026
 /lib/x86_64-linux-gnu/libresolv-2.13.so
 7fdd2cee9000-7fdd2ceeb000 rw-p  00:00 0
 7fdd2ceeb000-7fdd2ceed000 r-xp  09:00 815099
 /lib/x86_64-linux-gnu/libkeyutils.so.1.3
 7fdd2ceed000-7fdd2d0ec000 ---p 2000 09:00 815099
 /lib/x86_64-linux-gnu/libkeyutils.so.1.3
 7fdd2d0ec000-7fdd2d0ed000 r--p 1000 09:00 815099
 /lib/x86_64-linux-gnu/libkeyutils.so.1.3
 7fdd2d0ed000-7fdd2d0ee000 rw-p 2000 09:00 815099
 /lib/x86_64-linux-gnu/libkeyutils.so.1.3
 7fdd2d0ee000-7fdd2d0f5000 r-xp  09:00 815155
 /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
 7fdd2d0f5000-7fdd2d2f4000 ---p 7000 09:00 815155
 

[GRASS-dev] [GRASS GIS] #1561: g.region zoom doesn't support several raster

2012-01-31 Thread GRASS GIS
#1561: g.region zoom doesn't support several raster
--+-
 Reporter:  lucadelu  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.2
Component:  LibGIS| Version:  svn-releasebranch64  
 Keywords:|Platform:  All  
  Cpu:  All   |  
--+-
 I try to do g.region zoom with two layers but it doesn't work

 {{{
 g.region
 zoom=A2010177_lower.250m_16_days_NDVI,A2010177_upper.250m_16_days_NDVI -ap

 Illegal filename. Character , not allowed.
 ERROR: Raster map
A2010177_lower.250m_16_days_NDVI,A2010177_upper.250m_16_days_NDVI
not found
 }}}

-- 
Ticket URL: http://trac.osgeo.org/grass/ticket/1561
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] Re: [GRASS GIS] #1560: v.db.connect failed

2012-01-31 Thread GRASS GIS
#1560: v.db.connect failed
--+-
  Reporter:  lucadelu |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.5.0
 Component:  Database | Version:  svn-develbranch6 
Resolution:  invalid  |Keywords:   
  Platform:  Unspecified  | Cpu:  x86-64   
--+-
Changes (by lucadelu):

  * status:  new = closed
  * resolution:  = invalid


Comment:

 Invalid, after a distclean now all it's working

-- 
Ticket URL: http://trac.osgeo.org/grass/ticket/1560#comment:1
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] Re: [GRASS GIS] #1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong 'sort'

2012-01-31 Thread GRASS GIS
#1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong
'sort'
-+--
 Reporter:  sbl  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.2
Component:  Packaging| Version:  6.4.2 RCs
 Keywords:  wingrass, osgeo4w, qgis  |Platform:  MSWindows XP 
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:9 jef]:
  Replying to [comment:7 martinl]:
   It requires to collect list of required unix-line tools for GRASS and
 add `grass-msys` or update `msys` package in OSGeo4W framework.
 
  GRASS is the only dependant on `msys`.  So `msys` should either be
 extended or replaced by `grass-msys`.

 right, also long-term
 [wiki:CompileOnWindows#InstalltheenvironmentforcompilationMingW bug] (1.)
 could be fixed. Any volunteer for collecting list of required unix-like
 tools (see bash scripts in GRASS 6)?

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1553#comment:10
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] Re: [GRASS GIS] #1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong 'sort'

2012-01-31 Thread GRASS GIS
#1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong
'sort'
-+--
 Reporter:  sbl  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.2
Component:  Packaging| Version:  6.4.2 RCs
 Keywords:  wingrass, osgeo4w, qgis  |Platform:  MSWindows XP 
  Cpu:  Unspecified  |  
-+--

Comment(by hamish):

 Replying to [comment:10 martinl]:
  Any volunteer for collecting list of required unix-like tools
  (see bash scripts in GRASS 6)?

 as long as we are shipping a msys environment (grass6) all supplied SUS
 unix power tools should be included, whether used in grass scripts
 (currently/yet) or not. their usefulness to size ratio is incredible, and
 we must consider the countless end-user scripts we know nothing about, and
 will never see.

 if there are a few problematic or huge executables in there of course they
 should be reviewed on a case by case basis, but the default collection
 needs to be there in full.


 Hamish

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1553#comment:11
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] Re: [GRASS GIS] #1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong 'sort'

2012-01-31 Thread GRASS GIS
#1553: osgeo4w and qgis builds: path settings to msys on wingrass find wrong
'sort'
-+--
 Reporter:  sbl  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.2
Component:  Packaging| Version:  6.4.2 RCs
 Keywords:  wingrass, osgeo4w, qgis  |Platform:  MSWindows XP 
  Cpu:  Unspecified  |  
-+--

Comment(by hamish):

 (since we are a supplier of basic building blocks, we must be very careful
 in everything we do not to let a failure of imagination on our part
 artificially limit the end-users' or some future developers' ability to
 invent and expand in ways we never thought of.)


 thanks,
 Hamish

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1553#comment:12
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] Re: [GRASS GIS] #1561: g.region zoom doesn't support several raster

2012-01-31 Thread GRASS GIS
#1561: g.region zoom doesn't support several raster
--+-
 Reporter:  lucadelu  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.2
Component:  LibGIS| Version:  svn-releasebranch64  
 Keywords:|Platform:  All  
  Cpu:  All   |  
--+-

Comment(by hamish):

 that's because zoom= does not accept multiple maps.

 {{{
 Usage:
  g.region [-dsplectwmn3bgau] [region=name] [rast=name[,name,...]]
[rast3d=name] [vect=name[,name,...]] [3dview=name] [n=value] [s=value]
[e=value] [w=value] [t=value] [b=value] [rows=value] [cols=value]
[res=value] [res3=value] [nsres=value] [ewres=value] [tbres=value]
[zoom=name] [align=name] [save=name] [--overwrite] [--verbose]
[--quiet]
 }}}

 at least for TYPE_STRING (maybe ok for others) we can't simply have the
 parser automatically detect commas and print a warning, as it might be
 part of the option's value (e.g. g.message).


 change to a wish or close as invalid?


 Hamish

-- 
Ticket URL: http://trac.osgeo.org/grass/ticket/1561#comment:1
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] Re: [GRASS GIS] #1559: v.in.ogr segfault with CSV file

2012-01-31 Thread GRASS GIS
#1559: v.in.ogr segfault with CSV file
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.5.0
Component:  Vector   | Version:  svn-develbranch6 
 Keywords:   |Platform:  Linux
  Cpu:  x86-64   |  
-+--

Comment(by hamish):

 Hi,

 I reverted a small change which added a G_debug() statement but I don't
 really see why that would break it. Can you try again with the latest svn?
 If not, maybe distclean helps?

 can you look in the vector/$MAP/head file and see that there is no weird
 chars in there from a missing null terminator or something like that?

 I tried to reproduce it locally but no luck, worksforme.


 Hamish

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1559#comment:1
GRASS GIS http://grass.osgeo.org

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