I just pushed a big cleanup. Please test and don't be too surprised if
something breaks. I can't test with Solaris or Apple.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/
Old old systems just bumped the time in big steps on a timer interrupt.
Most modern OSes use something like the Intel TSC for timekeeping so the
clock ticks in nanosecond scale steps.
ntpd has a lot of ugly code to fuzz the clock. I don't really understand
that area. I think it makes sense i
> I have run tests removing the fuzz code. Never found any change with or
> without the clock fuzz. I was too scared to remove it.
It's scattered all over the place so I'm impressed if you really removed it
all.
The code that I was looking at in ntp_packetstamp had a run time test.
if
> That is worth filing a bug against BSD for.
They have confirmed that they know about it. (rather than I was confused)
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
devel@ntpsec.org said:
> If you are going to always #undef SO_BINTIME, why a few lines later test for
> it? Some left over test code?
Because I didn't know if SO_BINTIME for IPv6 was really broken on FreeBSD or
there was something simple I could do to make it work.
The #undef kludge made thin
Can anybody confirm that Solaris really doesn't have time stamps? I thought
we decided that all modern OSes did. That's why we could rip out the SIGIO
stuff.
I took a quick google and couldn't find any mention of anything that looked
like a time stamp in a Solaris man page for setsockopt. Bu
If you are looking at ntpq, it would be nice if there was a simple way to see
the packets sent/received and not much else.
A few of the packets have binary data. It may be as simple as only assoc IDs
are in binary. Everything else is raw ascii so it doesn't need any
complicated parsing or re
>> If Solaris doesn't support time stamps, I would expect
>> ntp_packetstamp to die on a #error. What happened with it?
> I factored the code so that if waf configure doesn't find a way to get
> packet arrival times from the UDP layer it uses the arrival time collected
> in userspace (ntp_packet
> Can you please look at issue #343? Your commit broke the Solaris build.
> https://gitlab.com/NTPsec/ntpsec/issues/342
I'll respond under the Re: USE_PACKET_TIMESTAMP thread.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@nt
Thanks for fixing this.
Can you verify that it works as well as builds?
> Newer versions of Solaris support SO_TIMESTAMP per:
> https://docs.oracle.com/cd/E19957-01/820-0724/gcoqs/index.html
That has a link to a setsockopt man page which says:
SunOS 5.11 Last Revised 21 Jan 2007
It doesn't sa
e...@thyrsus.com said:
> You're allowed to edit devel/TODO, Hal. :-). And in this case I think you
> should, rather than have med edit it into something that might inadvertently
> misrepresent what you're after.
OK. I've started adding things to devel/TODO
That doesn't solve the problem of mi
Nice. Thanks.
> restrict 10.169.0.0 mask 255.0.0.0
> restrict 10.169.0.0/8
Slightly strange example. I'd expect 10.0.0.0 mask 255.0.0.0 == 10.0.0.0/8
or 10.169.0.0 mask 255.255.0.0 == 10.169.0.0/16
Should that generate an error message?
--
These are my opinions. I hate spam.
___
I remove the SO_BINTIME mode. It's only supported by FreeBSD and they don't
support it for IPv6. They do support SO_TIMESTAMP.
The downside of that is reduced resolution on the time stamps. BINTIME gives
32 bit fractions of a second while TIMESTAMP gives microseconds (roughly 20
bits). We
Would somebody who understands this area please take a look and/or fix things
up.
It looks to me like etc and packaging are trying to do the same thing. Maybe
etc should be renamed to packaging/sample or something like that.
I think the contrib problem is only contrib/logrotate-ntpd vs
etc/l
Traceback (most recent call last):
File "/home/murray/ntpsec/play/.waf-1.9.7-fc95bab69065dbc43ddd71d4b69d0078/w
aflib/Task.py", line 145, in process
ret=self.run()
File "/home/murray/ntpsec/play/.waf-1.9.7-fc95bab69065dbc43ddd71d4b69d0078/w
aflib/Build.py", line 557, in run
fun(x.abspat
devel@ntpsec.org said:
> Since it's not in the git repo, I'm not sure what the best way would be to
> provide a verifiable change set.
It's off in a separate repository.
Look at https://gitlab.com/NTPsec/
--
These are my opinions. I hate spam.
___
There is one bug that I think should get fixed. I don't know the number.
ntpq fails too often on flaky links. I seem to be the only one who notices
it.
I assume it's something in the retransmission logic.
--
These are my opinions. I hate spam.
__
>> ntpq fails too often on flaky links. I seem to be the only one
>> who notices it.
>> I assume it's something in the retransmission logic.
> Are all these sentences describing one problem, or is there a
> bug *other* than failed retransmission on flaky links?
I'm not sure what you are asking.
> I was trying to verify that the bug number referred to
> the same problem as the rest of your text description.
I expect there is a bug matching what I described, but I'm not sure and I'm
not in a position to search or it.
--
These are my opinions. I hate spam.
___
One of the things we need to verify is that our code starts as fast as ntp
clsssic. I think they get going in 11 seconds. It's on their web someplace.
I don't know how to easily automate that. A hack to scan log files might
help.
This may be the tip of an iceberg, but I can't think of any ot
> I seem to recall that you were worried about your
> DNS-lookup changes slowing startup. Were you able to
> put that concern to rest?
I've assumed that any concerns about fast startup would avoid DNS.
We should compare new DNS, old DNS, and ntp classic with DNS.
--
These are my opinions. I h
> * I need to work on #348: reverse function for restrict
> * unpeer should be made to fully work from ntpq :config. This one is mine
> too.
There is a quirk tangled in this area. I don't know if there is a bug for it.
When the pool mode adds a server, if needed, it pokes a hole in the
restri
Should this work?
restrict default limited nomodify nopeer noquery
restrict 192.168.0.0 mask 255.255.0.0
restrict 127.0.0.1
ntpwait times out. It works when they are commented out.
I haven't investigated. I'm trying to catch up after a two week break. I'm
pretty sure it used to work bu
> Fair enough. I have an idea for a simple way to implement this. But I
> can't find where the hole-poking is actually being done - it's apparently
> not via a hack_restrict() call, which is what I'd have expected. Can you
> give me a file and line number?
ntp_proto.c, line 2480, in dns_take_
devel@ntpsec.org said:
> It is just possible that I broke restrict this morning at
> e7a4b0d3cf8932feeb898ed1343f25e8e65688d9 Address GitLab issue #356: reverse
> function for restrict
I reverted that fix and it's working again.
--
These are my opinions. I hate spam.
_
> The mistake I made was putting the new field first in the structure. This
> caused it to be randomly trashed by type-punning dynamic-allocation code
> that was expecting a link field there.
I don't understand yet. Why are we type punning there? If it's a hack to
avoid malloc, why is the cal
Background:
This isn't related to the bug, but often adds a layer of confusion when
trying to understand what is going on with DNS. The old ntpq -p had a few
lines of code that skipped some entries. I forget the details. I think it
skipped slots that hadn't received any responses yet.
I ma
I think it's important to split work on this into several areas.
The first is the simple no-DNS (and hence no-pool) case. This is the
important case.
How long does it take to get started when ntp.conf has 3 or 4 server slots
specified by IP Address? The interesting case is using iburst, but
> Maybe. On the other hand, Classic mode wouldn't actually buy them much. The
> only scripts a typical leaf-node installation runs come right out of the NTP
> source tree themselves, and ours do the right thing.
Would it be better if we changed that to a run time decision rather than
build time
I think I fixed the iburst startup problems.
I also added tests/time-startup.sh which is a script I used for timing. It
includes
export PYTHONPATH=/usr/local/lib/python2.7/site-packages
because that was the quickest way to get it working on my system.
Eric:
I don't understand the python fi
I've got a box sending bogus time, but the system seems to be running happily.
I assume there is some GPS rollover fixup code someplace, but I can't find
it. Anybody know where it is?
There are two likely places. On is in the HP driver itself,
ntpd/refclock_hpgps.c
The other is in ntpd/ntp_
> #55: ntpd refclock GPSD_JSON just stops working.
I haven't noticed any troubles.
> If any of you have an interest in saving this driver, step up now and fix
> it.
How important is supporting gpsd on systems without SHM?
I think we need the concept of stability to be associated with various
I know of 3 things that seem more important (to me) than anything on your
list.
The simple shared key crypto should support more than MD5 and SHA1.
ntpq still fails when talking over a lossy link. (There is a flake option in
restrict. We should see if that tickles the problem.)
ntpwait can'
[ 63/113] Compiling libntp/msyslog.c
In file included from /usr/include/python2.7/pyconfig.h:6:0,
from /usr/include/python2.7/Python.h:8,
from ../../libntp/pymodule.c:7:
/usr/include/python2.7/pyconfig-64.h:1199:0: warning: "_POSIX_C_SOURCE"
redefined
#define _PO
> See if it's e92a112b8.
It works after:
git checkout 98ed7cc3dbd9650168b10cf5bb3bc156c92a5476
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
You didn't say anything about anti-forgery.
In the long range, I think we will need a trusted organization to run and
manage enough servers to support the load, something along the lines of the
current DNS setup.
--
These are my opinions. I hate spam.
___
devel@ntpsec.org said:
> 4. Make NTS mandatory. In the NTPv5 packet format, the version, mode, NTS
> unique identifier, and (in client packets) NTS cookie come first in
> plaintext, then the whole rest of the packet is encrypted.
Is there a good high-level writeup of NTS?
Why encrypt stuff? (a
> What I don't understand is why the refclocks returning only 2-digit years
> ever worked at all. Does the sample-processing code simply ignore the
> century part of the year? If so, why is nmea supplying that?
Here is a comment in refclock_process_f
/*
* Compute the timecode
devel@ntpsec.org said:
> No? Well, I just did. Fsck...me...sideways! It's true. The reason all
> those old, busted Y2K-afflicted refclocks worked is that ntpd really does
> ignore the year part of clock timestamps.
The problem I'm interested in is not Y2K, it's GPS rollover. 1024 weeks is
How many of the NMEA devices have GPS rollover problems? (either now or soon)
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
>> How many of the NMEA devices have GPS rollover problems?
>> (either now or soon)
> It's impossible to tell. When a device will roll over is, because of the
> pivot-date trick, not a function of its hardware type but of its firmware
> release. --
Are there any known examples?
I have a coll
>> We could test fixup software by setting the system clock
>> ahead far enough to look like GPS had rolled over.
> What kind of fixup? I looked long and hard at this problem in the context
> of GPSD. I never found one that wasn't as bad - or worse - than relying on
> the sysrem clock date.
I
> Aha. With *that* I can reproduce these - don't get them with my normal
> invocation.
What was interesting about Gary's recipe that you didn't normally test?
Is there some option that we should add to tests/option-tester.sh?
Does anybody use it?
Is there a buildbot? Does it work? What OSe
> It's a good thing the Mac balked. There was a bug in the way I was passing
> out the computation result. Embarrassing.
Then how did it work at all on non-Mac systems?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.
[3/3] Compiling bob2/host/ntpd/ntp_parser.tab.c
In file included from ../../include/ntp.h:12:0,
from /home/murray/ntpsec/play/ntpd/ntp_parser.y:16:
../../include/ntp_fp.h: In function 'dtolfp':
../../include/ntp_fp.h:144:2: warning: implicit declaration of function
'ldexpl'
../../
devel@ntpsec.org said:
> ldexpl() is POSIX 2008 and ISO/IEC 9899:1999 (a.k.a. C99). =20
> Not supporting C99 is pretty lame. NTPsec specifically requires C99
> support.
> So clearly a NetBSD problem.
Thanks.
Looks like they tried but didn't get everything. The man page says:
The descri
>From issue simple mathematics (#381)
> The ntp codebase itself is not specific about what "query packets" are, but
> the processing for Mode 6 is right before that. I'd say odds are good that
> bad guys are shipping you Mode 6 packets hoping to crack something.
I've been thinking of tweaking th
[Using ldexp when ldexpl isn't available.]
> Serious loss of precision, but maybe the best we can do.
Does anybody have any data on how serious that would be?
Does ntp classic do anything interesting in this area? (That's the sort of
thing that Dave Mills is likely to have thought about.)
Did
> No, NTP doesn't do anything interesting here. The code predates the era
> whend long double was standardized and generally available, a transition
> that might have been as late as C99.
So it seems reasonable to assume that it's OK to run without the extra
precision.
The case I was worried
> Is NetBSD 6 still under development?If so, we can send them a bugreport.
Development has moved on to 7 and soon to be 8.
6 is still supported which means security fixes get backported.
--
These are my opinions. I hate spam.
___
devel ma
fallenpega...@gmail.com said:
> I know we've been removed most compatibility shims, but are they all gone?
> or do we still have a chunk of "if this OS, then define these missing
> functions"?
We have replacements for some non-POSIX string functions that are in many but
not all systems.
Ther
(I'll be out for the next day or so, so don't expect prompt answers. Sorry
this isn't cleaner. Gotta run.)
There may be bogus stuff in here. Measure twice, edit once.
I think the whole doubletime_t was a wild goose chase.
The claimed reason was precision. A double has 53 bits. We are inter
> All the fuss over long doubles has distracted folks from a more legitimate
> issue with NetBSD 6.1.5, which is that python-config returns a nonworking
> build setup for the C extension. But a workaround should be possible, and
> it's only in the build procedure, not the code.
Could you please
Can we get rid of it if very early in the startup sequence, we force the
system time to be at least the build time?
That is, if current time is less than build time, set the time to build time.
(no network involved)
--
These are my opinions. I hate spam.
>> In an earlier post, Mark stated that he preferred to keep NetBSD6 support
>> if possible because it's still recent enough to get security fixes. If
>> the same criterion is applied to OSX, then 10.10 and 10.11 should be
>> supported.
>I'm absolutely going to count you as a senior dev. So, you
Suppose we release some code. Assume it is bug free so users are happy.
How long do we expect it to run correctly?
Would we be happy with 67 years from the build date?
Do we know the limitations?
--
These are my opinions. I hate spam.
___
deve
>> Can we get rid of it if very early in the startup sequence, we force the
>> system time to be at least the build time?
> Ah, you're thinking of this as a way to get us into the right half of the
> next era after a wraparound?
I think it's a double win.
It gets rid of that ugly pivot code.
> The basic problem is that python2.7-config --ldflags includes "-lpython2.7"
> but no "-L" to say where to find it. On most platforms, a suitable "-L" is
> included.
I don't know anything about that area, but your "most platforms" seems
optimistic.
NetBSD 7.1 (GENERIC.201703111743Z)
-bash-4.
[Subject says NetBSD, but context has drifted to MacOS]
> That said, I'm going to push - not hard, not hill-to-die-on, just moderately
> - for remaining strict about our C99 conformance policy and culling old
> releases/minor platforms that can't meet it.
We aren't discussing C99 but rather the
> Nice idea, but prolly breaks some regression tests. Maybe for after 1.0?
Do we have any tests for that area?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
devel@ntpsec.org said:
> I think C99 was used here to to include the whole NTPsec policy of also
> wanting POSIX conformance. POSIX very much defines how the clock is played
> with.
POSIX defines ways to access the clock, but only the simple functions like
reading and setting the clock. It do
>> Suppose we release some code. Assume it is bug free so users are happy.
> You can drop that assumption without any change to the outcome.
I was thinking of roughly the following:
Suppose the code is good for 20 years after the build date. That covers GPS
rollover.
If we have a security fix
devel@ntpsec.org said:
> It's Feature Freeze Friday. The window closes at 5PM, so get your
> last-minute feature patches in now.
I think you should revert the long double change and wait until post-release
to clean up that area - not just the precision part but the whole clock
adjusting area.
I've got a case where top shows ntpd is using 60-70% of the CPU. I noticed
because the fan on the box is cycling on/off.
Has anybody seen anything like that recently?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.or
devel@ntpsec.org said:
> First thing to suspect on seeing that symptom, in ntpd or gpsd, is that
> somebody's tty layer is reacting badly to the unusual ways we use ioctls.
> I've seen this before multiple times.
Thanks. That's the hint I needed.
It's working normally after a reboot. I had do
devel@ntpsec.org said:
> Reverting it would be exacly the kind of poke-the-possible-hornet's-nest
> change that we should be avoiding.
That's the part I don't understand.
The new code didn't fix any real problem. It's only been running for a few
months. We have many years on the old code.
T
>> I think you should revert the long double change and wait until
>> post-release to clean up that area - not just the precision part but
>> the whole clock adjusting area.
> It fixed a bunch of issues and starting over could take weeks.
What problems did it fix?
Do you think we need more than
wscript says:
# XXX: needed for ntp_worker, for now
if ctx.env.DEST_OS == "openbsd":
ctx.define("PLATFORM_OPENBSD", "1", quote=False)
Also mentioned in ./devel/ifdex-ignores
It's not needed any more. Do you want to kill it now, or wait until post
release?
--
These are my opin
>> POSIX defines ways to access the clock, but only the simple functions like
>> reading and setting the clock. It doesn't cover how to slew the clock or
>> tweak the clock speed (drift) - things like ntp_adjtime or adjtime(x).
> That is correct, but not relevant to the discussion of whether to
> Why not build with all the refclocks? That is not a well tested way to
> configure NTPsec.
I regularly test/run with only the refclocks I plan to use.
I admit I haven't tested the SHM only case. If it doesn't work, we should
fix it.
> Nothing in ntpd.log of interest WRT shm/pps/gps
>> N
> Sure, test/run as you wish, but why not build them all?
No great reason. I got started that way ages ago.
It seems like a good idea for somebody to test the not-all case.
I think we should be able to build non-bloat systems, or at least
minimal-bloat. This seems like a good step in that dir
>> It seems like a good idea for somebody to test the not-all case.
> The all and not all case do get a lot of testing.
By "not all", I meant some but not all rather than none.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@nt
>> By "not all", I meant some but not all rather than none.
> Yes, I understood you, but all that does is lead to combintarorial excess.
It also reduces bloat.
All refclocks is close to double the file size. (I don't know how that
translates into actual memory usage after code gets loaded. str
Has anybody seen this before and/or is it working for you?
I tried again and got the same rejection.
Subject: [Rejected] Re: ntpsec | Confusion with drift at the rail (#44)
From: GitLab
Date: Tue, 19 Sep 2017 05:38:17 +
To: hmur...@megapathdsl.net
Unfortunately, your email message to GitLab
> Right now, if ntpd is brought up with no config file, it runs with no
> restrictions at all. Anyone can query it, anyone can configure it. This
> seems dubious from a security point of view.
Seems not-too-likely in the normal case since it won't keep good time.
Also seems possible in, say, a
>> Code in choice #1, and if its easy to do, with a big loud warning to stderr
>> and logerr that it's doing nothing.
> Can be done.
How about exiting after the loud warnings? That solves the open-door problem
if the admin is focused on some other problem.
--
These are my opinions. I hate
e...@thyrsus.com said:
> Yes, we could keep tinkering with stuff like this. But I think it's time to
> squash whaetever tracker issues we can, then stand away and *launch* the
> damn rocket.
You are the one who brought it up.
What would you have done if somebody we didn't know had filed a bug
> 0 192.168.1.22/32
> ntpport interface ignore
(and friends)
> I'm having trouble mapping that to my mental model of how restriction blocks
> work, which maked me nervous about modifying mearby code.
There is code that adds rules like that to keep ntpd from getting time from
i
Would it be interesting to hack the combination of ntpd and ntpq to show 0
values as 0 and tiny values at 0.000 or with a command line switch 0.9E-xx?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntp
Are there any systems where ntpsec is known to work and require cross
compiling?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
> I will audit them, but dropping this in the day before release doesn't just
> seem like asking for trouble, it seems like screaming WE WANT TO EMBARRASS
> OURSELVES.
Then put it on the known glitch list and fix it in 1.x
> And I would so regard it if this were ever required on Linux or FreeB
> but dropping this in the day before release
I was planning to make a scan through the documentation.
Is there anything else that you think would be a better use of my time?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@nt
The permissions on the stuff in ntpclients had the execute bit removed so
local testing doesn't work any more. I assume install fixes that since you
reported that ntpq worked.
In particular, tests/options-tester.sh says things like:
VERSION: ntpd ntpsec-0.9.7+1444 2017-09-26T09:54:52Z
VERSION:
> Following Fred's change, client tests now need to be run from build/main/
> ntpcllients rather than the source directory. I have pushed a change to
> tests/options-tester.sh that does this; please verify.
Did you actually test your version? It didn't work for me. I just pushed a
fix.
Testi
Our libraries currently get installed in places like:
/usr/local/lib/python2.7/site-packages/ntp/version.py
Should we be using ntpsec rather than ntp?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.n
hmur...@megapathdsl.net said:
> Testing Python code is broken. It's using the system libraries rather than
> the new/local libraries.
Author: Eric S. Raymond
Date: Tue Sep 26 13:59:10 2017 -0400
Restore accidentally removed creation of a magigic ntp/ link.
Fixed. Thanks.
--
These a
devel@ntpsec.org said:
>> BTW, all the tests fail on FreeBSD, due to an undefined
>> reference in jigs.py.
> Huh? If so, why has this not shown up in the results from the FreeBSD
> buildbot.
It works on my FreeBSD setup.
--
These are my opinions. I hate spam.
devel@ntpsec.org said:
> If that's also FreeBSD 10.3 and Python 2.7.13, then it must be something
> weird in my install, and nothing to worry about in general.
I've tested 10.3 and 11.0 on 64 bit Intel, 11.0 on 32 bit Intel, and 11.0 on
ARM (Pi, and BBB)
Your earlier message said:
FreeBSD Ma
> 1. python tests still not run by the build script
What do I type to run them? I have a handy script which is a good place for
things like that.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.
> Spend some time reading how Linus does his releases.
Got a suggested URL?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
> I'd like to hear from the senior devs (and anyone else with something
> intelligent to say!) on this.
You need a steering committee to represent the customers on things like this.
I didn't find enough info in the wiki page to enlighten me. I get the
general idea, but I don't know the tag t
I'm getting duplicates of issue-closed messages from gitlab.
I haven't checked to see if it's all of them, or just when you close
something, or just enough of them to attract my attention.
Are you doing anything interesting? Is anybody else getting them?
The last pair had dates that were 1 sec
devel@ntpsec.org said:
> That's right. What we can do, though, is win under the following
> assumption: if /usr/lib/X/Y/ is in sys.path, so is /usr/local/lib/X/Y/.
> Look at this from my system:
Bad assumption, at least on Fedora:
Python 2.7.13 (default, Sep 5 2017, 08:53:59)
[GCC 7.1.1 2017
> Once again, I think pip has the answer: edit the sys.path.
Why is editing sys.path better than using PYTHONPATH?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
> 2.3) Add code to the programs to augment sys.path prior to the import. This
> would need to be in all the programs; common code in a library would suffer
> from a chicken-and-egg problem.
The step that copies python code over to $build/main/... could do minor
edits. There would be only one co
>> What are the plans for splitting out the python stuff? Do most distros
>> include Python in their basic package?
> Python is effectively universal at this point.
My notes for setting up NetBSD and FreeBSD and OpenBSD include installing
python. (and setting up some links which may or may no
Should we test buildprep? I think that means setting up a clean minimal
system for each distro we claim to support. Maybe we should document what we
setup - the ISO used to make the CD/Thumb-drive and any options selected if
there was a choice.
Can we build the binaries and install them on a
I have 2 devices with GPS wrap around glitches.
One is a HP/Lucent box. It gets the date from the text string. Fudging
works.
The other is NMEA. It gets the right time and the current date, ignoring the
date in the text.
58027 27891.670 127.127.20.0 $GPZDA,074452,15,02,1998,+00,00 384 64 0
devel@ntpsec.org said:
> There's magic code in the NMEA driver that computes the year from other dare
> components based on some calendrical trick I don't understand. A comment
> notes that it will fail in 2399.
> Under consideration for 1.0, once I *do* undertstand it: making all refclock
> driv
>>> There's magic code in the NMEA driver
>> Maybe we should have a flag..
> I'm opposed to adding flags until an actual need is demonstrated. If we're
> going to add test and documentation complexity, it should be because we know
> we have to do it.
I agree with the philosophy, but I'll withho
801 - 900 of 1887 matches
Mail list logo
