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
On Sat, 23 Dec 2017, Hal Murray wrote:
> > but isn't when compiled extensions like 'ntpc' are involved. Extensions
> > almost never work with a different Python that the one they were compiled
> > and linked for, with a variety of possible failure modes.
>
> Should ntpc.so get installed in the A
On Sat, 23 Dec 2017, Jason Azze via devel wrote:
> On Sat, Dec 23, 2017 at 5:47 PM, Hal Murray wrote:
> >
> >> I ran a ./waf distclean before my configure, build, install steps. I will
> >> try from a fresh clone.
> >
> >> Before I open a GitLab issue, is this unexpected behavior?
> >
> > It sure
> but isn't when compiled extensions like 'ntpc' are involved. Extensions
> almost never work with a different Python that the one they were compiled
> and linked for, with a variety of possible failure modes.
Should ntpc.so get installed in the ARCH dir rather than the normal dir?
--
These a
On Wed, 20 Dec 2017, Richard Laager via devel wrote:
> 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
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.
___
deve
> 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 whil
On Sat, Dec 23, 2017 at 5:47 PM, Hal Murray wrote:
>
>> I ran a ./waf distclean before my configure, build, install steps. I will
>> try from a fresh clone.
>
>> Before I open a GitLab issue, is this unexpected behavior?
>
> It sure looks unexpected to me. There shouldn't be anything about 0.9.7
> 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 Gi
While freshening my NTPsec install to test the ntpq command history
bug, I accidentally ran ./waf install twice in a row because I thought
I had forgotten to run it at all. I thought I had forgotten because
ntpq -V still showed my old version 0.9.7+68.
On the second run, (which at the moment I tho
> 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
devel@nt
On Sat, Dec 23, 2017 at 3:24 PM, Eric S. Raymond via devel
wrote:
>
> This is highly annoying. We've done someting in our interpreter that busts
> that feature, but it is not obvious what. Perhaps the polyglot changes?
>
> I'll dig into this further when I get back from sword class
> --
>
I hap
Matthew Selsky via devel :
> On Fri, Dec 22, 2017 at 06:42:00AM -0500, Eric S. Raymond via devel wrote:
> > Hal Murray via devel :
> > >
> > > I was expecting one, but I get things like this:
> > > ntpq> ^[[A^[[A^[[B
> > > ***Command `' ambiguous
> > > ntpq>
> > >
> > > That was up-arrow, up-arr
13 matches
Mail list logo
