Hi,


..reportbug reports our (Devuan) BTS is down, bug report on gpsd:
Content-Type
: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Arnt <arnt@???>
To: Devuan Bug Tracking System <submit@???>
Subject: gpsd: ..2'nd roll over bug: gpsd clock is 56 years wrong,
"1963-07-18T08:57:40.584Z" Message-ID:
<155465156363.24771.3526445890355259661.reportbug@sda3> X-Mailer:
reportbug 7.1.6+devuan2.1 Date: Sun, 07 Apr 2019 17:39:23 +0200
X-Debbugs-Cc: arnt@???

Package: gpsd
Version: 3.16-4
Severity: important

..upstream bug.


Dear Maintainer,

*** Reporter, please consider answering these questions, where
appropriate ***

* What led up to the situation?

..according to http://catb.org/gpsd/NMEA.html#_dates_and_times :
GPS date and time are subject to a rollover problem in the 10-bit
week number counter, which will re-zero every 1024 weeks (roughly
every 19.6 years). The last rollover (and the first since GPS went
live in 1980) was in Aug-1999; the next will fall in Apr-2019.


..checks out rather well:
arnt@sda3:~$ date --date='1024 weeks ago'
Sun Aug 22 18:23:04 CEST 1999
arnt@sda3:~$ date --date='2048 weeks ago'
Sun Jan 6 17:23:36 CET 1980
arnt@sda3:~$ date --date='TZ=UTC 2048 weeks ago'
date: invalid date ‘TZ=UTC 2048 weeks ago’
arnt@sda3:~$ date --date='TZ="UTC" 2048 weeks ago'
Sun Jan 6 19:25:50 CET 1980
arnt@sda3:~$
http://www.leapsecond.com/java/gpsclock.htm
http://www.leapsecond.com/java/cal.htm


..fix suggestions: hard code third 10bit era and/or move to
the new 13bit "CNAV" data format pointed to above.

..this patch hard codes third 10bit era as suggested in 
gpsd-3.1x's timebase.c:
arnt@nb6:~$ diff -u timebase.h-3.16 timebase.h-new
--- timebase.h-3.16     2016-01-08 20:30:27.000000000 +0100
+++ timebase.h-new      2019-04-07 20:11:52.903644739 +0200
@@ -1,9 +1,9 @@
 /*
  * Constants used for GPS time detection and rollover correction.
  *
- * Correct for week beginning 2016-01-07T00:00:00
+ * Correct for week beginning 2019-04-07T02:00:00 UTC
  */
 #define BUILD_CENTURY  2000
-#define BUILD_WEEK     854            # Assumes 10-bit week counter 
-#define BUILD_LEAPSECONDS      17
-#define BUILD_ROLLOVERS        1      # Assumes 10-bit week counter
+#define BUILD_WEEK     1              # Assumes 10-bit week counter 
+#define BUILD_LEAPSECONDS      19
+#define BUILD_ROLLOVERS        2      # Assumes 10-bit week counter

..and ditto for gpsd-3.17:
arnt@nb6:~$ diff -u timebase.h-3.17 timebase.h-new
--- timebase.h-3.17     2017-09-07 13:53:40.000000000 +0200
+++ timebase.h-new      2019-04-07 20:11:52.903644739 +0200
@@ -1,9 +1,9 @@
 /*
  * Constants used for GPS time detection and rollover correction.
  *
- * Correct for week beginning 2017-09-07T00:00:00
+ * Correct for week beginning 2019-04-07T02:00:00 UTC
  */
 #define BUILD_CENTURY  2000
-#define BUILD_WEEK     941           # Assumes 10-bit week counter 
+#define BUILD_WEEK     1             # Assumes 10-bit week counter 
#define BUILD_LEAPSECONDS      19
-#define BUILD_ROLLOVERS        1         # Assumes 10-bit week counter
+#define BUILD_ROLLOVERS        2         # Assumes 10-bit week counter

..this patch hard codes third 10bit era as suggested in 
gpsd-3.11's timebase.c: 
arnt@sda3:~$ diff -u timebase.h*
--- timebase.h-3.11  2019-04-07 19:19:42.442197516 +0200
+++ timebase.h-ny      2019-04-07 19:18:28.572535352 +0200
@@ -1,8 +1,8 @@
 /*
  * Constants used for GPS time detection and rollover correction.
  *
- * Correct for week beginning 2014-08-21T00:00:00
+ * Correct for week beginning 2019-04-07T00:00:00
  */
-#define CENTURY_BASE   201400
-#define LEAPSECOND_NOW 16
-#define GPS_WEEK_NOW   1806
+#define CENTURY_BASE   201900
+#define LEAPSECOND_NOW 19
+#define GPS_WEEK_NOW   2049

..current timebase.h in gpsd-3.11 source:
arnt@sda3:~$ cat timebase.h
/*
 * Constants used for GPS time detection and rollover correction.
 *
 * Correct for week beginning 2014-08-21T00:00:00
 */
#define CENTURY_BASE    201400
#define LEAPSECOND_NOW  16
#define GPS_WEEK_NOW    1806
arnt@sda3:~$

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

-- System Information:
Distributor ID: Devuan
Description:    Devuan GNU/Linux 2.0 (ascii)
Release:        2.0
Codename:       ascii

Architecture: armv6l

Kernel: Linux 4.19.32+
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot
set LC_ALL to default locale: No such file or directory UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gpsd depends on:
ii  adduser              3.115
ii  init-system-helpers  1.48+devuan2.0
ii  libbluetooth3        5.43-2+deb9u1
ii  libc6                2.24-11+deb9u4
ii  libdbus-1-3          1.10.22-1+devuan2
ii  libgps22             3.16-4
ii  libusb-1.0-0         2:1.0.21-1
ii  lsb-base             4.1+devuan2
ii  netbase              5.4

Versions of packages gpsd recommends:
ii  python  2.7.13-2
pn  udev    <none>

Versions of packages gpsd suggests:
ii  dbus          1.10.22-1+devuan2
ii  gpsd-clients  3.16-4

-- debconf information:


--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.