Package: ufw
Version: 0.36.2-1
ufw relies on `sysctl` for some operations, e.g. when executing `ufw status
verbose`. After recently cleaning up an unnecessary package, it decided that
`procps` was no longer necessary and uninstalled it as well. However, `ufw`
depends on `/sbin/sysctl` (or `/usr
Forwarding to mailinglist. Got fooled by email client.
Original Message
On 8/12/24 6:43 PM, Danny van Heumen wrote:
> Hi, thanks for correcting this in light of new information.
>
> Original Message
> On 8/6/24 11:54 AM, Patrick Schl
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 haveg
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
nftabl
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 govern
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 conditions[
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 th
al Message ‐‐‐
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.
gt; 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
> >
> > Versio
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. re
10 matches
Mail list logo
