[GRASS5] Bugtracker usage.

[Glynn Clements]

Helena wrote:

> Bernhard
> 
> you are right - I looked at the bug tracker and it needs some serious
> clean-up. I tried to go through it and sort it a little bit out -
> here is what I managed to find out:
> 
> (I don't have permissions for doing modifications in the bug reports
> (and I probably should not have as I am not a programmer) and I don't
> want to bother Markus with this - so maybe you or somebody else who
> has a permission can double check what I have found and remove/close
> those bugs that are fixed or are not bugs.
> 
> Some bugs do not seem to be bugs, just people not having things
> properly installed - those should be removed - e.g
> 
> 755,753, 219, 199

#199 Nviz2.2 segmentation violation
#219 nviz2.2: BUG IN DYNAMIC LINKER 
#753 tcltkgrass menu system says xterm not found with Xfree 4.0  
#755 help (again)  

OK; I've marked these as resolved.

> this seems to be feature rather than bug
> 270

OK; marked as resolved.

> some are related to pretty old versions of GRASS and/or appear to be fixed
> (I cannot tell as they are out of my range of expertise
> 269 (5beta1?), 261, 195

#269 Grass5 and NFS 

I think that this is still present. Eric commented on this.

In looking into this, I noticed that src/libes/raster/io.c will create
the directory with mode 777 if it doesn't exist (it should be 1777). 
I've committed a fix for this particular issue.

Fixing the NFS issue is a bit more involved; if this is done as per
Eric's suggestion, the monitor socket (and possibly FIFOs) should also
be moved to below e.g. $HOME/.grass5. That would also make debugging
monitors easier.

#261 GRASS_PAGER: todo list

This is sort of done. The libraries still have hardcoded references to
"more"; allowing the user to override this is potentially problematic,
as programs which call library functions might not be expecting those
functions to invoke a curses program (i.e. less) which could mess up
the terminal.

This is classified as a "wish", so I've left it.

#195 r.mapcalc: not present on Max OSX binaries

Can someone check the MacOSX binary distribution?

If r.mapcalc is absent, my guess is that the build system didn't have
lex and yacc on it (a few other programs would also fail to be built,
but r.mapcalc would be the most noticeable).

> this seems to be fixed
> 252, 230 (it works for me in pre1), 112, 108

#252 r.to.sites: -z does not output third dimension 

I'm wondering if the submitter misunderstood (e.g. thought that
r.to.sites would magically obtain the elevation from somewhere).
I can't see a problem either, so marked as resolved.

#230 Seg fault in r.report

The submitter reports that b11 (2001/02) worked, but the 2001/03/26
snapshot didn't. But "cvs log" indicates that r.report didn't change
between those dates. Marked as resolved.

#112 Empty /usr/local/bin/grass5 file

This is currently taken by jhickey; I'll leave it for him to choose
whether to close it.

The "thread" goes on to discuss the Solaris-gcc-varargs issue.

I sent an updated configure.in to Markus for testing, but as he's
offline at the moment, I'm just going to commit it and wait for
complaints.

Basically, the new version only looks for headers and libraries in the
places that the compiler/linker looks by default, unless you
explicitly specify additional directories via configure arguments.

#108 s.geom : where is it?

Removed due to non-GPL status. Markus' comments suggest it is
superseded by s.delaunay and s.voronoi, so marked as resolved.

> I contacted the user that reported r.slope.aspect bug (756)
> that I may possibly fix to get some more info (I don't have the problem
> that he reports)
> 
> On a separate issue - as we are getting up and running GRASS here
>  I found that people are dowloading all kinds of versions
> of GRASS thinking that they have the latest one:
> e.g. dowload cvs (march2001?) and then update (probably incorrectly) so
> e.g. nviz script did not get updated
> or downloading beta11 (is it still there?)
> It would be good to minimize the versions that are out there or make
> it more prone to people installing old versions and/or not updating
> properly.
> Maybe keep just weekly CVS snapshot so that the CVS version is never
> older than the latest release?
> 
> It appears clear to me that I should get 5.0.0.pre1 or cvs snapshot
> but somehow not everybody is doing that.

Once 5.0.0 is released, we might wish to discourage the use of CVS (or
snapshots thereof) by people who don't know how to submit usable bug
reports (test cases, backtraces, etc) and aren't planning on keeping
up-to-date with development.

It's not (too much of) a problem to make the effort to track down bugs
in a single, commonly used version, nor to investigate reliable
reports in an arbitrary version. But trying to locate bugs which might
not even exist in a version that may no longer be relevant probably
isn't worth the effort.

-- 
Glynn Clements <glynn.clements at virgin.net>