Opened 11 years ago
Closed 10 years ago
#1300 closed defect (fixed)
upgrade of postgis/mapnik broke gpsdrive
Reported by: | hamish | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | OSGeoLive7.9 |
Component: | OSGeoLive | Keywords: | mapnik, postgis, gpsdrive |
Cc: |
Description
Hi,
gpsdrive doesn't start because legacy_minimal.sql called from load_postgis.sh failed to load because it doesn't exist anymore on the disc.
see also
https://bugs.debian.org/699079 https://groups.google.com/forum/#!topic/mapnik/e9xO1JiqFv4
is it valid to copy in the old version of legacy.sql from the 7.0 disc?
Also I notice that the python-mapnik package (2.2) isn't installed, but the python-mapnik2 (2.0) version is. Is that intentional? Libraries for both versions are installed (which is fine).
postgis is version 2.1.1. postgresq is mostly version 9.3.2.
thanks, Hamish
Change history (6)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Hopefully fixed with r11103. Kosmo and gvSIG likely also were affected by this.
Hamish
comment:5 by , 10 years ago
apparently the copy of legacy*.sql from gisvm/app-conf/ in load_gisdata.sh failed; should be an easy fix.
Hamish
Hi,
in the 7.0 live disc legacy.sql and legacy_minimal.sql were provided by the postgresql-9.1-postgis-2.0-scripts package and located in /usr/share/postgresql/9.3/contrib/postgis-2.1/
note that it's not just the osm_local DB, load_gisdata.sh is also trying to load it for the natural_earth2 DB.
I committed the ST_ api updates for gpsdrive back in January, maybe it just needs a rebuild?
anyway, copying in legacy_minimal.sql from the 7.0 live disc and changing paths from 2.0 to 2.1 in the .sql file works if all else fails.
Hamish