[GRASS5] grass 5.0.3 in debian

neteler · January 12, 2004, 8:37am

FYI,
the GRASS 5.0.3 package has been submitted to debian.

Hope that it's visible soon.

Markus

On Wed, Jan 07, 2004 at 04:19:10PM +0100, Federico Di Gregorio wrote:

btw, grass 5.0.3 has been uploaded to debian.org; the package grass-doc
is new so it will take a little bit to get processed. there are still
bugs (like the missing manpages) but the new build scripts make
maintenance much easier. bugs will be fixed soon.

federico

--
Federico Di Gregorio http://people.initd.org/fog
Debian GNU/Linux Developer fog@debian.org
INIT.D Developer fog@initd.org
99.99999999999999999999% still isn't 100% but sometimes suffice. -- Me

H_B · January 13, 2004, 6:13am

[Hi everyone, happy New Year]

the GRASS 5.0.3 package has been submitted to debian.

Great! This'll make the Knoppix based distros really easy to put together as
well.

A couple of points about the new Debian package..
(mostly from looking at the Debian.ChangeLog & package page, I haven't
tested or even inspected the package so I could be mistaken on some of
these...)

- what happened to all the dependencies? they all seem to be missing.
e.g., look at
  http://packages.debian.org/testing/science/grass
   vs
  http://packages.debian.org/unstable/science/grass
?

- add a dependency to the new gdal-bin package and build --with-gdal ?
This is in testing now.

- DBM patch & deps not needed as GRASS doesn't actually use DBM.
Build without.

Added build-deps in control file:
+ libgdbm-dev for --with-dbm

- after changing to tcl/tk 8.4, does NVIZ still work??? could someone check?

Build against tcl/tk 8.4 (Closes: #206844).

for possible fix, see
http://article.gmane.org/gmane.comp.gis.grass.devel/2036/
??
maybe fixed in the latest tcl/tk packages?

- The unstable package page (see above) says the package is 34mb,
Size: 34619.9
Installed size: 84920
Is it possible to build 5.0.3 with shared libs or is that 5.3+ only?

- What's with avoiding the freetype check? I've never had a problem with
the standard Debian version of freetype2..

Include dir for freetype2 is /usr/include/freetype2/freetype
+ debian/rules

With Debian I've always used:
./configure --with-freetype --with-freetype-includes=/usr/include/freetype2
?

cheers,
Hamish

Glynn_Clements · January 13, 2004, 6:38am

Hamish wrote:

- The unstable package page (see above) says the package is 34mb,
Size: 34619.9
Installed size: 84920
Is it possible to build 5.0.3 with shared libs or is that 5.3+ only?

It's possible, but not officially supported. I wouldn't recommend it
for building distributions (except for e.g. iPAQ where the space
saving is a necessity).

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

H_B · January 13, 2004, 7:40am

> - The unstable package page (see above) says the package is 34mb,
> Size: 34619.9
> Installed size: 84920
> Is it possible to build 5.0.3 with shared libs or is that 5.3+ only?

It's possible, but not officially supported. I wouldn't recommend it
for building distributions (except for e.g. iPAQ where the space
saving is a necessity).

Note the Debian ARM build is probably the easiest way to install GRASS
on an iPAQ..

Still, I'd agree that for the Debian package stability is the most
important issue.

Hamish

Francesco_P_Lovergi2 · January 13, 2004, 9:54am

On Tue, Jan 13, 2004 at 07:13:50PM +1300, Hamish wrote:

[Hi everyone, happy New Year]

> the GRASS 5.0.3 package has been submitted to debian.

Great! This'll make the Knoppix based distros really easy to put together as
well.

A couple of points about the new Debian package..
(mostly from looking at the Debian.ChangeLog & package page, I haven't
  tested or even inspected the package so I could be mistaken on some of
  these...)

- what happened to all the dependencies? they all seem to be missing.
e.g., look at
  http://packages.debian.org/testing/science/grass
   vs
  http://packages.debian.org/unstable/science/grass
?

Federico, dh_shlibdeps is missing in rules :-/
We need to re-release ASAP...

- add a dependency to the new gdal-bin package and build --with-gdal ?
This is in testing now.

We could consider this I think.

- DBM patch & deps not needed as GRASS doesn't actually use DBM.
Build without.
> Added build-deps in control file:
> + libgdbm-dev for --with-dbm

This is GDBM, not DBM. Ok, due for next release.

- after changing to tcl/tk 8.4, does NVIZ still work??? could someone check?
> Build against tcl/tk 8.4 (Closes: #206844).
for possible fix, see
http://article.gmane.org/gmane.comp.gis.grass.devel/2036/
??
maybe fixed in the latest tcl/tk packages?

To be verified.

- What's with avoiding the freetype check? I've never had a problem with
the standard Debian version of freetype2..
> Include dir for freetype2 is /usr/include/freetype2/freetype
> + debian/rules
With Debian I've always used:
./configure --with-freetype --with-freetype-includes=/usr/include/freetype2
?

You have to use the _current_ sid package for libfreetype6-dev (2.1.7-1.1) to see the
problem. In /usr/include/freetype2/freetype/freetype.h:

#ifndef FT_FREETYPE_H
#error "`ft2build.h' hasn't been included yet!"
#error "Please always use macros to include FreeType header files."
#error "Example:"
#error " #include <ft2build.h>"
#error " #include FT_FREETYPE_H"
#endif

this causes a configure test error and requires changes in a couple of files.

--
Francesco P. Lovergine

H_B · January 22, 2004, 7:12am

> > the GRASS 5.0.3 package has been submitted to debian.
>

...

> A couple of points about the new Debian package..

[I just installed it on a fresh machine]

...

> - add a dependency to the new gdal-bin package and build --with-gdal
> ? This is in testing now.
>

We could consider this I think.

Upon closer inspection that package only provides the executables
(gdalinfo, ogr2ogr, etc). It would need to depend on libgdal1, build
with libgdal1-dev, and I guess suggest gdal-bin.

It builds ok using libgdal1-dev, which looks like a CVS snapshot from
November. Didn't try actually importing anything though.

> - after changing to tcl/tk 8.4, does NVIZ still work??? could
> someone check?
> > Build against tcl/tk 8.4 (Closes: #206844).
> for possible fix, see
> http://article.gmane.org/gmane.comp.gis.grass.devel/2036/
> ??
> maybe fixed in the latest tcl/tk packages?
>

To be verified.

Nope, it doesn't work here.. same segfault.
Putting -lpthreads in
src.contrib/GMSL/NVIZ2.2/src/Gmakefile 's XTRA_LDFLAGS
doesn't fix it anymore either. Maybe somewhere else?

Compiling against Tcl/Tk 8.3 does work however.

regards,
Hamish

Glynn_Clements · January 22, 2004, 10:04am

Hamish wrote:

> > > the GRASS 5.0.3 package has been submitted to debian.
> >
...
> > A couple of points about the new Debian package..

[I just installed it on a fresh machine]

> > - after changing to tcl/tk 8.4, does NVIZ still work??? could
> > someone check?
> > > Build against tcl/tk 8.4 (Closes: #206844).
> > for possible fix, see
> > http://article.gmane.org/gmane.comp.gis.grass.devel/2036/
> > ??
> > maybe fixed in the latest tcl/tk packages?
> >
>
> To be verified.

Nope, it doesn't work here.. same segfault.
Putting -lpthreads in
src.contrib/GMSL/NVIZ2.2/src/Gmakefile 's XTRA_LDFLAGS
doesn't fix it anymore either. Maybe somewhere else?

Compiling against Tcl/Tk 8.3 does work however.

Do you have both 8.3 and 8.4 on the same machine? If so, are you sure
that the headers, the link-time libraries and the run-time libraries
are all the same version?

FWIW, does Debian include the version number (e.g. libtk8.3.so) or
does it use libtk.so.0?

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

Stephen_Clark1 · January 22, 2004, 4:29pm

Hello,

Is there anyone that has tried to script GRASS to do shortest route analysis on windows 2000 and then display the results on Mapserver version 4.0.

thanks
Stephen

Radim_Blazek · January 22, 2004, 4:17pm

On Thursday 22 January 2004 17:29, Stephen Clark wrote:

Hello,

Is there anyone that has tried to script GRASS to do shortest route
analysis on windows 2000 and then display the results on Mapserver version
4.0.

Yes, i have made such system, it works, but as it is so awful that
I must write GRASS Server, which responds queries send by client
via TCP/IP. Client is PHP module, using C library. Here is a part of
PHP example code which gets shortest path and draws it on the map:

$gserver = new grass_server();
$sp = new grass_points();
$ret = grass_shortest_path_coor($gserver, "road", $x1, $y1, $x2, $y2, &$costs, &$sp);

$spLine = ms_newLineObj();
for ( $i = 0; $i < $spPoints->n; $i++ ) {
$spLine->addXY( $spPoints->x[$i], $spPoints->y[$i]);
}
$spShape = ms_newShapeObj (MS_SHAPE_LINE);
$spShape->add($spLine);
$spLayer = $map->getLayerByName('sp');
$spShape->draw($map, $spLayer, $img);

GRASS Server already works, but it is not yet on the web, because it is
not finished. Anyway, on windows, some small changes will be necessary,
because sockets are bit different on unix and windows, I think.
Client needs nothing from GRASS package, so it should be possible to use
it without Cygwin, for example GRASS Server on Linux + Mapserver
on Windows.

Radim

H_B · January 27, 2004, 11:04am

> > > > the GRASS 5.0.3 package has been submitted to debian.

And it is now in Debian/testing and slated for the next Debian release!
Congratulations and thanks to Federico and Francesco!

"apt-get install grass"

> > > A couple of points about the new Debian package..
> [I just installed it on a fresh machine]

> > > - after changing to tcl/tk 8.4, does NVIZ still work??? could
> > > someone check?
> > > > Build against tcl/tk 8.4 (Closes: #206844).
> > > for possible fix, see
> > > http://article.gmane.org/gmane.comp.gis.grass.devel/2036/
> > > ??
> > > maybe fixed in the latest tcl/tk packages?
> >
> > To be verified.
>
> Nope, it doesn't work here.. same segfault.
> Putting -lpthreads in
> src.contrib/GMSL/NVIZ2.2/src/Gmakefile 's XTRA_LDFLAGS
> doesn't fix it anymore either. Maybe somewhere else?
>

> Compiling against Tcl/Tk 8.3 does work however.

Do you have both 8.3 and 8.4 on the same machine? If so, are you sure
that the headers, the link-time libraries and the run-time libraries
are all the same version?

I think I started out with only 8.4, but don't trust that.

Currently, I have the following installed:
tcl8.3 install
tcl8.3-dev install
tcl8.4 install
tcl8.4-dev install
tk8.3 install
tk8.3-dev install
tk8.4

tk8.3-dev conflicts with tk8.4-dev so the latter is removed.
GRASS compiles and NVIZ works.

After removing *8.3* packages from the system, the grass.deb package
still fails.

I'll have to check on which 'wish' is used, but I wouldn't think this
is accessed during building? And removing 'tk8.3' should fix it then,
but doesn't.

[then, after installing tk8.4-dev]
Building 5.0.3 from source, GRASS builds ok and NVIZ still fails.
Building 5.3-cvs from source, GRASS builds ok and NVIZ still fails.

FWIW, does Debian include the version number (e.g. libtk8.3.so) or
does it use libtk.so.0?

Everything is versioned. The file 'libtk.so.0' doesn't exist in the
Debian archive- not sure if that covers symlinks though.

/usr/lib/libtcl8.4.a
/usr/lib/libtcl8.4.so@ -> libtcl8.4.so.0
/usr/lib/libtcl8.4.so.0
/usr/lib/libtclstub8.4.a
/usr/lib/tcl8.4/[many]
/usr/include/tcl8.4/[many]

/usr/lib/libtk8.4.a
/usr/lib/libtk8.4.so@ -> libtk8.4.so.0
/usr/lib/libtk8.4.so.0
/usr/lib/libtkstub8.4.a
/usr/lib/tk8.4/[many]

/usr/bin/wish8.4
/usr/bin/wish@ -> /etc/alternatives/wish@ -> /usr/bin/wish8.4

(8.3 is along the same lines)

good idea though.

Hamish

Glynn_Clements · January 27, 2004, 1:39pm

Hamish wrote:

After removing *8.3* packages from the system, the grass.deb package
still fails.

I'll have to check on which 'wish' is used, but I wouldn't think this
is accessed during building?

No. "wish" isn't used by NVIZ in any way. However, the "nviz" script
itself uses tclsh (I strongly suggest replacing that with a Bourne
shell script; a simple "Segmentation fault" message is a lot less
confusing than the current 3-level Tcl backtrace).

And removing 'tk8.3' should fix it then, but doesn't.

[then, after installing tk8.4-dev]
Building 5.0.3 from source, GRASS builds ok and NVIZ still fails.
Building 5.3-cvs from source, GRASS builds ok and NVIZ still fails.

This is with no Tcl or Tk 8.3 files on the system, right?

Do the tkInt.h and tkIntDecls.h files from Debian's Tk 8.4 source code
match the tkInt8.4.h and tkIntDecls8.4.h files included in
NVIZ2.2/src?

Note: those files probably won't be included in any binary package;
that's why NVIZ includes copies. But NVIZ' copies *must* match the Tk
library which it uses.

Has anyone tried debugging this?

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

Federico_Di_Gregorio · January 27, 2004, 9:38pm

Il mar, 2004-01-27 alle 14:39, Glynn Clements ha scritto:
[snip]

Do the tkInt.h and tkIntDecls.h files from Debian's Tk 8.4 source code
match the tkInt8.4.h and tkIntDecls8.4.h files included in
NVIZ2.2/src?

Note: those files probably won't be included in any binary package;
that's why NVIZ includes copies. But NVIZ' copies *must* match the Tk
library which it uses.

argh. this is evil. any well-done package should include all needed
header files as debian does in /usr/include/tcl8.4/tk-private/. anyway,
a diff does not report anything usefull (no real differences.)

should we revert to 8.3?

federico

--
Federico Di Gregorio http://people.initd.org/fog
Debian GNU/Linux Developer fog@debian.org
INIT.D Developer fog@initd.org
The devil speaks truth much oftener than he's deemed.
He has an ignorant audience. -- Byron (suggested by Alice Fontana)

Glynn_Clements · January 28, 2004, 11:28am

Federico Di Gregorio wrote:

Il mar, 2004-01-27 alle 14:39, Glynn Clements ha scritto:
[snip]
> Do the tkInt.h and tkIntDecls.h files from Debian's Tk 8.4 source code
> match the tkInt8.4.h and tkIntDecls8.4.h files included in
> NVIZ2.2/src?
>
> Note: those files probably won't be included in any binary package;
> that's why NVIZ includes copies. But NVIZ' copies *must* match the Tk
> library which it uses.

argh. this is evil. any well-done package should include all needed
header files as debian does in /usr/include/tcl8.4/tk-private/.

Unfortunately, not including tkInt.h etc appears to be standard
practice; probably because they aren't required unless you are
creating your own widget classes.

Those headers aren't installed by Tk's "make install", and aren't
included in most vendors' binary packages. So, GRASS has to include
the tkInt.h and tkIntDecls.h files for the various Tk versions.

anyway, a diff does not report anything usefull (no real
differences.)

That's one possibility eliminated.

Has anything changed between 8.3 and 8.4 which would affect code which
creates new widget classes?

should we revert to 8.3?

Tk 8.4 isn't going to go away, so NVIZ/Togl will have to deal with the
issues eventually.

Another line of approach would be to check whether the original Togl
code has had any changes for Tk 8.4.

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

H_B · January 29, 2004, 11:56pm

> anyway, a diff does not report anything usefull (no real
> differences.)

That's one possibility eliminated.

Has anything changed between 8.3 and 8.4 which would affect code which
creates new widget classes?

? Big 8.4 change I was aware of was the intoduction of threads & 64bit
support, which likely exposes subtle bugs that were previously sleeping
in the NVIZ code ??

> should we revert to 8.3?

Tk 8.4 isn't going to go away, so NVIZ/Togl will have to deal with the
issues eventually.

Yes, but for the next Debian release there needs to be a working
package.

My suggestion would be to build a working package against 8.3, get that
into /testing, then rebuild with 8.4, upload to /unstable and file a
bug against it so the broken version doesn't get into testing(->stable).
I'd think that at this point Debian/Sarge is closer to release than
GRASS 5.0.4 or 5.3.0? (I mean by that I think Debian will release
sooner, not GRASS dragging on)

As it is only seen with Debian so far (??) it should be sorted out in
the Debian BTS by people familiar with Debian's TclTk.

Another line of approach would be to check whether the original Togl
code has had any changes for Tk 8.4.

I ran it through the debugger a while back, but don't have the energy to
do that right now, maybe it would help.

Hamish

Glynn_Clements · January 30, 2004, 1:28pm

Hamish wrote:

> > anyway, a diff does not report anything usefull (no real
> > differences.)
>
> That's one possibility eliminated.
>
> Has anything changed between 8.3 and 8.4 which would affect code which
> creates new widget classes?

? Big 8.4 change I was aware of was the intoduction of threads & 64bit
support, which likely exposes subtle bugs that were previously sleeping
in the NVIZ code ??

Are you referring just to making Tcl/Tk thread-safe, or does it
actually use multiple threads automatically? If it's the latter, then
NVIZ may not work with 8.4 for the foreseeable future.

If it's the former, maybe NVIZ needs to be compiled with -D_REENTRANT?

I doubt that 64-bit support will be an issue, given that the problems
are occurring on x86.

> Another line of approach would be to check whether the original Togl
> code has had any changes for Tk 8.4.

I checked that; Togl hasn't been updated for 8.4.

I ran it through the debugger a while back, but don't have the energy to
do that right now, maybe it would help.

Just getting a backtrace at the point the segfault occurs might
provide useful information. Anything beyond that might be a
significant amount of work (and may require Tcl/Tk libs which were
built for debugging, i.e. with -g and without -O).

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