[Live-demo] Re: grass and gps-drive

[Hamish]

Stefan wrote:
> I tried you install_grass.sh and got following error:
> 
> 2009-09-03 01:20:41
> URL:http://grass.osgeo.org/sampledata/spearfish_grass60data-0.3.tar.gz
> [21303045/21303045] ->
> "spearfish_grass60data-0.3.tar.gz.5" [1]
> 
> gzip: stdin: unexpected end of file
> tar: Unexpected EOF in archive
> tar: Unexpected EOF in archive
> tar: Error is not recoverable: exiting now

it is trying to un-tar(.gz) a partially downloaded file.

notice the output name:
  "spearfish_grass60data-0.3.tar.gz.5"
 
if the file already exists, and if you haven't used the -c flag, wget
downloads to a new file but adds a .1,.2,.3,... to the end of it.

I hadn't fully accounted for the script to be re-run, although it
should have cleaned up after itself if wget failed; I've now updated
it in SVN to download to a /tmp dir instead instead of
/usr/local/share/grass/. The rest of it should be safe to run multiple
times, even if it gives some errors about stuff already existing.


> Also the gps_drives-script exits with this message:
> 
> Package libcurl3-openssl-dev is a virtual package provided
> by:
>   libcurl4-openssl-dev 7.18.2-8ubuntu4.1
> You should explicitly select one to install.
> E: Package libcurl3-openssl-dev has no installation
> candidate

the debian/control file includes this list for build-depends:

libcurl4-gnutls-dev | libcurl4-openssl-dev | libcurl3-openssl-dev,

it needs any one of those packages, and it will try them in
order.
according to:  http://packages.ubuntu.com/libcurl4-openssl-dev

it should be available, I guess try editing the debian/control
file in the source dir to replace the "| libcurl3-openssl-dev,"
with just ",". But really it should try the first package in
the "a OR b OR c," first. I'm surprised it doesn't, or perhaps
something else has gone wrong.

I am working on Debian, most things are the same as Ubuntu but
some package names have changed.. but there is an automatic
build system which tests out these things so typically
incompatibilities are quickly caught.
  http://www.gpsdrive.de/build_cluster/results.shtml


> dpkg-checkbuilddeps: Unmet build dependencies: cmake
....
> speech-dispatcher (>= 0.6.6)
> debuild: fatal error at line 1293:
> You do not appear to have all build dependencies properly
> met.

cmake is the first thing on the control file's build-depends
list. Not much will happen without it!

That error comes from the "debuild binary" line. Earlier in
the script it runs "dpkg-checkbuilddeps" outside of that
and parses the output to install any missing packages.
(look for "$NEEDED_BUILD_PKG")

I've just added some more echos in it to help with debugging.

can you try running this from the
 /tmp/build_gpsdrive/gpsdrive-2.10pre7/ dir:

dpkg-checkbuilddeps 2>&1 | cut -f3 -d: | \
    sed -e 's/([^)]*)//g' -e 's/| [^ ]*//'

maybe the output is different in ubuntu and I need to adjust the
regex.

if that returns nothing or garbage, what does dpkg-checkbuilddeps
by itself return? (exact cut & paste into an attachment is
best)

> If you have the pbuilder package installed, you can run
> /usr/lib/pbuilder/pbuilder-satisfydepends as root to
> install the

maybe pbuilder-satisfydepends is more robust than my custom
parsing trick; it should already be installed with the pbuilder
package by gisvm/bin/setup.sh. But I like to do it ourselves
so that we have a list of build -dev packages we can remove
after the build is done, so they don't waste space on the disc.

> Do you know what could be wrong? Maybe I have to configure
> some additional stuff before I can run the scripts? Couldn't
> figure it out myself... :'(

probably just bugs and bad assumptions from my end, as mentioned
I haven't actually tried them on Ubuntu, the scripts are mostly
just "written by ear". :)

but the grass problem is the wget cruft, and with the output
of dpkg-checkbuilddeps I can give a suggestion about that.

I'll update the gpsdrive tileset sometime soon with SYD street
maps. After much crunching with `pngcrush` I've decided to go
with 85% quality JPEGs. I feel that PNGs should produce smaller
files than JPEGs for Mapnik line art, and I've gotten the PNG
file sizes down about 50-60%, but still doesn't compete with
JPEGs. Just a little more python hacking required before
upload....


best,
Hamish