Libmaxmind does not provide any version macro for link time version.
Print at least runtime version library used, if linked.
(cherry picked from commit e6d7384c0d)
Since Fedora 31 is the current Fedora release, replace Fedora 30 GitLab
CI jobs with their up-to-date counterparts.
(cherry picked from commit b36f5496237f0dbb84d7541140e87d7da475cd36)
Add a GitLab CI job (which is run only if all other jobs in a pipeline
succeed) that builds a BIND release tarball, i.e. fetches the source
tarball from the tarball building job, creates Windows zips, puts
certain parts of BIND documentation into the appropriate places, and
packs it all up into a single tarball whose contents can be subsequently
signed and published.
(cherry picked from commit 5a4a6b5e91)
Add a system test job for binaries created by Visual Studio in the
"Debug" build configuration to GitLab CI so that they can be tested
along their "Release" counterparts when necessary.
(cherry picked from commit 2b1c8c54d1)
Add a Visual Studio build job using the "Debug" build configuration to
GitLab CI without enabling it for every pipeline as it takes about twice
as long to complete as its "Release" counterpart.
(cherry picked from commit 12564928a7)
Add a set of jobs to GitLab CI that create a BIND source tarball and
then build and test its contents. Run those extra jobs only when a tag
is pushed to the Git repository as they are only meant to be sanity
checks of BIND source tarball contents.
(cherry picked from commit 8d56749046)
The util/prepare-softhsm2.sh script is useful for initializing a working
SoftHSM environment which can be used by unit tests and system tests.
However, since it is a test-specific script, it does not really belong
in the util/ subdirectory which is mostly pruned during the BIND source
tarball creation process. Move the prepare-softhsm2.sh script to
bin/tests/ so that its location is more appropriate for its purpose and
also so that it does not get removed during the BIND source tarball
creation process, allowing it to be used for setting up test
environments for tarball-based builds.
(cherry picked from commit c0be772ebc)
Convert the logic (currently present in the form of "rm -rf" calls in
util/kit.sh) for removing files and directories which are tracked by Git
but redundant in release tarballs into a set of .gitattributes rules
which allow the same effect to be achieved using "git archive".
(cherry picked from commit 925ecb0aae)
In bin/tests/system/conf.sh.win32, the "lwresd" system test is
erroneously listed both in SEQUENTIALDIRS and PARALLELDIRS. Keep it
only in the former to prevent GitLab CI pipelines from consistently
failing on Windows due to SUBDIRS containing a different number of tests
than found in bin/tests/system/systests.output.
The autosign test has a test case where a DNSSEC maintaiend zone
has a set of DNSSEC keys without any timing metadata set. It
tests if named picks up the key for publication and signing if a
delayed dnssec-settime/loadkeys event has occured.
The test failed intermittently despite the fact it sleeps for 5
seconds but the triggered key reconfigure action should happen after
3 seconds.
However, the test output showed that the test query came in before
the key reconfigure action was complete (see excerpts below).
The loadkeys command is received:
15:38:36 received control channel command 'loadkeys delay.example.'
The reconfiguring zone keys action is triggered after 3 seconds:
15:38:39 zone delay.example/IN: reconfiguring zone keys
15:38:39 DNSKEY delay.example/NSEC3RSASHA1/7484 (ZSK) is now published
15:38:39 DNSKEY delay.example/NSEC3RSASHA1/7455 (KSK) is now published
15:38:39 writing to journal
Two seconds later the test query comes in:
15:38:41 client @0x7f1b8c0562b0 10.53.0.1#44177: query
15:38:41 client @0x7f1b8c0562b0 10.53.0.1#44177: endrequest
And 6 more seconds later the reconfigure keys action is complete:
15:38:47 zone delay.example/IN: next key event: 05-Dec-2019 15:48:39
This commit fixes the test by checking the "next key event" log has
been seen before executing the test query, making sure that the
reconfigure keys action has been complete.
This commit however does not fix, nor explain why it took such a long
time (8 seconds) to reconfigure the keys.
(cherry picked from commit 2e4273b55a)
(cherry picked from commit fb0ddd5bfe)
When libidn2 2.3.0+ is used, the "idna" system test fails as dig does
not fail as expected any more due to libidn2 2.3.0 using Unicode 11.0.0
IDNA mapping tables [1] instead of Unicode 6.3.0 ones which were used
until libidn2 2.2.0. Specifically, the SOCKS character (🧦) used in the
invalid input U-label check in the "idna" system test is a valid IDNA
character as per the IDNA mapping tables for Unicode 11.0.0. Fix the
relevant checks by using a different character (🟥) which is an invalid
IDNA character for all versions of Unicode released to date.
[1] https://gitlab.com/libidn/libidn2/commit/5eaafda64e733bfe15f66c8a39fd9bc2753ba8f2
Mark Andrews
Ondřej SurýandMark Andrews
Petr MenšíkandMark Andrews
Evan Hunt
Tinderbox User
Michał KępieńandEvan Hunt
Michal Nowak
Matthijs Mekking