| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
Otherwise, running e.g.
nix-instantiate --eval -E --strict 'builtins.replaceStrings [""] ["X"] "abc"'
would just hang in an infinite loop.
Found by afl-fuzz.
First attempt of this was reverted in e2d71bd1862cdda because it caused
another infinite loop, which is fixed now and a test added.
|
|
Note that clearenv() is not available on macOS.
Fixes #1907.
|
|
E.g.
nix run --store ~/my-nix -f channel:nixos-17.03 hello -c hello
This problem was mentioned in #1897.
|
|
|
|
This reverts commit ddc58e789636e1b94149c342575d92583251fbf6.
https://hydra.nixos.org/eval/1435322
|
|
|
|
The overhead of sandbox builds is a problem on NixOS (since building a
NixOS configuration involves a lot of small derivations) but not for
typical non-NixOS use cases. So outside of NixOS we can enable it.
Issue #179.
|
|
|
|
Alos add a command "nix ping-store" to make it easier to see if Nix
can connect to a remote builder (e.g. 'nix ping-store --store
ssh://mac').
|
|
This reverts commit 4ea9707591beceacf9988b3c185faf50da238403.
It causes an infinite loop in Nixpkgs evaluation,
e.g. "nix-instantiate -A hello" hung.
PR #1886.
|
|
|
|
maybe a left-over from nix-store -r ?
|
|
The assertion is broken because there is no one-to-one mapping from
length of a base64 string to the length of the output.
E.g.
"1q69lz7Empb06nzfkj651413n9icx0njmyr3xzq1j9q=" results in a 32-byte output.
"1q69lz7Empb06nzfkj651413n9icx0njmyr3xzq1j9qy" results in a 33-byte output.
To reproduce, evaluate:
builtins.derivationStrict {
name = "0";
builder = "0";
system = "0";
outputHashAlgo = "sha256";
outputHash = "1q69lz7Empb06nzfkj651413n9icx0njmyr3xzq1j9qy";
}
Found by afl-fuzz.
|
|
Otherwise, running e.g.
nix-instantiate --eval -E --strict 'builtins.replaceStrings [""] ["X"] "abc"'
would just hang in an infinite loop.
Found by afl-fuzz.
|
|
E.g. nix-instantiate --eval -E 'abort "\r"' hangs.
Found by afl-fuzz.
|
|
Avoids ~180,000 string temporaries created when evaluating a headless
NixOS system.
|
|
https://hydra.nixos.org/eval/1434547#tabs-now-fail
|
|
Also add some examples to nix --help.
|
|
Don't silently succeed seccomp setup when !HAVE_SECCOMP.
|
|
|
|
Running Nix with build users without seccomp on Linux is dangerous,
and administrators should very explicitly opt-in to it.
|
|
|
|
|
|
configure.ac: check if lzma has MT support, fix deb build/etc.
|
|
This is needed for new arches where libseccomp support doesn't exist
yet.
Fixes #1878.
|
|
|
|
drvName is already assigned to the same value right at the start of the
function.
|
|
|
|
Boehm guarantees that memory returned by GC_malloc() is zeroed, so take
advantage of that.
|
|
Instead of having lexicographicOrder() create a temporary sorted array
of Attr*:s and copying attr names from that, copy the attr names
first and then sort that.
|
|
Avoids some malloc() traffic.
|
|
Set MANPATH in case man path isn’t set correctly.
|
|
Previously, this would fail at startup for non-NixOS installs:
nix-env --help
The fix for this is to just use "nixManDir" as the value for MANPATH
when spawning "man".
To test this, I’m using the following:
$ nix-build release.nix -A build
$ MANPATH= ./result/bin/nix-env --help
Fixes #1627
|
|
Fixes #1871.
|
|
Fixes #1868.
|
|
|
|
Allow includes from nix.conf
|
|
|
|
nix-store --export, nix-store --dump, and nix dump-path would previously
fail silently if writing the data out failed, because
a) FdSink::write ignored exceptions, and
b) the commands relied on FdSink's destructor, which ignores
exceptions, to flush the data out.
This could cause rather opaque issues with installing nixos, because
nix-store --export would happily proceed even if it couldn't write its
data out (e.g. if nix-store --import on the other side of the pipe
failed).
This commit adds tests that expose these issues in the nix-store
commands, and fixes them for all three.
|
|
|
|
|
|
|
|
Nix stats: flatten statistics
|
|
|
|
This was caused by derivations with 'allowSubstitutes = false'. Such
derivations will be built locally. However, if there is another
SubstitionGoal that has the output of the first derivation in its
closure, then the path will be simultaneously built and substituted.
There was a check to catch this situation (via pathIsLockedByMe()),
but it no longer worked reliably because substitutions are now done in
another thread. (Thus the comment 'It can't happen between here and
the lockPaths() call below because we're not allowing multi-threading'
was no longer valid.)
The fix is to handle the path already being locked in both
SubstitutionGoal and DerivationGoal.
|
