On 12/14/20 8:14 PM, Hal Murray via devel wrote:
I think we should install such a file containing LIBDIR
on systems where/etc/ld.so.conf.d/ is a directory.
No, please don't, for many reasons. If you attempt this, you're going to
encounter a lot of pain points as you try to deal with exception
GitLab Abuse folks:
A user (bot?) named @GitLab-Abuse-Automation closed a bunch of
legitimate NTPsec merge requests:
https://gitlab.com/NTPsec/www/-/merge_requests/33
https://gitlab.com/NTPsec/www/-/merge_requests/42
https://gitlab.com/NTPsec/www/-/merge_requests/63
https://gitlab.com/NTPsec/n
Thanks. I added that to the GitLab ticket. Maybe that will help them get
to the bottom of it. No response from them yet.
On 12/16/20 5:38 PM, James Browning via devel wrote:
After looking at it a little more it appears that something
temporarily disconnected several forked projects and during t
I got a response from GitLab's (presumably first-level support) on the
ticket I filed earlier:
"I see you're being affected by our @GitLab-Abuse-Automation bot. This
could be related to Content Violation. I'm raising this internally and
we will get back to you soon."
The first part, at least
On 12/17/20 9:01 PM, Fred Wright via devel wrote:
I'm not sure that is recoverable by users directly. And the "if you
broke it, you fix it" rule ought to apply to the GitLab folks.
They're still working on this. I think they thought they had everything,
but they definitely don't. I've let the
On 1/20/21 4:24 PM, Hal Murray via devel wrote:
If you split the file it's a flag day for all users (no small matter when the
uservase is as conservative and risk-averse as ntpd's)
We should be able to write a script to do the splitting.
It's a concern even beyond risk-aversion.
My producti
On 3/14/21 11:25 PM, Hal Murray via devel wrote:
Can anybody give me a pointer to code that does this? Or steer me in the
right direction, or ...
There is a recursive tangle of struct needs function and function needs struct,
but the function only needs a pointer to the struct so I think that
On 3/15/21 2:06 PM, Richard Laager via devel wrote:
On 3/14/21 11:25 PM, Hal Murray via devel wrote:
Can anybody give me a pointer to code that does this? Or steer me in the
right direction, or ...
There is a recursive tangle of struct needs function and function
needs struct, but the
On 3/24/21 3:39 PM, Hal Murray via devel wrote:
Do we have a HOWTO for setting up ntpsync?
I also don't know what you mean by ntpsync.
Does it include turning off systemd-timesyncd?
NTPsec ships with etc/ntpd.service which has:
Conflicts=systemd-timesyncd.service
That Conflicts means ntpd.
In the course of looking at the fix (fc50a701fa) for CVE-2021-22212, I
found a couple of things that I think are worth mentioning...
The specific change is trivial, changing the starting point of the range
from 0x21 (!) to 0x24 ($). This avoids 0x23 (#). However, it differs
from the pre-bug v
On 6/20/21 2:31 AM, Achim Gratz via devel wrote:
Eric S. Raymond via devel writes:
My choice for a language to move to would be Go. Possibly one of you
can argue for a different choice, though if you agree that Go is a
suitable target I would find that information interesting.
Since the last r
On 6/20/21 4:45 PM, Richard Laager via devel wrote:
I get the impression that Go has a shallower learning curve (i.e. is
easier to get started with), which is good, but may unfairly prejudice
Go in quick Go-vs-Rust "bake off" comparisons.
err... may unfairly prejudice Rust
On 6/29/21 3:41 PM, Eric S. Raymond via devel wrote:
Well, first, the historical target for accuracy of WAN time service is
more than an order of magnitude higher than 1ms.
My two NTP servers are +- 0.1 ms and +- 0.2 ms as measured by the NTP
pool monitoring system across the Internet.
--
Ri
On 6/29/21 8:52 PM, Eric S. Raymond wrote:
Richard Laager via devel :
On 6/29/21 3:41 PM, Eric S. Raymond via devel wrote:
Well, first, the historical target for accuracy of WAN time service is
more than an order of magnitude higher than 1ms.
My two NTP servers are +- 0.1 ms and +- 0.2 ms as
On 7/5/21 8:38 AM, Eric S. Raymond via devel wrote:
There is a close-to-RFC to handle this area. "Interleave" is the buzzword. I
haven't studied it. The idea is to grab a transmit time stamp, then tweak the
protocol a bit so you can send that on the next packet.
Daniel discovered it was bro
On 11/5/21 1:43 AM, Hal Murray via devel wrote:
... How does waf decide where to put things?
https://waf.io/apidocs/tools/python.html#waflib.Tools.python.check_python_version
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
___
On 11/16/21 12:42 AM, 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 only ntpd.service has references to network...
ntp-wait.service already has:
Requisite=ntpd.service
After=ntpd.service
On 11/27/21 8:45 AM, Udo van den Heuvel wrote:
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.
That is a failu
On 12/28/21 3:35 PM, Hal Murray via devel wrote:
Is there any magic not-before date in the ntpsec environment?
I think we used to have the build date in the version string but that was
removed to make builds reproducable. I thought we added something in a
#define someplace with the idea that it
For clarity, the upcoming 22.04 LTS release has this fixed, as do the
currently-supported non-LTS releases. The ntpsec in 18.04 LTS does not
support NTS at all. So it's only 20.04 that is a problem.
I've been aware this is a problem, but literally nobody has complained
to me, so I haven't both
On 4/19/22 17:01, Hal Murray via devel wrote:
One is to update the nts cert documentation to say
that it doesn't do any checking on the certificate.
- Present the certificate in _file_ as our certificate.
+ Present the certificate (chain) in _file_ as our certificate.
+ +
+ Note that there
+1 to NOT making this a knob.
On 4/20/22 15:07, Matt Selsky via devel wrote:
Hi Hal,
If you're sufficiently happy with my code change, then you can click "approve" and
"merge" on https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1264
I would rather not add knobs unless someone asks for this t
On 4/21/22 03:17, Hal Murray via devel wrote:
There are 8 cases. I think I tested them all. If it will make you happy,
I'll test again, being careful to check all 8 cases.
8 cases? I thought it was one setting, which would be 2 cases.
Can you expand upon what you're actually proposing? Ideal
On 4/22/22 02:08, Hal Murray wrote:
+1 to NOT making this a knob.
Would you please say more.
It would be invisible unless you go looking for it.
Are you against unnecessary knobs in general?
Yes.
If I had pushed this code a
month or 3 ago when we weren't discussing a release or wildcards,
I looked at 1268. I split it into a bunch of pieces and merged a bunch
of it. That shrinks the diff, making it easier to follow. Further
comments are on the MR.
On 5/2/22 09:35, countkase--- via devel wrote:
On Thursday, April 21, 2022, 09:20:06 AM PDT, Matt Selsky
wrote:
Hi James,
I'm no
On 5/2/22 14:36, Hal Murray via devel wrote:
I think I've figured out why I think my knob is interesting.
For the web, there are zillions of clients, most non-technical. A client is
likely to connect to many servers, often new/different ones on different days.
It all has to just work, straigh
Maybe not so easy in practice, given the CT issues today:
https://www.reddit.com/r/sysadmin/comments/ugwkh2/all_of_the_sudden_seeing_chrome_error_err/
--
Richard
> On May 3, 2022, at 03:40, Richard Laager wrote:
>
> That seems like low-hanging fruit. We would have to ship an
> application-sp
On 5/9/22 02:38, Hal Murray via devel wrote:
Does anybody know how the initial time gets set on a Raspberry Pi -- before
ntpd gets called?
I believe you're looking for "fake-hwclock". It periodically saves the
time to a file (allegedly* /etc/fake-hwclock.data) and restores it on boot.
* My ho
On 12/21/22 17:26, 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?
I was asked to enable it in Debian, but I did not.
Note that my understanding was that "enable" meant "compile in the
support such that use
On 1/3/23 13:46, Gary E. Miller via devel wrote:
Yo folkert!
On Tue, 3 Jan 2023 08:58:40 +0100
folkert wrote:
Can I please send the patch via e-mail? I've been struggeling with
gitlab for an hour and whatever I do it keeps complaining that I'm not
allowed to push to the project (my own clone,
On 1/12/23 19:10, Gary E. Miller via devel wrote:
How does ntpd know what size time_t to use? And thus know the size of
shmTime? How do we know portably, preserving backwards and forwards
compatibility?
In hindsight, maybe shmTime should have started with a 1 char version
field,or magic field.
On 1/13/23 18:33, Gary E. Miller via devel wrote:
Yo All!
Looks like there are four cases to support with shmTime:
1: 64-bit time_t with 64-bit ints:
All known 64-bit distros (?)
Works after 2038
No change required.
2: 64-bit time_t with 32-bit ints:
All *BSD (?)
I reviewed all of these, am opposed to none, approved two, and merged
one. Details on the tickets. I'd especially like to hear from Gary on
the gpsd one.
--
Richard
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/dev
On 2023-08-04 20:35, Fred Wright via devel wrote:
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 think it's fine for a backport fix release like this.
That said, I did advocate for merging it back in
On 2023-08-07 14:34, Matthew Selsky wrote:
On Mon, Aug 07, 2023 at 02:14:40PM -0500, Richard Laager via devel wrote:
That said, I did advocate for merging it back in to master (as a no-op). But
I don't feel particularly strongly about that.
The code fix itself is already in master.
On 2023-08-07 15:13, Fred Wright via devel wrote:
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 bra
On 2023-09-04 17:38, James Browning via devel wrote:
On Sep 4, 2023 14:46, Matthew Selsky via devel wrote:
On Mon, Sep 04, 2023 at 02:25:46PM -0700, Gary E. Miller via devel
wrote:
> From RHEL:
>
> "The RHEL 8 AppStream Lifecycle Page puts the end date of RHEL 8's
> Pyt
On 2023-09-12 00:03, Hal Murray via devel wrote:
Maybe it's time to switch to Go?
The opportunity for that may have passed. There's a new ntpd-rs project
writing an NTP daemon in Rust:
https://github.com/pendulum-project/ntpd-rs
It's certainly not a full ntpd replacement yet (e.g. no local r
Is there any AppArmor involved?
e.g. does /etc/apparmor.d/usr.sbin.ntpd exist or are there apparmor
failure messages in dmesg?
--
Richard
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
On 2023-11-13 02:17, Hal Murray via devel wrote:
I'm looking into making our documentation consistent.
NIST and Wikipedia use SHA-1.
NIST is the authority on SHA, so I'd follow their naming.
--
Richard
___
devel mailing list
devel@ntpsec.org
https
On 2023-12-03 03:22, Hal Murray via devel wrote:
I'm working on devel-TODO-NTS. (mostly deleting things)
Currently, if a bad guy hacks or arm-twists a certificate authority, they can
sign a certificate that the bad guy can use for a MITM attack.
Yes, that's how the CA ecosystem works. That is
On 2024-04-11 14:39, Hal Murray via devel wrote:
If somebody feels like hacking, something like this should be fun.
The idea is to setup a ntpd server watching the servers you want to monitor.
(noselect on the server line does that)
The new code is a program that watches that server to see if t
On 2024-05-02 15:48, Hal Murray via devel wrote:
There are 2 new options for the config file:
nts port
extra port
They do the same thing. Pick one.
Why two options that do the same thing?
--
Richard
___
devel mailing list
devel@ntps
On 2024-05-02 22:20, Hal Murray via devel wrote:
I don't like adding a new top level (extra) to the config file syntax.
In general, I agree with you on that. I'd keep it under nts.
--
Richard
___
devel mailing list
devel@ntpsec.org
https://lists.ntp
There was some discussion on the gpsd-users list a few years ago about
setting the ublox into "stationary mode":
https://lists.gnu.org/archive/html/gpsd-users/2013-11/msg2.html
https://lists.gnu.org/archive/html/gpsd-users/2013-08/msg7.html
I'm not 100% sure, but I think I finally have th
On 11/12/2017 07:15 AM, Achim Gratz via devel wrote:
> It can also be horrible if you have a poor antenna placement and lots
> of multipath reception.
How does stationary mode make this worse? (I'm not disagreeing. I'm
looking to understand.)
> There's also the implication that you actually
> hav
On 11/30/2017 10:39 PM, MLewis via devel wrote:
> One enhancement I'm think of coding and proposing to the author of
> PPS-Client, is antenna length.
FYI: The ublox receivers have a parameter for antenna cable delay.
--
Richard
___
devel mailing list
d
[Replying to lots of different people, slightly out-of-order.]
On 12/05/2017 09:52 AM, Eric S. Raymond via devel wrote:
> I'm not clear why we care about the pip cases.
I agree. If this matters, it can always be addressed later.
On 12/05/2017 09:17 AM, Ian Bruene via devel wrote:
> Distro Instal
On 12/06/2017 12:36 AM, Gary E. Miller wrote:
> On Tue, 5 Dec 2017 23:57:37 -0600
> Richard Laager via devel wrote:
>> On 12/05/2017 09:52 AM, Eric S. Raymond via devel wrote:
>>> I'm not clear why we care about the pip cases.
>>
>> I agree. If this mat
On 12/07/2017 03:06 PM, Fred Wright via devel wrote:
> On Wed, 6 Dec 2017, Ian Bruene via devel wrote:
>
>> For installs the only remaining problem is that for unknown reasons it
>> sometimes doesn't follow the PREFIX when installing the python libs.
>
> There's nothing "unknown" about it.
Actua
On 12/07/2017 10:59 PM, Gary E. Miller wrote:
>> The default case is prefix=/usr/local, which (correct me if I'm wrong)
>> works without hacks.
>
> Sadly, recently broken.
NTPsec has wafhelpers/fix_python_config.py, which is the hack in question.
Have you tried the patch I posted to #414, which
On 12/08/2017 01:48 AM, Hal Murray via devel wrote:
> Richard Laager said:
>> NTPsec's `waf configure --destdir` seems broken. That should be fixed,
>> especially if helping packagers is a priority.
>
> --destdir work on install rather than configure.
> --prefix works on configure not install
It
On 12/08/2017 02:20 AM, Hal Murray wrote:
> I haven't done a lot of testing. waf install --destdir=foo didn't crash like
> it would if it tried to write to /usr/ and the printout all looked good.
Since I know destdir worked for me in the package build, I looked into
this again to figure out what
On 12/08/2017 02:20 AM, Hal Murray wrote:
>> Does the /usr/local/lib/python... directory exist?
> Yes.
What is your full sys.path?
$ python -c 'import sys; print sys.path'
--
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mail
On 12/07/2017 03:06 PM, Fred Wright via devel wrote:
> The underlying problem is essentially that
> there's no equivalent of ld.so.conf for Python
You can add paths (one per line) in a .pth file in:
/usr/lib/python${ver}/${x}-packages
where $x is normally "site", but "dist" on Debian.
--
Richar
On 12/08/2017 12:44 PM, Hal Murray wrote:
>
>> What is your full sys.path?
>> $ python -c 'import sys; print sys.path'
>
> [murray@hgm raw]$ printenv PYTHONPATH
> /usr/local/lib/python2.7/site-packages
> [murray@hgm raw]$ python -c 'import sys; print sys.path'
> ['', '/usr/local/lib/python2.7/s
I agree that your system does not have /usr/local in its sys.path by
default.
I think that's broken.
Here's the relevant RedHat bug:
https://bugzilla.redhat.com/show_bug.cgi?id=662034
It is closed with, "F27 will have this issue resolved.".
For existing systems, there are three solutions:
On 12/08/2017 09:31 PM, Gary E. Miller via devel wrote:
> Conversely, any plain '/waf install' by user/admin, from our source,
> should go in a place, that MUST require that location in to be in
> PYTHONPATH.
On 12/08/2017 10:04 PM, Gary E. Miller via devel wrote:
> IFF you installed with './waf
On 12/08/2017 09:20 PM, Gary E. Miller via devel wrote:
> By Debian rules, ulness you do some sort of over-ride, '.waf install'
> should never, ever, install into dist-packages.
You're still misunderstanding. Debian has just renamed "site-packages"
to "dist-packages". They are otherwise exactly th
On 12/09/2017 03:18 AM, Achim Gratz via devel wrote:
> There are at least three different way of installing _anything_ (let's
> leave the details of Python and the various distro conventions aside for
> the moment):
>
> 1. System-wide, distribution-blessed installation (aka packaging).
> 2. System
On 12/08/2017 11:33 PM, Gary E. Miller via devel wrote:
> On Fri, 8 Dec 2017 22:40:55 -0600
> Richard Laager wrote:
>
>> On 12/08/2017 09:20 PM, Gary E. Miller via devel wrote:
>>> By Debian rules, ulness you do some sort of over-ride, '.waf
>>> install' should never, ever, install into dist-pack
On 12/09/2017 09:14 PM, Hal Murray wrote:
> What are the alternatives? Are there any good ones?
This is one of those areas where it is easy to (legitimately) criticize,
but hard to find a correct answer.
I'm a (largely inactive) developer on Pidgin. Over the years, we've seen
a number of proposa
On 12/11/2017 07:45 PM, Gary E. Miller via devel wrote:> Binary distro
installs, unexpectedly to some, go into a temporary> location
(/var/tmp/XX?).
Not that it matters much, but just for clarification... For Debian, the
temp location is ./debian/tmp (where . is the source tree). For RedHat,
it oft
On 12/12/2017 07:12 PM, Sanjeev Gupta via devel wrote:
> As a start, as Richard has already done the work of packaging ntpsec for
> Debian, perhaps we could include his "patches" in HEAD?
No patching was necessary (for this issue). --prefix=/usr works fine.
--
Richard
___
On 12/13/2017 12:25 AM, Hal Murray via devel wrote:
> Is there a simple way to do a git pull when I have edits in progress?
Use `git stash`, which (as you put it) is the "better way" to "save them
off to the side".
git stash
git pull
# Choose *one*:
git stash apply
git stash pop
`git stash app
On 12/13/2017 06:23 PM, Hal Murray via devel wrote:
> If you are using apparmor, ntpd can't read the drift file at startup because
> it is still root while the drift file is user ntp.
There are a couple other possible fixes for this:
1) Fix the apparmor policy. That's what I've done. The downsid
On 12/14/2017 12:01 AM, Hal Murray wrote:
> Is it easy to hack the startup scripts to change the mode so root can read it?
Yes, that could be done. I'm not sure I like that as a solution. It
seems weird to have something that only works correctly when run through
the init system, and subtly misbeh
>From your email, it sounds like we now agree on nearly everything.
I think we agree on the following as a viable, and probably the best,
option:
In the `waf install` process, after the PYTHONDIR directory is created,
check sys.path. If PYTHONDIR is not in sys.path, do $SOMETHING.
It sounds like
On 12/15/2017 02:22 AM, Hal Murray via devel wrote:
> Now what happens if a developer does a site install. (Is that the right
> term?)
>
> The new libraries will get used by the system-installed executables.
This seems like the expected result to me. On my Ubuntu system,
/usr/local/lib/python2.
On 12/14/2017 09:24 PM, Hal Murray wrote:
> I think it would be better to do the check before installing anything. If we
> aren't going to automatically fix it, I think we should print an error
> message and bail.
The problem is, this has false positives. If
/usr/local/lib/pythonX.Y/site-packag
On 12/15/2017 03:05 AM, Hal Murray wrote:
> rlaa...@wiktel.com said:
>>> That sort of stuff used to be easy before systemd
>> It's still easy. Add this to ntpd.service:
>> ExecStartPre=-/bin/chmod -f 664 /var/lib/ntp/ntp.drift
>
> I think I tried something like that to setup the ldattch for the P
On 12/18/2017 08:40 PM, Gary E. Miller via devel wrote:
> On Sat, 09 Dec 2017 10:18:57 +0100
> Achim Gratz via devel wrote:
>> 1. System-wide, distribution-blessed installation (aka packaging).
>> 2. System-wide, local installation.
>> 3. User installation.
>
> Whoa! Hold up right there. waf ha
On 12/18/2017 09:10 PM, Gary E. Miller via devel wrote:
> On Fri, 8 Dec 2017 22:34:46 -0600
> Richard Laager wrote:
>> When you say PYTHONPATH, do you mean:
>>
>> 1) "a custom directory set in the environment variable PYTHONPATH"
>> or
>> 2) A directory that python searches.
>
> Hmm... I think th
On 12/19/2017 01:50 PM, Gary E. Miller via devel wrote:
> I'm confused. To me, if you use --prefix, or DESTDIR, then you are
> explicitly NOT doing a system install. A system install MUST go
> in /usr, per the FHS, and your DESTDIR is preventing that. So now
> you are a #3.
I, and probably Achi
On 12/19/2017 01:42 PM, Hal Murray via devel wrote:
> My notes in ntpd.c at ENABLE_EARLY_DROPROOT say it doesn't work with SHM or
> NetBSD. Can we fix the SHM stuff? I've long been scheming on making the
> ntpd side of SHM read-only but that won't be a quick fix.
> Richard: Have you tried earl
On 12/19/2017 02:38 PM, Gary E. Miller via devel wrote:
> #1 `./waf configure --prefix=/usr` is a system install.
> #3 `./waf configure --prefix=/home/...` is a user install.
>> Package builds are:
>> ./waf configure --prefix=/usr
>> ./waf install --destdir=some_tmp_path
> Yup, that is a #3.
On 12/19/2017 02:53 PM, Gary E. Miller via devel wrote:
> On Tue, 19 Dec 2017 00:26:47 -0600
> Richard Laager wrote:
>
>> On 12/18/2017 09:10 PM, Gary E. Miller via devel wrote:
>>> On Fri, 8 Dec 2017 22:34:46 -0600
>>> Richard Laager wrote:
When you say PYTHONPATH, do you mean:
On 12/19/2017 05:48 PM, Gary E. Miller via devel wrote:
> I never, ever, ever, considered PYTHONPATH == sys.path.
Do you agree that sys.path is the authoritative list of directories that
are actually searched at run-time, by the python interpreter?
--
Richard
signature.asc
Description: OpenPG
On 12/19/2017 06:30 PM, Gary E. Miller via devel wrote:
> On Tue, 19 Dec 2017 18:22:11 -0600
> Richard Laager wrote:
>
>> On 12/19/2017 05:48 PM, Gary E. Miller via devel wrote:
>>> I never, ever, ever, considered PYTHONPATH == sys.path.
>>
>> Do you agree that sys.path is the authoritative lis
On 12/19/2017 07:50 PM, Gary E. Miller via devel wrote:
I think we're on the same page.
> I) waf could install a file in /usr/local/etc to tell ntpsec Python
> programs where to look.
How does the utility know to look in /usr/local/etc? If we have to put
the PREFIX into the utility, this is a mo
On 12/19/2017 10:23 PM, Gary E. Miller via devel wrote:
>> F) .pth file in /usr/.../pythonX.Y/-packages
>
> Uh, no. I looked at this some more. That first ... can only be lib,
> lib32 or lib64. Waf can not write there, Python only looks there.
Agreed. We can either tell the user to write t
On 12/20/2017 01:58 PM, Gary E. Miller via devel wrote:
> When I use DESTDIR, I feel I am 'configuring'.
./waf configure --prefix=/usr
./waf install --destdir=debian/tmp
Note that destdir appears at install time, not configure time.
--
Richard
signature.asc
Description: OpenPGP digital signa
On 12/20/2017 05:00 PM, Gary E. Miller via devel wrote:
> Neither --prefix, nor DESTDIR
> affect the generated and installed files.
I haven't checked, but I'm willing to stipulate that PREFIX is not
*currently* being embedded in any files installed by NTPsec.
The proposed "option H" is a change w
Rather than debate hypotheticals further, I have submitted a merge
request to implement the "option H" idea being discussed:
https://gitlab.com/NTPsec/ntpsec/merge_requests/615
I'm looking for feedback on that particular merge request. Only the last
commit is particularly interesting, which addres
On 12/23/2017 07:33 PM, Fred Wright via devel wrote:
> On the latter point, first of all, I neglected to mention in my earlier
> post that it would make sense to limit the automatic .pth file to the
> default PYTHONDIR/PYTHONARCHDIR case.
That seems reasonable, and even further limits the PREFIX "
On 01/02/2018 03:31 PM, Hal Murray via devel wrote:
>> Why is this not automatic from 'waf config' ?
>
> Probably because nobody ever wrote the code.
I assumed the question was rhetorical and was to be interpreted as the
statement: That should come from 'waf config'.
> But I think it's buggy any
On 01/02/2018 04:12 PM, Hal Murray wrote:
> Does anybody actually run with a config file in /usr/local/etc/?
I don't know. I don't. I tend to build distro packages out of my stuff,
using /usr and /etc. Barring that, I'm either installing to /usr/local
temporarily and don't care that much, or I'm i
On 01/02/2018 04:36 PM, Eric S. Raymond via devel wrote:
> Hal Murray via devel :
>> Can anybody explain how this is "working"?
>
> If you read the droproot code, I think you will quickly achieve enlightenment.
Can you elaborate? In this case, from my understanding, Hal isn't
starting it as root,
On 01/03/2018 04:44 PM, Gary E. Miller via devel wrote:
>>> Rather than having me misread your code, can you put a plain
>>> summary here?
PYTHONDIR and PYTHONARCHDIR (whatever they are) are embedded into the
executables and loaded into sys.path at runtime. This is *in addition*
and *in priority to
On 01/04/2018 09:18 AM, Ian Bruene via devel wrote:
> For alternate fixes we have rlaager's (!615) fix. The tradeoffs I see are:
> bad: the entire concept is a hideous violation of good import
> practices and generally all that is right and proper
I'm not convinced it's actually bad form. Can
On 01/04/2018 12:54 PM, Gary E. Miller via devel wrote:
> functional tests are run on the code in many different locations.
This concern is valid. Can you provide examples of what sort of tests
are run?
For example, within the build tree is fine:
./waf check
Specifically, which commands are run
On 01/04/2018 04:55 PM, Gary E. Miller via devel wrote:
>> Ubuntu does.
> Then why do they include it in PATH, but not PYTHONPATH?
s/PYTHONPATH/sys.path/
It *is* in both PATH and sys.path.
$ echo $PATH
/home/rlaager/bin:/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
On 01/04/2018 08:39 PM, Gary E. Miller via devel wrote:
> Cool. So you are unaffected by the original issue. Since you do not
> have the issue, I assume you'd prefer that no unneeded kludges be added
> when you build NTPsec. So why do you care how the issue gets solved?
I don't think being pers
On 01/04/2018 08:51 PM, Gary E. Miller via devel wrote:
> Sure, my MR is trivial: leave as is, except revert the patch that
> removed the PYTHONPATH guidance to the builder. Ain't borke, don't
> fix it.
I think one of the few things we agree on here is that the current
behavior in master is broke
On 01/04/2018 09:29 PM, Gary E. Miller via devel wrote:
> I must admit to being lost as to how this gets all mixed up in the
> PYTHONPATH confusion.
Because /usr/local is not in the default sys.path on some distros,
wafhelpers/fix_python_config.py was created to try to fix that. It then
creates a
On 01/04/2018 10:05 PM, Gary E. Miller via devel wrote:
>> Your proposal was "my MR is trivial: leave as is, except revert the
>> patch that removed the PYTHONPATH guidance to the builder." Your
>> proposal to leave things as is does not fix your #414. I asked if you
>> wanted to amend your proposa
On 01/04/2018 10:05 PM, Gary E. Miller via devel wrote:
> Any proposal that embeds paths in build products is broken. I already
> described in grewat detail several of the failure mechanisms and will
> not repeat myself.
The embedding code in !615 only ever adds to sys.path. It doesn't remove
any
On 01/04/2018 10:44 PM, Gary E. Miller via devel wrote:
> I just want it the way it was, the way that worked.
Can you submit an actual merge request for review?
--
Richard
signature.asc
Description: OpenPGP digital signature
___
devel mailing list
On 01/05/2018 01:25 PM, Achim Gratz via devel wrote:
> I think waf cannot currently cope with a different prefix for
> Python and the rest of the installation, but it should maybe have a way
> to split that on request of the user
waf has options for that, and they work:
./waf configure --prefix=fo
I'm okay with what's in master now.
On 01/05/2018 09:28 AM, Ian Bruene via devel wrote:
> Embedding the paths directly into the python programs works great, in
> all situations. Right up until it doesn't. One problem is that the
> Gentoo installation workflow is based around moving things around
>
101 - 200 of 423 matches
Mail list logo
