On 15/04/08 22:39, Marco Pasetti wrote:
Hi all,
It would be good also for me, even if it would better if we release it on
next week tough (I'm very busy now). BTW, there are few thing to do for me,
just some improvements for windows installer...
Martin, do you think that we could add the needed
#110: db/drivers/dbf fail to build due to undefined reference to
'SASetupDefaultHooks' (SHAPELIB)
---+
Reporter: marisn| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: closed
On Tue, 15 Apr 2008, Markus Neteler wrote:
(to continue on this thread)
After 6 release candidates, even tested on MS-Windows,
I don't see any real blockers any more. I suggest to get out
6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn.
Yes go for it I say; 6.3.0 is not
#50: g.copy segfaults (debian.gfoss.it package) [and latest SVN]
--+-
Reporter: steko| Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: major| Mil
Moritz Lennert wrote:
> > It would be good also for me, even if it would better if we release it on
> > next week tough (I'm very busy now). BTW, there are few thing to do for me,
> > just some improvements for windows installer...
> >
> > Martin, do you think that we could add the needed python
Hi Moritz,
>It really is not difficult to download and install the
python installers...
yes, I agree but: when I think to softwares packaging I always keep in my
mind all the experiences *collected* during the years with many users,
specially here at my university... specially among teach
Glynn,
>I would suggest two installers: one for GRASS alone, and one for the
various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
shouldn't have to download all of the dependencies each time a new
version of GRASS is released.
we could do as follows:
1. a *complete*, *first time*
Marco,
2008/4/16, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> > Martin, do you think that we could add the needed python files into the
> > 6.3.0 windows package, in order to let users start the pyGUI without the
> > need to install python stuffs by themselves?
>
> -1
>
> I don't think we should bloa
#72: PNG driver: boundary rendering is off by one pixel
--+-
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: blocker | Milest
Hi,
2008/4/16, Paul Kelly <[EMAIL PROTECTED]>:
> Yes go for it I say; 6.3.0 is not a stable release and everything does not
> have to be perfect, but may I suggest that the new branch for continued 6.x
> development be called develbranch_6 and that a 6.4 release branch be created
> off there at a
Hamish wrote:
> > After 6 release candidates, even tested on MS-Windows,
> > I don't see any real blockers any more. I suggest to get out
> > 6.3.0 this week and proceed with change to 6.4.release_branch/7.0.svn.
> >
> > We can have 6.3.1 if needed.
> >
> > Sounds ok?
>
> to me, trac bug #72 i
#111: r.los error "r.los.exe there are encountered to problem and needs to
close"
--+-
Reporter: gsancho | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority:
#111: r.los error "r.los.exe there are encountered to problem and needs to
close"
--+-
Reporter: gsancho | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority:
On Wed, Apr 16, 2008 at 6:28 AM, Hamish <[EMAIL PROTECTED]> wrote:
> Markus Neteler wrote:
> > (to continue on this thread)
> >
> > After 6 release candidates, even tested on MS-Windows,
> > I don't see any real blockers any more. I suggest to get out
> > 6.3.0 this week and proceed with chang
On 16/04/08 10:41, [EMAIL PROTECTED] wrote:
Glynn,
>I would suggest two installers: one for GRASS alone, and one for the
various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
shouldn't have to download all of the dependencies each time a new
version of GRASS is released.
we could
#50: g.copy segfaults (debian.gfoss.it package) [and latest SVN]
--+-
Reporter: steko| Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: major| Mil
#124: d.legend: apply arbitrary labels to a smooth floating-point colorbar
--+-
Reporter: epatton | Owner: hamish
Type: enhancement | Status: assigned
Priority: minor
I would vote for a lean base installer to be distributed on
grass.itc.it. Other projects can build fatter installers based
on that and distribute them. A bare bones installer will be
much easier to maintain for us in the long run.
Benjamin
Moritz Lennert wrote:
On 16/04/08 10:41, [EMAIL PROTECT
#97: r.random fails with bus error on Mac OS X 10.5
---+
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: critical | Milestone: 6
On two very similar systems built today from the RC6 tarball (i686 RHEL5,
F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
traditional "output" on RHEL5. The tarballs have the same md5sums. Why?
r.in.gdal, r.in.ascii, r.los and r.in.bin (at least) are affected.
lib/gis/pars
On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <[EMAIL PROTECTED]> wrote:
> On two very similar systems built today from the RC6 tarball (i686 RHEL5,
> F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
> traditional "output" on RHEL5. The tarballs have the same md5sums. Why?
>
>
On Wed, 16 Apr 2008, Dylan Beaudette wrote:
On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <[EMAIL PROTECTED]> wrote:
On two very similar systems built today from the RC6 tarball (i686 RHEL5,
F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
traditional "output" on RHEL5. The
On my way out of town. I have 3 quick comments
1) How the binary installers are packaged should not affect the 6.3.0
release. IMHO, go for it.
2) A separate dependency installer is an excellent idea for Windows. That is
what has been done on the Mac for years and is very successful.
3) Currently
I can't test on 10.5 until I get back in town next week.
Michael
On 4/16/08 7:14 AM, "GRASS GIS" <[EMAIL PROTECTED]> wrote:
> #97: r.random fails with bus error on Mac OS X 10.5
> ---+
> Reporter: cmbarton | Owner
On Wed, Apr 16, 2008 at 7:47 AM, Roger Bivand <[EMAIL PROTECTED]> wrote:
> On Wed, 16 Apr 2008, Dylan Beaudette wrote:
>
>
> > On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <[EMAIL PROTECTED]> wrote:
> >
> > > On two very similar systems built today from the RC6 tarball (i686
> RHEL5,
> > > F7), I
Hi,
Using the spearfish dataset:
# start grass
grass63 grass/spearfish60/user1/
# dump the table associated with 'bugsites' in PERMANENT
db.select [EMAIL PROTECTED]
dbmi: Protocol error
dbmi: Protocol error
# one more try:
db.select bugsites
DBMI-DBF driver error:
Table 'bugsites' doesn't exi
Hi Moritz,
>This actually sounds much more sophisticated than what Glynn proposed.
yes, it is... but we could make a walkaround... I'll explain how later...
>Could you not simply propose one installer with only the latest
>(complete) GRASS binaries. This installer could check for any existing
Roger Bivand wrote:
On Wed, 16 Apr 2008, Dylan Beaudette wrote:
On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <[EMAIL PROTECTED]>
wrote:
On two very similar systems built today from the RC6 tarball (i686
RHEL5,
F7), I see that G_OPT_R_OUTPUT gets defined on F7 as "base", and the
traditional "
#127: WinGRASS Tcl/Tk GUI - Text formatting error in Output window
---+
Reporter: 4everskiff | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Marco,
I see what you mean on Windows. Actually, in this case, there are no
dependencies like you find on Unix systems. A separate install for
Msys/TclTk/Python might be useful. Then that part could be installed only as
needed and GRASS could be updated more often.
Michael
On 4/16/08 9:00 AM, "
Michael,
>I see what you mean on Windows. Actually, in this case, there are no
>dependencies like you find on Unix systems
thx. it's difficult to be a Windows user here. GRASS people is used to work on
too much advanced systems than I'm used to ;-) (even if I'm a linux user too)
>A separate
#127: WinGRASS Tcl/Tk GUI - Text formatting error in Output window
-+--
Reporter: 4everskiff | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor
You have described it well. If it¹s easier to just do a single package, then
I think that is what you should do. That is what most Windows (and Mac)
users expect anyway.
Michael
On 4/16/08 9:40 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Michael,
>
>> >I see what you mean on Windows.
Dylan Beaudette pisze:
Is this the normal behavior? i.e. I can "use" raster and vector files
across mapsets, but why not vector attributes?
Because you are using DBF driver and your database is in:
$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
(check with db.connect -p). This results in a different
On Wednesday 16 April 2008, Maciej Sieczka wrote:
> Dylan Beaudette pisze:
> > Is this the normal behavior? i.e. I can "use" raster and vector files
> > across mapsets, but why not vector attributes?
>
> Because you are using DBF driver and your database is in:
>
> $GISDBASE/$LOCATION_NAME/$MAPSET/
#127: WinGRASS Tcl/Tk GUI - Text formatting error in Output window
-+--
Reporter: 4everskiff | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor
Hi Michael,
>If its easier to just do a single package, then I think that is what you
should do. That is what most Windows (and Mac) users expect anyway.
...and that's very good to hear for me ;-)
Marco
_
Da: Michael Barton [mailto:[EMAIL PROTECTED]
Inviato: mercoledì 16 aprile 200
#128: NVIZ fails to load vector points without other map
-+--
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.
#46: NVIZ fly mode broken on 64bit systems
--+-
Reporter: marisn | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
#128: NVIZ fails to load vector points without other map
--+-
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone:
On Wed, 16 Apr 2008, Markus Neteler wrote:
Roger Bivand wrote:
On Wed, 16 Apr 2008, Dylan Beaudette wrote:
> On Wed, Apr 16, 2008 at 7:26 AM, Roger Bivand <[EMAIL PROTECTED]>
> wrote:
> > On two very similar systems built today from the RC6 tarball (i686
> > RHEL5,
> > F7), I see that
Roger Bivand wrote:
> I don't have ldd on Cygwin, but will look under F7.
use cygcheck,
http://grass.osgeo.org/grass62/binary/mswindows/#trouble
Hamish
Be a better friend, newshound, and
know-it-all
GRASS GIS wrote:
> #50: g.copy segfaults (debian.gfoss.it package) [and latest SVN]
> --+-
> Reporter: steko| Owner: grass-dev@lists.osgeo.org
> Type: defect | Status: closed
>
[EMAIL PROTECTED] wrote:
> >I would suggest two installers: one for GRASS alone, and one for the
> >various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
> >shouldn't have to download all of the dependencies each time a new
> >version of GRASS is released.
>
> we could do as follows
Moritz Lennert wrote:
> > >I would suggest two installers: one for GRASS alone, and one for the
> > various dependencies (PROJ, GDAL, MSys, ...). The idea is that you
> > shouldn't have to download all of the dependencies each time a new
> > version of GRASS is released.
> > we could do as follo
[EMAIL PROTECTED] wrote:
> >The question then is: do we need a "complete" installer with everything
> >in it (as you suggest), or can we impose the burden of two installers on
> >people, i.e. as Glynn suggests: one GRASS installer + one Dependencies
> >installer. I think this would be the best so
Roger Bivand wrote:
> have odd/stale things in the GRASS_LD_LIBRARY_PATH and in PATH (or LD
> path) environment variables. I don't have ldd on Cygwin, but will look
> under F7.
On Cygwin, "cygcheck" lists the DLLs which a program uses.
--
Glynn Clements <[EMAIL PROTECTED]>
__
> > Dylan Beaudette pisze:
> > > Is this the normal behavior? i.e. I can "use" raster and vector
> > > files across mapsets, but why not vector attributes?
Maciek:
> > Because you are using DBF driver and your database is in:
> >
> > $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
> >
> > (check with db.conn
#127: WinGRASS Tcl/Tk GUI - Text formatting error in Output window
-+--
Reporter: 4everskiff | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor
#128: NVIZ fails to load vector points without other map
--+-
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone:
On Wed, 16 Apr 2008, Hamish wrote:
Roger Bivand wrote:
I don't have ldd on Cygwin, but will look under F7.
use cygcheck,
http://grass.osgeo.org/grass62/binary/mswindows/#trouble
Thanks to Hamish and Glynn - making a copy of the installed
/bin/cygjasper-1.dll as /bin/cygjasper-1-701-1.dl
Comment (by hamish):
(but points are treated differently than lines and faces in NVIZ)
see also bug #49: NVIZ displays points (sites) always as thematic
Hi
Related: there is Bob Covill's patch fixing NVIZ sites dependency [1].
It would be too bad not to have it utilized. It's almost complet
52 matches
Mail list logo