Commit graph

7346 commits

Author SHA1 Message Date
Bjørn Forsman 6864ad7cf5 fetchGit: fix submodule output attribute
Before this change it would be false for all evaluations but the first.
Now it follows the input argument (as it should).
2020-03-29 22:29:58 +02:00
Bjørn Forsman 587e259bfd tests/fetchGitSubmodules: add more tests 2020-03-29 22:29:58 +02:00
Bjørn Forsman 002a3a95dc fetchGit: fix "fatal: couldn't find remote ref refs/heads/master" issue with submodules 2020-03-29 22:29:58 +02:00
Julian Stecklina cc4fe977e5 Link to stdc++fs
Some platforms seem to still require linking with stdc++fs to enable
STL std::filesystem support.
2020-03-29 22:29:58 +02:00
Julian Stecklina 6c00a9545f Fix typo in submodule test 2020-03-29 22:29:58 +02:00
Julian Stecklina 435366ed3c Rename fetchGit fetchSubmodules to just submodules 2020-03-29 22:29:58 +02:00
Julian Stecklina c846abb5cc Add more test for git submodule functionality 2020-03-29 22:29:58 +02:00
Julian Stecklina c8d33de777 Add git submodule fixes from @bjornfor
This fixes fetching repositories with no submodules and also cleans up
.git files in checkouts.
2020-03-29 22:29:57 +02:00
Julian Stecklina ea861be292 Add documentation for submodule support in fetchGit 2020-03-29 22:29:57 +02:00
Julian Stecklina c2a24c2b88 Add test for fetchGit submodule support 2020-03-29 22:29:57 +02:00
Julian Stecklina f58604ac32 Add fetchSubmodules to builtins.fetchGit
There are some downsides to this features:

 - Submodules are not cached (unlike the root repo),
 - Full checkouts are created in a temporary directory.
2020-03-29 22:29:57 +02:00
Eelco Dolstra eb1911e277
Merge pull request #3445 from gnprice/pr-installer-colors
installer: Fix terminal colors.
2020-03-25 09:04:24 +01:00
Greg Price 7313aa267b installer: Fix terminal colors.
The install-multi-user script uses blue, green, and red colors, as
well as bold and underline, to add helpful formatting that helps
structure its rather voluminous output.

Unfortunately, the terminal escape sequences it uses are not quite
well-formed.  The relevant information is all there, just obscured
by some extra noise, a leading parameter `38`.  Empirically, the
result is:

 * On macOS, in both Terminal.app and iTerm2, the spurious `38` is
   ignored, the rest of the escape sequence is applied, and the colors
   show up as intended.

 * On Linux, in at least gnome-terminal and xterm, the spurious `38`
   and the next parameter after it are ignored, and what's left is
   applied.  So in the sequence `38;4;32`, the 4 (underline) is
   ignored but the 32 (green) takes effect; in a more typical sequence
   like `38;34`, the 34 (blue) is ignored and nothing happens.

These codes are all unchanged since this script's origins as a
Darwin-only script -- so the fact that they work fine in common macOS
terminals goes some way to explain how the bug arose.

Happily, we can make the colors work as intended by just deleting the
extra `38;`.  Tested in all four terminals mentioned above; the new
codes work correctly on all of them, and on the two macOS terminals
they work exactly the same as before.

---

In a bit more technical detail -- perhaps more than anyone, me
included, ever wanted to know, but now that I've gone and learned it
I'll write it down anyway :) -- here's what's happening in these codes:

An ECMA-48 "control sequence" begins with `\033[` aka "CSI", contains
any number of parameters as semicolon-separated decimal numbers (plus
sometimes other wrinkles), and ends with a byte from 0x40..0x7e.  In
our case, with `m` aka "SGR", "Select Graphic Rendition".

An SGR control sequence `\033[...m` sets colors, fonts, text styles,
etc.  In particular a parameter `31` means red, `32` green, `34` blue,
`4` underline, and `0` means reset to normal.  Those are all we use.

There is also a `38`.  This is used for setting colors too... but it
needs arguments.  `38;5;nn` is color nn from a 256-color palette, and
`38;2;rr;gg;bb` has the given RGB values.

There is no meaning defined for `38;1` or `38;34` etc.  On seeing a
parameter `38` followed by an unrecognized argument for it, apparently
some implementations (as seen on macOS) discard only the `38` and
others (as seen on Linux) discard the argument too before resuming.
2020-03-24 21:15:01 -07:00
Eelco Dolstra 0a10854f85 Misc changes from the flakes branch 2020-03-24 14:34:47 +01:00
Eelco Dolstra c85097da7c Fix --refresh with --no-net
https://hydra.nixos.org/build/110879699
(cherry picked from commit 5bbe793abf)
2020-03-24 14:26:23 +01:00
Eelco Dolstra 6b824c78f1 nix: Add --refresh as an alias for --tarball-ttl 0
(cherry picked from commit e721f99817)
2020-03-24 14:26:23 +01:00
Eelco Dolstra 777e21e596 nix path-info --json: Print hash in SRI format
(cherry picked from commit 442e665d6d)
2020-03-24 14:26:23 +01:00
Eelco Dolstra 7a8de57d3e Pretty-print 'nix why-depends' / 'nix-store -q --tree' output
Extracted from 678301072f.
2020-03-24 14:26:23 +01:00
Eelco Dolstra 4260a22a55 absPath(): Use std::optional
(cherry picked from commit 1bf9eb21b7)
2020-03-24 14:25:28 +01:00
Eelco Dolstra f9611c7ae4 buildenv: Eliminate global variables, other cleanup
(cherry picked from commit b82f75464d)
2020-03-24 14:06:47 +01:00
Eelco Dolstra 76e7d958ed Fix coverage build
https://hydra.nixos.org/build/110757285
(cherry picked from commit b430a81a1f)
2020-03-24 14:06:47 +01:00
Eelco Dolstra 231a8aa2c2 nix edit: Support non-derivation attributes
E.g.

  $ nix edit .#nixosConfigurations.bla

now works.

(cherry picked from commit d2032edb2f)
2020-03-24 14:06:47 +01:00
Eelco Dolstra c1ca4f0acc findAlongAttrPath(): Return position
(cherry picked from commit 0b013a54dc)
2020-03-24 14:06:47 +01:00
Eelco Dolstra 1eb952d27a findAlongAttrPath(): Throw AttrPathNotFound
(cherry picked from commit 6b0ca8e803)
2020-03-24 14:06:47 +01:00
Eelco Dolstra edc34cc1a2 Add function for quoting strings
(cherry picked from commit 7dcf5b011a)
2020-03-24 13:44:04 +01:00
Eelco Dolstra 5a7e7fc35f Use std::string_view
(cherry picked from commit 6529490cc1)
2020-03-24 13:26:37 +01:00
Eelco Dolstra c34a20e1f6 EvalState::allocAttr(): Add convenience method
(cherry picked from commit c02da99757)
2020-03-24 13:26:37 +01:00
Domen Kožar ddc6aaa8b2
Merge pull request #3441 from gnprice/pr-doc-store-ro
doc: Files in the store have modes 444/555, not 644/755
2020-03-24 10:26:50 +01:00
Greg Price e40e01c1dd doc: Files in the store have modes 444/555, not 644/755
This line has been this way since it was written, in 9e08f5efe
in 2006.

I think it was just a small mistake then; Eelco's thesis earlier
that year says the permission on each file is set to 0444 or 0555
in a derivation's output as part of the build process.  In any
case I'm pretty sure that's the behavior now.
2020-03-23 20:23:27 -07:00
Eelco Dolstra 160edd3f5d
Merge pull request #3440 from gnprice/pr-install-ro
installer: Set files read-only when copying into store
2020-03-23 09:14:12 +01:00
Eelco Dolstra 5885e20404
Merge pull request #3429 from LnL7/darwin-sandbox
darwin sandbox
2020-03-23 09:13:36 +01:00
Greg Price 26851dd2c2 installer: Set files read-only when copying into store
After installing Nix, I found that all the files and directories
initially copied into the store were writable, with mode 644 or 755:

  drwxr-xr-x 9 root root 4096 Dec 31  1969 /nix/store/ddmmzn4ggz1f66lwxjy64n89864yj9w9-nix-2.3.3

The reason is that that's how they were in the unpacked tarball, and
the install-multi-user script used `rsync -p` without doing anything
else to affect the permissions.

The plain `install` script for a single-user install takes care to
do a `chmod -R a-w` on each store path copied.  We could do the same
here with one more command; or we can pass `--chmod` to rsync, to
have it write the files with the desired modes in the first place.

Tested the new `rsync` command on both a Linux machine with a
reasonably-modern rsync (3.1.3) and a Mac with its default, ancient,
rsync 2.6.9, and it works as expected on both.  Thankfully the latter
is just new enough to have `--chmod`, which dates to rsync 2.6.7.
2020-03-22 23:07:20 -07:00
Domen Kožar 7bc1961e1f
Merge pull request #3431 from pmiddend/install-script-test-for-xz
installer: also test for xz to unpack
2020-03-21 10:40:16 +01:00
Philipp Middendorf 9450dece24 installer: also test for xz to unpack 2020-03-21 09:31:39 +01:00
Daiderd Jordan 2e9bc1245c
sandbox: fix /bin/sh on catalina
Sadly 10.15 changed /bin/sh to a shim which executes bash, this means it
can't be used anymore without also opening up the sandbox to allow bash.

    Failed to exec /bin/bash as variant for /bin/sh (1: Operation not permitted).
2020-03-20 22:12:30 +01:00
Daiderd Jordan f6c122aaeb
sandbox: allow pty devices
Nix now runs builds with a pseudo-terminal to enable colored build
output.
2020-03-20 21:58:45 +01:00
Daiderd Jordan 7f2df903d9
libstore: relax default sandbox-paths on darwin 2020-03-20 21:31:20 +01:00
Daiderd Jordan afb78ebd34
libstore: disable resolve-system-dependencies hook
This is used to determine the dependency tree of impure libraries so nix
knows what paths to open in the sandbox.  With the less restrictive
defaults it isn't needed anymore.
2020-03-20 21:21:56 +01:00
Eelco Dolstra 4ef43198f3
Merge pull request #3426 from jakobrs/remote-gc-delete-opt
Remove the --delete option for --gc. Fixes #3343
2020-03-20 09:34:20 +01:00
jakobrs c5a488afc0 Remove the --delete option for --gc
Running `nix-store --gc --delete` will, as of Nix 2.3.3, simply fail
because the --delete option conflicts with the --delete operation.

  $ nix-store --gc --delete
  error: only one operation may be specified
  Try 'nix-store --help' for more information.

Furthermore, it has been broken since at least Nix 0.16 (which was
released sometime in 2010), which means that any scripts which depend
on it should have been broken at least nine years ago. This commit
simply formally removes the option. There should be no actual difference
in behaviour as far as the user is concerned: it errors with the exact
same error message. The manual has been edited to remove any references
to the (now gone) --delete option.

Other information:
* Path for Nix 0.16 used:
  /nix/store/rp3sgmskn0p0pj1ia2qwd5al6f6pinz4-nix-0.16
2020-03-19 19:41:23 +01:00
Eelco Dolstra ef74fafc03
nix repl: Put EvalState on the heap
See 0629601da1.
2020-03-19 13:52:28 +01:00
Eelco Dolstra b244e65cdb
nix repl: Scan NixRepl for GC roots
Fixes #3175.
2020-03-19 13:50:01 +01:00
Eelco Dolstra b79b81dd2d
Merge pull request #3413 from Ericson2314/include-regex
Add missing `#include <regex>`
2020-03-14 09:25:06 +01:00
John Ericson 68fe0d9809 Add missing #include <regex> 2020-03-13 21:24:35 -04:00
Eelco Dolstra 779ef8f5ef
Merge pull request #3380 from contrun/no-attr-path-for-installed
display attr-path only when queried available
2020-03-13 19:26:20 +01:00
Eelco Dolstra 59c37112a9 README.md: Remove reference to OpenSSL
The OpenSSL files were removed in a6ca68a70c.

https://salsa.debian.org/debian/nix/issues/3
2020-03-13 18:42:53 +01:00
Eelco Dolstra 5392884eb1 Remove the 'release' job
Unless the 'tested' job in the Nixpkgs/NixOS jobsets, this job isn't
actually used for anything (e.g. we don't update a channel based on
whether 'release' succeeds).
2020-03-13 18:34:10 +01:00
Eelco Dolstra a692f90c80
Merge pull request #3410 from edolstra/no-tarball
Remove the tarball job
2020-03-13 18:20:09 +01:00
Eelco Dolstra 7c39201bcb
Remove the tarball job
Source tarballs are not very useful anymore. People who want to build
from source can also just build from the Git repository. Once upon a
time, the source tarball also saved users from needing a few
dependencies (e.g. bison and flex) but those are dwarfed by the other
dependencies, so it's no longer worth it.

Note: the release script should be updated to copy the vendoredCrates
tarball.
2020-03-13 18:05:22 +01:00
YI b6d794fb8d display attr-path only when queried available 2020-03-14 00:36:26 +08:00