| Age | Commit message (Collapse) | Author |
|---|
|
A [recent-ish change](https://github.com/NixOS/nix/pull/6676) logs a warning when a potentially counterintuitive situation happens.
This now causes the multi-user installer to [emit a warning](https://github.com/NixOS/nixpkgs/issues/189043) when it's doing
the "seed the Nix database" step via a low-level `nix-store --load-db` invocation.
`nix-store` functionality implementations don't actually use profiles or channels or homedir as far as i can tell. So why are we
hitting this code at all?
Well, the current command approach for functionality here builds a [fat `nix` binary](https://github.com/NixOS/nix/blob/master/src/nix/local.mk#L23-L26) which has _all_ the functionality of
previous individual binaries (nix-env, nix-store, etc) bundled in, then [uses the invocation name](https://github.com/NixOS/nix/blob/master/src/nix/main.cc#L274-L277) to select the
set of commands to expose. `nix` itself has this behavior, even when just trying to parse the (sub)command and arguments:
```
dave @ davembp2
$ nix
error: no subcommand specified
Try 'nix --help' for more information.
dave @ davembp2
$ sudo nix
warning: $HOME ('/Users/dave') is not owned by you, falling back to the one defined in the 'passwd' file
error: no subcommand specified
Try 'nix --help' for more information.
dave @ davembp2
$ HOME=~root sudo nix
error: no subcommand specified
Try 'nix --help' for more information.
```
This behavior can also be seen pretty easily with an arbitrary `nix-store` invocation:
```
dave @ davembp2
$ nix-store --realize
dave @ davembp2
$ sudo nix-store --realize # what installer is doing now
warning: $HOME ('/Users/dave') is not owned by you, falling back to the one defined in the 'passwd' file
dave @ davembp2
$ sudo HOME=~root nix-store --realize # what this PR effectively does
dave @ davembp2
$
```
|
|
GitHub Workflows security hardening
|
|
do not render relative links in help pages
|
|
|
|
this simplifies the setup a lot, and avoids weird looking `./file.md`
links showing up.
it also does not show regular URLs any more. currently the command
reference only has few of them, and not showing them in the offline
documentation is hopefully not a big deal.
instead of building more special-case solutions, clumsily preprocessing
the input, or issuing verbal rules on dealing with URLs, should better
be solved sustainably by not rendering relative links in `lowdown`:
https://github.com/kristapsdz/lowdown/issues/105
|
|
fix(libstore): allow access to trustd on macOS
|
|
Bump version
|
|
|
|
Prepare release
|
|
Fix progress bar flicker with -L
|
|
|
|
|
|
This was caused by -L calling setLogFormat() again, which caused the
creation of a new progress bar without destroying the old one. So we
had two progress bars clobbering each other.
We should change 'logger' to be a smart pointer, but I'll do that in a
future PR.
Fixes #6931.
|
|
Fix evaluation cache
|
|
98e361ad4c1a26d4ffe4762a6f33bb9e39321a39 introduced a regression where
previously stored attributes were replaced by placeholders. As a
result, a command like 'nix build nixpkgs#hello' had to be executed at
least twice to get caching.
This code does not seem necessary for suggestions to work.
|
|
|
|
Make nix copy parallel again
|
|
|
|
|
|
darwin-install: fix shell hint
|
|
Fix a misplaced parenthese in serve protocol check
|
|
This issue made it impossible for clients using a serve protocol of
version <= 2.3 to use the `cmdBuildDerivation` command of servers using
a protocol of version >= 2.6. The faulty version check makes the server
send back build outputs that the client is not expecting.
|
|
|
|
nix develop: Ignore some more bash special variables
|
|
JSON: print paths as strings without copying them to the store
|
|
Fixes #6940.
|
|
docker.nix: Provide boolean for whether to bundle nixpkgs
|
|
nix-shell: specify which outputs from bashInteractive to build
|
|
|
|
reword description of language properties
|
|
This hang for some reason didn't trigger in the Nix build, but did
running 'make installcheck' interactively. What happened:
* Store::addMultipleToStore() calls a SinkToSource object to copy a
path, which in turn calls LegacySSHStore::narFromPath(), which
acquires a connection.
* The SinkToSource object is not destroyed after the last bytes has
been read, so the coroutine's stack is still alive and its
destructors are not run. So the connection is not released.
* Then when the next path is copied, because max-connections = 1,
LegacySSHStore::narFromPath() hangs forever waiting for a connection
to be released.
The fix is to make sure that the source object is destroyed when we're
done with it.
|
|
|
|
|
|
nix repl: Stop the progress bar
|
|
after `nix eval --json` and `nix-instantiate --eval --json`.
|
|
Makes `printValueAsJSON` not copy paths to the store for `nix eval
--json`, `nix-instantiate --eval --json` and `nix-env --json`.
Fixes https://github.com/NixOS/nix/issues/5612
|
|
add a nix.conf option to set a download speed limit
|
|
Fix default profile path for root in nix profile documentation
|
|
The repl was broken since c3769c68465bae971ab6bb48cfcdea85b61ea83a. In
general, the progress bar is incompatible with the repl.
|
|
Avoid producing incomplete JSON
|
|
|
|
Installer: Don't assume TMPDIR ends in a slash
|
|
install: only create $TMPDIR if missing
|
|
Co-authored-by: Anderson Torres <torres.anderson.85@protonmail.com>
|
|
|
|
|
|
|
|
don't read outputs into memory for output rewriting
|
|
RewritingSink can handle being fed input where a reference crosses a
chunk boundary. we don't need to load the whole source into memory, and
in fact *not* loading the whole source lets nix build FODs that do not
fit into memory (eg fetchurl'ing data files larger than system memory).
|
|
|
