ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

Fix generated documentation

Browse Source
This commit is contained in:
Michal Nowak
2020-08-26 14:28:10 +00:00
parent 934c470b54
commit 5082d60105
5 changed files with 146 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files

91
CONTRIBUTING
View File

@@ -1,8 +1,8 @@
CONTRIBUTING
BIND Source Access and Contributor Guidelines
BIND 9 Source Access and Contributor Guidelines
Feb 22, 2018
May 28, 2020
Contents
@@ -12,35 +12,33 @@ Contents
Introduction
Thank you for using BIND!
Thank you for using BIND 9!
BIND is open source software that implements the Domain Name System (DNS)
protocols for the Internet. It is a reference implementation of those
protocols, but it is also production-grade software, suitable for use in
high-volume and high-reliability applications. It is by far the most
widely used DNS software, providing a robust and stable platform on top of
which organizations can build distributed computing systems with the
knowledge that those systems are fully compliant with published DNS
standards.
high-volume and high-reliability applications. It is very widely used DNS
software, providing a robust and stable platform on top of which
organizations can build distributed computing systems with the knowledge
that those systems are fully compliant with published DNS standards.
BIND is and will always remain free and openly available. It can be used
and modified in any way by anyone.
BIND is maintained by the Internet Systems Consortium, a public-benefit
501(c)(3) nonprofit, using a "managed open source" approach: anyone can
see the source, but only ISC employees have commit access. Until recently,
the source could only be seen once ISC had published a release: read
access to the source repository was restricted just as commit access was.
That's now changing, with the opening of a public git mirror to the BIND
source tree (see below).
BIND is maintained by Internet Systems Consortium, a public-benefit 501(c)
(3) nonprofit, using a "managed open source" approach: anyone can see the
source, but only ISC employees have commit access. In the past, the source
could only be seen once ISC had published a release; read access to the
source repository was restricted just as commit access was. That has
changed, as ISC now provides a public git mirror to the BIND source tree
(see below).
At Internet Systems Consortium, we're committed to building communities
that are welcoming and inclusive; environments where people are encouraged
to share ideas, treat each other with respect, and collaborate towards the
best solutions. To reinforce our commitment, the Internet Systems
Consortium has adopted the Contributor Covenant version 1.4 as our Code of
Conduct for BIND 9 project, as well as for the conduct of our developers
throughout the industry.
At ISC, we're committed to building communities that are welcoming and
inclusive: environments where people are encouraged to share ideas, treat
each other with respect, and collaborate towards the best solutions. To
reinforce our commitment, ISC has adopted a slightly modified version of
the Django Code of Conduct for the BIND 9 project, as well as for the
conduct of our developers throughout the industry.
Access to source code
@@ -67,8 +65,8 @@ branch, use:
$ git checkout v9_12
Whenever a branch is ready for publication, a tag will be placed of the
form v9_X_Y. The 9.12.0 release, for instance, is tagged as v9_12_0.
Whenever a branch is ready for publication, a tag is placed of the form
v9_X_Y. The 9.12.0 release, for instance, is tagged as v9_12_0.
The branch in which the next major release is being developed is called
master.
@@ -77,16 +75,16 @@ Reporting bugs
Reports of flaws in the BIND package, including software bugs, errors in
the documentation, missing files in the tarball, suggested changes or
requests for new features, etc, can be filed using https://gitlab.isc.org/
isc-projects/bind9/issues.
requests for new features, etc., can be filed using https://gitlab.isc.org
/isc-projects/bind9/issues.
Due to a large ticket backlog, we are sometimes slow to respond,
especially if a bug is cosmetic or if a feature request is vague or low in
priority, but we will try at least to acknowledge legitimate bug reports
within a week.
priority, but we try at least to acknowledge legitimate bug reports within
a week.
ISC's ticketing system is publicly readable; however, you must have an
account to file a new issue. You can either register locally or use
ISC's GitLab system is publicly readable; however, you must have an
account to create a new issue. You can either register locally or use
credentials from an existing account at GitHub, GitLab, Google, Twitter,
or Facebook.
@@ -104,19 +102,19 @@ list. ISC has a long history of handling reported vulnerabilities promptly
and effectively and we respect and acknowledge responsible reporters.
ISC's Security Vulnerability Disclosure Policy is documented at https://
kb.isc.org/article/AA-00861/0.
kb.isc.org/docs/aa-00861.
If you have a crash, you may want to consult ?What to do if your BIND or
DHCP server has crashed.?
If you have a crash, you may want to consult "What to do if your BIND or
DHCP server has crashed."
Contributing code
BIND is licensed under the Mozilla Public License 2.0. Earier versions
BIND is licensed under the Mozilla Public License 2.0. Earlier versions
(BIND 9.10 and earlier) were licensed under the ISC License
ISC does not require an explicit copyright assignment for patch
contributions. However, by submitting a patch to ISC, you implicitly
certify that you are the author of the code, that you intend to reliquish
certify that you are the author of the code, that you intend to relinquish
exclusive copyright, and that you grant permission to publish your work
under the open source license used for the BIND version(s) to which your
patch will be applied.
@@ -124,7 +122,7 @@ patch will be applied.
BIND code
Patches for BIND may be submitted directly via merge requests in ISC's
Gitlab source repository for BIND.
GitLab source repository for BIND.
Patches can also be submitted as diffs against a specific version of BIND
-- preferably the current top of the master branch. Diffs may be generated
@@ -133,9 +131,9 @@ using either git format-patch or git diff.
Those wanting to write code for BIND may be interested in the developer
information page, which includes information about BIND design and coding
practices, including discussion of internal APIs and overall system
architecture. (This is a work in progress, and still quite preliminary.)
architecture.
Every patch submitted will be reviewed by ISC engineers following our code
Every patch submitted is reviewed by ISC engineers following our code
review process before it is merged.
It may take considerable time to review patch submissions, especially if
@@ -170,27 +168,24 @@ All functional changes should be documented. There are three types of
documentation in the BIND source tree:
* Man pages are kept alongside the source code for the commands they
document, in files ending in .docbook; for example, the named man page
is bin/named/named.docbook.
* The BIND 9 Administrator Reference Manual is mostly in doc/arm/
Bv9ARM-book.xml, plus a few other XML files that are included in it.
document, in files ending in .rst: for example, the named man page is
bin/named/named.rst.
* The BIND 9 Administrator Reference Manual is in the .rst files in doc/
arm/; the PDF and HTML versions are automatically generated from the
.rst files.
* API documentation is in the header file describing the API, in
Doxygen-formatted comments.
It is not necessary to edit any documentation files other than these; all
PDF, HTML, and nroff-format man page files will be updated automatically
from the docbook and XML files after merging.
Patches to improve existing documentation are also very welcome!
Tests
BIND is a large and complex project. We rely heavily on continuous
automated testing and cannot merge new code without adequate test
coverage. Please see the 'Testing' section of doc/dev/dev.md for more
coverage. Please see the "Testing" section of doc/dev/dev.md for more
information.
Thanks
Thank you for your interest in contributing to the ongoing development of
BIND.
BIND 9.

6
PLATFORMS
View File

@@ -41,9 +41,9 @@ following systems:
* Ubuntu LTS 16.04, 20.04
* Fedora 32
* Red Hat Enterprise Linux / CentOS 7, 8
* FreeBSD 11.3, 12.1
* OpenBSD 6.6
* Alpine Linux
* FreeBSD 11.4, 12.1
* OpenBSD 6.7
* Alpine Linux 3.12
The amd64, i386, armhf and arm64 CPU architectures are all fully
supported.

2
README
View File

@@ -375,9 +375,7 @@ Acknowledgments
* This product includes software developed by the OpenSSL Project for
use in the OpenSSL Toolkit. http://www.OpenSSL.org/
* This product includes cryptographic software written by Eric Young
(eay@cryptsoft.com)
* This product includes software written by Tim Hudson
(tjh@cryptsoft.com)

99
configure vendored
View File

@@ -780,6 +780,8 @@ COVERAGE
CHECKDS
PYTHON
PERL
PANDOC
W3M
LN
ARFLAGS
XTARGETS
@@ -12477,6 +12479,103 @@ which ar resides, or set AR in the environment with the full path to ar.
;;
esac
#
# Look for w3m
#
for ac_prog in w3m
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
$as_echo_n "checking for $ac_word... " >&6; }
if ${ac_cv_path_W3M+:} false; then :
$as_echo_n "(cached) " >&6
else
case $W3M in
[\\/]* | ?:[\\/]*)
ac_cv_path_W3M="$W3M" # Let the user override the test with a path.
;;
*)
as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
for as_dir in $PATH
do
IFS=$as_save_IFS
test -z "$as_dir" && as_dir=.
for ac_exec_ext in '' $ac_executable_extensions; do
if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
ac_cv_path_W3M="$as_dir/$ac_word$ac_exec_ext"
$as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
break 2
fi
done
done
IFS=$as_save_IFS
;;
esac
fi
W3M=$ac_cv_path_W3M
if test -n "$W3M"; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $W3M" >&5
$as_echo "$W3M" >&6; }
else
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
$as_echo "no" >&6; }
fi
test -n "$W3M" && break
done
test -n "$W3M" || W3M="w3m"
#
# Look for pandoc
#
# Extract the first word of "pandoc", so it can be a program name with args.
set dummy pandoc; ac_word=$2
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
$as_echo_n "checking for $ac_word... " >&6; }
if ${ac_cv_path_PANDOC+:} false; then :
$as_echo_n "(cached) " >&6
else
case $PANDOC in
[\\/]* | ?:[\\/]*)
ac_cv_path_PANDOC="$PANDOC" # Let the user override the test with a path.
;;
*)
as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
for as_dir in $PATH
do
IFS=$as_save_IFS
test -z "$as_dir" && as_dir=.
for ac_exec_ext in '' $ac_executable_extensions; do
if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
ac_cv_path_PANDOC="$as_dir/$ac_word$ac_exec_ext"
$as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
break 2
fi
done
done
IFS=$as_save_IFS
test -z "$ac_cv_path_PANDOC" && ac_cv_path_PANDOC="pandoc"
;;
esac
fi
PANDOC=$ac_cv_path_PANDOC
if test -n "$PANDOC"; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $PANDOC" >&5
$as_echo "$PANDOC" >&6; }
else
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
$as_echo "no" >&6; }
fi
#
# Perl is optional; it is used only by some of the system test scripts.
# Note: the backtrace feature (see below) uses perl to build the symbol table,

2
doc/man/ddns-confgen.8in
View File

@@ -32,7 +32,7 @@ level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
..
.SH SYNOPSIS
.sp
\fBtsig\-keygen\fP [\fB\-a\fP algorithm] [\fB\-h\fP] [\fB\-r\fP randomfile] [\fB\-s\fP name]
\fBtsig\-keygen\fP [\fB\-a\fP algorithm] [\fB\-h\fP] [\fB\-r\fP randomfile] [name]
.sp
\fBddns\-confgen\fP [\fB\-a\fP algorithm] [\fB\-h\fP] [\fB\-k\fP keyname] [\fB\-q\fP] [\fB\-r\fP randomfile] [\fB\-s\fP name] [\fB\-z\fP zone]
.SH DESCRIPTION