Re: ✘ Release blockers?

[Greg Troxel]

Bernd Zeimetz <address@hidden> writes:

> On 12/24/19 3:28 PM, Greg Troxel wrote:
>> (switched back to py37-scons)
>> 
>> I also updated git again, and got the 'banish eval' commit (which looks
>> fine and long overdue).
>> 
>> I am getting some sporadic test failures.  I got one in an rtcm3 test
>> and then when I reran I got this.  As I read the diff it's a duplicated
>> line.
>> 
>> I wonder if this is about using the -t option even though I'm not
>> passing -j.
>
> If that is the case, then my guess that the issue is nether in a rather
> simple tcp/pty sende implementation, nor in the os specific tcp/pty
> part, would be true...

It is starting to seem more and more likely that your hypothesis is
true.

> Right now I'm running the regression tests on freebsd with truss and
> I've setup some jobs to do this every 30 minutes. I want to see whats
> going on...

I set WRITE_PAD to 0 in my build script earlier, and just realized I
still have it on.  So the following is with a nonstandard config.  In my
last 4 runs, I got
  semi-infinite zed-f9p-nmea output
  3 random failures that look like a duplicated line

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.
 
I have now removed the WRITE_PAD setting from my build script and tests
are proceeding.


All in all, while I am not sure if there are test issues, I don't see
any actual problems in the built products.