dnsdist: Generate our packages with meson

[rgacogne]

Short description

This PR updates the build scripts to build our DNSdist >= 2.0 packages with meson instead of autotools. There are some rather big changes:

• meson sub-directories that are shared with the authoritative server are no longer symbolic links because the meson directory at the root of the repository is not available when meson runs, causing issues. I think we could go for a different approach and make the meson available to the Docker environment instead
• h2o support is removed from our packages
• some features could not be properly disabled when building with meson
• a recent enough version of meson is not available in most distributions, so I'm installing it from a release tarball. This is a bit messy to do without conflicting with the meson version packaged by the distribution itself
• recent versions of meson require a recent enough version of Python, so I had to upgrade Python as well but fortunately there is a recent enough version in each distribution we support

I have a remaining issue that I don't know how to fix. Currently we set the correct version of DNSdist in configure.ac via the set-configure-ac-version.sh script. Unfortunately doing so creates an uncommitted change that meson refuses to pick up (Repository has uncommitted changes that will not be included in the dist tarball). We can use --allow-dirty so that meson keeps running but the resulting tarball does not have the correct version set in configure.ac, unsurprisingly. @omoerbeek @eli-schwartz any idea how to handle this properly?

DO NOT MERGE THIS!

Checklist

I have:

• read the CONTRIBUTING.md document
• compiled this code
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• added or modified unit test(s)

[eli-schwartz]

I have a remaining issue that I don't know how to fix. Currently we set the correct version of DNSdist in configure.ac via the set-configure-ac-version.sh script. Unfortunately doing so creates an uncommitted change that meson refuses to pick up (Repository has uncommitted changes that will not be included in the dist tarball). We can use --allow-dirty so that meson keeps running but the resulting tarball does not have the correct version set in configure.ac, unsurprisingly. @omoerbeek @eli-schwartz any idea how to handle this properly?

Meson expects dist tarball changes to be applied to the "pure" sources in $MESON_DIST_ROOT when running meson.add_dist_script(), which is processed after snapshotting the current project tree into a temporary staging directory.

The snapshot is created via git archive which is why uncommitted changes aren't picked up (and also why it doesn't pick up builddir-debug/ or meson.build.bak / meson.build~ or __pycache__/ directories etc.). This is why meson is able to get away with not utilizing EXTRA_DIST = like Makefile.am requires.

[coveralls]

Pull Request Test Coverage Report for Build 13439962109

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• 38 unchanged lines in 7 files lost coverage.
• Overall coverage increased (+3.8%) to 64.5%

---

Files with Coverage Reduction	New Missed Lines	%
modules/gpgsqlbackend/gpgsqlbackend.cc	1	88.62%
pdns/backends/gsql/gsqlbackend.hh	1	97.71%
ext/json11/json11.cpp	2	62.72%
pdns/misc.cc	4	62.29%
pdns/recursordist/rec-tcpout.cc	6	50.79%
pdns/dnsdistdist/dnsdist-tcp.cc	8	75.82%
modules/lmdbbackend/lmdbbackend.cc	16	72.85%

Totals
Change from base Build 13433765276:	3.8%
Covered Lines:	127644
Relevant Lines:	166903

---

💛 - Coveralls

[rgacogne]

Thanks, Eli! I think I have something working now, test run in progress (will fail for el-7 and buster): https://github.com/rgacogne/pdns/actions/runs/13439966426

[omoerbeek]

Some thoughts:

• For auth a specific version of meson is installed through pip, see build-and-test-all.yml. I have no particular preference, but I dislike having multiple install methods used by various scripts. So we have to decide what methods suits us best and make sure we are consistently using that method.
• It is not clear to me why the scripts in the meson subdir should be copies instead of symlinks. meson dist makes sure symlinks end up into the dist tarball as files through meson-dist-script.sh . At which step of the package build process are the files needed but not available if you use symlinks in the meson subdir?
• The change in the tarball name is unexpected and probably unneeded. You can use meson dist --formats bztar to get a .tar.bz2 dist file. Adding: I tried this but is seems the meson version in alpine (1.6.1) used to create the dist file has no bztar support. So we might want start to use our own installed meson for this step as well.

[omoerbeek]

xz and zx ? but also see general comment wrt tarball name

[rgacogne]

Oops, that's indeed a typo. I'll fix for now, pending a decision on the actual tarball format.

[eli-schwartz]

The change in the tarball name is unexpected and probably unneeded. You can use meson dist --formats bztar to get a .tar.bz2 dist file. Adding: I tried this but is seems the meson version in alpine (1.6.1) used to create the dist file has no bztar support. So we might want start to use our own installed meson for this step as well.

Since meson 1.5.0, bztar has been a valid meson dist option: https://mesonbuild.com/Release-notes-for-1-5-0.html#support-for-bztar-in-meson-dist

CPython itself can be compiled without bzip2 support, although it seems odd to do so and most distributions should already have it in the base system...

[zeha]

Personally I'd welcome the tarballs changing to xz.

[rgacogne]

* For auth a specific version of meson is installed through `pip`, see `build-and-test-all.yml`. I have no particular preference, but I dislike having multiple install methods used by various scripts. So we have to decide what methods suits us best and make sure we are consistently using that method.

I agree we should unify the way we are installing meson. I went with the current approach of installing from a release tarball because it makes me feel more confident about reproducibility than using pip, which even with pinned versions seems to me to have more moving parts, but also because RPM-based distributions need the data/macros.meson file that did not seem to be installed via pip.

* It is not clear to me why the scripts in the meson subdir should be copies instead of symlinks. `meson dist` makes sure symlinks end up into the dist tarball as files through `meson-dist-script.sh `. At which step of the package build process are the files needed but not available if you use symlinks in the `meson` subdir?

It was initially needed because the Docker builder only included a partial view of the repository (pdns/dnsdistdist) so the symlinks were broken. Later in the process I realized that meson refuses to work on a partial view of the repository (rightfully claiming the repository is dirty) so I had to include the whole git repository in the Docker builder image anyway. I'll check whether I can revert the symlinks changes.

* The change in the tarball name is unexpected and probably unneeded. You can use `meson dist --formats bztar` to get a `.tar.bz2` dist file. Adding: I tried this but is seems the meson version in alpine (1.6.1) used to create the dist file has no bztar support. So we might want start to use our own installed meson for this step as well.

I personally would prefer to generate tar.xz archives rather than bz2 ones, and I would not mind keeping the alpine-provided meson for the dist step if possible, but I'll do what is needed if we prefer to keep tar.bz2 archives instead. @Habbie do you have a preference?