[Git][NTPsec/ntpsec][master] 2 commits: Fix "the the" typos

Hal Murray gitlab at mg.gitlab.com
Mon Dec 7 06:12:03 UTC 2015 

Hal Murray pushed to branch master at NTPsec / ntpsec


Commits:
94dc3a1c by Hal Murray at 2015-12-06T22:02:00Z
Fix "the the" typos

Including in comments in code.

- - - - -
f723fcb4 by Hal Murray at 2015-12-06T22:09:50Z
Merge branch 'master' of gitlab.com:NTPsec/ntpsec

- - - - -


22 changed files:

- docs/autokey.txt
- docs/clock.txt
- docs/cluster.txt
- docs/confopt.txt
- docs/decode.txt
- docs/driver28.txt
- docs/miscopt.txt
- docs/oncore-shmem.txt
- docs/parsenew.txt
- docs/poll.txt
- docs/prefer.txt
- docs/stats.txt
- docs/xleave.txt
- include/ntp_net.h
- libisc/win32/interfaceiter.c
- ntpd/ntp_leapsec.c
- ntpd/ntp_leapsec.h
- ntpd/ntp_proto.c
- ntpd/refclock_arc.c
- ntpd/refclock_mx4200.c
- ntpd/refclock_oncore.c
- util/calc_tickadj/calc_tickadj.txt


Changes:

=====================================
docs/autokey.txt
=====================================
--- a/docs/autokey.txt
+++ b/docs/autokey.txt
@@ -91,7 +91,7 @@ produced by commercial services, utility programs in the OpenSSL
 software library, and the link:keygen.html[{ntpkeygen}] utility program
 in the NTP software distribution. A certificate includes the subject
 name of the client, the issuer name of the server, the public key of the
-client and the time period over which the the public and private keys
+client and the time period over which the public and private keys
 are valid. All Autokey hosts have a self-signed certificate with the
 Autokey name as both the subject and issuer. During the protocol,
 additional certificates are produced with the Autokey host name as
@@ -384,7 +384,7 @@ the filestamp suppressed. Thus, the nonencryted parameters file from
 each TA is copied to X with this name.
 
 To complete the configuration, the TH includes the client parameters
-file name in the +ident+ option of the the +server+ command for the TA
+file name in the +ident+ option of the +server+ command for the TA
 association
 
 +server 1.2.3.4 ident group,+
@@ -400,7 +400,7 @@ can be configured using more than one cryptotype combination, although
 not all combinations are interoperable. Note however that some
 cryptotype combinations may successfully intemperate with each other,
 but may not represent good security practice. The server and client
-cryptotypes are defined by the the following codes.
+cryptotypes are defined by the following codes.
 
 NONE::
   A client or server is type NONE if authentication is not available or


=====================================
docs/clock.txt
=====================================
--- a/docs/clock.txt
+++ b/docs/clock.txt
@@ -88,7 +88,7 @@ the TOY chip clock has drifted significantly from NTP time. This can
 cause a transient at system startup. In the past, this has produced a
 phase transient and resulted in a frequency surge that could take some
 time, even hours, to subside. When the highest accuracy is required,
-some means is necessary to manage the startup process so that the the
+some means is necessary to manage the startup process so that the
 clock is quickly set correctly and the frequency is undisturbed. The
 hold timer is used to suppress frequency adjustments during the training
 and startup intervals described below. At the beginning of the interval
@@ -141,7 +141,7 @@ Sync Interval::
 
 The state machine consists of five states. An event is created when an
 update is received by the discipline algorithm. Depending on the state
-and the the offset magnitude, the machine performs some actions and
+and the offset magnitude, the machine performs some actions and
 transitions to the same or another state. Following is a short
 description of the states.
 


=====================================
docs/cluster.txt
=====================================
--- a/docs/cluster.txt
+++ b/docs/cluster.txt
@@ -61,7 +61,7 @@ jitter dominates peer jitter,the algorithm prunes candidate 1. In (b),
 pruning additional candidates does not reduce select jitter, the
 algorithm terminates with candidates 2, 3 and 4 as survivors.
 
-The survivor list is passed on to the the mitigation algorithms, which
+The survivor list is passed on to the mitigation algorithms, which
 combine the survivors, select a system peer, and compute the system
 statistics passed on to dependent clients. Note the use of root distance
 λ as a weight factor at each round in the clock cluster algorithm. This


=====================================
docs/confopt.txt
=====================================
--- a/docs/confopt.txt
+++ b/docs/confopt.txt
@@ -72,7 +72,7 @@ include::includes/assoc-options.txt[]
 == Auxiliary Commands ==
 
 Information on authentication for broadcast, manycast, and
-manycat options can be found at link:authopt.html[Authentication Options].
+manycast options can be found at link:authopt.html[Authentication Options].
 
 include::includes/assoc-auxcommands.txt[]
 


=====================================
docs/decode.txt
=====================================
--- a/docs/decode.txt
+++ b/docs/decode.txt
@@ -139,7 +139,7 @@ of the +rv associd+ display produced by the +{ntpq}+ program.
 
 The Status Field displays the peer status code bits in hexadecimal; each
 bit is an independent flag. (Note this field is 5 bits wide, and
-combines with the the 3-bit-wide Select Field to create the first full
+combines with the 3-bit-wide Select Field to create the first full
 byte of the peer status word.) The meaning of each bit in the Status
 Field is listed in the following table:
 


=====================================
docs/driver28.txt
=====================================
--- a/docs/driver28.txt
+++ b/docs/driver28.txt
@@ -109,7 +109,7 @@ The 4th field is the number of second ticks since the last poll. The 5th
 field is the number of good data samples found. The last 64 will be used
 by _{ntpd}_. The 6th field is the number of sample that didn't have valid
 data ready. The 7th field is the number of bad samples. The 8th field is
-the number of times the the mode 1 info was update while _{ntpd}_ was
+the number of times the mode 1 info was update while _{ntpd}_ was
 trying to grab a sample.
 
 Here is a sample showing the GPS reception fading out:


=====================================
docs/miscopt.txt
=====================================
--- a/docs/miscopt.txt
+++ b/docs/miscopt.txt
@@ -23,7 +23,7 @@ include::includes/misc-options.txt[]
 // If you change this, be very sure to keep that synchronized.
 
 +tos+ [+beacon+ 'beacon' | +ceiling+ 'ceiling' | +cohort+ {+0+ | +1+} | +floor+ 'floor' | +maxclock+ 'maxclock' | +maxdist+ 'maxdist' | +minclock+ 'minclock' | +mindist+ 'mindist' | +minsane+ 'minsane' | +orphan+ 'stratum' | +orphanwait+ 'delay']::
-  This command alters certain system variables used by the the clock
+  This command alters certain system variables used by the clock
   selection and clustering algorithms. The default values of these
   variables have been carefully optimized for a wide range of network
   speeds and reliability expectations. Very rarely is it necessary to


=====================================
docs/oncore-shmem.txt
=====================================
--- a/docs/oncore-shmem.txt
+++ b/docs/oncore-shmem.txt
@@ -126,7 +126,7 @@ better accuracy. In 0D mode no position is calculated.
 
 When the SHMEM option is active, and if one of *Posn2D* or *Posn3D* is
 specified, one @@Ea record is hijacked each 15s, and the receiver is put
-back in 2D/3D mode so the the current location can be determined (for
+back in 2D/3D mode so the current location can be determined (for
 position determination, or for tracking SA). The timekeeping code is
 careful NOT to use the time associated with this (less accurate) 2D/3D
 tick in its timekeeping functions.


=====================================
docs/parsenew.txt
=====================================
--- a/docs/parsenew.txt
+++ b/docs/parsenew.txt
@@ -44,7 +44,7 @@ following values can be OR'ed together:
      PARSEB_POWERUP            no synchronisation - clock confused (must set then)
      PARSEB_NOSYNC             timecode currently not confirmed (must set then)
                                usually on reception error when there is still a
-                               chance the the generated time is still ok.
+                               chance the generated time is still ok.
 
      PARSEB_DST                DST in effect (informational only)
      PARSEB_UTC                timecode contains UTC time (informational only)


=====================================
docs/poll.txt
=====================================
--- a/docs/poll.txt
+++ b/docs/poll.txt
@@ -16,7 +16,7 @@ a jiggle counter, which is initially set to zero. When a clock update is
 received and the offset exceeds the clock jitter by a factor of 4, the
 jiggle counter is increased by the poll exponent; otherwise, it is
 decreased by twice the poll exponent. If the jiggle counter is greater
-than an arbitrary threshold of 30, it is reset to 0 and the the poll
+than an arbitrary threshold of 30, it is reset to 0 and the poll
 exponent is increased by 1. If the jiggle counter is less than -30, it
 is set to 0 and the poll exponent decreased by 1. In effect, the
 algorithm has a relatively slow reaction to good news, but a relatively


=====================================
docs/prefer.txt
=====================================
--- a/docs/prefer.txt
+++ b/docs/prefer.txt
@@ -183,7 +183,7 @@ prefer peer is among the survivors, the combine algorithm is not used.
 Instead, the offset and jitter of the prefer peer are used exclusively
 as the final values. In the common case involving a radio clock and a
 flock of remote backup servers, and with the radio clock designated a
-prefer peer, the the radio clock disciplines the system clock as long as
+prefer peer, the radio clock disciplines the system clock as long as
 the radio itself remains operational. However, if the radio fails or
 becomes a falseticker, the combined backup sources continue to
 discipline the system clock.


=====================================
docs/stats.txt
=====================================
--- a/docs/stats.txt
+++ b/docs/stats.txt
@@ -61,7 +61,7 @@ offset, delay and dispersion are called the sample statistics.
 
 [NOTE]
 In very fast networks where the client clock frequency is not
-within 1 PPM or so of the the server clock frequency, the roundtrip
+within 1 PPM or so of the server clock frequency, the roundtrip
 delay may have small negative values. This is usually a temporary
 condition when the client is first started. When using the roundtrip
 delay in calculations, negative values are assumed zero.


=====================================
docs/xleave.txt
=====================================
--- a/docs/xleave.txt
+++ b/docs/xleave.txt
@@ -25,7 +25,7 @@ In other words, we would like to replace the transmit softstamp with a
 drivestamp, but the problem is the transmit drivestamp is available only
 after the packet has been sent. A solution for this problem is the
 two-step or interleaved protocol described on this page and included in
-the the current reference implementation. In interleaved modes the
+the current reference implementation. In interleaved modes the
 transmit drivestamp for one packet is actually carried in the
 immediately following packet. The trick, however, is to implement the
 interleaved protocol without changing the NTP packet header format,


=====================================
include/ntp_net.h
=====================================
--- a/include/ntp_net.h
+++ b/include/ntp_net.h
@@ -211,7 +211,7 @@ typedef union {
 /*
  * Macro for checking for invalid addresses.  This is really, really
  * gross, but is needed so no one configures a host on net 127 now that
- * we're encouraging it the the configuration file.
+ * we're encouraging it the configuration file.
  */
 #define	LOOPBACKADR	0x7f000001
 #define	LOOPNETMASK	0xff000000


=====================================
libisc/win32/interfaceiter.c
=====================================
--- a/libisc/win32/interfaceiter.c
+++ b/libisc/win32/interfaceiter.c
@@ -81,7 +81,7 @@ static	PGETADAPTERSADDRESSES	pGAA;
 /* Common utility functions */
 
 /*
- * Windows always provides 255.255.255.255 as the the broadcast
+ * Windows always provides 255.255.255.255 as the broadcast
  * address.  ntpd needs to know the broadcast address which will target
  * only that network interface, not all.  Reconstruct it from the
  * address and mask.


=====================================
ntpd/ntp_leapsec.c
=====================================
--- a/ntpd/ntp_leapsec.c
+++ b/ntpd/ntp_leapsec.c
@@ -964,7 +964,7 @@ do_hash_data(
 		isc_sha1_update(mdctx, text, tlen);
 }
 
-/* given a reader and a reader arg, calculate and validate the the hash
+/* given a reader and a reader arg, calculate and validate the hash
  * signature of a NIST leap second file.
  */
 int


=====================================
ntpd/ntp_leapsec.h
=====================================
--- a/ntpd/ntp_leapsec.h
+++ b/ntpd/ntp_leapsec.h
@@ -77,7 +77,7 @@ extern bool leapsec_electric(electric_mode el);
  * 'tai_offs' is the CURRENT distance from clock (UTC) to TAI. Always valid.
  * 'tai_diff' is the change in TAI offset after the next leap
  *	transition. Zero if nothing is pending or too far ahead.
- * 'warped' is set only once, when the the leap second occurred between
+ * 'warped' is set only once, when the leap second occurred between
  *	two queries. Always zero in electric mode. If non-zero,
  *      immediately step the clock.
  * 'proximity' is a proximity warning. See definitions below. This is


=====================================
ntpd/ntp_proto.c
=====================================
--- a/ntpd/ntp_proto.c
+++ b/ntpd/ntp_proto.c
@@ -2391,7 +2391,7 @@ clock_filter(
 	peer->jitter = max(SQRT(peer->jitter), LOGTOD(sys_precision));
 
 	/*
-	 * If the the new sample and the current sample are both valid
+	 * If the new sample and the current sample are both valid
 	 * and the difference between their offsets exceeds CLOCK_SGATE
 	 * (3) times the jitter and the interval between them is less
 	 * than twice the host poll interval, consider the new sample


=====================================
ntpd/refclock_arc.c
=====================================
--- a/ntpd/refclock_arc.c
+++ b/ntpd/refclock_arc.c
@@ -152,7 +152,7 @@ GENERAL
 	significant.
 
      c) Note that the bit time of 3.3ms adds to the potential error in
-	the the clock timestamp, since the bit clock of the serial link
+	the clock timestamp, since the bit clock of the serial link
 	may effectively be free-running with respect to the host clock
 	and the MSF clock.  Actually, the error is probably 1/16th of
 	the above, since the input data is probably sampled at at least


=====================================
ntpd/refclock_mx4200.c
=====================================
--- a/ntpd/refclock_mx4200.c
+++ b/ntpd/refclock_mx4200.c
@@ -1064,7 +1064,7 @@ static int day1tab[] = {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
 static int day2tab[] = {31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
 
 /*
- * Calculate the the Julian Day
+ * Calculate the Julian Day
  */
 static int
 mx4200_jday(


=====================================
ntpd/refclock_oncore.c
=====================================
--- a/ntpd/refclock_oncore.c
+++ b/ntpd/refclock_oncore.c
@@ -420,7 +420,7 @@ struct	refclock refclock_oncore = {
 
 /*
  * Understanding the next bit here is not easy unless you have a manual
- * for the the various Oncore Models.
+ * for the various Oncore Models.
  */
 
 static struct msg_desc {


=====================================
util/calc_tickadj/calc_tickadj.txt
=====================================
--- a/util/calc_tickadj/calc_tickadj.txt
+++ b/util/calc_tickadj/calc_tickadj.txt
@@ -31,7 +31,7 @@ instead of slowing the clock down a little.
 If 'tick' on that box is 10,000,000 then by setting it to 9999779 the
 drift value will be somewhere around 0.0.
 
-_calc_tickadj_ tries to determine the the tick value by using the
+_calc_tickadj_ tries to determine the tick value by using the
 _tickadj_ program from the {project-shortname} package. If this
 doesn't work you can specify current tick manually on command line.
 



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/73f252f1a5e7e840d2a7f346d0a8e6191bb2a814...f723fcb4922d88591676743a0742bf16652a6cec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/vc/attachments/20151207/d722a13a/attachment.html>

More information about the vc mailing list