random-util: eat up bad RDRAND values seen on AMD CPUs
An ugly, ugly work-around for #11810. And no, we shouldn't have to do
this. This is something for AMD, the firmware or the kernel to
fix/work-around, not us. But nonetheless, this should do it for now.
Fixes: #11810
(cherry picked from commit
1c53d4a070edbec8ad2d384ba0014d0eb6bae077)
Gbp-Pq: Name random-util-eat-up-bad-RDRAND-values-seen-on-AMD-CPUs.patch
Drop support for /usr/sbin/halt.local
/usr/sbin/halt.local is a Fedora/Red Hat anachronism from pre-systemd
times.
(cherry picked from commit
44508946534eee032927c263b79464832656dd6e)
Gbp-Pq: Name Drop-support-for-usr-sbin-halt.local.patch
meson: stop creating .wants directories for {multi-user,getty}.target (#12569)
Since preset is supposed to be used to enable the services, there is no
need to pre-create those directories either.
Follow-up for #12164
(cherry picked from commit
dadc7f2e43b163dd740832abd73b83245f716c1e)
Gbp-Pq: Name meson-stop-creating-.wants-directories-for-multi-user-get.patch
test: add test for flush_accept()
Fixes: #12335
(cherry picked from commit
5b116c37e14582ee6550c9157445d6bbd4ce1813)
Gbp-Pq: Name test-add-test-for-flush_accept.patch
socket-util: make sure flush_accept() doesn't hang on unexpected EOPNOTSUPP
So apparently there are two reasons why accept() can return EOPNOTSUPP:
because the socket is not a listening stream socket (or similar), or
because the incoming TCP connection for some reason wasn't acceptable to
the host. THe latter should be a transient error, as suggested on
accept(2). The former however should be considered fatal for
flush_accept(). Let's fix this by explicitly checking whether the socket
is a listening socket beforehand.
(cherry picked from commit
f3d75364fbebf2ddb6393e54db5e10b6f6234e14)
Gbp-Pq: Name socket-util-make-sure-flush_accept-doesn-t-hang-on-unexpe.patch