Re: ✘ Release blockers?

[Greg Troxel]

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

> Yo Greg!
>
>>   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.

Sounds good, and easy to fix the man page post-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.

Agreed, but should be easy to figure out.

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

No, I am not saying gpsd needs C11.  What I am saying is that pkgsrc
requires that each package declare what languages the package needs as
well as what packages it depends on and then pkgsrc by various
complicated means manages to hide language implementations and installed
packages that were NOT declared, so that attempts to use them in the
build fails, as part of the path to repeatable builds.

So what I don't get is that if gpsd does not need C11, then why is the
configure checking for it?

Now, if qt *headers* need C11, and the gpsd build scripts are going to
use qt, then maybe they need to look for C11 first.  But if qt the
*implementation* needs c11, but the headers are c99, then gpsd doesn't
need to.

I realize I/pkgsrc are being more pedantic about this than others.  But
still it feels like it would be good to reduce confusion.

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

Even if you live in the US, or Liberia.  While imperial units are used
by many, it seems that anything vaguely scientific uses metric.  In the
US, liquor is metric, drugs and car parts.  More importantly, a number
of states, perhaps most now, use meters in state plane coordinates, and
NGS is thoroughly metric.  The WGS84 specification is in metric.  So I
find it bizarre to have a non-metric default, and I really don't
understand who actually would like that.

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

They do.  My point is that I am so used to thinking about geo/GPS stuff
in metric, that even though this person was in the US (Massachusetts
even), it seemed downright strange to me that any UI would show things
like error estimates in feet.  Distance to next turn in miles or feet -
not so strange, as I realize other people do that..  But the nerdier
things like error estimates - I was genuinely so surprised that I almost
wrote to them and said "really?  does your device really show error
estimates in feet?" until I realized that yes, it surely did.

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

I don't follow.  They are feet for imperial/nautical and meters for
metric.

But are they US Survey Feet or International Feet?  Not that important,
as the US Survey Feet unit is being discontinued and International Feet
will be just called Feet, at 0.3048m.  (Did you realize that a "statute
mile" is 3mm longer than a "mile"?, and that rods and chains are based
on survey feet, not international feet?)

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

In terms of all the people that use gpsd, I really cannot believe that a
majority would prefe imperial units.  I would think it's at least 9:1
metric, if not higher.  My logic is that everyone who isn't in the US,
Liberia or Burma prefers metric, and that more than half of US people
that play with GPS want metric too.

> Unix is choice, just set XGPSOPTS.

<intentionally inflammatory just for fun>
Sure, but that can also be said for those who want Fred Flintstone units.
  Obligatory wikipedia reference: 
https://en.wikipedia.org/wiki/Fred_Flintstone_Units
</>