We need to set FC so that CMake and other tools can find the fortran
compiler. Also we need to limit the hardening flags since fortify and
format don’t work with fortran.

Fixes #88449

This is the right one on cross compilation.

Fixes #89215

used together with cpython's debugging symbols, this allows inspection of
the python stack of cpython programs in gdb. this file is a little
different from the rest of the python output by this package, in that it's
not intended to be run by the current python being built, instead by the
python being used by the gdb in question, which could be very different.
therefore placed in its own, but hopefully logical & predictable location.

Fix reproducibility by fixing SOURCE_DATE_EPOCH usage

There's a circular dependency to systemd via cryptsetup and lvm2
(systemd -> cryptsetup -> lvm2 -> udev=systemd).

However, cryptsetup only really needs the devmapper component shipped
with lvm2. So build `pkgs.cryptsetup` with a lvm2 that doesn't come with
udev.

…yptsetup-generator.c)

This package previously did override the systemd package, and instructed
ninja, systemd's previous build system, to only build the
cryptsetup-specific systemd generators (plus some manual rpath
massaging, as ninja install wasn't used).

Afterwards, users were expected to add this package to their
`systemd.generator-packages` (or since
https://github.com/NixOS/nixpkgs/pull/65376/files `systemd.packages`)
NixOS module options, so systemd will use these generators.

As the previous commit added cryptsetup support directly to the systemd
package (and pkgs.systemd now already ships the cryptsetup generators),
we don't need another package shipping the same generators.

This creates and opens a luks volume, puts its passphrase into a keyfile
and writes a /etc/crypttab. It then reboots the machine, and verifies
systemd parsed /etc/crypttab properly, and was able to unlock the volume
with the keyfile provided (as we try to mount it).

The memorySize of the VM had to be bumped, as luksFormat would otherwise
run out of memory.

systemd: build with cryptsetup support, add cryptsetup generators

gnupg22: 2.2.20 -> 2.2.21

This produced a warning:

> grep: Invalid range end

In a [], - has to come last.

Reported-by: Daniël de Kok <me@danieldk.eu>
Fixes: 75fdc1c

"The former date based internal versioning (snapshot) is replaced by the
regular version numbering which corresponds to the kernel version." [0]

File changes (additions/removals):
+share/man/man8/ip-mptcp.8.gz
+share/man/man8/tc-gate.8.gz

[0]: https://marc.info/?l=linux-netdev&m=159681449423365

libbytesize: 2.3 -> 2.4

Incluing the patch file in-tree because the upstream patch is not
intended to apply for Python 2.

Re #94004

Meson allows projects to set `build_rpath` property, containing paths
that will be added during build but will be removed when installing.

When Meson removes build_rpath from `DT_RUNPATH` entry, it just writes
the shorter ␀-terminated new rpath over the old one to reduce
the risk of potentially breaking the ELF files
(when the linker does string de-duplication or something).
But this can cause much bigger problem for Nix, as it can produce
cut-in-half-by-␀ store path references.

For example, in systemd’s libudev, it was removing three `$ORIGIN`-relative paths from

    $ORIGIN/../libsystemd:$ORIGIN/../basic:$ORIGIN/../shared:…␀

resulting in the following `DT_RUNPATH` entry:

    …␀store/v589pqjhvxrj73g3r0xb41yr84z5pwb7-gcc-9.3.0-lib/lib␀

We previously handled this in `fix-rpath.patch` but the method we prevent
Meson from removing paths added to rpath through `NIX_LDFLAGS` was changed
during 0.55.0 update and I forgot about this second purpose of the patch.

Let’s re-add this clearing code, as it worked without issues for a long time.

radsecproxy: 1.8.1 -> 1.8.2

This reverts commit fee8c0a.
The required systemd update was done in 9f911ab; test works for me:
nix build -f nixos/release.nix tests.latestKernel.login.x86_64-linux