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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]