In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
when `npth` upgraded 1.6 -> 1.7, the `npth-config` binary it previously
provided was removed, and functionality folded into `gpgrt-config`. see:
<417abd56fd/NEWS (L8)>
GnuPG upstream changed some of its behavior on the 2.4 branch to use its
own, non-standardized format for keys and encrypted data by default.
This affects in particular the way that keys are generated, and
algorithm capability flags within now signal the ability to use GnuPG's
own AEAD encryption format.
Notably, these formats are not compatible with other implementations of
OpenPGP. It is based on a draft spec that is specific to GnuPG
(draft-koch-openpgp-2015-rfc4880bis), and not compatible with the format
that is on track to be standardized as upcoming OpenPGP version 6.
The political circumstances that led to this issue are complex (and a
bit dumb), but in the end GnuPG emitting incompatible packets is
certainly in noone's interest. This patch is a revert of a GnuPG
upstream commit as it is applied by Fedora, I suggest we follow suit
until the situation becomes more clear.
See also: https://src.fedoraproject.org/rpms/gnupg2/pull-request/15
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
Since version 2.3, GnuPG no longer falls back to other access methods if
its built-in CCID driver fails to access smartcards, including yubikeys.
The built-in CCID driver fails on macOS.
The upstream developers recommend disabling CCID support in this case:
If it works and the distribution doesn't offer appropriate USB
configuration, I think that it's good for the distribution to use
--disable-ccid-driver for building GnuPG.
Cite: https://dev.gnupg.org/T5415
See also: https://dev.gnupg.org/T5409Fixes#155629
pcsclite pulls in a lot of dependencies, including spidermonkey, which is
nearly or completely impossible to build on 32-bit architectures. PC/SC support
is not commonly used, so provide a flag to allow users to disable it and
significantly reduce the closure size.
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: ../util/libutil.a(estream-printf.o):/build/gnupg-1.4.23/util/../include/memory.h💯 multiple definition of
`memory_debug_mode'; gpgsplit.o:/build/gnupg-1.4.23/tools/../include/memory.h💯 first defined here
