See: #612

A temporary measure during development of new packaging tests.

See: #612

Cleanup before introduction of new packaging tests.

See: #612

Cleanup before introduction of new packaging tests.

See: #612

... in case of IPv6 link-local addresses.
The casting isn't very nice, but we certainly rely on `family` being
always on the same offset anyway (and it's ensured by standards).

I'm really sorry about this.  It's my regression in 5.5.0 (!1225)

Practical consequence was that the RW transaction was held open
until that instance did something with cache (and thus closed),
so any other instance would be frozen in the meantime if doing
anything non-read-only with cache (e.g. startup).
https://lists.nic.cz/hyperkitty/list/knot-resolver-users@lists.nic.cz/thread/6DOXXOA6ACEUBVYPUY3T2MLGIHWOMV6M/

In a few places the tag-set specification for jobs could match
either amd64 or arm64 runners.  That non-determinism is bad,
especially when passing platform-specific artifacts around.

This is just a stop-gap measure.  Later we'll need to rethink our CI
in terms of the two platforms.

I didn't touch tag-sets with `condor`, as that will probably always be
just a single machine (which coordinates scheduling on others).

The apkg installation through pip3 was pulling too new jinja2 version,
breaking subsequent usage of sphinx to build docs (in `apkg build`).

Fixes #735

It's probably a bit more efficient, but this part of code should be
rarely used even on a resolver serving all in XDP.

Somehow I did this wrong when porting to libknot 3.1.

* set myself as package maintainer
* use {{ now }} instead of hardcoded datetime
  * bump apkg compat to 2

This is a no-op as GPG_CHECK is disabled for upstream package but it
keeps the .spec files in sync.

Fixes #727

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

Also change the return type of kr_pkt_has_dnssec() and lua's :dobit()

release 5.5.0

See merge request !1272