This commit patches one of the llvm-exegesis tests to swap out whatever
CPU model happens to be on the build host for bdver2 (AMD Family
15h/Piledriver), which was picked because it looks like that was the
intent of the test author. This provides a more predictable compilation
behaviour when running on older (or possibly even newer!) machines.
One of the machines that is currently part of the NixOS Hydra build
farm, wendy, is using an old AMD Opteron CPU for which LLVM has no
scheduling machine model. This causes one of the tests for llvm-exegesis
to fail, because it segfaults trying to use the machine model to produce
useful analysis results.
Note that this particular test only runs on x86-64 build hosts anyway;
aarch64 isn't affected.
This deliberately only patches LLVM 12 to limit the rebuilds; other
LLVM versions are going through staging.
* nixos/nginx: add upstreams examples
I am not fully sure if they are fully correct but they deployed the right syntax.
* nixos/nginx: use literal example
* Update nixos/modules/services/web-servers/nginx/default.nix
* Update nixos/modules/services/web-servers/nginx/default.nix
This makes the targetPrefix always conform to nixpkgs' expectations
instead of relying on the autotools build system to figure it out
correctly (which is also inconsistent across versions).
See also ca9be0511b0661be5255dd1fe0b05c5eaf3e56d8.
Don't rely on gcc detecting from the passed platforms which prefix to
use, but always specify the prefix nixpkgs expects (or doesn't). This
allows us to work around problems where the configure script would add
prefix where nixpkgs doesn't expect one (if `--target` was specified,
but the same as `--host`) or doesn't add one if nixpkgs expects one (if
`--target` and `--host` are the same, but we are actually cross
compiling, but the relevant parts of the platform are not encoded into
the platform config.
See also ca9be0511b0661be5255dd1fe0b05c5eaf3e56d8.
I was getting problems with the unit failing to start due to NAMESPACE
or CAPABILITIES permissions.
Upstream now provides a systemd unit file in the repo, we should use that
one, and that one works for me.
It is building fine locally, tested by myself and @SuperSandro2000 (who had added the broken tag).
Should this be tested on hydra before removing it? I don't know if that is even possible.
Clipboard support was actually introduced in version `0.8.0`, and this
change flew completely over my head. Now the /paste command should
actually work by default and as expected.
