Re: [gpsd-dev] Last known 3.12 blocker solved

[Eric S. Raymond]

Hal Murray <address@hidden>:
> I'm assuming the following sequence should do the right thing:
>   git clone/pull
>   scons
>   scons check
>   scons install
> and that it should work with or without an old or current version of gpsd 
> already being installed and/or running.

The scons install is the risky part.  Thanks to your prodding I now have 
scons check using libraries in the source directory pretty well walled off
from any resource a production gpsd might be using.

> Part of the problem is that I was forgetting to add "chrpath=yes" when I ran 
> scons.  Apologies for all the noise and wild geese.  (I was trying to avoid 
> wild geese by making sure I was using a clean test environment.  My working 
> directory has that in a script so I don't forget.)

If you want to guarantee a clean test environment chrpath=yes is the
best way to go.  It keeps you uninvolved with anything in /usr/local.

> You might look into fixing chrpath to default to yes if chrpath is installed 
> and/or giving a loud warning if scons check will be run against a non-local 
> library.

I used to default chrpath=yes, and got a ration of crap for it for reasons
I no longer remember. :-(
 
> There was a some discussion of this area a while ago.  I thought the 
> non-chrpath mode was that "scons" linked with the local libraries and "scons 
> install" relinked with the to-be installed libraries.

That's chrpath=yes you're describing.  With chrpath=no it always links with
installed libraries.

>                                           Mumble.  Maybe I'll 
> remove chrpath from a system so somebody tests that case.

chrpath=no is equivalent to removing it.

> How many bugs/quirks are in this tangle?
> 
>   why is scons check using a SMH key of 0x47505344
> 
>   should scons check be deleting SHM segments?
> 
>   why is a manual test leaving un-keyed segments?

Those are all damned good questions about which I presently have no clue.
I'll probably spend the next couple of days staring at this.
 
>   "shared-segment creation failed" doesn't get counted as an error.

That's because it's an error thrown by the slave gpsd instance.  It's
difficult to pass that out to where regress-driver can see it.

> There is an additional problem of a test run stomping on SHM used by 
> production gpsd/ntpd.  Does the test mode actually do anything with those SHM 
> segments?  Does the data from the test stream get written there, possibly 
> feeding bogus data to ntpd?  (it only polls once a second)

The test mode does *not* do anything with those segments - nothing gets
written to them unless gpsd sees a PPS event and there's no way for
that to happen when it's being driven by ptys.  gpsd allocates
them up front only because of the privilege-dropping issue.

Dammit, do I have to postpone the release to completely rework SHM 
allocation?  It begins to look like it.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>