Re: Install tangle

> Assuming this is a newly-installed system, /usr/local/lib/python2.7/ > dist-packages does not exist. Since it does not exist, it does not show up > in sys.path. Thanks. That's the example I was looking for. There is another example based on that which is when the user doesn't actually

Re: Install tangle

Thanks. > 1) Does configure bail if installing the python libs might not work? No. > I think #1 always has to be no. Otherwise, you'll break tons of working > setups, including but not limited to package builds. Could you please say more. I'm assuming that PYTHONPATH or xxx.pth would fix

Re: Install tangle

Gary said. > Yup. Do we know if this can fail silently? I tried it. It's not silent. Waf: Leaving directory `/home/murray/ntpsec/play/hgm/main' Build failed Traceback (most recent call last): File "/home/murray/ntpsec/play/.waf-1.9.14-d7f6128a2aa20a656027b134f0b4f4a6/ waflib/Task.py", line

Re: Install tangle

>> Does configure bail if installing the python libs in >> /usr/local/ isn't going to work? Poor choice of words on my part. "going to work" is ambiguous. One possibility is that the install won't work, maybe because a directory doesn't exist. But it should be able to create directories so

Install tangle

What is the current status? Does configure bail if installing the python libs in /usr/local/ isn't going to work? Do we have a good writeup for the PYTHONPATH and/or .pth solutions? -- These are my opinions. I hate spam. ___ devel mailing list

Re: Crypto, passwords

>> When I use ntpq from Classic, I'm never prompted for a password. I'm not >> sure if it's reading the key from /etc/ntp.keys on my behalf or not. >> Are you modifying things, or just looking? >> For example, ntpq -p doesn't require a password. > I only run ntpq -p and other read-only

Re: Version strings

> asciidoc shows a manversion in the bottom left, but asciidoctor has dropped > this attribute. > asciidoctor seems to be the future[0], so it this worth it? I think so. I assume we can work out some way to do it and/or asciidoctor will add support for it if they expect to capture a big

Re: Version strings

matthew.sel...@twosigma.com said: > Yes, what if we build the version from the VERSION file (+ last git commit > short hash + BUILD_EPOCH, only when building from git)? > This would avoid having to calculate the distance to the tag, etc, that > autorevision currently does. > The BUILD_EPOCH

Re: Version strings

> What's wrong with being tangled up in ntpsec's policy and library. Now we > just have to fix it one place, not two. How does adding complexity help > here? I was looking for a way to decouple simple scripts from the python library package. It all started when you wanted to be able to run

Re: rasPi Stretch Lite install notes

>>> Who cares about the dynamic peak? That is handled by the RasPi on >>> board capacitors. When the capacitors can not hold up the DC any >>> longer then the meter sees the problem. >> No, the meter is much too slow for that. (Or at least mine is.) > I'd love to test that. Maybe the $100

Re: What packet modes do we support?

e...@thyrsus.com said: > I don't know. My from-the-code-out view does not make me confident that I > know what the consequences of *not* processing mode 1 are. If somebody else said: peer It would stop working. It's probably reasonably easy to process them. Just treat them like mode 3

Re: Version strings

devel@ntpsec.org said: > I just re-read this. I see you said "date". I addressed the version number, > not the date. I think the change is still good for that reason. My fat finger. Sorry. Our man pages already have the date in the center of the bottom line. What I was looking for was to add

Re: rasPi Stretch Lite install notes

devel@ntpsec.org said: > That sounds useful, yes. Again, I wouldn't want a configurable delay as > much as I would like to ensure that it only ever flushes a full block (or a > whole multiple of that), as defined by the underlying fs (so most likely > 512byte or 4kiB), to storage unless the

Re: Version strings

> Long-term, I'd like to simplify and just do the same git checks within waf > itself. It's got to work without git, and it has to get the same checksum when built from git or tarball. I think that means you have to stash the git timestamp in a local file. That file doesn't get checked into

Re: rasPi Stretch Lite install notes

> Who cares about the dynamic peak? That is handled by the RasPi on board > capacitors. When the capacitors can not hold up the DC any longer then the > meter sees the problem. No, the meter is much too slow for that. (Or at least mine is.) -- These are my opinions. I hate spam.

Re: What packet modes do we support?

> The page that covers differences from Classic - docs/ntpsec.txt. It's under > Security. Thanks. * peer mode has been removed. The keyword peer in ntp.conf is now just an alias for keyword server. * Broadcast- and multicast client modes, which are impossible to secure, have been

Re: Version strings

>> Maybe it's time to move ntpviz and the logging >> stuff to a separate package. > How does that help? Then they could have their own version string policy rather than getting tangled up with ntpsec's policy and library. I think I'd call it a bug if a script only uses the python library to

Re: rasPi Stretch Lite install notes

>> The logging code currently includes a flush. A few lines of >> code could batch that. > Unless it's made optional it should be kept that way. Agreed. I was thinking of a parameter in the config file to set the flush delay. -- These are my opinions. I hate spam.

Version strings

Was: Re: Catching up Gary said: > waf should be putting the version in ntploggps, then it will mean something, > and can run standalone There was similar discussion of waf editing man pages to get the date on the bottom left corner. I don't understand waf well enough to go there. I think this

Re: rasPi Stretch Lite install notes

> To be somewhat nicer to the SD card I think of moving the ntpd statistic > logs to a tmpfs and then periodically moving them to permanent storage I did something like that ages ago. I don't remember why I stopped. Most likely it just fell through the cracks. I keep daily log files. I

Re: What do I do about this? (Pipeline failed - can't find bison)

> This smells like a Gitlab glitch, probably transient. Is there a simple way to say "Please try again?" (without adding clutter to git's log) -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org

What do I do about this? (Pipeline failed - can't find bison)

I figured out why I didn't get the expected response from GitLab's build checker the other day. I forgot to do the push. Blush/Sigh. This just arrived: Subject: ntpsec | Pipeline #15898502 has failed for master | e349aa13 WARNING: The following packages cannot be authenticated! libcap2

Re: Catching up

>> I don't think running directly out of the source tree is very >> interesting. > OTOH, a bunch of programs, like ntplogtemp, that used to be able to run > in tree, no longer can. I think that is our loss. Creeping complexity > for no real user benefit. Sometimes life is tough. python

We need more testing

Was: Subject: Re: What packet modes do we support? Eric said: >> Context is I'm working on documentation. Often, I'm removing >> stuff that is no longer relevant. Sometimes that requires checking >> the code. Some of the code needs cleaning up too. I think - maybe >> I just don't understand

Re: Catching up

rlaa...@wiktel.com said: [Running with Python3] Thanks. > That way, the scripts can be run directly from the source tree (with the / > usr/bin/env shebang). I don't think running directly out of the source tree is very interesting. Many of the python programs need our python libraries and

Re: asciidoc question: [red]?

>> I find this in our documentation: >> page. [red]#Note: Potential ... > http://www.methods.co.nz/asciidoc/chunked/ch10.html Thanks, but I didn't want to get in that deep. I was looking for something simple I could copy. As far as I can tell, we don't use colors. (That's probably good.

Catching up

I just pushed lots of documentation updates, mostly in the crypto area. (No thumbs up/down message from the autobuild stuff yet. I guess it's sleeping.) There is (much?) more work to do. I'm going to take a break from documentation for a while. There is a new hack in attic/digest.c It works on

Re: SHA1 vs crypto doc

>> Looks like the shannn are blessed by FIPS 180-4 >> I'll update the doc to mention them. > Better check to make sure the support is in place first. I think I remember > floating a patch for that only to have Daniel thumbs-down it and say he > was going to do do that. That turned into an

What packet modes do we support?

Where is that documented? Context is I'm working on documentation. Often, I'm removing stuff that is no longer relevant. Sometimes that requires checking the code. Some of the code needs cleaning up too. I think - maybe I just don't understand it yet. We treat peer in ntp.conf as an

asciidoc question: [red]?

I find this in our documentation: page. [red]#Note: Potential It comes through unmodified in the html version. I assume it's trying to make some text stand out. How do I make colored text and/or is that the right way to do it? Is there an example I can copy? -- These are my opinions. I

What do I type to proofread a man page?

after waf has built it. And/or where should I look to find that info? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel

Re: Crypto, passwords

> I'm not an expert in this sort of things, but I would suggest you at least > change that to an HMAC. Good suggestion. Thanks. Mostly, this code has to be backwards compatible. It's setup to do digests: EVP_DigestInit_ex(...); // setup for digest type EVP_DigestInit_ex(...);

Re: Crypto, passwords

> I have no idea how it's used in NTP. But I understand it's some kind of > shared password? You should clearly look in how it's being used and if that > actually makes sense. Maybe it needs more than just replacing the hash > algorithm. It appends a digest to the packet. This digest covers the

Re: SHA1 vs crypto doc

Eric said: > What could we say, other than: "Both MD5 and SHA-1 have been compromised. > Don't trust either of the alternatives we actually support." :-) We support anything OpenSSL supports. It's just that ntpkeygen and all the documentation hides it. >From man dgst on Fedora:

Re: Crypto, passwords

Matthew Selsky said: > When I use ntpq from Classic, I'm never prompted for a password. I'm not > sure if it's reading the key from /etc/ntp.keys on my behalf or not. Thanks. Are you modifying things, or just looking? For example, ntpq -p doesn't require a password. Are you running as root?

SHA1 vs crypto doc

> No, SHA1 is no longer considered safe. The first collision was generated > early last year. The git team is considering a move to SHA-2 (I think - I > might be out of date on this.) Should we fix the documentation for the upcoming release? And update ntpkeygen. There are comments in the

Re: Crypto, passwords

devel@ntpsec.org said: >> Should we fix the code that reads keys to allow text for other >> types than MD5? > I've had this on my mind for a while, but it seems like the kind of thing > where we might want to float a draft RFC before implementing. > We need to be careful here because the

Crypto, passwords

Does anybody use shared keys between NTP servers? The keys file format is text for MD5 and hex for all others. ntpkeygen makes 10 MD5 and 10 SHA1 keys. MD5 is no longer considered safe. Is SHA1 considered safe? What other types should we test and/or suggest people use? ntpq needs a password

Re: Attn: Install path debaters

Whatever happens, we need to document a summary of this discussion so we don't have to repeat it again tomorrow. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel

Re: File protection mystery

>> Anybody understand setcap? > Alas, I've never used it. I think I've figured out what is going on. The capabilities on a file are OR-ed in to what you start with. Thus if you run it as non-root, you get the specified capabilities. If you run it as root, you start with root's

Re: More install troubles

> When you want "/etc", use SYSCONFDIR. That defaults to PREFIX/etc, but would > be changed to just /etc for a distro package. See: ./waf configure --help Thanks, but... Does anybody actually run with a config file in /usr/local/etc/? If that is interesting, we have more troubles than just the

File protection mystery

I've been experimenting with running ntpd as setuid ntp. I can't figure out how it is reading my keys file. -r. 1 root root 1072 Oct 5 2015 /etc/ntp/ntpkey_MD5key_deb2.example. com.3653024474 lrwxrwxrwx. 1 root root 41 Dec 3 2016 /etc/ntp/ntp.keys ->

Re: More install troubles

> Why is this not automatic from 'waf config' ? Probably because nobody ever wrote the code. But I think it's buggy anyway. The only place it's used is for /etc/ which probably doesn't want a prefix. No replies to my NFS query yet. I'll probably procrastinate a bit. If I don't get any

Re: Range checking on config file

> I'm divided in my mind about whether to fix this. It's not really right, ... Do we have a good place to document it? It's possible that the Bison parser does range checks and doesn't allow the nasty case. -- These are my opinions. I hate spam.

Anybody use NFS and crypto keys?

I'm working on the documentation for ntpkeygen. It's got various comments involving NFS. I can't match what's written with what I know about NFS and ntpd. But I don't use NFS. This is tangled up with asciidoc's prefixdir If you had secrets, would you get them over NFS? Does anybody put

Re: Range checking on config file

>> Unless I missed something, the code processing gonfig slots can't distinguish >> -1 from 0x or the equivalent decimal number. ... > That is correct. Is this leading to a bug? I don't know of a case where it currently causes problems. We might be able to find one if we look hard

Range checking on config file

Unless I missed something, the code processing gonfig slots can't distinguish -1 from 0x or the equivalent decimal number. They both come through as T_Integer. There is no T_Unsigned The checking code gets to pull it as either xx->val.i or xx->val.u struct attr_val_tag {

More install troubles

>From docs/asciidoc.conf: # This is to help distribution packagers # Change this to match install paths, and then build documentation prefixdir=/usr/local That seem likely to fall through the cracks. As an example, has anybody mentioned it during the ongoing discussion? It's only used in a

Re: bad printf

> I think a cast would be safe in this situation. Yup. I used PRTu32. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel

Re: bad printf

> ../../ntpd/ntp_loopfilter.c:1005:20: warning: format '%lu' expects argument= > of type 'long unsigned int', but argument 2 has type 'uptime_t {aka unsign= > ed int}' [-Wformat=3D] > DPRINT(2, ("local_clock: mu %lu state %d poll %d count %d\n", My bad. I'll fix. But first I have to

Install is writing in my build directory

Is that expected? Why? ... waf check does it too. So does a redundant waf build. I'd like a way to test that everything is ready to install. I'd expect waf check to do that. [ 97/104] Processing /home/murray/ntpsec/raw/build/main/pylib/control.py: wafhelpers/pythonize-header

Drop root and friends

Inspired by the problem with reading the drift file, I'm scheming about that area. I tried running ntpd as setuid, user ntp. It died when it tried to open a socket. On Linux, the droproot code keeps cap_sys_nice,cap_sys_time and maybe cap_net_bind_service. So I poked around some more.

What is .gitlab-ci.yml?

and/or where is it documented and/or why is it part of the git source tree? It contains many lines like this one: - python -m unittest discover -s build/main/tests/pylib Does/should waf check to that? If so, I think that line could be replaced with a "check" added to the previous line.

Re: Does ntpq have a command line history mechanism?

jamesb.f...@gmail.com said: > might it be commit f5bd6314795be0380eb1c4bdfb872c7edfa9ee82 > Author: Ian Bruene > Date: Mon Oct 2 08:18:51 2017 -0500 > Possible fix for ntpq unicode issue Yes. Thanks. I don't know anything about the unicode issue. -- These are

Re: ntpd/varsion.h

Thanks. > I don't think version.h itself belongs in a source tarball, but *some* kind > of git-independent version information needs to be, so that one can build > outside a git repo. The current kludgery that one has to go through with > autorevision is tedious. There is also version.py I

Do we want ./waf dist?

devel/make-tarball looks better to me? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel

ntpd/varsion.h

Should it be included in a tarball? How about wafhelpers/.autorevision-cache? Should it be moved to $build/main/ntpd/, similar to the way that derived python files were moved to $build/main/pylib/? -- These are my opinions. I hate spam. ___

Re: ./waf install is not idempotent?

> A bunch of stuff in the packaging directory under SUSE and RPM, and this: > ./pylib/version.py:VCS_TAG = "NTPsec_0_9_7" > ./pylib/version.py:VERSION = "0.9.7" That's another symptom of our overall development process leaving cruft around. That stuff was moved to $build/main/pylib/ quite a

Re: ./waf install is not idempotent?

> So . . . I just kept running ./waf install, and I think it just cycles > through these three modes: > 1) installs ntpq 0.9.7 > 2) Python error 3) > installs ntpq 1.0.1+183 > I ran a ./waf distclean before my configure, build, install steps. I will > try from a fresh clone. > Before I open a

Re: Does ntpq have a command line history mechanism?

> root@protactinium:/home/jazze/code/ntpsec# ntpq -V ntpq ntpsec-0.9.7+68 > 2017-03-31T08:38:03Z Thanks. The remove import change was late Dec 2016. Looks like bisect time. -- These are my opinions. I hate spam. ___ devel mailing list

Re: Does ntpq have a command line history mechanism?

> @Hal, can you double-check that the readline python module is importable on > your system? You might need libedit or GNU readline installed. Python 2.7.14 (default, Dec 11 2017, 14:52:53) [GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] on linux2 Type "help", "copyright", "credits" or "license" for

Does ntpq have a command line history mechanism?

I was expecting one, but I get things like this: ntpq> ^[[A^[[A^[[B ***Command `' ambiguous ntpq> That was up-arrow, up-arrow, down-arrow Is there some package I need to install? -- These are my opinions. I hate spam. ___ devel mailing list

DESTDIR vs --destdir and friends

How about we pick one and go back to discussing where to install stuff. I prefer --destdir since I can see what's going on when looking at a script. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org

Re: DESTDIRMime-Version: 1.0

> export DESTDIR=/usr/local/ > ./waf configure --refclock=all --prefix=BATSHT && ./waf build &&./waf install > /usr/local/u1/local/src/NTP/ntpsec/BATSHT/{bin,sbin,share} You didn't put a / in front of BATSHT so it turns that into the full pathname of a local directory and then puts DESTDIR in

Fw: [Git][NTPsec/ntpsec][master] Tweak INSTALL to mention when prefix+destdir work

> You just pushed a doc change I do not entirely agree with, and is > insufficiently informative of the issues. > +NB: --destdir works at install time, --prefix works at configure time. OK. Poor choice of words. Got a better suggestion? If you specify a prefix at install time, it is ignored,

Re: Python libs on Debian/Raspbian

> --prefix and DESTDIR, are ONLY used to decide where to install. And as the > above shows, how they work together not exactly obvious. Given the length of this discussion, we should probably figure this out. INSTALL says: There is a separate `--destdir' option that changes the root of the

Re: Python libs on Debian/Raspbian

> We have different paths embedded in the binaries that we run the regression > tests against. autoconf has tricks that it does with LD_LIBRARY_PATH so > that "make check" uses the libraries in the build area. waf likely has a > similar feature that we can take advantage of. I don't think

Re: Fix for Issue #409

> The question by Richard still stands, though: we should not do anything as > root that can be done with lesser privileges, so why not defer reading the > drift file until after we've dropped root? That would be vastly preferrable > to any of the other workarounds discussed. The original idea

Re: Fix for Issue #409

> That's not a fix, that's creating a latent security problem with clobbering > a file name that's known in advance so you can plant things under that name > and have it overwrite a different file that you normally wouldn't be able to > access. I'm not following what you are trying to describe.

Fix for Issue #409

I just pushed a fix for Issue #409. The drift file now gets created with the normal protection modes rather than 600 so apparmor should be happy when reading it as root during startup. (Unless you have a non-standard default mode. ...) I also added a few more uses of uptime_t and removed

Re: Preparing for a point release

Gary said: > Well, in Gentoo, you are never supposed to directly access /usr/lib64. You > are only supposed to access /usr/lib which is a link to lib32 or lib64, > which ever is in current use. On this Fedora box, /usr/lib/ and /usr/lib64/ are different directories. /usr/lib64/ is much bigger.

Re: Python libs on Debian/Raspbian

Gary said: > PYTHONPATH, sys.path, or site.addsitedir(), the same options we keep dancing > around. They generally add things to the search path. I want to remove things. I'm trying to avoid using the system or local libraries to make sure I'm testing the new libraries that I want to test.

Re: Python libs on Debian/Raspbian

>> 1. System-wide, distribution-blessed installation (aka packaging). >> 2. System-wide, local installation. >> 3. User installation. >> I don't see user installations as a real thing for ntpd, but the user >> space control and monitoring tool tools might be a different story. > We need it

Re: Python search path?? How do I test ntpq?

Oh, crap. Sorry for the clutter. File "/home/murray/ntpsec/play/hgm/main/ntpclients/ntp/util.py", line 1076, That's not the installed library. I got fooled by the full path name when I was expecting something like ./whatever Now to go find out what happened. -- These are my opinions. I

Re: Cruft from timesync

> Is this our problem? I'm not sure. I think we'll have to get out wireshark or whatever it's called and see what's going on. I don't understand why the avgint is so low. A timesync bug could do lots of retransmissions unreasonably quickly. But I would expect a batch each time the system

Counter cleanup

I just pushed code that fixes the counter overflow problem, Issue #424. I made a pass through the mode6 code and fixed various other counters too. If you can read it, it should be big enough. The hit count in the MRU slots didn't get changed. It will take a long sustained attack to

Cruft from timesync

192.168.1.106 is a Ubuntu 17.10 box that I'm setting up. It's using DHCP and running timesync. Looking at one of the local NTP servers that my DHCP server gives out. ntpq> mru Ctrl-C will stop MRU retrieval and display partial results. lstint avgint rstr r m v count rport remote address

Re: Do Python libraries need a ersion number?

e...@thyrsus.com said: > If you look in the library Python directories you will see that this is not > done. It would make writing imports a problem, as "ntp-1.0" is not parsed > as a single token in Python. So we have to use things like ntp, ntp2, ... ? Do Python libraries get used by other

Re: Do Python libraries need a ersion number?

devel@ntpsec.org said: > This seems like the expected result to me. On my Ubuntu system, /usr/local/ > lib/python2.7/dist-packages comes before /usr/lib/python2.7/dist-packages in > sys.path, and /usr/local/bin and sbin come before /usr/bin and sbin. I was thinking of the case where somebody

Re: Bite of the Buildbugs!

Thanks for the nice summary. > In the `waf install` process, after the PYTHONDIR directory is created, > check sys.path. If PYTHONDIR is not in sys.path, do $SOMETHING. I think it would be better to do the check before installing anything. If we aren't going to automatically fix it, I think

Re: Is there any reason the drift file should be mode 600?

> 1) Fix the apparmor policy. ... Is it easy to hack the startup scripts to change the mode so root can read it? That sort of stuff used to be easy before systemd. It actually executed /etc/sysconfig/ntpd We have similar problems of needing to run ldattach for PPS. I haven't figured out

Re: Is there any reason the drift file should be mode 600?

e...@thyrsus.com said: > Yes. A Unix write(2) under 512 bytes is atomic, and (when to a local > filesystem) can't be signal-interrupted either. There's a constant PIPE_BUF > which is historically 512 but may be larger on modern Unixes - I haven't > looked in a long time. Technically it

Is there any reason the drift file should be mode 600?

This is from issue 409. https://gitlab.com/NTPsec/ntpsec/issues/409 The code that writes the drift file uses mkstemp and rename. mkstemp uses mode 600. I can't see a way to override that. That gets inherited by the renamed file. If you are using apparmor, ntpd can't read the drift file at

git lesson please

devel@ntpsec.org said: > Er, whoops! I broke that as part of my fix for improperly generated files. > Should be fixed now. Thanks. Is there a simple way to do a git pull when I have edits in progress? [murray@hgm raw]$ git pull error: cannot pull with rebase: You have unstaged changes.

version stuff, autorevision

Something broke in my setup and I can't figure out what's going on. I build/test on one system, then scp to other systems so I can build and test there. The scp step skips .git to reduce clutter and save network time. Some of the other systems don't even have git installed. I have a kludge

Re: Type for uptime in seconds

> I'd just do "typedef uint32_t uptime_t;" somewhere, myself. There isn't a > system type devoted to this sort of thing; closest would be clock_t. The > units for that are not specified, but are often microseconds. Thanks. That's just what I was looking for. I'm running with it. Feels

Type for uptime in seconds

Context is Issue #424 It's simple to change the counters to 64 bits. But a few of the relevant variables are uptime in seconds. Is there a good type to use for them? time_t is misleading. current_time is seconds since ntpd was started not seconds since 1970. unsigned long current_time;

Installing man/html pages

Are we installing man pages in the right place? Do distros agree on where to install them? Does anybody who wants man pages also want html versions? Do we have anything in one format that isn't in the other? Do we want an install option to install only man pages? The idea is to help

Alternatives to waf

Richard Laager said: > While I agree that waf is obscure (and accordingly wish ntpsec used > something else), it seems to do the right thing out of the box. What are the alternatives? Are there any good ones? Is there a good URL discussing the issues and tradeoffs? I'm not familiar with that

Re: Python libs on Debian/Raspbian

> When you say PYTHONPATH, do you mean: > 1) "a custom directory set in the environment variable PYTHONPATH" That's what I mean. I think Gary does too. But maybe you mean more by "custom" than I do. I've been assuming /usr/local/, mirroring where I expect the distro to put it in /usr/ if they

Re: Old cruft

>> It works on Fedora. > We have different definitions of 'works'. My definition of "works" was that it installed where I think you wanted it to go and ntpq and friends worked without PYTHONPATH but with Richard's local.pth If you think we should be using PYTHONPATH, then we shouldn't waste

Re: Python libs on Debian/Raspbian

> Conversely, any plain '/waf install' by user/admin, from our source,=20 > should go in a place, that MUST require that location in to be in > PYTHONPATH. I thought that people didn't like PYTHONPATH. Richard's local.pth suggestion works (without PYTHONPATH) on Fedora. It seemed like an

Re: Old cruft

> So, forgive my tardiness, can you explain local.pth a bit? It's magic from Richard. It's a file that adds stuff to Python's search path. I don't know details. It works on Fedora. Grep your email. If that doesn't work, I'll find a Message-ID or link to the archived copy. Also look for

Re: Python libs on Debian/Raspbian

devel@ntpsec.org said: > We need to focus our default on helping the user that downloads our source > tar ball to install the build exactly where Python upstream wants us to: I don't care where it is installed. I'm trying to make sure it works after it gets installed. Do we have to use

Re: Old cruft

> I assuming you did a test of the debian package install, and that properly > installed into: > /usr/local/lib/python2.7/dist-packages > Then you did a native NTPsec install, and that properly installed here: > /usr/local/lib/python2.7/dist-packages > Are my assumptions correct? If so,

Python libs on Debian/Raspbian

site-packages isn't on python's search path. murray@deb:~$ python -c "import sys; print sys.path;" ['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload',

Old cruft

> I'm currently trying to figure out how a just built/installed ntpq on a > Raspberry Pi thinks it is 0.9.7 ??? Found it. There was an old ntpc.so in /usr/local/lib/python2.7/dist-packages/ while new stuff was getting installed in /usr/local/lib/python2.7/site-package s/ntp/ -- These are my

Re: Preparing for a point release

>> We'll need a variation for 32 bit systems. > Uh, no. And no. At least not on Gentoo. Well, in addition to something for 32 bit systems, we may need different recipes for different distros. Fedora is different than Gentoo. When I cut-pasted Richard's recipe on a 32 bit system, it barfed

Re: Preparing for a point release

rlaa...@wiktel.com said: > cat > /usr/lib64/python2.7/site-packages/local.pth << EOF >> /usr/local/lib64/python2.7/site-packages >> /usr/local/lib/python2.7/site-packages >> EOF > mkdir -p /usr/local/lib64/python2.7/site-packages > mkdir -p /usr/local/lib/python2.7/site-packages We'll need a

Re: Preparing for a point release

> It is closed with, "F27 will have this issue resolved.". I'm running on F27. > For existing systems, there are three solutions: ... rlaa...@wiktel.com said: > 3) Create a .pth file in the appropriate place, which is somewhere under / > usr. There are probably existing ones: find

<    9   10   11   12   13   14   15   16   17   18   >