[GRASS5] Tarball?!!

GRASS GRASS developer
1

Now that we've got every developer a chance to check the release
branch version and nobody cried, we should do a beta release.

I've watched the CVS committs in the last days and I'm think
that we can release the branch as grass5.0.0.

Some people have committed bug fixes to both branches
most of the other bug fixes and enhancement can happily go into 5.0.1.

Markus,
can you create a tarball of the release branch? grass5.0.0pre4
Please only create the tarball first.
Then we can check if people can build binaries.

Or can you give us a schedule when you will be able to do this?

Thanks,
  Bernhard

2

On Tue, May 07, 2002 at 06:46:53PM +0200, Bernhard Reiter wrote:

Now that we've got every developer a chance to check the release
branch version and nobody cried, we should do a beta release.

I've watched the CVS committs in the last days and I'm think
that we can release the branch as grass5.0.0.

Some people have committed bug fixes to both branches
most of the other bug fixes and enhancement can happily go into 5.0.1.

Markus,
can you create a tarball of the release branch? grass5.0.0pre4
Please only create the tarball first.
Then we can check if people can build binaries.

I'd like to see the next release be 5.0. There have been a couple fixes
that maybe need some a little more testing and then we should put out
5.0. We'll probably need to follow it up with a bugfix release a month
or two later. I'm not sure it's useful to do another
"pre-beta-release-candidate" release ;-).

--
Eric G. Miller <egm2@jps.net>

3

On Tuesday 07 May 2002 06:46 pm, Bernhard Reiter wrote:

Now that we've got every developer a chance to check the release
branch version and nobody cried, we should do a beta release.

I've watched the CVS committs in the last days and I'm think
that we can release the branch as grass5.0.0.

Some people have committed bug fixes to both branches
most of the other bug fixes and enhancement can happily go into 5.0.1.

Markus,
can you create a tarball of the release branch? grass5.0.0pre4
Please only create the tarball first.
Then we can check if people can build binaries.

Or can you give us a schedule when you will be able to do this?

Thanks,
  Bernhard

We should wait for v.llabel, it is essential module.
And BTW, v.digit: move point doesn't work, I'll try to fix today.

Radim

4

On Tue, May 07, 2002 at 07:28:03PM -0700, Eric G. Miller wrote:

On Tue, May 07, 2002 at 06:46:53PM +0200, Bernhard Reiter wrote:
> can you create a tarball of the release branch? grass5.0.0pre4

I'd like to see the next release be 5.0.

We are following the plan.
If we can fix all release critical bugs on the release branch for
about one month, we can release pre4 as 5.0.0.
There have been too many code changes to just to a plain 5.0.0 release.
A beta period has to be done.

5

On Wed, May 08, 2002 at 09:17:13AM +0200, Radim Blazek wrote:

On Tuesday 07 May 2002 06:46 pm, Bernhard Reiter wrote:
> can you create a tarball of the release branch? grass5.0.0pre4

> Or can you give us a schedule when you will be able to do this?

We should wait for v.llabel, it is essential module.

Do you have a schedule on it? Who is doing it?
I'd rather not wait for it. There were many chances to have it included.

And BTW, v.digit: move point doesn't work, I'll try to fix today.

Okay, if it is an easy fix.

  Bernhard

6

On Wed, May 08, 2002 at 11:57:51AM +0200, Bernhard Reiter wrote:

On Wed, May 08, 2002 at 09:17:13AM +0200, Radim Blazek wrote:
> On Tuesday 07 May 2002 06:46 pm, Bernhard Reiter wrote:
> > can you create a tarball of the release branch? grass5.0.0pre4

> > Or can you give us a schedule when you will be able to do this?

> We should wait for v.llabel, it is essential module.

Do you have a schedule on it? Who is doing it?
I'd rather not wait for it. There were many chances to have it included.

Well, the v.llabel *was* working and was damaged during the last update.
So it must be fixed (hi Roger). Eventually Roger uploaded the wrong file
since the module cannot work any more (misuse of parameter options),
even not for him.

> And BTW, v.digit: move point doesn't work, I'll try to fix today.
Okay, if it is an easy fix.

  Bernhard

Markus

7

Okay.
Roger? What is the timeframe for this?

Another option would be to revert to the last working version.

On Wed, May 08, 2002 at 12:09:39PM +0200, Markus Neteler wrote:

On Wed, May 08, 2002 at 11:57:51AM +0200, Bernhard Reiter wrote:
> On Wed, May 08, 2002 at 09:17:13AM +0200, Radim Blazek wrote:
> > On Tuesday 07 May 2002 06:46 pm, Bernhard Reiter wrote:
> > > can you create a tarball of the release branch? grass5.0.0pre4
>
> > > Or can you give us a schedule when you will be able to do this?
>
> > We should wait for v.llabel, it is essential module.
>
> Do you have a schedule on it? Who is doing it?
> I'd rather not wait for it. There were many chances to have it included.

Well, the v.llabel *was* working and was damaged during the last update.
So it must be fixed (hi Roger). Eventually Roger uploaded the wrong file
since the module cannot work any more (misuse of parameter options),
even not for him.

> > And BTW, v.digit: move point doesn't work, I'll try to fix today.
> Okay, if it is an easy fix.
>
> Bernhard

Markus
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Professional Service for Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)

8

On Wednesday 08 May 2002 11:57 am, Bernhard Reiter wrote:

> And BTW, v.digit: move point doesn't work, I'll try to fix today.

Okay, if it is an easy fix.

For me it is not easy. It is a strange problem, which I cannot reproduce
on other machine. Select point on line does not work in "move point",
but works in "move line", both use the same function.

=> Don't wait for this.

Radim

9

On Tue, May 07, 2002 at 06:46:53PM +0200, Bernhard Reiter wrote:

Now that we've got every developer a chance to check the release
branch version and nobody cried, we should do a beta release.

I've watched the CVS committs in the last days and I'm think
that we can release the branch as grass5.0.0.

Some people have committed bug fixes to both branches
most of the other bug fixes and enhancement can happily go into 5.0.1.

Markus,
can you create a tarball of the release branch? grass5.0.0pre4
Please only create the tarball first.
Then we can check if people can build binaries.

Or can you give us a schedule when you will be able to do this?

Folks,

any objections for creating the source tarball of the release branch?

If not, I'll do that tomorrow morning Italian/Central European time.

The list of contributions to this release is really impressive
(see the NEWS.html file).

Markus

10

Markus Neteler wrote:

any objections for creating the source tarball of the release branch?

If not, I'll do that tomorrow morning Italian/Central European time.

We should check whether any of the recent changes should be
incorporated into the release. A complete list of the differences
between the head and the release branch follows.

aclocal.m4
configure
configure.in

  Fix to LOC_CHECK_LIBS
  GLw checks

src/libes/gis/sites.c
src/libes/gis/readsites_xyz.c

  Catch ERANGE

src/raster/r.tiff/
html/html/r.in.tiff.html

  Eric's true-colour changes

src/raster/r.in.png/
html/html/r.in.png.html

  My true-colour changes (and re-write)

src/raster/r.what/

  Increase NFILES
  Fix potential compile error (trailing garbage)

src/display/d.text.freetype
html/html/d.text.freetype.html
html/display.html
html/grass_commandlist.html
html/html/d.text.html

  Support "freetypecap" file
  Add HTML file
  Reference d.text.freetype from other files

src/display/devices/XDRIVER/XDRIVER24/Serve_Xevent.c

  Fix bug in resize code

src/display/devices/windows

  Use gmake5
  Various fixes

src/include/gisdefs.h
src/include/glocale.h
src/libes/gis/locale.c
src.garden/grass.postgresql/*/
documents/grass_i18n_howto.html

  I18N update

src/sites/s.surf.rst/

  Resurrect I18N

src.garden/grass.postgresql/v.to.pg/
html/html/v.to.pg.html
locale/ru/LC_MESSAGES/v.to.pg.po

  PostGIS support ("-p" switch)

src.contrib/GMSL/NVIZ2.2/src/tkInt8.0p2.h
src.contrib/GMSL/NVIZ2.2/src/tkInt8.0.2.h
src.contrib/GMSL/NVIZ2.2/src/tkInt8.0.5.h
src.contrib/GMSL/NVIZ2.2/src/togl.c

  Add tkInt8.0.5.h

src.contrib/GMSL/NVIZ2.2/scripts/nviz2.2_script
src.contrib/GMSL/NVIZ2.2/src/nviz_init.c

  Load state file ("state=") option

html/html/m.in.e00.html

  Document -t switch
  Additional comments regarding raster (GRID) files

html/html/d.extend.html

  Change format of Huidae's email address

mk/Makefile.docs

  Fix bug in generating manpages

handheld/

  Added

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

11

On Fri, May 10, 2002 at 06:02:33AM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> any objections for creating the source tarball of the release branch?
>
> If not, I'll do that tomorrow morning Italian/Central European time.

We should check whether any of the recent changes should be
incorporated into the release. A complete list of the differences
between the head and the release branch follows.

[snip]

src/libes/gis/sites.c
src/libes/gis/readsites_xyz.c

  Catch ERANGE

Not a huge deal since it generally shouldn't be an issue. But the check
is more correct than what was previously done and what dubious functions
like atoi and atof provide (which is no error reporting). Since some
of these functions are used for "untrusted" user input, it might be
good to have the check.

src/raster/r.tiff/
html/html/r.in.tiff.html

  Eric's true-colour changes

I tend to think this is high on the importance list, since the command
won't even run under some configurations without the changes. Also
fixes a small error regarding the projection when no TIFF world file
is present.

src/raster/r.in.png/
html/html/r.in.png.html

  My true-colour changes (and re-write)

Possibly consider adding support for pnw (PNG World files)? Same format
as TIFF World files... If so, similar support should be added to the
output program.

I don't have any opinions about the others...

--
Eric G. Miller <egm2@jps.net>

12

On Fri, May 10, 2002 at 06:02:33AM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> any objections for creating the source tarball of the release branch?
>
> If not, I'll do that tomorrow morning Italian/Central European time.

We should check whether any of the recent changes should be
incorporated into the release. A complete list of the differences
between the head and the release branch follows.

[snip]

src/raster/r.what/

  Increase NFILES

there was a limit to 14 files. I have tested with 110 files without
problems.

  Fix potential compile error (trailing garbage)

It seems that especially iPAQ-gcc is very sensitive to compiler warnings
while Linux/iX86 happily continues. It's a fix.

[...no comment]

src/display/devices/windows

  Use gmake5
  Various fixes

If the fix re-enables winGRASS, we should consider a sync.

[...no comment]

src.contrib/GMSL/NVIZ2.2/src/tkInt8.0p2.h
src.contrib/GMSL/NVIZ2.2/src/tkInt8.0.2.h
src.contrib/GMSL/NVIZ2.2/src/tkInt8.0.5.h
src.contrib/GMSL/NVIZ2.2/src/togl.c

  Add tkInt8.0.5.h

This should be also in release

src.contrib/GMSL/NVIZ2.2/scripts/nviz2.2_script
src.contrib/GMSL/NVIZ2.2/src/nviz_init.c

  Load state file ("state=") option

Did anyone test that except me? Here it works well and
does not look like a dangerous change.

html/html/m.in.e00.html

  Document -t switch
  Additional comments regarding raster (GRID) files

Should be sync'ed.

html/html/d.extend.html

  Change format of Huidae's email address

Should be sync'ed.

mk/Makefile.docs

  Fix bug in generating manpages

Should be sync'ed.

handheld/

  Added

Should be sync'ed (just to scripts).

Markus

13

Glynn Clements wrote:

> any objections for creating the source tarball of the release branch?
>
> If not, I'll do that tomorrow morning Italian/Central European time.

We should check whether any of the recent changes should be
incorporated into the release. A complete list of the differences
between the head and the release branch follows.

I've sync'd all of the following:

aclocal.m4
configure
configure.in

  Fix to LOC_CHECK_LIBS
  GLw checks

src/raster/r.what/

  Increase NFILES
  Fix potential compile error (trailing garbage)

src/display/devices/XDRIVER/XDRIVER24/Serve_Xevent.c

  Fix bug in resize code

src.contrib/GMSL/NVIZ2.2/src/tkInt8.0p2.h
src.contrib/GMSL/NVIZ2.2/src/tkInt8.0.2.h
src.contrib/GMSL/NVIZ2.2/src/tkInt8.0.5.h
src.contrib/GMSL/NVIZ2.2/src/togl.c

  Add tkInt8.0.5.h

html/html/d.extend.html

  Change format of Huidae's email address

mk/Makefile.docs

  Fix bug in generating manpages

I've also sync'd:

src/display/devices/windows

  Use gmake5
  Various fixes

However, I've just discovered that Mike reverted the Makefiles,
apparently due to a problem with the Gmakefiles. I'd like to see what
the issue is before progressing.

In light of comments from Markus and Eric, I'll also sync these:

html/html/m.in.e00.html

  Document -t switch
  Additional comments regarding raster (GRID) files

handheld/

  Added

src/libes/gis/sites.c
src/libes/gis/readsites_xyz.c

  Catch ERANGE

src/raster/r.tiff/
html/html/r.in.tiff.html

  Eric's true-colour changes

I've also decided to sync:

src/raster/r.in.png/
html/html/r.in.png.html

  My true-colour changes (and re-write)

The previous handling of true-colour images was extremely dubious; it
attempted to read user input, regardless of whether stdin was a tty,
and generated massive colour tables.

There's also the GLw changes to r3.showdspf.openGL/Gmakefile, which I
omitted to mention. I'll sync those; r3.showdspf.openGL isn't built by
default, so it isn't critical either way.

That leaves the following awaiting a decision:

src/display/d.text.freetype
html/html/d.text.freetype.html
html/display.html
html/grass_commandlist.html
html/html/d.text.html

  Support "freetypecap" file
  Add HTML file
  Reference d.text.freetype from other files

d.text.freetype is fairly new anyway, so I don't see any point in
using an older version.

src/include/gisdefs.h
src/include/glocale.h
src/libes/gis/locale.c
src.garden/grass.postgresql/*/
documents/grass_i18n_howto.html

  I18N update

The release branch has the last-but-one version of the I18N interface
(which is basically a historical accident; this just happened to be
the situation on the day the branch was made), so it should probably
be sync'd.

src/sites/s.surf.rst/

  Resurrect I18N

I18N should be harmless (if you don't have libintl.h, it's a definite
no-op).

src.garden/grass.postgresql/v.to.pg/
html/html/v.to.pg.html
locale/ru/LC_MESSAGES/v.to.pg.po

  PostGIS support ("-p" switch)

I don't know about this bit.

src.contrib/GMSL/NVIZ2.2/scripts/nviz2.2_script
src.contrib/GMSL/NVIZ2.2/src/nviz_init.c

  Load state file ("state=") option

This bit doesn't look right:

  --- /usr/src/grass5-rel/src.contrib/GMSL/NVIZ2.2/scripts/nviz2.2_script Tue Jan 22 04:51:40 2002
  +++ /usr/src/grass5-head/src.contrib/GMSL/NVIZ2.2/scripts/nviz2.2_script Wed May 8 01:39:42 2002
  @@ -320,7 +320,7 @@
       appBusy
   
       if {$fname != -1} then {
  - Nwrite_ppm $fname
  + Nwrite_ppm $fname 1
       }
       # show user can proceed
       appNotBusy

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

14

Bob,

please send a comment on below change:
On Fri, May 10, 2002 at 08:32:26AM +0100, Glynn Clements wrote:

> src.contrib/GMSL/NVIZ2.2/scripts/nviz2.2_script

[...]

> Load state file ("state=") option

This bit doesn't look right:

  --- /usr/src/grass5-rel/src.contrib/GMSL/NVIZ2.2/scripts/nviz2.2_script Tue Jan 22 04:51:40 2002
  +++ /usr/src/grass5-head/src.contrib/GMSL/NVIZ2.2/scripts/nviz2.2_script Wed May 8 01:39:42 2002
  @@ -320,7 +320,7 @@
       appBusy
   
       if {$fname != -1} then {
  - Nwrite_ppm $fname
  + Nwrite_ppm $fname 1
       }
       # show user can proceed
       appNotBusy

Why does the "1" appear - is it a bugfix?

Thanks,

Markus

15

On Fri, May 10, 2002 at 08:28:14AM -0300, Bob Covill wrote:

Markus Neteler wrote:
>
> Bob,
>
> please send a comment on below change:
> On Fri, May 10, 2002 at 08:32:26AM +0100, Glynn Clements wrote:
> > > src.contrib/GMSL/NVIZ2.2/scripts/nviz2.2_script
> [...]
> > > Load state file ("state=") option
> >
> > This bit doesn't look right:
> >
> > --- /usr/src/grass5-rel/src.contrib/GMSL/NVIZ2.2/scripts/nviz2.2_script Tue Jan 22 04:51:40 2002
> > +++ /usr/src/grass5-head/src.contrib/GMSL/NVIZ2.2/scripts/nviz2.2_script Wed May 8 01:39:42 2002
> > @@ -320,7 +320,7 @@
> > appBusy
> >
> > if {$fname != -1} then {
> > - Nwrite_ppm $fname
> > + Nwrite_ppm $fname 1
> > }
> > # show user can proceed
> > appNotBusy
>
> Why does the "1" appear - is it a bugfix?
>
> Thanks,
>
> Markus

Markus,

No the "1" should not be there after the Nwrite_ppm. The 1 is part the
testing the that I have been doing for drawing in the background. I had
added flags to Ndraw_all (not in above script) and Nwrite_ppm. Depending
on the flag it would draw and save images in the background.

Obviously this is unimplemented, so please remove the "1".

Sorry about passing that one on.

Thanks for the quick answer. I have removed the "1"
in CVS/HEAD.

Markus

16

Markus Neteler wrote:

> Obviously this is unimplemented, so please remove the "1".
>
> Sorry about passing that one on.

Thanks for the quick answer. I have removed the "1"
in CVS/HEAD.

OK; sync'd.

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

17

The only remaining differences are d.text.freetype (freetypecap),
v.to.pg (PostGIS), s.surf.rst (I18N), NEWS.html, and the removal of
src.nonGPL.

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

18

Glynn Clements wrote:

The only remaining differences are d.text.freetype (freetypecap),
v.to.pg (PostGIS), s.surf.rst (I18N), NEWS.html, and the removal of
src.nonGPL.

... and the (incomplete) changes to configure.in (but not configure
itself) and src/CMD/lists/optional which Alex has just committed.

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

19

Hi all.

> src/display/devices/windows
>
> Use gmake5
> Various fixes

However, I've just discovered that Mike reverted the Makefiles,
apparently due to a problem with the Gmakefiles. I'd like to see what
the issue is before progressing.

Minor problem - see separate message on WinGrass list.

The interesting aspect of this problem is that there were no Gmakefiles per
se in the Pre4 branch apart from the original one in
"src/display/devices/windows" which drove the original Cygwin Makefiles in
"wrap" and "w32" (which seems to be a reasonable state of affairs given
that the Cygwin Makefiles work).

For some reason or other those subdirectory Gmakefiles only appeared in the
CVS Head.

Cheers

Mike Thomas

20

Final update (hopefully): I've sync'd everything except the v.to.pg
changes and the I18N of libgis which Alex started over the weekend
(the latter *will* break systems with a separate libintl).

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