| Age | Commit message (Collapse) | Author |
|---|
|
Fixes https://github.com/NixOS/nix/issues/2009.
|
|
|
|
Fixes #1905
|
|
|
|
|
|
constant memory
Just because we can.
|
|
|
|
|
|
For instance, this reduced the memory consumption of
$ nix copy --from ssh://localhost --to ~/my-nix /nix/store/1n7x0yv8vq6zi90hfmian84vdhd04bgp-blender-2.79a
from 632 MiB to 16 MiB.
|
|
|
|
This avoids sandbox annoyances.
|
|
|
|
|
|
|
|
E.g.
cannot build on 'ssh://mac1': cannot connect to 'mac1': bash: nix-store: command not found
cannot build on 'ssh://mac2': cannot connect to 'mac2': Host key verification failed.
cannot build on 'ssh://mac3': cannot connect to 'mac3': Received disconnect from 213... port 6001:2: Too many authentication failures
Authentication failed.
|
|
also document it
|
|
copyStorePath() now pipes the output of srcStore->narFromPath()
directly into dstStore->addToStore(). The sink used by the former is
converted into a source usable by the latter using
boost::coroutine2. This is based on [1].
This reduces the maximum resident size of
$ nix build --store ~/my-nix/ /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1 --substituters file:///tmp/binary-cache-xz/ --no-require-sigs
from 418592 KiB to 53416 KiB. (The previous commit also reduced the
runtime from ~4.2s to ~3.4s, not sure why.) A further improvement will
be to download files into a Sink.
[1] https://github.com/NixOS/nix/compare/master...Mathnerd314:dump-fix-coroutine#diff-dcbcac55a634031f9cc73707da6e4b18
Issue #1969.
|
|
This allows decompression to happen in O(1) memory.
|
|
The certificates won't get any better if we retry.
|
|
Wrap thread local in function for Cygwin
|
|
Actually fixes #1976.
|
|
Note that this only requires headers from boost so it doesn't add a
runtime dependency.
Also, use Nixpkgs 18.03.
|
|
|
|
Fixes #1826. See #1352 for a previous instance of a similar change.
|
|
|
|
rand() requires we call srand() instead,
but might as well use random().
|
|
This can be iterated on and currently leaves out settings we know we
want to forward, but it fixes #1713 and fixes #1935 and isn't
fundamentally broken like the status quo. Future changes are suggested
in a comment.
|
|
|
|
|
|
well
|
|
generation is not the one we are deleting
|
|
|
|
|
|
This allows building armv[67]l-linux derivations on compatible aarch64
machines. Failure to add the architecture may result from missing
hardware support, in which case we can't run 32-bit binaries and don't
need to restrict them with seccomp anyway,
|
|
This allows specifying additional systems that a machine is able to
build for. This may apply on some armv7-capable aarch64 processors, or
on systems using qemu-user with binfmt-misc to support transparent
execution of foreign-arch programs.
This removes the previous hard-coded assumptions about which systems are
ABI-compatible with which other systems, and instead relies on the user
to specify any additional platforms that they have ensured compatibility
for and wish to build for locally.
NixOS should probably add i686-linux on x86_64-linux systems for this
setting by default.
|
|
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.
|
|
https://hydra.nixos.org/eval/1434547#tabs-now-fail
|
|
Running Nix with build users without seccomp on Linux is dangerous,
and administrators should very explicitly opt-in to it.
|
|
|
|
This is needed for new arches where libseccomp support doesn't exist
yet.
Fixes #1878.
|
|
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
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Fixes #1340.
|
