Re: ✘ Release blockers?

[Greg Troxel]

Bernd Zeimetz <address@hidden> writes:

> On 12/24/19 4:17 PM, Greg Troxel wrote:
>
>> I removed -o -t from SConstruct:
>> 
>> @@ -2268,7 +2268,7 @@ else:
>>      for gps_name, gps_log in zip(gps_names, gps_logs):
>>          gps_tests.append(Utility(
>>              'gps-regress-' + gps_name, gps_herald,
>> -            '$SRCDIR/regress-driver -q -o -t $REGRESSOPTS ' + gps_log))
>> +            '$SRCDIR/regress-driver -q $REGRESSOPTS ' + gps_log))
>>      gps_regress = env.Alias('gps-regress', gps_tests)
>>  
>>      # Run the passthrough log in all transport modes for better coverage
>> 
>> and am rerunning.  (I'm not sure if that's right, and what the
>> recommended way to switch between tcp and pty for input is.)
>> This also had a faliuer, but it looks like the usual too-low-WRITE_PAD
>> type.
>
> -o -t uses tcp
> -o -u uses udp
> no -o at all -> pty.
>
> There is no option in gpsfake to force pty usage.

Thanks for explaining.  It seems we should have a way to use pty instead
of tcp (presuming this is for providing the fake input to gpsd -- with
pty more of the code would seem to be exercised), but I don't see that
as being in the way of the release.

I ran with the (local) change above and no forcing of WRITE_PAD, and got
a clean pass.

As I read gps/fake.py, WRITE_PAD is used in either tcp or pty case,
because it's in feed, which is common.


I will try tcp and a larger WRITE_PAD.  Perhaps the tcp code is faster
than pty on netbsd and thus switching to tcp is provoking whatever the
bug is.