[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ✘ Release blockers?
From: |
Fred Wright |
Subject: |
Re: ✘ Release blockers? |
Date: |
Thu, 26 Dec 2019 15:26:52 -0800 (PST) |
User-agent: |
Alpine 2.21 (LRH 202 2017-01-01) |
On Mon, 23 Dec 2019, Gary E. Miller wrote:
How do people feel today about a release?
Everything I care about is good to go.
About the only possibly blocking issue I can think of is the
gpsfake issues in some of the pipelines.
Is it:
a) fixed
b) almost fixed
c) can't be easily fixed
Any other bloking issues?
It looks like the PRN and svid are swapped for SBAS satellites. They
ought to match this:
https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System
It's also not clear that it's correct to regard the NMEA numbers as
"svids" when that term usually has a different meaning, but we should at
least get the PRNs right.
It looks like the relevant code appears in multiple places, and even the
magic number 87 isn't parameterized:
MacPro:gpsd fw$ grep -nw ' 87' *.c
driver_garmin.c:579: session->gpsdata.skyview[j].svid =
(short)sats->svid + 87;
driver_nmea0183.c:1179: *ubx_svid = 87 + nmea_satnum;
driver_nmea0183.c:1279: *ubx_svid = 87 + nmea_satnum;
driver_superstar2.c:197: porn = (unsigned int)(getub(buf, off + 3)
>> 1) + 87;
driver_tsip.c:76: *svid = prn + 87;
driver_tsip.c:88: *svid = prn + 87;
driver_ubx.c:126: nmea_PRN = svId - 87;
monitor_superstar2.c:50: porn = ((unsigned char)getub(buf, off + 3)
>> 1) + 87;
I didn't want to fix it without finding out if there are further
ramifications.
Also, running the 3.19 cgps against the latest daemon hangs without
acquiring any data.
On Tue, 24 Dec 2019, Hal Murray wrote:
The in-progress test is crazy big:
-rw-r--r-- 1 gdt wheel 8.1G Dec 24 08:56 /tmp/gpsd-test-XXXXXXXXXXXXXX.B7OW
crJ0/test-2801.chk
and then diff gets unhappy wanting 8G of ram.
That's the loop writing stuff that I encountered a few days ago.
If this is reproducible, it would be good to determine:
A) Is this a daemon bug or just a test bug?
B) Is it a new bug since 3.19?
If it's yes/yes, then it's almost certainly a release blocker. If it's
no/yes, then a probable release blocker. If yes/no, then worth some
investigation and maybe a fix if it's a reasonably focused fix. If it's
no/no, then leave it for later.
Fred Wright
- Re: ✘ Release blockers?, (continued)
- Re: ✘ Release blockers?, Bernd Zeimetz, 2019/12/24
- Re: ✘ Release blockers?, Greg Troxel, 2019/12/24
- Re: ✘ Release blockers?, Greg Troxel, 2019/12/24
- Re: ✘ Release blockers?, Bernd Zeimetz, 2019/12/24
- Re: ✘ Release blockers?, Greg Troxel, 2019/12/24
- Re: ✘ Release blockers?, Bernd Zeimetz, 2019/12/24
- Re: ✘ Release blockers?, Greg Troxel, 2019/12/24
- Re: ✘ Release blockers?, Greg Troxel, 2019/12/24
- Re: ✘ Release blockers?, Gary E. Miller, 2019/12/24
- Re: ✘ Release blockers?, Hal Murray, 2019/12/24
- Re: ✘ Release blockers?,
Fred Wright <=
- Re: Re: ✘ Release blockers?, Hal Murray, 2019/12/26
- Re: ✘ Release blockers?, Gary E. Miller, 2019/12/26
- Re: Re: ✘ Release blockers?, Fred Wright, 2019/12/26
- Re: ✘ Release blockers?, Gary E. Miller, 2019/12/26
- Re: ✘ Release blockers?, Gary E. Miller, 2019/12/30
- Re: ✘ Release blockers?, Hal Murray, 2019/12/30
- Re: ✘ Release blockers?, Fred Wright, 2019/12/31
- Re: Re: ✘ Release blockers?, Hal Murray, 2019/12/31
- Re: ✘ Release blockers?, Greg Troxel, 2019/12/31
- Re: ✘ Release blockers?, Greg Troxel, 2019/12/31