Re: 1.1.6 build fails on FC30
On Thu, 16 Apr 2020, Hal Murray via devel wrote: Because RS232 signaling is negative logic. That's what I used to think, but somebody corrected me many years ago. The data is upside down but the control signals are not. From https://en.wikipedia.org/wiki/RS-232 under Voltage levels For data transmission lines (TxD, RxD, and their secondary channel equivalents), logic one is represented as a negative voltage and the signal condition is called "mark". Logic zero is signaled with a positive voltage and the signal condition is termed "space". Control signals have the opposite polarity: the asserted or active state is positive voltage and the de-asserted or inactive state is negative voltage. Examples of control lines include request to send (RTS), clear to send (CTS), data terminal ready (DTR), and data set ready (DSR). But the polarity difference between data and control lines is precisely the reason for the inversion. TTL RxD/TxD signals are active-high, while RS-232 RxD/TxD signals are active-low. The common level converters take this into account, and hence are inverting. This means that active-high RS-232 control lines become active-low TTL control lines when the same level converters are used. That being said, there's nothing in the RS-232 standard about repurposing a line meant for modem control for a PPS signal, so there's no "official standard" for the polarity, and it's up to the receiver to decide that. Unless it clearly states the polarity in the spec, you should check. Fred Wright ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
> Because RS232 signaling is negative logic. That's what I used to think, but somebody corrected me many years ago. The data is upside down but the control signals are not. >From https://en.wikipedia.org/wiki/RS-232 under Voltage levels For data transmission lines (TxD, RxD, and their secondary channel equivalents), logic one is represented as a negative voltage and the signal condition is called "mark". Logic zero is signaled with a positive voltage and the signal condition is termed "space". Control signals have the opposite polarity: the asserted or active state is positive voltage and the de-asserted or inactive state is negative voltage. Examples of control lines include request to send (RTS), clear to send (CTS), data terminal ready (DTR), and data set ready (DSR). -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
Udo van den Heuvel via devel writes: > On 16-04-2020 21:15, Achim Gratz via devel wrote: >>If so, you must use the clear edge of the PPS (flag2 1). > > Why is that? Because RS232 signaling is negative logic. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
>> If so, you must use the clear edge of the PPS (flag2 1).
> Why is that?
Which edge you should use depends on the device and how you wired it up.
Most PPS devices are setup so you should use the rising/assert edge. If you
run it through an RS-232 level shifter, they contain an inverter so you should
use the other edge.
If the width of the PPS is wide enough, you can figure out which edge to use
by looking at the output from ntpq -p when the system time is close, probably
because ntpd is using other NTP servers. Typical low cost GPS units have a
100 ms or 500 ms pulse. If it is off that much, try the other edge.
If you have a high end system with a narrow PPS, I'd try something like:
$ cat /sys/devices/virtual/pps/pps0/{assert,clear}
You have to do that after setting up the PPS but before running ntpd. It
disables the edge it's not using.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 16-04-2020 21:15, Achim Gratz via devel wrote: >If so, you must use the clear edge of the PPS (flag2 1). Why is that? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
Udo van den Heuvel via devel writes: > refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.0006 time2 > 0.260 baud 4800 Your time1 value doesn't make any sense. You should use the highest baud rate you can configure on your device, if you need to stick with 4800 you must restrict the mesage type so that the GPS actually can send all data well before the second is over. Last and most importantly, I believe you showed before that you get your PPS in via serial line discipline. If so, you must use the clear edge of the PPS (flag2 1). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 16-04-2020 11:31, Hal Murray wrote: >> I could switch to a NMEA clock sans PPS and a dedicated PPS clock? > > That's what I would try. So I went to: ##NMEA zonder PPS refclock nmea unit 0 mode 7 flag3 1 flag2 0 flag1 0 time1 0.0006 time2 0.260 baud 4800 # ## PPS van dezelfde NMEA GPS refclock pps unit 0 flag2 0 A NMEA clock without, a PPS clock with PPS. (If I did that correctly) I also switches the two Garmin GPS18X's between this box and the firewall. On this workstation I see: $ ntpq -pn remote refid st t when poll reach delay offset jitter == xNMEA(0).GPS.0 l 18 64 377 0. -331.787 23.4930 xPPS(0) .PPS.0 l7 64 377 0. -0.8792 0.1323 +192.168.10.98 .GPS.1 u 98 128 377 0.2679 -0.7279 0.1074 *fd00:c0a8:a00: .GPS.1 u 126 128 377 0.2856 -0.5707 0.2049 2606:4700:f1:: .STEP. 16 1- 5120 0. 0. 0.0010 -2405:fc00:0:1: .PPS.1 8 104 128 377 172.2620 1.3215 1.2845 -2001:470:e815: .PPS.1 8 115 128 377 174.3298 -8.0867 1.0422 (cut) So I start to think the serial port might have an issue? The firewall shows: # ntpq -pn remote refid st t when poll reach delay offset jitter === oNMEA(0) .GPS.0 l 40 64 377 0. 0.1373 0. fd00:c0a8:a00:1 165.216.214.155 2 u8 64 377 0.3301 0.9063 0.1030 192.168.10.70 165.216.214.155 2 u 55 64 377 0.2456 0.8751 0.0562 2606:4700:f1::1 .NTS. 16 4- 2560 0. 0. 0.0010 -2a01:3f7:2:202: 194.58.202.202 8 30 64 377 36.1680 2.4365 0.9056 #2a03:b0c0:1:d0: 37.15.221.1892 8 43 64 377 23.1451 2.6572 1.8014 +2001:888:0:7::2 193.67.79.2022 u 23 64 377 14.3002 3.6927 0.3338 (cut) (also with kernel discipline) This looks more normal? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
> I could switch to a NMEA clock sans PPS and a dedicated PPS clock? That's what I would try. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 16-04-2020 00:55, Hal Murray wrote: >> So no error messages about gps/NMEA. > >> NMEA(0) .GPS.0 l 15 64 377 >> 0. 0. 0.0019 > > What's the line for that in your ntp.conf? Any fudge lines? driftfile /var/lib/ntp/drift nts key /etc/letsencrypt/keys/_key-certbot.pem nts cert /etc/letsencrypt/csr/_csr-certbot.pem restrict default nomodify nopeer noquery restrict -6 default nomodify nopeer noquery restrict 127.0.0.1 restrict -6 ::1 restrict 192.168.10.0 mask 255.255.255.0 nomodify refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.0006 time2 0.260 baud 4800 disable monitor server 192.168.10.98 minpoll 4 iburst server fd00:c0a8:a00:1::1 server time.cloudflare.com:1234 nts # TLS1.3 only server ntpmon.dcs1.biz nts server pi4.rellim.com nts server ntp1.glypnod.com nts server ntp2.glypnod.com nts server ntp.xs4all.nl server ntp2.xs4all.nl server ntp0.nl.net server ntp2.nl.net server keetweej.vanheusden.com server ntp.nmi.nl includefile /etc/ntp/crypto/pw keys /etc/ntp/keys statsdir /var/log/ntp/ logconfig =syncall -clockall We have some `time`in place. See the nmea refclock. Has been there for ages. > What does stty say for the baud rate? # stty < /dev/ttyS0 speed 4800 baud; line = 18; intr = ; quit = ; erase = ; kill = ; eof = ; start = ; stop = ; susp = ; rprnt = ; werase = ; lnext = ; discard = ; ignbrk -brkint -imaxbel -opost -onlcr -isig -iexten -echo -echoe -echok -echoctl -echoke > What sort of GPS device ? What baud rate is it using? Garmin GPS18X 4800 bps. > Try stopping ntpd and running cat /dev/whatever > That should show some NMEA sentences. It does, even with the ntpd running. > The 377 reach shows that something is working but the rest of the line shows > that it isn't. > > The NMEA driver is strange in that it tries to merge both the NMEA and PPS. > I > guess that's good if it works, but it makes debugging things like this > complicated. I could switch to a NMEA clock sans PPS and a dedicated PPS clock? > I run with 2 separate servers. Here is the chunk from my ntp.conf > > server 127.127.20.0 prefer path /dev/ttyAMA0 mode 0x010011 > fudge 127.127.20.0 flag1 0# disable PPS > fudge 127.127.20.0 time2 0.600# Fixup offset > server 127.127.22.0# PPS signal, needs prefer > fudge 127.127.22.0 flag2 0# Rising edge > > That turns into: > *NMEA(0) .GPS.0 l 31 64 377 0. 10.9381 > 27.6977 > oPPS(0) .PPS.0 l 30 64 377 0. 0.0570 > 0.0004 Like more or less what I understand from this part... Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
> So no error messages about gps/NMEA. > NMEA(0) .GPS.0 l 15 64 377 > 0. 0. 0.0019 What's the line for that in your ntp.conf? Any fudge lines? What does stty say for the baud rate? What sort of GPS device ? What baud rate is it using? Try stopping ntpd and running cat /dev/whatever That should show some NMEA sentences. The 377 reach shows that something is working but the rest of the line shows that it isn't. The NMEA driver is strange in that it tries to merge both the NMEA and PPS. I guess that's good if it works, but it makes debugging things like this complicated. I run with 2 separate servers. Here is the chunk from my ntp.conf server 127.127.20.0 prefer path /dev/ttyAMA0 mode 0x010011 fudge 127.127.20.0 flag1 0# disable PPS fudge 127.127.20.0 time2 0.600# Fixup offset server 127.127.22.0# PPS signal, needs prefer fudge 127.127.22.0 flag2 0# Rising edge That turns into: *NMEA(0) .GPS.0 l 31 64 377 0. 10.9381 27.6977 oPPS(0) .PPS.0 l 30 64 377 0. 0.0570 0.0004 -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 12-04-2020 17:35, Udo van den Heuvel via devel wrote: > On 12-04-2020 17:25, ASSI via devel wrote: >>> # ppswatch /chroot/ntpd/dev/pps0 >>> (shows similar output) >> >> Good, but does ntpd see the same? > > Well, devices look like this: And pps debug messages: # dmesg|grep event [ 408.583301] pps pps0: PPS event at 1586955482.000224958 [ 408.783290] pps pps0: PPS event at 1586955482.200221526 [ 409.583276] pps pps0: PPS event at 1586955483.000216947 [ 409.783279] pps pps0: PPS event at 1586955483.200224550 [ 410.583256] pps pps0: PPS event at 1586955484.000219902 [ 410.783257] pps pps0: PPS event at 1586955484.200224501 [ 411.583231] pps pps0: PPS event at 1586955485.000214265 [ 411.783227] pps pps0: PPS event at 1586955485.200217887 [ 412.583211] pps pps0: PPS event at 1586955486.000214565 [ 412.783209] pps pps0: PPS event at 1586955486.200217559 [ 413.583183] pps pps0: PPS event at 1586955487.000207532 [ 413.783188] pps pps0: PPS event at 1586955487.200214856 [ 414.583161] pps pps0: PPS event at 1586955488.000204200 [ 414.783164] pps pps0: PPS event at 1586955488.200212572 [ 415.583138] pps pps0: PPS event at 1586955489.000201916 [ 415.783140] pps pps0: PPS event at 1586955489.200209170 [ 416.583115] pps pps0: PPS event at 1586955490.000202426 [ 416.783117] pps pps0: PPS event at 1586955490.200206886 We can recognise the 200 ms pulse length of the gps. And some messages: # grep ntp /var/log/messages|grep -v NTSc Apr 15 14:57:52 doos ntpd[13057]: INIT: ntpd ntpsec-1.1.8 2019-08-02T00:00:00Z: Starting Apr 15 14:57:52 doos ntpd[13057]: INIT: Command line: /usr/sbin/ntpd -u ntp:ntp -g -N -p /var/run/ntpd.pid Apr 15 14:57:52 doos ntpd[13058]: INIT: precision = 1.466 usec (-19) Apr 15 14:57:52 doos ntpd[13058]: INIT: successfully locked into RAM Apr 15 14:57:52 doos ntpd[13058]: CONFIG: readconfig: parsing file: /etc/ntp.conf Apr 15 14:57:52 doos ntpd[13058]: AUTH: authreadkeys: reading /etc/ntp/keys Apr 15 14:57:52 doos ntpd[13058]: AUTH: authreadkeys: added 0 keys Apr 15 14:57:52 doos ntpd[13058]: CONFIG: 'monitor' cannot be disabled while 'limited' is enabled Apr 15 14:57:52 doos ntpd[13058]: INIT: Using SO_TIMESTAMPNS Apr 15 14:57:52 doos ntpd[13058]: IO: Listen and drop on 0 v6wildcard [::]:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen and drop on 1 v4wildcard 0.0.0.0:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen normally on 2 lo 127.0.0.1:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen normally on 3 eth0 192.168.10.70:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen normally on 4 lo [::1]:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen normally on 5 eth0 [fd00:c0a8:a00:1::70]:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen normally on 6 eth0 [2001:981:a812:0:b62e:99ff:fe92:5264]:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listen normally on 7 eth0 [fe80::b62e:99ff:fe92:5264%2]:123 Apr 15 14:57:52 doos ntpd[13058]: IO: Listening on routing socket on fd #24 for interface updates Apr 15 14:57:52 doos ntpd[13058]: SYNC: Found 14 servers, suggest minsane at least 3 Apr 15 14:57:52 doos ntpd[13058]: INIT: MRU 10922 entries, 13 hash bits, 65536 bytes Apr 15 14:57:52 doos ntpd[13058]: INIT: OpenSSL 1.1.1d FIPS 10 Sep 2019, 1010104f Apr 15 14:57:52 doos ntpd[13057]: 2020-04-15T14:57:52 ntpd[13057]: INIT: ntpd ntpsec-1.1.8 2019-08-02T00:00:00Z: Starting Apr 15 14:57:52 doos ntpd[13057]: 2020-04-15T14:57:52 ntpd[13057]: INIT: Command line: /usr/sbin/ntpd -u ntp:ntp -g -N -p /var/run/ntpd.pid Apr 15 14:57:56 doos ntpd[13058]: EX-REP: Count=1 Print=1, Score=0.500, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 15 14:57:56 doos ntpd[13058]: EX-REP: e400 4e54534e 68b79e8c 7aba3928 01040024 ab1ba90e 83b3398e b52bc6be 4326e979 982bfea5 f885c05a 718c2243 47483da8 Apr 15 14:59:01 doos ntpd[13058]: EX-REP: Count=2 Print=2, Score=0.996, M4 V4 from [2606:4700:f1::1]:123, lng=84 Apr 15 14:59:01 doos ntpd[13058]: EX-REP: e400 4e54534e fcbd5032 7356fdea 01040024 e445b468 d2d8f320 ea459fd8 86e68505 33cf4112 3f7d5a7d 9f2969df 4627b682 So no error messages about gps/NMEA. ntpq: # ntpq -pn remote refid st t when poll reach delay offset jitter === NMEA(0) .GPS.0 l 15 64 377 0. 0. 0.0019 192.168.10.98 .GPS.1 u 12 16 377 0.3325 0.8299 0.1966 fd00:c0a8:a00:1::1 .GPS.1 u4 64 377 0.3462 0.8608 0.7197 2606:4700:f1::1 .NTS. 16 0- 64 0 0. 0. 0.0019 2405:fc00:0:1::123 .PPS.1 8- 64 377 172.2785 2.9948 0.8281 2001:470:e815::24
Re: 1.1.6 build fails on FC30
On 12-04-2020 17:25, ASSI via devel wrote: >> # ppswatch /chroot/ntpd/dev/pps0 >> (shows similar output) > > Good, but does ntpd see the same? Well, devices look like this: # ls -l /dev/*ps* lrwxrwxrwx 1 root root 5 Apr 12 16:54 /dev/gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Apr 12 16:54 /dev/gpspps0 -> pps0 crw-rw 1 root ntp 253, 0 Apr 12 16:54 /dev/pps0 # ls -l /dev/ttyS0 crw-rw 1 root ntp 4, 64 Apr 12 16:54 /dev/ttyS0 # ls -l /chroot/ntpd/dev/ total 0 lrwxrwxrwx 1 root root 5 Mar 9 2018 gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Mar 9 2018 gpspps0 -> pps0 srw-rw-rw- 1 root root 0 Apr 12 16:39 log crw-r--r-- 1 ntp ntp1, 3 Mar 9 2018 null crw-r--r-- 1 ntp ntp 253, 0 Nov 3 17:15 pps0 crw-r--r-- 1 ntp ntp4, 64 Mar 9 2018 ttyS0 So a process running as ntp could access the necessary device files. What else could be in the way of ntpd 'seeing' things? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
Udo van den Heuvel via devel writes: > When then is the jitter so low? > If solely using NMEA the jitter and offset would be worse. Well, run ntpq with the -u switch to see what those really are. If you've set the serial to low latency and a fairly high speed, you can expect jitter in the single-to-double digit µs range, so it would show up as all zero in ntpq in standard display mode. > But: should ttyS0 show up in /proc/interrups? (ttyS1 does) Don't know… >> although from your boot log it's clear you were apparently expecting to >> use that. Have you set the flag to use the PPS and does the device >> deliver (stable) PPS signal? > > # ppswatch /dev/pps0 > trying PPS source "/dev/pps0" > found PPS source "/dev/pps0" > timestamp: 1586697390, sequence: 139, offset: 199075943 > timestamp: 1586698062, sequence: 140, offset: 196910388 > timestamp: 1586698062, sequence: 140, offset: 196910388 > timestamp: 1586698063, sequence: 141, offset: 196889843 > timestamp: 1586698063, sequence: 141, offset: 196889843 > timestamp: 1586698064, sequence: 142, offset: 196873213 > timestamp: 1586698064, sequence: 142, offset: 196873213 > timestamp: 1586698065, sequence: 143, offset: 196852628 > timestamp: 1586698065, sequence: 143, offset: 196852628 > timestamp: 1586698066, sequence: 144, offset: 196834846 > timestamp: 1586698066, sequence: 144, offset: 196834846 > timestamp: 1586698067, sequence: 145, offset: 196818850 > timestamp: 1586698067, sequence: 145, offset: 196818850 > timestamp: 1586698068, sequence: 146, offset: 196800678 > timestamp: 1586698068, sequence: 146, offset: 196800678 > timestamp: 1586698069, sequence: 147, offset: 196782262 > timestamp: 1586698069, sequence: 147, offset: 196782262 > timestamp: 1586698070, sequence: 148, offset: 196762613 That could become about 20µs jitter from eyeballing the data. The sequence numbers look awfully low though for a system that is up for a while already? > # ppswatch /chroot/ntpd/dev/pps0 > (shows similar output) Good, but does ntpd see the same? > Something is coming out of it. > >> If so, does the device file expected by >> ntpd exist in your chroot environment (generally a symlink to the real >> /dev/pps* device) and is it readable by ntpd? > > # ls -l /dev/*ps* > lrwxrwxrwx 1 root root 5 Apr 12 11:58 /dev/gps0 -> ttyS0 > lrwxrwxrwx 1 root root 4 Apr 12 11:58 /dev/gpspps0 -> pps0 > crw-rw 1 root ntp 253, 0 Apr 12 11:58 /dev/pps0 > # ls -l /chroot/ntpd/dev/*ps* > lrwxrwxrwx 1 root root 5 Mar 9 2018 /chroot/ntpd/dev/gps0 -> ttyS0 > lrwxrwxrwx 1 root root 4 Mar 9 2018 /chroot/ntpd/dev/gpspps0 -> pps0 > crw-r--r-- 1 ntp ntp 253, 0 Nov 3 17:15 /chroot/ntpd/dev/pps0 The files used by ntpd should be gps0 / gpspps0. >> Also, if there's an >> apparmor profile for ntpd, check in /var/log/audit/audit.log (or >> wherever that is under Fedora, also in the chroot maybe) that apparmor >> allows the access as well. > > selinux is disabled. > never used apparmor. Fedora / RHEL traditionally wasn't using it, I have no idea what the current state on these platforms is. I just mentioned it because it can cause an otherwise perfectly fine configuration to fail rather obscurely. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 12-04-2020 14:55, ASSI via devel wrote: > Udo van den Heuvel via devel writes: >> Using tsc clocksource we get: >> >> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource >> tsc >> # ntpq -pn >> remote refid st t when poll reach delay offset >> jitter >> === >> +NMEA(0) .GPS.0 l9 64 377 0. 0. >> 0.0019 >> *192.168.10.98 .GPS.1 u 27 64 377 0.3096 -0.0919 >> 0.1178 >> +fd00:c0a8:a00:1 .GPS.1 u 37 64 377 0.3211 -0.0505 >> 0.0775 >> >> I.e.: no system peer selection of GPS. >> We tried HPET, AC PI_PM and now TSC. >> None of them works to fix this issue. > > Then the clock isn't really the problem I suppose. The GPS is reachable > and has no offset and low jitter, but doesn't appear to use PPS; When then is the jitter so low? If solely using NMEA the jitter and offset would be worse. But: should ttyS0 show up in /proc/interrups? (ttyS1 does) Both are on a single pciE card. Setserial shows: # /bin/setserial /dev/ttyS0 /dev/ttyS0, UART: 16850, Port: 0xd0c0, IRQ: 37, Flags: low_latency # /bin/setserial /dev/ttyS1 /dev/ttyS1, UART: 16850, Port: 0xd0c8, IRQ: 37 # cat /dev/gps0 (NMEA stream) > although from your boot log it's clear you were apparently expecting to > use that. Have you set the flag to use the PPS and does the device > deliver (stable) PPS signal? # ppswatch /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" timestamp: 1586697390, sequence: 139, offset: 199075943 timestamp: 1586698062, sequence: 140, offset: 196910388 timestamp: 1586698062, sequence: 140, offset: 196910388 timestamp: 1586698063, sequence: 141, offset: 196889843 timestamp: 1586698063, sequence: 141, offset: 196889843 timestamp: 1586698064, sequence: 142, offset: 196873213 timestamp: 1586698064, sequence: 142, offset: 196873213 timestamp: 1586698065, sequence: 143, offset: 196852628 timestamp: 1586698065, sequence: 143, offset: 196852628 timestamp: 1586698066, sequence: 144, offset: 196834846 timestamp: 1586698066, sequence: 144, offset: 196834846 timestamp: 1586698067, sequence: 145, offset: 196818850 timestamp: 1586698067, sequence: 145, offset: 196818850 timestamp: 1586698068, sequence: 146, offset: 196800678 timestamp: 1586698068, sequence: 146, offset: 196800678 timestamp: 1586698069, sequence: 147, offset: 196782262 timestamp: 1586698069, sequence: 147, offset: 196782262 timestamp: 1586698070, sequence: 148, offset: 196762613 # ppswatch /chroot/ntpd/dev/pps0 (shows similar output) Something is coming out of it. > If so, does the device file expected by > ntpd exist in your chroot environment (generally a symlink to the real > /dev/pps* device) and is it readable by ntpd? # ls -l /dev/*ps* lrwxrwxrwx 1 root root 5 Apr 12 11:58 /dev/gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Apr 12 11:58 /dev/gpspps0 -> pps0 crw-rw 1 root ntp 253, 0 Apr 12 11:58 /dev/pps0 # ls -l /chroot/ntpd/dev/*ps* lrwxrwxrwx 1 root root 5 Mar 9 2018 /chroot/ntpd/dev/gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Mar 9 2018 /chroot/ntpd/dev/gpspps0 -> pps0 crw-r--r-- 1 ntp ntp 253, 0 Nov 3 17:15 /chroot/ntpd/dev/pps0 > Also, if there's an > apparmor profile for ntpd, check in /var/log/audit/audit.log (or > wherever that is under Fedora, also in the chroot maybe) that apparmor > allows the access as well. selinux is disabled. never used apparmor. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
Udo van den Heuvel via devel writes: > Using tsc clocksource we get: > > # cat /sys/devices/system/clocksource/clocksource0/current_clocksource > tsc > # ntpq -pn > remote refid st t when poll reach delay offset > jitter > === > +NMEA(0) .GPS.0 l9 64 377 0. 0. > 0.0019 > *192.168.10.98 .GPS.1 u 27 64 377 0.3096 -0.0919 > 0.1178 > +fd00:c0a8:a00:1 .GPS.1 u 37 64 377 0.3211 -0.0505 > 0.0775 > > I.e.: no system peer selection of GPS. > We tried HPET, AC PI_PM and now TSC. > None of them works to fix this issue. Then the clock isn't really the problem I suppose. The GPS is reachable and has no offset and low jitter, but doesn't appear to use PPS; although from your boot log it's clear you were apparently expecting to use that. Have you set the flag to use the PPS and does the device deliver (stable) PPS signal? If so, does the device file expected by ntpd exist in your chroot environment (generally a symlink to the real /dev/pps* device) and is it readable by ntpd? Also, if there's an apparmor profile for ntpd, check in /var/log/audit/audit.log (or wherever that is under Fedora, also in the chroot maybe) that apparmor allows the access as well. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 12-04-2020 11:43, Udo van den Heuvel via devel wrote: >> You might want to try if disabling C6 > > Thanks. Using tsc clocksource we get: # cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc # ntpq -pn remote refid st t when poll reach delay offset jitter === +NMEA(0) .GPS.0 l9 64 377 0. 0. 0.0019 *192.168.10.98 .GPS.1 u 27 64 377 0.3096 -0.0919 0.1178 +fd00:c0a8:a00:1 .GPS.1 u 37 64 377 0.3211 -0.0505 0.0775 162.159.200.123 .STEP. 16 1- 10240 0. 0. 0.0019 -2405:fc00:0:1:: .PPS.1 8 21 64 377 172.4212 2.2202 0.8405 (cut) I.e.: no system peer selection of GPS. We tried HPET, AC PI_PM and now TSC. None of them works to fix this issue. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 12-04-2020 11:39, ASSI via devel wrote: > Udo van den Heuvel via devel writes: >> So we went to tsc by disabling hpet but that one also has an issue. >> Now we are on acpi_pm. > > That is going to suck rocks. So it's just about any clock in your > system going backwards at times except the ACPI-PM? No. I see no system peer selected in ` ntpq- pn` so I suspect this issue has not vanished. > >> See https://pastebin.com/5BbgWVFt for a dmesg. > > That log is with HPET disabled. Exactly. > You might want to try if disabling C6 Thanks. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
Udo van den Heuvel via devel writes: > So we went to tsc by disabling hpet but that one also has an issue. > Now we are on acpi_pm. That is going to suck rocks. So it's just about any clock in your system going backwards at times except the ACPI-PM? > See https://pastebin.com/5BbgWVFt for a dmesg. That log is with HPET disabled. You might want to try if disabling C6 power save state is getting you a different result, although that will also disable the highest boost clock (as a certain number of cores need to be in C6 for this boost to get applied). There might be other settings in the power management settings of your BIOS that enable/disable powering down certain subsystems that may have an effect. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 12-04-2020 10:33, ASSI via devel wrote: > Udo van den Heuvel via devel writes: >> When booting with hpet=disable we see stuff like: > > Well, what clock sources get reported on boot when you don't force > anything and which one gets ultimately selected by the kernel? Are you > actually using a kernel new enough to know about Ryzen CPU, and does it > have the latest microcode for it (assuming that the BIOS isn't up on the > latest release of that already)? Please upload the full boot log to one > of the paste services instead of trying to guess what might look > interesting. We use kernel 5.6.3. We use Fedora 31 and update quite religiously. BIOS ais at latest release from Gigabyte. We know hpet has an issue. So we went to tsc by disabling hpet but that one also has an issue. Now we are on acpi_pm. See https://pastebin.com/5BbgWVFt for a dmesg. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
Udo van den Heuvel via devel writes: > When booting with hpet=disable we see stuff like: Well, what clock sources get reported on boot when you don't force anything and which one gets ultimately selected by the kernel? Are you actually using a kernel new enough to know about Ryzen CPU, and does it have the latest microcode for it (assuming that the BIOS isn't up on the latest release of that already)? Please upload the full boot log to one of the paste services instead of trying to guess what might look interesting. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 13:10, Achim Gratz via devel wrote: > based on the comments in the source. Again, if you don#t actually use > hardpps (and if this is the same Ryzen system you've had the timer > trouble on) it would be much more likely to work if you didn't configure > NTP_PPS and left the timer selection at the automoatic choice TSC > instead of forcing HPET. When booting with hpet=disable we see stuff like: [ 49.411072] usb 1-6.3: new full-speed USB device number 4 using xhci_hcd [ 60.413459] clocksource: timekeeping watchdog on CPU3: Marking clocksource 'tsc' as unstable because the skew is too large: [ 60.413460] clocksource: 'acpi_pm' wd_now: 9efd1b wd_last: 4c447b mask: ff [ 60.413461] clocksource: 'tsc' cs_now: 46847f4e13 cs_last: 3d27b1ddd6 mask: [ 60.413461] tsc: Marking TSC unstable due to clocksource watchdog [ 60.413473] usb 3-6.1: New USB device strings: Mfr=1, Product=3, SerialNumber=3 [ 60.413484] sdc: sdc1 sdc2 sdc4 [ 60.413931] ata6.00: Enabling discard_zeroes_data [ 60.414026] sd 5:0:0:0: [sdc] Attached SCSI removable disk [ 61.103005] usb 3-6.1: Product: 00 [ 61.103006] usb 3-6.1: Manufacturer: Moonbase Otago http://www.moonbaseotago.com/random [ 61.103007] usb 3-6.1: SerialNumber: 00 [ 61.103031] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. [ 61.389493] sched_clock: Marking unstable (61145974825, -42941333)<-(61315108884, -212077652) [ 61.389516] Freeing unused kernel image (initmem) memory: 1056K I.e.: messages about TSC appear to be not too positive. Gigabyte customer support were informed about this. when running without HPET ntpd still does not select NMEA gps as system peer. So HPET is not the cause now. But what is? Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
Udo van den Heuvel via devel writes: > I do not understand why NO_HZ is necessary or even usable without > conflict witgh PPS such as CONFIG_NO_HZ_COMMON. NO_HZ has been the default configuration for a long time and it doesn't have anything to do with the PPS API support. The _only_ conflict is with NTP_PPS, which predates NO_HZ and never has been adapted for it. >> Once you have that working correctly you can try to enable hardpps, > > How? By switching off NO_HZ configuration (assuming you don't care about the other side effects that's going to have) and switching on NTP_PPS. You can then compare that with the performance of the previous kernel config and decide if its worth the trouble. My experience is that even without hardpps the clock can be controlled to much better precision than can be transferred even over LAN. > Yes, that makes the /dev/pps0 device appear. It also sends the PPS events to the kernel in your current configuration, which should recognizably change the clock rate. > We start ntpd after this step. …configured with or without flag3 set? > Sure, in the chroot (!) the devices (created with mknod) are owned by ntp: Then run the ppstest in the chroot also, perhaps? Anyway, I'd think the device should still be owned by root, but group ntp. If Fedora uses apparmor, you also need to add the device to the apparmor profile or ntpd will not be able to open it (check the audit log for errors). > If I run ntpd outside of the chroot the error does not appear and PPS > works. With or without the time going backwards? > So we take another look at the chroot... I'm not sure the chroot really buys you anything, security-wise. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 14:36, Achim Gratz via devel wrote: > configuration, like so: > > CONFIG_NO_HZ_COMMON=y > CONFIG_NO_HZ_IDLE=y > # CONFIG_NO_HZ_FULL is not set > CONFIG_NO_HZ=y I do not understand why NO_HZ is necessary or even usable without conflict witgh PPS such as CONFIG_NO_HZ_COMMON. > CONFIG_PPS=y > # CONFIG_PPS_DEBUG is not set > # PPS clients support > # CONFIG_PPS_CLIENT_KTIMER is not set > CONFIG_PPS_CLIENT_LDISC=m > CONFIG_PPS_CLIENT_PARPORT=m > CONFIG_PPS_CLIENT_GPIO=m > # PPS generators support Except for the GPIO client that is what is in use here. > Once you have that working correctly you can try to enable hardpps, How? >> Yet we still see: >> REFCLOCK: refclock_ppsapi: time_pps_create: Operation not supported > > So does the PPS device exist and does it generate events? # ppstest /dev/pps0 trying PPS source "/dev/pps0" found PPS source "/dev/pps0" ok, found 1 source(s), now start fetching data... source 0 - assert 1572791560.772062581, sequence: 62 - clear 1572791559.972049895, sequence: 62 source 0 - assert 1572791560.772062581, sequence: 62 - clear 1572791560.972135103, sequence: 63 source 0 - assert 1572791561.772070058, sequence: 63 - clear 1572791560.972135103, sequence: 63 source 0 - assert 1572791561.772070058, sequence: 63 - clear 1572791561.972073160, sequence: 64 source 0 - assert 1572791562.772077047, sequence: 64 - clear 1572791561.972073160, sequence: 64 source 0 - assert 1572791562.772077047, sequence: 64 - clear 1572791562.972080079, sequence: 65 source 0 - assert 1572791563.772082569, sequence: 65 - clear 1572791562.972080079, sequence: 65 > If it's > coming in via a serial device, have you started an ldattach to enable > the PPS line discipline? Yes, that makes the /dev/pps0 device appear. We start ntpd after this step. If it is a link to the actual device (as usual > /dev/gpspps0 -> /dev/pps0), does it point to the correct device? Are > the permissions on the device correct? Sure, in the chroot (!) the devices (created with mknod) are owned by ntp: # ls -l /chroot/ntpd/dev/ total 0 lrwxrwxrwx 1 root root 5 Mar 9 2018 gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Mar 9 2018 gpspps0 -> pps0 srw-rw-rw- 1 root root 0 Nov 3 13:29 log crw-r--r-- 1 ntp ntp1, 3 Mar 9 2018 null crw-r--r-- 1 ntp ntp 252, 0 Mar 9 2018 pps0 crw-r--r-- 1 ntp ntp4, 64 Mar 9 2018 ttyS0 If I run ntpd outside of the chroot the error dopes not appear and PPS works. So we take another look at the chroot... Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
Udo van den Heuvel via devel writes: > On 03-11-2019 13:22, Udo van den Heuvel via devel wrote: >> Thanks for your thoughts. I will post the results... > > # gzip -dc /proc/config.gz |grep NO_HZ > # CONFIG_NO_HZ_IDLE is not set > # CONFIG_NO_HZ_FULL is not set > # CONFIG_NO_HZ is not set Again, I was suggesting to start from a more standard kernel configuration, like so: CONFIG_NO_HZ_COMMON=y CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_PPS=y # CONFIG_PPS_DEBUG is not set # PPS clients support # CONFIG_PPS_CLIENT_KTIMER is not set CONFIG_PPS_CLIENT_LDISC=m CONFIG_PPS_CLIENT_PARPORT=m CONFIG_PPS_CLIENT_GPIO=m # PPS generators support Once you have that working correctly you can try to enable hardpps, but I suspect that it has bitrotted quite a bit except for the handful of embedded platforms where it is still the standard config. In other words, there may be new incompatibilities on your platform that nobody has yet encountered via interactions with other parts of the kernel (power management and the like). > Yet we still see: > REFCLOCK: refclock_ppsapi: time_pps_create: Operation not supported So does the PPS device exist and does it generate events? If it's coming in via a serial device, have you started an ldattach to enable the PPS line discipline? If it is a link to the actual device (as usual /dev/gpspps0 -> /dev/pps0), does it point to the correct device? Are the permissions on the device correct? lrwxrwxrwx 1 root root 5 Nov 3 12:59 /dev/gps0 -> ttyS0 lrwxrwxrwx 1 root root 4 Nov 3 12:59 /dev/gpspps0 -> pps0 crw-rw 1 root ntp 249, 0 Nov 3 12:59 /dev/pps0 Remember that running the PPS in via a serial line w/ PPS line discipline and having hardpps configured the kernel will take over the clock steering and NTP just needs to watch (which you need to tell it via flag3). The data you've shown indicates you run with hardpps _and_ try to steer the clock with ntpd as well. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 13:22, Udo van den Heuvel via devel wrote: > Thanks for your thoughts. I will post the results... # gzip -dc /proc/config.gz |grep NO_HZ # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set Yet we still see: REFCLOCK: refclock_ppsapi: time_pps_create: Operation not supported # gzip -dc /proc/config.gz |grep PPS CONFIG_PPS=y # CONFIG_PPS_DEBUG is not set CONFIG_NTP_PPS=y # PPS clients support CONFIG_PPS_CLIENT_KTIMER=m CONFIG_PPS_CLIENT_LDISC=y # CONFIG_PPS_CLIENT_PARPORT is not set # CONFIG_PPS_CLIENT_GPIO is not set # PPS generators support Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 13:10, Achim Gratz via devel wrote: >> We do have continuous timer ticks enabled. > > That doesn't matter AFAIK. The incompatibility is already introduced by > > CONFIG_NO_HZ_COMMON=y Ah This box has that setting. The other does not. > based on the comments in the source. Again, if you don#t actually use > hardpps (and if this is the same Ryzen system you've had the timer > trouble on) it would be much more likely to work if you didn't configure > NTP_PPS and left the timer selection at the automoatic choice TSC > instead of forcing HPET. We force hpet on the kernel commandline. >> We do run a 250HZ configuration. > > I'm pretty sure that hardpps was never thotoughly tested with HZ that Thanks for your thoughts. I will post the results... Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 12:35, ASSI via devel wrote: > Udo van den Heuvel via devel writes: >> yet: >> >> # grep PPS .config >> CONFIG_PPS=y >> # CONFIG_PPS_DEBUG is not set >> CONFIG_NTP_PPS=y > > If you really wanted to enable hardpps, then you _must_ disable NOHZ in > the kernel config and let ntpd know (via flag3) that the kernel PLL is > active. Otherwise, disable that option. We do have continuous timer ticks enabled. We do run a 250HZ configuration. # grep HZ .config CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 # Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
Udo van den Heuvel via devel writes: > yet: > > # grep PPS .config > CONFIG_PPS=y > # CONFIG_PPS_DEBUG is not set > CONFIG_NTP_PPS=y If you really wanted to enable hardpps, then you _must_ disable NOHZ in the kernel config and let ntpd know (via flag3) that the kernel PLL is active. Otherwise, disable that option. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 12:15, Udo van den Heuvel via devel wrote: > > On 03-11-2019 12:06, Hal Murray wrote: >> >>> We do see pps and nmea but ntpd does not choose the local gps. Why? >> >> How do you "see" them? > > I use `ntpq -pn` to see what the status is. > > >>> NMEA(0) .GPS.0 l8 64 377 0. 0. 0.0019 >> >> I don't understand what's going on. The 377 says it is working, but the >> 0. and 0.0019 say that it isn't working. >> >> Do you have the baud rate correct? > > Yes. > `cat /dev/gps0` shows the NEMA stream. > >> What is in clockstats? > > We have clocklist: > > ntpq> clocklist > associd=0 status=0012 1 event, clk_bad_format, > name="NMEA", > timecode="$GPGGA,111253,5150.2223,N,00457.3970,E,1,08,1.0,-106.4,M,45.5,M,,*6F", > poll=14, noreply=0, badformat=1, baddata=0, fudgetime1=0.0, > fudgetime2=260.0, stratum=0, refid=GPS, flags=5, device="NMEA GPS Clock" > > > Then the 'badformat' is worrying. > What is wrong and how can I fix this? > > Also: when the GPS gives bad data, then why doesn't it use a different > clock as peer? We furthermore find: Nov 3 11:58:32 bv ntpd[15925]: REFCLOCK: refclock_ppsapi: time_pps_create: Operation not supported Nov 3 11:58:32 bv ntpd[15925]: REFCLOCK: NMEA(0) flag1 1 but PPSAPI fails yet: # grep PPS .config CONFIG_PPS=y # CONFIG_PPS_DEBUG is not set CONFIG_NTP_PPS=y # PPS clients support CONFIG_PPS_CLIENT_KTIMER=m CONFIG_PPS_CLIENT_LDISC=y # CONFIG_PPS_CLIENT_PARPORT is not set # CONFIG_PPS_CLIENT_GPIO is not set # PPS generators support # Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 03-11-2019 12:06, Hal Murray wrote: > >> We do see pps and nmea but ntpd does not choose the local gps. Why? > > How do you "see" them? I use `ntpq -pn` to see what the status is. >> NMEA(0) .GPS.0 l8 64 377 0. 0. 0.0019 > > I don't understand what's going on. The 377 says it is working, but the > 0. and 0.0019 say that it isn't working. > > Do you have the baud rate correct? Yes. `cat /dev/gps0` shows the NEMA stream. > What is in clockstats? We have clocklist: ntpq> clocklist associd=0 status=0012 1 event, clk_bad_format, name="NMEA", timecode="$GPGGA,111253,5150.2223,N,00457.3970,E,1,08,1.0,-106.4,M,45.5,M,,*6F", poll=14, noreply=0, badformat=1, baddata=0, fudgetime1=0.0, fudgetime2=260.0, stratum=0, refid=GPS, flags=5, device="NMEA GPS Clock" Then the 'badformat' is worrying. What is wrong and how can I fix this? Also: when the GPS gives bad data, then why doesn't it use a different clock as peer? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
> We do see pps and nmea but ntpd does not choose the local gps. Why? How do you "see" them? > NMEA(0) .GPS.0 l8 64 377 0. 0. 0.0019 I don't understand what's going on. The 377 says it is working, but the 0. and 0.0019 say that it isn't working. Do you have the baud rate correct? What is in clockstats? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 02-08-2019 10:31, Udo van den Heuvel via devel wrote: > On 02-08-19 07:33, Udo van den Heuvel via devel wrote: >> On one machine I see something weird: >> >> # ntpq -pn >> remote refid st t when poll reach delay offset >> jitter >> === >> NMEA(0) .GPS.0 l 38 64 377 0. 0. >> 0.0019 (...) Similarly on another box: # ntpq -pn remote refid st t when poll reach delay offset jitter === NMEA(0) .GPS.0 l8 64 377 0. 0. 0.0019 fd00:c0a8:a00:1::70 67.96.200.2183 u 40 64 377 0.5053 -0.9482 0.1484 192.168.10.70 67.96.200.2183 u 55 64 377 0.3385 -0.9747 0.1622 2001:888:0:7::2 193.67.79.2022 u 55 64 377 14.5311 -3.6038 0.2071 2001:888:0:7::22193.67.79.2022 u 39 64 377 15.4898 -3.6090 0.2897 2001:888:0:8::42193.79.237.142 u 26 64 377 15.4917 -3.3595 0.3590 193.67.79.202 .GPS.1 u 35 64 377 18.2123 -3.4533 0.3782 193.79.237.14 .GPS.1 u 44 64 377 15.3530 -3.8482 0.0702 162.23.41.10.MRS.1 u 34 64 377 31.6796 -3.7795 0.1488 130.149.17.8.GPS.1 u 39 64 377 38.8027 -1.9196 0.3486 131.188.3.222 .MBGh. 1 u 19 64 377 27.3543 -2.3403 0.0917 131.188.3.223 .PZFs. 1 u 46 64 377 27.6289 -2.2454 0.2238 keetweej.vanheusden.com .DNS. 16 u- 1024 0 0. 0. 0.0019 185.31.230.94 .INIT. 16 u- 1024 0 0. 0. 0.0019 ntp.nmi.nl .DNS. 16 u- 1024 0 0. 0. 0.0019 134.221.205.12 .INIT. 16 u- 1024 0 0. 0. 0.0019 # ntptime ntp_gettime() returns code 0 (OK) time e1692e8d.fc7a5b10 2019-11-03T10:46:37.986Z, (.986242416), maximum error 2150516 us, estimated error 16 us, TAI offset 0 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 0.000 us, frequency -30.043 ppm, interval 4 s, maximum error 2150516 us, estimated error 16 us, status 0x2001 (PLL,NANO), time constant 0, precision 1.000 us, tolerance 500 ppm, pps frequency 0.000 ppm, stability 0.000 ppm, jitter 0.000 us, intervals 0, jitter exceeded 0, stability exceeded 0, errors 0. We do see pps and nmea but ntpd does not choose the local gps. Why? Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 02-08-19 07:33, Udo van den Heuvel via devel wrote: > On one machine I see something weird: > > # ntpq -pn > remote refid st t when poll reach delay offset > jitter > === > NMEA(0) .GPS.0 l 38 64 377 0. 0. > 0.0019 > 192.168.10.98 .GPS.1 u3 16 377 0.5049 0.4519 > 0.0468 > fd00:c0a8:a00:1 .GPS.1 u 11 64 377 0.3664 0.4386 > 0.1500 > 2001:888:0:7::2 193.67.79.2022 u 18 64 377 15.2859 4.6559 > 0.1818 > 2001:888:0:7::2 193.79.237.142 u 20 64 377 15.2148 4.1001 > 0.2219 > 193.67.79.202 .DNS. 16 u- 10240 0. 0. > 0.0019 > 193.79.237.14 .DNS. 16 u- 10240 0. 0. > 0.0019 > 185.31.230.94 .DNS. 16 u- 10240 0. 0. > 0.0019 > 134.221.205.12 .DNS. 16 u- 10240 0. 0. > 0.0019 After a while: $ ntpq -pn remote refid st t when poll reach delay offset jitter === xNMEA(0) .GPS.0 l 39 64 377 0. 0. 0.0019 *192.168.10.98 .GPS.1 u4 16 377 0.3188 0.4948 0.0348 +fd00:c0a8:a00:1 .GPS.1 u 34 64 377 0.3338 0.3530 0.1080 -2001:888:0:7::2 193.79.237.142 u 42 64 377 14.9423 4.1657 0.2031 +2001:888:0:7::2 193.79.237.142 u 23 64 377 14.9395 4.0204 0.2603 193.67.79.202 .DNS. 16 u- 10240 0. 0. 0.0019 193.79.237.14 .DNS. 16 u- 10240 0. 0. 0.0019 185.31.230.94 .DNS. 16 u- 10240 0. 0. 0.0019 134.221.205.12 .DNS. 16 u- 10240 0. 0. 0.0019 This is the machine with CLOCK messages like: Aug 2 10:20:50 s2 ntpd[8263]: CLOCK: ts_prev 1564734050 s + 602281287 ns, ts_min 1564734050 s + 602280310 ns Aug 2 10:20:50 s2 ntpd[8263]: CLOCK: ts 1564734050 s + 602281287 ns Aug 2 10:20:50 s2 ntpd[8263]: CLOCK: sys_fuzz 2305 nsec, prior fuzz 0.02107 Aug 2 10:20:50 s2 ntpd[8263]: CLOCK: this fuzz -0.01769 Aug 2 10:20:50 s2 ntpd[8263]: CLOCK: prev get_systime 0xe0ee70e2.9a2f0787 is 0.00593 later than 0xe0ee70e2.9a2efd93 Which do not disaopear with 'logconfig -clockall'. udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 02-08-19 07:12, Matthew Selsky wrote: > You can likely remove python-devel and python-devel. Did so. > Are your RPM packages published anywhere? Not currently. On one machine I see something weird: # ntpq -pn remote refid st t when poll reach delay offset jitter === NMEA(0) .GPS.0 l 38 64 377 0. 0. 0.0019 192.168.10.98 .GPS.1 u3 16 377 0.5049 0.4519 0.0468 fd00:c0a8:a00:1 .GPS.1 u 11 64 377 0.3664 0.4386 0.1500 2001:888:0:7::2 193.67.79.2022 u 18 64 377 15.2859 4.6559 0.1818 2001:888:0:7::2 193.79.237.142 u 20 64 377 15.2148 4.1001 0.2219 193.67.79.202 .DNS. 16 u- 10240 0. 0. 0.0019 193.79.237.14 .DNS. 16 u- 10240 0. 0. 0.0019 185.31.230.94 .DNS. 16 u- 10240 0. 0. 0.0019 134.221.205.12 .DNS. 16 u- 10240 0. 0. 0.0019 No preferred clock. Any ideas? (this is the 1.1.6 code) Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Fri, Aug 02, 2019 at 06:31:34AM +0200, Udo van den Heuvel wrote: > Builds successfully after adapting the directories in the %files section. Excellent! > URL: http://www.ntpsec.org > Requires(post): systemd-units > Requires(preun): systemd-units > Requires(postun): systemd-units > BuildRequires: systemd-units > BuildRequires: bison gcc openssl-devel > BuildRequires:libcap-devel libseccomp-devel > BuildRequires: pps-tools-devel > BuildRequires: avahi-compat-libdns_sd-devel > BuildRequires: libcap openssl-libs pps-tools > BuildRequires: python-devel libxslt asciidoc m4 > BuildRequires: python-psutil asciidoc docbook-style-xsl wget > BuildRequires: /usr/bin/pathfix.py > BuildRequires: python3-devel python3-psutil You can likely remove python-devel and python-devel. Are your RPM packages published anywhere? Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 20:33, Matthew Selsky wrote:
> To:
> %{__python3} ./waf configure \
> %{__python3} ./waf build
> DESTDIR=$RPM_BUILD_ROOT %{__python3} ./waf install
>
> Let's see if that helps.
Builds successfully after adapting the directories in the %files section.
> Is there a git repo for your spec file work?
No, just vi, but feel free to use.
Kind regards,
Udo
# cat SPECS/ntpsec.spec |grep -v ^#
%global debug_package %{nil}
Summary: The NTPsec daemon and utilities
Name: ntpsec
Version: 1.1.6
Release: 0%{?dist}
License: BSD
Group: System Environment/Daemons
Source: ftp://ftp.ntpsec.org/pub/releases/ntpsec-%{version}.tgz
URL: http://www.ntpsec.org
Requires(post): systemd-units
Requires(preun): systemd-units
Requires(postun): systemd-units
BuildRequires: systemd-units
BuildRequires: bison gcc openssl-devel
BuildRequires:libcap-devel libseccomp-devel
BuildRequires: pps-tools-devel
BuildRequires: avahi-compat-libdns_sd-devel
BuildRequires: libcap openssl-libs pps-tools
BuildRequires: python-devel libxslt asciidoc m4
BuildRequires: python-psutil asciidoc docbook-style-xsl wget
BuildRequires: /usr/bin/pathfix.py
BuildRequires: python3-devel python3-psutil
%description
The NTPsec project - a secure, hardened, and improved implementation
of Network Time Protocol derived from NTP Classic, Dave Mills’s
original.
The Network Time Protocol (NTP) is used to synchronize a computer's
time with another reference time source. This package includes ntpd
(a daemon which continuously adjusts system time) and utilities used
to query and configure the ntpd daemon.
Perl scripts ntp-wait and ntptrace are in the ntp-perl package,
ntpdate is in the ntpdate package and sntp is in the sntp package.
The documentation is in the ntp-doc package.
%package doc
Summary: NTP documentation
Group: Documentation
Requires: %{name} = %{version}-%{release}
BuildArch: noarch
%description doc
This package contains NTP documentation in HTML format.
%prep
%setup -q
pathfix.py -pni "%{__python3} %{py3_shbang_opts}" .
%build
CFLAGS="-O2" %{__python3} ./waf configure \
--prefix=/usr\
--enable-early-droproot\
--refclock=nmea,generic\
--libdir=%{_libdir}\
--docdir=%{_docdir}/ntpsec\
--enable-doc
CFLAGS="-O2" %{__python3} ./waf build
%install
DESTDIR=$RPM_BUILD_ROOT %{__python3} ./waf install
pushd $RPM_BUILD_ROOT
mkdir -p .%{_sysconfdir}/{ntp/crypto,sysconfig,dhcp/dhclient.d}
.%{_libexecdir}
mkdir -p .%{_sysconfdir}/ntp.d
mkdir -p .%{_localstatedir}/{lib/{s,}ntp,log/ntpstats} .%{_unitdir}
mkdir -p .%{_unitdir}
mkdir -p .%{_docdir}/ntpsec
mkdir -p .%{_docdir}/ntpsec/icons
mkdir -p .%{_docdir}/ntpsec/includes
mkdir -p .%{_docdir}/ntpsec/pic
mkdir -p .%{_sysconfdir}/ntp/crypto/
mv .%{_bindir}/ntpdig .%{_sbindir}
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/default.conf
.%{_sysconfdir}/ntp.conf
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/use-gpsd-json
.%{_sysconfdir}/ntp.d/
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/use-gpsd-shm
.%{_sysconfdir}/ntp.d/
install -p -m644
%{_builddir}/%{name}-%{version}/etc/ntp.d/use-minimal-logging
.%{_sysconfdir}/ntp.d/
install -p -m644
%{_builddir}/%{name}-%{version}/etc/ntp.d/use-no-remote-configuration
.%{_sysconfdir}/ntp.d/
install -p -m644
%{_builddir}/%{name}-%{version}/etc/ntp.d/use-performance-logging
.%{_sysconfdir}/ntp.d/
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/use-pool
.%{_sysconfdir}/ntp.d/
popd
%post
%systemd_post ntpd.service
%preun
%systemd_preun ntpd.service
%postun
%systemd_postun_with_restart ntpd.service
%files
%{_sbindir}/*
%{_bindir}/*
%{_libdir}/python3.7/site-packages/ntp/*
%{_libdir}/python3.7/site-packages/ntp*info
%dir %attr(-,ntp,ntp) %{_sysconfdir}/ntp.d
%config(noreplace) %attr(644,ntp,ntp) %{_sysconfdir}/ntp.d/*
%{_unitdir}/*
%{_mandir}/*
%config(noreplace) %verify(not md5 size mtime) %attr(644,ntp,ntp)
%{_sysconfdir}/ntp.conf
%dir %attr(750,root,ntp) %{_sysconfdir}/ntp/crypto
%dir %attr(-,ntp,ntp) %{_localstatedir}/lib/ntp
%dir %attr(-,ntp,ntp) %{_localstatedir}/log/ntpstats
%ghost %attr(644,ntp,ntp) %{_localstatedir}/lib/ntp/drift
%files doc
%{_docdir}/ntpsec/*
%changelog
* Fri Jun 15 2018 Udo van den Heuvel 1.1.1-0
- Bump to 1.1.1
* Thu Mar 15 2018 Udo van den Heuvel 1.1.0-0
- Bump to 1.1.0
* Wed Mar 07 2018 Udo van den Heuvel 1.0.1-2
- Fresh git pull
* Sat Mar 03 2018 Udo van den Heuvel 1.0.1-1
- Bump to 1.0.1, include configs, service files, etc
* Tue Nov 14 2017 Udo van den Heuvel 1.0.0-0
- Create 1.0.0 package.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 07:19:02PM +0200, Udo van den Heuvel wrote:
> On 01-08-19 19:00, Matthew Selsky wrote:
> > You may need to specifically use %{__python3} when you call "waf" in the 2
> > places in the %build section.
>
> So maybe not use --python=%{__python3} for waf?
"--python" should not need to be passed to waf.
> Without this the rpm builds OK.
Please change these:
CFLAGS="-O2" ./waf configure \
CFLAGS="-O2" ./waf build
DESTDIR=$RPM_BUILD_ROOT ./waf install
To:
%{__python3} ./waf configure \
%{__python3} ./waf build
DESTDIR=$RPM_BUILD_ROOT %{__python3} ./waf install
Let's see if that helps. waf sets a reasonable CFLAGS already.
Is there a git repo for your spec file work?
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 19:00, Matthew Selsky wrote:
> You may need to specifically use %{__python3} when you call "waf" in the 2
> places in the %build section.
When I do these things I get:
Waf: Leaving directory `/usr/src/redhat/BUILD/ntpsec-1.1.6/build/main'
Traceback (most recent call last):
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py",
line 122, in waf_entry_point
run_commands()
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py",
line 183, in run_commands
ctx=run_command(cmd_name)
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py",
line 174, in run_command
ctx.execute()
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py",
line 377, in execute
return execute_method(self)
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Context.py",
line 88, in execute
self.recurse([os.path.dirname(g_module.root_path)])
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Context.py",
line 129, in recurse
user_function(self)
File "/usr/src/redhat/BUILD/ntpsec-1.1.6/wscript", line 962, in
init_handler
obj.execute()
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py",
line 377, in execute
return execute_method(self)
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Build.py",
line 104, in execute
self.execute_build()
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Build.py",
line 123, in execute_build
self.post_build()
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/.waf-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Build.py",
line 280, in post_build
m(self)
File "/usr/src/redhat/BUILD/ntpsec-1.1.6/wscript", line 917, in bin_test
from wafhelpers.bin_test import cmd_bin_test
File "/usr/src/redhat/BUILD/ntpsec-1.1.6/wafhelpers/bin_test.py", line
11, in
import ntp.util
File
"/usr/src/redhat/BUILD/ntpsec-1.1.6/build/main/tests/pylib/ntp/util.py",
line 16, in
import ntp.ntpc
ImportError: No module named ntpc
error: Bad exit status from /var/tmp/rpm-tmp.3EkTlR (%build)
RPM build errors:
Macro expanded in comment on line 119: %{_sysconfdir}/sysconfig/ntpd
Macro expanded in comment on line 126: %{_sysconfdir}/ntp/crypto/pw
Macro expanded in comment on line 127: %{_sysconfdir}/dhcp/dhclient.d
Macro expanded in comment on line 128:
%{_sysconfdir}/dhcp/dhclient.d/ntp.sh
Bad exit status from /var/tmp/rpm-tmp.3EkTlR (%build)
So maybe not use --python=%{__python3} for waf?
Without this the rpm builds OK.
Kind regards,
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 05:02:58PM +0200, Udo van den Heuvel wrote:
> On 01-08-19 16:39, Udo van den Heuvel via devel wrote:
> > The 1.1.6 code does not.
>
> The workaround now works when I use the pathfix.py line with this
> addition: %{buildroot}%{_sbindir}/*
>
> The whole SPEC then looks like the stuff below.
Awesome.
Can you change the BuildRequires to "python3-devel" and "python3-psutil"?
>
> How can we explain the existing shebangs?
And can you change the pathfix line to:
--snip--
pathfix.py -pni "%{__python3} %{py3_shbang_opts}" .
--snip--
And move it to the %prep section instead of the %install section.
You may need to specifically use %{__python3} when you call "waf" in the 2
places in the %build section.
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 16:39, Udo van den Heuvel via devel wrote:
> The 1.1.6 code does not.
The workaround now works when I use the pathfix.py line with this
addition: %{buildroot}%{_sbindir}/*
The whole SPEC then looks like the stuff below.
How can we explain the existing shebangs?
Kind regards,
Udo
# cat SPECS/ntpsec.spec |grep -v ^#
%global debug_package %{nil}
Summary: The NTPsec daemon and utilities
Name: ntpsec
Version: 1.1.6
Release: 0%{?dist}
License: BSD
Group: System Environment/Daemons
Source: ftp://ftp.ntpsec.org/pub/releases/ntpsec-%{version}.tgz
URL: http://www.ntpsec.org
Requires(post): systemd-units
Requires(preun): systemd-units
Requires(postun): systemd-units
BuildRequires: systemd-units
BuildRequires: bison gcc openssl-devel
BuildRequires:libcap-devel libseccomp-devel
BuildRequires: pps-tools-devel
BuildRequires: avahi-compat-libdns_sd-devel
BuildRequires: libcap openssl-libs pps-tools
BuildRequires: python-devel libxslt asciidoc m4
BuildRequires: python-psutil asciidoc docbook-style-xsl wget
BuildRequires: /usr/bin/pathfix.py
%description
The NTPsec project - a secure, hardened, and improved implementation
of Network Time Protocol derived from NTP Classic, Dave Mills’s
original.
The Network Time Protocol (NTP) is used to synchronize a computer's
time with another reference time source. This package includes ntpd
(a daemon which continuously adjusts system time) and utilities used
to query and configure the ntpd daemon.
Perl scripts ntp-wait and ntptrace are in the ntp-perl package,
ntpdate is in the ntpdate package and sntp is in the sntp package.
The documentation is in the ntp-doc package.
%package doc
Summary: NTP documentation
Group: Documentation
Requires: %{name} = %{version}-%{release}
BuildArch: noarch
%description doc
This package contains NTP documentation in HTML format.
%prep
%setup -q
%build
CFLAGS="-O2" ./waf configure \
--prefix=/usr\
--enable-early-droproot\
--refclock=nmea,generic\
--libdir=%{_libdir}\
--docdir=%{_docdir}/ntpsec\
--enable-doc
CFLAGS="-O2" ./waf build
%install
DESTDIR=$RPM_BUILD_ROOT ./waf install
pushd $RPM_BUILD_ROOT
mkdir -p .%{_sysconfdir}/{ntp/crypto,sysconfig,dhcp/dhclient.d}
.%{_libexecdir}
mkdir -p .%{_sysconfdir}/ntp.d
mkdir -p .%{_localstatedir}/{lib/{s,}ntp,log/ntpstats} .%{_unitdir}
mkdir -p .%{_unitdir}
mkdir -p .%{_docdir}/ntpsec
mkdir -p .%{_docdir}/ntpsec/icons
mkdir -p .%{_docdir}/ntpsec/includes
mkdir -p .%{_docdir}/ntpsec/pic
mkdir -p .%{_sysconfdir}/ntp/crypto/
mv .%{_bindir}/ntpdig .%{_sbindir}
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/default.conf
.%{_sysconfdir}/ntp.conf
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/use-gpsd-json
.%{_sysconfdir}/ntp.d/
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/use-gpsd-shm
.%{_sysconfdir}/ntp.d/
install -p -m644
%{_builddir}/%{name}-%{version}/etc/ntp.d/use-minimal-logging
.%{_sysconfdir}/ntp.d/
install -p -m644
%{_builddir}/%{name}-%{version}/etc/ntp.d/use-no-remote-configuration
.%{_sysconfdir}/ntp.d/
install -p -m644
%{_builddir}/%{name}-%{version}/etc/ntp.d/use-performance-logging
.%{_sysconfdir}/ntp.d/
install -p -m644 %{_builddir}/%{name}-%{version}/etc/ntp.d/use-pool
.%{_sysconfdir}/ntp.d/
pathfix.py -pni "%{__python2} %{py2_shbang_opts}"
%{buildroot}%{python2_sitearch} %{buildroot}%{_bindir}/*
%{buildroot}%{_sbindir}/*
popd
%post
%systemd_post ntpd.service
%preun
%systemd_preun ntpd.service
%postun
%systemd_postun_with_restart ntpd.service
%files
%{_sbindir}/*
%{_bindir}/*
%{_libdir}/python2.7/site-packages/ntp/*
%{_libdir}/python2.7/site-packages/ntp*info
%dir %attr(-,ntp,ntp) %{_sysconfdir}/ntp.d
%config(noreplace) %attr(644,ntp,ntp) %{_sysconfdir}/ntp.d/*
%{_unitdir}/*
%{_mandir}/*
%config(noreplace) %verify(not md5 size mtime) %attr(644,ntp,ntp)
%{_sysconfdir}/ntp.conf
%dir %attr(750,root,ntp) %{_sysconfdir}/ntp/crypto
%dir %attr(-,ntp,ntp) %{_localstatedir}/lib/ntp
%dir %attr(-,ntp,ntp) %{_localstatedir}/log/ntpstats
%ghost %attr(644,ntp,ntp) %{_localstatedir}/lib/ntp/drift
%files doc
%{_docdir}/ntpsec/*
%changelog
* Fri Jun 15 2018 Udo van den Heuvel 1.1.1-0
- Bump to 1.1.1
* Thu Mar 15 2018 Udo van den Heuvel 1.1.0-0
- Bump to 1.1.0
* Wed Mar 07 2018 Udo van den Heuvel 1.0.1-2
- Fresh git pull
* Sat Mar 03 2018 Udo van den Heuvel 1.0.1-1
- Bump to 1.0.1, include configs, service files, etc
* Tue Nov 14 2017 Udo van den Heuvel 1.0.0-0
- Create 1.0.0 package.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 16:27, Matthew Selsky wrote:
> See
> https://gitlab.com/NTPsec/ntpsec/commit/3ee8e4c3c3cf4b2d6f010874e7f447a23a1710cf
> for the change that we made to our CI targets.
Sure.
1.1.3 that is on my system has the correct shebangs.
The 1.1.6 code does not.
(...)
+ /usr/lib/rpm/redhat/brp-mangle-shebangs
*** ERROR: ambiguous python shebang in /usr/bin/ntpwait: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntplogtemp:
#!/usr/bin/env python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpsweep: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
mangling shebang in /usr/bin/ntpleapfetch from /bin/sh to #!/usr/bin/sh
*** ERROR: ambiguous python shebang in /usr/bin/ntpviz: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpsnmpd: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpkeygen:
#!/usr/bin/env python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntptrace: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpq: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpmon: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/sbin/ntpdig: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
error: Bad exit status from /var/tmp/rpm-tmp.3GaOm3 (%install)
RPM build errors:
Macro expanded in comment on line 117: %{_sysconfdir}/sysconfig/ntpd
Macro expanded in comment on line 124: %{_sysconfdir}/ntp/crypto/pw
Macro expanded in comment on line 125: %{_sysconfdir}/dhcp/dhclient.d
Macro expanded in comment on line 126:
%{_sysconfdir}/dhcp/dhclient.d/ntp.sh
Bad exit status from /var/tmp/rpm-tmp.3GaOm3 (%install)
[root@surfplank2 redhat]# cd
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64
[root@surfplank2 ntpsec-1.1.6-0.fc30.x86_64]# head usr/bin/ntpmon
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# SPDX-License-Identifier: BSD-2-Clause
'''\
Any keystroke causes a poll and update. Keystroke commands:
'a': Change peer display to apeers mode, showing association IDs.
'd': Toggle detail mode (some peer will be reverse-video highlighted
when on).
'h': Display helpscreen.
#
Kind regards,
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 04:31:52PM +0200, Udo van den Heuvel wrote: > On 01-08-19 16:27, Matthew Selsky wrote: > > On Thu, Aug 01, 2019 at 04:18:30PM +0200, Udo van den Heuvel wrote: > > > > See > > https://gitlab.com/NTPsec/ntpsec/commit/3ee8e4c3c3cf4b2d6f010874e7f447a23a1710cf > > for the change that we made to our CI targets. > > Sure, but why then is there a complaint from the Redhat Fedora tool(s)? I don't think the Fedora tools use anything related to our CI targets so our change should have neither helped, not harmed. > > The debian package replaces the shebangs. You can see how at > > https://sources.debian.org/patches/ntpsec/1.1.3+dfsg1-2/hardcode-python3-path.patch/ > > > > You likely want to use the RPM macro that does the equivalent. I'm not > > familiar enough with RPM packaging to give more specific advice. > > > We have a tool OK, cool. I'd be happy to review what you come up with if you want. And if you have suggestions for improving packaging/packaging.adoc, I'd be happy to hear them. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 16:27, Matthew Selsky wrote: > On Thu, Aug 01, 2019 at 04:18:30PM +0200, Udo van den Heuvel wrote: > >> The build shows otherwise, else there would not be an error. >> Or did I miss a step in the build process? > > See > https://gitlab.com/NTPsec/ntpsec/commit/3ee8e4c3c3cf4b2d6f010874e7f447a23a1710cf > for the change that we made to our CI targets. Sure, but why then is there a complaint from the Redhat Fedora tool(s)? > The debian package replaces the shebangs. You can see how at > https://sources.debian.org/patches/ntpsec/1.1.3+dfsg1-2/hardcode-python3-path.patch/ > > You likely want to use the RPM macro that does the equivalent. I'm not > familiar enough with RPM packaging to give more specific advice. We have a tool Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 04:18:30PM +0200, Udo van den Heuvel wrote: > The build shows otherwise, else there would not be an error. > Or did I miss a step in the build process? See https://gitlab.com/NTPsec/ntpsec/commit/3ee8e4c3c3cf4b2d6f010874e7f447a23a1710cf for the change that we made to our CI targets. > Because the shebangs are not explicit the build fails. > At least that is what I understand from the errors. The debian package replaces the shebangs. You can see how at https://sources.debian.org/patches/ntpsec/1.1.3+dfsg1-2/hardcode-python3-path.patch/ You likely want to use the RPM macro that does the equivalent. I'm not familiar enough with RPM packaging to give more specific advice. Thanks, -Matt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 16:15, Matthew Selsky wrote: >> Can someone please fix the /usr/sbin/ntpdig error? it makes the >> workround fail... > > Our code works on both Python2 and Python3. Given F30's recent changes, we > switched our CI targets to explicitly point at python3. The build shows otherwise, else there would not be an error. Or did I miss a step in the build process? > We're going to leave the shebangs alone in the source for maximum > compatibility with upstream PEP recommendations. See also > packaging/packaging.adoc in the repo. Because the shebangs are not explicit the build fails. At least that is what I understand from the errors. Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On Thu, Aug 01, 2019 at 03:32:40PM +0200, Udo van den Heuvel via devel wrote:
> On 01-08-19 15:24, Udo van den Heuvel via devel wrote:
> > The script will exit with nonzero exit code, rendering the build failed.
>
> When trying to work around this in my spec file, I use:
> pathfix.py -pni "%{__python2} %{py2_shbang_opts}"
> %{buildroot}%{python2_sitearch} %{buildroot}%{_bindir}/*
[..]
> QUESTION:
>
>
> Can someone please fix the /usr/sbin/ntpdig error? it makes the
> workround fail...
Our code works on both Python2 and Python3. Given F30's recent changes, we
switched our CI targets to explicitly point at python3.
If you're going to mangle the shebang as a package maintainer, feel free to
change all of the shebangs to explicit python3 on Fedora.
We're going to leave the shebangs alone in the source for maximum compatibility
with upstream PEP recommendations. See also packaging/packaging.adoc in the
repo.
Thanks,
-Matt
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 15:24, Udo van den Heuvel via devel wrote:
> The script will exit with nonzero exit code, rendering the build failed.
When trying to work around this in my spec file, I use:
pathfix.py -pni "%{__python2} %{py2_shbang_opts}"
%{buildroot}%{python2_sitearch} %{buildroot}%{_bindir}/*
Result:
(...)
+ pathfix.py -pni '/usr/bin/python2 -s'
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpfrob
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpkeygen
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpleapfetch
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntplogtemp
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpmon
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpq
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpsnmpd
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpsweep
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntptime
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntptrace
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpviz
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpwait
recursedown('/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages')
recursedown('/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp')
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/__init__.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/agentx.py:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/agentx_packet.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/control.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/magic.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/packet.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/poly.py:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/statfiles.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7/site-packages/ntp/util.py:
no change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpfrob: no
change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpkeygen:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpleapfetch: no
change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntplogtemp:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpmon: updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpq: updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpsnmpd:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpsweep:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntptime: no
change
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntptrace:
updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpviz: updating
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/bin/ntpwait:
updating
+ popd
~/rpmbuild/BUILD/ntpsec-1.1.6
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-ldconfig
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip /usr/bin/strip
+ /usr/lib/rpm/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1 0
Bytecompiling .py files below
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7
using /usr/bin/python2.7
+ /usr/lib/rpm/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-mangle-shebangs
mangling shebang in /usr/bin/ntpleapfetch from /bin/sh to #!/usr/bin/sh
*** ERROR: ambiguous python shebang in /usr/sbin/ntpdig: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
error: Bad exit status from /var/tmp/rpm-tmp.2SXyXF (%install)
RPM build errors:
Macro expanded in comment on line 117: %{_sysconfdir}/sysconfig/ntpd
Macro expanded in comment on line 124: %{_sysconfdir}/ntp/crypto/pw
Macro expanded in comment on line 125: %{_sysconfdir}/dhcp/dhclient.d
Macro expanded in comment on line 126:
%{_sysconfdir}/dhcp/dhclient.d/ntp.sh
Bad exit status from /var/tmp/rpm-tmp.2SXyXF (%install)
QUESTION:
Can someone please fix the /usr/sbin/ntpdig error? it makes the
workround fail...
Kind regards,
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: 1.1.6 build fails on FC30
On 01-08-19 15:09, Udo van den Heuvel via devel wrote:
> Hello,
>
> The compile on Fedora 30 fails at the very end:
>
> (...)
> + /usr/lib/rpm/brp-python-hardlink
> + /usr/lib/rpm/redhat/brp-mangle-shebangs
> *** ERROR: ambiguous python shebang in /usr/bin/ntpwait: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntplogtemp:
> #!/usr/bin/env python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntpsweep: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> mangling shebang in /usr/bin/ntpleapfetch from /bin/sh to #!/usr/bin/sh
> *** ERROR: ambiguous python shebang in /usr/bin/ntpviz: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntpsnmpd: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntpkeygen:
> #!/usr/bin/env python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntptrace: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntpq: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/bin/ntpmon: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> *** ERROR: ambiguous python shebang in /usr/sbin/ntpdig: #!/usr/bin/env
> python. Change it to python3 (or python2) explicitly.
> error: Bad exit status from /var/tmp/rpm-tmp.AKqksQ (%install)
>
>
> RPM build errors:
> Macro expanded in comment on line 107: %{_sysconfdir}/sysconfig/ntpd
>
> Macro expanded in comment on line 114: %{_sysconfdir}/ntp/crypto/pw
>
> Macro expanded in comment on line 115: %{_sysconfdir}/dhcp/dhclient.d
>
> Macro expanded in comment on line 116:
> %{_sysconfdir}/dhcp/dhclient.d/ntp.sh
>
> Bad exit status from /var/tmp/rpm-tmp.AKqksQ (%install)
Probably has to do with the info at
https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error
The buildroot policy script in /usr/lib/rpm/redhat/brp-mangle-shebangs
currently changes all python shebangs to python2 with a message like:
*** WARNING: mangling shebang in /usr/bin/taskotron_result from
#!/usr/bin/python to #!/usr/bin/python2. This will become an ERROR, fix
it manually!
We will change it to:
*** ERROR: ambiguous python shebang in /usr/bin/taskotron_result:
#!/usr/bin/python. Change it to python3 (or python2) explicitly.
The script will exit with nonzero exit code, rendering the build failed.
Of course I can (try to) work around this in my spec file but I guess
the project also has to choose python2 or pyhton3...
Kind regards,
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
1.1.6 build fails on FC30
Hello,
The compile on Fedora 30 fails at the very end:
(...)
+ pushd /root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64
~/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64
~/rpmbuild/BUILD/ntpsec-1.1.6
+ mkdir -p ./etc/ntp/crypto ./etc/sysconfig ./etc/dhcp/dhclient.d
./usr/libexec
+ mkdir -p ./etc/ntp.d
+ mkdir -p ./var/lib/sntp ./var/lib/ntp ./var/log/ntpstats
./usr/lib/systemd/system
+ mkdir -p ./usr/lib/systemd/system
+ mkdir -p ./usr/share/doc/ntpsec
+ mkdir -p ./usr/share/doc/ntpsec/icons
+ mkdir -p ./usr/share/doc/ntpsec/includes
+ mkdir -p ./usr/share/doc/ntpsec/pic
+ mkdir -p ./etc/ntp/crypto/
+ mv ./usr/bin/ntpdig ./usr/sbin
+ install -p -m644
/root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/default.conf ./etc/ntp.conf
+ install -p -m644
/root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/use-gpsd-json ./etc/ntp.d/
+ install -p -m644
/root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/use-gpsd-shm ./etc/ntp.d/
+ install -p -m644
/root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/use-minimal-logging ./etc/ntp.d/
+ install -p -m644
/root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/use-no-remote-configuration
./etc/ntp.d/
+ install -p -m644
/root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/use-performance-logging
./etc/ntp.d/
+ install -p -m644 /root/rpmbuild/BUILD/ntpsec-1.1.6/etc/ntp.d/use-pool
./etc/ntp.d/
+ popd
~/rpmbuild/BUILD/ntpsec-1.1.6
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-ldconfig
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip /usr/bin/strip
+ /usr/lib/rpm/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1 0
Bytecompiling .py files below
/root/rpmbuild/BUILDROOT/ntpsec-1.1.6-0.fc30.x86_64/usr/lib64/python2.7
using /usr/bin/python2.7
+ /usr/lib/rpm/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-mangle-shebangs
*** ERROR: ambiguous python shebang in /usr/bin/ntpwait: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntplogtemp:
#!/usr/bin/env python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpsweep: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
mangling shebang in /usr/bin/ntpleapfetch from /bin/sh to #!/usr/bin/sh
*** ERROR: ambiguous python shebang in /usr/bin/ntpviz: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpsnmpd: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpkeygen:
#!/usr/bin/env python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntptrace: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpq: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/bin/ntpmon: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
*** ERROR: ambiguous python shebang in /usr/sbin/ntpdig: #!/usr/bin/env
python. Change it to python3 (or python2) explicitly.
error: Bad exit status from /var/tmp/rpm-tmp.AKqksQ (%install)
RPM build errors:
Macro expanded in comment on line 107: %{_sysconfdir}/sysconfig/ntpd
Macro expanded in comment on line 114: %{_sysconfdir}/ntp/crypto/pw
Macro expanded in comment on line 115: %{_sysconfdir}/dhcp/dhclient.d
Macro expanded in comment on line 116:
%{_sysconfdir}/dhcp/dhclient.d/ntp.sh
Bad exit status from /var/tmp/rpm-tmp.AKqksQ (%install)
How can we fix this?
Below is the spec file used.
Kind regards,
Udo
# cat SPECS/ntpsec.spec |grep -v ^#
%global debug_package %{nil}
Summary: The NTPsec daemon and utilities
Name: ntpsec
Version: 1.1.6
Release: 0%{?dist}
License: BSD
Group: System Environment/Daemons
Source: ftp://ftp.ntpsec.org/pub/releases/ntpsec-%{version}.tgz
URL: http://www.ntpsec.org
Requires(post): systemd-units
Requires(preun): systemd-units
Requires(postun): systemd-units
BuildRequires: systemd-units
BuildRequires: bison gcc openssl-devel
BuildRequires:libcap-devel libseccomp-devel
BuildRequires: pps-tools-devel
BuildRequires: avahi-compat-libdns_sd-devel
BuildRequires: libcap openssl-libs pps-tools
BuildRequires: python-devel libxslt asciidoc m4
BuildRequires: python-psutil asciidoc docbook-style-xsl wget
%description
The NTPsec project - a secure, hardened, and improved implementation
of Network Time Protocol derived from NTP Classic, Dave Mills’s
original.
The Network Time Protocol (NTP) is used to synchronize a computer's
time with another reference time source. This package includes ntpd
(a daemon which continuously adjusts system time) and utilities used
to query and configure the ntpd daemon.
Perl scripts ntp-wait and ntptrace are in the ntp-perl package,
ntpdate is in the ntpdate package and sntp is in the sntp package.
The documentation is in
