most tests use debian-devscripts' hardening-check, so only work on
ELF systems and can only detect a limited subset of flags.
some extra tests actually execute fortify-protected programs and
should be slightly more universally applicable.
- Better filesystem case-sensitivity heuristic
We shouldn't assume that Linux is always case-sensitive.
- Don't include case-sensitive filename in tree
Was used for tests, but this broke channel updates because there's a
check to make sure there's no case-sensitive files!
https://hydra.nixos.org/build/233371356/nixlog/1
This commit does the following two things:
1. Changes the Haskell package used in the extraDependencies test from
releaser to conduit. The reason for this is that conduit is more
of a "core" package in Haskell, and it is more likely to always be
working. (If conduit is not compiling, then large chunks of Hackage
won't be working.)
2. Tighten up the GHCi test to actually use the package from
extraDependencies. It appears that GHCi can fail to import the
package from extraDependencies, and that doesn't cause GHCi to
return an error code, which means the test isn't actually testing
anything.
This new change makes it so that if the package from
extraDependencies is actually not included for some reason, then
this shellFor test should fail.
```
nix-repl> (pkgs.htop.overrideAttrs { pname = "hello-overriden"; }).pname
error:
… while evaluating a branch condition
at /nix/store/phn5cahwacv9wjgalygw62x8l4xbl6x3-source/lib/customisation.nix:86:7:
85| in
86| if builtins.isAttrs result then
| ^
87| result // {
… while calling the 'isAttrs' builtin
at /nix/store/phn5cahwacv9wjgalygw62x8l4xbl6x3-source/lib/customisation.nix:86:10:
85| in
86| if builtins.isAttrs result then
| ^
87| result // {
(stack trace truncated; use '--show-trace' to show the full trace)
error: attempt to call something which is not a function but a set
at /nix/store/phn5cahwacv9wjgalygw62x8l4xbl6x3-source/pkgs/stdenv/generic/make-derivation.nix:58:21:
57| f = self: super:
58| let x = f0 super;
| ^
59| in
```
This commit adds `pkgs.test.cross.sanity`, which is meant to be a
carefully curated list of builds/packages that tend to break when
refactoring our cross-compilation infrastructure.
It should strike a balance between being small enough to fit in
a single eval (i.e. not so large that hydra-eval-jobs is needed)
so we can ask @ofborg to check it, yet should have good examples
of things that often break. So, no buckshot `mapTestOnCross`
calls here.
Makes overrideAttrs usable in the same way that `override` can be used.
It allows the first argument of `overrideAttrs` to be either a function
or an attrset, instead of only a function:
hello.overrideAttrs (old: { postBuild = "echo hello"; })
hello.overrideAttrs { postBuild = "echo hello"; }
Previously only the first example was possible.
Co-authored-by: adisbladis <adisbladis@gmail.com>
Co-authored-by: matthewcroughan <matt@croughan.sh>
This change adds a flag to update shebang paths that point to the Nix
store. This is particularly useful when a cross-compiled package uses
same script at compile-time and run-time, but the interpreter must be
changed since hostPlatform != buildPlatform.
With a recent hackage update, turtle stopped compiling on ghc94. This
commit changes the tests.haskell.incremental test to use the temporary
package instead of turtle.
We shouldn't try compiling to aarch64-unknown-linux-gnu from
aarch64-unknown-linux-gnu, because that tends to confuse things and is
not representative of actual cross compilation usage.
This commit adds a derivation `gcc-stageCompare` to
`pkgs/test/stdenv/default.nix`.
It is important to always build this derivation whenever building
`stdenv`! Because we are using a Nix-driven bootstrap instead of
gcc's built-in `--enable-bootstrap`, the `gcc` derivation no longer
performs the post-self-compilation sanity check. You must build
this derivation in order to perform that sanity check.
The major benefit of this new approach is that the sanity check
(which involves a third compilation of gcc) can be performed
*concurrently* with all packages that depend on `stdenv`, rather
than serially. Since `stdenv` has very little derivation-level
parallelism it cannot take advantage of more than one or perhaps two
builders. If you have three or more builders this commit will
reduce the time-to-rebuild-stdenv by around 20% (one of three gcc
rebuilds is removed from the critical path, and stdenv's build time
is dominated by roughly 3*gcc + 1*binutils + 1*bison-test-suite).
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Set the executable bit before running the check phase, so that the check
phase can run the script to test its behaviour.
This aligns with what `concatTextFile` is doing.
Also use explicit `if` statements so that we don't silently ignore
`chmod` failures.
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
Some packages are only marked broken on specific platforms, so we
filter those out as well.
Consequently, this might not raise an error if the attribute value
needs to point to a different pkgs attribute, but this is not something
we can detect. For now, we'll have to rely on users of such pkg-config
packages to report that kind of error.
There's really not much we can do about this here.
error: The option `settings.NIXOS_TEST_BOOLEAN.tristate' has conflicting definition values:
- In `structuredExtraConfig': "n"
- In `structuredExtraConfig': "y"
since https://github.com/NixOS/nixpkgs/pull/90065
yes does not silently win over no
Closes#16182
This improves the error message
Error: _assignFirst found no valid variant!
which occurred when the set of outputs was not sufficient to set
the various outputDev, outputBin, etc variables. Specifically, this
would mean that "out" is not among the outputs, which is valid for
a derivation.
This changes the message to something like
error: _assignFirst: could not find a non-empty variable to assign to outputDev. The following variables were all unset or empty: dev out.
If you did not define an "out" output, make sure to define all the specific required outputs: define an output for one of the unset variables.
While this isn't a full explanation of what stdenv can and can not do,
I think it's vast improvement over the 0 bits of information that it
used to provide. This at least gives a clue as to what's going on, and
even suggests a fix, although probably multiple such fixes are required
in an instance where someone starts with a no-out derivation from scratch
(and decide to persist).
Derivations not using `__structuredAttrs` should not attempt to set
environment variables from `env`.
Derivations using `__structuredAttrs` should fail if `env` is not
exportable.
Avoids confusion: `vim-full`'s build-time features are configurable, but both
`vim` and `vim-full` are *customizable* (in the sense of user configuration).
Previously, the cutensor samples could not find the libcutensor.so.1
shared library at runtime. This patch adds cutensor as a buildInput so
the shared library is linked in properly.
* origin/staging-next: (62 commits)
Re-Revert "lua: fix on darwin by using makeBinaryWrapper (#172749)"
openldap: fix cross-compilation
makeBinaryWrapper: fix codesign on aarch64-darwin
python3Packages.ldap: fix linking with openldap 2.5+
Revert "lua: fix on darwin by using makeBinaryWrapper (#172749)"
wine: enable parallel build again
pkgsi686Linux.gdb: fix formatting for 32-bit systems
gtk4: Fix incorrect merge
nixos/openldap: use upstream unit defaults
openldap: update maintainers
openldap: 2.4.58 -> 2.6.2
Revert "Add mingwW64-llvm cross-system."
lua: fix on darwin by using makeBinaryWrapper (#172749)
python310Packages.python-mimeparse: execute tests
pandas: fix darwin build
gtk3: 3.24.33 -> 3.24.33-2022-03-11
gtk4: patch fixing g-c-c crashes
e2fsprogs: patch for CVE-2022-1304
firefox-unwrapped: fix cross compilation
rustc: expose correct llvmPackages for cross compile
...
There are many different versions of the `cudatoolkit` and related
cuda packages, and it can be tricky to ensure they remain compatible.
- `cudaPackages` is now a package set with `cudatoolkit`, `cudnn`, `cutensor`, `nccl`, as well as `cudatoolkit` split into smaller packages ("redist");
- expressions should now use `cudaPackages` as parameter instead of the individual cuda packages;
- `makeScope` is now used, so it is possible to use `.overrideScope'` to set e.g. a different `cudnn` version;
- `release-cuda.nix` is introduced to easily evaluate cuda packages using hydra.
Disable file globbing in --prefix/--suffix, since bash will otherwise
try to find filenames matching the the value to be prefixed/suffixed
if it contains characters considered wildcards, such as `?` and
`*`. We want the value as is, except we also want to split it on on
the separator; hence we can't quote it.
Sanitizers don't seem to be present on aarch64-darwin/macOS 12 (Monterey), so they are removed from the aarch64-darwin tests.
Switching from nativeBuildInputs to buildInputs and adding cc to the deps list caused some strange error messages to go away.
On macOS, /tmp is a symlink to /private/tmp. When performing cd /tmp, and checking cwd - it won't match since it follows the symlink.
This caused test breakage on macOS but not Linux. Instead, use a folder which is not a symlink, and consistent across Linux and macOS.
This allows packagePlatforms to pick up on the overall supported
platforms and schedule builds on Hydra for more than the evaluation
platform (usually x86_64-linux).
Since the rust writer doesn't seem to get fixed on darwin, we'll just
wrap the haskell writer test in our own derivation (which is possible
since tests.writers exposes a bunch of internals via passthru) and
expose it via tests.haskell which are already in mergeable.
Finally a way to test the (hopefully) working haskell writer on darwin
again!
This fixes#126344, specifically with the goal of enabling overriding the
checkPhase argument. See `design notes` at the end for details.
This allows among other things, enabling bash extension for the `checkPhase`.
Previously using such bash extensions was prohibited by the `writeShellScript`
code because there was no way to enable the extension in the checker.
As an example:
```nix
(writeShellScript "foo" ''
shopt -s extglob
echo @(foo|bar)
'').overrideAttrs (old: {
checkPhase = ''
# use subshell to preserve outer environment
(
export BASHOPTS
shopt -s extglob
${old.checkPhase}
)
'';
})
```
This commit also adds tests for this feature to `pkgs/tests/default.nix`,
under `trivial-overriding`. The test code is located at
`pkgs/build-support/trivial-builders/test-overriding.nix`.
Design notes:
-------------
Per discussion with @sternenseemann, the original approach of just wrapping
`writeTextFile` in `makeOverridable` had the issue that combined with `callPackage`
in the following form, would shadow the `.override` attribute of the `writeTextFile`:
```nix
with import <nixpkgs>;
callPackage ({writeShellScript}: writeShellScript "foo" "echo foo")
```
A better approach can be seen in this commit, where `checkPhase` is moved
from an argument of `writeTextFile`, which is substituted into `buildCommand`,
into an `mkDerivation` argument, which is substituted from the environment
and `eval`-ed. (see the source)
This way we can simple use `.overideAttrs` as usual, and this also makes
`checkPhase` a bit more conformant to `mkDerivation` naming, with respect to
phases generally being overridable attrs.
Co-authored-by: sterni <sternenseemann@systemli.org>
Co-authored-by: Naïm Favier <n@monade.li>
* neovim: temporary revert to unbreak user configs
Newly introduced "plugins" parameter is disabled until we get a better
testing infrastructure to minimize breaking changes.
additional argument not generated by makeNeovimConfig
If true (the default), appends "-u <customRc>" to the wrapped arguments.
Set to false if you want to control where to save the generated config
(e.g., in ~/.config/init.vim or project/.nvimrc)
Rust 1.50.0 incorporated a Cargo change (rust-lang/cargo#8937) in
which cargo vendor erroneously changed permissions of vendored
crates. This was fixed in Rust
1.51.0 (rust-lang/cargo#9131). Unfortunately, this means that all
cargoSha256/cargoHashes produced during the Rust 1.50.0 cycle are
potentially broken.
This change updates cargoSha256/cargoHash tree-wide.
Fixes#121994.
Contrary to database-id-class, linear is part of stackage and actively
maintained, so the test is less likely to fail due to version
constraint issues as it is currently.
* tests.vim: init (moved from vim-utils.nix)
Moved tests from pkgs/misc/vim-plugins/vim-utils.nix to pkgs/test/vim.
Also reduced the amount of generated config:
- Make it possible to have an empty config when configured adequately
- removed default vim config when using native packages, it could be
source of bugs see linked issues (syntax on overrides vim highlights)
Things to watch out for:
- if you set configure.beforePlugins yourself, you will need to add set nocompatible too not to lose it
- filetype indent plugin on | syn on is not enabled anymore by default for the vim-plug installer: I dont think we should override vim defualts, at least not here since it is shared with neovim. Also sometimes it's enabled before plugins (pathogen etc,) which is not consistent.
you can run the tests via
$ nix-build -A tests.vim
Remove old CUDA toolkits (and corresponding CuDNN versions).
- Not supported by upstream anymore.
- We do not use them in nixpkgs.
- We do not test or actively maintain them.
- Anything but ancient GPUs is supported by newer toolkits.
Fixes#107131.
Since CUDA is unfree, we won't actually use this when testing Nixpkgs
officially. But I want to include this as they are useful for users of
Nixpkgs trying to set up / debug a CUDA environment.
Currently we set dynamic-linker unconditionally. This breaks
however some static binaries i.e. rust binaries linked against musl.
There is no reason we should set an elf interpreter for static binaries
hence this is skipped if `-static` or `-static-pie` is either passed to
our cc or ld wrapper.
I made a mistake merge. Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
This makes it work like work-on-multi from Reflex Platform. In
particular, rather than making `.env` from `shellFor`, we make `.env`
the primitive, and `shellFor` works by combining together the arguments
of all the packages to `generic-builder` and taking the `.env` of the
resulting mashup-package.
There are 2 benefits of this:
1. The dependency logic is deduplicated. generic builder just concatted
lists, whereas all the envs until now would sieve apart haskell and
system build inputs. Now, they both decide haskell vs system the same
way: according to the argument list and without reflection.
Consistency is good, especially because it mean that if the build
works, the shell is more likely to work.
2. Cross is handled better. For native builds, because the
`ghcWithPackages` calls would shadow, we through both the regular
component (lib, exe, test, bench) haskell deps and Setup.hs haskell
deps in the same `ghcWithPackages` call. But for cross builds we use
`buildPackages.ghcWithPackages` to get the setup deps. This ensures
everything works correctly.
Adds pkgsCross.wasm32 and pkgsCross.wasm64. Use it to build Nixpkgs
with a WebAssembly toolchain.
stdenv/cross: use static overlay on isWasm
isWasm doesn’t make sense dynamically linked.
You can build (partially) with LLVM toolchain using the useLLVM flag.
This works like so:
nix-build -A hello --arg crossSystem '{ system =
"aarch64-unknown-linux-musl"; useLLVM = true }'
also don’t separate debug info in lldClang
It doesn’t work currently with that setup hook. Missing build-id?
You can use stdenv.hostPlatform.emulator to get an executable that
runs cross-built binaries. This could be any emulator. For instance,
we use QEMU to emulate Linux targets and Wine to emulate Windows
targets. To work with qemu, we need to support custom targets.
I’ve reworked the cross tests in pkgs/test/cross to use this
functionality.
Also, I’ve used talloc to cross-execute with the emulator. There
appears to be a cross-execute for all waf builds. In the future, it
would be nice to set this for all waf builds.
Adds stdenv.hostPlatform.qemuArch attrbute to get the qemuArch for
each platform.
fc9644d4c9 accidentally enabled the
sanitizer tests for GCC on Darwin, when fixing that case was never
attempted. Also inverted the condition from broken to working for
clarity.
We already did them on non-mass-rebuild llvm 6. Also, this allows
simplifying the stdenv booting.
We were missing the libcxxabi dep in compile-rt in llvm 6, so fixed that
too.
