- Jun 09, 2016
-
-
Eelco Dolstra authored
-
- May 30, 2016
-
-
Domen Kožar authored
-
- May 04, 2016
-
-
Eelco Dolstra authored
-
Eelco Dolstra authored
-
Eelco Dolstra authored
-
- Mar 11, 2016
-
-
Nathan Zadoks authored
Alpine seems to use this, and it results in a wrong builtins.currentSystem. Big-endian ARM systems have triples starting with armv6eb- or armv7eb-, so this doesn't change any systems that already worked.
-
- Mar 03, 2016
-
-
Nathan Zadoks authored
-
- Jan 12, 2016
-
-
Eelco Dolstra authored
This reverts commit 80ebd60e. The reason why we cleared CFLAGS/CXXFLAGS was because otherwise we get a default value of -O2, which interferes with the defaults set in the Makefile. (E.g. "make OPTIMIZE=0" should not pass -O2.)
-
- Jan 05, 2016
-
-
Ilya Novoselov authored
Looks like 5a05cf40 removed usage of environment CFLAGS and CXXFLAGS by mistake. That change broke building of nix on fedora core 23.
-
- Dec 10, 2015
-
-
Eelco Dolstra authored
Also, use "#if __APPLE__" instead of "#if SANDBOX_ENABLED" to prevent ambiguity.
-
- Nov 07, 2015
-
-
Danny Wilson authored
d_type is not part of the POSIX spec unfortunately.
-
- Nov 04, 2015
-
-
Eelco Dolstra authored
-
- Oct 30, 2015
-
-
Eelco Dolstra authored
-
- Oct 21, 2015
-
-
Jude Taylor authored
-
- Mar 27, 2015
-
- Feb 16, 2015
-
-
Harald van Dijk authored
chroot only changes the process root directory, not the mount namespace root directory, and it is well-known that any process with chroot capability can break out of a chroot "jail". By using pivot_root as well, and unmounting the original mount namespace root directory, breaking out becomes impossible. Non-root processes typically have no ability to use chroot() anyway, but they can gain that capability through the use of clone() or unshare(). For security reasons, these syscalls are limited in functionality when used inside a normal chroot environment. Using pivot_root() this way does allow those syscalls to be put to their full use.
-
- Feb 10, 2015
-
-
Eelco Dolstra authored
-
- Feb 04, 2015
-
-
Eelco Dolstra authored
Sodium's Ed25519 signatures are much shorter than OpenSSL's RSA signatures. Public keys are also much shorter, so they're now specified directly in the nix.conf option ‘binary-cache-public-keys’. The new command ‘nix-store --generate-binary-cache-key’ generates and prints a public and secret key.
-
- Nov 25, 2014
-
-
Eelco Dolstra authored
-
- Sep 22, 2014
-
-
Eelco Dolstra authored
-
- Sep 17, 2014
-
-
Eelco Dolstra authored
-
Eelco Dolstra authored
-
Eelco Dolstra authored
-
- Jul 10, 2014
-
-
Eelco Dolstra authored
-
- May 26, 2014
-
-
Eelco Dolstra authored
-
- Feb 01, 2014
-
-
Eelco Dolstra authored
-
- Jan 21, 2014
-
-
Eelco Dolstra authored
-
- Jan 09, 2014
-
-
Eelco Dolstra authored
-
- Nov 25, 2013
-
-
Eelco Dolstra authored
This way, we can use config.status for generating scripts/* (without ending up with lines like "#! /usr/bin/perl -I${libexecdir}/...").
-
Eelco Dolstra authored
-
Eelco Dolstra authored
-
Eelco Dolstra authored
-
- Nov 22, 2013
-
-
Eelco Dolstra authored
-
Eelco Dolstra authored
-
- Nov 14, 2013
-
-
Eelco Dolstra authored
AFAIK, nobody uses it, it's not maintained, and it has no tests.
-
- Aug 19, 2013
-
-
Eelco Dolstra authored
-
- Aug 07, 2013
-
-
Eelco Dolstra authored
On a system with multiple CPUs, running Nix operations through the daemon is significantly slower than "direct" mode: $ NIX_REMOTE= nix-instantiate '<nixos>' -A system real 0m0.974s user 0m0.875s sys 0m0.088s $ NIX_REMOTE=daemon nix-instantiate '<nixos>' -A system real 0m2.118s user 0m1.463s sys 0m0.218s The main reason seems to be that the client and the worker get moved to a different CPU after every call to the worker. This patch adds a hack to lock them to the same CPU. With this, the overhead of going through the daemon is very small: $ NIX_REMOTE=daemon nix-instantiate '<nixos>' -A system real 0m1.074s user 0m0.809s sys 0m0.098s
-
- Aug 06, 2013
-
-
Eelco Dolstra authored
-
- Jul 12, 2013
-
-
Gergely Risko authored
-
- Mar 25, 2013
-
-
Shea Levy authored
makeStoreWritable: Use statvfs instead of /proc/self/mountinfo to find out if /nix/store is a read-only bind mount /nix/store could be a read-only bind mount even if it is / in its own filesystem, so checking the 4th field in mountinfo is insufficient. Signed-off-by:
Shea Levy <shea@shealevy.com>
-