GitLab

this is ongoing, with many TODO cases.

this fix is necessary for ddns to make responses correctly.

it's necessary for making distcheck pass on macos.

adopted denied as it was used in BIND 9's log message.

Compiling perfdhcp.c code with C++ compiler causes errors on various
platforms. Perfdhcp.c is now being refactored to C++ and will be soon removed
anyway.

This fixes the logging placeholders in messages to really match what is logged.

now its python test relies on isc python modules we need this workaround
for MacOS X.  This fix solves recent buildbot failures on macmini.
okayed on jabber

  - Compilation fix for FreeBSD

This fix is trivial, so directly committing without review.

At least for some logging. This eliminates having more real parameters
than placeholders for the used messages. Other occurrences of the
function are preserved, as the corresponding messages have full set of
placeholders.

- refactored duplicate code
- updated docstrings

Remove a duplicated line in commandOptions::reset() and corrected
header comments in initClientsNum().

This is the guide update to mention the listen_on workaround for multi-homed
hosts.

We want to disable the logger if there was an exception while putting
the parameters in. While we can't detect all possible ones, we can
detect some and reduce some false positives of the strict log checker
and not output mangled messages.

When we enable the strict log checking and the excess placeholders check
triggers, we need to print the message to easily identify the message ID
with the problem.

The DATASRC_DATABASE_FINDNSEC3_COVER logging message was missing a
placeholder. Added.

As per review comment http://bind10.isc.org/ticket/1455#comment:15

This mode is useful for DDNS-type updates; it allows for additions and deletions to be done in any order (keeping track of them separately).
It does have some extra restrictions; SOA records must be the first deleted and the first added type, and may not occur later anymore (causes ValueError).

For now, I left this in python/isc/xfrin, even though it is not purely xfrin anymore. Should we move it to datasrc? or util?