[GRASS5] Let's publish 5.0.3

[Buchan_Milne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Markus Neteler wrote:

On Thu, Aug 14, 2003 at 04:20:30PM +0200, Buchan Milne wrote:

Markus Neteler wrote:

On Tue, Aug 12, 2003 at 07:28:43PM +0100, Paul Kelly wrote:

According to this suggestion I have updated the roadmap:
http://grass.itc.it/roadmap.html

As a mostly-user of grass, I get confused by this. Where was 5.2? Why no
5.1 if there is a 5.3? What about 5.7 if there is a 5.8?

The other software I am familiar with that has a similar problem with
versioning is samba. They had a stable release branch, 2.0.x, and were
doing heavy development in HEAD, which was supposed to be 2.1. Then,
they realised they would need a new stable branch with selected features
from HEAD (win2k support when a domain controller). So, they renumbered
HEAD to 3.0, but the new stable release branch became 2.2.x.

Grass is in a similar position. I would suggest, to keep people from
wondering about seemingly random version numbers, to:

- -keep 5.0.x branch in bugfix mode
- -development of current grass50 cvs becomes 5.1, if pre-release
snapshots are to be made, eventually becoming 5.2.x

To me this looks more confusing:

To whom? Grass developers? How many grass users have seen 5.1 who would
be confused by this?

replacing an existing 5.1 with
another 5.1 is not easy to understand. That's why I suggested to
skip number 5.1 (say, rename the current 5.1 to 5.7) and also
skip number 5.2 (as an unstable version following the non-existing
5.1 is 5.3 which then leads to 5.4).

For external people (ie who install grass and use it) 5.0->5.4,
5.7,5.8->6.0 makes one wonder what happened to 5.1, 5.2, 5.3, or if
there were 5.3.x releases (development), what happened to 5.1 and 5.2.

Users should never rely on version numbers in CVS, and surely 5.1.1 is
no more confusing than 5.3.1 if they though 5.1.0 was going to be the
new vector code?

But you have to decide who it's more important not to confuse, and who
you are more likely to confuse ...

Regards,
Buchan

- --
|--------------Another happy Mandrake Club member--------------|
Buchan Milne Mechanical Engineer, Network Manager
Cellphone * Work +27 82 472 2231 * +27 21 8828820x202
Stellenbosch Automotive Engineering http://www.cae.co.za
GPG Key http://ranger.dnsalias.com/bgmilne.asc
1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/QS9frJK6UGDSBKcRAjoYAJ4hEd1mpRQB3uEOJOfMcvWU+OMfSgCffsjX
Ky+gKSgQCIy/GhejiH8B8JI=
=AqZo
-----END PGP SIGNATURE-----

******************************************************************
Please click on http://www.cae.co.za/disclaimer.htm to read our
e-mail disclaimer or send an e-mail to info@cae.co.za for a copy.
******************************************************************

[neteler]

On Mon, Aug 18, 2003 at 09:56:15PM +0200, Buchan Milne wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Markus Neteler wrote:
> On Thu, Aug 14, 2003 at 04:20:30PM +0200, Buchan Milne wrote:
>
>>Markus Neteler wrote:
>>
>>>On Tue, Aug 12, 2003 at 07:28:43PM +0100, Paul Kelly wrote:
>>
>>>According to this suggestion I have updated the roadmap:
>>>http://grass.itc.it/roadmap.html
>>
>>As a mostly-user of grass, I get confused by this. Where was 5.2? Why no
>>5.1 if there is a 5.3? What about 5.7 if there is a 5.8?
>>
>>The other software I am familiar with that has a similar problem with
>>versioning is samba. They had a stable release branch, 2.0.x, and were
>>doing heavy development in HEAD, which was supposed to be 2.1. Then,
>>they realised they would need a new stable branch with selected features
>>from HEAD (win2k support when a domain controller). So, they renumbered
>>HEAD to 3.0, but the new stable release branch became 2.2.x.
>>
>>Grass is in a similar position. I would suggest, to keep people from
>>wondering about seemingly random version numbers, to:
>>
>>- -keep 5.0.x branch in bugfix mode
>>- -development of current grass50 cvs becomes 5.1, if pre-release
>>snapshots are to be made, eventually becoming 5.2.x
>
> To me this looks more confusing:

To whom? Grass developers? How many grass users have seen 5.1 who would
be confused by this?

this is easy to answer:
Checked on Mon, Jul 07, 2003 at 11:42:59AM +0200, Markus Neteler wrote:
   GRASS 5.1 Linux Binaries downloads in 1-6/2003 (only grass.itc.it):
         1168 successful downloads from 307 different sites
   GRASS 5.1 source code downloads in 1-6/2003 (only grass.itc.it):
          538 successful downloads from 245 different sites
   The numerous mirror sites are not considered here.

I should do a fresh 'access_log' check again.

> replacing an existing 5.1 with
> another 5.1 is not easy to understand. That's why I suggested to
> skip number 5.1 (say, rename the current 5.1 to 5.7) and also
> skip number 5.2 (as an unstable version following the non-existing
> 5.1 is 5.3 which then leads to 5.4).
>

For external people (ie who install grass and use it) 5.0->5.4,
5.7,5.8->6.0 makes one wonder what happened to 5.1, 5.2, 5.3, or if
there were 5.3.x releases (development), what happened to 5.1 and 5.2.

OK, it seems you are not happy with the roadmap.html document.

Users should never rely on version numbers in CVS, and surely 5.1.1 is
no more confusing than 5.3.1 if they though 5.1.0 was going to be the
new vector code?

But you have to decide who it's more important not to confuse, and who
you are more likely to confuse ...

Very true. However, it seems that most developers are not too interested
in this version numbering - so I don't know.
In any case we should *release* a new version and not only talk about
it.

Markus

[Bernhard_Reiter]

On Thu, Aug 14, 2003 at 04:20:30PM +0200, Buchan Milne wrote:

Markus Neteler wrote:
> On Tue, Aug 12, 2003 at 07:28:43PM +0100, Paul Kelly wrote:

>
> According to this suggestion I have updated the roadmap:
> http://grass.itc.it/roadmap.html

As a mostly-user of grass, I get confused by this. Where was 5.2? Why no
5.1 if there is a 5.3? What about 5.7 if there is a 5.8?

Key to this numbering scheme
is that odd secondary numbers always mean development versions.

[Bernhard_Reiter]

On Mon, Aug 18, 2003 at 10:40:29PM +0200, Markus Neteler wrote:

On Mon, Aug 18, 2003 at 09:56:15PM +0200, Buchan Milne wrote:
> Markus Neteler wrote:
> > On Thu, Aug 14, 2003 at 04:20:30PM +0200, Buchan Milne wrote:

> >>Grass is in a similar position. I would suggest, to keep people from
> >>wondering about seemingly random version numbers, to:
> >>
> >>- -keep 5.0.x branch in bugfix mode

That is what we plan to do.
But we need people maintaining it.
Otherwise focus will shift on things active developers are
interested it.

> >>- -development of current grass50 cvs becomes 5.1, if pre-release
> >>snapshots are to be made, eventually becoming 5.2.x
> >
> > To me this looks more confusing:
>
> To whom? Grass developers? How many grass users have seen 5.1 who would
> be confused by this?

I completely agree with Markus here
there has been a lot talk about 5.1 and its feature set.
Also there are many people not following GRASS development intensively.
If we release something that is called 5.1.x which does not have
the features as expected, this is a problem.

> > replacing an existing 5.1 with
> > another 5.1 is not easy to understand. That's why I suggested to
> > skip number 5.1 (say, rename the current 5.1 to 5.7) and also
> > skip number 5.2 (as an unstable version following the non-existing
> > 5.1 is 5.3 which then leads to 5.4).

It is easer to explain why that numbering scheme changed.

> But you have to decide who it's more important not to confuse, and who
> you are more likely to confuse ...

Very true. However, it seems that most developers are not too interested
in this version numbering - so I don't know.

I'll think most people will just go with your judgement.

[Bernhard_Reiter]

On Thu, Aug 14, 2003 at 12:12:23PM +0200, Markus Neteler wrote:

On Thu, Aug 14, 2003 at 11:05:13AM +0100, Paul Kelly wrote:
>
>
> On Thu, 14 Aug 2003, Markus Neteler wrote:
>
> > [...]
> >
> > Are there implications to release 5.3.0 before 5.0.3?
>
> Only that people might use it I think the CVS HEAD is in good working
> order at the minute. The old experimental releases 5.0.0preX had some
> quite serious bugs in them and at that time there was no alternative
> stable release available; I think the time is right to release 5.3.0.

To somewhat confirm:
I have looks at the diffs between the 5.0.x release branch and the
CVS HEAD. It seems to be a lot of (useless?) work required to
patch in the important bugfixes into the release branch for a 5.0.3
version.
Probably we better work on 5.4.0 then and 5.7.

5.0.3 is important for stability reasons.
In other projects I know how important that is in principle.

It will be quite some time before 5.4.0
and we need an official most stable version until we get this.

[neteler]

On Fri, Aug 22, 2003 at 04:40:21PM +0200, Bernhard Reiter wrote:

On Thu, Aug 14, 2003 at 12:12:23PM +0200, Markus Neteler wrote:
> On Thu, Aug 14, 2003 at 11:05:13AM +0100, Paul Kelly wrote:
> >
> >
> > On Thu, 14 Aug 2003, Markus Neteler wrote:
> >
> > > [...]
> > >
> > > Are there implications to release 5.3.0 before 5.0.3?
> >
> > Only that people might use it I think the CVS HEAD is in good working
> > order at the minute. The old experimental releases 5.0.0preX had some
> > quite serious bugs in them and at that time there was no alternative
> > stable release available; I think the time is right to release 5.3.0.
>
> To somewhat confirm:
> I have looks at the diffs between the 5.0.x release branch and the
> CVS HEAD. It seems to be a lot of (useless?) work required to
> patch in the important bugfixes into the release branch for a 5.0.3
> version.
> Probably we better work on 5.4.0 then and 5.7.

5.0.3 is important for stability reasons.
In other projects I know how important that is in principle.

Good news: You may have seen my activities to prepare 5.0.3

Now testers are needed to try release candidate 1:
http://mpa.itc.it/markus/grass50/

-> grass-5.0.3rc1_src.tar.gz 24M

It will be quite some time before 5.4.0
and we need an official most stable version until we get this.

Sure - under construction.
It basically depends on people to test above 5.0.3 release candidate.

Markus

[H_B]

Now testers are needed to try release candidate 1:
http://mpa.itc.it/markus/grass50/

-> grass-5.0.3rc1_src.tar.gz 24M

Is there any hope of getting --with-readline working for 5.0.3?
http://article.gmane.org/gmane.comp.gis.grass.user/1000

Hamish

[Glynn_Clements]

Hamish wrote:

> Now testers are needed to try release candidate 1:
> http://mpa.itc.it/markus/grass50/
>
> -> grass-5.0.3rc1_src.tar.gz 24M

Is there any hope of getting --with-readline working for 5.0.3?

Readline already works in 5.0.2, *provided* that libreadline has
dependency information.

http://article.gmane.org/gmane.comp.gis.grass.user/1000

As mentioned in that message, the problem is that, if libreadline
doesn't have dependency information, how do we decide which of
lib[n]curses, libtinfo or libtermcap we should use in order to get
tgetnum() etc.

Note that it may matter as to which one we choose; depending upon
which one we use, r.mapcalc might work perfectly, or it might only
work on certain types of terminal, or it might not work at all.

Also note that automated tests won't necessarily help; it's entirely
possible that using the wrong library will result in an r.mapcalc
which compiles and links without error but is unusable.

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

[H_B]

> Is there any hope of getting --with-readline working for 5.0.3?

Readline already works in 5.0.2, *provided* that libreadline has
dependency information.

Ok, further compiling finds that --with-readline works fine on my
Debian/testing, but fails on RedHat 9.

Should this then be fwd'd to Redhat (et al) as a bug/complaint?

Hamish

[Stephan_Holl2]

Hello developers,

[...]

Good news: You may have seen my activities to prepare 5.0.3

Now testers are needed to try release candidate 1:
http://mpa.itc.it/markus/grass50/

-> grass-5.0.3rc1_src.tar.gz 24M

[...]

I tried to compile GRASS5.0.3RC1 on debian testing.

*my configure-options:
CFLAGS="-O3 -Wall -mcpu=k6" LDFLAGS="-s" \
./configure --with-readline \
--with-tcltk-includes=/usr/include/tcl8.3/ \
'--with-postgres-includes=/usr/include/postgresql
/usr/include/postgresql/server
' \
--with-freetype \
--with-freetype-includes=/usr/X11R6/include/freetype2 \
--with-freetype-libs=/usr/X11R6/lib \
--with-gdal=/usr/local/bin/gdal-config \
--with-gd-libs=/usr/lib \
--with-gd-includes=/usr/include \
--with-png-libs=/usr/lib \
--with-png-includes=/usr/include \
--with-cxx \
--with-proj\

This results in 2 failures, d.barscale and grass.postgres (g.column.pg
and g.stats.pg)
everything else compiles.

*d.barscale:
make[1]: Entering directory
`/home/steph/grass-5.0.3rc1/src/display/d.barscale/cmd'
gcc -I/home/steph/grass-5.0.3rc1/src/include -O3 -Wall -mcpu=k6 -c
main.c -o OBJ.i686-pc-linux-gnu/main.o
main.c: In function `main':
main.c:50: error: `DEFAULT_BG_COLOR' undeclared (first use in this
function)
main.c:50: error: (Each undeclared identifier is reported only once
main.c:50: error: for each function it appears in.)
main.c:57: error: `DEFAULT_FG_COLOR' undeclared (first use in this
function)
main.c: At top level:
/home/steph/grass-5.0.3rc1/src/include/gis.h:35: Warnung:
`GRASS_copyright' defined but not used
make[1]: *** [OBJ.i686-pc-linux-gnu/main.o] Fehler 1
make[1]: Leaving directory
`/home/steph/grass-5.0.3rc1/src/display/d.barscale/cmd'
make: *** [all] Fehler 1

*g.column.pg:
make[1]: Entering directory
`/home/steph/grass-5.0.3rc1/src.garden/grass.postgresql/g.column.pg'
gcc -I/home/steph/grass-5.0.3rc1/src/include -O3 -Wall -mcpu=k6
-I/usr/include/postgresql -I/usr/include/postgresql/server -Wall
-DPACKAGE=\""g.column.pg"\" -c main.c -o OBJ.i686-pc-linux-gnu/main.o
main.c:83:30: missing terminating " character
main.c: In function `main':
main.c:84: error: Syntaxfehler before "a"
main.c:85: error: stray '\' in program
main.c:85:35: missing terminating " character
main.c:87:37: Warnung: multi-character character constant
main.c:91:34: missing terminating " character
main.c:96:30: missing terminating " character
main.c:97: error: Syntaxfehler before "FROM"
main.c:98:37: Warnung: multi-character character constant
main.c:101:34: missing terminating " character
main.c: At top level:
/home/steph/grass-5.0.3rc1/src/include/gis.h:35: Warnung:
`GRASS_copyright' defined but not used

*g.status.pg:
make[1]: Entering directory
`/home/steph/grass-5.0.3rc1/src.garden/grass.postgresql/g.stats.pg'
gcc -I/home/steph/grass-5.0.3rc1/src/include -O3 -Wall -mcpu=k6
-I/usr/include/postgresql -I/usr/include/postgresql/server -Wall
-DPACKAGE=\""g.stats.pg"\" -c infxStats.c -o
OBJ.i686-pc-linux-gnu/infxStats.o
infxStats.c:40:21: missing terminating " character
infxStats.c: In function `infxStats':
infxStats.c:41: error: Syntaxfehler before "group"
infxStats.c:41:39: missing terminating " character
infxStats.c:51:26: missing terminating " character
infxStats.c:52: error: `s' undeclared (first use in this function)
infxStats.c:52: error: (Each undeclared identifier is reported only once
infxStats.c:52: error: for each function it appears in.)
infxStats.c:52:18: missing terminating " character
infxStats.c:53: error: Syntaxfehler before string constant
infxStats.c:54:27: missing terminating " character
infxStats.c:55:18: missing terminating " character
infxStats.c:105: error: Syntaxfehler at end of input
/home/steph/grass-5.0.3rc1/src/include/gis.h:35: Warnung:
`GRASS_copyright' defined but not used
make[1]: *** [OBJ.i686-pc-linux-gnu/infxStats.o] Fehler 1

after a quick test
* NVIZ is up and running,
* PNG-driver works, also in 24bit,
* tcltkgrass runs,
* monitors work,
* r.fill.dir works
* pg*-modules not available because of former compile errors
* r.proj works without datum-transformation

hth
  Stephan

--
Stephan Holl

GnuPG Key-ID: 11946A09

16:57:56 up 5:44, 1 user, load average: 0.36, 0.11, 0.07

[neteler]

On Sun, Aug 24, 2003 at 06:17:11PM +0200, Stephan Holl wrote:
[...]

This results in 2 failures, d.barscale and grass.postgres (g.column.pg
and g.stats.pg)
everything else compiles.

*d.barscale:
make[1]: Entering directory
`/home/steph/grass-5.0.3rc1/src/display/d.barscale/cmd'
gcc -I/home/steph/grass-5.0.3rc1/src/include -O3 -Wall -mcpu=k6 -c
main.c -o OBJ.i686-pc-linux-gnu/main.o
main.c: In function `main':
main.c:50: error: `DEFAULT_BG_COLOR' undeclared (first use in this
function)
main.c:50: error: (Each undeclared identifier is reported only once
main.c:50: error: for each function it appears in.)
main.c:57: error: `DEFAULT_FG_COLOR' undeclared (first use in this
function)
main.c: At top level:

OK, fixed in CVS (release branch). The patch is

diff -u -r1.4.2.3 main.c
--- main.c 20 Aug 2003 08:16:03 -0000 1.4.2.3
+++ main.c 24 Aug 2003 16:47:26 -0000
@@ -47,14 +47,14 @@
        opt1 = G_define_option() ;
        opt1->key = "bcolor" ;
        opt1->type = TYPE_STRING ;
- opt1->answer = DEFAULT_BG_COLOR ;
+ opt1->answer = "black" ;
        opt1->required = NO ;
        opt1->description= "Color used for the background, or \"none\"" ;

        opt2 = G_define_option() ;
        opt2->key = "tcolor" ;
        opt2->type = TYPE_STRING ;
- opt2->answer = DEFAULT_FG_COLOR ;
+ opt2->answer = "white" ;
        opt2->required = NO ;
        opt2->options = D_color_list();
        opt2->description= "Color used for the text" ;

The other two problems: I darkly remember a newline fix, any
suggestions? Otherwise I'll dig into the details (commit archive).

after a quick test
* NVIZ is up and running,

Great. But you tested with tcl8.3.
Is there anyone with tcl8.4 who could try?

* PNG-driver works, also in 24bit,
* tcltkgrass runs,
* monitors work,
* r.fill.dir works
* pg*-modules not available because of former compile errors
* r.proj works without datum-transformation

Thanks, Stephan

Markus

[Stephan_Holl2]

Hello Markus,

At Sun, 24 Aug 2003 18:51:49 +0200 Markus Neteler wrote:

[...]

OK, fixed in CVS (release branch). The patch is

diff -u -r1.4.2.3 main.c
--- main.c 20 Aug 2003 08:16:03 -0000 1.4.2.3
+++ main.c 24 Aug 2003 16:47:26 -0000
@@ -47,14 +47,14 @@
        opt1 = G_define_option() ;
        opt1->key = "bcolor" ;
        opt1->type = TYPE_STRING ;
- opt1->answer = DEFAULT_BG_COLOR ;
+ opt1->answer = "black" ;
        opt1->required = NO ;
        opt1->description= "Color used for the background, or
        \"none\"" ;

        opt2 = G_define_option() ;
        opt2->key = "tcolor" ;
        opt2->type = TYPE_STRING ;
- opt2->answer = DEFAULT_FG_COLOR ;
+ opt2->answer = "white" ;
        opt2->required = NO ;
        opt2->options = D_color_list();
        opt2->description= "Color used for the text" ;

[...]

thanks, compiles now!

> after a quick test
> * NVIZ is up and running,

Great. But you tested with tcl8.3.
Is there anyone with tcl8.4 who could try?

[...]

I recompiled with tcl8.4,
* tcltkgrass runs,
* NVIZ stops running,
...
The papers are available at
http://www2.gis.uiuc.edu:2280/modviz/
Loading Data
Update elev null mask
Loading Data
translating colors
Adding panels from
/home/steph/grass-5.0.3rc1/dist.i686-pc-linux-gnu/etc/nviz2.2/scripts

the "please wait"-boxes appear, and the above message is the last output
of NVIZ.
ps ax shows a defunct-process for NVIZ.

any suggestions?

cheers
  Stephan

--
Stephan Holl

GnuPG Key-ID: 11946A09

20:21:03 up 9:07, 1 user, load average: 0.34, 0.13, 0.19

[neteler]

Concerning the readline support:

I have made a test on Mandrake 9.1 (current):

configure:6605: checking whether to use Readline
configure:6626: checking for location of Readline includes
configure:6652: checking for readline/readline.h
configure:6660: gcc -E conftest.c >/dev/null 2>conftest.out
configure:6696: checking for readline/history.h
configure:6704: gcc -E conftest.c >/dev/null 2>conftest.out
configure:6738: checking for location of Readline library
configure:6763: checking for readline in -lreadline
configure:6780: gcc -o conftest -g -O2 -rdynamic conftest.c -lreadline 1>&5
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `tgetnum'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `tgoto'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `tgetflag'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `BC'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `tputs'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `PC'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `tgetent'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `UP'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `tgetstr'
collect2: ld returned 1 exit status
configure: failed program was:
#line 6769 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply. */
char readline();

int main() {
readline()
; return 0; }

When adding -lncurses the test passes. Could be add -lncurses to
the config script (how) for the test?

Markus

[neteler]

Followup: I forgot to mention that below was tested in 5.1
But it should be valid for all GRASS 5.0.x/CVS HEAD/5.1 versions.

Markus

On Sun, Aug 24, 2003 at 09:10:56PM +0200, Markus Neteler wrote:

Concerning the readline support:

I have made a test on Mandrake 9.1 (current):

configure:6605: checking whether to use Readline
configure:6626: checking for location of Readline includes
configure:6652: checking for readline/readline.h
configure:6660: gcc -E conftest.c >/dev/null 2>conftest.out
configure:6696: checking for readline/history.h
configure:6704: gcc -E conftest.c >/dev/null 2>conftest.out
configure:6738: checking for location of Readline library
configure:6763: checking for readline in -lreadline
configure:6780: gcc -o conftest -g -O2 -rdynamic conftest.c -lreadline 1>&5
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `tgetnum'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `tgoto'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `tgetflag'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `BC'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `tputs'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `PC'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `tgetent'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `UP'
/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/../../../libreadline.so: undefined reference to `tgetstr'
collect2: ld returned 1 exit status
configure: failed program was:
#line 6769 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply. */
char readline();

int main() {
readline()
; return 0; }

When adding -lncurses the test passes. Could be add -lncurses to
the config script (how) for the test?

Markus

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

[Glynn_Clements]

Markus Neteler wrote:

Concerning the readline support:

When adding -lncurses the test passes. Could be add -lncurses to
the config script (how) for the test?

http://grass.itc.it/pipermail/grass5/2003-August/006104.html

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

[H_B]

> *d.barscale:

...

OK, fixed in CVS (release branch). The patch is

...

The other two problems: I darkly remember a newline fix, any
suggestions? Otherwise I'll dig into the details (commit archive).

Are you sure that wasn't d.where (Revision 1.13)? That has proj code and
is CVS/HEAD only.

Hamish

[neteler]

On Sat, Aug 23, 2003 at 10:20:50PM +1200, M. Hamish Bowman wrote:

> Now testers are needed to try release candidate 1:

NVIZ with Tcl/Tk 8.4: (on debian/testing) [WISH=/usr/bin/wish8.4]

GRASS:~ > nviz rastermap
[...]
Loading Data
Update elev null mask
building color table
child killed: segmentation violation

Remains to be an open problem (does the CVS HEAD work ?).

html/html/d.barscale.html
  - add missing options (fixed in CVS HEAD)

fixed.

src/tcltkgrass/module/d.barscale
  - add reference to bcolor=none (fixed in CVS HEAD)

fixed.

src/display/d.barscale/cmd/main.c
  * Compile error, sync changed code. (not fixed):

fixed yesterday.

html/html/d.rgb.html
  - minor cosmetics (fixed in CVS HEAD)

fixed

html/html/r.composite.html
  - add missing option (fixed in CVS HEAD)

fixed

html/html/d.where.html
  - included unavailable 5.3.0 options (not fixed)

fixed

NEWS.html
  - r.sun: NULL data support, much faster <--in HEAD only (proj)
  - What's new in GRASS 5.0.2/CVS comparing to 5.0.1
      --> 5.0.2 comparing to 5.0.1 (not fixed)

fixed

html/html/shade.rel.sh.html
  - html file looks ok, SYNOPSIS section of man page built wrong. (?)

not fixed. Also in CVS HEAD?

src.garden/grass.postgresql
  * Compilation error (not fixed)
     with Debian/Testing's gcc (GCC) 3.3.1 20030626 (Debian prerelease)
     ok with Redhat 9's gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

../../bin.i686-pc-linux-gnu/gmake5 g.column.pg
  SRC = /usr/src/grass5source/grass-5.0.3rc1/src
  CMD = /usr/src/grass5source/grass-5.0.3rc1/src/CMD
  UNUSED = /usr/src/grass5source/grass-5.0.3rc1/unused
  HEADER = head.i686-pc-linux-gnu
  ARCH = i686-pc-linux-gnu
  GISBASE = /usr/src/grass5source/grass-5.0.3rc1/dist.i686-pc-linux-gnu
  VERSION = 5.0.3 August 2003
#################################################################
/usr/src/grass5source/grass-5.0.3rc1/src.garden/grass.postgresql/g.column.pg
  make -f OBJ.i686-pc-linux-gnu/make.rules

make[1]: Entering directory `/usr/src/grass5source/grass-5.0.3rc1/src.garden/grass.postgresql/g.column.pg'
gcc -I/usr/src/grass5source/grass-5.0.3rc1/src/include -O3 -march=i686 -Wall -I/usr/include/postgresql -Wall -DPACKAGE=\""g.column.pg"\" -c main.c -o OBJ.i686-pc-linux-gnu/main.o
main.c:83:30: missing terminating " character
main.c: In function `main':
main.c:84: error: syntax error before "a"
main.c:85: error: stray '\' in program

I have tried to fix that. Could you please test the attached main.c
of g.column.pg?

ps -- can anything be done to get rid of all the
src/include/gis.h:35: warning: `GRASS_copyright' defined but not used
warnings?

It would just need the line 35 in src/include/gis.h commented. As far
as I remember this was left to get "GRASS_copyright" into the binaries.
Mhhh.

Markus

(attachments)

main.c (2.49 KB)

[neteler]

On Sun, Aug 24, 2003 at 06:17:11PM +0200, Stephan Holl wrote:
[...]

*d.barscale:

fixed

*g.column.pg:

See new main.c in my previous mail.

*g.status.pg:

Find attached a new infxStats.c - please try.

[...]

Markus

(attachments)

infxStats.c (2.61 KB)

[Stephan_Holl2]

Hello Markus,

At Mon, 25 Aug 2003 09:59:45 +0200 Markus Neteler wrote:

> *g.column.pg:
See new main.c in my previous mail.

yes, compiles fine with this patch.
as I do not use this command, no tests for functionality are done

> *g.status.pg:

Find attached a new infxStats.c - please try.

compiles fine as well.

NVIZ still fails working with tcl8.4 and wish 8.4

cheers
  Stephan

--
Stephan Holl

GnuPG Key-ID: 11946A09

11:30:43 up 2:13, 1 user, load average: 0.06, 0.04, 0.06

[H_B]

> html/html/shade.rel.sh.html
> - html file looks ok, SYNOPSIS section of man page built wrong.
> (?)

not fixed. Also in CVS HEAD?

Yes, also shade.clr.sh.html, on all 5.0.2, 5.0.3rc1, 5.0.CVS, Redhat
7.3, 9.0, and Debian.

this:
<H2>SYNOPSIS</H2>

<B>shade.rel.sh</B> <BR><B>shade.rel.sh help</B> <BR>

<B>shade.rel.sh</B> [<B>altitude=</B><EM>value</EM>]
[<B>azimuth=</B><EM>value</EM>]
[<B>elevation=</B><EM>name</EM>]

becomes this:
SYNOPSIS
       shade.rel.sh
       shade.rel.sh help shade.rel.sh [altitude=value] [azimuth=value] [eleva- tion=name]

Pretty minor, but I wonder why.

> src.garden/grass.postgresql
> * Compilation error (not fixed)
> with Debian/Testing's gcc (GCC) 3.3.1 20030626 (Debian
> prerelease) ok with Redhat 9's gcc (GCC) 3.2.2 20030222 (Red
> Hat Linux 3.2.2-5)...

I have tried to fix that. Could you please test the attached main.c
of g.column.pg?

Yes, that compiles. I don't use *.pg, so can't test further.

The changed g.stats.pg compiled ok as well.

> ps -- can anything be done to get rid of all the
> src/include/gis.h:35: warning: `GRASS_copyright' defined but not
> used warnings?

It would just need the line 35 in src/include/gis.h commented. As far
as I remember this was left to get "GRASS_copyright" into the
binaries. Mhhh.

Ok, sounds like a good reason to keep it then. Is it bad form to call it
as a no-op in a common library just so it gets used? Call it from the
parser as part of 'x.foo --help' or something? Just an annoyance grepping
through the make log for "warning:", not important.

Hamish