[TangerineSDR] [EXTERNAL] Magnetometer/Grape Raspberry Pi Image

[Rob Wiesler]

On Mon, Nov 01, 2021 at 14:49:24 -0400, Jonathan via TangerineSDR wrote:
> The bug I linked to did affect the running code. Gary provided me that
> link, even though he mentions regressions.

Okay, I'm sorry, I misparsed that bug report.  Very embarrasing. :{

>                                            At that time, the bug could
> not be tested unless it was simulated. Now, the bug did actually
> surface on both my FreeBSD system (with a traditional RTC) and my Pi
> (without an RTC). Upgrading fixed the issue.

Right.  The part I missed was that the buggy code in question was only
intended for the simulation path, but affected the live path anyway.
And here I was wondering what people were so worked up about when this
made the rounds back in August ...

>                                              My issue did not arise
> from the use (or misuse) of “tinker panic 0”. I understand that not
> having an RTC is not an ideal situation, but it’s the best option
> without having an RTC. In production, the Pi will always be on an
> experience momentary reboots.

I still disagree that "tinker panic 0" is even worth considering as an
option.  As I've said, the only acceptable use of that option that I've
heard of is in situations where the system resumes from suspend and sees
the remote timeserver's time jump, and even then I suspect there's a
better option (e.g. NTP detecting the resume event).  If you need to fix
the system time on boot, make sure ntp starts with the -g option.  With
the Debian package (at least on bullseye), this is done by default in
/etc/default/ntp .

Disabling panic means, among other things, that remote servers can
arbitrarily mess with your system time much more easily.  Also, while
allowing the system time to step backwards at boot time is bad enough,
allowing the system time to step backwards at unpredictable times after
that is much worse.

> I suppose this is where some feel that new releases should go in the
> "unstable" repository,

"Feel", nothing.  This is an integral part of how Debian works.

>                        and I agree, but in the case of gpsd, a lot of
> updates and bug fixes are missed, and you have to use the
> self-compiled version for those updates and bug fixes.

Updates are intentionally missed if they are not bug fixes and are not
required for backporting bug fixes.  Bug fixes are backported.  If they
are not, please file a bug against your distribution's gpsd package.
Sometimes breakages do happen, and backports aren't applied correctly,
or prerequisite patches are missed and not cherry-picked.  These are
things to file bug reports about, not reasons to abandon the packaged
version entirely.

I find that even if you need to switch to a custom or "future" version,
it's often best to build up a custom version of your distribution's
package containing the fixes or updates required.  This means that (a)
you have work that you can send to the package maintainer to make their
job easier, (b) there's only one copy of the package on your system,
which eliminates a broad category of problems, (c) your package manager
will upgrade you to any new release from your distribution once your fix
is upstreamed or the new release is packaged, and (d) you keep
distribution-specific patches and configuration with minimal extra
effort.  Even it it turns out to be more work, that usually reveals
incompatibilities between the new version and the rest of your system.

>                                                        In my case,
> that wasn’t necessary, but it was when I originally compiled it
> because Gary updated the TSIP driver so the RES SMT 360 would work
> with it.

If that hardware is still unsupported in the version of gpsd that Bill
is/was using on the device in question, then I apologize for jumping on
you while missing vital context, but otherwise it's still bad advice to
tell someone to compile from source before even checking for in-distro
fixes.  Even if he were using buster still (which ships gpsd 3.17), the
right answer would be to enable buster-backports to get the new features
in 3.22 (which, as I said, was updated to include the fix for this bug
even before 3.23 was released upstream).