On 12-02-2022 08:37, Hal Murray wrote:
Please try git head. I fixed my test case.
Updated git again a few minutes ago.
With these changes I see no WNRO messages thus far...
If this was the intended behaviour: THANKS!
Udo
___
devel mailing list
dev
On 12-02-2022 07:36, Gary E. Miller via devel wrote:
A capture of the raw NMEA would be helpful.
The other gps18x does not show the wrong date.
So would a reset of the 'wrong date' gps18x work?
Powerdown/up?
Udo
___
devel mailing list
devel@ntpsec.or
On 12-02-2022 08:37, Hal Murray wrote:
Please try git head. I fixed my test case.
Feb 12 12:17:10 plnksrf ntpd[148641]: INIT: ntpd ntpsec-1.2.1: Starting
Feb 12 12:17:10 plnksrf ntpd[148641]: INIT: Command line: /usr/sbin/ntpd
-u ntp:ntp -x -N -p /var/run/ntpd.pid
Feb 12 12:17:10 plnksrf nt
On 12-02-2022 06:45, Hal Murray wrote:
devel@ntpsec.org said:
Is this an effect? I get loads of these:
Feb 6 00:00:28 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 0
weeks, WNRO
That's a bug. Looks like it's alternating between 0 and 1024.
Which sentence(s) are you using? Wha
On 20-12-2021 21:51, Hal Murray via devel wrote:
I have a NMEA unit that's off by 1024 weeks. Somebody is fixing it twice.
Anybody know where that fixup code is located? I took a quick scan in the
NMEA driver but didn't find it.
Is this an effect? I get loads of these:
Feb 6 00:00:28 sr
On 26-11-2021 06:52, Hal Murray wrote:
ntpd does not start, reliably.
What goes wrong? Is there an error message?
What I can find in journalctl -b:
systemd[1]: Dependency failed for Wait for ntpd to synchronize system clock.
This is before the network scripts I still use (no network-manage
On 22-11-2021 19:50, Richard Laager via devel wrote:
What is the actual problem you are experiencing?
ntpd does not start, reliably.
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
On 16-11-2021 07:42, Udo van den Heuvel via devel wrote:
Can we please adjust the service files so that also ntp-wait.service
starts after we have network?
Currently it fails consistently.
Or is it confused by the ramdisk network setup?
Udo
Hello,
Can we please adjust the service files so that also ntp-wait.service
starts after we have network?
Currently only ntpd.service has references to network...
Kind regards,
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailm
Hello,
I built another ntpsec from git using the usual spec file, without
errors as far as I could see.
Yet, when I run the command below, I get some 'wrong version' output.
What is wrong here and how do I correct?
# /usr/bin/ntpq -c kerninfo
associd=0 status=c016 leap_alarm, sync_unspec, 1 ev
On 14-10-2020 20:04, James Browning via devel wrote:
> Not your system it's mine. In the interim, move the libntpc files up a
> level. I should have a patch soon.
Simply check ld.so.conf and rerun ldconfig.
Was easy fix on Fedora.
Udo
___
devel mailing
On 08-10-2020 12:55, Hal Murray wrote:
> It will probably help if you provide your distro and what versions of python
> appear if you ask for python, python2, and python3
We are on fedora 31, x86_64, etc.
Fedora appears to being moved towards python3.
Kind regards,
Udo
_
On 07-10-2020 12:17, Udo van den Heuvel via devel wrote:
> On 06-10-2020 20:27, Hal Murray via devel wrote:
>>
>>> and you can download the release tarballs with sums and signatures from
>>> ftp://ftp.ntpsec.org/pub/releases/
>>
>> It's not there ye
On 06-10-2020 20:27, Hal Murray via devel wrote:
>
>> and you can download the release tarballs with sums and signatures from
>> ftp://ftp.ntpsec.org/pub/releases/
>
> It's not there yet.
Other stuff that might not be 'there' yet shows when building the binaries:
()
+ pushd /root/rpmbuild/
On 03-07-2020 15:00, Hal Murray wrote:
>> How can I avoid this from happening again?
>
> That isn't enough info to figure out what happened. Somehow, ntpd thought
> the
> time was way off, and you had the -g switch on that allowed it to take big
> jumps. If you turn off the -g switch, ntpd w
On 03-07-2020 10:34, ASSI via devel wrote:
> Udo van den Heuvel via devel writes:
>> May 18 10:06:48 boombox ntpd[2055]: CLOCK: time stepped by 59097600.478559
>> May 18 10:06:48 boombox ntpd[2055]: CLOCK: time changed from 2020-07-03 to
>> 2022-05-18
>
> That's
Hello,
Had to reboot the box.
When it came up it got the wrong date.
It looks like ntpd had a role here:
(...)
Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/sdc [SAT], not found
in smartd database.
Jul 3 10:06:47 boombox smartd[2004]: Device: /dev/sdc [SAT], can't
monitor Current_Pending_Se
On 26-05-2020 00:31, Hal Murray via devel wrote:
> Fedora is updating from Python 3.7 to 3.8.
>
> That breaks ntpq (and friends) because the installed ntp libraries are over
> in 3.7 but ntpq is looking in 3.8
>
> Is there a good/clean fix for this? Should the code that chops the ".py? off
> t
Hello,
What can I do about these EX-REP messages?
Apr 17 06:31:34 doos ntpd[240324]: EX-REP: Count=99 Print=42,
Score=2.097, M4 V4 from [2606:4700:f1::1]:123, lng=84
Apr 17 06:31:34 doos ntpd[240324]: EX-REP: e400
4e54534e 40cdeadb 42681b33 00
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
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
refc
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 /et
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
Hal,
On 14-04-2020 05:07, Hal Murray wrote:
> I just pushed a fix. Please test.
With this fix the ntpd appears to be running a few hours now without issue.
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
On 14-04-2020 07:22, Hal Murray wrote:
> Given that you have tested most of the rest of your ntp.conf, my guess would
> be file permissions on the certificate or key. The key is most likely since
> there is no reason to hide the certificate.
# cd /etc/letsencrypt/
# find . -exec ls -ld {} \;
dr
On 14-04-2020 05:07, Hal Murray wrote:
>
>> # grep nts /etc/ntp.conf
>> nts key /etc/letsencrypt/keys/_key-certbot.pem
>> nts cert /etc/letsencrypt/csr/_csr-certbot.pem
>> server time.cloudflare.com:1234 nts # TLS1.3 only
> ...
>
> Thanks.
>
> I just pushed a fix. Please test.
Will do
On 13-04-2020 20:18, Hal Murray wrote:
> It's dying while trying to reload the certificate file.
>
> Is that happening after running for an hour?
Yes.
>
> That turns into 2 questions. Why is it trying to reload the certificates,
> and
> why is it crashing?
>
> What's in your ntp.conf? I do
On 13-04-2020 19:39, Hal Murray wrote:
>> Or will I do the debug build?
>
> Please do it again with symbols.
>
> How long does it run before it crashes? Seconds? Hours? ...
(gdb) bt
#0 use_certificate_chain_file (ctx=ctx@entry=0x0, ssl=ssl@entry=0x0,
file=file@entry=0x555f9640
"/etc/let
On 13-04-2020 16:01, Hal Murray wrote:
>
> udo...@xs4all.nl said:
>> Started things this way. One gdb line worries me a bit: (No debugging symbols
>> found in build/main/ntpd/ntpd)
>
>> Perhaps a different build is needed?
>
> I'm not sure how that stuff works.
>
> configure has an --enable-de
On 13-04-2020 16:01, Hal Murray wrote:
>
> udo...@xs4all.nl said:
>> Started things this way. One gdb line worries me a bit: (No debugging symbols
>> found in build/main/ntpd/ntpd)
>
>> Perhaps a different build is needed?
>
> I'm not sure how that stuff works.
>
> configure has an --enable-de
On 13-04-2020 14:48, Hal Murray wrote:
>> Apr 13 06:10:27 doos ntpd[204063]: EX-REP: Count=1 Print=1, Score=0.500, M4
>> V4 from [2606:4700:f1::1]:123, lng=84
>
> That's saying the NTS stuff isn't working. 2606:4700:f1::1 is Cloudflare.
> They have updated their servers to use the latest tweak
On 13-04-2020 15:23, Hal Murray wrote:
> when it crashes, you should get back to gdb
> then
> bt should give you a stack trace
Started things this way.
One gdb line worries me a bit:
(No debugging symbols found in build/main/ntpd/ntpd)
Perhaps a different build is needed?
Udo
On 13-04-2020 14:48, Hal Murray wrote:
> Can you get a stack trace?
I did not find a core dump.
How else can I get a stack dump?
> What were your configure options?
CFLAGS="-O2" %{__python3} ./waf configure \
--prefix=/usr\
--enable-early-droproot\
On 13-04-2020 14:13, Udo van den Heuvel via devel wrote:
> All,
>
> This happens since yesterday:
This is with a fairly recent 1.1.8 git build.
Fedora is up to date.
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman
All,
This happens since yesterday:
Apr 13 06:10:23 doos ntpd[204062]: INIT: ntpd ntpsec-1.1.8
2019-08-02T00:00:00Z: Starting
Apr 13 06:10:23 doos ntpd[204062]: INIT: Command line: /usr/sbin/ntpd -u
ntp:ntp -g -N -p /var/run/ntpd.pid
Apr 13 06:10:23 doos ntpd[204063]: INIT: precision = 1.397 usec
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
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
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 r
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
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? A
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 sel
On 23-02-2020 11:30, Achim Gratz via devel wrote:
> Udo van den Heuvel via devel writes:
>> ntpd[2256]: NTSc: NTS-KE req to pi4.rellim.com took 0.370 sec, fail
>
> You'd need the /^NTSc: / lines immediately preceding this to figure out
> where it failed. There is no ful
Hello,
What does a line of
ntpd[2256]: NTSc: NTS-KE req to pi4.rellim.com took 0.370 sec, fail
signify?
A remote issue?
Or a local failure?
What is failing exactly?
Kind regards,
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mai
On 03-01-2020 06:06, Hal Murray wrote:
>
>>> Do you have a "disable monitor" in your ntp.conf?
>> yes
>
> That turns off monitoring, aka the MRU list.
I believe that was a security feature to prevent amplification of
ddos-type attacks. (for ntp classic)
Or doesn't this work this way for ntpsec?
On 02-01-2020 20:26, Hal Murray wrote:
> That's not the normal output.
>
> Do you have a "disable monitor" in your ntp.conf?
yes
> What does "ntpq -c monstats" show?
# ntpq -c monstats
enabled:0
addresses: 0
peak addresses: 0
maximum addresses: 11915
re
On 02-01-2020 11:03, Hal Murray via devel wrote:
> Is anybody other than me and Mike interested in large MRU lists?
I see stuff like this:
# ntpq -c mru
Ctrl-C will stop MRU retrieval and display partial results.
lstint avgint rstr r m v count rport remote address
==
On 13-12-2019 12:37, Hal Murray wrote:
> Are you using a chroot jail? If so, does it let ntpd see the root certs?
The chroot is the root cause I guess.
Thanks for tipping me abotu taht one.
I copied over /etc/pki to /chroot/ntpd/etc and stuff starts to see certs
and such:
Dec 13 12:42:57 sp2 nt
On 13-12-2019 11:31, Udo van den Heuvel via devel wrote:
> No change in ntpd behaviour...
Certificates ended up in /etc/pki/tls/certs/ca-bundle.trust.crt and
/etc/pki/tls/certs/ca-bundle.crt
But after an ntpd restart no change...
Udo
___
de
On 13-12-2019 11:21, Udo van den Heuvel via devel wrote:
> On 13-12-2019 11:09, Udo van den Heuvel via devel wrote:
>> So is this an isseu in the ca-certificates rpm?
>
> https://letsencrypt.org/certificates/ shows the relationships between
> certificates.
> Could it be that
On 13-12-2019 11:09, Udo van den Heuvel via devel wrote:
> So is this an isseu in the ca-certificates rpm?
https://letsencrypt.org/certificates/ shows the relationships between
certificates.
Could it be that the Fedora rpm has no info on the X3 cert?
Hal,
On 13-12-2019 10:56, Hal Murray wrote:
> On Fedora, it's ca-certificates.noarch
Dec 13 11:07:18 sp2 ntpd[1582985]: NTSc: DNS lookup of ntp2.glypnod.com
took 0.031 sec
Dec 13 11:07:18 sp2 ntpd[1582985]: NTSc: nts_probe connecting to
ntp2.glypnod.com:123 => [2a03:b0c0:1:d0::1f9:f001]:123
Dec 1
On 10-12-2019 06:47, Hal Murray wrote:
> Do you have the normal collection of root certificates installed? Are they
> up
> to date?
Can anybody confirm that installing the certificates for ntpd as a
server can fix the client-side certificate issues as well?
Kind regards,
Udo
__
Hal,
On 10-12-2019 06:47, Hal Murray wrote:
>> I also might have a local issue as I get:
>> NTSc: certificate invalid: 20=>unable to get local issuer certificate
>> (for the other servers mentioned at the howto page)
>
> What OS/distro/version are you using?
Fedora 31 Linux with kernel.org, git
On 10-12-2019 06:18, Udo van den Heuvel via devel wrote:
> Dec 10 05:52:57 s2 ntpd[984825]: NTSc: NTS-KE req to
> time.cloudflare.com:1234 took 0.070 sec, fail
I also might have a local issue as I get:
NTSc: certificate invalid: 20=>unable to get local issuer certificate
(for
On 10-12-2019 05:58, Hal Murray wrote:
> openssl s_client -showcerts -quiet time.cloudflare.com:1234
# openssl s_client -showcerts -quiet time.cloudflare.com:1234
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc,
On 10-12-2019 05:03, Hal Murray wrote:
>
>> Also: NTSc: certificate invalid: 19=>self signed certificate in certificate
>> chain
>
>> When I try nts as a client...
>
> Which host?
>
The first one in the howto:
Public NTP servers supporting NTS:
server time.cloudflare.com:1234 nts # TLS1.3
On 09-12-2019 23:38, Paul Theodoropoulos via devel wrote:
> https://docs.ntpsec.org/latest/NTS-QuickStart.html
>
> If anyone has a contact over at cloudflare, you might ask them to
> correct this...
Also: NTSc: certificate invalid: 19=>self signed certificate in
certificate chain
When I try nts
On 01-12-2019 23:51, Matthew Selsky wrote:
> On Sun, Dec 01, 2019 at 10:45:28AM +0100, Udo van den Heuvel via devel wrote:
>> Perhaps also in this way:
>>
>> rpmbuild -bb --define '_wrong_version_format_terminate_build 0'
>> SPECS/ntpsec.spec
>
> Udo,
On 01-12-2019 10:14, Udo van den Heuvel via devel wrote:
> The macro _wrong_version_format_terminate_build can be used to work
> around this issue:
Perhaps also in this way:
rpmbuild -bb --define '_wrong_version_format_terminate_build 0'
SPECS/ntpsec.spec
K
Hello,
The macro _wrong_version_format_terminate_build can be used to work
around this issue:
On 01-12-2019 09:00, Udo van den Heuvel via devel wrote:
> Processing files: ntpsec-1.1.8-1.fc31.x86_64
> error: Invalid version (double separator '-'):
> 1.1.8.2019-08-02T00-00-00Z
Hello,
Previously 1.1.8 built OK, now I get:
(...)
+ popd
~/rpmbuild/BUILD/ntpsec-1.1.8
+ /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
+ /us
On 24-11-2019 15:11, James Browning via devel wrote:
> I do not suppose this would be anything like issue 499.
Different code. (?)
'straight' clock, no kernel issues identified (yet).
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/m
On 24-11-2019 15:01, Eric S. Raymond wrote:
> Udo van den Heuvel :
>> I have an M8N on order, would that be compatible enough to this driver?
>> If so: I could help test etc.
>
> That can't hurt - they speak the same protocol - but the big deal with
> the T variant os a stationary mode you don't h
On 24-11-2019 14:18, Eric S. Raymond wrote:
> Udo van den Heuvel via devel :
>> I cam across this ublox ntpsec refclock:
>> https://gitlab.com/trv-n/ntpsec-ublox
>> Would it be usable for incorporation in the ntpsec tree?
(...)
>
> I have filed an issue on its tra
Hello,
I cam across this ublox ntpsec refclock:
https://gitlab.com/trv-n/ntpsec-ublox
Would it be usable for incorporation in the ntpsec tree?
(AFAIK this is a 'straight' refclock; no extra lines needed besides
rx/tx and pps)
Kind regards,
Udo
___
devel
On 04-11-2019 16:10, Udo van den Heuvel via devel wrote:
> Question:
>
> Can anybody mention which libraries in the chroot I should have for
> ntpsec's ntpd?
> Things are working now but perhaps functionality can improve with the
> right software in lib64.
FWIW: so far
On 03-11-2019 17:53, Achim Gratz via devel wrote:
> Alternatively, sysfs lets you know the device number in a
> perhaps more script-friendly version:
>
>> cat /sys/devices/virtual/pps/pps0/dev
> 249:0
Thanks, I'll find a way to script that for the chroot.
Question:
Can anybody mention which lib
On 03-11-2019 17:12, Achim Gratz via devel wrote:
>> So we take another look at the chroot...
>
> I'm not sure the chroot really buys you anything, security-wise.
Not doing anything felt not OK.
ntpd run outside of the chroot does not have an issue.
ntpd in the chroot does have this issue.
We f
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.
> CONFI
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_pps
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. Ag
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
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 st
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 o
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
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
> ===
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
===
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
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
"/u
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,
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-
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/3ee8e4c3c3cf4b2d6f01087
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, el
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} %{buildr
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:
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/n
On 14-04-19 14:01, Hal Murray wrote:
> backwards runs forever. ^C when you get bored.
No output after running `backwards` for over 30 minutes.
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
On 14-04-19 14:01, Hal Murray wrote:
> I just pushed some tweaks. Would you please try attic/clock and
hpet:
# ./a.out
res avg min dups CLOCK
1 1666 419CLOCK_REALTIME
400 5 444-1 CLOCK_REALTIME_COARSE
1 1657 419CLOCK
On 14-04-19 14:01, Hal Murray wrote:
>
> udo...@xs4all.nl said:
>> ntpsec 1.1.3's ntpd from
>> ftp://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz
>> gives me after startup:
>
>> Apr 13 15:53:50 bla ntpd[12382]: CLOCK: ts_prev 1555163630 s + 594156272 ns,
>> ts_min 1555163630 s + 594155713 ns
On 13-04-19 18:28, Achim Gratz via devel wrote:
>> !?
>> What /was/ the problem in that case?
>
> The same that you still see: the system clock gets stopped and two
> consecutive reads of the clock read the same (or maybe time even goes
> backwards when looked at with higher resolution).
Timetrav
On 13-04-19 14:02, Hal Murray wrote:
> Plese give it a quick try to see if ntpsec is the problem. How about just
> trying the 1.1.3 release?
ntpsec 1.1.3's ntpd from
ftp://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz gives me after
startup:
Apr 13 15:53:50 bla ntpd[12382]: CLOCK: ts_prev 155
On 13-04-19 15:29, Achim Gratz via devel wrote:
> Udo van den Heuvel via devel writes:
>> Fedora 29, kernel.org 4.19.30. (my compile)
>
> Is this a "tickless" kernel perhaps? If so, try "nohz=off" on the
> kernel command line in the boot manager and see if
On 13-04-19 12:21, Hal Murray wrote:
>> I never ever saw these before.
>
> Something changed. All we have to do is figure out what/when.
>
> Was the switch to using HPET recent?
hpet must have been the default until it wasn't or at least tsc stopped
being stable.
> Did you do a recent git pull
On 13-04-19 10:09, Hal Murray via devel wrote:
> Here is a typical batch of the confusing CLOCK printout:
>
> Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts_prev 1555072655 s +
> 712154322 ns, ts_min 1555072655 s + 712153764 ns
> Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts 1555072655 s + 7121
On 13-04-19 01:27, Hal Murray wrote:
> I haven't had time to look carefully at the CLOCK problems. What sort of
> hardware is that running on?
Fedora 29 on x86_64 with Garmin gps18x on rs232.
Udo
___
devel mailing list
devel@ntpsec.org
http://lists.n
Hello,
What to think about logging like this:
Apr 11 19:12:25 vr ntpd[3428]: JUNK: M3 V4 0/23 1 4ef 48/ 0 0 550 from
[2600:1700:6731:6c0:f2de:f1ff:fe20:1bbe]:38764, lng=1408
Apr 11 19:14:34 vr ntpd[3428]: JUNK: M3 V4 0/23 1 4ef 48/ 0 0 560 from
[2600:1700:6731:6c0:f2de:f1ff:fe20:1bbe]:38764, lng=
Hello,
In my spec file (for Fedora) I configure and build nptsec with:
%build
CFLAGS="-O2" ./waf configure \
--prefix=/usr\
--enable-early-droproot\
--refclock=nmea,generic\
--libdir=%{_libdir}\
--docdir=%{_docdir}/nt
On 31-03-19 15:13, Achim Gratz via devel wrote:
> Udo van den Heuvel via devel writes:
>> But it was runnning on clocksource tsc.
>
> Again no direct experience, but TSC should be stable these days unless
> something is very much wrong with the drivers. ALso, I've seen r
On 31-03-19 14:43, Achim Gratz via devel wrote:
>> Same as it ever was:
>
> How are we supposed to know that if you don't say it?
Because I was happy and documented stuff on linuxpps.org.
Because no backups were made there the documentation went missing.
>> Garmin GPS18X getting power from USB,
On 31-03-19 13:37, Udo van den Heuvel via devel wrote:
>> As long as the time is that much off, yes it'll do that.
>
> Time is not that much off.
> It also happens when I sync the clock manually and then start ntpd.
>
>> Does anything in the boot log complain abo
1 - 100 of 152 matches
Mail list logo
