Linux has been doing it since 2006.
FreeBSD got it in 1999
No big deal. Just an opportunity to cleanup a batch of crufty #ifdef-s
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/l
We allow/require UTF-8 rather than simple ASCII. I know we need that to
get the character for micro, as in microseconds. Do we need it for
anything else?
--
I saw a note recently about AI being susceptable to hiding evil code in
invisible unicode.
New Vulnerability in GitHub Copilot and
matthew.sel...@twosigma.com said:
> Sounds good (either commenting or trying this again). I'll proceed with
> cu= tting the release very late tonight.
Great. Thanks.
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo
Fred Wright said:
> If that's really true, then SCM_TIMESTAMPNS_OLD should be defined any
> time that SO_TIMESTAMPNS_OLD is defined, so using the correct macro
> should work. If SCM_TIMESTAMPNS_OLD is *not* defined in this case (but
> the correct value is known)
There are a couple of shoulds in t
> If the values are identical, then it's not functionally incorrect, but
> it's certainly conceptually incorrect to compare an SO_* value to a
> cmsg_type field. And if the values are identical, it wouldn't change the
> behavior to use the correct name.
Sorry, I guess my previous message wasn
> I do know that the SO_* symbols are for the socket options and the SCM_*
> symbols are for the CMSG types, so I don't see how this could possibly be
> correct. Note the code immediately above it.
The OLD stuff is a mess.
I did it the way you expect, but that didn't work because
SCM_TIMESTA
> When I made the debug log changes you asked for last night, I was
> thinking the same thine. A lot of duplication.
> After release we should rip and shred that.
Sounds good to me.
--
These are my opinions. I hate spam.
___
devel mailing lis
Is there any reason to have a DPRINT next to a msyslog that prints the
same stuff?
DPRINT is only useful if you are running with -n and msyslog stuff goes to
the console too in that case. Right?
--
These are my opinions. I hate spam.
___
deve
> Change pushed.
Thanks.
+Alternatively you can create a link your python3 called python. Assuming
Looks like a "to" got lost.
create a link your
create a link to your
> > > Should we fix waf install to do the magic for SELinux?
...
> Gentoo, Ubuntu, and others, do SELinux. BUt not by def
>> On FreeBSD, ./buildprep -n says:
>> pkg install bison python3
>> ln -s /usr/local/bin/python3 /usr/local/bin/python
>> pkg install ca_root_nss
>> I think the ln step is bogus. So I'll remove it.
> What makes you think it's bogus? Aside from whether it's best to point
> to 'python3' or t
What's the story on new waf install directories vs old waf directories?
Do we need to change the code and/or fix the documentation?
Is there anything else we need to sort out before a release?
--
These are my opinions. I hate spam.
___
devel mai
> A lot of changes in the last few days.
Nothing has changed in the core ntpd code in a long time.
Many of the recent changes have been in documentation.
I've improved buildprep. It's still pretty crappy but nobody was
somplaining.
> Some I am not happy about.
Anything specific?
> I sug
If somebody is still using Python 2, do they have to manually fix the link
from waf to point to the old waf? Or is there some magic that takes care
of that?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://l
Anybody understand this area?
Reading state information... Done
Package python-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
python-
> Same conceptual idea as python-is-python3, right?
> But just install python3-dev directly.
Maybe, but there is something going on that I don't understand yet.
Here is the code in my buildprep:
apt)
$install build-essential# Build environment
[README-PYTHON]
.> What would be the standard name?
> Dunno. Never seen a file like that, so can'tany be any standard.
I think README is a fairly common name for a file in a direcory if you are
trying to help somebody get started. It's common enough that it has a
Wikipedia page.
https://en.w
>> Have you looked at README-PYTHON?
> See attached.
Looks good. Thanks.
+When building NTPSec for installtion, the install procedure asks the
installtion => installation
+current python for the proper locatiopn to install the python modules.
locatiopn => location
(Fixed in Fedora 39, Sep-
Gary said:
>> Have you looked at README-PYTHON?
> Nope. Non standard file name. Why would anyone look there?
What would be the standard name?
> Actually, who ever reads any of the doc??
It's referenced in 2 other docs:
INSTALL.adoc:More info in README-PYTHON.
NEWS.adoc: See README-PYT
Gary said:
>> We've been talking about a release for a long time. I've been
>> assuming people have been testing.
> I do not assume that. Likely they will test after release.
By "people", I was thinking of those who read @devel.
I assume your "they" is for the much larger collection who wil
> Best to educate the user to debug his own Python issues.
Have you looked at README-PYTHON?
I thought it was pretty good. If you think a paragraph or whatever about
PEP would help, please add it. I think a short paragraph with a link to
the long version would be a good addition, but I don't
g...@rellim.com said:
>> I'll punt on any distros where it's not on by default.
>> I may try it for Fedora, but not until after the release.
> Any distros that do not have 'python' are broken, not PEP compliant. And
> a bug should be filed upstream.
Sorry, I didn't quote enough context.
My "af
>> That "to" looks backwards to me. I expect:
>> link python to your python3
> python3 exists, python does not. So you create python by linking
> it to python3. As Fred says: like cp.
The ln command looked OK to me. I was commenting about the descriptive
text. To me, "to" has an arrow fr
> +Alternatively you can link your python3 to python.
> +`ln -s /usr/bin/python3 /usr/bin/python`
That "to" looks backwards to me. I expect:
link python to your python3
That command line doesn't work on FreeBSD or NetBSD
FreeBSD:
$ which python3
/usr/local/bin/python3
$
NetBSD:
$ which
> MR 1454 submitted.
Approved and merged.
It case it helps...
All of my systems have python setup and none of them have python2.
I've been working on buildprep recently. For all the distros thet I've
tested/fixed, buildprep now sets up python to go to python3.
--
These are my opinions. I
I think we are ready.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
buildprep tried to handle both python2 and python3
But the code the does some of that is off to the side in a tools () subr
so some people editing the mainline code (maybe only me) don't see it. As
a result, some of the mainline code now assumes python3.
It's more complicated than that. We
I think we should put together a recipe for each distro that will get
ntpsec running after a fresh install from their download media.
We probably need a few notes on the "fresh install" step. That's to make
it reproducable and speed things up for those of us who aren't super
familiar with that
> It's Selinux (most of) the way down. YMWV
Great. Thanks.
> # /sbin/restorecon -v /usr/lib/systemd/system/ntp*
Does install need to do that?
Do the systemd files get installed each time, or only the first when they
aren't there yet?
> # restorecon ${PREFIX}/{,s}bin/ntp*
Looks like install need
I've got a fresh Fedora install. ntpsec builds and installs, but systemd
doesn't like the ntpd.service that got installed. It's the same as what
I'm using on other Fedora systems.
Has anybody seen this before? I haven't been able to get it to tell me
why it doesn't like our service files.
On a fresh FreeBSD install and a fresh ntpsec build+install, I get
INIT: must be run as root, not uid 123
That's when using the normal rc startup stuff.
It worked after I ran it from the command line for a while.
Does anybody understand what's going on here?
(The code is all there. I should
> There are definitely systems with python3 and no python. Eg, Debian 12
> for example.
Some (most?) distros have a tiny package that sets up python to go to
python3.
On Debian, it's python-is-python3, and buildprep installs it.
On Fedora, it's python-unversioned-command-3.13.2
I'll add it
> Please remove the older waf binary and replace the symlink with the newer waf
> binary itself.
OK. Done.
Can you do the release this weekend?
I'm working on some documentation tweaks.
My plan is to do a fresh install of ntpsec on a fresh install of Fedora,
Debian, and FreeBSD to see if I
James said:
>> Why are we keeping the old version?
> Paranoia, I figured that if I removed it there would be a high chance
> something would go wrong and I would be responsible. Also, it is not
> that expensive.
> If you want to remove it go ahead; the symlink could go in the same
> commit and
> Python 2.7 works with either version of waf.
Thanks.
Why are we keeping the old version?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
> The code has changed, behavior is not noticeably different than it was before.
Didn't it change from dist-packages to site-packages on Debian and friends?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://lis
Found it:
https://lists.ntpsec.org/pipermail/devel/2019-February/007659.html
From: Richard Laager
Subject: Is it time to drop seccomp?
Here is the key chunk. Thanks Richard!!
I think the setuid/setcap as described above is dangerous. Unless you
limit the permissions on "other" (e.g. chmod 27
>> Is that a bug or feature?
> I think it is a bug, but that is this years fashion.
Do we fix it, or document it?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
James said:
>There is no magic, no fancy Python tricks. When you run waf or
>waf-2.1.4 you get new behavior. waf-2.0.25 gets you new behavior
>closer to the old behavior.
Why do we still have the old waf? Do we need directions on when/how to
use it?
There is a note in NEWS, but
> I tried to bisect the git. No luck. The issue depends on which Python I
> am running.
commit e899c2ffd4243e933150f2349874e4e462657c54
Author: James Browning
Date: Thu Mar 13 02:06:11 2025 -0700
Use waf 2.1.4, revise, and drop Py2.6 builds.
Which python works the old way?
We now ha
James said:
> I do not; a quick search suggests that SHM needed root.
"needed root" doesn't make sense in the context of that discussion. Linux
has a fine grained capabilities facility. See man capabilities(7). There
is one for SHM.
CAP_IPC_LOCK
. Lock memory (mlock(2
There is also dist-packages vs site-packages on Debian
The old waf used dist-packages
The new waf uses site-packages (like Fedora)
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/list
I don't use PYTHONPATH
The old waf used to install python libraries in /usr/local/lib64/
The new waf now installs things in /usr/loca/lib/
Is that a bug or feature?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
h
Back in 2018, I did some work on getting ntpd to start as ntp:ntp
There was a way on Linux to set some capabilities on a file.
Somebody talked me/us out of this. I don't remember why.
I've poked around in the archives, but I haven't found the message that
I'm looking for.
Does anybody rememb
g...@rellim.com said:
> I agree, way too much work. I would leave OS compat #ifdefs as they are.
> Partly because testing an alternative would be a pain. A few things
> could be combined using POSIX.
My comment about a different module for each OS/environment was assuming
we were working wi
You provided the patch to make our code run on FIPS systems.
Are you using NTS?
We are currently using an old libriary for the NTS crypto. I'm looking
into using OpenSSL directly so we can retire that library. The library
works on FIPS systems. The new code doesn't.
If you are not using N
I agree that the current DEBUG stuff needs fixing.
I think we can get around the droproot type problems by having a module
for each environment and picking the right one at build time. The
disadvantage with that approach is that if there is any code common to
more than one implementation, then
Gary said (in a gitlab discussion):
> We need to get rid of most #ifdef. Newer languages don't support it, and
> it leads to binaries that behave differently. DEBUG should be the first
> to go.
How do they configure things?
I expect the environment is new enough that most code can run on, fo
g...@rellim.com said:
> https://docs.asciidoctor.org/asciidoc/latest/lists/ordered/#styles
> Very fiddly stuff.
Thanks. That was exactly what I was looking for. It said to put a
{empty} after the dot. That works for both man page and html.
--
These are my opinions. I hate spam.
__
>> RFC 8915::
> ^^
> Starts a list.
Most of the others that also use :: come out looking OK. The next line on
them starts with "David" instead of "D." and they don't get the "1" in
front of the line of text.
I was wrong about the web page being OK. It changes the D. to A. and
inden
I added a few RFCs to the ntpd man page.
The code looks like this:
RFC 8915::
D. Franke and D. Sibold and K. Teichel and M. Dansarie and R. Sundblad
_Network Time Security for the Network Time Protocol_, RFC 8915
That turns into this:
RFC 8915
1. Franke and D. Sibold and
https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1430
Should we include it in the release?
Maybe mark it as experimental?
Wait until after the release?
...
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://
I just merged James' MR that adds adds the new waf and keeps the old waf.
If you have any python2 environments, please test, and give an extra scan
over the printout. I don't have any python2 environments to test with.
--
These are my opinions. I hate spam.
___
It's working again. I assume it hung while trying to download something.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Enforcing VM Isolation
Creating nesting VM tunnel
Creating nesting VM macos-14-xcode-15
Dialing nesting daemon
ERROR: Job failed: execution took longer than 1h0m0s seconds
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.or
What needs to happen before we can get a release out?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
I've pushed Richard's suggestion from a week ago.
from NEWS
* Python 2.7 is now the minimum supported version.
This is likely to be the last release supporting Python 2.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpse
Thanks. Your comments seem good to me.
Does new waf run on python 2.7?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
matthew.sel...@twosigma.com said:
> I sounds like we would want a release out before we start mucking with
> threads given that your review of the code shows a lot of potential
> complexity.
It's not so much the complexity as the time. We've been talking about a
release for a long time. How
I've been trying to cleanup the thread priorities. So far, all I have is
a sore head.
The root of the problem is that we are creating the threads after dropping
root. You might think that it would be OK to reduce your priority, but it
doesn't work that way.
pthread_create() has an option t
James said:
> Doesn't NTPsec also use a thread or two to handle NTS-KE traffic?
Good catch. Thanks.
>> The other is from the time the transmit side grabs the time until the
>> packet hits the wire. With NTS, that window is a lot larger -- it can't
>> do the crypto until it has put the time s
> This is from: https://bugs.debian.org/1086000
> Does anyone have insight on this? Is running at real-time priority
> actually helpful to timekeeping accuracy?
Yes, it helps. I don't have any numbers to say how much. How often is
probably more interesting.
I'd be happy if we changed it to old
I think we are getting close. I'm shifting my efforts to testing.
Does anybody know of things that need fixing or merging or ??? before a
release?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://lists.nt
matthew.sel...@twosigma.com said:
> Let's remove this CI target. There's no need to test a specific version
> of AsciiDoc 3 on every commit.
It was working yesterday after James' fix.
It was broken a few minutes ago. So I took your suggestion and commented
it out.
--
These are my opinions
matthew.sel...@twosigma.com said:
> Yes. You can manually run a pipeline manually at
> https://gitlab.com/NTPsec/ntpsec/-/pipelines
That's the normal CI pipeline collection of tests. Is there an option to
run the scheduled tests that I didn't see?
> What's the advantage to running a pipelin
matthew.sel...@twosigma.com said:
> It's an asciidoc implementation written in python 3, instead of ruby.
> We're only testing that the asciidoc program runs without errors. We're
> not checking that it produces the expected output.
Thanks.
Yup. Testing documentation is an interesting problem
matthew.sel...@twosigma.com said:
> Let's remove this CI target. There's no need to test a specific version
> of AsciiDoc 3 on every commit.
What's interesting about the 3? Are some of the other tests also testing
plain old asciidoc?
James' fix worked so things are back to normal. Do we wa
AsciiDoc-3-Fedora :
$ wget https://asciidoc3.org/asciidoc3-3.2.3.tar.gz
[0] Downloading 'https://asciidoc3.org/asciidoc3-3.2.3.tar.gz' ...
HTTP ERROR response 404 [https://asciidoc3.org/asciidoc3-3.2.3.tar.gz]
I poked around a bit and didn't find anything with version numbers. There
was a lates
What does this mean? Is it going to cause us any trouble?
/home/murray/ntpsec/raw/./waf:101: DeprecationWarning: Python 3.14 will,
by default, filter extracted tar archives and reject files or modify their
metadata. Use the filter argument to control this behavior.
for x in t: t.extract(x)
Richard Laager said:
> I don't think -Werror should be the default. That can break things that
> are perfectly fine, especially if someone is trying to build an existing
> release on a newer compiler that added a new warning.
> If you made -Werror the default in release builds, please revert tha
> I've certainly seen warnings without that option, so it probably just
> means "enable *more* warnings".
Correct. I fixed that comment too.
> For example, I just submitted an MR to fix a warning for something which
> is perfectly legal, but which broke the build here due to -Werror.
Thank
It's on now, and -Werror too. Gitlab is happy.
openSUSE still has an old old Bison.
I had to fix a few printf errors. Mostly %ld getting a long long.
I think those are harmless on little endian but would break on big endian.
(That's assuming the value fits in a long.)
--
These are my opi
Thanks.
Gary said:
>> Should we be running with -Werror
>> to turn warnings into errors so gitlab/CI will notice? Any reason
>> not to do that?
> Try it and see. If the makes the CI look terrible, turn it back off.
We still have the warning from old old Bison.
warning: switch missing defau
waf configure --help says:
--enable-warnings Enable annoying CC warnings
Are they really annoying? My normal build script turns it on without
problems.
What does gitlab do with warnings? Should we be running with -Werror to
turn warnings into errors so gitlab/CI will notice? Any reas
> Though it's best to recommend forking and then cloning the fork, since
> that's a more appropriate setup for submitting MRs.
Thanks.
It would be great if you could write a few words about that -- or add a
URL to someplace that already explains it. But that's not part of the
release.
--
I ran it on a subset of my toys. All looks good.
I see header padding on FreeBSD and NetBSD. I didn't see anything funny,
but that's only a manual inspection.
The FreeBSD BINTIME looks good.
Testing SO_TIMESTAMP+SO_TS_CLOCK+SO_TS_BINTIME:
Sent at 1738968876.289623, received at 1738968
Sigh. It needs a dose of TLC.
The Downloads section has 2 URLs.
The first one is https://gitlab.com/groups/NTPsec
git clone on that one doesn't work.
The second is https://github.com/ntpsec/ntpsec
git clone on that worked
We should have a git clone example to copy/paste.
The Tarba
Is this the right time to convert all our python code to go?
(That's post release)
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
> As Alice would say, "curiouser and curiouser". Just when I think I've
> figured out the reason for one bit of bizarreness, you find another. :-)
I think the current code works on all my systems.
> What's the breakdown in the 32-bit NetBSD case? One would hope that the
> payload is 64+32 a
>> I have no objections to cleaning up the code so that the NTP_SIZEOF
>> stuff isn't needed. I like your LAST_time_t example.
> Do you want me to fix the other similar case and make it an MR?
If you want me to review or test, sure make it an MR. If you you can test
well enough, just push it.
>>> Oh, now I have context. The only extra code for cross builds would
>>> be the --march. When you use --march then /usr/include/sys may not
>>> be used for . cc swaps sys directory to one approriate
>>> to the target.
>> Are you sure of that?
> 100%
I don't have a cross build setup work
>> It didn't know what a struct timeval was.
> Did you set the required defines first?
I don't think I have to set anything.
> Any place I can go to see the BSD man page
> and the include file contents?
I got the man page via google: freebsd man timespec
Google found their source code on git
Linux:
x86-64:16
I don't have any really really old systems.
x86-32: 8
Debien, 6.1.0-29-686-pae i686
Arm: 8
Arm64: 16
FreeBSD:
x86-64: 20 <===
x86-32: 8
Arm: 16
Arm64: 20 <===
NetBSD:
x86-64: 20 <===
x86-32: 12
Arm: 20 <===
long is 4, time_t is 8, timesp
> Did you see my comment about how dropping Python 2 before getting rid of
> the polyXXX wrapers is dangerous, because removing the wrappers without
> properly fixing the underlying code is more likely to break Python 3 than
> Python 2?
Yes, but I don't know enough about Python to know what it
The current code in wafhelpers/check_sizeof.py seems to work.
There are 2 reasons I would like to keep and understand it. One is
general curiousity. It was commited by ESR and he is usually very good
about fixing crappy code. My best guess is that it was part of a large
chunk that was copie
> Uh, yes. I'll continue to object. It buys us nothing now, and it will
> annoy some people. Maybe later this year.
OK. I guess I missed your previous objections.
Have we actually made contact with anybody using python2 (and NTPsec)?
Should we put a note in NEWS saying this is the last re
It would be really nice if we had a working example of a cross compile,
and something like a HOWTO-cross to document it, including the packages
that need to be installed.
It would be nice if option-tester could also do an install, bin-test, and
uninstall.
Best in a scratch directory.
--
T
Neat. Thanks.
> - libm
> - stdbool.h
Those should be part of the POSIX environment.
At worst, we can clone stdbool.h and find the source for libm and grab the
parts we need.
> - struct timex and two of its members
This will be the tricky part. I'm expecting a small shim to translate
ntp_adjt
>> That was my first try. It didn't work on BSD.
> Care to share what the failure was?
It didn't know what a struct timeval was.
> Where can I find that man page?
man timeval on this Linux box says:
SYNOPSIS
#include
Without the sys, it worked on Linux but not on BSD.
With the sys it
The unobvious part is the code in wafhelpers/check_sizeof.py that handles
the cross case for getting NTP_SIZEOF_TIME_T and friends.
Please take a look at the code. It's got a loop!!!
--
These are my opinions. I hate spam.
___
devel mailing lis
So if you see warnings from gitlab, please investigate.
If this keeps working for a while, we should undo the
allow_failure: true
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/l
> Does anybody have a working cross build setup that I can copy?
I have one now. Or at least one that gets far enough to tickle this bug.
The cross compile stuff for sizeof is, well, unobvious to me. I think I
asked about it a while ago with no response.
It came from ESR in 2016 with no note
Thanks.
There are several tangles in your response.
>> +("sys/time.h", "struct timeval"),
> DOn't do that. Per the man page:
That was my first try. It didn't work on BSD.
On all the systems I'v tried, man timeval says:
#include
So that part seems to be working OK.
>> That lis
Anybody understand this?
While I was cleaning up the long long in struct timex tangle, I added a
line to wscript to document the size of struct struct timeval
sizeofs = [
("time.h", "struct timespec"),
+("sys/time.h", "struct timeval"),
("time.h", "time_t
I've seen this twice.
This is talking to a remote system that has (very) recently restarted ntpd.
Traceback (most recent call last):
File "/usr/local/bin/ntpmon", line 371, in
sl = statline(peer_report, mru_report, nyquist)
File "/usr/local/bin/ntpmon", line 84, in statline
leader =
There are a lot of merge requests in the queue. I approved a few without
as much checking as I would like to do. I expect to do more of the same,
so git master may be unstable for a while.
We will have to do a lot of testing before the actual release.
For now, I've gotten side tracked on fi
Is there a way to catch configure time test code snippets that don't
compile? An example within our code would be great.
If so, I'm pretty sure I can move the test I need from run time to compile
time.
Has anybody actually tested our cross build mode? That is run on X86,
cross build for ar
Currently, our CI cross compile armhf case is failing. We discussed this
back in Sept and I fixed things by handling each of 5 cases individually.
It turns out there are more than 5 cases. I missed the others so that's
why cross armhf is currently failing.
I can add another handful of spec
I'm update/upgrading and cleaning up my NetBSD boxes.
ntpmon broke. Python gave a backtrace rather than a simple error message.
File "/usr/local/lib/python3.13/site-packages/ntp/ntpc.py", line 41, in
_importado
return _dlo(ntpc_paths)
File "/usr/local/lib/python3.13/site-packages/ntp/
Richard Laager said:
> Are there platforms (still worth supporting) that have Python 2 but not
> Python 3 out of the box?
I think that's the key question.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://li
Thanks.
> It's not about "with" in the sense of what's on the system; it's about
> what Python version *their code* works with. Due to the large
> incompatibilities between Python 2 and Python 3, it takes serious work to
> update existing Python 2 code to work with Python 3. And such fixes
> o
1 - 100 of 1128 matches
Mail list logo
