Build Broken for RHEL/Cent 6 - undefined reference to `clock_settime'

[Jason Azze]

I discovered my Jenkins system hasn't been triggering builds on SCM
changes since the 18th.

Somewhere in the big changeset listed below, RHEL/Cent 6 got broken again.

(Sorry for the links to localhost in the output.)

CentOS 7 and Fedora 24 are still building OK, as is Ubuntu 14 and 16.

-- Forwarded message --
From:  
Date: Sat, Oct 22, 2016 at 11:48 AM
Subject: Build failed in Jenkins: NTPsec_multiplatform » puppet #338
To: ja...@azze.org


http://localhost:8080/job/NTPsec_multiplatform/slave=puppet/338/Changes:

[esr] In pyntpq, three more commands - the association listers - are mow

[esr] Remove some test code no longer needed.

[esr] Typo fixes annd minor refactoring.  Make attribute dictionaries

[esr] Complwrw a structure name change and do some information hiding.

[esr] Ensure that Python code cannot fall out of sync with magic ntp.h

[gem] ntpviz: stop splitting/joining, keep lines as lists.

[gem] ntpviz: remove 3 unused functions.

[gem] ntpviz: 30% speedup.  Better to write plot to tmp file than pipe it.

[esr] Fix build breakage die to generared Python having casts.

[gem] ntpviz: fix --help option. % strikes again...

[gem] ntpviz: fix --local-error, remove stry \n's.

[gem] ntpviz: remove dead code.

[gem] ntpviz: cut the size of the plot file data again.

[gem] ntpviz: tweak ntpviz man page.  Describe -D levels.

[esr] Break a coincidental cohesion.

[esr] In which we discover that init_lib() is pointless,,,

[esr] Remove unneeded code.

[esr] Remove an incorrect byte swap.

[esr] Create a C extension to make libntp functions available to Python.

[gem] ntpviz: typo.  95% is actually 98%

[esr] Add prettydate to Python extension to use it in pyntpq.

[esr] Document the requirement for Python.h and friends.

[esr] Improve Python 3 compatibility.

[esr] The libopts libray is long dead.  Decomplicate the build recipe.

[esr] Remove unecessary things from link lines.

[gem] ntpviz: Don't plot a line during data abcense

[esr] Accept hex literals in Mode 6 responses.

[esr] Add pyntpq code to validate association IDs and indices.

[esr] Address Gitlab issue #128: git head fails on debian 7 x86_64

--

Started by upstream project "NTPsec_multiplatform" build number 338
originally caused by:
 Started by user anonymous
Building remotely on puppet (scons waf lin64) in workspace
/home/jenkins/workspace/NTPsec_multiplatform/slave/puppet
[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Done
Cloning the remote Git repository
Cloning repository https://gitlab.com/NTPsec/ntpsec.git
 > git init /home/jenkins/workspace/NTPsec_multiplatform/slave/puppet
# timeout=10
Fetching upstream changes from https://gitlab.com/NTPsec/ntpsec.git
 > git --version # timeout=10
 > git fetch --tags --progress https://gitlab.com/NTPsec/ntpsec.git
+refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url https://gitlab.com/NTPsec/ntpsec.git #
timeout=10
 > git config --add remote.origin.fetch
+refs/heads/*:refs/remotes/origin/* # timeout=10
 > git config remote.origin.url https://gitlab.com/NTPsec/ntpsec.git #
timeout=10
Fetching upstream changes from https://gitlab.com/NTPsec/ntpsec.git
 > git fetch --tags --progress https://gitlab.com/NTPsec/ntpsec.git
+refs/heads/*:refs/remotes/origin/*
Checking out Revision b6f3094e73748f3a6982e71ff8c0575b37e32e06
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f b6f3094e73748f3a6982e71ff8c0575b37e32e06
 > git rev-list 308cc666355c0fb6d1b546620aa656b1d89652c0 # timeout=10
[puppet] $ /bin/sh -xe /tmp/hudson7715452463132933101.sh
+ ./waf configure --refclock=all
Setting top to   :
/home/jenkins/workspace/NTPsec_multiplatform/slave/puppet
Setting out to   :
/home/jenkins/workspace/NTPsec_multiplatform/slave/puppet/build
--- Configuring host ---
Checking for 'gcc' (C compiler)  : /usr/bin/gcc
Checking for program 'bison' : /usr/bin/bison
Checking compiler: yes
Compiler found   : GCC
Checking for program 'awk'   : /bin/awk
Checking for program 'sh': /bin/sh
Checking for program 'asciidoc'  : /usr/local/bin/asciidoc
Checking for program 'a2x'   : /usr/local/bin/a2x
Checking for program 'xsltproc'  : /usr/bin/xsltproc
Checking for program 'git'   : /usr/bin/git
DEVEL: Getting revision  :
b6f3094e73748f3a6982e71ff8c0575b37e32e06
Building version : 0.9.5-b6f3094
--- Configuring main ---
Checking build target: unix
Checking for type uint64_t   : yes
Checking for type struct if_laddrconf: no
Checking for type struct if_laddrreq : no
Checking for type struct timex   : yes
Checking for type struct ntptimeval  : yes
Checking for time_tick in struct timex   : no
Checking for modes in 

Re: Proposal - drop the GPSD JSON driver

[Eric S. Raymond]

Hal Murray :
> >> I assume that using a pipe or socket rather than SHM would fix that.
> 
> > Probably, but then we run unto buffering jitter again.
> 
> Are we on the same wavelength yet?  Have we agreed that latency is not 
> critical?  If so, why is jitter important?

It is possible that I am confused.

What ntpd gets from a clock source is a series of pairs asserting
"at system time X I believe it was UTC time Y".

Are you telling me there is no value in minimizing the time from X to when
the sample triggers a correction, and the variation in that time?

Basic servocontrol theory tells me that control lag is the enemy of
precision and tends to produce whiplash effects.  Does that not apply here?
-- 
http://www.catb.org/~esr/;>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Proposal - drop the GPSD JSON driver

[Hal Murray]

>> Word-length mismatch between two programs built under the same OS
>> never happens, or close enough to never that I don't care.
> Uh, no.  remember when intel OS went from 32 bit to 64-bit?  It was a huge
> issue with ntpd.  RasPi is about to have the same problems. 

What sort of problem do you expect?

I'd expect troubles if you tried to run a 32 bit gpsd or 32 bit ntpd on a 64 
bit system (using 32 bit libraries) while the other one was 64 bit and the 
shared struct used int or long rather than int32_t and friends.

I just checked ntpd/refclock_shm.c
It's got int's, no longs.  So does gpsd.
We should make things explicit for the great SHM cleanup.
It's also got time_t.   That will break the 32/64 bit combination on Fedora.  
It's 4 bytes on 32 bit systems and 8 bytes on 64 bit systems.



>> As Hal points out, if you version-number the struct properly you can
>> add fields at the end ad libitum.
> IFF you do it right, AND chose a transport that can handle varying lengths.
> Traditional SHM can not do that.  The current NTP SHM can not do that. 

The current SHM setup was extended to support nanoseconds without breaking old 
code.  (and it doesn't even have a version number slot)



-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Proposal - drop the GPSD JSON driver

[Gary E. Miller]

Yo Hal!

On Sat, 22 Oct 2016 03:15:01 -0700
Hal Murray  wrote:

> >> Word-length mismatch between two programs built under the same OS
> >> never happens, or close enough to never that I don't care.  
> > Uh, no.  remember when intel OS went from 32 bit to 64-bit?  It was
> > a huge issue with ntpd.  RasPi is about to have the same
> > problems.   
> 
> What sort of problem do you expect?

Uh, the one I described in the previous email.  Binary C structures
will not match.  Pain ensues, just like last time.

> I'd expect troubles if you tried to run a 32 bit gpsd or 32 bit ntpd
> on a 64 bit system (using 32 bit libraries) while the other one was
> 64 bit and the shared struct used int or long rather than int32_t and
> friends.

Ah, so we agree, yes, those configurations will be problematic.  We
live through that in the intel 32 -> 64 bit treansition, we are about to
live through it again on the ARM.

> I just checked ntpd/refclock_shm.c

Yeah, ugly, ugly, ugly.

> >> As Hal points out, if you version-number the struct properly you
> >> can add fields at the end ad libitum.  
> > IFF you do it right, AND chose a transport that can handle varying
> > lengths. Traditional SHM can not do that.  The current NTP SHM can
> > not do that.   
> 
> The current SHM setup was extended to support nanoseconds without
> breaking old code.  (and it doesn't even have a version number slot)

Yeah, but a ton if extensions not done because it would break old code.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgp_59OU7SE08.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Proposal - drop the GPSD JSON driver

[Gary E. Miller]

Yo Eric!

On Sat, 22 Oct 2016 09:21:59 -0400
"Eric S. Raymond"  wrote:

> Hal Murray :
> > >> I assume that using a pipe or socket rather than SHM would fix
> > >> that.  
> >   
> > > Probably, but then we run unto buffering jitter again.  
> > 
> > Are we on the same wavelength yet?  Have we agreed that latency is
> > not critical?  If so, why is jitter important?  
> 
> It is possible that I am confused.

Now we agree.  :-)
 
> What ntpd gets from a clock source is a series of pairs asserting
> "at system time X I believe it was UTC time Y".

Yes.

> Are you telling me there is no value in minimizing the time from X to
> when the sample triggers a correction, and the variation in that time?

Yes. ntpd sits on the data, by default, for 32 seconds average, and 64
seconds max.  The big ntpd loop only goes around every second.  A few
micro seconds is not releavnt.  Long term tests on GPSD-JSON confirm this.

> Basic servocontrol theory tells me that control lag is the enemy of
> precision and tends to produce whiplash effects.  Does that not apply
> here?

With all the averaging, filtering and polling, the transit time from
delta generation to ntpd input is way less then 3 orders of magnitude
less than the ntpd control loop cycle (one second).  Then when 
ntpd averages the deltas over 64 seconds all immmediacy is lost.

But don't believe me, or my long term GPSD-experiments, set up your own.
Not hard.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgp1PmhgBrp9Z.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Proposal - drop the GPSD JSON driver

[Gary E. Miller]

Yo Hal!

On Sat, 22 Oct 2016 02:31:01 -0700
Hal Murray  wrote:

> >> I assume that using a pipe or socket rather than SHM would fix
> >> that.  
> 
> > Probably, but then we run unto buffering jitter again.  
> 
> Are we on the same wavelength yet?  Have we agreed that latency is
> not critical?  If so, why is jitter important?


Latency is critical, jitter is important, but the GPSD-JSON driver does
not add any.  As you said ealier, the deltas are computed in the kernel
(for KPPS) or in gpsd (for PPS).  The gpsd sends that to ntpd. ntpd does
not even look at that interval more often than the defaullt 64s poll
interval.  So a few extra fractions of a second encoding, transmitting,
and decoding, is swamped in the 64s poll interval.  Even with the now
possible 1 second poll it in insignificant.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgps2hBLrouuN.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Python.h is broken on NetBSD and FreeBSD

[Eric S. Raymond]

Hal Murray :
> How does that work?
> 
> On Linux, it's in:
>   /usr/include/python2.7/Python.h
> but the code does:
>   #include 
> 
> On NetBSD, it's in:
>   /usr/pkg/include/python2.7/Python.h
> 
> On FreeBSD, it's in:
>   /usr/local/include/python2.7/Python.h

What the build system is expected to do is add the local path to Python.h
to the list of inclusions it passes to the compilation of your project's
Python extension or extensions.

(For the uniniatiated: A Python extension is a shared library that makes
the C functions in it available as though they were part of a loadable
Python module. I needed to build a Python extension to make certain functions
from libntp visible to the Python translation of ntpq - in particular the
code for handling l_fp timestamps.  Trying to duplicate that in pure Python
would have been insane.)

Matt Selsky and I are looking into that right now. We think waf has the
capability to autoconfigure this, but the documentation is rather opaque.
It's going to take some digging.

(The extension will also help when we replace the C ntpdig and write
the so-far-hypothetical ntpshark.)

Boosted by this, the translation is going very well. I now have about
3/4ths of the command set implemented, including the all-important
"peers" command. Various unusual cases still need polishing and testing.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Python.h is broken on NetBSD and FreeBSD

[Hal Murray]

How does that work?

On Linux, it's in:
  /usr/include/python2.7/Python.h
but the code does:
  #include 

On NetBSD, it's in:
  /usr/pkg/include/python2.7/Python.h

On FreeBSD, it's in:
  /usr/local/include/python2.7/Python.h


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel