Hamish:
>> > I have just built new gpsdrive packages locally using
>> > "debuild binary" on Etch.
>> >
>> > When I try to start I get this error:
>> > DB: Error while opening /usr/share/icons/map-icons/geoinfo.db:
>> > unable to open database file
>> >
>> > I used to have such a file in
>> > /usr/share/gpsdrive/geoinfo.db, but these new packages do
>> > not include that?
>> >
>> > As I'm on etch, I've build without GDA3, Mapnik, and Speech options.
>> > what am I doing wrong?
>
> You also need to install a recently new version of openstreetmap-icons
Hamish:
> > there is no such package available for Etch,
> >
http://packages.debian.org/search?keywords=openstreetmap> >
> > and debian/control does not depend on
> > openstreetmap-map-icons-classic | openstreetmap-map-icons-scalable |
> > openstreetmap-map-icons-square
(actually it does depend on "openstreetmap-map-icons" which is the
source-package AFAICT, but that is removed by the etch patch)
> > note this was build without support for Mapnik and GDA3 --
> > OSM and POI database isn't used here.
Guenther wrote:
> the poi database is part of gpsdrive, it won't work without.
> so the geoinfo.db and some icons are required for gpsdrive to run.
ok, as a fall-back can we work on a minimal (dozen?) basic icon set like
"x" "o" triangle, etc.? probably the old WLAN etc set from gpsdrive 2.09
would do. hopefully it is very little work, won't need to be maintained,
and well help out a lot of folks.
besides not existing in etch, those openstreetmap-map-icons packages are
2.8 to 3.6mb installed (and that will only grow with time), which is space
I don't want to waste on an embedded install, especially as I don't use
the program in a way that uses more than about two waypoint symbols (+ and
x).
don't misunderstand -- I am glad that we now depend on that package
instead of trying to maintain our own icon set. But I think we need a
minimal 12-icon starter-pack drop-in replacement option too (probably 20k
instead of requiring megabytes).
for now I've symlinked geoinfo.db from an old version of the package and
as long as I don't try to create any waypoints I'm fine.
that version switching exposed another problem: it made dpkg very upset
that the Python-Version was not set and it refused to do anything. In
the end to get it unstuck I had to temporarily move away
/usr/bin/pycentral, run dpkg to reinstall, then move pycentral back into
place. :-/ no fun
possibly related: I notice the new debian/pycompat file lists only 2.5,
but the control file depends on python 2.4.
- could the pycompat file say "2.4, 2.5" (or "current") instead?
Again as Etch can't use Mapnik/OSM, and only python2.4 is available there,
I don't think we need python at all there so can rip it out in the etch
patch set.
fwiw, I care to keep 2.10rc1 etch-compatible for a couple reasons:
- avoid developer monoculture
- if we can't get it to build on debian(-1), what hope is there for
the mac osx/fink version etc to work?
- often the choice of distro is somewhat out of the user's hands, or
they have important reasons to stay with an older OS that has nothing
to do with gps.
- we shouldn't force people into the constant upgrade-mill.
In fact I'm waiting for us to release before I upgrade my dev machine
to lenny so I can catch these backwards incompatibilities.
thanks,
Hamish
_______________________________________________
GPSdrive mailing list
GPSdrive@...
http://lists.gpsdrivers.org/mailman/listinfo/gpsdrive