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.
libgcc of the gcc being built, not the gcc building it.
* Only include a directory in the rpath of an executable/library if it
is actually used. Before, the `/lib' directory of every build input
was added to the rpath, causing many unnecessary retained
dependencies. For instance, Perl has a `/lib' directory, but most
applications whose build process uses Perl don't actually link
against Perl. (Also added a test for this.)
* After building glibc, remove glibcbug, to prevent a retained
dependency on gcc.
* Add a newline after `building X' in GNU Make.
svn path=/nixpkgs/trunk/; revision=911
On the downside, the build process of stdenvLinux builds gcc 9 times
(3 x 3 bootstrap stages). That's a bit excessive.
svn path=/nixpkgs/trunk/; revision=880
* Make builders unexecutable by removing the hash-bang line and
execute permission.
* Convert calls to `derivation' to `mkDerivation'.
* Remove `system' and `stdenv' attributes from calls to
`mkDerivation'. These transformations were all done automatically,
so it is quite possible I broke stuff.
* Put the `mkDerivation' function in stdenv/generic.
svn path=/nixpkgs/trunk/; revision=874
checked whether absolute paths passed to gcc/ld refer to the store,
which is wrong: they can also refer to the build tree
(/tmp/nix-...).
* Less static composition in the construction of stdenv-nix-linux:
gcc-wrapper and generic are now passed in as arguments, rather then
referenced by relative path. This makes it easier to hack on a
specific stage of the bootstrap process (before, a change to, e.g.,
generic/setup.sh would cause all bootstrap stages to be redone).
svn path=/nixpkgs/trunk/; revision=833
- gcc/ld-wrappers have been factored out into a separate
derivation. This allows a working gcc to be installed in the user
environment. (Previously the Nix gcc didn't work because it
needed a whole bunch of flags to point to glibc.)
- Better modularity: packages can specify hooks into the setup
scripts. For instance, setup no longer knows about the
PKG_CONFIG_PATH variable; pkgconfig can set it up instead.
- gcc not longer depends on binutils. This simplifies the bootstrap
process.
svn path=/nixpkgs/trunk/; revision=816
