BIND 10 master, updated. ae5693b89371208d5d5d8e884b52362f861c633f [master] lots of minor doc fixes in mes files
BIND 10 source code commits
bind10-changes at lists.isc.org
Thu Dec 27 22:39:15 UTC 2012
The branch, master has been updated
via ae5693b89371208d5d5d8e884b52362f861c633f (commit)
via 778e6009722520325aaa1efc98240fffc8f6b6d1 (commit)
via 59b176e95540aacd2b0f167cba350d7fa18771db (commit)
via b52e736b9e5079aedf5252f04d019a80292bfc41 (commit)
via 9b0a73f8a2523480f538747d579c940534ac5ac5 (commit)
from 1a0577f9f348a74eacc959e091756f0e7a71accb (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit ae5693b89371208d5d5d8e884b52362f861c633f
Author: Jeremy C. Reed <jreed at isc.org>
Date: Thu Dec 27 16:34:18 2012 -0600
[master] lots of minor doc fixes in mes files
misspellings or typos
spelled out "wg" so next spell check doesn't fail on it
periods at end of sentences (even for incomplete bullet items
to be consistent)
remove double words (the the, up up)
This was not reviewed, but is mostly minor changes.
Two items I was unclear about I confirmed on jabber.
commit 778e6009722520325aaa1efc98240fffc8f6b6d1
Author: Jeremy C. Reed <jreed at isc.org>
Date: Thu Dec 27 16:33:34 2012 -0600
[master] remove duplicated word in doxygen brief
parser parser
commit 59b176e95540aacd2b0f167cba350d7fa18771db
Author: Jeremy C. Reed <jreed at isc.org>
Date: Thu Dec 27 16:32:43 2012 -0600
[master] remove duplicated word
the the
commit b52e736b9e5079aedf5252f04d019a80292bfc41
Author: Jeremy C. Reed <jreed at isc.org>
Date: Thu Dec 27 16:31:21 2012 -0600
[master] remove duplicated words
the the
for for
commit 9b0a73f8a2523480f538747d579c940534ac5ac5
Author: Jeremy C. Reed <jreed at isc.org>
Date: Thu Dec 27 16:29:02 2012 -0600
[master] rename DATASRC_DATABASE_JOURNALREADR_BADDATA message id
to DATASRC_DATABASE_JOURNALREADER_BADDATA
Okayed by jinmei via jabber.
This is to be consistent with the other
DATASRC_DATABASE_JOURNALREADER_* message IDs.
Also while here some minor edits to messages file:
fix typo (was repeated word)
fix misspelling typo
period at end of sentence
-----------------------------------------------------------------------
Summary of changes:
doc/guide/bind10-guide.xml | 4 ++--
src/bin/auth/auth_messages.mes | 8 ++++----
src/bin/bind10/bind10_messages.mes | 4 ++--
src/bin/dbutil/dbutil_messages.mes | 6 +++---
src/bin/dhcp4/dhcp4_messages.mes | 2 +-
src/bin/dhcp6/dhcp6_messages.mes | 4 ++--
src/bin/loadzone/b10-loadzone.xml | 2 +-
src/bin/xfrin/xfrin_messages.mes | 12 ++++++------
src/bin/xfrout/xfrout_messages.mes | 6 +++---
src/lib/datasrc/database.cc | 2 +-
src/lib/datasrc/datasrc_messages.mes | 8 ++++----
src/lib/dns/rdata.h | 2 +-
src/lib/log/log_messages.mes | 4 ++--
src/lib/python/isc/ddns/libddns_messages.mes | 2 +-
src/lib/resolve/resolve_messages.mes | 6 +++---
src/lib/server_common/server_common_messages.mes | 4 ++--
16 files changed, 38 insertions(+), 38 deletions(-)
-----------------------------------------------------------------------
diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml
index 0d8bb0b..23756b4 100644
--- a/doc/guide/bind10-guide.xml
+++ b/doc/guide/bind10-guide.xml
@@ -3871,7 +3871,7 @@ Dhcp6/subnet6 [] list (default)</screen>
<section id="dhcp6-limit">
<title>DHCPv6 Server Limitations</title>
<para> These are the current limitations and known problems
- with the the DHCPv6 server
+ with the DHCPv6 server
software. Most of them are reflections of the early stage of
development and should be treated as <quote>not implemented
yet</quote>, rather than actual limitations.</para>
@@ -4156,7 +4156,7 @@ specify module-wide logging and see what appears...
If there are multiple logger specifications in the
configuration that might match a particular logger, the
specification with the more specific logger name takes
- precedence. For example, if there are entries for for
+ precedence. For example, if there are entries for
both <quote>*</quote> and <quote>Resolver</quote>, the
resolver module — and all libraries it uses —
will log messages according to the configuration in the
diff --git a/src/bin/auth/auth_messages.mes b/src/bin/auth/auth_messages.mes
index ac9ffb9..d93da51 100644
--- a/src/bin/auth/auth_messages.mes
+++ b/src/bin/auth/auth_messages.mes
@@ -141,7 +141,7 @@ The specific problem is printed in the log message.
The thread for maintaining data source clients has received a command to
reconfigure, and has now started this process.
-% AUTH_DATASRC_CLIENTS_BUILDER_RECONFIGURE_SUCCESS data source reconfiguration completed succesfully
+% AUTH_DATASRC_CLIENTS_BUILDER_RECONFIGURE_SUCCESS data source reconfiguration completed successfully
The thread for maintaining data source clients has finished reconfiguring
the data source clients, and is now running with the new configuration.
@@ -169,7 +169,7 @@ probably better to stop and restart it.
% AUTH_DATA_SOURCE data source database file: %1
This is a debug message produced by the authoritative server when it accesses a
-datebase data source, listing the file that is being accessed.
+database data source, listing the file that is being accessed.
% AUTH_DNS_SERVICES_CREATED DNS services created
This is a debug message indicating that the component that will handling
@@ -184,7 +184,7 @@ reason for the failure is given in the message.) The server will drop the
packet.
% AUTH_INVALID_STATISTICS_DATA invalid specification of statistics data specified
-An error was encountered when the authoritiative server specified
+An error was encountered when the authoritative server specified
statistics data which is invalid for the auth specification file.
% AUTH_LOAD_TSIG loading TSIG keys
@@ -208,7 +208,7 @@ requests to b10-ddns) to handle it, but it failed. The authoritative
server returns SERVFAIL to the client on behalf of the separate
process. The error could be configuration mismatch between b10-auth
and the recipient component, or it may be because the requests are
-coming too fast and the receipient process cannot keep up with the
+coming too fast and the recipient process cannot keep up with the
rate, or some system level failure. In either case this means the
BIND 10 system is not working as expected, so the administrator should
look into the cause and address the issue. The log message includes
diff --git a/src/bin/bind10/bind10_messages.mes b/src/bin/bind10/bind10_messages.mes
index aba8da5..36a4422 100644
--- a/src/bin/bind10/bind10_messages.mes
+++ b/src/bin/bind10/bind10_messages.mes
@@ -154,7 +154,7 @@ The boss module received the given signal.
% BIND10_RESTART_COMPONENT_SKIPPED Skipped restarting a component %1
The boss module tried to restart a component after it failed (crashed)
unexpectedly, but the boss then found that the component had been removed
-from its local configuration of components to run. This is an unusal
+from its local configuration of components to run. This is an unusual
situation but can happen if the administrator removes the component from
the configuration after the component's crash and before the restart time.
The boss module simply skipped restarting that module, and the whole system
@@ -262,7 +262,7 @@ indicated OS API function with given error.
The boss forwards a request for a socket to the socket creator.
% BIND10_STARTED_CC started configuration/command session
-Debug message given when BIND 10 has successfull started the object that
+Debug message given when BIND 10 has successfully started the object that
handles configuration and commands.
% BIND10_STARTED_PROCESS started %1
diff --git a/src/bin/dbutil/dbutil_messages.mes b/src/bin/dbutil/dbutil_messages.mes
index 90ede92..2fbd000 100644
--- a/src/bin/dbutil/dbutil_messages.mes
+++ b/src/bin/dbutil/dbutil_messages.mes
@@ -53,7 +53,7 @@ inconsistent state, and it is advised to restore it from the backup that was
created when b10-dbutil started.
% DBUTIL_EXECUTE Executing SQL statement: %1
-Debug message; the given SQL statement is executed
+Debug message; the given SQL statement is executed.
% DBUTIL_FILE Database file: %1
The database file that is being checked.
@@ -67,7 +67,7 @@ The given database statement failed to execute. The error is shown in the
message.
% DBUTIL_TOO_MANY_ARGUMENTS too many arguments to the command, maximum of one expected
-There were too many command-line arguments to b10-dbutil
+There were too many command-line arguments to b10-dbutil.
% DBUTIL_UPGRADE_CANCELED upgrade canceled; database has not been changed
The user aborted the upgrade, and b10-dbutil will now exit.
@@ -95,7 +95,7 @@ again.
% DBUTIL_UPGRADE_PREPARATION_FAILED upgrade preparation failed: %1
An unexpected error occurred while b10-dbutil was preparing to upgrade the
-database schema. The error is shown in the message
+database schema. The error is shown in the message.
% DBUTIL_UPGRADE_SUCCESFUL database upgrade successfully completed
The database schema update was completed successfully.
diff --git a/src/bin/dhcp4/dhcp4_messages.mes b/src/bin/dhcp4/dhcp4_messages.mes
index c7bfeae..8724f8d 100644
--- a/src/bin/dhcp4/dhcp4_messages.mes
+++ b/src/bin/dhcp4/dhcp4_messages.mes
@@ -75,7 +75,7 @@ may well be a valid DHCP packet, just a type not expected by the server
% DHCP4_PACKET_RECEIVE_FAIL error on attempt to receive packet: %1
The IPv4 DHCP server tried to receive a packet but an error
-occured during this attempt. The reason for the error is included in
+occurred during this attempt. The reason for the error is included in
the message.
% DHCP4_PACKET_SEND_FAIL failed to send DHCPv4 packet: %1
diff --git a/src/bin/dhcp6/dhcp6_messages.mes b/src/bin/dhcp6/dhcp6_messages.mes
index 6ef8455..1bc9437 100644
--- a/src/bin/dhcp6/dhcp6_messages.mes
+++ b/src/bin/dhcp6/dhcp6_messages.mes
@@ -79,7 +79,7 @@ such failure. Each specific failure is logged in a separate log entry.
% DHCP6_LEASE_ALLOC lease %1 has been allocated (client duid=%2, iaid=%3)
This debug message indicates that the server successfully granted (in
response to client's REQUEST message) a lease. This is a normal behavior
-and incicates successful operation.
+and indicates successful operation.
% DHCP6_LEASE_ALLOC_FAIL failed to grant a lease for client duid=%1, iaid=%2
This message indicates that the server failed to grant (in response to
@@ -121,7 +121,7 @@ a received OFFER packet as UNKNOWN).
% DHCP6_PACKET_RECEIVE_FAIL error on attempt to receive packet: %1
The IPv6 DHCP server tried to receive a packet but an error
-occured during this attempt. The reason for the error is included in
+occurred during this attempt. The reason for the error is included in
the message.
% DHCP6_PACKET_SEND_FAIL failed to send DHCPv6 packet: %1
diff --git a/src/bin/loadzone/b10-loadzone.xml b/src/bin/loadzone/b10-loadzone.xml
index d181503..8c55f9b 100644
--- a/src/bin/loadzone/b10-loadzone.xml
+++ b/src/bin/loadzone/b10-loadzone.xml
@@ -67,7 +67,7 @@
<para>
Some control entries (aka directives) are supported.
- $ORIGIN is followed by a domain name, and sets the the origin
+ $ORIGIN is followed by a domain name, and sets the origin
that will be used for relative domain names in subsequent records.
$INCLUDE is followed by a filename to load.
The previous origin is restored after the file is included.
diff --git a/src/bin/xfrin/xfrin_messages.mes b/src/bin/xfrin/xfrin_messages.mes
index 837cafa..770a8b2 100644
--- a/src/bin/xfrin/xfrin_messages.mes
+++ b/src/bin/xfrin/xfrin_messages.mes
@@ -24,7 +24,7 @@ The serial fields of the first and last SOAs of AXFR (including AXFR-style
IXFR) are not the same. According to RFC 5936 these two SOAs must be the
"same" (not only for the serial), but it is still not clear what the
receiver should do if this condition does not hold. There was a discussion
-about this at the IETF dnsext wg:
+about this at the IETF dnsext working group:
http://www.ietf.org/mail-archive/web/dnsext/current/msg07908.html
and the general feeling seems that it would be better to reject the
transfer if a mismatch is detected. On the other hand, also as noted
@@ -61,10 +61,10 @@ There was an error opening a connection to the master. The error is
shown in the log message.
% XFRIN_GOT_INCREMENTAL_RESP got incremental response for %1
-In an attempt of IXFR processing, the begenning SOA of the first difference
+In an attempt of IXFR processing, the beginning SOA of the first difference
(following the initial SOA that specified the final SOA for all the
differences) was found. This means a connection for xfrin tried IXFR
-and really aot a response for incremental updates.
+and really got a response for incremental updates.
% XFRIN_GOT_NONINCREMENTAL_RESP got nonincremental response for %1
Non incremental transfer was detected at the "first data" of a transfer,
@@ -149,16 +149,16 @@ daemon will now shut down.
The AXFR transfer of the given zone was successful.
The provided information contains the following values:
-messages: Number of overhead DNS messages in the transfer
+messages: Number of overhead DNS messages in the transfer.
records: Number of Resource Records in the full transfer, excluding the
final SOA record that marks the end of the AXFR.
bytes: Full size of the transfer data on the wire.
-run time: Time (in seconds) the complete axfr took
+run time: Time (in seconds) the complete axfr took.
-bytes/second: Transfer speed
+bytes/second: Transfer speed.
% XFRIN_TSIG_KEY_NOT_FOUND TSIG key not found in key ring: %1
An attempt to start a transfer with TSIG was made, but the configured TSIG
diff --git a/src/bin/xfrout/xfrout_messages.mes b/src/bin/xfrout/xfrout_messages.mes
index 97b7a31..88e3e4c 100644
--- a/src/bin/xfrout/xfrout_messages.mes
+++ b/src/bin/xfrout/xfrout_messages.mes
@@ -70,7 +70,7 @@ AXFR-style IXFR.
% XFROUT_IXFR_NO_ZONE IXFR client %1, %2: zone not found with journal
The requested zone in IXFR was not found in the data source
-even though the xfrout daemon sucessfully found the SOA RR of the zone
+even though the xfrout daemon successfully found the SOA RR of the zone
in the data source. This can happen if the administrator removed the
zone from the data source within the small duration between these
operations, but it's more likely to be a bug or broken data source.
@@ -84,7 +84,7 @@ NOTAUTH.
An IXFR request was received, but the client's SOA version is the same as
or newer than that of the server. The xfrout server responds to the
request with the answer section being just one SOA of that version.
-Note: as of this wrting the 'newer version' cannot be identified due to
+Note: as of this writing the 'newer version' cannot be identified due to
the lack of support for the serial number arithmetic. This will soon
be implemented.
@@ -206,7 +206,7 @@ xfrout daemon process is still running. This xfrout daemon (the one
printing this message) will not start.
% XFROUT_XFR_TRANSFER_CHECK_ERROR %1 client %2: check for transfer of %3 failed: %4
-Pre-response check for an incomding XFR request failed unexpectedly.
+Pre-response check for an incoming XFR request failed unexpectedly.
The most likely cause of this is that some low level error in the data
source, but it may also be other general (more unlikely) errors such
as memory shortage. Some detail of the error is also included in the
diff --git a/src/lib/datasrc/database.cc b/src/lib/datasrc/database.cc
index d791fbc..f377ffe 100644
--- a/src/lib/datasrc/database.cc
+++ b/src/lib/datasrc/database.cc
@@ -1745,7 +1745,7 @@ public:
arg(zone_).arg(rrclass_).arg(accessor_->getDBName());
return (rrset);
} catch (const Exception& ex) {
- LOG_ERROR(logger, DATASRC_DATABASE_JOURNALREADR_BADDATA).
+ LOG_ERROR(logger, DATASRC_DATABASE_JOURNALREADER_BADDATA).
arg(zone_).arg(rrclass_).arg(accessor_->getDBName()).
arg(begin_).arg(end_).arg(ex.what());
isc_throw(DataSourceError, "Failed to create RRset from diff on "
diff --git a/src/lib/datasrc/datasrc_messages.mes b/src/lib/datasrc/datasrc_messages.mes
index e9b4c90..6983459 100644
--- a/src/lib/datasrc/datasrc_messages.mes
+++ b/src/lib/datasrc/datasrc_messages.mes
@@ -144,7 +144,7 @@ instead.
% DATASRC_DATABASE_FOUND_EMPTY_NONTERMINAL empty non-terminal %2 in %1
The domain name does not have any RRs associated with it, so it doesn't
exist in the database. However, it has a subdomain, so it does exist
-in the DNS address space. This type of domain is known an an "empty
+in the DNS address space. This type of domain is known as an "empty
non-terminal" and so we return NXRRSET instead of NXDOMAIN.
% DATASRC_DATABASE_FOUND_NXDOMAIN search in datasource %1 resulted in NXDOMAIN for %2/%3/%4
@@ -202,7 +202,7 @@ a zone's difference sequences from a database-based data source. The
zone's name and class, database name, and the start and end serials
are shown in the message.
-% DATASRC_DATABASE_JOURNALREADR_BADDATA failed to convert a diff to RRset in %1/%2 on %3 between %4 and %5: %6
+% DATASRC_DATABASE_JOURNALREADER_BADDATA failed to convert a diff to RRset in %1/%2 on %3 between %4 and %5: %6
This is an error message indicating that a zone's diff is broken and
the data source library failed to convert it to a valid RRset. The
most likely cause of this is that someone has manually modified the
@@ -287,7 +287,7 @@ matching the name. This is returned as the result of the search.
The given wildcard matches the name being sough but it as an empty
nonterminal (e.g. there's nothing at *.example.com but something like
subdomain.*.example.org, do exist: so *.example.org exists in the
-namespace but has no RRs assopciated with it). This will produce NXRRSET.
+namespace but has no RRs associated with it). This will produce NXRRSET.
% DATASRC_DATABASE_WILDCARD_MATCH search in datasource %1 resulted in wildcard match at %2 with RRset %3
The database doesn't contain directly matching name. When searching
@@ -490,7 +490,7 @@ destroyed.
% DATASRC_MEM_WILDCARD_CANCEL wildcard match canceled for '%1'
Debug information. A domain above wildcard was reached, but there's something
below the requested domain. Therefore the wildcard doesn't apply here. This
-behaviour is specified by RFC 1034, section 4.3.3
+behaviour is specified by RFC 1034, section 4.3.3.
% DATASRC_MEM_WILDCARD_DNAME DNAME record in wildcard domain '%1'
The software refuses to load DNAME records into a wildcard domain. It isn't
diff --git a/src/lib/dns/rdata.h b/src/lib/dns/rdata.h
index 4cd63cc..3fe0c74 100644
--- a/src/lib/dns/rdata.h
+++ b/src/lib/dns/rdata.h
@@ -60,7 +60,7 @@ public:
///
/// \brief A standard DNS module exception that is thrown if RDATA parser
-/// parser encounters a character-string (as defined in RFC1035) exceeding
+/// encounters a character-string (as defined in RFC1035) exceeding
/// the maximum allowable length (\c MAX_CHARSTRING_LEN).
///
class CharStringTooLong : public Exception {
diff --git a/src/lib/log/log_messages.mes b/src/lib/log/log_messages.mes
index f150f39..4bc8c98 100644
--- a/src/lib/log/log_messages.mes
+++ b/src/lib/log/log_messages.mes
@@ -97,7 +97,7 @@ There may be several reasons why this message may appear:
- The message ID has been mis-spelled in the local message file.
- The program outputting the message may not use that particular message
-(e.g. it originates in a module not used by the program.)
+(e.g. it originates in a module not used by the program).
- The local file was written for an earlier version of the BIND 10 software
and the later version no longer generates that message.
@@ -131,7 +131,7 @@ version of BIND 10.
% LOG_READING_LOCAL_FILE reading local message file %1
This is an informational message output by BIND 10 when it starts to read
a local message file. (A local message file may replace the text of
-one of more messages; the ID of the message will not be changed though.)
+one or more messages; the ID of the message will not be changed though.)
% LOG_READ_ERROR error reading from message file %1: %2
The specified error was encountered reading from the named message file.
diff --git a/src/lib/python/isc/ddns/libddns_messages.mes b/src/lib/python/isc/ddns/libddns_messages.mes
index 7e34e70..406151c 100644
--- a/src/lib/python/isc/ddns/libddns_messages.mes
+++ b/src/lib/python/isc/ddns/libddns_messages.mes
@@ -122,7 +122,7 @@ as the class in the Zone Section, ANY, or NONE.
A FORMERR response is sent back to the client.
% LIBDDNS_UPDATE_DATASRC_ERROR error in datasource during DDNS update: %1
-An error occured while committing the DDNS update changes to the
+An error occurred while committing the DDNS update changes to the
datasource. The specific error is printed. A SERVFAIL response is sent
back to the client.
diff --git a/src/lib/resolve/resolve_messages.mes b/src/lib/resolve/resolve_messages.mes
index 1df544a..6447082 100644
--- a/src/lib/resolve/resolve_messages.mes
+++ b/src/lib/resolve/resolve_messages.mes
@@ -86,7 +86,7 @@ SERVFAIL will be returned.
% RESLIB_NOTSINGLE_RESPONSE response to query for <%1> was not a response
A debug message, the response to the specified query from an upstream
-nameserver was a CNAME that had mutiple RRs in the RRset. This is
+nameserver was a CNAME that had multiple RRs in the RRset. This is
an invalid response according to the standards so a SERVFAIL will be
returned to the system making the original query.
@@ -138,7 +138,7 @@ A debug message, the response to the specified query indicated an error
that is not covered by a specific code path. A SERVFAIL will be returned.
% RESLIB_RECQ_CACHE_FIND found <%1> in the cache (resolve() instance %2)
-This is a debug message and indicates that a RecursiveQuery object found the
+This is a debug message and indicates that a RecursiveQuery object found
the specified <name, class, type> tuple in the cache. The instance number
at the end of the message indicates which of the two resolve() methods has
been called.
@@ -178,7 +178,7 @@ A debug message giving the round-trip time of the last query and response.
This is a debug message and indicates that a RunningQuery object found
the specified <name, class, type> tuple in the cache.
-% RESLIB_RUNQ_CACHE_LOOKUP looking up up <%1> in the cache
+% RESLIB_RUNQ_CACHE_LOOKUP looking up <%1> in the cache
This is a debug message and indicates that a RunningQuery object has made
a call to its doLookup() method to look up the specified <name, class, type>
tuple, the first action of which will be to examine the cache.
diff --git a/src/lib/server_common/server_common_messages.mes b/src/lib/server_common/server_common_messages.mes
index 0e4efa5..22ce0f3 100644
--- a/src/lib/server_common/server_common_messages.mes
+++ b/src/lib/server_common/server_common_messages.mes
@@ -17,11 +17,11 @@ $NAMESPACE isc::server_common
# \brief Messages for the server_common library
% SOCKETREQUESTOR_CREATED Socket requestor created for application %1
-Debug message. A socket requesor (client of the socket creator) is created
+Debug message. A socket requestor (client of the socket creator) is created
for the corresponding application. Normally this should happen at most
one time throughout the lifetime of the application.
-% SOCKETREQUESTOR_DESTROYED Socket requestor destoryed
+% SOCKETREQUESTOR_DESTROYED Socket requestor destroyed
Debug message. The socket requestor created at SOCKETREQUESTOR_CREATED
has been destroyed. This event is generally unexpected other than in
test cases.
More information about the bind10-changes
mailing list