For what they're worth, my random thoughts are below...
On 4/11/19 4:31 AM, Hal Murray via devel wrote:
> There is a potential item: We may need the NTP server to listen on some port
> in addition to 123 in order to get around various filtering rules leftover
> from NTP DDoS amplification attack
The Debian man page for ntpdate has this BUGS section:
The slew adjustment is actually 50% larger than the measured offset,
since this (it is argued) will tend to keep a badly drifting clock more
accurate. This is probably not a good idea and may cause a troubling
hunt for some values of
On 8/16/19 5:21 PM, Sanjeev Gupta via devel wrote:
> My new push (on Gitlab) uses (unsigned long long) , and tests OK on
> 32-bit and 64-bit systems.
It seems like you should be using a size-specific type here rather than
trying to find a type of the appropriate size manually and using that.
Use
On 8/19/19 8:33 PM, Gary E. Miller via devel wrote:
> I just pushed Dan Drown's patch for the ALPN. That allows NTPsec to
> interoperate with other NTS implementations.
>
> But, it will break existing NTPsec NTS. So upgrade to git head now if
> you use NTS.
Can we get a point release soon, plea
On 8/23/19 6:55 PM, Hal Murray via devel wrote:
> Or maybe wait for the NTS RFC to come out so we have a good reason for the
> release.
What is the official (or barring that, consensus) view on the quality of
NTS in NTPsec? Is it something that is usable in production? If so,
please cut a release
Achim,
I haven't fact checked you, but what you're saying about the APIs sounds
reasonable. Is there any chance you could propose a patch to fix this?
(Or have you already and I missed it?)
--
Richard
___
devel mailing list
devel@ntpsec.org
http://list
On 8/29/19 2:20 PM, Gary E. Miller via devel wrote:
> Sadly we do not get to pick the API. The user picks the available
> APIs when he picks a distro.
Read `man strerror_r`. The defines determine which API (XSI or GNU)
glibc provides. You, the application author, pick the API by setting the
macros
On 8/29/19 4:04 PM, Hal Murray via devel wrote:
> Gary said:
> [API for strerror_r()]
>> On Linux, yes. But not on all distros. For example, on Android, which gpsd
>> supports, strerror_r() always returns an int. No options.
>
> Same on NetBSD and FreeBSD.
Right, so that seems like an argumen
How about this:
https://gitlab.com/NTPsec/ntpsec/merge_requests/1027
I'd love to know if that builds and works on all the supported
platforms. It seems like it should.
If there are problems with the approach from the first commit, the
second (renaming mystrerror to ntp_strerror_r) and third (usin
On 9/16/19 6:08 PM, James Browning via devel wrote:
> - additions to the DNS code to allow non-A/ pools. (cname/srv probably)
Is it not following CNAMEs already? I haven't checked.
> - less awful asccidoctor support
What's the issue here? I might be able to help.
--
Richard
___
On 9/16/19 1:33 AM, Hal Murray via devel wrote:
> Port randomization:
> https://tools.ietf.org/html/draft-gont-ntp-port-randomization-04
> I'd guess somewhere between a day and a week to implement this.
>From the draft, it sounds like this might be as simple as NOT specifying
a port on the sock
At work, I have two NTP servers. They are part of the pool, with both
IPv4 and IPv6.
Internally, my systems use my NTP servers (marked with prefer) and the
pool to provide additional sources. As is typical, ntpd prefers IPv6
after resolving the hostname.
>From time to time, the pool will serve me
On 10/26/19 10:24 PM, Hal Murray via devel wrote:
> That approach is worth investigating, but it adds a layer of complexity if
> you
> want to support more than a single reader.
Are multiple readers a thing? What's the use case here? I mean,
presumably I'm not running multiple ntpds on the same s
On 10/28/19 3:37 PM, Hal Murray wrote:
>
>> Are multiple readers a thing? What's the use case here? I mean, presumably
>> I'm not running multiple ntpds on the same system, right?
>
> The idea is to be able to run shmmon without stopping ntpd.
That makes sense. Thanks!
> The other half of maki
The default for maxclock is 10. This includes the "pool" entries, of
which the stock Debian configuration has four:
pool 0.debian.pool.ntp.org iburst
pool 1.debian.pool.ntp.org iburst
pool 2.debian.pool.ntp.org iburst
pool 3.debian.pool.ntp.org iburst
As a result, the default is to use 6 pool serv
On 11/4/19 4:32 AM, Hal Murray wrote:
> The pool entries shouldn't be counted as servers.
Can you expand on the meaning of "should" here? Are you saying what you
think the current state is, or what you think the desired state is?
The current state is definitely that pool entries count towards
max
On 11/4/19 12:35 PM, Achim Gratz via devel wrote:
> Richard Laager via devel writes:
>> The default for maxclock is 10. This includes the "pool" entries, of
>> which the stock Debian configuration has four:
>> pool 0.debian.pool.ntp.org iburst
>> pool 1
I have an Apparmor profile in the Debian package, which is derived from
the packaging for NTP Classic, which comes fromm Novell/SUSE with
changes by Canonical for Ubuntu. I had to make some changes to support SSL.
--
Richard
___
devel mailing list
devel
This is a bit off-topic, but I'm hoping this list can help.
Context, to avoid the XY problem:
I'm working with a small, Canadian Internet exchange that offers an NTP
service. They originally had one CDMA and one NTP master clock NTP
server feeding (via NTP) 3x Ubuntu + NTP Classic servers facing
On 11/13/19 1:43 PM, Gary E. Miller via devel wrote:
> Add a GHz power divider for $10 and run all 3 on one antenna.
So basically any splitter that has 3-4 outputs, e.g. SMA connectors, and
a rating of 1-2 GHz (to cover the GPS bands)?
Does this assume an unpowered antenna and GPS receivers that
On 11/17/19 3:00 AM, Hal Murray via devel wrote:
> I'm looking at
> https://docs.ntpsec.org/latest/index.html
>
> Section 5. The Handbook mentions peers, broadcast, and automatic server
> discovery.
>
> We should make a pass cleaning that stuff out.
>
> peer should probably be replaced with s
On 11/17/19 6:44 AM, Sanjeev Gupta via devel wrote:
> Interesting discussion on the 5G requirements
Any chance you can even briefly expand on this? In other words, what are
the 5G requirements that relate to NTP/NTS?
--
Richard
___
devel mailing list
d
Does commit 74308fa20545ae1b34708ec06e38ea244dda7c54 disable the use of
wildcard certificates for NTS? If so, why was that done?
--
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
On 11/18/19 12:59 AM, Hal Murray wrote:
> rlaa...@wiktel.com said:
>> Does commit 74308fa20545ae1b34708ec06e38ea244dda7c54 disable the use of
>> wildcard certificates for NTS? If so, why was that done?
>
> Looks that way. No specific reason. I was just cleaning up and tightning
> things down.
On 11/18/19 2:36 PM, Gary E. Miller via devel wrote:
> I would say another config option. Both for client and server.
I don't see why we would need a config option for the server. If you
don't want a wildcard cert there, don't use one. If you do, do. No need
to configure.
If someone wants an opt
So, it turns out that --enable-debug-gdb does not imply --enable-debug
like I guess I assumed. As a result, the Debian packages do not have
--enable-debug.
Does the project have any recommendation/preference for downstream
distributions? Should we enable debugging?
On the one hand, the answer see
On 11/20/19 6:32 AM, Hal Murray via devel wrote:
> What is the long term importance of shared keys? (old authentication) Is it
> useful/important to have a backup that doesn't use OpenSSL and doesn't depend
> on certificates? (we do use their crypto library)
I don't use them, so that biases m
On 11/20/19 6:32 AM, Hal Murray via devel wrote:
> I'd like a non NTPsec specific web page that lists public servers. (I want
> to
> be able to make changes easily rather than package it where it gets tangled
> up
> with a release mechanism.)
It'd be really nice if the ntp.org folks would add
I now have a second stratum 1 server, with an independent setup. This
allows me to compare the two. Why does ntp1 have this very specific
repeating pattern of local clock offset? It's roughly +7 us, -5 us, +2
us, -4 us and then repeats again, over and over. We can also see that in
the histogram, wh
On 11/20/19 4:33 PM, Paul Theodoropoulos via devel wrote:
> Just a shot in the dark, but it looks to me like an errant
> overly-greedy cron job or systemd timer - perhaps something else is
> polling the serial port on a schedule. If you set up hourly graphs you
> might be able to correlate it with
The NTPviz output says, "TDOP is a dimensionless error factor. TDOP
ranges from 1 to greater than 20. 1 denotes the highest possible
confidence level. 2 to 5 is good."
I routinely have TDOP values below 1, which this text implies is impossible:
https://ntp2.wiktel.com/day/index.html#local_gps
Wh
On 11/21/19 12:55 AM, ASSI via devel wrote:
>> I could try fiddling around with the polling interval. Next steps might
>> be to try raising the polling the interval to 4 and/or lowering it to 1.
> It is generally inadvisable to use too short polling intervals unless
> rthe clock you are disciplini
On 11/21/19 1:15 AM, Hal Murray wrote:
>> ntp1 uses the PPS refclock with a polling interval of 3 from a telecom GPSDO
>> (OCXO):
> What brand/model?
Symmetricom TimeSource 3000. It's an older, end-of-life model that we've
had in place for a while. We have four of them in different sites, but
thi
On 11/23/19 1:28 AM, ASSI via devel wrote:
> Richard Laager via devel writes:
>> On 11/21/19 1:15 AM, Hal Murray wrote:
>>>> ntp1 uses the PPS refclock with a polling interval of 3 from a telecom
>>>> GPSDO
>>>> (OCXO):
>>> What brand/model?
On 11/23/19 12:57 AM, ASSI via devel wrote:
> Richard Laager via devel writes:
>> On 11/21/19 12:55 AM, ASSI via devel wrote:
>>>> I could try fiddling around with the polling interval. Next steps might
>>>> be to try raising the polling the interval to 4 and/
This is probably a question for Hal:
I'm getting a lot of useless-to-me NTS log messages. I assume these are
just random things scanning open ports. I wonder if these should be
toned-down from ERR to DEBUG.
2019-11-23T01:56:32.467297-06:00 ntp2 ntpd[16212]: NTSs: TCP accept-ed from
23.91.196.81:
Also, what does this mean and is it a problem (it's an ERR level)? I'm
seeing it on both servers.
2019-11-23T01:49:33.497786-06:00 ntp1 ntpd[28568]: CLOCK: ts_prev 1574495373 s
+ 497394102 ns, ts_min 1574495373 s + 497388500 ns
2019-11-23T01:49:33.497936-06:00 ntp1 ntpd[28568]: CLOCK: ts 15744953
On 11/13/19 1:43 PM, Gary E. Miller via devel wrote:
> A simple u-blox
> NEO-M8N for $10 will do. Then $5 for a TTL to RS-232 converter.
>
> Get one of these NEO-M8N for $7:
>
> https://www.ebay.com/itm/Replacement-NEO-M8N-GPS-BDS-Dual-mode-Module-Flight-Control-Satellite-ATGM336H/182622902135
On 11/23/19 8:19 PM, Gary E. Miller via devel wrote:
> There is a gpsd program in the contrib/ directory. It tests your
> CPU granularity. On a Raspberry Pi that is about 52 ns. Worse
> on an Intel chip.
It looks like you're talking about clock_test.c. I grabbed the version
from gpsd git:
https
On 11/23/19 3:02 AM, Hal Murray wrote:
> The code that reads the clocks works hard to make sure that fuzzing the
> bottom
> bits doesn't make time go backwards. That logging is what happens when
> things
> go wrong.
>
> What sort of hardware/OS are you running on?
2x Intel Xeon CPU X5460 @ 3
On 11/23/19 1:53 AM, Richard Laager via devel wrote:
>
> On ntp2 (again, this is the u-blox 6 eval kit), I'm getting duplicated
> sequence numbers, which doesn't seem quite right:
>
> rlaager@ntp2:~$ sudo ppstest /dev/pps0
> trying PPS source "/dev/pps0&quo
On 11/24/19 2:23 AM, Udo van den Heuvel via devel wrote:
> I cam across this ublox ntpsec refclock:
> https://gitlab.com/trv-n/ntpsec-ublox
That's certainly interesting. I'd personally be interested, from a
hobby/curiosity* perspective, in such a driver if it automated various
configuration steps
On 11/24/19 3:41 AM, Hal Murray via devel wrote:
> rlaa...@wiktel.com said:
>> I can build from git or with whatever patches, if needed. If something is
>> wrong with this clock fuzzing code, I'd love to help get to the bottom of it,
>> but this doesn't seem like the sort of thing I can sort out by
On 11/25/19 6:29 PM, James Browning via devel wrote:
> The suggested
> means of connecting to a local GPSD instance is to use the gpsd refclock.
That's the opposite of my understanding. See:
https://lists.ntpsec.org/pipermail/devel/2016-October/002392.html
and also make sure to read this:
https://
nning 4.15.0-45-generic and has not been rebooted since 2019-09-28.
Trying again with NTPsec 1.1.3 seems like a useful next step. If that is
good, then I need to bisect the difference.
On 11/25/19 11:46 AM, Achim Gratz via devel wrote:
> Richard Laager via devel writes:
>> These both have
On 11/26/19 12:19 PM, Achim Gratz via devel wrote:
> Richard Laager via devel writes:
>> I only have the clock fuzzing errors on my NTP servers. I don't have an
>> exact matching configuration that's not an NTP server, but: Similar
>> hardware running Debian 10 and
On 11/30/19 6:17 AM, ASSI via devel wrote:
> ASSI via devel writes:
>> is… intriguing. If you follow the code through the function, ts_min in
>> the log should always be ts_prev+sys_fuzz; these two values can't be
>> identical or differ by any other value, ts_min must strictly be greater
>> than t
On 12/1/19 2:17 AM, Richard Laager via devel wrote:
> On 11/30/19 6:17 AM, ASSI via devel wrote:
>> ASSI via devel writes:
>>> is… intriguing. If you follow the code through the function, ts_min in
>>> the log should always be ts_prev+sys_fuzz; these two values can'
On 12/1/19 2:44 AM, Achim Gratz via devel wrote:
> Richard Laager via devel writes:
>> The issue persists when removing "nts" from "server" lines (i.e.
>> disabling NTS client behavior).
>>
>> The problem goes away when disabling NTS server behavior.
On 12/5/19 8:33 AM, Hal Murray via devel wrote:
> Last night Richard Laager sent me some IRC stuff indicating that the fuzz
> mess
> was due to NTS threads calling get_systime() which isn't thread safe. In
> hindsight, I should have seen that sooner.
>
> I just pushed a fix. Please test.
I f
On 12/9/19 2:56 AM, Hal Murray via devel wrote:
> Is there any reason to support anything older than TLS 1.2?
No. The NTS standard requires TLS 1.2 as a minimum (since NTS is a new
protocol, there is no need for backwards compatibility with old TLS).
--
Richard
signature.asc
Description: Open
Hal,
It looks like you broke building on macOS:
https://gitlab.com/NTPsec/ntpsec/commit/22c134c8b20e9a897fc5521df871606167067b2e
that links to the pipeline here:
https://gitlab.com/NTPsec/ntpsec/pipelines/101491292
which links to these failed jobs:
https://gitlab.com/NTPsec/ntpsec/-/jobs/37
https://www.ntpsec.org/contributor.html
links to hacking.txt (and mentions that inline), which is now hacking.adoc.
--
Richard
signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailm
Upon further investigation, there is a concern about the GPS antenna
placement.
Does anyone have recommendations for GPS antenna RF-to-fiber converters
or other ways to have the GPS antenna a long way (in a building) from
the GPS receiver?
--
Richard
signature.asc
Description: OpenPGP digital
MR !1037 [1], by James Browning, "significantly revises the document
build system. It adds the ability to use asciidoctor, asciidoc3, and
odd-numbered versions like asciidoc-py3 9.0.0rc1. It also changes the
build system to fail hard, unless there is a working AsciiDoc toolchain,
or both --disable-
On 2/2/20 3:44 PM, Jason Azze via devel wrote:
> It looks like the --enable-doc waf configuration option was removed in the
> commit "Add support for other asciidoc processors". Was there any discussion
> about this change?
Yes. See the mailing list archive and MR !1037.
--
Richard
signatur
On 2/2/20 6:25 PM, James Browning via devel wrote:
> On Sun, Feb 2, 2020, at 3:49 PM Gary E. Miller via devel
> wrote:
>>
>> Yo Jason!
>>
>> On Sun, 02 Feb 2020 16:44:25 -0500
>> Jason Azze via devel wrote:
>>
>>> It looks like the --enable-doc waf configuration option was removed
>>> in the comm
We discussed this in #ntpsec. For context, I wasn't the original MR
author, but I was very involved in review of the MR, approved it, and
ultimately merged it.
My understanding is that there are two objections here:
1) Changing the default was mixed in with other changes.
2) It is undesirable t
On 2/17/20 1:34 PM, Gary E. Miller via devel wrote:
> But, when I tried to build with git head, I now get this error:
>
> Waf: Leaving directory `/usr/local/src/NTP/ntpsec/build/main'
> Fatal Python error: PyThreadState_Get: no current thread
> ../Do-config-ntpsec: line 11: 13733 Abort trap: 6
https://blog.ntpsec.org/2020/02/15/copyright-year.html
"There is no need to include the year in a copyright declaration
statement. And related, there is no need to update the year statement,
add new year statements, manage year range statements, or any of that
stuff. It is tedious, boring, adds no
On 2/22/20 8:57 PM, James Browning via devel wrote:
>> Looks like the second test is backwards. It's printing the message on a
>> system where pipefail works.
>>
>> if (set -o pipefail) 2>/dev/null
>> then
>> echo "### Old sh - no pipefail"
>> echo "### We can't test for errors during build"
>
On 2/22/20 6:15 PM, Hal Murray via devel wrote:
> Context is the seccomp tangle. Issue #633
>
> Should I just add a helper that looks in /etc/os-release?
Are you really, absolutely, positively sure that you can't check for the
feature itself directly. If you start going down the distro-checking
On 2/24/20 11:02 PM, Hal Murray via devel wrote:
> I'm looking at strace output. There are a few calls used only once or twice.
>
> It seems obvious that we should drop root as early as possible. But it's not
> obvious that we should enable seccomp early.
>
> If we turn on seccomp early, then
On 2/23/20 4:59 AM, Hal Murray via devel wrote:
> Should we drop secomp? It's a pain to maintain.
I wouldn't cry.
> How many people use it? Richard: do you turn it on for the Debian builds?
I do not. It seems really fragile to me. A change in an underlying
library can break a working binary, p
On 3/23/20 5:43 AM, Eric S. Raymond via devel wrote:
> Hal Murray :
>> We can do several things:
>> 1) clean out the ifdefs that make things work with older versions of
>> OpenSSL.
>> That is drop support for systems that haven't upgraded their OpenSSL to
>> a
>> supported version.
>> 2)
On 3/26/20 3:35 PM, Hal Murray via devel wrote:
> Would somebody please fix and/or teach me how to do it.
>
> https://gitlab.com/NTPsec/ntpsec/pipelines/130148924
> had 11 failed builds.
You've raised the OpenSSL requirement to > 1.1.1a. Assuming OpenSSL is
mandatory to build NTPsec, then you've
On 3/26/20 4:13 PM, Richard Laager via devel wrote:
> On 3/26/20 3:35 PM, Hal Murray via devel wrote:
>> Would somebody please fix and/or teach me how to do it.
>>
>> https://gitlab.com/NTPsec/ntpsec/pipelines/130148924
>> had 11 failed builds.
>
> You
ntpd seems to load the TLS certificate and key before dropping
privileges. Unfortunately, when it tries to *reload* the certificate
later, it has dropped privileges and fails. This is a bit of a trap, as
a sysadmin can think a setup is working when it isn't. (This bit me.) I
think it would be bette
On 4/20/20 3:22 AM, Hal Murray via devel wrote:
>
> One of the last changes to the draft NTS RFC was to change the string
> constant
> used to make the keys that are used to encrypt and authenticate the NTP+NTS
> traffic.
>
> There isn't any easy way to make a backwards compatible update.
>
>
On 5/8/20 1:10 PM, Gary E. Miller via devel wrote:
> I think the year of first publication still has some use as it disambiguates
> which version of copyright law applies.
The "year of first publication" applies per copyrightable thing, so if
the file has multiple changes, you'd need multiple year
On 6/9/20 3:20 AM, Mike Simpson via devel wrote:
> As you only get a 90 day very from LE I now have a cron job after the
> “certbot renew” which copies the keys over and chown them. It feels clunky.
Use a deploy hook. I wrote the attached one for Debian. Note that Debian
uses user "ntpsec" and gr
I don't think I ever got an answer on this one.
On 7/6/20 11:28 PM, Richard Laager via security wrote:
> Another NTP CVE (which is already public)... does this affect NTPsec?
>
> On 7/6/20 12:55 PM, Moritz Muehlenhoff wrote:
>> This was assigned CVE-2020-13817 for ntp.org:
>> http://support.ntp
On 8/12/20 4:44 AM, Hal Murray via devel wrote:
>> Is that a bug, or should I remove that chunk of text?
>
> That doesn't seem very clear. Let me try again.
>
> The documentation mentions /etc/services
> The current code doesn't use it. It passes "123" rather than "ntp" to the
> DNS
> lookup
On 8/13/20 5:48 AM, Hal Murray via devel wrote:
>>> https://bugs.ntp.org/show_bug.cgi?id=3596
>
> That bug talks about feeding bogus time to a system by guessing the transmit
> time stamp.
>
> When ntpd gets a response, it drops responses where the time-stamp it sent
> doesn't match the corre
On 8/15/20 4:59 AM, Hal Murray via devel wrote:
> Let's start with the simple case - no NTS. There are a few NTP servers with
> names
> that return multiple IP Addresses. I'd like to be able to test all of those
> too. Fortunately, we can do that by specifying their individual numerical IP
>
On 9/1/20 10:27 PM, Hal Murray via devel wrote:
> What's the word for what Debian does?
In the package: no seccomp.
I really don't see the advantage in seccomp; it seems like a lot more
trouble than it is worth.
I do ship an AppArmor profile.
--
Richard
signature.asc
Description: OpenPGP di
On 9/2/20 12:47 PM, Gary E. Miller via devel wrote:
> Yo Eric!
>
> On Wed, 2 Sep 2020 08:07:53 -0400 (EDT)
> "Eric S. Raymond via devel" wrote:
>
>> Retaining support for Python 2 proliferates test paths and
>> complicates the fix for at least one outstanding bug.
>
> Python 2 will be with us
On 9/2/20 2:30 PM, Hal Murray wrote:
>> I do ship an AppArmor profile.
>
> Thanks. That's the word I was fishing for.
>
> I've never worked with it. Is there a good introductory writeup?
There is various documentation, but I don't have anything off the top of
my head to direct you to.
> Are t
Let me start over now that I've reviewed the specifics of the NTPsec
scripts and build system again:
We are currently using "#!/usr/bin/env python" in all the scripts, and
waf uses the same. The minimum to do to drop Python 2 is:
1. Change waf's shebang:
-#!/usr/bin/env python
+#!/usr/b
On 9/2/20 7:54 PM, Gary E. Miller via devel wrote:
> A big one: RHEL. As I said earlier, any time Python 2 breaks in gpsd
> it only takes a day or two for complaints. I have customers that will
> be on RHEL for years to come. They need NTPsec.
RHEL 6 support (measured in terms of security update
On 9/2/20 7:44 PM, Gary E. Miller via devel wrote:
>> 1. Change waf's shebang:
>> -#!/usr/bin/env python
>> +#!/usr/bin/env python3
>
> Uh, no. That breaks Gentoo eselect.
How, specifically?
What do these give on your system?
python3 --version
ls -l /usr/bin/python3
For compariso
On 9/3/20 1:12 PM, Gary E. Miller via devel wrote:
> On Thu, 3 Sep 2020 02:30:43 -0500
> Richard Laager via devel wrote:
>
>> On 9/2/20 7:44 PM, Gary E. Miller via devel wrote:
>>>> 1. Change waf's shebang:
>>>> -#!/usr/bin/env python
>&g
On 9/3/20 12:39 PM, Gary E. Miller via devel wrote:
>> There may be other reasons to keep Python 2 support, but as Richard
>> says RHEL 6 will stop being one of them before our next point release
>> after this one.
>
> And then how long for users to update? Two years? Three years?
The point of
On 9/4/20 12:16 AM, Gary E. Miller via devel wrote:
> On Thu, 3 Sep 2020 23:28:33 -0500
> Richard Laager via devel wrote:
>
>> NTPsec can require Python
>> 3 as long as all distros that NTPsec supports can install Python 3.
>
> Yup. Let us know when that happens. Go
[Reposting to list.]
On 9/3/20 11:15 PM, Gary E. Miller via devel wrote:
> The case you left out:
>
> # select 2.7
> spidey ~ # python3 --version
> Python 3.8.5
>
> Uh, oh. That is why we do not do that.
No, that is exactly as intended. The context here is that we want to
require Python 3
On 9/4/20 1:37 AM, Hal Murray via devel wrote:
> Another question... How many systems are we interested in that have Python2,
> don't have Python3, and have a version of OpenSSL that is too old for NTS?
The OpenSSL requirement* (>= 1.1.1b) requires a lot newer distro
versions than the Python 3 r
On 9/5/20 2:19 PM, Gary E. Miller via devel wrote:
> And yet, Gentoo, and others still ship 2.7. And end users still use it.
This is not a discussion about whether Gentoo should drop Python 2.7.
It's not a discussion about whether users should stop using Python 2
entirely. Perhaps we can intuit e
On 9/5/20 5:39 PM, Gary E. Miller via devel wrote:
> It would be nice if you answered my objections
Your primary concern seems to be that users will complain. Let me take
smaller bites at that:
RHEL 7 has Python 2.7.5 and Python 3.6.8. User "complains". We say, "run
`yum install python3`". Is thi
On 9/6/20 5:43 PM, Hal Murray via devel wrote:
> Anybody using the modem driver?
I tested in November, for fun, not any practical reason. NIST's service
is still up. The USNO service was dead. I emailed them and received no
response.
I posted a couple patches, which were merged; see `git log 9a85
On 9/7/20 11:03 AM, James Browning via devel wrote:
> I (re)developed a Python wrapper around a C FFI stub[1]. It is largely
> based around my merge request !1010 [2].
I'll repeat from here, in case people want to respond to those points:
https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1010#note_
I touched up the the shebang MR !1166 just now.
It consists of three commits:
The first commit is:
Subst installed Python shebangs
This adds a ./waf configure --pyshebang option. This is used as the
shebang in the installed Python scripts. (Scripts that are not
installed
On 9/17/20 11:54 AM, Gary E. Miller via devel wrote:
> I agree with the first of 4 goals of the MR.
...
> Rather than go around and around, how about a simple MR that only
> implements goals 1 and 4?
That is the first commit. I will merge that commit soon, barring any
objections to that piece.
On 9/17/20 7:07 PM, Gary E. Miller via devel wrote:
> On Thu, 17 Sep 2020 16:52:06 -0700
> "Gary E. Miller via devel" wrote:
>
The fallback, goal 4, is "/usr/bin/env python". Does anyone
object to making that "/usr/bin/env python3"?
>>>
>>> I am in favor of that change. I'm happy t
On 11/11/20 7:07 PM, Hal Murray via devel wrote:
> I've been thinking about something like this for a while. The idea is to be
> able to specify the IP Address to be used for contacting a NTP or NTS-KE
> server.
If you want to specify the IP address, just specify the IP address
("server 1.2.3.4
On 10/6/20 8:29 AM, James Browning via devel wrote:
> So, I was running ntpviz rarely, I updated to a (recentish git head), I
> added a gpsd module symlink under ntpclients/, and boom breakage. I
> followed the traceback to a line, I patched the line a couple of times,
> and I requested the followi
On 12/12/20 10:00 AM, James Browning via devel wrote:
On 2020 December 19, I intend to merge > !1196
Merged. Thanks! Closed #680.
(the first patch of) !1167
I left some comments and questions there.
!1189
LGTM. Approved. I'll leave it to you to merge. It'd be nice to have a
"Fixes #558
On 12/12/20 7:07 PM, Gary E. Miller via devel wrote:
NTPsec git head broke Python 2.7, badly.
I believe James B is looking at test failures under certain conditions,
but I've never been able to reproduce them. I wonder if this is that
issue. Do the installed binaries break in the same way whe
On 12/12/20 7:53 PM, Gary E. Miller via devel wrote:
On Sat, 12 Dec 2020 19:46:22 -0600
Richard Laager via devel wrote:
On 12/12/20 7:07 PM, Gary E. Miller via devel wrote:
NTPsec git head broke Python 2.7, badly.
I believe James B is looking at test failures under certain
conditions, but
On 12/12/20 9:17 PM, Gary E. Miller via devel wrote:
No, the tests are run before installing in DESTDIR. So that you can stop
and not install broken things.
You want to be using the
built files before installing in DESTDIR.
Agreed 100%.
The tests run before install and need to work in the
On 12/14/20 3:21 PM, Hal Murray via devel wrote:
I setup a new machine over the weekend. Fedora 33, Python 3.9.0
After a build and install, ntpq couldn't find ntp.ntpc
I fixed things by setting up /etc/ld.so.conf.d/ntpd.conf
containing /usr/local/lib64/ and running ldconfig.
Yeah, that's app
1 - 100 of 423 matches
Mail list logo
