The indentation stripping semantics of strings are fairly bad and have a
few gotchas where the resulting string has not the intended indentation.
This commit fixes most if not all such instances in Nixpkgs.
I tried to strive a balance between keeping the diff small and
reformatting/refactoring the code to look better. In general,
reformatting should be left to Nixfmt.
Note that this causes a lot of rebuilds by design. All changes need to
be thoroughly vetted and reviewed for correctness. There is no automatic
way to prove correctness.
List of files to fix generated by running
https://gerrit.lix.systems/c/lix/+/2092 on Nixpkgs and looking at the
warnings.
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"
```
The nixpkgs-unstable channel's programs.sqlite was used to identify
packages producing exactly one binary, and these automatically added
to their package definitions wherever possible.
Many packages have some kind of flag indicating whether or not to build with
systemd support. Most of these default to `stdenv.isLinux`, but systemd does
not build on (and is marked `broken` for) `isStatic`. Only a few packages have
the needed `&& !isStatic` in the default value for their parameter.
This commit moves the logic for the default value of these flags into
`systemd.meta.{platforms,badPlatforms}` and evaluates those conditions using
`lib.meta.availableOn`.
This provides three benefits:
1. The default values are set correctly (i.e. including `&& isStatic`)
2. The default values are set consistently
3. The way is paved for any future non-Linux systemd platforms (FreeBSD is
reported to have experimental systemd support)
Done with the help of https://github.com/Mindavi/nixpkgs-mark-broken
Tool is still WIP but this is one of the first results.
I manually audited the results and removed some results that were not valid.
Note that some of these packages maybe should have more constrained platforms set
instead of broken set, but I think not being perfectly correct is better than
just keep trying to build all these things and never succeeding.
Some observations:
- Some darwin builds require XCode tools
- aarch64-linux builds sometimes suffer from using gcc9
- gcc9 is getting older and misses some new libraries/features
- Sometimes tools try to do system detection or expect some explicit settings for
platforms that are not x86_64-linux
This fixes the python init error mentioned here:
https://github.com/NixOS/nixpkgs/issues/105221#issuecomment-1251150900
However, there are still issues with the derived python environment - for some
reason datadog_checks.base is not present in the env's site-packages, which all
the other checks depend on, so python loading still isn't working fully (but I
believe this is an improvement over what's there already at least).
If using go119, the agent throws an error at startup:
```
panic: Something in this program imports go4.org/unsafe/assume-no-moving-gc to declare that it assumes a non-moving garbage collector, but your version of go4.org/unsafe/assume-no-moving-gc hasn't been updated to assert that it's safe against the go1.19 runtime
```
I believe this needs a fix in the datadog package itself, similar to:
https://github.com/DataDog/datadog-agent/pull/11455 but for go1.19
Loading Errors for apm, process-agent and winproc.d appear on the
datadog agent.
To suppress these errors, I have removed these default configurations
that were copied in the postInstall phase.
