| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
ssh-ng: also store build logs to make them accessible by `nix log`
|
|
|
|
|
|
Fixes
nix-daemon: src/libstore/sqlite.cc:97: nix::SQLiteStmt::Use::Use(nix::SQLiteStmt&): Assertion `stmt.stmt' failed.
which happens because the daemon doesn't properly handle the case
where ca-derivations isn't enabled at daemon startup.
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #6193.
|
|
|
|
|
|
A few notes:
* The `echo hi` is needed to make sure that a file that can be read by
`nix log` is properly created (i.e. some output is needed). This is
known and to be fixed in #6051.
* We explicitly ignore the floating-CA case here: the `$out` of `input3`
depends on `$out` of `input2`. This means that there are actually two
derivations - I assume that this is because at eval time (i.e.
`nix-instantiate -A`) the hash of `input2` isn't known yet and the
other .drv is created as soon as `input2` was built. This is another
issue on its own, so we ignore the case here explicitly.
|
|
- Make sure that it starts even without the `nix-command` xp feature
- Fail if it doesn’t manage to start
This fixes a 30s wait for every test in `init.sh` as the daemon couldn’t
start, but the code was just waiting 30s and continuing as if everything
was all right.
|
|
Replace defaultBla.$system with bla.$system.default
|
|
testS: poll more eagerly for the daemon start/stop
|
|
Polling every 1 second means that even the simplest test takes at least
2 seconds. We can reasonably poll 1/10 of that to make things much
quicker (esp. given that most of the time 0.1s is enough for the
daemon to be started or stopped)
|
|
The tests are scheduled in the order they appear, so running the long
ones first slightly improves the scheduling.
On my machine, this decreases the time of `make install` from 40s to 36s
|
|
|
|
This also simplifies some InstallableFlake logic and fixes 'nix
bundle' parsing its installable twice.
Fixes #5532.
|
|
fix nix repl not overriding existing bindings in :a
|
|
previously :a would override old bindings of a name with new values if the added
set contained names that were already bound. in nix 2.6 this doesn't happen any
more, which is potentially confusing.
fixes #6041
|
|
|
|
Flake follows: resolve all follows to absolute
|
|
It's not possible in general to know in computeLocks, relative to
which path the follows was intended to be. So, we always resolve
follows to their absolute states when we encounter them (which can
either be in parseFlakeInput or computeLocks' fake input population).
Fixes https://github.com/NixOS/nix/issues/6013
Fixes https://github.com/NixOS/nix/issues/5609
Fixes https://github.com/NixOS/nix/issues/5697 (again)
|
|
|
|
|
|
|
|
Bundlers are now responsible for correctly handling their inputs which
are no longer constrained to be (Drv->Drv)->Drv->Drv, but can be of
type (attrset->Drv)->attrset->Drv.
|
|
It’s totally valid to have entries in `NIX_PATH` that aren’t valid paths
(they can even be arbitrary urls or `channel:<channel-name>`).
Fix #5998 and #5980
|
|
|
|
Always good to have :)
|
|
Follow-up from #5969
Fix #5982
|
|
|
|
Fixes
$ nix-instantiate --parse -E 'x: with x; _'
(x: (with x; __curPos))
|
|
|
|
Make `nix search` highlight all regexes and matches
|
|
tests: skip flake search test if no git is present
|
|
Fix segfault or stack overflow caused by large derivation fields
|
|
|
|
Make `nix why-depends` quieter by default
|
|
|
|
if we defer the duplicate argument check for lambda formals we can use more
efficient data structures for the formals set, and we can get rid of the
duplication of formals names to boot. instead of a list of formals we've seen
and a set of names we'll keep a vector instead and run a sort+dupcheck step
before moving the parsed formals into a newly created lambda. this improves
performance on search and rebuild by ~1%, pure parsing gains more (about 4%).
this does reorder lambda arguments in the xml output, but the output is still
stable. this shouldn't be a problem since argument order is not semantically
important anyway.
before
nix search --no-eval-cache --offline ../nixpkgs hello
Time (mean ± σ): 8.550 s ± 0.060 s [User: 6.470 s, System: 1.664 s]
Range (min … max): 8.435 s … 8.666 s 20 runs
nix eval -f ../nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix
Time (mean ± σ): 346.7 ms ± 2.1 ms [User: 312.4 ms, System: 34.2 ms]
Range (min … max): 343.8 ms … 353.4 ms 20 runs
nix eval --raw --impure --expr 'with import <nixpkgs/nixos> {}; system'
Time (mean ± σ): 2.720 s ± 0.031 s [User: 2.415 s, System: 0.231 s]
Range (min … max): 2.662 s … 2.780 s 20 runs
after
nix search --no-eval-cache --offline ../nixpkgs hello
Time (mean ± σ): 8.462 s ± 0.063 s [User: 6.398 s, System: 1.661 s]
Range (min … max): 8.339 s … 8.542 s 20 runs
nix eval -f ../nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix
Time (mean ± σ): 329.1 ms ± 1.4 ms [User: 296.8 ms, System: 32.3 ms]
Range (min … max): 326.1 ms … 330.8 ms 20 runs
nix eval --raw --impure --expr 'with import <nixpkgs/nixos> {}; system'
Time (mean ± σ): 2.687 s ± 0.035 s [User: 2.392 s, System: 0.228 s]
Range (min … max): 2.626 s … 2.754 s 20 runs
|
|
This removes a dynamic stack allocation, making the derivation
unparsing logic robust against overflows when large strings are
added to a derivation.
Overflow behavior depends on the platform and stack configuration.
For instance, x86_64-linux/glibc behaves as (somewhat) expected:
$ (ulimit -s 20000; nix-instantiate tests/lang/eval-okay-big-derivation-attr.nix)
error: stack overflow (possible infinite recursion)
$ (ulimit -s 40000; nix-instantiate tests/lang/eval-okay-big-derivation-attr.nix)
error: expression does not evaluate to a derivation (or a set or list of those)
However, on aarch64-darwin:
$ nix-instantiate big-attr.nix ~
zsh: segmentation fault nix-instantiate big-attr.nix
This indicates a slight flaw in the single stack protection page
approach that is not encountered with normal stack frames.
|
|
Unless `--precise` is passed, make `nix why-depends` only show the
dependencies between the store paths, without introspecting them to
find the actual references.
This also makes it ~3x faster
|
|
|
|
|
