- Jul 23, 2016
-
-
Shea Levy authored
Fixes #977
-
- Jul 21, 2016
-
-
Shea Levy authored
-
Eelco Dolstra authored
-
Eelco Dolstra authored
-
Eelco Dolstra authored
-
Eelco Dolstra authored
-
Eelco Dolstra authored
For one particular NixOS configuration, this cut the runtime of "nix-store -r --dry-run" from 6m51s to 3.4s. It also fixes a bug in the size calculation that was causing certain paths to be counted twice, e.g. before: these paths will be fetched (1249.98 MiB download, 2995.74 MiB unpacked): and after: these paths will be fetched (1219.56 MiB download, 2862.17 MiB unpacked):
-
Langston Barrett authored
-
Eelco Dolstra authored
-
Eelco Dolstra authored
This speeds up queries against the binary cache.
-
Eelco Dolstra authored
Fix spec file
-
Eelco Dolstra authored
-
Matthias Beyer authored
Once upon a time, I wrote my bachelors thesis about functional deployment mechanisms. I had to evaluate several szenarios where package management and deployment were relevant. One szenario was to do distributed builds over several machines. I told myself: Weee, nix can do this! And with nix, this is actually save, as you do not have side effects when building! So I started. I use a cloud to set up four virtual machines where I wanted to do the build. A fifth machine was used as master to distribute the builds. All was good. I created the necessary SSH keys, made sure every machine was reachable by the master and configured the build in my remotes.conf. When I started to try to build weechat from source, the build failed. It failed, telling me error: unable to start any build; either increase ‘--max-jobs’ or enable distributed builds And I started to dig around. I digged long and good. But I wasn't able to find the issue. I double and triple checked my environment variables, my settings, the SSH key and everything. I reached out to fellow Nixers by asking on the nixos IRC channel. And I got help. But we weren't able to find the issue, either. So I became frustrated. I re-did all the environment variables. And suddenly,... it worked! What did I change? Well... I made the environment variables which contained pathes contain absolute pathes rather than relatives. And because I like to share my knowledge, this should be put into the documentation, so others do not bang their heads against the wall because something is not documented somewhere.
-
Eelco Dolstra authored
-
- Jul 20, 2016
-
-
Marc Scholten authored
-
Domen Kožar authored
-
Dmitry Kalinkin authored
Fixes: a6ca68a7 ("Require OpenSSL")
-
- Jul 13, 2016
- Jul 11, 2016
-
-
Shea Levy authored
-
- Jul 04, 2016
-
-
Eelco Dolstra authored
Don't hardcode docbook XSL namespace URL
-
aszlig authored
Docbook XSL got updated to version 1.79.1 in NixOS/nixpkgs@fb893a8 and we're still referring to the hardcoded previous version. So instead of just updating this to 1.79.1 we're going to use "current" in the hope that this won't happen again. I have tested this by building the manual under Nix(OS) but I haven't tested this in a non-Nix environment, so I'm not sure whether this could have implications. Signed-off-by:
aszlig <aszlig@redmoonstudios.org> Cc: @edolstra
-
- Jul 01, 2016
-
-
Timothy Allen authored
-
Timothy Allen authored
Since we now chmod /nix/store at install time, we don't need to do it in the post install script. We still chgrp in the post-install, because the nixbld group doesn't exist at install time.
-
Timothy Allen authored
-
Timothy Allen authored
The Nix download page only mentions the .xz source tarball, so that's what people are likely to have available. This means that somebody who downloads a Nix source tarball can turn it directly into an RPM with `rpmbuild -ta nix-*.tar.xz`.
-
Timothy Allen authored
Nix expects build users to be in the "nixbld" group. You can change that in the config file, but `nix.spec` does not ship with a config file, so we should use the defaults.
-
- Jun 20, 2016
-
-
Eelco Dolstra authored
-
- Jun 17, 2016
-
-
Eelco Dolstra authored
Looks like these were accidentally commented out in 9ffc4f43.
-
- Jun 16, 2016
-
-
Eelco Dolstra authored
Remove nix-copy-closure reference note from nix-store docs
-
- Jun 15, 2016
-
-
Johannes 'fish' Ziemke authored
nix-copy-closure is not using nix-store directly anymore.
-
- Jun 09, 2016
-
-
Eelco Dolstra authored
This way, all builds appear to have a uid/gid of 0 inside the chroot. In the future, this may allow using programs like systemd-nspawn inside builds, but that will require assigning a larger UID/GID map to the build. Issue #625.
-
Eelco Dolstra authored
-
- Jun 03, 2016
-
-
Eelco Dolstra authored
-
Eelco Dolstra authored
This allows an unprivileged user to perform builds on a diverted store (i.e. where the physical store location differs from the logical location). Example: $ NIX_LOG_DIR=/tmp/log NIX_REMOTE="local?real=/tmp/store&state=/tmp/var" nix-build -E \ 'with import <nixpkgs> {}; runCommand "foo" { buildInputs = [procps nettools]; } "id; ps; ifconfig; echo $out > $out"' will do a build in the Nix store physically in /tmp/store but logically in /nix/store (and thus using substituters for the latter).
-
Eelco Dolstra authored
-
Eelco Dolstra authored
-