* libflux: 0.124.0 -> 0.139.0; as specified in influxdb 2.1's release notes
* UI: 2.0.8 -> 2.1.2; matching what influxdb 2.1.1 requires
* Add checks in influxdb2's build to verify that libflux and the UI are at
the version specified by upstream.
* The CLI got split into a separate repository for reasons to do with influx's
cloud service, and its version has also been decoupled from the main influxdb
repository. Link it back into the influxdb2 derivation, for compatibility
with the previous derivation versions.
The old version of the script tried to parse the output of the dotnet tool, but
apparently, that output changed and thus the list of dependencies was empty.
We previously weren't able to build systemd for Musl, but now we
can! (But not statically.) So there's no longer any reason to have
systemd support in Redis disabled by default for pkgsMusl.
* libflux: 0.115.0 -> 0.124.0; which fixes build errors for libflux on
hydra (unused vars in Rust)
* the UI (chronograf) is now in embeded as a static asset from its GitHub
repository
The python modules that we to the enviroment should always come from the
same python version as scons as otherwise they can't be loaded.
This unbreaks the build of mongodb 4.2 which pinned python to 3.8 while
our python attribute moved on to 3.9 which is what scons uses now.
Convention is to use `jre` and make it specific in the callPackage
call.
This way users can override it regardless of changes to the default
neo4j jre.
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
