| Age | Commit message (Collapse) | Author |
|---|
|
add maintainers' handbook
|
|
|
|
|
|
add CODEOWNERS
|
|
encourage adding 👍 to express interest
|
|
Lower verbosity of exceptions in getMaxCPU()
|
|
Change "while evaluating <fun>" to "while *calling*" in trace
|
|
The old way was not correct.
Here is an example:
```
$ nix-instantiate --eval --expr 'let x = a: throw "asdf"; in x 1' --show-trace
error: asdf
… while evaluating 'x'
at «string»:1:9:
1| let x = a: throw "asdf"; in x 1
| ^
… from call site
at «string»:1:29:
1| let x = a: throw "asdf"; in x 1
| ^
```
and yet also:
```
$ nix-instantiate --eval --expr 'let x = a: throw "asdf"; in x' --show-trace
<LAMBDA>
```
Here is the thing: in both cases we are evaluating `x`!
Nix is a higher-order languages, and functions are a sort of value. When
we write `x = a: ...`, `a: ...` is the expression that `x` is being
defined to be, and that is already a value. Therefore, we should *never*
get an trace that says "while evaluating `x`", because evaluating `a:
...` is *trival* and nothing happens during it!
What is actually happening here is we are applying `x` and evaluating
its *body* with arguments substituted for parameters. I think the
simplest way to say is just "while *calling* `x`", and so that is what I
changed it to.
|
|
Fixes #7268.
|
|
doc: listToAttrs: document repeated keys
|
|
Also, don't assume in LocalDerivationGoal that cgroups are mounted on
/sys/fs/cgroup.
|
|
|
|
docs: drop shell prompt character for consistency
|
|
decided on the @NixOS/documentation-team, see NixOS/nix.dev#359 for more information
|
|
|
|
Really fix 'nix store make-content-addressed --json'
|
|
https://hydra.nixos.org/log/mcgypcf9vj4n8vdmw7lj3l05c899v73w-nix-2.12.0pre20221201_16b03f0-x86_64-unknown-linux-musl.drv
|
|
|
|
|
|
add missing newline, for consistent formatting
|
|
|
|
nix store make-content-addressed: Fix JSON construction
|
|
Fixes
error: [json.exception.type_error.301] cannot create object from initializer list
in tests/fetchClosure.sh.
|
|
refactor rendering documentation of builtins
|
|
Automatic UID allocation
|
|
|
|
Add nobody user/group to Nix docker image
|
|
repl: print a newline on ctrl-D
|
|
NixOS/dependabot/github_actions/zeebe-io/backport-action-0.0.9
Bump zeebe-io/backport-action from 0.0.8 to 0.0.9
|
|
|
|
Bumps [zeebe-io/backport-action](https://github.com/zeebe-io/backport-action) from 0.0.8 to 0.0.9.
- [Release notes](https://github.com/zeebe-io/backport-action/releases)
- [Commits](https://github.com/zeebe-io/backport-action/compare/v0.0.8...v0.0.9)
---
updated-dependencies:
- dependency-name: zeebe-io/backport-action
dependency-type: direct:production
update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>
|
|
|
|
|
|
|
|
Replace src/libutil/json.cc with nlohmann
|
|
in order to avoid potential problems with the progress bar
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
|
|
|
|
|
|
|
Fix random client failures during GC server shutdown
|
|
We need to close the GC server socket before shutting down the active
GC client connections, otherwise a client may (re)connect and get
ECONNRESET. But also handle ECONNRESET for resilience.
Fixes random failures like
GC socket disconnected
connecting to '/tmp/nix-shell.y07M0H/nix-test/default/var/nix/gc-socket/socket'
sending GC root '/tmp/nix-shell.y07M0H/nix-test/default/store/kb5yzija0f1x5xkqkgclrdzldxj6nnc6-non-blocking'
reading GC root from client: error: unexpected EOF reading a line
1 store paths deleted, 0.00 MiB freed
error: reading from file: Connection reset by peer
in gc-non-blocking.sh.
|
|
Don't use GC_STRNDUP
|
|
It calls strlen() on the input (rather than simply copying at most
`size` bytes), which can fail if the input is not zero-terminated and
is inefficient in any case.
Fixes #7347.
|
|
as in [1], make the document structure visible, like in a template
[1]: 4655563470b59e0ef50a33af003058c2b54db778
|
|
|
|
Fix why-depends for CA derivations
|
|
|
|
why-depends assumed that we knew the output path of the second argument.
For CA derivations, we might not know until it's built. One way to solve
this would be to build the second installable to get the output path.
In this case we don't need to, though. If the first installable (A)
depends on the second (B), then getting the store path of A will
necessitate having the store path B. The contrapositive is, if the store
path of B is not known (i.e. it's a CA derivation which hasn't been
built), then A does not depend on B.
|
|
|
|
|
