after numpy updated to 1.26.1 distutils no longer provides the lib
locations so use env vars for non-darwin. On darwin Accelerate library
is prioritized over BLAS so add Accelerate to buildInputs.
t/css-dom.t was deactivated because it failed due to deprecated syntax. This
commit uses an upstream patch to fix the syntax and activate the test again.
https://hydra.nixos.org/build/240114924/nixlog/1
```
error: linking with `/nix/store/sa6hywsm1mqfyd1xakyzv4ljjsb3hawh-clang-wrapper-11.1.0/bin/cc` failed: exit status: 1
|
...
= note: ld: library not found for -liconv
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)
```
after adding libiconv it starts to fail with
```
File "/nix/store/ncs3h7zqjl3cl2cwflka40rrirb6qg1m-python3.11-mitmproxy-rs-0.3.11/lib/python3.11/site-packages/mitmproxy_rs/__init__.py", line 1, in <module>
from .mitmproxy_rs import *
ModuleNotFoundError: No module named 'mitmproxy_macos'
```
so it needs extra module
https://github.com/mitmproxy/mitmproxy_rs/tree/main/mitmproxy-macos
So the fixes are
- add `libiconv` dependency to mitmproxy-rs
- add `mitmproxy-macos` python package and add it to dependencies of
`mitmproxy-rs` and `mitmproxy` itself (otherwise import fails,
looks like the import is sneaky because it is platform-conditional)
https://github.com/openai/whisper/blob/v20231117/CHANGELOG.md
Always propagate openai-triton, since whether or not it is free is
decided by `nixpkgs.config.cudaSupport`.
This allows us to drop the local `cudaSupport` flags in favor of the
nixpkgs-wide one.
Part of ZHF for 23.11: https://hydra.nixos.org/build/241300457
I bisected this failure to this first bad commit: [9ed7bfe46b] llvmPackages: 11 -> 16 on Linux,
then looked around for other repairs made to assuage LLVM's errors. This appears to be the pattern.
Depends on EOL software and no maintenance has been attempted to change this after a ping
(https://github.com/NixOS/nixpkgs/issues/259178)
Feel free to adopt and re-introduce if you care about this software.
This will probably seriously hamper ELK usability in nixpkgs, but as it
receives no maintenance…
While using very old compilers is a fair usecase, it induces a maintenance churn as
we collect more and more LLVM versions for the LLVM maintainers.
Especially when we need to backport uniform changes to the whole tree,
furthermore, it consumes and waste CI resources.
