Python ntpq lands - what to do next?
Eric S. Raymond
esr at thyrsus.com
Sat Nov 5 21:50:00 UTC 2016
Hal Murray <hmurray at megapathdsl.net>:
>
> esr at thyrsus.com said:
> > (Hal, I tested and it works both in-tree without installation and out of
> > tree after waf install. If you still have an environment-specific problem
> > we'll fix that.)
>
> It's broken for me.
>
> [murray at glypnod ntpq]$ ./ntpq
> Traceback (most recent call last):
> File "./ntpq", line 17, in <module>
> from ntp.packet import *
> File "/home/murray/ntpsec/play/ntpq/ntp/packet.py", line 16, in <module>
> from ntpc import lfptofloat
> ImportError: No module named ntpc
> [murray at glypnod ntpq]$
>
> That's with no PYTHONPATH.
>
> There is a link in pylib:
> ntpc.so -> ../build/main/libntp/ntpc.so
> I don't have a build directory.
That's odd. Where is waf putting your binaries?
> I assume waf configure should setup that link.
No, I made it by hand based on the normal shape of the tree after a
waf build. Clearly you have done something to break that assumption,
but I don't yet know what.
> I haven't figured out what's going on here.
>
> [110/137] Compiling VERSION
> error: No repo or cache detected.
>
> -> task in '/home/murray/ntpsec/play/pylib/version.py' failed with exit
> status 1 (run with -v to display more information)
>
> -rw-rw-r-- 1 murray murray 0 Nov 5 11:42 version.py
>
> What I'm doing is building on a system without git after rsyncing from my
> main system. The rsync step excludes as much as I can, mostly .waf and .git
>
> How is this new version stuff going to work from a tarball?
What's going on: In fulfilment of a request from Gary to make package
version information easily accessible from Python, I told waf to
generate a file pylib/version.py using VERSION as input. Mine looks
like this:
# Generated by autorevision - do not hand-hack!
TYPE = "git"
BASENAME = "ntpsec"
UUID = "5a60ff124237ba5d23101e4ca60016ebeae7cb50"
NUM = 11271
DATE = "2016-11-05T20:26:32Z"
BRANCH = "master"
TAG = "NTPsec_0_9_4"
TICK = 838
VERSION = "0.9.5"
ACTION_STAMP = "2016-11-05T20:26:32Z!esr at thyrsus.com"
FULL_HASH = "30b568a7e26aaf7c43089545d4c0384834046c3d"
SHORT_HASH = "30b568a"
WC_MODIFIED = True
# end
I believe that the production won't fire (and fail) if
pylib/version.py exists and is newer than VERSION, which I expect to
be the case in a tarball that prserves dates (because it will always
be true after waf runs).
So the first question is, does your unpacked tarball have a pylib/version.py?
And is it newer or older than VERSION?
> After build, there are things like statfiles.pyc in pylib/
> Is that the right place for them? Why are they not in build/main/pylib/ in
> parallel with the other compiler output?
It's a waf quirk I don't know the reason for. If you look in build/main/pylib/
you'll probably see this:
__init__.pyo ntp_magic.pyo statfiles.pyo version.pyo
Those are the optimized versions that "waf install" copies to rootspace.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel
mailing list