Re: ✘ Release blockers?

[Greg Troxel]

"Gary E. Miller" <address@hidden> writes:

> Yo All!
>
> I know we are all distracted by the holidays, but hopefully also a good
> time for a lot of testing.
>
> Last I knew, it seemed like the main, possibly blocking, issue is the
> occasional gpsfake errors.  Recent patches have pretty much eliminated
> that for me.  Is this issue under control enough for a release?
>
> Any other last minute blockers?

I am testing commit 445000975cf43525ca8a437ab652e29a84a049e0.

BLUF: I'm fine with releasing this commit as 3.(N+1).


On NetBSD-8/amd64, it builds and passes tests.

With the tarball created by scons dist, I built a not-yet-committed
updated pgksrc package, and the tests pass.

Livetesting the pkgsrc package from the above SHA1, with a ublox 8:
  basically works, xgps works, ntpd non-pps works.
  ubxtool turned off GLONASS successfully
  ubxtool enabled GALILEO successfully
  gpspipe -w and gpsprof -r work

  cgps does not seem to work (displays but gets no data after the
  VERSION object), but I had some build funniness in pgksrc finding
  curses.  (I'm not worried about this for release.)

  In xgps I see uN for used on one GLONASS satellite (SVID4/PRN68) and
  one GPS satellite (PRN4).  This is new and the man page doesn't
  explain.  They were being tracked at decent SNR, vs the other N ones
  that aren't being tracked.  I see on galmon.eu that G04 (GPS PRN 4) as
  they call it is "NOT OK" for health.  And R04 is also NOT OK for
  health.  So this gpsd/xgps reporting great to see.  Both G04 and R04
  both being not healthy at once is curious.

  I saw QZ 1 on xpgs, but with no elevation.  I'm not near .ja so the
  idea that it's above the horizon seems off :-)

Minor things for later (I believe these are all not new, and don't mean
to suggest they hold up the release - just things to look into at some
point).  (Just listing them stream of consciousness as I test.)

  I am seeing an error on startup (even as root):
    gpsd:ERROR: shmget(0x47505344, 24024, 0666) for SHM export failed: Invalid 
argument
  Despite this, I am seeing time in ntpd via SHM (not pps, with an ublox
  M8030 without pps wired) that is within 30 ms.

  
  I diffed the build output without and with pkgsrc.  I was not aware
  that C11 is checked for, not sure why this is happening, and not sure
  whether it makes any difference.  pkgsrc hides C11 if it is not
  declared as a used language, and C11 vs C99 surprises me for gpsd
  given portability goals.

    -Checking if compiler is C11... (cached) no
    -Checking for C header file libkern/OSAtomic.h... (cached) no
    -No memory barriers - SHM export and time hinting may not be reliable.
    +Checking if compiler is C11... (cached) yes
    +Checking if compiler supplies __STDC_NO_ATOMICS__... (cached) no
    +Checking for C header file stdatomic.h... (cached) yes

  I think it's a bug that xgps default to imperial units.  Recently I
  saw someone in a normal context post GPS error estimates in feet (as
  part of a "why doesn't my phone nav work" discussion) and I was really
  surprised that anybody would do that for a moment.  ECEF in feet is
  even more comical, since I would expect that everyone who understands
  what that means prefers meters.  But seriously, for the nerd audience,
  do enough people really want imperial units to have that as the
  default?