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