Re: ✘gpsd .23.2~rc1

[Fred Wright]

On Thu, 7 Apr 2022, Gary E. Miller wrote:

> I just bumped the gpsd version in got to 3.23.2~rc1.  There is
> always more to do on gpsd, but this seems like a good pause point.

It seems to me that this should really be 3.24 rather than 3.23.2.  Will 
the next release be 3.23.2.1? :-)

This probably came about due to just replacing 'dev' with 'rc1'.  The 
trouble with the current naming scheme for dev versions is that it assumes 
that one can predict the *next* version number.  If the version were a 
simple integer that would be fine, but with the variable-resolution 
versioning, not so much.  I suggest basing future dev versions on the 
*preceding* release version, in order to avoid that.

On Thu, 7 Apr 2022, Hal Murray wrote:

> [zillion of copies of these or similar from gpsfake and regress-driver --
> maybe more]
>
> check-0.log:/home/murray/gpsd/raw/gpsd-3.23.2~rc1/gpsfake:21:
> DeprecationWarning: The distutils package is deprecated and slated for removal
> in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
>
> check-0.log:<string>:1: DeprecationWarning: The distutils package is
> deprecated and slated for removal in Python 3.12. Use setuptools or check PEP
> 632 for potential alternatives

Fixing that may be more complicated than they suggest, in order to support 
a wide range of Python versions.

> ----------
>
> 32 bit Debian on X86_64
>
> It's reproducable.
>
> cd gpsd-3.23.2~rc1; ./regress-driver -q -o -t test/daemon/ublox-zed-f9p-hp.log
> Processing test/daemon/ublox-zed-f9p-hp.log
> --- test/daemon/ublox-zed-f9p-hp.log.chk        2022-04-07 17:19:53.319684638
> -0700
> +++ /tmp/gpsd-test-oL87pr222GfyOp/test-6745.chk 2022-04-07 20:52:40.567122999
> -0700
> @@ -176,7 +176,7 @@
[...]
> $GPGSA,A,3,2,12,25,29,,,,,,,,,1.3,0.8,1.0*04^M
> -{"class":"TPV","mode":3,"time":"2019-04-22T21:19:45.000Z","leapseconds":18,"ep
> t":0.005,"lat":-45.877531298,"lon":170.500106470,"altHAE":26.1200,"altMSL":24.3
                                                    ^^^^^^^^^^^^^^^
> 290,"alt":24.3290,"epv":12.485,"track":217.8765,"magtrack":243.6232,"magvar":25
> .7,"speed":0.071,"climb":0.028,"eps":0.73,"epc":24.98,"ecefx":-4387118.20,"ecef
> y":734143.42,"ecefz":-4555799.86,"ecefvx":0.05,"ecefvy":-0.03,"ecefvz":-0.03,"e
> cefpAcc":19.44,"ecefvAcc":0.73,"geoidSep":5.124,"eph":14.905,"sep":24.510}^M
> +{"class":"TPV","mode":3,"time":"2019-04-22T21:19:45.000Z","leapseconds":18,"ep
> t":0.005,"lat":-45.877531298,"lon":170.500106470,"altHAE":26.1199,"altMSL":24.3
                                                    ^^^^^^^^^^^^^^^
> 290,"alt":24.3290,"epv":12.485,"track":217.8765,"magtrack":243.6232,"magvar":25
> .7,"speed":0.071,"climb":0.028,"eps":0.73,"epc":24.98,"ecefx":-4387118.20,"ecef
> y":734143.42,"ecefz":-4555799.86,"ecefvx":0.05,"ecefvy":-0.03,"ecefvz":-0.03,"e
> cefpAcc":19.44,"ecefvAcc":0.73,"geoidSep":5.124,"eph":14.905,"sep":24.510}^M
[...]

I also saw this on 32-bit OpenBSD (for the same test).  I haven't dug into 
it yet, but I suspect it's another instance of the older problem fixed by 
e379bfac5.

On Fri, 8 Apr 2022, James Browning wrote:

> Apple LLVM version 10.0.0 (clang-1000.10.44.4) on High Sierra reports:
> > clang: warning: treating 'c' input as 'c++' when in C++ mode, this
> behavior is deprecated [-Wdeprecated]
> for about a dozen .c files in libgps/

That's a long-standing problem related to the way Qt support works.  The 
warning only shows up with certain versions of clang, and in spite of the 
deprecation warning, I've yet to see a version that refuses to compile it.

There'd be no issue if Qt support were just a wrapper around the standard 
libgps, which is the way the non-Qt C++ support works.  But instead, for 
Qt it builds a separate version of libgps with some Qt-related tweaks, and 
builds it as C++ to make the Qt stuff work.  AFAICT, the only reason for 
this ugly approach is to run the libgps network accesses through 
QtNetwork, and I believe the only reason that's done is to keep the Qt UI 
from blocking when the libgps network I/O is blocked.  It's the classic 
problem that occurs whenever one has two or more independent packages 
where each needs to block for its own reasons.

That's on my list of things to fix, but since fixing it is nontrivial and 
it's only a warning, it hasn't been a high priority.  Adding to the 
problem is the lack of a good Qt client for testing.  I dredged up the 
ancient qtgpsc and got it to be partially functional, but it still needs 
work.

> I think the logging is too quiet with -s and too loud without and I'm not
> really testing.

I did some work in that area a while back, and I disagree with the "too 
quiet" part.  I believe the output in -s mode is sufficient to determine 
*whether* there are issues, though sometimes running without -s is neede 
to find out *why* something is failing.  I think the current -s output is 
still too verbose, but at least it avoids burying all the warnings in a 
forest of build commands.

On Fri, 8 Apr 2022, Gary E. Miller wrote:
> On Fri, 8 Apr 2022 08:00:00 -0700
> James Browning <jamesb.fe80@gmail.com> wrote:

> > The previous file and gpsd-code-example griped about the rouge gems'
> > absence, I gave it to them
>
> You mean "ruby gems"?  If you are missing that, then your AasciiDoctor is
> not installed correctly.  Nothing gpsd can do about that.  gpsd
> checks that AsciiDoctor is installed, not that it is installed correctly.

AFAIK, the rouge gems are not a general requirement for asciidoctor.  When 
I looked into this a bit, I found something that indicated that this error 
is often caused by something being specfied incorrectly so that it falls 
back to needing 'rouge', but that's as far as I got.  I'm not aware of any 
actual problem caused by the absence of 'rouge', so I didn't bother 
digging further.

On Fri, 8 Apr 2022, Gary E. Miller wrote:
> On Fri, 8 Apr 2022 08:00:00 -0700
> James Browning <jamesb.fe80@gmail.com> wrote:
>
> > > Presence of gripes about regress-driver burning through all of the
> > > NTP SHM segments on macOS.
> >
> > That has been there forever.  I have no idea why shm_release() fails
> > to do its job.  It gets called on exit, with the right parameters
> > None of its syscalls report any errors.  I just rearranged the code a
> > tad, but do not expect that helped.
>
> I just pushed another try, that works for me.  The trick is to set
> the SHM for removal while gpsd is still running as root.
>
> Please test, after you reboot and clear your SHMs.

I've seen enough of those on some platforms that I put a filter into one 
of my test scripts to get rid of them.  I'll have to see if I can take 
that out now.

It would actually make sense to disable SHM support altogether for the 
regression tests, but there's currently no option to do that.  Obviously 
any test specifically for the SHM output would need to keep it, but I 
don't think there is any such thing at the moment.  Normal regression 
tests can't use SHM since it has no flow control.

Fred Wright