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.

We've been unable to progress with these failures for some time,
and it's not good to have them red in CI all the time.
Manual start should allow easier testing of future fixes,
without doing the futile runs automatically.

Fixes #758