Re: ✘ Release blockers?

[Fred Wright]

On Wed, 18 Dec 2019, Bernd Zeimetz wrote:
> On 2019-12-18 10:02, Fred Wright wrote:
> > >  We do test on clang.  I test on osX which uses clang.  But I see I do not
> > >  have Qt enabled.  Not sure how to do that on a mac.
> >
> >  If you have MacPorts installed, just install the qt4-mac port.  At one
> >  time I also had builds with Qt5 working on the Mac, but something
> >  changed that broke it since then, so for now it's Qt4-only.
>
> qt4 is deprecated and should be gone for good for a long time.
> Nothing serious should use it anymore.

It's better than not testing the Qt code on the mac at all.

> > > >  It also only happens with
> > > >  qt=yes, but qt=no is forced if pkg-config can't find QtNetwork,
> > > >  explaining non-failures in certain cases.
> > >
> > >  The only Qt thing gpsd builds is a simple test case.  No known clients.
> >
> >  Yeah, I know, but at least the simple test should build and run.
>
> It does everywhere else, can you please show at least a log of the failure?

I previously posted the complete command line of the failing command, 
which happened on multiple platforms.  It may depend on the clang version. 
In any case, it works on all platforms now.

When building the Qt code, some clang versions say:

clang: warning: treating 'c' input as 'c++' when in C++ mode, this 
behavior is deprecated

That may be related.

That whole Qt build area is a mess, but I'm not going to try to rework it 
right now.

> Looking at your commits, I'm wondering about
[...]
> If c_only disappears from qt_flags before it is being removed,
> there is something completely broken. Not sure what you are trying to
> fix there. Note the 'if c_only in qt_flags' line.
>
> So what did you actually try to do here? Guess you had a reason for
> that change?

Nope.  Brain fart.  That's what I get for hurrying (while also having a 
remove() failure on the brain from another place).  It is actually more 
efficient to use the try/except *instead of* the if when the item has a 
high probability of being present, but the if is more compact, and of 
course it makes no sense to do both.  Reverted.

On Wed, 18 Dec 2019, Gary E. Miller wrote:
> On Wed, 18 Dec 2019 01:02:40 -0800 (PST)
> Fred Wright <address@hidden> wrote:
>
> > > Could be.  AFAIK, only some Power CPUs have big-endian modes.  They
> > > should die...
> >
> > All POWER and PowerPC processors are natively big-endian.
>
> Uh, no:
>
>    https://en.wikipedia.org/wiki/PowerPC#Endian_modes
>
> Selectable.  Sometimes on a per page level.

Read it again.  Particularly the parts about "The processor starts in 
big-endian mode" and the "warped view" needed for little-endian mode.  In 
any case, my information is baed on the actual PowerPC specs from Motorola 
and IBM, not Wikipedia.

> > > If you could do this, and send the results that would help a lot:
> > >
> > >  # ./regress-driver test/daemon/garmin18x-bin.log
> >
> > I'll look into it myself first, since I can actually reproduce it
> > here.
>
> The sooner the better.  This is close to the last issue before release.

It looks like it's indeed an old problem that wasn't noticed when there 
were no tests for it, so it's not really a regression.  There are *also* 
differences in behavior between 3.19 and latest on the x86, but that may 
be due to new fixes rather than new bugs.  Has the output been inspected 
closely enough to tell the difference?

> > One thing that isn't strictly a regression, but has been rearing its
> > ugly head lately, is that crock where it thinks it needs to build the
> > Python extensions with the exact same C compiler as was used for
> > Python itself.
>
> Sadly that is the world we live in today.  I run into this constantly
> on Gentoo unstable that loves to update the compilers frequently.
>
> > I'd like to try to fix that before the release.
>
> The world would appreciate that, but not a gpsd issue.

Actually it is.  There's nothing that says that Python extensions need to 
be built with the same compiler as Python itself, but the GPSD build 
procedure thinks that they do.  Unfortunately, a quick experiment at 
fixing that proved unsuccessful, so I guess that bug will have to wait.

On Sat, 14 Dec 2019, Fred Wright wrote:
> On Wed, 11 Dec 2019, Gary E. Miller wrote:
> >  On Wed, 11 Dec 2019 17:48:26 -0800 (PST)
> >  Fred Wright <address@hidden> wrote:
>
> > > > >  2) The rename of the altitude field has an interoperability issue
> > > > >  with other GPSD versions.  The client and server can be on
> > > > >  different machines, and not necessarily the same version.  At
> > > > >  least one direction should be fixable with a bit of fallback code.
> > > >
> > > >  I restored "alr"/"altitude" and marked it deprecated and undefined.
> > >
> > >  I'm not sure that alone is enough to fix it, but I'll try it when I
> > >  get a chance.
> >
> >  I restored what I took out, so it has all the bugs that it had before.
>
> That's not sufficient.  More on this later.

The problem is that new clients are expecting it under the new name, and 
get nothing if it's provided under the old name.  This is easily seen by 
pointing a current cgps build at an older gpsd.

I actually don't see any value in changing the name in the JSON at all, 
since hardly anyone looks at the JSON directly and changing the name 
breaks compatibility.  What would make more sense would be to keep the old 
name on the wire and have the client libraries pass it along under both 
names, with the old one being labeled deprecated.  That not only keeps 
compatibility on the wire, but also avoids breaking existing clients. 
These are public libraries, so there can be other programs that use them 
besides the ones bundled with GPSD, and those shouldn't be expected to be 
updated in lockstep with GPSD releases.

Fred Wright