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

Merge branch 'remove-bind9-bugs-references' into 'v9_11'

Browse Source 
Update documentation to remove obsolete bind9-bugs@isc.org email address

See merge request isc-projects/bind9!111
This commit is contained in:
Evan Hunt
2018-03-08 10:40:14 -08:00
parent 63ddec2443 b02bf3b8a2
commit 3096be06d4
12 changed files with 478 additions and 86 deletions
Download Patch File Download Diff File Expand all files Collapse all files

186
CONTRIBUTING Normal file
View File

@@ -0,0 +1,186 @@
BIND Source Access and Contributor Guidelines
Feb 22, 2018
Contents
1. Access to source code
2. Reporting bugs
3. Contributing code
Introduction
Thank you for using BIND!
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.
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).
Access to source code
Public BIND releases are always available from the ISC FTP site.
A public-access GIT repository is also available at https://gitlab.isc.org
. This repository is a mirror, updated several times per day, of the
source repository maintained by ISC. It contains all the public release
branches; upcoming releases can be viewed in their current state at any
time. It does not contain development branches or unreviewed work in
progress. Commits which address security vulnerablilities are withheld
until after public disclosure.
You can browse the source online via https://gitlab.isc.org/isc-projects/
bind9
To clone the repository, use:
$ git clone https://gitlab.isc.org/isc-projects/bind9.git
Release branch names are of the form v9_X, where X represents the second
number in the BIND 9 version number. So, to check out the BIND 9.12
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.
The branch in which the next major release is being developed is called
master.
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.
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.
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
credentials from an existing account at GitHub, GitLab, Google, Twitter,
or Facebook.
Reporting possible security issues
If you think you may be seeing a potential security vulnerability in BIND
(for example, a crash with REQUIRE, INSIST, or ASSERT failure), please
report it immediately by emailing to security-officer@isc.org. Plain-text
e-mail is not a secure choice for communications concerning undisclosed
security issues so please encrypt your communications to us if possible,
using the ISC Security Officer public key.
Do not discuss undisclosed security vulnerabilites on any public mailing
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.
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 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
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.
BIND code
Patches for BIND may be submitted directly via merge requests in ISC's
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
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.)
Every patch submitted will be reviewed by ISC engineers following our code
review process before it is merged.
It may take considerable time to review patch submissions, especially if
they don't meet ISC style and quality guidelines. If a patch is a good
idea, we can and will do additional work to bring it up to par, but if
we're busy with other work, it may take us a long time to get to it.
To ensure your patch is acted on as promptly as possible, please:
* Try to adhere to the BIND 9 coding style.
* Run make check to ensure your change hasn't caused any functional
regressions.
* Document your work, both in the patch itself and in the accompanying
email.
* In patches that make non-trivial functional changes, include system
tests if possible; when introducing or substantially altering a
library API, include unit tests. See Testing for more information.
Changes to configure
If you need to make changes to configure, you should not edit it directly;
instead, edit configure.in, then run autoconf. Similarly, instead of
editing config.h.in directly, edit configure.in and run autoheader.
When submitting a patch as a diff, it's fine to omit the configure diffs
to save space. Just send the configure.in diffs and we'll generate the new
configure during the review process.
Documentation
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.
* 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
information.
Thanks
Thank you for your interest in contributing to the ongoing development of
BIND.

201
CONTRIBUTING.md Normal file
View File

@@ -0,0 +1,201 @@
<!--
- Copyright (C) Internet Systems Consortium, Inc. ("ISC")
-
- This Source Code Form is subject to the terms of the Mozilla Public
- License, v. 2.0. If a copy of the MPL was not distributed with this
- file, You can obtain one at http://mozilla.org/MPL/2.0/.
-
- See the COPYRIGHT file distributed with this work for additional
- information regarding copyright ownership.
-->
## BIND Source Access and Contributor Guidelines
*Feb 22, 2018*
### Contents
1. [Access to source code](#access)
1. [Reporting bugs](#bugs)
1. [Contributing code](#contrib)
### Introduction
Thank you for using BIND!
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.
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](https://www.isc.org),
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).
### <a name="access"></a>Access to source code
Public BIND releases are always available from the
[ISC FTP site](ftp://ftp.isc.org/isc/bind9).
A public-access GIT repository is also available at
[https://gitlab.isc.org](https://gitlab.isc.org).
This repository is a mirror, updated several times per day, of the
source repository maintained by ISC. It contains all the public release
branches; upcoming releases can be viewed in their current state at any
time. It does *not* contain development branches or unreviewed work in
progress. Commits which address security vulnerablilities are withheld
until after public disclosure.
You can browse the source online via
[https://gitlab.isc.org/isc-projects/bind9](https://gitlab.isc.org/isc-projects/bind9)
To clone the repository, use:
> $ git clone https://gitlab.isc.org/isc-projects/bind9.git
Release branch names are of the form `v9_X`, where X represents the second
number in the BIND 9 version number. So, to check out the BIND 9.12
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`.
The branch in which the next major release is being developed is called
`master`.
### <a name="bugs"></a>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](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.
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 credentials from an existing account at GitHub, GitLab, Google,
Twitter, or Facebook.
### Reporting possible security issues
If you think you may be seeing a potential security vulnerability in BIND
(for example, a crash with REQUIRE, INSIST, or ASSERT failure), please
report it immediately by emailing to security-officer@isc.org. Plain-text
e-mail is not a secure choice for communications concerning undisclosed
security issues so please encrypt your communications to us if possible,
using the [ISC Security Officer public key](https://www.isc.org/downloads/software-support-policy/openpgp-key/).
Do not discuss undisclosed security vulnerabilites on any public mailing 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](https://kb.isc.org/article/AA-00861/0).
If you have a crash, you may want to consult
[‘What to do if your BIND or DHCP server has crashed.’](https://kb.isc.org/article/AA-00340/89/What-to-do-if-your-BIND-or-DHCP-server-has-crashed.html)
### <a name="bugs"></a>Contributing code
BIND is licensed under the
[Mozilla Public License 2.0](http://www.isc.org/downloads/software-support-policy/isc-license/).
Earier versions (BIND 9.10 and earlier) were licensed under the [ISC License](http://www.isc.org/downloads/software-support-policy/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
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.
#### <a name="bind"></a>BIND code
Patches for BIND may be submitted directly via merge requests in
[ISC's Gitlab](https://gitlab.isc.org/isc-projects/bind9/) 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 using either `git format-patch` or `git diff`.
Those wanting to write code for BIND may be interested in the
[developer information](doc/dev/dev.md) 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.)
Every patch submitted will be reviewed by ISC engineers following our
[code review process](doc/dev/dev.md#reviews) before it is merged.
It may take considerable time to review patch submissions, especially if
they don't meet ISC style and quality guidelines. If a patch is a good
idea, we can and will do additional work to bring it up to par, but if
we're busy with other work, it may take us a long time to get to it.
To ensure your patch is acted on as promptly as possible, please:
* Try to adhere to the [BIND 9 coding style](doc/dev/style.md).
* Run `make` `check` to ensure your change hasn't caused any
functional regressions.
* Document your work, both in the patch itself and in the
accompanying email.
* In patches that make non-trivial functional changes, include system
tests if possible; when introducing or substantially altering a
library API, include unit tests. See [Testing](doc/dev/dev.md#testing)
for more information.
##### Changes to `configure`
If you need to make changes to `configure`, you should not edit it
directly; instead, edit `configure.in`, then run `autoconf`. Similarly,
instead of editing `config.h.in` directly, edit `configure.in` and run
`autoheader`.
When submitting a patch as a diff, it's fine to omit the `configure`
diffs to save space. Just send the `configure.in` diffs and we'll
generate the new `configure` during the review process.
##### Documentation
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.
* 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](doc/dev/dev.md#testing)
for more information.
#### Thanks
Thank you for your interest in contributing to the ongoing development
of BIND.

14
Makefile.in
View File

@@ -93,15 +93,23 @@ test-force:
README: README.md
${PANDOC} --email-obfuscation=none -s -t html README.md | \
${W3M} -dump -cols 75 -O ascii -T text/html > $@
${W3M} -dump -cols 75 -O ascii -T text/html | \
sed -e '$${/^$$/d;}' > $@
HISTORY: HISTORY.md
${PANDOC} --email-obfuscation=none -s -t html HISTORY.md | \
${W3M} -dump -cols 75 -O ascii -T text/html > $@
${W3M} -dump -cols 75 -O ascii -T text/html | \
sed -e '$${/^$$/d;}' > $@
OPTIONS: OPTIONS.md
${PANDOC} --email-obfuscation=none -s -t html OPTIONS.md | \
${W3M} -dump -cols 75 -O ascii -T text/html > $@
${W3M} -dump -cols 75 -O ascii -T text/html | \
sed -e '$${/^$$/d;}' > $@
CONTRIBUTING: CONTRIBUTING.md
${PANDOC} --email-obfuscation=none -s -t html CONTRIBUTING.md | \
${W3M} -dump -cols 75 -O ascii -T text/html | \
sed -e '$${/^$$/d;}' > $@
unit::
sh ${top_builddir}/unit/unittest.sh

41
README
View File

@@ -51,19 +51,21 @@ bind9/releasenotes
Reporting bugs and getting help
Please report assertion failure errors and suspected security issues to
security-officer@isc.org.
To report non-security-sensitive bugs or request new features, you may
open an Issue in the BIND 9 project on the ISC GitLab server at https://
gitlab.isc.org/isc-projects/bind9.
General bug reports can be sent to bind9-bugs@isc.org.
Please note that, unless you explicitly mark the newly created Issue as
"confidential", it will be publicly readable. Please do not include any
information in bug reports that you consider to be confidential unless the
issue has been marked as such. In particular, if submitting the contents
of your configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
named-checkconf -px.
Feature requests can be sent to bind-suggest@isc.org.
Please note that, while tickets submitted to ISC's ticketing system are
not initially publicly readable by default, they can be made publicly
acessible afterward. Please do not include information in bug reports that
you consider to be confidential. In particular, when sending the contents
of your configuration file, it is advisable to obscure key secrets: this
can be done automatically by using named-checkconf -px.
If the bug you are reporting is a potential security issue, such as an
assertion failure or other crash in named, please do NOT use GitLab to
report it. Instead, please send mail to security-officer@isc.org.
Professional support and training for BIND are available from ISC at
https://www.isc.org/support.
@@ -84,11 +86,17 @@ Information for BIND contributors can be found in the following files: -
General information: doc/dev/contrib.md - BIND 9 code style: doc/dev/
style.md - BIND architecture and developer guide: doc/dev/dev.md
Patches for BIND may be submitted either as Github pull requests or via
email. When submitting a patch via email, please prepend the subject
header with "[PATCH]" so it will be easier for us to find. If your patch
introduces a new feature in BIND, please submit it to bind-suggest@isc.org
; if it fixes a bug, please submit it to bind9-bugs@isc.org.
Patches for BIND may be submitted as Merge Requests in the ISC GitLab
server at at https://gitlab.isc.org/isc-projects/bind9/merge_requests.
By default, external contributors don't have ability to fork BIND in the
GitLab server, but if you wish to contribute code to BIND, you may request
permission to do so. Thereafter, you can create git branches and directly
submit requests that they be reviewed and merged.
If you prefer, you may also submit code by opening a GitLab Issue and
including your patch as an attachment, preferably generated by git
format-patch.
BIND 9.11 features
@@ -464,4 +472,3 @@ Acknowledgments
(eay@cryptsoft.com)
* This product includes software written by Tim Hudson
(tjh@cryptsoft.com)

50
README.md
View File

@@ -60,22 +60,24 @@ For up-to-date release notes and errata, see
### <a name="help"/> Reporting bugs and getting help
Please report assertion failure errors and suspected security issues to
To report non-security-sensitive bugs or request new features, you may
open an Issue in the BIND 9 project on the
[ISC GitLab server](https://gitlab.isc.org) at
[https://gitlab.isc.org/isc-projects/bind9](https://gitlab.isc.org/isc-projects/bind9).
Please note that, unless you explicitly mark the newly created Issue as
"confidential", it will be publicly readable. Please do not include any
information in bug reports that you consider to be confidential unless
the issue has been marked as such. In particular, if submitting the
contents of your configuration file in a non-confidential Issue, it is
advisable to obscure key secrets: this can be done automatically by
using `named-checkconf -px`.
If the bug you are reporting is a potential security issue, such as an
assertion failure or other crash in `named`, please do *NOT* use GitLab to
report it. Instead, please send mail to
[security-officer@isc.org](mailto:security-officer@isc.org).
General bug reports can be sent to
[bind9-bugs@isc.org](mailto:bind9-bugs@isc.org).
Feature requests can be sent to
[bind-suggest@isc.org](mailto:bind-suggest@isc.org).
Please note that, while tickets submitted to ISC's ticketing system
are not initially publicly readable by default, they can be made publicly
acessible afterward. Please do not include information in bug reports that
you consider to be confidential. In particular, when sending the contents of
your configuration file, it is advisable to obscure key secrets: this can
be done automatically by using `named-checkconf -px`.
Professional support and training for BIND are available from
ISC at [https://www.isc.org/support](https://www.isc.org/support).
@@ -96,12 +98,20 @@ Information for BIND contributors can be found in the following files:
- BIND 9 code style: [doc/dev/style.md](doc/dev/style.md)
- BIND architecture and developer guide: [doc/dev/dev.md](doc/dev/dev.md)
Patches for BIND may be submitted either as Github pull requests
or via email. When submitting a patch via email, please prepend the
subject header with "`[PATCH]`" so it will be easier for us to find.
If your patch introduces a new feature in BIND, please submit it to
[bind-suggest@isc.org](mailto:bind-suggest@isc.org); if it fixes a bug,
please submit it to [bind9-bugs@isc.org](mailto:bind9-bugs@isc.org).
Patches for BIND may be submitted as
[Merge Requests](https://gitlab.isc.org/isc-projects/bind9/merge_requests)
in the [ISC GitLab server](https://gitlab.isc.org) at
at [https://gitlab.isc.org/isc-projects/bind9/merge_requests](https://gitlab.isc.org/isc-projects/bind9/merge_requests).
By default, external contributors don't have ability to fork BIND in the
GitLab server, but if you wish to contribute code to BIND, you may request
permission to do so. Thereafter, you can create git branches and directly
submit requests that they be reviewed and merged.
If you prefer, you may also submit code by opening a
[GitLab Issue](https://gitlab.isc.org/isc-projects/bind9/issues) and
including your patch as an attachment, preferably generated by
`git format-patch`.
### <a name="features"/> BIND 9.11 features

2
acconfig.h
View File

@@ -6,8 +6,6 @@
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*/
/* $Id: acconfig.h,v 1.53 2008/12/01 23:47:44 tbox Exp $ */
/*! \file */
/***

2
bin/python/setup.py
View File

@@ -12,7 +12,7 @@ setup(name='isc',
description='Python functions to support BIND utilities',
url='https://www.isc.org/bind',
author='Internet Systems Consortium, Inc',
author_email='bind9-bugs@isc.org',
author_email='info@isc.org',
license='MPL',
requires=['ply'],
packages=['isc'])

7
config.h.in
View File

@@ -1,14 +1,15 @@
/* config.h.in. Generated from configure.in by autoheader. */
/*
* Copyright (C) 1999-2005, 2007, 2008, 2012, 2014, 2016 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) Internet Systems Consortium, Inc. ("ISC")
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*
* See the COPYRIGHT file distributed with this work for additional
* information regarding copyright ownership.
*/
/* $Id: acconfig.h,v 1.53 2008/12/01 23:47:44 tbox Exp $ */
/*! \file */
/***

53
configure vendored
View File

@@ -10,7 +10,7 @@
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.69 for BIND 9.11.
#
# Report bugs to <bind9-bugs@isc.org>.
# Report bugs to <info@isc.org>.
#
#
# Copyright (C) 1992-1996, 1998-2012 Free Software Foundation, Inc.
@@ -282,11 +282,10 @@ fi
$as_echo "$0: In particular, zsh $ZSH_VERSION has bugs and should"
$as_echo "$0: be upgraded to zsh 4.3.4 or later."
else
$as_echo "$0: Please tell bug-autoconf@gnu.org and bind9-bugs@isc.org
$0: about your system, including any error possibly output
$0: before this message. Then install a modern shell, or
$0: manually run the script under such a shell if you do
$0: have one."
$as_echo "$0: Please tell bug-autoconf@gnu.org and info@isc.org about
$0: your system, including any error possibly output before
$0: this message. Then install a modern shell, or manually
$0: run the script under such a shell if you do have one."
fi
exit 1
fi
@@ -600,7 +599,7 @@ PACKAGE_NAME='BIND'
PACKAGE_TARNAME='bind'
PACKAGE_VERSION='9.11'
PACKAGE_STRING='BIND 9.11'
PACKAGE_BUGREPORT='bind9-bugs@isc.org'
PACKAGE_BUGREPORT='info@isc.org'
PACKAGE_URL='https://www.isc.org/downloads/BIND/'
# Factoring default headers for most tests.
@@ -1847,7 +1846,7 @@ Help can also often be found on the BIND Users mailing list
(https://lists.isc.org/mailman/listinfo/bind-users) or in the #bind
channel of the Freenode IRC service.
Report bugs to <bind9-bugs@isc.org>.
Report bugs to <info@isc.org>.
BIND home page: <https://www.isc.org/downloads/BIND/>.
_ACEOF
ac_status=$?
@@ -2310,9 +2309,9 @@ $as_echo "$as_me: WARNING: $2: see the Autoconf documentation" >&2;}
$as_echo "$as_me: WARNING: $2: section \"Present But Cannot Be Compiled\"" >&2;}
{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: proceeding with the compiler's result" >&5
$as_echo "$as_me: WARNING: $2: proceeding with the compiler's result" >&2;}
( $as_echo "## --------------------------------- ##
## Report this to bind9-bugs@isc.org ##
## --------------------------------- ##"
( $as_echo "## --------------------------- ##
## Report this to info@isc.org ##
## --------------------------- ##"
) | sed "s/^/$as_me: WARNING: /" >&2
;;
esac
@@ -23109,23 +23108,11 @@ done
then
use_dlz_mysql=$d
mysql_include=$d/include/mysql
if test -d $d/lib/mysql
then
mysql_lib=$d/lib/mysql
else
mysql_lib=$d/lib
fi
break
elif test -f $d/include/mysql.h
then
use_dlz_mysql=$d
mysql_include=$d/include
if test -d $d/lib/mysql
then
mysql_lib=$d/lib/mysql
else
mysql_lib=$d/lib
fi
break
fi
done
@@ -23136,21 +23123,9 @@ then
if test -f $d/include/mysql/mysql.h
then
mysql_include=$d/include/mysql
if test -d $d/lib/mysql
then
mysql_lib=$d/lib/mysql
else
mysql_lib=$d/lib
fi
elif test -f $d/include/mysql.h
then
mysql_include=$d/include
if test -d $d/lib/mysql
then
mysql_lib=$d/lib/mysql
else
mysql_lib=$d/lib
fi
fi
fi
@@ -23190,6 +23165,12 @@ $as_echo "no" >&6; }
$as_echo "using mysql with libs ${mysql_lib} and includes ${mysql_include}" >&6; }
;;
*)
if test -d "$use_dlz_mysql/lib/mysql"
then
mysql_lib="$use_dlz_mysql/lib/mysql"
else
mysql_lib="$use_dlz_mysql/lib"
fi
CONTRIB_DLZ="$CONTRIB_DLZ -DDLZ_MYSQL"
for i in dlz_mysql_driver
@@ -24464,7 +24445,7 @@ $config_headers
Configuration commands:
$config_commands
Report bugs to <bind9-bugs@isc.org>.
Report bugs to <info@isc.org>.
BIND home page: <https://www.isc.org/downloads/BIND/>."
_ACEOF

2
configure.in
View File

@@ -9,7 +9,7 @@ AC_DIVERT_PUSH(1)dnl
esyscmd([sed -e 's/^/# /' -e '/Portions of this code/,$d' COPYRIGHT])dnl
AC_DIVERT_POP()dnl
AC_INIT(BIND, [9.11], [bind9-bugs@isc.org], [], [https://www.isc.org/downloads/BIND/])
AC_INIT(BIND, [9.11], [info@isc.org], [], [https://www.isc.org/downloads/BIND/])
AC_PREREQ(2.59)
AC_CONFIG_HEADER(config.h)

2
win32utils/build.txt
View File

@@ -274,4 +274,4 @@ Step 11: Python package install
BIND python tools should work with version 2 or 3, 32 or 64 bits.
Please report bugs, whether in the process of building the application
or in BIND 9 itself, to bind9-bugs@isc.org.
or in BIND 9 itself, at https://gitlab.isc.org/isc-projects/bind9.

4
win32utils/readme1st.txt
View File

@@ -163,5 +163,5 @@ server on the localhost.
PROBLEMS:
Please report bugs to bind9-bugs@isc.org. Other questions can go
to the bind-users@isc.org mailing list.
Please report bugs at https://gitlab.isc.org/isc-projects/bind9.
Other questions can go to the bind-users@isc.org mailing list.