[meta-oe][PATCH 0/5] ntpd and gpsd updates for high-precision timing

[meta-oe][PATCH 0/5] ntpd and gpsd updates for high-precision timing

[Peter A. Bigot]

The first patch restores server debugging capability to NTP, a feature
that is necessary when diagnosing configuration issues.

The remaining patches make it possible to use the pulse-per-second
capability of GPS and Linux RFC 2783 kernel PPS support to synchronize
clocks to microsecond accuracy, either using gpsd as a mediator or
using ntp directly.

Peter A. Bigot (5):
  ntp: re-enable server debugging and control by PACKAGECONFIG
  gpsd: update to 3.10
  pps-tools: add recipe
  gpsd: add optional support for KPPS interface
  ntp: add optional support for KPPS interface

 .../ntp/files/ntp-disable-debugging.patch          | 23 ------------
 meta-networking/recipes-support/ntp/ntp.inc        |  6 ++-
 ...truct-respect-sysroot-also-in-SPLINTOPTS.patch} | 19 ++++++----
 .../0002-SConstruct-remove-rpath.patch}            | 19 ++++++----
 ...refix-includepy-with-sysroot-and-drop-sy.patch} | 27 ++++++++------
 ...isable-html-and-man-docs-building-becaus.patch} | 43 ++++++++++++----------
 .../gpsd/{gpsd_3.7.bb => gpsd_3.10.bb}             | 17 +++++----
 meta-oe/recipes-support/pps-tools/pps-tools_git.bb | 16 ++++++++
 8 files changed, 89 insertions(+), 81 deletions(-)
 delete mode 100644 meta-networking/recipes-support/ntp/files/ntp-disable-debugging.patch
 rename meta-oe/recipes-navigation/gpsd/{gpsd-3.7/0002-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch => gpsd-3.10/0001-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch} (61%)
 rename meta-oe/recipes-navigation/gpsd/{gpsd-3.7/0004-SConstruct-remove-rpath.patch => gpsd-3.10/0002-SConstruct-remove-rpath.patch} (75%)
 rename meta-oe/recipes-navigation/gpsd/{gpsd-3.7/0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch => gpsd-3.10/0003-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch} (82%)
 rename meta-oe/recipes-navigation/gpsd/{gpsd-3.7/0001-SConstruct-disable-html-and-man-docs-building-becaus.patch => gpsd-3.10/0004-SConstruct-disable-html-and-man-docs-building-becaus.patch} (62%)
 rename meta-oe/recipes-navigation/gpsd/{gpsd_3.7.bb => gpsd_3.10.bb} (91%)
 create mode 100644 meta-oe/recipes-support/pps-tools/pps-tools_git.bb

-- 
1.8.5.5

[meta-oe][PATCH 1/5] ntp: re-enable server debugging and control by PACKAGECONFIG

[Peter A. Bigot]

The description in a previous patch to disable debugging is incorrect.
Although the option is default-enabled in configure.ac, configure does
respect the option that disables it.

In ntp 4.2.7 the option code is refactored to ntp_debug.m4 and has an
effect in sntp as well.  Adding --disable-debugging to the top-level
configure options overrides the default for both 4.2.6 and 4.2.7 without
patching the distribution.

Make the selection explicit and configurable, but restore the historical
default.  Absence of debugging capability in the server makes it
difficult to validate complex configurations.

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 .../ntp/files/ntp-disable-debugging.patch          | 23 ----------------------
 meta-networking/recipes-support/ntp/ntp.inc        |  5 +++--
 2 files changed, 3 insertions(+), 25 deletions(-)
 delete mode 100644 meta-networking/recipes-support/ntp/files/ntp-disable-debugging.patch

diff --git a/meta-networking/recipes-support/ntp/files/ntp-disable-debugging.patch b/meta-networking/recipes-support/ntp/files/ntp-disable-debugging.patch
deleted file mode 100644
index 242276e..0000000
--- a/meta-networking/recipes-support/ntp/files/ntp-disable-debugging.patch
+++ /dev/null
@@ -1,23 +0,0 @@
-set ntp_ok to no if ntp debugging is not enabled.
-
-Upstream-status: Pending
-
-There is a problem in configure.ac file that whether or not
-'--enable-debugging' is specified in configure cmdline, debugging
-is always enabled.
-We should disable ntp debugging by default.
-
-Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
-
----
---- a/configure.ac
-+++ b/configure.ac
-@@ -2458,7 +2458,7 @@
-         [+ include ntpd debugging code]
-     )],
-     [ntp_ok=$enableval],
--    [ntp_ok=yes]
-+    [ntp_ok=no]
- )
- case "$ntp_ok" in
-  yes)
diff --git a/meta-networking/recipes-support/ntp/ntp.inc b/meta-networking/recipes-support/ntp/ntp.inc
index b63f202..55926e0 100644
--- a/meta-networking/recipes-support/ntp/ntp.inc
+++ b/meta-networking/recipes-support/ntp/ntp.inc
@@ -23,7 +23,6 @@ SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.g
            file://sntp.service \
            file://sntp \
            file://ntpd.list \
-           file://ntp-disable-debugging.patch \
            file://CVE-2013-5211.patch \
 "
 
@@ -38,7 +37,8 @@ USERADD_PACKAGES = "${PN}"
 USERADD_PARAM_${PN} = "--system --home-dir /var/lib/ntp \
                        --shell /bin/false --user-group ntp"
 
-PACKAGECONFIG ??= "cap"
+# NB: debug is default-enabled by NTP; keep it default-enabled here.
+PACKAGECONFIG ??= "cap debug"
 PACKAGECONFIG[openssl] = "--with-openssl-libdir=${STAGING_LIBDIR} \
                           --with-openssl-incdir=${STAGING_INCDIR} \
                           --with-crypto, \
@@ -46,6 +46,7 @@ PACKAGECONFIG[openssl] = "--with-openssl-libdir=${STAGING_LIBDIR} \
                           openssl"
 PACKAGECONFIG[cap] = "--enable-linuxcaps,--disable-linuxcaps,libcap"
 PACKAGECONFIG[readline] = "--with-lineeditlibs,--without-lineeditlibs,readline"
+PACKAGECONFIG[debug] = "--enable-debugging,--disable-debugging"
 
 do_install_append() {
     install -d ${D}${sysconfdir}/init.d
-- 
1.8.5.5

[meta-oe][PATCH 2/5] gpsd: update to 3.10

[Peter A. Bigot]

Patches rebased onto new version with no material changes.

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 ...truct-respect-sysroot-also-in-SPLINTOPTS.patch} | 19 ++++++----
 .../0002-SConstruct-remove-rpath.patch}            | 19 ++++++----
 ...refix-includepy-with-sysroot-and-drop-sy.patch} | 27 ++++++++------
 ...isable-html-and-man-docs-building-becaus.patch} | 43 ++++++++++++----------
 .../gpsd/{gpsd_3.7.bb => gpsd_3.10.bb}             | 14 +++----
 5 files changed, 66 insertions(+), 56 deletions(-)
 rename meta-oe/recipes-navigation/gpsd/{gpsd-3.7/0002-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch => gpsd-3.10/0001-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch} (61%)
 rename meta-oe/recipes-navigation/gpsd/{gpsd-3.7/0004-SConstruct-remove-rpath.patch => gpsd-3.10/0002-SConstruct-remove-rpath.patch} (75%)
 rename meta-oe/recipes-navigation/gpsd/{gpsd-3.7/0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch => gpsd-3.10/0003-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch} (82%)
 rename meta-oe/recipes-navigation/gpsd/{gpsd-3.7/0001-SConstruct-disable-html-and-man-docs-building-becaus.patch => gpsd-3.10/0004-SConstruct-disable-html-and-man-docs-building-becaus.patch} (62%)
 rename meta-oe/recipes-navigation/gpsd/{gpsd_3.7.bb => gpsd_3.10.bb} (92%)

diff --git a/meta-oe/recipes-navigation/gpsd/gpsd-3.7/0002-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch b/meta-oe/recipes-navigation/gpsd/gpsd-3.10/0001-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch
similarity index 61%
rename from meta-oe/recipes-navigation/gpsd/gpsd-3.7/0002-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch
rename to meta-oe/recipes-navigation/gpsd/gpsd-3.10/0001-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch
index 40baa01..c4134f4 100644
--- a/meta-oe/recipes-navigation/gpsd/gpsd-3.7/0002-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch
+++ b/meta-oe/recipes-navigation/gpsd/gpsd-3.10/0001-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch
@@ -1,22 +1,25 @@
-From f5f262be8ae54bd0c0f52802f2007ec89163756f Mon Sep 17 00:00:00 2001
+From 3c5fb3a8691ac711ea93edf8e0b42bffc62b197e Mon Sep 17 00:00:00 2001
 From: Martin Jansa <Martin.Jansa@gmail.com>
 Date: Tue, 24 Apr 2012 11:52:35 +0200
-Subject: [PATCH 1/2] SConstruct: respect sysroot also in SPLINTOPTS
+Subject: [PATCH 1/4] SConstruct: respect sysroot also in SPLINTOPTS
+
+Upstream-Status: Inappropriate [embedded specific]
 
 Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
+Signed-off-by: Peter A. Bigot <pab@pabigot.com>
 ---
- SConstruct |    5 ++++-
- 1 files changed, 4 insertions(+), 1 deletions(-)
+ SConstruct | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/SConstruct b/SConstruct
-index a25e88a..a1bddb9 100644
+index 14e2f59..f0cafa8 100644
 --- a/SConstruct
 +++ b/SConstruct
-@@ -1277,7 +1277,10 @@ def Utility(target, source, action):
- 
+@@ -1414,7 +1414,10 @@ def Utility(target, source, action):
  # Report splint warnings
  # Note: test_bits.c is unsplintable because of the PRI64 macros.
+ # If you get preprocessor or fatal errors, add +showscan.
 -splintopts = "-I/usr/include/libusb-1.0 +quiet"
 +if not env['sysroot']:
 +    splintopts = "-I/usr/include/libusb-1.0 +quiet"
@@ -26,5 +29,5 @@ index a25e88a..a1bddb9 100644
  ma_status, ma = _getstatusoutput('dpkg-architecture -qDEB_HOST_MULTIARCH')
  if ma_status == 0:
 -- 
-1.7.5.4
+1.8.5.5
 
diff --git a/meta-oe/recipes-navigation/gpsd/gpsd-3.7/0004-SConstruct-remove-rpath.patch b/meta-oe/recipes-navigation/gpsd/gpsd-3.10/0002-SConstruct-remove-rpath.patch
similarity index 75%
rename from meta-oe/recipes-navigation/gpsd/gpsd-3.7/0004-SConstruct-remove-rpath.patch
rename to meta-oe/recipes-navigation/gpsd/gpsd-3.10/0002-SConstruct-remove-rpath.patch
index 83b98bb..083a662 100644
--- a/meta-oe/recipes-navigation/gpsd/gpsd-3.7/0004-SConstruct-remove-rpath.patch
+++ b/meta-oe/recipes-navigation/gpsd/gpsd-3.10/0002-SConstruct-remove-rpath.patch
@@ -1,7 +1,7 @@
-From 7d736bbd517c12d19d7b85a5b0db84732b2f86da Mon Sep 17 00:00:00 2001
+From d090638ff983e509162d5e3b62aa4918de4aa5fa Mon Sep 17 00:00:00 2001
 From: Martin Jansa <Martin.Jansa@gmail.com>
 Date: Tue, 24 Apr 2012 16:24:35 +0200
-Subject: [PATCH 2/2] SConstruct: remove rpath
+Subject: [PATCH 2/4] SConstruct: remove rpath
 
 * even with correct prefix (without DESTDIR) included it's redundant
   WARNING: QA Issue: libgps:
@@ -13,19 +13,22 @@ Subject: [PATCH 2/2] SConstruct: remove rpath
   in file
   /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gpsd/gpsd-3.5-r0/packages-split/libgps/usr/lib/libgps.so.20.0
 
+Upstream-Status: Inapppropriate [embedded specific]
+
 Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
+Signed-off-by: Peter A. Bigot <pab@pabigot.com>
 ---
- SConstruct |    7 +++++--
- 1 files changed, 5 insertions(+), 2 deletions(-)
+ SConstruct | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
 
 diff --git a/SConstruct b/SConstruct
-index a1bddb9..3e7c607 100644
+index f0cafa8..ff46713 100644
 --- a/SConstruct
 +++ b/SConstruct
-@@ -1205,8 +1205,11 @@ if qt_env:
+@@ -1340,8 +1340,11 @@ if qt_env:
+     binaryinstall.append(LibraryInstall(qt_env, installdir('libdir'), compiled_qgpsmmlib))
  
- # We don't use installdir here in order to avoid having DESTDIR affect the rpath
  if env["shared"] and env["chrpath"]:
 -    env.AddPostAction(binaryinstall, '$CHRPATH -r "%s" "$TARGET"' \
 -                      % (installdir('libdir', False), ))
@@ -38,5 +41,5 @@ index a1bddb9..3e7c607 100644
  if not env['debug'] and not env['profiling'] and env['strip']:
      env.AddPostAction(binaryinstall, '$STRIP $TARGET')
 -- 
-1.7.5.4
+1.8.5.5
 
diff --git a/meta-oe/recipes-navigation/gpsd/gpsd-3.7/0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch b/meta-oe/recipes-navigation/gpsd/gpsd-3.10/0003-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch
similarity index 82%
rename from meta-oe/recipes-navigation/gpsd/gpsd-3.7/0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch
rename to meta-oe/recipes-navigation/gpsd/gpsd-3.10/0003-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch
index c6eb03b..1d8c14b 100644
--- a/meta-oe/recipes-navigation/gpsd/gpsd-3.7/0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch
+++ b/meta-oe/recipes-navigation/gpsd/gpsd-3.10/0003-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch
@@ -1,8 +1,8 @@
-From dd3ca38b27cce93f7e932abaa27b41371234fa90 Mon Sep 17 00:00:00 2001
+From ad7b06d375730b30f181c5efb3bf21418f296f73 Mon Sep 17 00:00:00 2001
 From: Martin Jansa <Martin.Jansa@gmail.com>
 Date: Tue, 24 Apr 2012 18:45:14 +0200
-Subject: [PATCH] SConstruct: prefix includepy with sysroot and drop sysroot
- from python_lib_dir
+Subject: [PATCH 3/4] SConstruct: prefix includepy with sysroot and drop
+ sysroot from python_lib_dir
 
 * without PYTHONPATH, distutil's sysconfig returns INCLUDEPY without sysroot prefix
   and with PYTHONPATH from OE it's pointing to native python dir
@@ -30,19 +30,22 @@ Subject: [PATCH] SConstruct: prefix includepy with sysroot and drop sysroot
 * python_lib_dir = python_lib_dir.replace(env['sysroot'], '')
   returns path to target sysroot
 
+Upstream-Status: Inappropriate [embedded specific]
+
 Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
+Signed-off-by: Peter A. Bigot <pab@pabigot.com>
 ---
- SConstruct |    9 +++++++++
- 1 files changed, 9 insertions(+), 0 deletions(-)
+ SConstruct | 9 +++++++++
+ 1 file changed, 9 insertions(+)
 
 diff --git a/SConstruct b/SConstruct
-index 3c919fc..8478181 100644
+index ff46713..0e518e7 100644
 --- a/SConstruct
 +++ b/SConstruct
-@@ -932,6 +932,12 @@ else:
-         if vars[i] is None:
-             vars[i] = []
-     (cc, cxx, opt, basecflags, ccshared, ldshared, so_ext, includepy, ldflags) = vars
+@@ -1089,6 +1089,12 @@ else:
+         basecflags += ' -coverage'
+         ldflags += ' -coverage'
+         ldshared += ' -coverage'
 +
 +    if env['sysroot']:
 +        print "Prefixing includepy '%s' with sysroot prefix" % includepy
@@ -52,7 +55,7 @@ index 3c919fc..8478181 100644
      # in case CC/CXX was set to the scan-build wrapper,
      # ensure that we build the python modules with scan-build, too
      if env['CC'] is None or env['CC'].find('scan-build') < 0:
-@@ -1165,11 +1171,14 @@ if not env['python']:
+@@ -1353,11 +1359,14 @@ if not env['python']:
      python_install = []
  else:
      python_lib_dir = sysconfig.get_python_lib(plat_specific=1)
@@ -68,5 +71,5 @@ index 3c919fc..8478181 100644
      python_modules_install = python_env.Install( DESTDIR + python_module_dir,
                                                  python_modules)
 -- 
-1.7.8.5
+1.8.5.5
 
diff --git a/meta-oe/recipes-navigation/gpsd/gpsd-3.7/0001-SConstruct-disable-html-and-man-docs-building-becaus.patch b/meta-oe/recipes-navigation/gpsd/gpsd-3.10/0004-SConstruct-disable-html-and-man-docs-building-becaus.patch
similarity index 62%
rename from meta-oe/recipes-navigation/gpsd/gpsd-3.7/0001-SConstruct-disable-html-and-man-docs-building-becaus.patch
rename to meta-oe/recipes-navigation/gpsd/gpsd-3.10/0004-SConstruct-disable-html-and-man-docs-building-becaus.patch
index 9db2432..8527f0d 100644
--- a/meta-oe/recipes-navigation/gpsd/gpsd-3.7/0001-SConstruct-disable-html-and-man-docs-building-becaus.patch
+++ b/meta-oe/recipes-navigation/gpsd/gpsd-3.10/0004-SConstruct-disable-html-and-man-docs-building-becaus.patch
@@ -1,7 +1,7 @@
-From ca1a781afbd68697ef2f573557f1f93ec7ab8d3c Mon Sep 17 00:00:00 2001
+From 697e2e9ff97487266d817cdd41bacc83f681e3d7 Mon Sep 17 00:00:00 2001
 From: Martin Jansa <Martin.Jansa@gmail.com>
 Date: Sun, 29 Apr 2012 00:05:59 +0200
-Subject: [PATCH] SConstruct: disable html and man docs building because
+Subject: [PATCH 4/4] SConstruct: disable html and man docs building because
  xmlto-native from OE is broken
 
 It will try to load dtd and fail:
@@ -20,30 +20,33 @@ It will try to load dtd and fail:
 | scons: *** [gpsctl.1] Error 1
 | scons: building terminated because of errors.
 
+Upstream-Status: Inappropriate [disable feature]
+
 Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
+Signed-off-by: Peter A. Bigot <pab@pabigot.com>
 ---
- SConstruct |    4 ++--
- 1 files changed, 2 insertions(+), 2 deletions(-)
+ SConstruct | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/SConstruct b/SConstruct
-index 9c0f751..8236abb 100644
+index 0e518e7..c01a71b 100644
 --- a/SConstruct
 +++ b/SConstruct
-@@ -560,12 +560,12 @@ size_t strlcpy(/*@out@*/char *dst, /*@in@*/const char *src, size_t size);
- 
+@@ -704,12 +704,12 @@ size_t strlcpy(/*@out@*/char *dst, /*@in@*/const char *src, size_t size);
  
- manbuilder = mangenerator = htmlbuilder = None
--if config.CheckXsltproc():
-+if False and config.CheckXsltproc():
-     mangenerator = 'xsltproc'
-     build = "xsltproc --nonet %s $SOURCE >$TARGET"
-     htmlbuilder = build % docbook_html_uri
-     manbuilder = build % docbook_man_uri
--elif WhereIs("xmlto"):
-+elif False and WhereIs("xmlto"):
-     mangenerator = 'xmlto'
-     htmlbuilder = "xmlto html-nochunks $SOURCE; mv `basename $TARGET` $TARGET"
-     manbuilder = "xmlto man $SOURCE; mv `basename $TARGET` $TARGET"
+     manbuilder = mangenerator = htmlbuilder = None
+     if env['manbuild']:
+-        if config.CheckXsltproc():
++        if False and config.CheckXsltproc():
+             mangenerator = 'xsltproc'
+             build = "xsltproc --nonet %s $SOURCE >$TARGET"
+             htmlbuilder = build % docbook_html_uri
+             manbuilder = build % docbook_man_uri
+-        elif WhereIs("xmlto"):
++        elif False and WhereIs("xmlto"):
+             mangenerator = 'xmlto'
+             xmlto = "xmlto %s $SOURCE || mv `basename $TARGET` `dirname $TARGET`"
+             htmlbuilder = xmlto % "html-nochunks"
 -- 
-1.7.8.6
+1.8.5.5
 
diff --git a/meta-oe/recipes-navigation/gpsd/gpsd_3.7.bb b/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb
similarity index 92%
rename from meta-oe/recipes-navigation/gpsd/gpsd_3.7.bb
rename to meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb
index 8c6a6f7..d12c7a8 100644
--- a/meta-oe/recipes-navigation/gpsd/gpsd_3.7.bb
+++ b/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb
@@ -7,20 +7,18 @@ PROVIDES = "virtual/gpsd"
 
 EXTRANATIVEPATH += "chrpath-native"
 
-PR = "r14"
-
 SRC_URI = "${SAVANNAH_GNU_MIRROR}/${BPN}/${BP}.tar.gz \
-    file://0002-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch \
-    file://0004-SConstruct-remove-rpath.patch \
-    file://0001-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch \
-    file://0001-SConstruct-disable-html-and-man-docs-building-becaus.patch \
+    file://0001-SConstruct-respect-sysroot-also-in-SPLINTOPTS.patch \
+    file://0002-SConstruct-remove-rpath.patch \
+    file://0003-SConstruct-prefix-includepy-with-sysroot-and-drop-sy.patch \
+    file://0004-SConstruct-disable-html-and-man-docs-building-becaus.patch \
     file://gpsd-default \
     file://gpsd \
     file://60-gpsd.rules \
     file://gpsd.service \
 "
-SRC_URI[md5sum] = "52d9785eaf1a51298bb8900dbde88f98"
-SRC_URI[sha256sum] = "7800c478ee9d7ca7a502b0f892828561b1fbf7bc69d9d38c447c82c3628302ac"
+SRC_URI[md5sum] = "fc5b03aae38b9b5b6880b31924d0ace3"
+SRC_URI[sha256sum] = "706fc2c1cf3dfbf87c941f543381bccc9c4dc9f8240eec407dcbf2f70b854320"
 
 inherit scons update-rc.d python-dir pythonnative systemd
 
-- 
1.8.5.5

[meta-oe][PATCH 3/5] pps-tools: add recipe

[Peter A. Bigot]

This provides some utilities and a user-space header necessary to use
the Linux KPPS (RFC 2783) capabilities of gpsd and ntp.

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta-oe/recipes-support/pps-tools/pps-tools_git.bb | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
 create mode 100644 meta-oe/recipes-support/pps-tools/pps-tools_git.bb

diff --git a/meta-oe/recipes-support/pps-tools/pps-tools_git.bb b/meta-oe/recipes-support/pps-tools/pps-tools_git.bb
new file mode 100644
index 0000000..73c46ee
--- /dev/null
+++ b/meta-oe/recipes-support/pps-tools/pps-tools_git.bb
@@ -0,0 +1,16 @@
+SUMMARY = "User-space tools for LinuxPPS"
+
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
+
+PV = "0.0.0+git${SRCPV}"
+SRCREV = "0deb9c7e135e9380a6d09e9d2e938a146bb698c8"
+SRC_URI = "git://github.com/ago/pps-tools.git"
+
+S = "${WORKDIR}/git"
+
+do_install() {
+        install -d ${D}${bindir} ${D}${includedir} \
+                   ${D}${includedir}/sys
+        oe_runmake 'DESTDIR=${D}' install
+}
-- 
1.8.5.5

[meta-oe][PATCH 4/5] gpsd: add optional support for KPPS interface

[Peter A. Bigot]

gpsd by default builds with PPS (pulse-per-second) support, but without
kernel support to capture the edge of the pulse the accuracy is only
+/-5us.  Under Linux the pps-tools package installs the header required
for the user-level API to the RFC 2783 KPPS interface.  If gpsd detects
this header, it will use the API to improve accuracy to +/-1us.

See: http://www.catb.org/gpsd/gpsd-time-service-howto.html#_enabling_pps

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb b/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb
index d12c7a8..1c2d9eb 100644
--- a/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb
+++ b/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb
@@ -20,6 +20,9 @@ SRC_URI = "${SAVANNAH_GNU_MIRROR}/${BPN}/${BP}.tar.gz \
 SRC_URI[md5sum] = "fc5b03aae38b9b5b6880b31924d0ace3"
 SRC_URI[sha256sum] = "706fc2c1cf3dfbf87c941f543381bccc9c4dc9f8240eec407dcbf2f70b854320"
 
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[kpps] = ",,pps-tools"
+
 inherit scons update-rc.d python-dir pythonnative systemd
 
 INITSCRIPT_NAME = "gpsd"
-- 
1.8.5.5

Re: [meta-oe][PATCH 4/5] gpsd: add optional support for KPPS interface

[Burton, Ross]

On 28 August 2014 13:06, Peter A. Bigot <pab@pabigot.com> wrote:
> +PACKAGECONFIG ??= ""
> +PACKAGECONFIG[kpps] = ",,pps-tools"

That's not actually deterministic - if pps-tools is installed but the
packageconfig option is disabled then gpsd will still enable the
support.

Ross

Re: [meta-oe][PATCH 4/5] gpsd: add optional support for KPPS interface

[Peter A. Bigot]

On 08/28/2014 07:53 AM, Burton, Ross wrote:
> On 28 August 2014 13:06, Peter A. Bigot <pab@pabigot.com> wrote:
>> +PACKAGECONFIG ??= ""
>> +PACKAGECONFIG[kpps] = ",,pps-tools"
> That's not actually deterministic - if pps-tools is installed but the
> packageconfig option is disabled then gpsd will still enable the
> support.

Yeah, I'm aware of that.  It's also not something that can be 
controlled, since gpsd's author doesn't believe in configuration options 
to enable features: every capability is enabled or disabled by 
inspecting the environment at compile-time.

Although ntp does support some explicit enable/disable flags, it too 
fails to provide a way to say "Pay no attention to that PPS header, it 
isn't really there."

For this situation I don't think there's a big issue.  The PACKAGECONFIG 
setting ensures that the header will be available if the feature is 
desired.  If it happens to be present but PPS support isn't explicitly 
requested, there's no failure in either build or runtime: it's still 
gated by runtime checks for PPS sources and the option being enabled in 
the Linux kernel.  (There are no runtime libraries that need to be 
installed to use KPPS.)

Is this going to be a problem with the patch being accepted?

Peter

Re: [meta-oe][PATCH 4/5] gpsd: add optional support for KPPS interface

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

On Thu, Aug 28, 2014 at 08:05:54AM -0500, Peter A. Bigot wrote:
> On 08/28/2014 07:53 AM, Burton, Ross wrote:
> > On 28 August 2014 13:06, Peter A. Bigot <pab@pabigot.com> wrote:
> >> +PACKAGECONFIG ??= ""
> >> +PACKAGECONFIG[kpps] = ",,pps-tools"
> > That's not actually deterministic - if pps-tools is installed but the
> > packageconfig option is disabled then gpsd will still enable the
> > support.
> 
> Yeah, I'm aware of that.  It's also not something that can be 
> controlled, since gpsd's author doesn't believe in configuration options 
> to enable features: every capability is enabled or disabled by 
> inspecting the environment at compile-time.
> 
> Although ntp does support some explicit enable/disable flags, it too 
> fails to provide a way to say "Pay no attention to that PPS header, it 
> isn't really there."

Then we need to patch their configure.

> For this situation I don't think there's a big issue.  The PACKAGECONFIG 
> setting ensures that the header will be available if the feature is 
> desired.  If it happens to be present but PPS support isn't explicitly 
> requested, there's no failure in either build or runtime: it's still 
> gated by runtime checks for PPS sources and the option being enabled in 
> the Linux kernel.  (There are no runtime libraries that need to be 
> installed to use KPPS.)
> 
> Is this going to be a problem with the patch being accepted?

Yes

people can be used to have KPPS support enabled by "accident" e.g.
because they are building ntp with KPPS support and pps-tools is almost
always built before gpsd..

and then once it's built in different order and end-user will be
surprised by lost KPPS support from gpsd.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [meta-oe][PATCH 4/5] gpsd: add optional support for KPPS interface

[Peter A. Bigot]

On 08/28/2014 09:32 AM, Martin Jansa wrote:
> On Thu, Aug 28, 2014 at 08:05:54AM -0500, Peter A. Bigot wrote:
>> On 08/28/2014 07:53 AM, Burton, Ross wrote:
>>> On 28 August 2014 13:06, Peter A. Bigot <pab@pabigot.com> wrote:
>>>> +PACKAGECONFIG ??= ""
>>>> +PACKAGECONFIG[kpps] = ",,pps-tools"
>>> That's not actually deterministic - if pps-tools is installed but the
>>> packageconfig option is disabled then gpsd will still enable the
>>> support.
>> Yeah, I'm aware of that.  It's also not something that can be
>> controlled, since gpsd's author doesn't believe in configuration options
>> to enable features: every capability is enabled or disabled by
>> inspecting the environment at compile-time.
>>
>> Although ntp does support some explicit enable/disable flags, it too
>> fails to provide a way to say "Pay no attention to that PPS header, it
>> isn't really there."
> Then we need to patch their configure.
>
>> For this situation I don't think there's a big issue.  The PACKAGECONFIG
>> setting ensures that the header will be available if the feature is
>> desired.  If it happens to be present but PPS support isn't explicitly
>> requested, there's no failure in either build or runtime: it's still
>> gated by runtime checks for PPS sources and the option being enabled in
>> the Linux kernel.  (There are no runtime libraries that need to be
>> installed to use KPPS.)
>>
>> Is this going to be a problem with the patch being accepted?
> Yes
>
> people can be used to have KPPS support enabled by "accident" e.g.
> because they are building ntp with KPPS support and pps-tools is almost
> always built before gpsd..and then once it's built in different order and end-user will be
> surprised by lost KPPS support from gpsd.

The number of people who will use KPPS is incredibly small, and nobody's 
going to use it unintentionally as it requires on-target configuration.  
Those who need it, though, have no recourse other than to build ntpd or 
gpsd outside of OE if patches like these aren't present.

I understand the reasoning and agree in theory that absolute determinism 
would be ideal, but believe hacking the ntp and gpsd configuration 
infrastructure to explicitly disable use of a detected PPS header would 
present a bigger risk and long-term cost to stability and 
maintainability in OE than the possibility you've identified.  So that 
solution isn't something I'm going to take on.

An alternative is to add kpps to the default PACKAGECONFIG, so the 
required header is normally available.  The cost of the feature's 
presence in the packages is nearly zero (a slight increase in daemon 
code size, and an extra check when the process starts.)  Would that be 
acceptable?

If we can't come to an agreement, then the only patch that's really 
important is the first one which restores the ability to diagnose 
misconfigured NTP systems.  Please let me know whether I should mark the 
others as withdrawn in patchwork.

Peter

Re: [meta-oe][PATCH 4/5] gpsd: add optional support for KPPS interface

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3337 bytes --]

On Thu, Aug 28, 2014 at 10:23:54AM -0500, Peter A. Bigot wrote:
> On 08/28/2014 09:32 AM, Martin Jansa wrote:
> > On Thu, Aug 28, 2014 at 08:05:54AM -0500, Peter A. Bigot wrote:
> >> On 08/28/2014 07:53 AM, Burton, Ross wrote:
> >>> On 28 August 2014 13:06, Peter A. Bigot <pab@pabigot.com> wrote:
> >>>> +PACKAGECONFIG ??= ""
> >>>> +PACKAGECONFIG[kpps] = ",,pps-tools"
> >>> That's not actually deterministic - if pps-tools is installed but the
> >>> packageconfig option is disabled then gpsd will still enable the
> >>> support.
> >> Yeah, I'm aware of that.  It's also not something that can be
> >> controlled, since gpsd's author doesn't believe in configuration options
> >> to enable features: every capability is enabled or disabled by
> >> inspecting the environment at compile-time.
> >>
> >> Although ntp does support some explicit enable/disable flags, it too
> >> fails to provide a way to say "Pay no attention to that PPS header, it
> >> isn't really there."
> > Then we need to patch their configure.
> >
> >> For this situation I don't think there's a big issue.  The PACKAGECONFIG
> >> setting ensures that the header will be available if the feature is
> >> desired.  If it happens to be present but PPS support isn't explicitly
> >> requested, there's no failure in either build or runtime: it's still
> >> gated by runtime checks for PPS sources and the option being enabled in
> >> the Linux kernel.  (There are no runtime libraries that need to be
> >> installed to use KPPS.)
> >>
> >> Is this going to be a problem with the patch being accepted?
> > Yes
> >
> > people can be used to have KPPS support enabled by "accident" e.g.
> > because they are building ntp with KPPS support and pps-tools is almost
> > always built before gpsd..and then once it's built in different order and end-user will be
> > surprised by lost KPPS support from gpsd.
> 
> The number of people who will use KPPS is incredibly small, and nobody's 
> going to use it unintentionally as it requires on-target configuration.  
> Those who need it, though, have no recourse other than to build ntpd or 
> gpsd outside of OE if patches like these aren't present.
> 
> I understand the reasoning and agree in theory that absolute determinism 
> would be ideal, but believe hacking the ntp and gpsd configuration 
> infrastructure to explicitly disable use of a detected PPS header would 
> present a bigger risk and long-term cost to stability and 
> maintainability in OE than the possibility you've identified.  So that 
> solution isn't something I'm going to take on.
> 
> An alternative is to add kpps to the default PACKAGECONFIG, so the 
> required header is normally available.  The cost of the feature's 
> presence in the packages is nearly zero (a slight increase in daemon 
> code size, and an extra check when the process starts.)  Would that be 
> acceptable?

More acceptable than the undeterministic behavior - you should even add
it to DEPENDS.

> If we can't come to an agreement, then the only patch that's really 
> important is the first one which restores the ability to diagnose 
> misconfigured NTP systems.  Please let me know whether I should mark the 
> others as withdrawn in patchwork.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [meta-oe][PATCH 4/5] gpsd: add optional support for KPPS interface

[Peter A. Bigot]

On 08/28/2014 10:47 AM, Martin Jansa wrote:
> On Thu, Aug 28, 2014 at 10:23:54AM -0500, Peter A. Bigot wrote:
>> On 08/28/2014 09:32 AM, Martin Jansa wrote:
>>> On Thu, Aug 28, 2014 at 08:05:54AM -0500, Peter A. Bigot wrote:
>>>> On 08/28/2014 07:53 AM, Burton, Ross wrote:
>>>>> On 28 August 2014 13:06, Peter A. Bigot <pab@pabigot.com> wrote:
>>>>>> +PACKAGECONFIG ??= ""
>>>>>> +PACKAGECONFIG[kpps] = ",,pps-tools"
>>>>> That's not actually deterministic - if pps-tools is installed but the
>>>>> packageconfig option is disabled then gpsd will still enable the
>>>>> support.
>>>> Yeah, I'm aware of that.  It's also not something that can be
>>>> controlled, since gpsd's author doesn't believe in configuration options
>>>> to enable features: every capability is enabled or disabled by
>>>> inspecting the environment at compile-time.
>>>>
>>>> Although ntp does support some explicit enable/disable flags, it too
>>>> fails to provide a way to say "Pay no attention to that PPS header, it
>>>> isn't really there."
>>> Then we need to patch their configure.
>>>
>>>> For this situation I don't think there's a big issue.  The PACKAGECONFIG
>>>> setting ensures that the header will be available if the feature is
>>>> desired.  If it happens to be present but PPS support isn't explicitly
>>>> requested, there's no failure in either build or runtime: it's still
>>>> gated by runtime checks for PPS sources and the option being enabled in
>>>> the Linux kernel.  (There are no runtime libraries that need to be
>>>> installed to use KPPS.)
>>>>
>>>> Is this going to be a problem with the patch being accepted?
>>> Yes
>>>
>>> people can be used to have KPPS support enabled by "accident" e.g.
>>> because they are building ntp with KPPS support and pps-tools is almost
>>> always built before gpsd..and then once it's built in different order and end-user will be
>>> surprised by lost KPPS support from gpsd.
>> The number of people who will use KPPS is incredibly small, and nobody's
>> going to use it unintentionally as it requires on-target configuration.
>> Those who need it, though, have no recourse other than to build ntpd or
>> gpsd outside of OE if patches like these aren't present.
>>
>> I understand the reasoning and agree in theory that absolute determinism
>> would be ideal, but believe hacking the ntp and gpsd configuration
>> infrastructure to explicitly disable use of a detected PPS header would
>> present a bigger risk and long-term cost to stability and
>> maintainability in OE than the possibility you've identified.  So that
>> solution isn't something I'm going to take on.
>>
>> An alternative is to add kpps to the default PACKAGECONFIG, so the
>> required header is normally available.  The cost of the feature's
>> presence in the packages is nearly zero (a slight increase in daemon
>> code size, and an extra check when the process starts.)  Would that be
>> acceptable?
> More acceptable than the undeterministic behavior - you should even add
> it to DEPENDS.

So not make it configurable at all?

OK, I think that would be safe, and would eliminate the existing 
non-determinism.  I'll rework the patches to do that.

Peter

>> If we can't come to an agreement, then the only patch that's really
>> important is the first one which restores the ability to diagnose
>> misconfigured NTP systems.  Please let me know whether I should mark the
>> others as withdrawn in patchwork.
>

Re: [meta-oe][PATCH 4/5] gpsd: add optional support for KPPS interface

[Peter A. Bigot]

On 08/28/2014 10:23 AM, Peter A. Bigot wrote:
> On 08/28/2014 09:32 AM, Martin Jansa wrote:
>> On Thu, Aug 28, 2014 at 08:05:54AM -0500, Peter A. Bigot wrote:
>>> On 08/28/2014 07:53 AM, Burton, Ross wrote:
>>>> On 28 August 2014 13:06, Peter A. Bigot <pab@pabigot.com> wrote:
>>>>> +PACKAGECONFIG ??= ""
>>>>> +PACKAGECONFIG[kpps] = ",,pps-tools"
>>>> That's not actually deterministic - if pps-tools is installed but the
>>>> packageconfig option is disabled then gpsd will still enable the
>>>> support.
>>> Yeah, I'm aware of that.  It's also not something that can be
>>> controlled, since gpsd's author doesn't believe in configuration 
>>> options
>>> to enable features: every capability is enabled or disabled by
>>> inspecting the environment at compile-time.
>>>
>>> Although ntp does support some explicit enable/disable flags, it too
>>> fails to provide a way to say "Pay no attention to that PPS header, it
>>> isn't really there."
>> Then we need to patch their configure.
>>
>>> For this situation I don't think there's a big issue.  The 
>>> PACKAGECONFIG
>>> setting ensures that the header will be available if the feature is
>>> desired.  If it happens to be present but PPS support isn't explicitly
>>> requested, there's no failure in either build or runtime: it's still
>>> gated by runtime checks for PPS sources and the option being enabled in
>>> the Linux kernel.  (There are no runtime libraries that need to be
>>> installed to use KPPS.)
>>>
>>> Is this going to be a problem with the patch being accepted?
>> Yes
>>
>> people can be used to have KPPS support enabled by "accident" e.g.
>> because they are building ntp with KPPS support and pps-tools is almost
>> always built before gpsd..and then once it's built in different order 
>> and end-user will be
>> surprised by lost KPPS support from gpsd.
>
> The number of people who will use KPPS is incredibly small, and 
> nobody's going to use it unintentionally as it requires on-target 
> configuration.  Those who need it, though, have no recourse other than 
> to build ntpd or gpsd outside of OE if patches like these aren't present.
>
> I understand the reasoning and agree in theory that absolute 
> determinism would be ideal, but believe hacking the ntp and gpsd 
> configuration infrastructure to explicitly disable use of a detected 
> PPS header would present a bigger risk and long-term cost to stability 
> and maintainability in OE than the possibility you've identified.  So 
> that solution isn't something I'm going to take on.
>
> An alternative is to add kpps to the default PACKAGECONFIG, so the 
> required header is normally available.  The cost of the feature's 
> presence in the packages is nearly zero (a slight increase in daemon 
> code size, and an extra check when the process starts.) Would that be 
> acceptable?
>
> If we can't come to an agreement, then the only patch that's really 
> important is the first one which restores the ability to diagnose 
> misconfigured NTP systems.  Please let me know whether I should mark 
> the others as withdrawn in patchwork.

If it matters, note that withdrawing the patches won't change the status 
quo: ntpd and gpsd are feature-sensitive to the presence of 
sys/timepps.h in the build environment, e.g. if pps-tools is added by 
another layer.  The only difference is that without the patches there's 
no clue in their recipes that this could happen and no way to provide 
determinism in the want-kpps situation.

Peter

Re: [meta-oe][PATCH 4/5] gpsd: add optional support for KPPS interface

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 4059 bytes --]

On Thu, Aug 28, 2014 at 10:48:59AM -0500, Peter A. Bigot wrote:
> On 08/28/2014 10:23 AM, Peter A. Bigot wrote:
> > On 08/28/2014 09:32 AM, Martin Jansa wrote:
> >> On Thu, Aug 28, 2014 at 08:05:54AM -0500, Peter A. Bigot wrote:
> >>> On 08/28/2014 07:53 AM, Burton, Ross wrote:
> >>>> On 28 August 2014 13:06, Peter A. Bigot <pab@pabigot.com> wrote:
> >>>>> +PACKAGECONFIG ??= ""
> >>>>> +PACKAGECONFIG[kpps] = ",,pps-tools"
> >>>> That's not actually deterministic - if pps-tools is installed but the
> >>>> packageconfig option is disabled then gpsd will still enable the
> >>>> support.
> >>> Yeah, I'm aware of that.  It's also not something that can be
> >>> controlled, since gpsd's author doesn't believe in configuration 
> >>> options
> >>> to enable features: every capability is enabled or disabled by
> >>> inspecting the environment at compile-time.
> >>>
> >>> Although ntp does support some explicit enable/disable flags, it too
> >>> fails to provide a way to say "Pay no attention to that PPS header, it
> >>> isn't really there."
> >> Then we need to patch their configure.
> >>
> >>> For this situation I don't think there's a big issue.  The 
> >>> PACKAGECONFIG
> >>> setting ensures that the header will be available if the feature is
> >>> desired.  If it happens to be present but PPS support isn't explicitly
> >>> requested, there's no failure in either build or runtime: it's still
> >>> gated by runtime checks for PPS sources and the option being enabled in
> >>> the Linux kernel.  (There are no runtime libraries that need to be
> >>> installed to use KPPS.)
> >>>
> >>> Is this going to be a problem with the patch being accepted?
> >> Yes
> >>
> >> people can be used to have KPPS support enabled by "accident" e.g.
> >> because they are building ntp with KPPS support and pps-tools is almost
> >> always built before gpsd..and then once it's built in different order 
> >> and end-user will be
> >> surprised by lost KPPS support from gpsd.
> >
> > The number of people who will use KPPS is incredibly small, and 
> > nobody's going to use it unintentionally as it requires on-target 
> > configuration.  Those who need it, though, have no recourse other than 
> > to build ntpd or gpsd outside of OE if patches like these aren't present.
> >
> > I understand the reasoning and agree in theory that absolute 
> > determinism would be ideal, but believe hacking the ntp and gpsd 
> > configuration infrastructure to explicitly disable use of a detected 
> > PPS header would present a bigger risk and long-term cost to stability 
> > and maintainability in OE than the possibility you've identified.  So 
> > that solution isn't something I'm going to take on.
> >
> > An alternative is to add kpps to the default PACKAGECONFIG, so the 
> > required header is normally available.  The cost of the feature's 
> > presence in the packages is nearly zero (a slight increase in daemon 
> > code size, and an extra check when the process starts.) Would that be 
> > acceptable?
> >
> > If we can't come to an agreement, then the only patch that's really 
> > important is the first one which restores the ability to diagnose 
> > misconfigured NTP systems.  Please let me know whether I should mark 
> > the others as withdrawn in patchwork.
> 
> If it matters, note that withdrawing the patches won't change the status 
> quo: ntpd and gpsd are feature-sensitive to the presence of 
> sys/timepps.h in the build environment, e.g. if pps-tools is added by 
> another layer.  The only difference is that without the patches there's 
> no clue in their recipes that this could happen and no way to provide 
> determinism in the want-kpps situation.

That's why I'm building world builds with many builds (to possibly
find as many issues like this as possible).

If it's in some private layer we cannot do much about it, but we can
prevent this happening in meta-oe itself by careful review :).

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [meta-oe][PATCH 4/5] gpsd: add optional support for KPPS interface

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

On Thu, Aug 28, 2014 at 07:06:20AM -0500, Peter A. Bigot wrote:
> gpsd by default builds with PPS (pulse-per-second) support, but without
> kernel support to capture the edge of the pulse the accuracy is only
> +/-5us.  Under Linux the pps-tools package installs the header required
> for the user-level API to the RFC 2783 KPPS interface.  If gpsd detects
> this header, it will use the API to improve accuracy to +/-1us.
> 
> See: http://www.catb.org/gpsd/gpsd-time-service-howto.html#_enabling_pps
> 
> Signed-off-by: Peter A. Bigot <pab@pabigot.com>
> ---
>  meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb b/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb
> index d12c7a8..1c2d9eb 100644
> --- a/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb
> +++ b/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb
> @@ -20,6 +20,9 @@ SRC_URI = "${SAVANNAH_GNU_MIRROR}/${BPN}/${BP}.tar.gz \
>  SRC_URI[md5sum] = "fc5b03aae38b9b5b6880b31924d0ace3"
>  SRC_URI[sha256sum] = "706fc2c1cf3dfbf87c941f543381bccc9c4dc9f8240eec407dcbf2f70b854320"
>  
> +PACKAGECONFIG ??= ""
> +PACKAGECONFIG[kpps] = ",,pps-tools"

Both recipes need some way of explicit disable of pps-tools, so that the
result is the same when building gpsd or ntp before or after pps-tools.

>  inherit scons update-rc.d python-dir pythonnative systemd
>  
>  INITSCRIPT_NAME = "gpsd"
> -- 
> 1.8.5.5
> 
> -- 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

[meta-oe][PATCH v2] gpsd: add deterministic support for KPPS interface

[Peter A. Bigot]

gpsd enables low-precision PPS (pulse-per-second) support by default,
but only includes the high-precision kernel API capabilities if
sys/timepps.h is also detected.  Under Linux the pps-tools package
installs this header.  Remove the feature non-determinism and increase
gpsd capabilities by adding an explicit dependency.

See: http://www.catb.org/gpsd/gpsd-time-service-howto.html#_enabling_pps

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
V2: replace PACKAGECONFIG with DEPENDS to remove nondeterminism

 meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb b/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb
index d12c7a8..6d3adc1 100644
--- a/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb
+++ b/meta-oe/recipes-navigation/gpsd/gpsd_3.10.bb
@@ -2,7 +2,7 @@ SUMMARY = "A TCP/IP Daemon simplifying the communication with GPS devices"
 SECTION = "console/network"
 LICENSE = "BSD"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d217a23f408e91c94359447735bc1800"
-DEPENDS = "dbus dbus-glib ncurses python libusb1 chrpath-replacement-native"
+DEPENDS = "dbus dbus-glib ncurses python libusb1 chrpath-replacement-native pps-tools"
 PROVIDES = "virtual/gpsd"
 
 EXTRANATIVEPATH += "chrpath-native"
-- 
1.8.5.5

[meta-oe][PATCH 5/5] ntp: add optional support for KPPS interface

[Peter A. Bigot]

ntp checks for presence of sys/timepps.h to determine whether the kernel
supports the RFC 2783 KPPS interface.  Without this feature the ATOM
clock driver does not work, and other drivers like NMEA require offset
configuration.

See: http://doc.ntp.org/4.2.6/kernpps.html

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta-networking/recipes-support/ntp/ntp.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta-networking/recipes-support/ntp/ntp.inc b/meta-networking/recipes-support/ntp/ntp.inc
index 55926e0..fc50fe3 100644
--- a/meta-networking/recipes-support/ntp/ntp.inc
+++ b/meta-networking/recipes-support/ntp/ntp.inc
@@ -47,6 +47,7 @@ PACKAGECONFIG[openssl] = "--with-openssl-libdir=${STAGING_LIBDIR} \
 PACKAGECONFIG[cap] = "--enable-linuxcaps,--disable-linuxcaps,libcap"
 PACKAGECONFIG[readline] = "--with-lineeditlibs,--without-lineeditlibs,readline"
 PACKAGECONFIG[debug] = "--enable-debugging,--disable-debugging"
+PACKAGECONFIG[kpps] = ",,pps-tools"
 
 do_install_append() {
     install -d ${D}${sysconfdir}/init.d
-- 
1.8.5.5

[meta-networking][PATCH v2] ntp: add deterministic support for KPPS interface

[Peter A. Bigot]

ntp checks for presence of sys/timepps.h to determine whether the kernel
supports the RFC 2783 KPPS interface.  Under Linux the pps-tools package
installs this header.  Without this feature the ATOM clock driver does
not work, and other drivers like NMEA have reduced precision.  Remove
the feature non-determinism and increase ntpd capabilities by adding an
explicit dependency.

See: http://doc.ntp.org/4.2.6/kernpps.html

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
V2: replace PACKAGECONFIG with DEPENDS to remove nondeterminism

 meta-networking/recipes-support/ntp/ntp.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta-networking/recipes-support/ntp/ntp.inc b/meta-networking/recipes-support/ntp/ntp.inc
index 55926e0..f55a39a 100644
--- a/meta-networking/recipes-support/ntp/ntp.inc
+++ b/meta-networking/recipes-support/ntp/ntp.inc
@@ -8,6 +8,8 @@ SECTION = "console/network"
 LICENSE = "NTP"
 LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=fea4b50c33b18c2194b4b1c9ca512670"
 
+DEPENDS = "pps-tools"
+
 INC_PR = "r6"
 
 SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.gz \
-- 
1.8.5.5

Re: [meta-networking][PATCH v2] ntp: add deterministic support for KPPS interface

[Rongqing Li]

On 08/29/2014 01:43 AM, Peter A. Bigot wrote:
> ntp checks for presence of sys/timepps.h to determine whether the kernel
> supports the RFC 2783 KPPS interface.  Under Linux the pps-tools package
> installs this header.  Without this feature the ATOM clock driver does
> not work, and other drivers like NMEA have reduced precision.  Remove
> the feature non-determinism and increase ntpd capabilities by adding an
> explicit dependency.
>
> See: http://doc.ntp.org/4.2.6/kernpps.html
>
> Signed-off-by: Peter A. Bigot <pab@pabigot.com>
> ---
> V2: replace PACKAGECONFIG with DEPENDS to remove nondeterminism
>
>   meta-networking/recipes-support/ntp/ntp.inc | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/meta-networking/recipes-support/ntp/ntp.inc b/meta-networking/recipes-support/ntp/ntp.inc
> index 55926e0..f55a39a 100644
> --- a/meta-networking/recipes-support/ntp/ntp.inc
> +++ b/meta-networking/recipes-support/ntp/ntp.inc
> @@ -8,6 +8,8 @@ SECTION = "console/network"
>   LICENSE = "NTP"
>   LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=fea4b50c33b18c2194b4b1c9ca512670"
>
> +DEPENDS = "pps-tools"

Could we add this dependent by PACKAGECONFIG?

-R


> +
>   INC_PR = "r6"
>
>   SRC_URI = "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.gz \
>

-- 
Best Reagrds,
Roy | RongQing Li

Re: [meta-networking][PATCH v2] ntp: add deterministic support for KPPS interface

[Peter A. Bigot]

On 09/29/2014 02:50 AM, Rongqing Li wrote:
>
>
> On 08/29/2014 01:43 AM, Peter A. Bigot wrote:
>> ntp checks for presence of sys/timepps.h to determine whether the kernel
>> supports the RFC 2783 KPPS interface.  Under Linux the pps-tools package
>> installs this header.  Without this feature the ATOM clock driver does
>> not work, and other drivers like NMEA have reduced precision. Remove
>> the feature non-determinism and increase ntpd capabilities by adding an
>> explicit dependency.
>>
>> See: http://doc.ntp.org/4.2.6/kernpps.html
>>
>> Signed-off-by: Peter A. Bigot <pab@pabigot.com>
>> ---
>> V2: replace PACKAGECONFIG with DEPENDS to remove nondeterminism
>>
>>   meta-networking/recipes-support/ntp/ntp.inc | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/meta-networking/recipes-support/ntp/ntp.inc 
>> b/meta-networking/recipes-support/ntp/ntp.inc
>> index 55926e0..f55a39a 100644
>> --- a/meta-networking/recipes-support/ntp/ntp.inc
>> +++ b/meta-networking/recipes-support/ntp/ntp.inc
>> @@ -8,6 +8,8 @@ SECTION = "console/network"
>>   LICENSE = "NTP"
>>   LIC_FILES_CHKSUM = 
>> "file://COPYRIGHT;md5=fea4b50c33b18c2194b4b1c9ca512670"
>>
>> +DEPENDS = "pps-tools"
>
> Could we add this dependent by PACKAGECONFIG?

That was my original intent, but it was rejected as non-deterministic.  
See discussion at: http://patchwork.openembedded.org/patch/79279/

Peter