With Rust 1.61, it is necessary to link to external static/dynamic libaries
when building the rlib that uses them, rather than when linking the final
binary. In fact, it is no longer necessary to specify the libraries to link
when building the final binary, but the library search path flags must still
be included.
The fetchgit function in nixpkgs sets the leaveDotGit argument to true
if deepClone is set to true. nix-prefetch-git did behave differently. It
would not assume --leave-dotGit if --deepClone is specified. With this
change the inconsistency is addressed by assuming --leave-dotGit if
--deepClone is specified.
When maintainers override stages of `fetchgit' (e.g. `postPatch`) it
is very easy for them to accidentally leak the outpath-hash of their
current `stdenv` into `fetchgit''s output, and therefore into the
value they paste into `sha256`.
This is a problem, because the resulting expression will break
whenever any change is made to `stdenv` or when anybody attempts to
build the expression on a different platform than the one used by the
original maintainer.
Almost as much of a problem is the fact that CI **does not catch**
these problems. The `fetchgit` is run only once, then its output goes
into cachix, and all future builds (hydra, CI, ofborg) pull from
cachix.
Let's offer maintainers the option to check that they aren't making
this mistake, by passing through `allowedRequisites`. The default
value is `null`, but it might be worth changing that at some point in
the future.
It is also sometimes difficult to communicate to package maintainers
why their expression is problematic. Having `allowedRequisites`
passed through makes it easier to do this: "look, when I switch on
`allowedRequisites` your package breaks; are you sure you meant to
hardcode the hash today's `x86_64-linux.stdenv` into your expression?`
For an example use case, see https://github.com/NixOS/nixpkgs/pull/171223
The issue above is part of a larger problem with nixpkgs infra: there
large parts of cachix cannot be reproduced easily if they are lost.
Once something ends goes into cachix, we never ever again reverify the
procedure by which it was placed into cachix.
musl and darwin support UTF-8 locales without any extras. As a result
unzip can unpack UTF-8 filenames there as is. But on glibc without
locale archive presence files get mangled as:
deps/αβ -> deps/#U03b1#U03b2
This makes `fetchzip` fixed-output derivations unstable.
Tested this change to fail in `coq.src` which was generated in system
that mangles UTF-8 symbols:
$ nix build -f. coq.src --rebuild -L
source> trying https://github.com/coq/coq/archive/V8.15.2.zip
source> % Total % Received % Xferd Average Speed Time Time Time Current
source> Dload Upload Total Spent Left Speed
source> 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0
source> 100 8945k 100 8945k 0 0 1513k 0 0:00:05 0:00:05 --:--:-- 1989k
source> unpacking source archive /build/V8.15.2.zip
error: hash mismatch in fixed-output derivation '/nix/store/hrnyykm7wgw8vxisgq7hc2bg5gr0y6s8-source.drv':
specified: sha256-h81nFqkuvZkMR7YLHy7laTq5yOhjMW+w6rYzncxvyD4=
got: sha256-DTspmwyD3Evl1CUmvUy2MonbLGUezvsHN3prmP9eK2I=
Note: it means that some of existing caches for fixed output
derivations become incorrect. It should not break already cached
tarballs on cache.nixos.org thus the impact should not be widespread.
This enables users to make use of clang's multi-platform/target support
without having to go through full cross system setup. This is especially useful
for generating bpf object files, I'm not even usre what would a no-userland
cross compile system tuple even look like to even try going that route.
Fixes#176128
Otherwise, these warnings are emitted:
command-line option '-Wformat=1' is valid for C/C++/ObjC/ObjC++ but not for Fortran
command-line option '-Wformat-security' is valid for C/C++/ObjC/ObjC++ but not for Fortran
'-Werror=' argument '-Werror=format-security' is not valid for Fortran
Fixes part of #27218
- put `findlib` in `buildInputs` of `mkCoqDerivation` to make sure `coq` packages find their ocaml plugin dependencies,
- use `propagatedBuildInputs` to make sure ocaml plugin dependencies are in path,
- updated `coqPackage.heq` (broken url),
- fixed use of `DESTDIR` and `COQMF_COQLIB` in mkCoqDerivation,
- adding `COQCORELIB` environement variable to put ocaml plugin files in the right place,
- make `metaFetch` available from `coqPackages`
a67950f20b added `url` attribute
from `fetchurl` and therefore also from `fetchzip`.
We previously relied on `url` from fetchgit-based fetchers
to find the repo URL but now it will just return tarballs
in the case of `fetchFrom{GitHub,GitLab}`.
Let’s add an attribute to `fetch{git,FromGitHub,FromGitLab}`
to expose a repo URL consistently.
* 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
...
This should be a significant disk space saving for most NixOS
installations. This method is a bit more complicated than doing it in
the postInstall for the firmware derivations, but this way it's
automatic, so each firmware package doesn't have to separately
implement its compression.
Currently, only xz compression is supported, but it's likely that
future versions of Linux will additionally support zstd, so I've
written the code in such a way that it would be very easy to implement
zstd compression for those kernels when they arrive, falling back to
xz for older (current) kernels.
I chose the highest possible level of compression (xz -9) because even
at this level, decompression time is negligible. Here's how long it took
to decompress every firmware file my laptop uses:
i915/kbl_dmc_ver1_04.bin 2ms
regulatory.db 4ms
regulatory.db.p7s 3ms
iwlwifi-7265D-29.ucode 62ms
9d71-GOOGLE-EVEMAX-0-tplg.bin 22ms
intel/dsp_fw_kbl.bin 65ms
dsp_lib_dsm_core_spt_release.bin 6ms
intel/ibt-hw-37.8.10-fw-22.50.19.14.f.bseq 7ms
And since booting NixOS is a parallel process, it's unlikely (but
difficult to measure) that the time to user interaction was held up at
all by most of these.
Fixes (partially?) #148197
The old logic flow had the structure
if ( … ) {
if ( … ) {
…
} else {
…
}
} else {
…
}
which is quite hard to follow in Nix. Instead we ensure that no if
expression is inside a then branch.
This change is zero rebuild, as no logic was changed.
- use propagatedBuildInputs to make sure ocaml plugin stuff is in path
- updated coqPackage.heq (broken url)
- fixed use of `DESTDIR` and `COQMF_COQLIB` in mkCoqDerivation
- adding `COQCORELIB` environement variable to put ocaml plugin files in the right place
- make metaFetch available from `coqPackages`
A small shell script that can be used to extract a binary wrapper's
makeCWrapper call from its embedded docstring, without depending on
makeBinaryWrapper.
As far as I can tell, this has never actually done anything, as
LDEMULATION is not exported. I tried exporting it and builds broke,
and as it doesn't seem to have caused any problems as a noop all these
years it didn't seem worth investigating further.
This parameter is being set to `$NIX_BUILD_CORES` by default. This is a
standard practice but there's a suspicion that this can produce broken
builds. For some details see
https://github.com/cargo2nix/cargo2nix/issues/184 . As a
work-around/test, it'd be good if codegen-units can be set to something
constant, such as `1`. This PR allows it.
Note that the default of `$NIX_BUILD_CORES` is preserved so this MR
causes no change in default behaviour and no rebuilds.
Take a "nixSupport" argument that is an attrset of lists to append
to "$out/nix-support/${name}" where name is the name of the
attribute. This attrset is available from the passthru of the
wrapped compiler.
This is an alternative to imperatively issuing flags with
extraBuildCommands and makes it possible to append or filter
flags with an override.
Previously buildDotnetModule did not properly inherit some arguments from
derivations, take for example this expression:
dotnetFlags = [
"--runtime linux-x64"
];
It would error out as follows: "MSBUILD : error MSB1001: Unknown switch.".
Setting the same flag from bash would work fine. This fixes that, all
arguments should now be properly interpreted :)
There used to be a few issues with the way we generate the nuget source:
* The derivation generated for the deps would have "nuget-deps" in them twice:
/nix/store/...-foo-1.0-nuget-deps-nuget-deps
* We always tried to generate the dependencies for "projectReferences"
even when it wasn't set, causing a warning.
This fixes those issues :)
This improves the metadata generation, previously it would take any
"license" entry from the nuspec, and tried to match it to an spdx ID from
"lib.licenses".
Sometimes however licenses are provided in plain-text, which we
obviously cannot cleanly resolve. This resulted in in useless information
("LICENSE.txt") being written to "meta.license".
It's impossible to pass arguments with spaces with curlOpts.
curlOptsList supports that. Passing a list to curlOpts has been
deprecated. This commit is fully backwards compatible.
Examples: support has to be added to https://github.com/nix-community/nixdoc
'nixdoc --category testers --description "nixpkgs testers" --file ./pkgs/build-support/testers/default.nix'
we will have more testers in the future so they should have their own
location
putting 'testers' in args will also make it simpler to use multiple testers
This commits changes the Emacs wrapper, in order to preload all autoload
definitions when built with additional packages. The list of all
definitions is generated at build-time. Packages do not need to
be (require)d for them to work.
Before this change, a code like
```sh
nix-shell -I "nixpkgs=$PWD" -p "emacs.pkgs.withPackages(e:[e.magit])" \
--run "emacs -Q -nw -f magit"
```
will fail with the message `Symbol’s function definition is void: magit`
After the change, the same code above will open Emacs with magit
enabled.
A slightly longer startup time of ~10ms was detected in local, informal
experiments.
More information on autoloading:
https://www.gnu.org/software/emacs/manual/html_node/eintr/Autoload.html
These features are internal-only, have special characters that bash
doesn't support in variable names, and aren't normally given
environment variables by cargo as far as I can tell.
This commit fixes precise dependency ignorance by converting the
environment variable `autoPatchelfIgnoreMissingDeps` into a bash array
`ignoreMissingDepsArray`, passing `"${ignoreMissingDepsArray[@]}"`
instead of `"${autoPatchelfIgnoreMissingDeps[@]}"` to the python
script.
The original implementation does not work when
`autoPatchelfIgnoreMissingDeps` contains multiple dependency names.
Because it mistakenly passes `"${autoPatchelfIgnoreMissingDeps[@]}"`
to the python script. According to the Nix manual
(https://nixos.org/manual/nix/stable/expressions/derivations.html),
lists of strings are concatenated into whitespace-separated strings,
then passed to the builder as environment variables. So, if
`autoPatchelfIgnoreMissingDeps = [ "dep1" "dep2" "dep3" ]`,
`"${autoPatchelfIgnoreMissingDeps[@]}"` will be expanded to a single
argument `"dep1 dep2 dep3"`, which is not the intended behavior,
because the python script takes the long argument as a dependency
name.
With this commit, `"${ignoreMissingDepsArray[@]}"` will be expanded to
three arguments `"dep1" "dep2" "dep3"` arguments as expected, fixing
the issue.
cpio includes the number of directory hard links in archives it creates.
Some filesystems, like btrfs, do not count directory hard links the same
way as more common filesystems like ext4 or tmpfs, so archives built
when /tmp is on such a filesystem do not reproduce. This patch replaces
cpio with bsdtar, which does not have this issue. The specific
invocation is from this page:
https://reproducible-builds.org/docs/archives/
before
$ nix build ".#whipper.tests.version"
whipper> File "/nix/store/2iiyy58pmm1ys6dy8ycbmmmfm67iakv1-whipper-0.10.0/bin/.whipper-wrapped", line 6, in <module>
whipper> File "/nix/store/2iiyy58pmm1ys6dy8ycbmmmfm67iakv1-whipper-0.10.0/lib/python3.9/site-packages/whipper/__init__.py", line 5, in <module>
note: keeping build directory '/tmp/nix-build-whipper-0.10.0-test-version.drv-7'
after
$ nix build ".#whipper.tests.version"
whipper> Traceback (most recent call last):
whipper> File "/nix/store/2iiyy58pmm1ys6dy8ycbmmmfm67iakv1-whipper-0.10.0/bin/.whipper-wrapped", line 6, in <module>
whipper> from whipper.command.main import main
whipper> File "/nix/store/2iiyy58pmm1ys6dy8ycbmmmfm67iakv1-whipper-0.10.0/lib/python3.9/site-packages/whipper/__init__.py", line 5, in <module>
whipper> from pkg_resources import (get_distribution,
whipper> ModuleNotFoundError: No module named 'pkg_resources'
note: keeping build directory '/tmp/nix-build-whipper-0.10.0-test-version.drv-34'
error: builder for '/nix/store/5lxjicdhwgmjcz9ddlxgq3s3gyaa6lz4-whipper-0.10.0-test-version.drv' failed with exit code 1;
Desktop files are only useful when accompanied by the binaries they
specify. So it makes more sense to put them next to the binaries rather
than `$out` which only usually contains the binaries.
