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.
datadog-agent is now built as a go module. However, the build process
is now to be driven by the python invoke tool. While datadog-agent
builds with buildGoModule, some investigation should be done to ensure
we are not missing any integrations or features from the invoke build
system.
This also updates datadog-agent from python 2.7 to 3.x.
One other issue of note: most of the invoke tasks seem to use some git
parsing to get version numbers and the like. This package may need to
be checked for reproducibility issues now.
