Bug#1034361: haveged: autopkgtest fails on bookworm kernel: service fails to start

Hi, I looked into haveged a while back because I ran into some issue. (Don't remember exactly what.) Apparently, the upstream systemd-service contains a conditional to only start on old kernels. The strategies that haveged performed are apparently incorporated into the kernel. That makes

Bug#1033144: [Firewalld] exit with status-code cleaned up rules in firewall

Package: firewalld Version: 1.3.0-1~bpo11+1 I do not know exactly how to reproduce, so I will describe my facts and suspicions best I can. I checked current status of the firewall on my system (`firewalld`) and discovered it was not running and in addition, the rules were not present in

Bug#1001039: panfrost: missing dependency in modinfo causes issues during early loading (dmesg)

Package: linux-signed-arm64 Version: 5.10.70+1 Version: 5.14.9+2~bpo11+1 The 'panfrost' driver for the variety of Mali graphics devices requires a GPU scaling governor to be available. Either this version of the source has not yet been patched, or the patch only affects a statically bound

Bug#999811: HAVEGED is obsolete starting from linux kernel 5.6

Package: haveged Version: 1.9.14-1 HAVEGED is no longer considered necessary on any linux kernel 5.6 and greater. The site itself recommends[1] not using it as kernel random support is sufficiently improved, making haveged obsolete. Upstream uses a systemd service file with starting

Bug#993949: dnscrypt-proxy fails to use address from DoH servers on start-up, resorts to system resolver

Hi Eric, It has been quiet for a while. I'd like to hear what your thoughts are on this. Kind regards, Danny ‐‐‐ Original Message ‐‐‐ On Friday, September 10th, 2021 at 5:54 PM, Danny van Heumen wrote: > Hi Eric, > > Indeed, a fix was implemented. > > Yes. I think t

Bug#993949: dnscrypt-proxy fails to use address from DoH servers on start-up, resorts to system resolver

‐‐‐ On Friday, September 10th, 2021 at 5:54 PM, Danny van Heumen wrote: > Hi Eric, > > Indeed, a fix was implemented. > > Yes. I think that the address from the public-resolvers document should take > precedence over the address from an arbitrary resolver. > >

Bug#993949: dnscrypt-proxy fails to use address from DoH servers on start-up, resorts to system resolver

. > Do > > you think this is serious enough to warrant cherrypicking into the > > package or should we just wait for the next upstream release? > > - Danny van Heumen (da...@dannyvanheumen.nl) wrote: > > > Package: dnscrypt-proxy > > > > Version: 2.

Bug#993949: dnscrypt-proxy fails to use address from DoH servers on start-up, resorts to system resolver

Package: dnscrypt-proxy Version: 2.0.45+ds1-1+b5 Severity: normal X-Debbugs-Cc: da...@dannyvanheumen.nl Dear Maintainer, A bug was recently found where DNS stamp information is used incorrectly to fill the resolver cache on initialization. In short, DNS stamps of the various DNSCrypt/DoH/etc.