gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] 3.11 release is imminent


From: Eric S. Raymond
Subject: Re: [gpsd-dev] 3.11 release is imminent
Date: Thu, 21 Aug 2014 06:41:50 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

Bernd Zeimetz <address@hidden>:
> >> Please run another set of tests with the repository head version.
> > 
> > 
> > will do.
> 
> seems to become worse...
> https://buildd.debian.org/status/logs.php?pkg=gpsd&ver=3.10%2Bdev3~d6b65b48-1&suite=sid

Hmm...Ignoring DBUS issues, I see this:

The armel and armelhf logs look almost clean. There is this:

driver_zodiac.c:399:34: warning: cast increases required alignment of target 
type [-Wcast-align]
     unsigned short *shortwords = (unsigned short *)msg;

hurd-i386 aand i386 look clean.

Under kfreebsd-amd64 and kfreebsd-386 I see this:

driver_garmin.c:627:19: warning: 'PrintUSBPacket' defined but not used 
[-Wunused-function]
 static gps_mask_t PrintUSBPacket(struct gps_device_t *session, Packet_t * pkt)
                   ^
driver_garmin.c:851:13: warning: 'is_usb_device' defined but not used 
[-Wunused-function]
 static bool is_usb_device(const char *path UNUSED, int vendor, int product,
             ^
Under kfreebsd-386 I see a regression-testt failure on GPSmap-76S.  There
is one failure to parse a GPGSA, then this divergence in the handling 
of a sat-picture sentence.

-{"class":"SKY","tag":"GSV","xdop":0.60,"ydop":0.64,"vdop":3.00,"tdop":0.82,"hdop":2.00,"gdop":1.82,"pdop":3.60,"satellites":[{"PRN":3,"el":41,"az":50,"ss":46,"used":true},{"PRN":7,"el":60,"az":317,"ss":49,"used":true},{"PRN":8,"el":34,"az":315,"ss":45,"used":true},{"PRN":11,"el":35,"az":148,"ss":45,"used":true},{"PRN":13,"el":38,"az":213,"ss":45,"used":true},{"PRN":16,"el":27,"az":68,"ss":43,"used":true},{"PRN":19,"el":72,"az":76,"ss":50,"used":true},{"PRN":23,"el":9,"az":182,"ss":37,"used":true},{"PRN":24,"el":6,"az":166,"ss":35,"used":true},{"PRN":28,"el":9,"az":271,"ss":36,"used":true}]}
+{"class":"SKY","tag":"GSV","satellites":[{"PRN":3,"el":41,"az":50,"ss":46,"used":false},{"PRN":7,"el":60,"az":317,"ss":49,"used":false},{"PRN":8,"el":34,"az":315,"ss":45,"used":false},{"PRN":11,"el":35,"az":148,"ss":45,"used":false},{"PRN":13,"el":38,"az":213,"ss":45,"used":false},{"PRN":16,"el":27,"az":68,"ss":43,"used":false},{"PRN":19,"el":72,"az":76,"ss":50,"used":false},{"PRN":23,"el":9,"az":182,"ss":37,"used":false},{"PRN":24,"el":6,"az":166,"ss":35,"used":false},{"PRN":28,"el":9,"az":271,"ss":36,"used":false}]}

The mips log repeats the driver_zodiac error above, then has some
AIS regression failures on Type 6 sentences.

The mipsel log repeats the driver_zodiac error.  It has a several
regression failures.  These look spurious to me - whole-sentence
dropouts (as opposed to nearly but not quite matching JSON objects)
are what you get from flaky failures in the pty layer on a heavily
loaded machine.

More AIS type 6 errors in the powerpc log.

s390x has a dropout regression failure that is probably spurious.

Some compilation warnings under sparc:

shmexport.c: In function 'shm_update':
shmexport.c:69:40: warning: cast increases required alignment of target type 
[-Wcast-align]

gpspipe.c: In function 'main':
gpspipe.c:344:12: warning: format '%ld' expects argument of type 'long int', 
but argument 5 has type '__suseconds_t' [-Wformat]
gpspipe.c:344:12: warning: format '%ld' expects argument of type 'long int', 
but argument 5 has type '__suseconds_t' [-Wformat]
gpspipe.c:348:12: warning: format '%ld' expects argument of type 'long int', 
but argument 4 has type '__suseconds_t' [-Wformat]
gpspipe.c:348:12: warning: format '%ld' expects argument of type 'long int', 
but argument 4 has type '__suseconds_t' [-Wformat]

It has a dropout error on the geostar-geos1m-binary.log test.

Am I missing anything that you noticed?

I don't know what's up with those AIS Type 6 failures.  Curious that it's 
not flaking out on Type 8, which has very similar gandling.  That may
be some clue.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]