On Sun, 7 Apr 2019, Hal Murray wrote:
Does a simple void cast work? E.g.:
(void) strerror_r(...)
I haven't found the magic using that approach.
../../ntpd/nts.c:214:16: warning: ignoring return value of ???strerror_r???,
declared with attribute warn_unused_result [-Wunused-result]
On Sun, 30 Jun 2019, Mark Atwood wrote:
The NTPsec Project is pleased to announce the tagging of version 1.1.5
I guess "tagging" is a good description given that the tarball doesn't
seem to have been published. :-)
Fred Wright
___
devel mailing
On Mon, 22 Jul 2019, Gary E. Miller via devel wrote:
No one has a solid answer to the NTS ALPN issue?
"at some time the NTPSEC server would return "\x07ntske/1" instead of
just "ntske/1"."
Doesn't ring any BELs for me. :-)
All kidding aside, it's probably not a coincidence that \x07 is the
On Fri, 16 Aug 2019, Eric S. Raymond via devel wrote:
Sanjeev Gupta :
sizeof(double) seems to be 8 bytes. The 8192 * No of Secs per week
overflows this.
Huh. If "long double" isn't 16 bytes, we're foing to have a problem.
There's no guarantee that long double differs from double. Anythi
On Wed, 21 Aug 2019, Hal Murray via devel wrote:
ntpd/refclock_gpsd.c has:
#define _XOPEN_SOURCE 600
I see the following warning:
NetBSD:
../../ntpd/refclock_gpsd.c:2118:6: warning: implicit declaration of function
'strlcpy' [-Wimplicit-function-declaration]
FreeBSD:
../../ntpd/refclock_gps
On Thu, 29 Aug 2019, Gary E. Miller via devel wrote:
Warnings on OSX:
[ 73/131] Compiling libntp/ntp_calendar.c
../../ntpd/ntp_control.c:2612:27: warning: format specifies type 'unsigned
short' but the argument has type 'unsigned int' [-Wformat]
socktoa(rmt_addr),
On Fri, 30 Aug 2019, Fred Wright via devel wrote:
On Thu, 29 Aug 2019, Gary E. Miller via devel wrote:
Warnings on OSX:
[ 73/131] Compiling libntp/ntp_calendar.c
../../ntpd/ntp_control.c:2612:27: warning: format specifies type 'unsigned
short' but the argument has type &#x
On Sat, 31 Aug 2019, Matthew Selsky wrote:
On Fri, Aug 30, 2019 at 08:01:59PM -0700, Fred Wright via devel wrote:
On Thu, 29 Aug 2019, Gary E. Miller via devel wrote:
Warnings on OSX:
[ 73/131] Compiling libntp/ntp_calendar.c
../../ntpd/ntp_control.c:2612:27: warning: format specifies
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 d
On Tue, 16 Jun 2020, Mike Simpson via devel wrote:
There is libressl from the OpenBSD team
https://www.libressl.org/
It was forked from openssl in 2014
The last time I tried it, libaes_siv wouldn't build with LibreSSL, so that
would need to be fixed. Unless LibreSSL provides an adequate A
On Sun, 30 Aug 2020, Hal Murray via devel wrote:
Is there any way to do something like
#define FOO $FOO+1
I want to keep track of the number of times a macro has been called. That
seems like something that would happen often enough that there would be a
standard recipe but I haven't seen it.
On Thu, 3 Sep 2020, Hal Murray wrote:
I don't see how to use your master/entry macros to solve my problem.
I didn't mean for those to be usable as is, but just as an illustration of
the concept. YMMV.
The current code has only one table but it needs a symbol for the offset of
each slot
On Wed, 2 Sep 2020, Hal Murray via devel wrote:
As of 1.1.9, NTPsec doesn't build "normally" on Debian 7...
Debian 7 is pretty old. Support ended May 2018
Do we want to support versions of distros that the vendor doesn't support any
more? My vote would be no.
There are sometimes signifi
On Wed, 14 Oct 2020, Hal Murray via devel wrote:
I'm setting up a new Debian system. I'm far from a Debian wizard, but I'm not
a total newbie either.
I have a ntp.pth setup, so ntpq finds the python libraries.
[...]
File "/usr/local/lib/python3/dist-packages/ntp/ntpc.py", line 49, in _dlo
On Sat, 12 Dec 2020, James Browning via devel wrote:
On Sat, Dec 12, 2020, at 6:41 PM Gary E. Miller via devel
wrote:
Yo James!
On Sat, 12 Dec 2020 18:35:13 -0800
James Browning via devel wrote:
The following patch clears it up on the machine I bisected on.
No, that uses the installed
On Thu, 17 Dec 2020, Eric S. Raymond wrote:
James Browning via devel :
The ntpsec forks belonging to rlaager, selsky, and ianbreune are still
detached. A quick check shows that there are no forks. The page I looked at
claimed that such detached repositories cannot be reattached. TLDR there is
On Sun, 14 Mar 2021, Hal Murray via devel wrote:
[Context is cleaning up ntp_control]
This will probably be simple after somebody gives me a good example and/or
explains things to me.
I want to put a (pointer to a) function in a field of a struct.
The type of that function includes a pointer
On Fri, 27 Aug 2021, MLewis via devel wrote:
"
A new set of patches submitted to the Linux kernel mailing list summarises
the progress of the project to enable Rust to be used alongside C for
implementing the Linux kernel.
[...]
"
There's a YouTube video of a talk on this subject. It's
On Tue, 15 Feb 2022, Hal Murray via devel wrote:
matthew.sel...@twosigma.com said:
Are we worried about the speed of the build, lack of build support on
particular platforms, or something else?
I'm not particularly concerned about the speed of a build. As far as I know,
nobody has complain
On Thu, 8 Dec 2022, James Browning via devel wrote:
Selsky broke the build[1] back in May 2020 when switching the
python_scripts variable in /wscript to a set when Python 2.6
does not support sets. Given the lack of complaints, I suspect
no one uses 2.6 anymore, which can be dropped.
Python
On Thu, 15 Dec 2022, Matthew Selsky via devel wrote:
On Wed, Dec 14, 2022 at 03:39:29PM -0800, James Browning via devel wrote:
'Do not apply transform to symbolic link targets' [1] Which I
got from googling 'gnu tar transform' IIRC. It is also a
gnuism, but I do not see a portable transform t
On Sat, 17 Dec 2022, Hal Murray via devel wrote:
I just pushed code to save 10 NTS keys used to make cookies.
The commit message for that is lacking the blank line after the summary
line. This means that some git tools treat the entire commit message as
the summary, creating obnoxiously l
On Mon, 19 Dec 2022, James Browning via devel wrote:
On 12/18/2022 6:02 PM PST Hal Murray via devel wrote:
The commit message for that is lacking the blank line after the summary
line. This means that some git tools treat the entire commit message as the
summary, creating obnoxiously long li
On Wed, 21 Dec 2022, Matt Selsky via devel wrote:
This is only a 2 minute delay, if I converted all timestamps to UTC correctly.
My last post was delayed 11 minutes, which is longer than it should be,
but not awful.
I did find that a spammer was abusing our Mailman instance's web
interfa
The build currently fails when building againts OpenSSL 1.1. MacPorts is
currently building it that way since the last release failed to build
against OpenSSL 3 (due to the attic problem), though it should be able to
move to OpenSSL 3 on the next release. So it's not actually an issue for
On Wed, 21 Dec 2022, Hal Murray via devel wrote:
Does anybody use it?
Do any distros build with it enabled?
Should we add an "#warn untested" to the code?
If some systems need leap-smeared time to get around bugs in their code,
they should be free to implement an *internal* leap-smeared tim
On Wed, 21 Dec 2022, Hal Murray wrote:
but if breaking OpenSSL 1.1 was unintentional, then it needs to be fixed
I'm not aware of any intententional breakage. I'm pretty sure we would have
done it at configure time.
I don't think *unintentional* breakage would be done at configure time.
On Wed, 21 Dec 2022, Hal Murray wrote:
f...@fwright.net said:
It's 1.1.1s, which is the latest 1.1. I don'think there's anything
nonstandard besides using versioned install locations so that multiple
versions can be installed side-by-side.
I poked around some more. I have it building and r
On Wed, 21 Dec 2022, Fred Wright via devel wrote:
On Wed, 21 Dec 2022, Hal Murray wrote:
I guess if you don't see the issue I'll have to look more closely; I
thought
you might "just know" the problem.
Does git head work on 3.0?
Yes. I think it gets confused when
On Wed, 21 Dec 2022, Hal Murray via devel wrote:
Google says:
https://developers.google.com/time/smear
We encourage anyone smearing leap seconds to use a 24-hour linear smear from
noon to noon UTC.
There were earlier versions which did sine rather than linear.
Hmm. I don't recall any non
On Tue, 3 Jan 2023, folkert via devel wrote:
Lost me. What about sntp do you want to put on gitlab?
Oh, reading these in reverse order. I think you are offering to
add this as a Merge Request on GitLab? Yes, that would be good.
Can I please send the patch via e-mail? I've been struggeli
On Tue, 3 Jan 2023, folkert wrote:
Lost me. What about sntp do you want to put on gitlab?
Oh, reading these in reverse order. I think you are offering to
add this as a Merge Request on GitLab? Yes, that would be good.
Can I please send the patch via e-mail? I've been struggeling with
gi
On Mon, 2 Jan 2023, folkert via devel wrote:
[...]
It makes it include the delay in the json output.
Note that the delay is not the full story in the time uncertainty. A
long-standing ntpdig bug is that it fails to include the dispersion. The
delay gives the uncertainty in the server->cl
On Sun, 23 Jul 2023, Hal Murray via devel wrote:
git log on a fresh clone shows things like this:
Author: Hal Murray
Date: Tue Jul 4 15:16:47 2023 -0700
Squash warnings about not handled enumeration
I haven't used that email in ages. My profile has been updated. Mail from
gitlab goe
On Thu, 3 Aug 2023, Hal Murray via devel wrote:
Should that also go to users@ and devel@?
What fraction of people on users or devel are also on announce?
And for that matter, what exactly is 1.2.2a, given that there's no git tag
for that version?
Fred Wright
_
On Fri, 4 Aug 2023, Matthew Selsky wrote:
On Fri, Aug 04, 2023 at 01:47:29PM -0700, Fred Wright via devel wrote:
And for that matter, what exactly is 1.2.2a, given that there's no git tag
for that version?
1.2.2a is 1.2.2 + the 2 line patch to avoid the crash. We'll releas
On Fri, 4 Aug 2023, Fred Wright via devel wrote:
On Fri, 4 Aug 2023, Matthew Selsky wrote:
On Fri, Aug 04, 2023 at 01:47:29PM -0700, Fred Wright via devel wrote:
And for that matter, what exactly is 1.2.2a, given that there's no git tag
for that version?
1.2.2a is 1.2.2 + the 2 line
On Fri, 4 Aug 2023, James Browning via devel wrote:
On 08/04/2023 6:35 PM PDT Fred Wright via devel wrote:
:::snip:::
I notice that the two commits for that don't seem to be in any branch.
Having commits only "owned" by a tag and not a branch seems fragile.
I do
In general, it's a good idea to read an actual book on git, rather than
trying to understand it purely through manpages. The one I used (almost a
decade ago) is this one:
https://www.amazon.com/gp/product/1449316387/
It doesn't tell you everything you might want to know, but it cov
On Sat, 18 Nov 2023, Fred Wright via devel wrote:
[...]
With or without this problem, it's a bad idea to combine multiple
unrelated changes into a single MR anyway. It's best to stick to one
topic per branch, both locally and in any MRs derived from such
branches.
I neglected t
On Wed, 6 Dec 2023, Matthew Selsky via devel wrote:
Sounds good. I'll aim to release ~15-Dec-2023.
Fortunately this hasn't happened yet. :-)
The main issue I've found is that the "struct var" in ntp_control.c, is
relying on anonymous unions, which are a relatively new language feature.
Th
it would be heavy-handed
for the normal build procedure. Or even having CI tests both ways might
be useful, to distiguish between errors and warnings. Though if CI tests
had the ability to report error versus warning results, that would be
unnecessary.
On Mon, 18 Dec 2023, Matthew Selsky w
On Mon, 18 Dec 2023, Fred Wright wrote:
On Mon, 18 Dec 2023, Matthew Selsky wrote:
On Sun, Dec 17, 2023 at 08:17:23PM -0800, Fred Wright via devel wrote:
There are also a bunch of warnings with some compilers, which might be
worth
looking at. They're often fairly easy to fix, and some
On Mon, 18 Dec 2023, Hal Murray via devel wrote:
James said:
It sounds like a race condition in our wscript files or waf. How willing are
you to sink time into this, I think it's a losing proposition.
I've got a --jobs=1 in my script. That was added to make sure the printout
was easy to rea
I found one build error that's a regression - in OpenBSD 5.6. It's
"'CMAC_CTX' undeclared" in authreadkeys.c, which is due to the new
conditional around the inclusion of . Some other sources
include this unconditionally, and macencrypt.c has it in an if/else
construct. The else case there
On Thu, 21 Dec 2023, Fred Wright via devel wrote:
I found one build error that's a regression - in OpenBSD 5.6. It's
"'CMAC_CTX' undeclared" in authreadkeys.c, which is due to the new
conditional around the inclusion of . Some other sources
include this unc
On Thu, 21 Dec 2023, Hal Murray wrote:
Let's put that stuff on the back burner until the release is out.
Agreed for OpenBSD per se, though it might be worth trying to determine
whether the apparent fencepost error with OPENSSL_VERSION_NUMBER is really
OpenBSD-specific, or a more general pr
Commit 07231d10e2 to add cipher-find also added exp-timing.c to the build
list but didn't actually add a source for it. Thus the attic build fails.
It probably makes sense to fix this before the release since it's a
regression and also doesn't affect any normally installed components, and
On Mon, 25 Dec 2023, Fred Wright via devel wrote:
Commit 07231d10e2 to add cipher-find also added exp-timing.c to the build
list but didn't actually add a source for it. Thus the attic build fails.
It probably makes sense to fix this before the release since it's a
regressio
On Sat, 30 Dec 2023, Hal Murray via devel wrote:
Thanks.
and thanks to all who contributed and tested.
For some reason the antecedent to this message wasn't sent to the list,
though I'd noticed the release by checking the repo.
There are a couple of minor issues that I should have notic
On Wed, 3 Jan 2024, Matthew Selsky wrote:
On Tue, Jan 02, 2024 at 07:21:39PM -0800, Fred Wright via devel wrote:
There are a couple of minor issues that I should have noticed in the RC but
didn't:
1) The 1.2.2a entry is missing from NEWS. This is presumably because of the
way the
On Tue, 2 Jan 2024, Hal Murray via devel wrote:
Fred Wright said:
[context is my reply to the released message.]
For some reason the antecedent to this message wasn't sent to the list,
though I'd noticed the release by checking the repo.
My copy was sent to:
Subject: NTPsec 1.2.3 released
On Wed, 3 Jan 2024, Matthew Selsky wrote:
On Tue, Jan 02, 2024 at 08:52:53PM -0800, Fred Wright via devel wrote:
It should, though if the timestamps get updated in the process it would
trade bad name ordering for bad timestamp ordering. The ideal thing would
be to fix the names but keep the
On Thu, 2 May 2024, Hal Murray via devel wrote:
Note that for AT&T, the normal case of an NTP client goes through NAT so
NTP isn't using port 123 and doesn't get blocked.
Many, if not most, NAT implementations avoid remapping "privileged" client
ports, on the theory that specific port numbe
On Fri, 21 Jun 2024, Hal Murray via devel wrote:
Does anybody other than me run/test on NetBSD?
Ocasionally. I have a NetBSD 6.1.5 VM.
The test-all part of option-tester gets the following error.
Why only in option-tester?
ntp_stdlib includes signal.h
Do we have to do some magic to ma
On Tue, 25 Jun 2024, Hal Murray via devel wrote:
$ grep rtems wscript */wscript wafhelpers/*
wscript:if ctx.options.enable_rtems_trace:
wscript:ctx.find_program("rtems-tld", var="BIN_RTEMS_TLD",
wscript: path_list=[ctx.options.rtems_trace_path,
wscript:# Bor
On Sat, 7 Sep 2024, Hal Murray via devel wrote:
Does #ifdef work on functions? I thought not, but the old code looks like
its doing that.
It only works when the apparent functions are macros. The preprocessor
knows nothing about functions.
On Sat, 7 Sep 2024, Hal Murray via devel wrote:
On Wed, 11 Sep 2024, Hal Murray via devel wrote:
I'm trying to cleanup the tangle in ntp_control.c that generates warnings.
They may be actual bugs. The problem is that the man page says long while
the actual size may be 32 or 64 on 32 bit Linux systems.
If I knew the size, the fix would be
On Fri, 25 Aug 2017, Daniele Nicolodi via devel wrote:
> this https://www.ntpsec.org/supported-platforms.html says that MacOS X
> is an actively maintained platform, however, NTPsec current git master
> requires clock_settime() and (ad far as I know) this POSIX function is
> not implemented on Ma
On Sat, 26 Aug 2017, Eric S. Raymond via devel wrote:
> There have been inquiries from Daniele Nicolodi and Fred Wright about
> Mac OS X support.
Actually, mine wasn't an inquiry, it was an answer. :-)
> Mark Atwood, who's our strategy/product-management/external-relations
> specialist, may ove
On Sat, 26 Aug 2017, Hal Murray via devel wrote:
> [ 63/113] Compiling libntp/msyslog.c
> In file included from /usr/include/python2.7/pyconfig.h:6:0,
> from /usr/include/python2.7/Python.h:8,
> from ../../libntp/pymodule.c:7:
> /usr/include/python2.7/pyconfig-64
On Thu, 31 Aug 2017, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel :
> > I just tried to build ntpsec for the first time in weeks. Not good.
>
> Were you formerly getting these?
>
> ntp_parser.tab.c: In function ‘yytnamerr’:
> ntp_parser.tab.c:1329:21: warning: conversion to ‘long
On Fri, 1 Sep 2017, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel :
> > Yo Eric!
> >
> > On Thu, 31 Aug 2017 23:35:03 -0400
> > "Eric S. Raymond via devel" wrote:
> >
> > > > Expected 3486372600 Was 104913720
> >
> > Sure looks like integer overflow.
> >
> > > Something about the ex
On Wed, 13 Sep 2017, Hal Murray via devel wrote:
> I think the whole doubletime_t was a wild goose chase.
>
> The claimed reason was precision. A double has 53 bits. We are interrested
> in adjustments, not absolute values. If we are taking a huge adjustment (31
> bits), that still leaves 20 b
On Thu, 14 Sep 2017, Eric S. Raymond wrote:
> So, did I make an ignorant mistake? Can this fix be rescued? Is
> someone else better equipped than me for the rescue? (Translation:
> I'd really love to dump this mess on Fred or Gary.)
The point I was trying to make is that C doesn't promise tha
On Thu, 14 Sep 2017, Hal Murray via devel wrote:
> > All the fuss over long doubles has distracted folks from a more legitimate
> > issue with NetBSD 6.1.5, which is that python-config returns a nonworking
> > build setup for the C extension. But a workaround should be possible, and
> > it's onl
On Thu, 14 Sep 2017, Hal Murray wrote:
> > The basic problem is that python2.7-config --ldflags includes "-lpython2.7"
> > but no "-L" to say where to find it. On most platforms, a suitable "-L" is
> > included.
>
> I don't know anything about that area, but your "most platforms" seems
> optimis
On Fri, 15 Sep 2017, Fred Wright via devel wrote:
> On Thu, 14 Sep 2017, Hal Murray wrote:
>
> > > The basic problem is that python2.7-config --ldflags includes
> > > "-lpython2.7"
> > > but no "-L" to say where to find it. On most platforms
On Sun, 24 Sep 2017, Eric S. Raymond via devel wrote:
> Achim Gratz via devel :
> > Eric S. Raymond via devel writes:
> > > Now that iburst has been fixed - and Achim reports seeing this problem
> > > with iburst off - this pretty much has to be an issue deeper in the
> > > protocol machine. (I g
On Mon, 25 Sep 2017, Hal Murray via devel wrote:
> Are there any systems where ntpsec is known to work and require cross
> compiling?
I don't think a full build would work as a cross-compile, because one has
to jump through extra hoops to make cross-compiling Python extensions
work. Cross-compi
On Mon, 25 Sep 2017, Achim Gratz via devel wrote:
> Fred Wright via devel writes:
>
> > Can the failure rate be increased by changing the governor settings to
> > make the server slower? On the Pi that would significantly worsen the
> > time accuracy, but for the purposes
On Mon, 25 Sep 2017, Achim Gratz via devel wrote:
> Fred Wright via devel writes:
> > I get a kick out of you guys fussing over "thermal stability" when the
> > largest source of time error is the interrupt latency in timing the PPS
> > signal.
>
> The me
On Mon, 25 Sep 2017, Gary E. Miller via devel wrote:
> On Mon, 25 Sep 2017 16:55:30 -0700 (PDT)
> Fred Wright via devel wrote:
>
> > PPS(2) is the counter-capture PPS source, and is the primary timing
> > reference.
>
> Can you explain a bit more about this source?
I finally have the fixes I've been working on related to the Python
library setup ready for publication. The important issues were:
1) Waf misuses get_python_lib() in a way that often gets the wrong result,
with the effect of installing the libraries in a location where Python
doesn't look for t
On Mon, 25 Sep 2017, Gary E. Miller via devel wrote:
> On Mon, 25 Sep 2017 20:26:44 -0700 (PDT)
> Fred Wright via devel wrote:
>
> > 1) Waf misuses get_python_lib() in a way that often gets the wrong
> > result, with the effect of installing the libraries in a location
>
On Tue, 26 Sep 2017, Eric S. Raymond wrote:
> I've restored that magic link.
>
> It fell to ab attempt to stop creating a now unneeded magic link in the
> source part of the tree. I won't try to re-fix that before release.
That code *used to* create magic links in the source tree, but I changed
On Tue, 26 Sep 2017, Eric S. Raymond via devel wrote:
> Hal Murray :
> > The permissions on the stuff in ntpclients had the execute bit removed so
> > local testing doesn't work any more. I assume install fixes that since you
> > reported that ntpq worked.
> >
> > In particular, tests/options-te
On Tue, 26 Sep 2017, Eric S. Raymond wrote:
> Fred Wright via devel :
> > > Plus these are most likely too late for 1.0. We are in the final
> > > testing phases now.
> >
> > I think requiring users to set PYTHONPATH to run the tools should be
> > cons
Resending with the correct subject.
On Tue, 26 Sep 2017, Eric S. Raymond wrote:
> Fred Wright via devel :
> > > Plus these are most likely too late for 1.0. We are in the final
> > > testing phases now.
> >
> > I think requiring users to set PYTHONPATH to run t
On Tue, 26 Sep 2017, Eric S. Raymond via devel wrote:
> Ian Bruene via devel :
> >
> > The python 3 build appears to work. However it has a unicode bug in ntpq
> > (but not ntpmon! Yay consistency!), and I can not say that I *trust* any of
> > it.
> >
> > This is partially my fault, as I failed to
On Tue, 26 Sep 2017, Eric S. Raymond wrote:
> Fred Wright via devel :
> > > Not Gentoo, the FHS. And the package I am using is git head.
> >
> > The point is that the portable way to determine where to install the
> > libraries is to ask Python via the get_pytho
On Tue, 26 Sep 2017, Eric S. Raymond wrote:
> Fred Wright via devel :
> > BTW, all the tests fail on FreeBSD, due to an undefined reference in
> > jigs.py.
>
> Huh? If so, why has this not shown up in the results from the FreeBSD
> buildbot.
I don't know, but w
On Tue, 26 Sep 2017, Hal Murray via devel wrote:
> devel@ntpsec.org said:
> >> BTW, all the tests fail on FreeBSD, due to an undefined
> >> reference in jigs.py.
> > Huh? If so, why has this not shown up in the results from the FreeBSD
> > buildbot.
>
> It works on my FreeBSD setup.
If that's als
On Tue, 26 Sep 2017, Hal Murray wrote:
> devel@ntpsec.org said:
> > If that's also FreeBSD 10.3 and Python 2.7.13, then it must be something
> > weird in my install, and nothing to worry about in general.
>
> I've tested 10.3 and 11.0 on 64 bit Intel, 11.0 on 32 bit Intel, and 11.0 on
> ARM (Pi, a
On Tue, 26 Sep 2017, Ian Bruene via devel wrote:
> On 09/26/2017 05:02 PM, Eric S. Raymond via devel wrote:
> > Huh? If so, why has this not shown up in the results from the FreeBSD
> > buildbot.
>
> Two reasons:
>
> 1. python tests still not run by the build script
Ah, yes. Two of the tests we
On Tue, 26 Sep 2017, Eric S. Raymond wrote:
> Fred Wright via devel :
>
> > BTW, I have a tool that lists a few things including the library paths for
> > every version of Python it can find on the system. I can submit it to
> > devel/ if you like.
>
> Please d
On Wed, 27 Sep 2017, Eric S. Raymond via devel wrote:
> I've pushed a fix for Fred Wright's FixConfig class that seems to
> solve the problem of incorrect Python library locations.
>
> I tested it with no --prefix option and with --prefix=/usr,
> using install --destdir=/tmp/ntp.
>
> Gary, please
On Wed, 27 Sep 2017, Fred Wright wrote:
> On Wed, 27 Sep 2017, Eric S. Raymond via devel wrote:
>
> > I've pushed a fix for Fred Wright's FixConfig class that seems to
> > solve the problem of incorrect Python library locations.
> >
> > I tested it with no --prefix option and with --prefix=/usr,
>
On Wed, 27 Sep 2017, Eric S. Raymond wrote:
> Fred Wright via devel :
> >
> > On Wed, 27 Sep 2017, Eric S. Raymond via devel wrote:
> >
> > > I've pushed a fix for Fred Wright's FixConfig class that seems to
> > > solve the problem of incorrect
On Wed, 27 Sep 2017, Eric S. Raymond wrote:
> Fred Wright via devel :
> > FYI, I just took a look at sys.path on the three Linuces I have here
> > (Ubuntu, CentOS, and Fedora), and none of them has a single entry with
> > "local" as part of the path.
>
> I se
On Wed, 27 Sep 2017, Gary E. Miller via devel wrote:
>
> What we see that pip does, is edit the sys.path to include the
> location an egg is installed. That looks to me like a method
> to go forward with.
That sounds plausible, but we need to figure out how it does that. It's
not just about "ed
On Wed, 27 Sep 2017, Gary E. Miller via devel wrote:
> Fred Wright via devel wrote:
> It only matters
> > for Linux, since get_python_lib() returns FHS-compliant results on
> > *BSD, and on OSX the paths are so completely different that FHS
> > doesn't apply.
&g
On Wed, 27 Sep 2017, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel :
> > What we see that pip does, is edit the sys.path to include the
> > location an egg is installed. That looks to me like a method
> > to go forward with.
>
> It looks to me like a fscking disaster, introducing ye
will require much more than just
> changes to get_python_lib().
Agreed.
On Thu, 28 Sep 2017, Gary E. Miller via devel wrote:
> On Wed, 27 Sep 2017 19:02:23 -0700 (PDT)
> Fred Wright via devel wrote:
>
> > One of the ways to do #1 is to use the path returned by
> > get_pyth
On Sun, 1 Oct 2017, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel :
> > How do you plan that a local NTPsec install from source does not
> > overwite an NTPsec install from the native OS repositories?
>
> That now will never happen if the /usr/local/lb/python-X.Y directory exists;
>
On Sun, 1 Oct 2017, Eric S. Raymond wrote:
> Fred Wright via devel :
> > On Sun, 1 Oct 2017, Eric S. Raymond via devel wrote:
> > > Gary E. Miller via devel :
> > > > How do you plan that a local NTPsec install from source does not
> > > > ove
On Fri, 6 Oct 2017, Eric S. Raymond via devel wrote:
> Fred Wright writes:
> >Sorry for the lateness, but I realized that the current code still has a
> >bug (as well as a couple of deficiencies of a more-or-less cosmetic
> >nature). It's currently checking sys.path in the *running* Python, but i
On Thu, 5 Oct 2017, Hal Murray wrote:
> >> Warnings are easily lost in the noise. So either create the
> >> directory or treat it as an error and bail.
>
> > There are two issues with just "creating the directory":
> > 1) There's no guarantee that Python will actually use it.
> > 2) Creating the
On Sat, 7 Oct 2017, Hal Murray via devel wrote:
> If I have PYTHONPATH defined as /usr/local/lib/python2.7/site-packages
> Then the python libs get installed in /usr/local/lib/...
> If I unset PYTHONPATH, they get installed to /usr/lib/...
Doh! (on Eric's behalf) That would be an unfortunate pr
On Sat, 7 Oct 2017, Eric S. Raymond via devel wrote:
> Hal Murray via devel :
> > waf configure prints out:
> > PREFIX: /usr/local
> >
> > Should it also printout where it will install the python libraries?
>
> Good idea. I'd take that patch.
It's already there. Look
1 - 100 of 146 matches
Mail list logo
