gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ✘ Release blockers?


From: Gary E. Miller
Subject: Re: ✘ Release blockers?
Date: Tue, 31 Dec 2019 12:43:43 -0800

Yo Greg!

On Tue, 31 Dec 2019 15:22:35 -0500
Greg Troxel <address@hidden> wrote:

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

Thanks for testing!  I guess we are all GO now.

>   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.

Yeah, the doc is a bit behind.  Those two sats are new and not yet
cleared for service.  So they broadcast an ephmeris with the "unhealthy"
bit set, until they are deemed ready for everyone to use.

The cgps and xgps code to show the "u" was a rush fix when  all the
GALILEO birds went dumb.


> 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.)

A good list.  We'll need it soon, after the release.

>   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.

gpsd can open up to 4 SHMs. Not the SHM number (0x47505344) can be decoded
as ASCII: GPS4.  Since you run as root you are likely using GPS0 and GPS1.

I'm not even sure why gpsd would ever try to open GPS4.

>   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.

Nah, it is a perm error.

>  pkgsrc hides C11 if it is not
>   declared as a used language, and C11 vs C99 surprises me for gpsd
>   given portability goals.

Are you saying (basic) gpsd needs C11?  I know a lot of the stuff like
the Qt stuff needs C11 (out of our control).

>     -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

Odd.  Worth looking at later.

>   I think it's a bug that xgps default to imperial units.

Unless you live in the USA.  This can be changed with the (undocumented)
XGPSOPTS environment variable.  I guess it could be a build time option.


>  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.

They must not live in the USA.

>  ECEF in
> feet is even more comical, since I would expect that everyone who
> understands what that means prefers meters.

Worse yet, the ECEF units are not quite consistent with the others as
the options change.

>  But seriously, for the
> nerd audience, do enough people really want imperial units to have
> that as the default?

I would hope the non-nerd audience is bigger than the nerd one.

Unix is choice, just set XGPSOPTS.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpMPvkF8VSFX.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]