Paolo Cavallini wrote:
Thanks to the enlightenments from guru Frankie (Lovergine), I have
been debugging gpstrans, which is constantly crashing for us:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399828
hopefully I'll get my hands on one of our garmins in the next days to
begin some testing with gpstrans ver 0.40. (it's prime field season
here, so no promises of quick access)
Reproducing your bug & confirming the graveness or non-graveness of
debian bug #399828 is a high priority for me as I am very interested in
Etch being released with a working gpstrans package.
My conclusions are:
- - gpstrans has serious problems (it does not check the input, and
thus crashes easily when encountering unexpected, but valid, strings)
yes, it has always been fragile, but I wouldn't call them serious
problems. If run with correct inputs it works fine (ver 0.39), and when
used from within a script (like v.in.garmin) the inputs are always
given in the correct form. It would be nice to have it be a bit more
robust but I'm not going to spend much time worrying about someone
mispelling /dev/ttyS0 as "com1" etc.
- - it does not seem actively maintained anymore
AFAICT James Van Zandt (the debian package maintainer) became the
de-facto upstream maintainer and released a new version (0.40) in May
2006. The latest date in the ChangeLog for that release is listed as
2006-05-08 with several new development updates. (presumably the cause
of your instability).
- - it does not support many modern devices
It's a tool for serial garmins, and with those devices it works quite
well. The new version purportedly will handle new devices, but as I
don't have any of those on hand 
I can't really comment on that.
gpstrans (0.40-1) unstable; urgency=low
* New upstream release: understands most (all?) Garmin formats
- - we have valid backend replacements, of which the best seems
gpsbabel
sure. redundancy is good.
I would therefore suggest replacing v.in.garmin with v.in.gpsbabel.
"-1"
Of course we could keep the two, but having two commands doing the
same thing is confusing for the users, and let the devs waste their
time maintaining the two.
I prefer to use v.in.garmin, and will actively maintain it as long as we
need it in our work, and do not consider that wasted time (also because
I feel some responsibility having written or rewritten much of it). At
the same time I will leave any v.in.gpsbabel development to the module's
authors, beyond simple/obvious fixes (mostly because I am not actively
using it).
ie here at my work we have a working solution with v.in.garmin and I
see no need to spend valuable time/effort converting to something else.
Also v.in.garmin (and gpstrans) is mature, v.in.gpsbabel is not (yet):
I think v.in.gpsbabel needs some care, possibly tweaking etc., but
being a script this should be easy and quick.
Yes, I think it will be very nice after a little more tweaking and
testing, but there is still some work to be done. I have trouble testing
it further due to a firmware bug in all our Garmins (timestamps shift
off-by-one after the memory wraps, ie between downloads if unit is
permanently logging; no response from the company) so I am never sure
exactly what is the script going wrong and what is broken input.
regards,
Hamish