Re: ✘gpsd .23.2~rc1

[Gary E. Miller]

Yo Fred!

On Fri, 8 Apr 2022 19:38:04 -0700 (PDT)
Fred Wright <fw@fwright.net> wrote:

> 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? :-)

Since the last one was 3.23.1, makes sens to me that the next one is
3.23.2.

For some reason gpsd users are more reluctant to go from 3.23 to 
3.24, than from 3.23 to 3.23.1.

> This probably came about due to just replacing 'dev' with 'rc1'.

As documented in SConsctruct.

> The 
> trouble with the current naming scheme for dev versions is that it
> assumes that one can predict the *next* version number.

Where did you get that idea?  There has been no previous consistency
or implication of that.

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

I tried that once, confused everyone.  

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

It was previsouly fixed in SConscipt.  I have already fixed gpsfake, not
pushed yet.  Just one more place for me to fix.

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

Since you have an idea, I'll eave that one to last.

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

I suspect you are correct, but without the build log, we are jsut guessing.

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

Since Qt is getting less FOSS all the time, I'm hoping it jsut
becomes a non-issue.

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

I'm still totally lost on this one...

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

What is "rouge"?  gpsd does not use it, so not a gpsd problem.

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

Fix already pushed.

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

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

pgpctMgoZOlCS.pgp
Description: OpenPGP digital signature