This fixes config_tests on aarch64 macOS.
The key difference is that they use 16k pages,
so LMDB space usage also behaves a bit different.

That option isn't supported there, so the test wouldn't work.
Now the config tests work for me on x86 macOS.

Enums are more like ints anyway (in standard),
even when drawn from a small subset.

So far the message wasn't pointing to freebind at all:
[net   ] bind to '::1@53' (UDP): Operation not supported

I used preprocessor to avoid duplication and unused warnings.

Another way would be to ignore the freebind option if not supported,
but I think it's better to convince users not to specify it.

release 5.5.2

See merge request !1337

21.10 isn't supported anymore, which is probably why it's failing.

We've already done that on OBS side, which is probably why it's failing.

https://github.com/lunarmodules/luacov/issues/99

We're mostly using those in NEWS and first line of commit messages.
I'm not sure if they're much better than alternatives, but at least
consistency is nice.

This caused a huge increase in real memory usage in case of queries
arriving to kresd while being disconnected from internet.
The usage was slowly creeping up, even over 2G.

Interesting past commits: b350d38d and two preceding.

There apparently was no real memory leak.  I assume that reusal of
long-living mempools is risky in terms of memory fragmentation,
though the extent of the issue surprised me very much.
The issue seemed the same with normal glibc and jemalloc.

I generally dislike ad-hoc optimization attempts like these freelists.
Now the allocator can better decide *itself* how to reuse memory.

For long arrays we really want to increase their length by a fraction.
Otherwise it will cost lots of CPU.  Doubling seems customary,
though I could imagine e.g. keeping the +50% growth on longest arrays.

I finally got sufficiently angry with this piece of code when debugging
https://forum.turris.cz/t/how-to-debug-a-custom-hosts-file-for-kresd/17449
though in that case it wasn't the main source of inefficiency.

CI: two of the mysterious/bogus warnings around arrays disappeared.

Fixes #760

Oto Šťáva authored 2 years ago and Vladimír Čunát committed 2 years ago

Fixes #760.

Also removes a warning in policy.REROUTE that is no longer true.

Oto Šťáva authored 2 years ago and Vladimír Čunát committed 2 years ago

Fixes CIDs 355763 and 355764. Also fixes a minor typo.

Other LTS than 22.04 have really old versions in the repo (<= 3.2.1),
so better not advertise those at all.

The address won't work anymore, and Jakub says this field isn't needed.

https://gitlab.nic.cz/knot/knot-resolver/-/jobs/635837#L219

This reverts commit ac3e7ac7.
They have been fixed and seem reliable now.

It broke down and it isn't relevant anymore.

That way we get at least basic testing before 3.2 is made default in CI.

Our strategy was (and remains) that the in-header QNAME is overwritten
in-place, so most of our code was already (correctly) assuming that
knot_pkt_qname() returns lower-case only.  That simplifies this commit.