| Age | Commit message (Collapse) | Author |
|---|
|
Don't retry on "unsupported protocol" error
|
|
When encountering an unsupported protocol, there's no need to retry.
Chances are, it won't suddenly be supported between retry attempts;
error instead. Otherwise, you see something like the following:
$ nix-env -i -f git://git@github.com/foo/bar
warning: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1); retrying in 335 ms
warning: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1); retrying in 604 ms
warning: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1); retrying in 1340 ms
warning: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1); retrying in 2685 ms
With this change, you now see:
$ nix-env -i -f git://git@github.com/foo/bar
error: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1)
|
|
This is needed since we no longer produce a source tarball.
(cherry picked from commit bf70a047a0b2da606f65a88f13ce2994065cd9c4)
|
|
This prevents users from accidentally nuking their profile via
nix-env.
(cherry picked from commit 021634e3e3edb327089d33ab41b743f0a40126da)
|
|
libexpr: remove unused attrError
|
|
The attrError variable is no longer used but still allocated on every
call to the findAlongAttrPath function.
|
|
Backport 'nix dev-shell' from the flakes branch
|
|
fix placeholder not substituted in passAsFile
|
|
|
|
|
|
This also adds a '--profile' option to 'nix build' (replacing 'nix-env
--set').
|
|
|
|
(cherry picked from commit 2c692a3b144523bca68dd6de618124ba6c9bb332)
|
|
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.
|
|
|
|
https://hydra.nixos.org/build/110879699
(cherry picked from commit 5bbe793abf18414878a069399d1759673d693fb6)
|
|
(cherry picked from commit e721f99817bb7154d8098c902e25f84521a90b7f)
|
|
(cherry picked from commit 442e665d6d3fcbdee7dece2f62a597142f8784b1)
|
|
Extracted from 678301072f05b650dc15c5edb4c25f08f0d6cace.
|
|
(cherry picked from commit 1bf9eb21b75f0d93d9c1633ea2e6fdf840047e79)
|
|
(cherry picked from commit b82f75464d1e5ae9a00d8004e5dd7b1ca05059e4)
|
|
https://hydra.nixos.org/build/110757285
(cherry picked from commit b430a81a1fbf6c792ba49e3aefe46256263430e5)
|
|
E.g.
$ nix edit .#nixosConfigurations.bla
now works.
(cherry picked from commit d2032edb2f86e955a8a7724a27c0c3225f386500)
|
|
(cherry picked from commit 0b013a54dc570395bed887369f8dd622b8ce337b)
|
|
(cherry picked from commit 6b0ca8e803710342af70e257935724c5ad84ca04)
|
|
(cherry picked from commit 7dcf5b011a0942ecf953f2b607c4c8d0e9e652c7)
|
|
(cherry picked from commit 6529490cc10018d5191e50c482ac1180b96b1a3c)
|
|
(cherry picked from commit c02da997570ac0d9b595d787bea8cb5a4e3cc1f5)
|
|
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.
|
|
installer: Set files read-only when copying into store
|
|
darwin sandbox
|
|
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.
|
|
installer: also test for xz to unpack
|
|
|
|
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).
|
|
Nix now runs builds with a pseudo-terminal to enable colored build
output.
|
|
|
|
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.
|
|
Remove the --delete option for --gc. Fixes #3343
|
|
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
|
|
See 0629601da1d163a059fa19004256961f8ecdeb78.
|
|
Fixes #3175.
|
|
Add missing `#include <regex>`
|
|
|
|
display attr-path only when queried available
|
|
The OpenSSL files were removed in a6ca68a70c3bc0b2e6abad70346c99642a896f9f.
https://salsa.debian.org/debian/nix/issues/3
|
|
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).
|
|
Remove the tarball job
|
