> I'll add language to INSTALL that one should make sure this directory exists
> so as not to step on any distribution copy of the ntp library.
That doesn't sound strong enough. It's too easy to accidentally screw up.
--
These are my opinions. I hate spam.
___
> On most systems this will do the right thing.
Which systems don't work right and/or what are we supposed to do there?
> I have implemented and tested this solution, along with full documentation
> and packaging guidance.
I think the documentation needs more work in this area. A separate fil
GPZDA doesn't have a valid/bogus flag
GPRMC only has 2 digit years.
I have a NMEA device that is in the old era.
$GPRMC,030328,A,3726.0814,N,12212.2610,W,000.3,346.3,160298,015.5,E*60
I should be able to calculate the offset, but I haven't got my head around it
yet. It's some mix of year tr
>>> I'll add language to INSTALL that one should make sure this directory
exists
>>> so as not to step on any distribution copy of the ntp library.
>> That doesn't sound strong enough. It's too easy to accidentally screw up.
> What would your recommend instead?
I'm not sure. This whole mess
> As usual, I thing adding an option is a bad substitute for figuring out what
> the right thing is and doing it.
Then create the directory.
> It would be easy enough to throw a warning if the desired /usr/local
> directory doesn't exist.
Warnings are easily lost in the noise. So either creat
> I would bet that /usr/local//lib/python-X.Y is NOT in the sys.path no matter
> what.
So are we back to PYTHONPATH?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
> There are two cases. User-installed code and binaries are supposed to go
> under /usr/local/X; stuff from packages goes under /usr/X, where X = {bin,
> lib}.
I think that means our normal devel-mode install is "user-installed code".
I think that needs to go in our documentation. (along wit
1 Oct 23:48:57 ntpd[16245]: NMEA(0) Changed GPS epoch warp to -4096 weeks
Note that there is not TAG: on the front of that message, or this one:
1 Oct 23:48:56 ntpd[16245]: NMEA(0) serial /dev/cuau0 open at 4800 bps
--
These are my opinions. I hate spam.
__
>> Do we need a way to check that we are using the right library?
>> I think that means we need the version string or time stamp in both the
>> library and the code that uses the library with a simple sanity check at
the
>> top of the uses code.
> It's not normal practice to do this in Python.
> It appears from recent traffic that we have a resiolution of the
> library-path mess that is, if not perfect, at least acceptable to all. It's
> good that PYTHONPATH is gone.
Is there a clear statement someplace of what is supposed to happen?
On Fedora, the python library stuff is getting st
>> Warnings are easily lost in the noise. So either create the
>> directory or treat it as an error and bail.
> There are two issues with just "creating the directory":
> 1) There's no guarantee that Python will actually use it.
> 2) Creating the directory requires root, and it would be
> undesir
If I have PYTHONPATH defined as /usr/local/lib/python2.7/site-packages
Then the python libs get installed in /usr/local/lib/...
If I unset PYTHONPATH, they get installed to /usr/lib/...
Having a PYTHONPATH setup could be leftover from when ntpsec needed it, or it
could be setup because some othe
waf configure prints out:
PREFIX: /usr/local
Should it also printout where it will install the python libraries?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mai
>> Having a PYTHONPATH setup could be leftover from when
>> ntpsec needed it, or it could be setup because some other
>> package needs it.
> Most likely the former, since reasonable packages don't
> require PYTHONPATH. :-)
It seems reasonably likely to me that anybody geeky enough to be inst
>>> Should it also printout where it will install the python libraries?
>> Good idea. I'd take that patch.
> It's already there. Look at PYTHONDIR towards the end.
Thanks.
Is that used for anything other that storing python libraries?
What is PYTHONARCHDIR used for?
--
These are my opinion
> No, if "storing" includes the code that may clean up old library installs.
Ahh... Thanks. That brings up a question I've been wondering about for ages.
What sort of cleanup does waf install do? Is that documented anyplace?
--
These are my opinions. I hate spam.
___
>> What sort of cleanup does waf install do? Is that documented anyplace?
> I don't think install cleans up anything at all. Uninstall removes files
> that would be installed by the *current* code, which of course may leave
> stuff around if the location or set of files changes.
Thanks.
There
My reading is that Fedora doesn't support /usr/local/,
at least not the way we want/expect it to.
So we have 2 options:
Install in /usr/ (no local) and break FHS
Install in /usr/local/ and require PYTHONPATH to use it.
--
These are my opinions. I hate spam.
_
> python -m discover -s build/main/tests/pylib
/usr/bin/python: No module named discover
What is discover and/or why aren't those tests run as part of the normal
tests run by waf check?
--
> @esr I believe that the problem here is caused by differing
> time_t sizes as handled by lfp_sta
>> My reading is that Fedora doesn't support /usr/local/,
>> at least not the way we want/expect it to.
> Lost me. What is expected/wanted? Don't you expect Fedora to respect the
> 40+ years of UNIX tradition and standards to led to the current FHS?
Their default python setup doesn't look for
Did you feed the same parameters to waf configure? Did you forget to include
the SHM driver?
Check your log files to see what it says about SHM.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.
> Last night, we tagged and released 1.0.0 of NTPsec
Congrats.
Should the version number on git be bumped to 1.0.1?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
I was expecting VERSION to get bumped to 1.0.1 after the tarball and such.
> From me: Local monitoring mode to measure and
> graph the offet between a noselected GPS and NTP time.
Just add "noselect" and graph peerstats.
--
A possibly interesting feature in that area.
I have code that wr
>>> For under a $100 you could get a Raspberry Pi, a GPS HAT, and
>>> connect your input to a GPIO pin. Configure ntpd to log the real
>>> PPS and the input as another 'PPS'.
>> Is there an option to log all individual PPS events?
># ppswatch /dev/pps0
That's a way to log stuff, but I don't
Arg, blush. Wrong list. Sorry for the clutter.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
I'm working with an old NMEA device. It sends things like:
$GPRMC,062409,A,3726.0822,N,12212.2630,W,000.3,190.6,150398,015.5,E*6A
I've got a fudge time2 to fix that. It seems to be working.
I'm seeing stuff like this in the log file:
28 Oct 22:48:51 ntpd[2504]: NMEA(0) Changed GPS epoch war
VERSION currently says
1.0.0
I was expecting that to get bumped to 1.0.1 after the release was out so that
we could easily determine that we are running a development version rather
than a release.
But maybe that should be 1.1.0? Or 1.1.1?
devel/hacking.txt says:
We use a variant of three
fallenpega...@gmail.com said:
> I suggest running it with gpsd for a while instead of NTPsec, and see if
> gpsd's logging identifies the issue.
> Or if the ntpd log contains the NMEA strings, it may be possible to
> reconstruct a gpsd playback file, and play it into gpsd, and see what it
> says.
> Remember, without this patches we still have support for the *current* Mac
> OS X, just not far back into older ones. I think that is a sufficient
> gesture for our purposes.
> Opinions of other solicited.
We decided not to put in a trivial patch that would make things work for
older NetBSD
devel@ntpsec.org said:
> I thought that was still under some discussion when we shipped. Remind me
> what the patch was?
I got the impression that you pretty much vetoed it and/or weren't interested
in more discussion. I could easily have misread whatever you said.
I think we should dump long
> As it is now, the OS installed version of ntpd will conflict with a source
> installed version. Not good. FHS compliance would be nice.
I think it would be really helpful if somebody would write up something that
covered this whole area.
I don't understand this area well enough to explain i
> We have some loose ends from 1.0 to clean up. I took care of a few of them
> today;
Would you please fix the VERSION string and update the text in
devel/hacking.txt to clarify what should get bumped after a release. Should
it go to 1.0.1 or 1.1.1?
The release recipe should also get updated
> Dropping long double opened a can of worms about overflow/precision problems
> and how to redo the pivot logic that I didn't want to broach while were
> trying to avoid destabilizing changes.
We ran for years without long doubles. There were no destabilizing problems.
> Now would be a reason
> Thoughts?
Is Go well supported on ARM? (how about powerpc which is other-endian?)
> * libntp is a problem - ideally we want to have the Python extension
> that wraps it call compile Go rather than C, but that could be
> difficult to arrange.
Why do we need a python extension? Can't we c
> I set it at 1.0.1
Thanks.
> I'm expecting 1.1 to be the next minoe release.
>From devel/hacking.txt
> When the minor number is even, it refers to a "stable" release, and when the
> minor number is odd, it refers to a "development" release. New releases on
> "stable" are generally bugfixes that
Delivery-date: Sat Nov 4 17:56:59 2017
Message-id:
Subject: Re: ntpsec | ntpd build fails: undefined reference to
`addr_from_typeunit' (#406)
From: "Eric S. Raymond"
Date: Sun, 05 Nov 2017 00:41:50 +
To: hmur...@megapathdsl.net
Delivery-date: Sat Nov 4 17:57:00 2017
Message-id: <4fc5760f4
> I have become opposed to forking stable releases ...
Even if we don't fork, we need the same structure in version numbers to
handle backporting of bug fixes.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://
>> Is Go well supported on ARM? (how about powerpc which is other-endian?)
> According to the Go documentation, both are fully supported.
How about embedded OSes?
Has anybody managed to get ntpsec running on an embedded OS? Where is that
on our priorities?
--
These are my opinions. I hate
>>> libntp
>> Why do we need a python extension? Can't we convert ntpclients to Go?
> Yeah, that'd be be kind of a mess. ...
Then we leave that chunk of libntp available for Python. It won't be very
big.
>> Maybe that would be a good time to split the refclocks out to separate
>> programs
>> Write a dumb NTP server in Go. The idea is to move ntpd
>> to a different port number so the new code can answer
>> client requests. This assumes that a server can get all the
>> info it needs from the kernel. That may be bogus, but
>> I think it's worth a try. We could write similar code i
>> We ran for years without long doubles. There were no destabilizing
>> problems.
> No, but changing the code *back* before 1.0 was a thing I didn't want to do.
I was surprised you put that change in that close to 1.0. Taking it back
should have been a simple revert.
> I rememenber now thi
> What you say sounds like it would be very interesting if I understood your
> assumptions. I don't. How do we get from 65KLOC to a page if it's doing
> the Byzantine-algorithm thing on multiple peers and clock sources?.
The tiny version is a server only. There is no complicated data.
The ol
> However, the Go developers have stated that this is one of their major aims,
> and it is easy to believe they will be funded to do this because the
> business case for moving a lot of Google's Android devevelopment is *quite*
> clear.
I thought Android is/was derived from Linux. Has it diverg
While looking at some code, I noticed several symbols that are sometimes
protected with an ifdef and sometimes assumed to exist.
I think they are all required by POSIX, and thus the ifdefs are not needed.
Is there any simple way to verify that a symbol is required by POSIX, and/or
the parts of
> Pretty direct, I'd say. I wouldn't even have introducing *methods* as an
> initial goal. My experience is that trying to re-engineer while you
> translate is a dangerous rathole - you can easily end up at a place where
> you've lost track of the semantic mapping between the original code and t
> On the other hand, the thought of trying to do significant structural
> changes *as we verify a translation* scares me - I do not think I am good
> enough to take *that* risk, and I'm dubious that anyone is.
Right. But that assumes the goal is to exactly replicate the current code.
Given th
> Simple, Distro installed stuff goes in /usr. User installed stuff goes in /
> usr/local/. Nice clean separation. Been taht way since I learned UNIX in
> the early 1980's.
If it was as simple as that, we wouldn't be having this discussion.
If stuff goes into /usr/local/, what do I have to d
> Wrong question. Much harware has NO hardware support (FPU)
> for any floating point, so it is done in the CPU, not FPU.
Is anybody running on a system without hardware for floating point?
--
These are my opinions. I hate spam.
___
devel mailing
eric said:
> Do you have any suggestions about a test target? I've been giving that some
> thought, and it's not easy to come up with anything that I think has close
> to the same near-realtime constraints as ntpd.
How about the simple ntpd server I suggested a few days ago?
Even if you can't
e...@thyrsus.com said:
> I still don't understand that suggestion at all. Would it be implementing
> the Byzantine time=sync algorithms? If so, howe is it simple?
No. That's what makes it simple.
> I guess I need to see something more like a functional spec for your
> concept. It sounds like
../../tests/ntpd/leapsec.c:581:3: warning: implicit conversion from 'long
long' to 'time_t' (aka 'int') changes value from 2982009600 to -1312957696
[-Wconstant-conversion]
../../tests/ntpd/leapsec.c:582:3: warning: implicit conversion from 'long
long' to 'time_t' (aka 'int') changes value from
>> Yea, I have the same conclusions. Maybe just a toy NTP client that
>> compared one peer or refclock to the sysclock? Then compare that to what
>> the local ntpd thinks about the sysclock.
> No, because, agauin, that's not far short of the real thing.
There is a lot of wiggle room in "toy cl
> The resaon I'd take this is that it's good for timekeeping setups. In
> stationary mode you can get time with fewer sats visible.
I think you may be reading too much into "stationary" mode.
If you know the position, you can get time with only one satellite. Timing
receivers normally have a
My Linux man page says open(2) takes an optional 3rd argument - the mode bits
that are used if the file is created. The POSIX man pages don't say anything
about it, but do leave a ... in the skeleton for open.
The mode argument specifies the file mode bits be applied when a
new
devel@ntpsec.org said:
> I'm headed out the door, over hill and dale, but smeone asked me to show a
> minimal NTPsec build. I failed, and found a bug:
> spidey ntpsec # ./waf configure && ./waf build
> [...]
> [82/93] Compiling ntpfrob/bumpclock.c
> ../../ntpd/ntpd.c: In function 'ntpdmain':
> .
> > ../../ntpd/ntpd.c:831:39: error: 'debug' undeclared (first use in
> > this function) fprintf(stdout, "#debug =3D3D %d\n", debug); =20
Here is what I think is going on.
The default configuration is no-debug. That is supposed to configure out all
references to debug in ntpd/*, but ntplib is
hmur...@megapathdsl.net said:
> The search order magic seems to be broken on most systems. Or they extern
> debug without any warning. Or ...
I changed the offending "debug" to "xdebug". My system generated an error.
I added a "barf" to ntpd/declcond.h, expecting it to generate an error. I
Why did you decide to remove the utmpx stuff?
When I looked at the source code (after a git pull) for issue 411, that chunk
was still there.
Looking now, after:
commit c0bb4b05ac1864ea14535b55c15aa6c03d8f2ea2 (origin/master, origin/HEAD)
Author: Eric S. Raymond
Date: Wed Nov 22 20:4
I got mail from gitlab complaining about my recent fix to
tests/option-tester.sh
Commit: 7766f017 ( https://gitlab.com/NTPsec/ntpsec/commit/7766f0177dd8ce4b375
51e93a8e302a345e7e43c )
Commit Message: Fix to not use --disable-debug
Job #41726247 ( https://gitlab.com/NTPsec/ntpsec/-/jobs/41726247
Does anybody have a list of the stuff we installed in the wrong place and
didn't automagically clean up? We did a lot of that ages ago. I'd like to
clean it up manually.
Looking at /usr/local/{bin,sbin}/ntp*, I found
some stuff with dashes in the names
some stuff in sbin that we moved to b
It seems like a good idea for somebody to actually test our code on a
big-endian system.
I have a Mac Mini G4. It's currently running Debian 8/jessie. But Debian
9/stretch has dropped support for powerpc.
Does anybody know of Linux distros that support 32 bit PowerPC? I want to
download a
The output from waf -v is full of crap like this:
-DHAVE_STRUCT_TIMEX=1', '-DHAVE_STRUCT_NTPTIMEVAL=1',
'-DHAVE_STRUCT_TIMEX_MODES=1', '-DHAVE_STRUCT_NTPTIMEVAL_TAI=1',
'-DNTP_SIZEOF_LONG=4', '-DNTP_SIZEOF_TIME_T=4', '-DOPEN_BCAST_SOCKET=1',
'-DHAVE_OPENSSL_EVP_H=1', '-DHAVE_OPENSSL_RAND_H=1',
An interesting tangle. I'm cleaning up odds and ends, including upgrading
Raspberry Pi-s to Stretch. One of them dies with a SIGSYS trap.
It's dieing on 240 which is futex. That's locks, only needed if you are
using threads. This system was built with --disable_dns_lookup, so there
shouldn'
k...@roeckx.be said:
> This means that when we initialize a global variable we use the
> pthread_once() function, which internally uses the futex to do that. It's
> not using threads itself, it's just making sure that if you use threads
> things work properly.
Thanks.
Do we have to link with pt
devel@ntpsec.org said:
> waf doesn't know that config.h exists; this is its way to pass configuration
> switches. The fact that we generate a config.h is really legacy behavior
> from autoconf and could be eliminated, but it's low on my priority list.
It may be "legacy", but I like it. It's a h
More poking around... Remember, I don't really grok waf.
The call to write_config_header has a suspicious looking argument. So I
tried it.
-ctx.write_config_header("config.h", remove=False)
+ctx.write_config_header("config.h", remove=True)
config.h looks reasonable. waf -v is much les
> What's mysterious here?
I haven't figured out what this stuff is doing. I don't think any of them
are referenced by any of the code.
> '-DPYTHONDIR="/usr/local/lib/python2.7/site-packages"',
> '-DPYTHONARCHDIR="/usr/local/lib64/python2.7/site-packages"',
> '-DHAVE_PYEXT=1', '-DHAVE_PYTHON_H
> ?? I haven't figured out how the simple case builds without warnings.
Found it.
My script that generates warnings nukes the build directory.
Running configure again, then build, recompiles lots of stuff, but not
everything. I'm guessing it notices the new config.h which timespecops.c
doesn'
> > '-DPYTHONDIR="/usr/local/lib/python2.7/site-packages"',
> > '-DPYTHONARCHDIR="/usr/local/lib64/python2.7/site-packages"',
> > '-DHAVE_PYEXT=1', '-DHAVE_PYTHON_H=1'
> Yeah, that's boilerplate for use by Python extensions written in C.
I haven't found any uses in our code. Should we remove it
I was setting up ntpsec on a Raspberry Pi. Things got confused. It looked
like another instance of the drift stuck at 500 ppm bug, issue 44
https://gitlab.com/NTPsec/ntpsec/issues/44
but things got even more confused when I tried to gather more info.
I finally figured out that systemd-timesy
> There aren't any uses in our code. Whether we can remove it is a question.
> Have you identified where it's generated.
I think it's in wafhelpers/check_pthread.py
If you are thinking about that area, please consider issue #412
https://gitlab.com/NTPsec/ntpsec/issues/412
--
These are my o
> It is important to specify -g on the command line to allow NTP to correct
> the clock on boot. However, if Restart=yes is set, a malicious (or broken)
> server could send the incorrect time, trip the panic threshold, and when
> ntpd restarts, serve it the incorrect time (which would be accepted
Nice. Thanks.
You don't need the RTC. You can get the initial time over the net.
> - (if I understand properly) pps-client takes a pair of GPIO pins and
> calibrates latency, so its PPS adjustment is more accurate.
Any numbers?
I've thought of doing something like
sleep until a bit after
devel@ntpsec.org said:
> - pps-client installed as expected. One gets the Stretch source and
> compiles the kernel as part of that.
It would be interesting to poke around in pps-client to see what it actually
does.
There are two ways to use PPS. One is to to capture the data and then feed
th
devel@ntpsec.org said:
>> You don't need the RTC. You can get the initial time over the net.
> But the time I can get from the DS3231 RTC after outages should have
> drifted in microseconds, or tens of or hundreds of. So very fast sync to
> TOS by pps-client once booted and GPS solution provided
Looks good, but I think that retaining some mention of orphan mode is
appropriate. Some distros shipped with local clock in their ntp.conf. I
think the idea was to do what orphan mode does better.
How about appending another paragraph:
If you find a localclock in the ntp.conf from your distr
/usr/local/bin/temp-log
/usr/local/bin/gps-log
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
> The cause of this issue is that the python libraries are stored in pylib/
> but installed (and referenced in the code) as ntp/. Previously this caused
> import problems that were solved when someone added code to create a
> symlink from ntp/ to pylib/ at the end of the build process.
That
> IMO, a config file is a lot more readable than a bunch of bloated compiler
> command lines. It would be even more so if it included comments. :-)
The -v output is a lot more readable since I removed the config file stuff
from the command line.
--
These are my opinions. I hate spam.
__
> More changes that improve the comprendibility of the build would be an
> excellent thing.
One thing we could do to help documentation would be to add the command line
args to waf configure as a comment to the top of config.h
--
These are my opinions. I hate spam.
___
> Should be simple to implement at the same time (that's what he said).
But at a foot per nanosecond for the speed of light, you have to get a pretty
long cable before it becomes significant.
--
Light is actually slower than that in coax, but 1 is an easy number to
remember and work with.
> The "uptime" variable is used to by snmp clients to do "count per time"
> calculations, and also to notice how long after boot that that that daemon
> started, or if its restarting. If you need to, insert into your subagent
> code when it first runs to grab the system clock value and store it,
> Should the HAVE_KERNEL_PLL conditional be abolished? Or. to put it
> equivalently, do we have any development targets that lack ntp_adjtime()/
> adjtimex()?
That symbol is not defined when I build on OpenBSD.
I'd be happy to clean up that area, but I think it is more complicated than
you ha
e...@thyrsus.com said:
> I'm aware. There's a separate HAVE_KERNEL_PPS that conditionalizes the code
> for the second case.
I can't find any references to HAVE_KERNEL_PPS
I assume you mean HAVE_PPSAPI which is only referenced by refclocks
-
I screwed up. There are actually 3 things t
>> First: capture pulse timing info.
>> Second: adjust "drift" on system clock
>> Third: in kernel PLL to adjust drift from PPS pulses
> It *is* clear enough that ntp_adjtime() is a prerequisite for any of the
> above three things to go on.
You need drift correction implemented in the kernel to
e...@thyrsus.com said:
> There are two reasons to try to get rid of HAVE_KERNEL_PLL. The public one
> is that it gets rid of the two-paths problem that sunk TESTFRAME. I might be
> able to bring that concept back and fully test-jig the ntpd code, which
> would be an extremely good thing.
I'd be
>From 693dd71a42fe037c4b3efda0b2876ed9bd91c8e2
Experimental removal of HAVE_KERNEL_PLL.
There might also be a subsidiary problem with STA_NANO as well.
STA_NANO is available on NetBSD and FreeBSD.
It's not available on OpenBSD.
--
These are my opinions. I hate spam.
I'd like to encourage everybody to use it when making "interesting" changes.
The idea is to at least try all the configuration options. It will catch
simple quirks before you do the push. (Better is to try it before you do the
commit so we avoid broken landing spots when doing a bisect.)
The
>> >> First: capture pulse timing info.
>> >> Second: adjust "drift" on system clock
>> >> Third: in kernel PLL to adjust drift from PPS pulses
> You need drift correction implemented in the kernel to get decent
>> timekeeping. ntp_adjtime is just the API.
> For the drift correction, yes. Am
devel@ntpsec.org said:
>> I'd like to encourage everybody to use it when making
> "interesting" changes.
> Mostly failed for me. See attached.
[93/93] Linking test-default/main/ntptime/ntptime
ntpd/ntp_config.c.3.o: In function `destroy_attr_val_fifo':
ntp_config.c:(.text+0x33): undefined refer
The direct mode of ntpq mrulist is broken.
The direct mode is a hack to print out the info as it is collected rather
than collecting everything then sorting the list and printing it out. The
idea is to avoid using lots of memory.
It's supposed to print out the MJD and seconds this day for the
days = int(last) / 86400
seconds = last - days*86400
I've kludged some printing.
days is a float, for example: 17504.9482755
is int/int supposed to result in an int or a float?
I expected it to be an int. This code used to work. Trying by hand, I get
an int...
--
T
g...@rellim.com said:
> Since I do not have NTP_DEBUG_LISTS defined, the extern is never pulled in.
> Not the first time thee DBUG stuff caused issues for me.
Look in include/ntp_lists.h
if DEBUG exists, it defines NTP_DEBUG_LISTS
and sets up a couple of list macros to call check_gen_fifo_consi
> There is a change in the way this is handled by Python between 2 and 3.
> You can force integer arithmetic with "//" like 3 // 2 which
> will result in 1.
Thanks. That's what I was looking for.
And here is the corresponding commit at the right time:
commit 9765c7ce597f0933f8b45fa627d195262be
> I can confirm that debug is being set.
This is pretty weird. I wonder where it is being set, and why it isn't also
set in the other modules.
> I don not see anything in there to turn on DEBUG.
> Is there a verbose option for waf to show the gcc commands it is running?
waf -v is verbose mode.
> I get exactly the same results. ???
> Then my build fails:
Just to make sure...
Any chance you have local edits doing something strange?
Can you try it on a fresh git clone?
Does gcc look in any environment variables?
Another possibility is something like:
grep "#define" . -r | grep DEBUG
Subject: ntpsec | Pipeline #14729097 has failed for master | 3c1cc3c8
From: GitLab
Commit: 3c1cc3c8 ( https://gitlab.com/NTPsec/ntpsec/commit/3c1cc3c8317faa48ce8
e5b8ef7909c16cb04deab )
Commit Message: Fix ntpq -c direct -c mrulist to output seconds...
Commit Author: Hal Murray
Removing build/
Several of our python modules don't import division from __future__
Maybe that's because they don't do any divides. I think it would be simpler
to always include division so we don't have to remember to see if we need to
add it every time we a chunk of code that does a divide.
[murray@hgm raw]
> +1. Do it.
Before or after the point release?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
> I try my build script first after clone, and option-tester.sh first after
> clone. I no longer see the issue. Weird...
Can you diff the directories?
Another possibility is that ccache got confused.
--
These are my opinions. I hate spam.
___
901 - 1000 of 1887 matches
Mail list logo
