Re: [GRASS-dev] 6.4.0 blocker bugs

[Markus Metz]

Hamish wrote:

[snip]
>
> RC bugs according to the trac'er:
>  https://trac.osgeo.org/grass/report/13

The one blocker applies to Windows 7 only. My point was that for Linux
and IIUC also MAC 6.4 is stable. GRASS is not part of a Windows7
installation, but available through Linux repositories, e.g. yum
install grass should give you 6.4 without enabling particular
repositories, GDAL and PROJ4, also QGIS and SAGA are available through
standard repositories. Nothing but man power keeps us from making
available new wingrass installers on a regular basis.
>
> of those, weak-blockers IMO are-

of those, the only blocker is #1020, and it applies apparently to Windows7 only.
>
> I'm still meaning to spend a little time on this:
>  #1051   wxgui: SEARCH_PATH corruption

Great!
>
> and verify that g.proj's memory bug is /really/ fixed:
>  https://trac.osgeo.org/grass/ticket/1032
A mystery because not reproducible.

>  https://trac.osgeo.org/grass/ticket/827
Windows only, out of reach for us, unless we make a plan on how to
tell libgdal to ignore any Windows/System32/*.dll

>  https://trac.osgeo.org/grass/ticket/820
Proposed fix for OSGEO4W: add msys bash because from within the
OSGEO4W msys (the one you get when starting grass with msys console),
there is no /bin/bash

>  https://trac.osgeo.org/grass/ticket/555
>
> v.in.gpsbabel on WinGrass + a GPX file as in #555 is a quick test:
>> why does g.proj consistently fail in one particular script
>> with exit code 5, "ERROR_ACCESS_DENIED", and yet works fine
>> from the MSys command line and in other scripts?
>
> could someone with MS-Windows please (re)test that?

Done so on XP.

>
> when it's ready,

No blockers left for Linux, it's ready, IMHO.

Umh, we could wait a bit more to discover new blockers caused by e.g.
new incompatibilities between wxPython 2.8.11 and 2.8.12 or changes in
OSGEO4W...

Just nagging,

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

Re: [GRASS-dev] grass65 installation error

[Martin Landa]

Hi,

2010/7/6 Mohammed Rashad :
> change_view.cpp:87: error: invalid conversion from ‘nv_data*’ to ‘int’
> /home/rashad/grass6_devel/dist.i686-pc-linux-gnu/include/grass/nviz.h:133:
> error: too many arguments to function ‘int Nviz_set_viewpoint_persp(int)’
> change_view.cpp:87: error: at this point in file
> error: command 'gcc' failed with exit status 1
> make: *** [OBJ.i686-pc-linux-gnu/_grass6_wxnviz.so] Error 1

wxNviz waits for ctypes backport. Please ignore these errors for a while.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] grass65 installation error

[Mohammed Rashad]

 c1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
In file included from /usr/include/python2.6/Python.h:8,
 from nviz.h:28,
 from change_view.cpp:15:
/usr/include/python2.6/pyconfig.h:1031:1: warning: "_POSIX_C_SOURCE" redefined
In file included from /usr/include/assert.h:37,
 from /usr/include/wx-2.8/wx/debug.h:18,
 from /usr/include/wx-2.8/wx/defs.h:521,
 from /usr/include/wx-2.8/wx/wxprec.h:13,
 from nviz.h:5,
 from change_view.cpp:15:
/usr/include/features.h:158:1: warning: this is the location of the previous 
definition
In file included from /usr/include/python2.6/Python.h:8,
 from nviz.h:28,
 from change_view.cpp:15:
/usr/include/python2.6/pyconfig.h:1040:1: warning: "_XOPEN_SOURCE" redefined
In file included from /usr/include/assert.h:37,
 from /usr/include/wx-2.8/wx/debug.h:18,
 from /usr/include/wx-2.8/wx/defs.h:521,
 from /usr/include/wx-2.8/wx/wxprec.h:13,
 from nviz.h:5,
 from change_view.cpp:15:
/usr/include/features.h:160:1: warning: this is the location of the previous 
definition
change_view.cpp: In member function ‘std::vector 
> Nviz::SetViewDefault()’:
change_view.cpp:56: error: cannot convert ‘float*’ to ‘double*’ for argument 
‘1’ to ‘int Nviz_get_exag_height(double*, double*, double*)’
change_view.cpp: In member function ‘int Nviz::SetView(float, float, float, 
float, float)’:
change_view.cpp:81: error: cannot convert ‘nv_data*’ to ‘double’ for argument 
‘1’ to ‘int Nviz_set_viewpoint_height(double)’
change_view.cpp:83: error: cannot convert ‘nv_data*’ to ‘double’ for argument 
‘1’ to ‘int Nviz_set_viewpoint_position(double, double)’
change_view.cpp:85: error: invalid conversion from ‘nv_data*’ to ‘int’
/home/rashad/grass6_devel/dist.i686-pc-linux-gnu/include/grass/nviz.h:134: 
error: too many arguments to function ‘int Nviz_set_viewpoint_twist(int)’
change_view.cpp:85: error: at this point in file
change_view.cpp:87: error: invalid conversion from ‘nv_data*’ to ‘int’
/home/rashad/grass6_devel/dist.i686-pc-linux-gnu/include/grass/nviz.h:133: 
error: too many arguments to function ‘int Nviz_set_viewpoint_persp(int)’
change_view.cpp:87: error: at this point in file
error: command 'gcc' failed with exit status 1
make: *** [OBJ.i686-pc-linux-gnu/_grass6_wxnviz.so] Error 1


--
Rashad



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

[GRASS-dev] Re: [GRASS GIS] #827: standalone-installer: execution failed on g.proj.exe -p

[GRASS GIS]

#827: standalone-installer: execution failed on g.proj.exe -p
--+-
 Reporter:  timmie|   Owner:  grass-...@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.0
Component:  Installation  | Version:  svn-releasebranch64  
 Keywords:  wingrass  |Platform:  MSWindows XP 
  Cpu:  x86-32|  
--+-

Comment(by mmetz):

 Replying to [comment:21 glynn]:
 >
 > The obvious common factor between g.region and g.proj is GDAL.
 >
 > I would guess that the libtiff.dll which is being loaded isn't the one
 which GDAL wants. You can use [http://www.dependencywalker.com/ Dependency
 Walker] to determine where libraries are being loaded from.
 >
 > The %PATH% environment variable is the last resort for locating
 libraries, so if there is a libtiff.dll in e.g. Windows or
 Windows/System32, it will take precedence. The only locations which are
 ahead of the Windows directories are the executable's directory (i.e.
 $GISBASE/bin) and any "Side-by-Side Assemblies" specified in the program's
 manifest (if it has one).

 Exactly the same error occurred on one of the systems I maintained last
 week, the culprit was a (very old) Windows/System32/libtiff.dll.
 Workaround was to move this libtiff.dll to a sandbox place, only then gdal
 (and consequently everything using gdal) used the correct libtiff.dll. No
 idea what application installed Windows/System32/libtiff.dll. Not sure if
 a manifest for g.proj or g.region would work because gdalinfo itself did
 not work, same error as shown in the attached pics.

 Not a solution but because this affects everything in osgeo4w that uses
 gdal I would say this should not keep us from releasing 6.4.0final.

 My2c,

 Markus M

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Re: [GRASS GIS] #820: r.in.wms doesn't work in WinGRASS installer distribution

[GRASS GIS]

#820: r.in.wms doesn't work in WinGRASS installer distribution
+---
 Reporter:  ddalimonte  |   Owner:  grass-...@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.0
Component:  Packaging   | Version:  svn-releasebranch64  
 Keywords:  r.in.wms, wingrass  |Platform:  MSWindows XP 
  Cpu:  Unspecified |  
+---

Comment(by mmetz):

 Replying to [comment:21 hamish]:
 >
 > [snip]
 > I think the problem is that #!/bin/bash is being run as some other sh
 for some reason.

 There is no /bin/bash available to my OSGEO4W msys. There is
 C:\OSGEO4W\bin\bash, but that is not available for the msys console
 C:\OSGEO4W\apps\msys\msys.bat because /bin seems to be equal to
 C:\OSGEO4W\apps\msys\bin and not C:\OSGEO4W\bin and there is no
 C:\OSGEO4W\apps\msys\bin\bash. So I added bash for msys plus its
 dependencies regex and termcap from

 http://sourceforge.net/downloads/mingw/MSYS/

 and r.in.wms works.

 Is this a proper solution or a crude hack?

 Markus M

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Re: [GRASS GIS] #555: v.in.gpsbabel on wingrass: g.proj error

[GRASS GIS]

#555: v.in.gpsbabel on wingrass: g.proj error
-+--
 Reporter:  hamish   |   Owner:  grass-...@…
  
 Type:  defect   |  Status:  new
  
 Priority:  minor|   Milestone:  6.4.0  
  
Component:  Vector   | Version:  6.4.0 RCs  
  
 Keywords:  wingrass, v.in.gpsbabel, g.proj  |Platform:  MSWindows XP   
  
  Cpu:  x86-32   |  
-+--

Comment(by mmetz):

 Replying to [comment:8 hamish]:
 > I am still completely baffled by this one.
 >
 > why does g.proj consistently fail in one particular script with exit
 code 5, "ERROR_ACCESS_DENIED", and yet works fine from the MSys command
 line and in other scripts?
 >

 Just tested v.in.gpsbabel on a recent (r42640) wingrass installation,
 works fine, coordinates are properly reprojected, seems to be fixed.

 Markus M

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] 6.4.0 blocker bugs

[Glynn Clements]

Helena Mitasova wrote:

> >> I learned that we should await the ctypes port to get rid of SWIG?
> > 
> > SWIG is only used within GRASS for the wxGUI vdigit and nviz modules. 
> > It's also used to generate wrappers for programmers who wish to access
> > the libraries directly, but these aren't used by any part of GRASS.
> > 
> > I suggest disabling all of this in the final release. The vdigit and
> > nviz modules don't work on Windows, and aren't particularly robust on
> > other platforms (and being loaded in-process means that any problems
> > affect the GUI as a whole, not just the vdigit/nviz modules).
> 
> Glynn, 
> I assume you are talking about wxnviz here, not the TclTk based nviz
> which runs on windows just fine?

Correct.

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

Re: [GRASS-dev] 6.4.0 blocker bugs

[Hamish]

everyone wrote:
> > >>> time to get out 6.4.0final :-)

MN:
> > I learned that we should await the ctypes port to get
> > rid of SWIG?

Glynn:
> SWIG is only used within GRASS for the wxGUI vdigit and
> nviz modules. It's also used to generate wrappers for
> programmers who wish to access the libraries directly, but
> these aren't used by any part of GRASS.
> 
> I suggest disabling all of this in the final release. The
> vdigit and nviz modules don't work on Windows, and aren't
> particularly robust on other platforms (and being loaded
> in-process means that any problems affect the GUI as a whole,
> not just the vdigit/nviz modules).
> 
> The SWIG wrappers for the libraries are barely usable and
> are planned to be replaced, so we shouldn't be encouraging
> their use.
> 
> IOW:
> 
> 1. The "swig" directory should be removed from DIRS in the
> top-level Makefile, so it isn't built (unless the user builds
> it manually).

fyi I've just commented out the SUBDIRS+=python in the
grass 6.5 swig/Makefile, assuming ctypes will take its place
there. no objection to it happening in the root Makefile.

I agree that we shouldn't release 6.4.0 with swig enabled, as
it will only encourage folks to invest in a dead-end.

> 2. Official binaries shouldn't use --with-python; this will
> prevent the vdigit and nviz modules from being built.
>
> 3. Optionally back-port the ctypes wrappers (lib/python/
> ctypes). Even if this doesn't work (fails to build or
> generates broken wrappers), it shouldn't break anything which
> would otherwise work.
> 
> 4. Optionally back-port the ctypes-based nviz module
> (wxnviz.py). This has most of the same issues as nviz/vdigit
> (i.e. the GRASS libraries are being accessed directly from the
> GUI process, so a segfault or G_fatal_error() will kill the
> GUI), but not all of them.
>
> 4b. Alternatively, back-port the changes but not wxnviz.py
> itself. The result is equivalent to just building
> --without-python (i.e. the GUI will try to import the wxnviz
> module, fail, and warn that it's disabled), except that the
> user can drop in wxnviz.py from SVN if they want to try it out.

I've no big opinion on if wxVdigit and wxNviz using swig should
remain enabled in 6.4.0 for now, or not. Works for me.

I suggest to continue to stabilize ctypes in 6.5svn and see where
it ends up. If it works cleanly there, backport to the 6.4 branch
for 6.4.1. (or if it's a quick job, for 6.4.0, but then as Martin
suggests we'd need one last RC. If it means a better end product
I don't mind that much)

Some folks on the list (eg Kim) report working Python interfaces,
I'm not sure if that has anything to with SWIG or just lib/python/
and init.* magic. Anyway, we should announce intentions once we
have some so they can adapt as needed. :)

Python programming hooks are a big selling point these days (our
univ even offers a new course in geospatial programming using
python) so it would be a pity to remove that from the 6.4.0
release announcement, but not the end of the world if it will be
released mature in 6.4.1. Personally I'd say that the stuff
offered by lib/python/ and our solid collection of low-level C
modules let us claim support for python programmers with a
straight face, even if it isn't every single libgis C lib fn.

--

RC bugs according to the trac'er:
  https://trac.osgeo.org/grass/report/13

of those, weak-blockers IMO are-

seems solvable with slight effort AFAICT:
 #1006   r.terraflow fails to stat() stream file on Windows
 #994v.buffer creating wrong buffer around polygon edges

I'm still meaning to spend a little time on this:
 #1051   wxgui: SEARCH_PATH corruption

and verify that g.proj's memory bug is /really/ fixed:
 https://trac.osgeo.org/grass/ticket/1032
 https://trac.osgeo.org/grass/ticket/827
 https://trac.osgeo.org/grass/ticket/820
 https://trac.osgeo.org/grass/ticket/555

v.in.gpsbabel on WinGrass + a GPX file as in #555 is a quick test:
> why does g.proj consistently fail in one particular script
> with exit code 5, "ERROR_ACCESS_DENIED", and yet works fine
> from the MSys command line and in other scripts?

could someone with MS-Windows please (re)test that?

--

Helena, fyi the FOSS4G 2010 Live osgeo demo DVD/usb stick will
ship with 6.4.0rc6; but MacOSX and MS Windows installers can be
updated at the last minute if newer versions become available.
The live version ships with the version UbuntuGIS has at build
time (which in turn is often derived from what Debian's Testing
has). We've got to prep, build, test, and send the master to
press a long time before the actual conference.


when it's ready,
Hamish


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