The `remote-store` test loads the `user-env` one to test nix-env when
using the daemon, but actually does it incorrectly because every test
starts (in `common.sh`) by resetting the value of `NIX_REMOTE`, meaning
that the `user-env` test will never use the daemon.
Fix this by setting `NIX_REMOTE_` before sourcing `user-env.sh` in the
`remote-store` test, so that `NIX_REMOTE` is correctly set inside the
test
(cherry picked from commit f6ac888d3e)
Otherwise, when running as root and user namespaces are enabled,
opening the slave fails with EPERM.
Fixes "opening pseudoterminal slave: Permission denied" followed by a
hang (https://hydra.nixos.org/build/213104244), and "error: getting
sandbox mount namespace: No such file or directory" (#8072), which
happens when the child fails very quickly and consequently reading
/proc/<child>/ns fails.
(cherry picked from commit 16db8dc96f)
Hopefully this fixes "unexpected EOF" failures on macOS
(#3137, #3605, #7242, #7702).
The problem appears to be that under some circumstances, macOS
discards the output written to the slave side of the
pseudoterminal. Hence the parent never sees the "sandbox initialized"
message from the child, even though it succeeded. The conditions are:
* The child finishes very quickly. That's why this bug is likely to
trigger in nix-env tests, since that uses a builtin builder. Adding
a short sleep before the child exits makes the problem go away.
* The parent has closed its duplicate of the slave file
descriptor. This shouldn't matter, since the child has a duplicate
as well, but it does. E.g. moving the close to the bottom of
startBuilder() makes the problem go away. However, that's not a
solution because it would make Nix hang if the child dies before
sending the "sandbox initialized" message.
* The system is under high load. E.g. "make installcheck -j16" makes
the issue pretty reproducible, while it's very rare under "make
installcheck -j1".
As a fix/workaround, we now open the pseudoterminal slave in the
child, rather than the parent. This removes the second condition
(i.e. the parent no longer needs to close the slave fd) and I haven't
been able to reproduce the "unexpected EOF" with this.
(cherry picked from commit c536e00c9d)
This was originally added in #4770 to support structured attrs in
`nix-shell` & `nix develop`: the issue was that it was somewhat awkward
to just write those files into a project directory, especially since
it'd break in case of multiple `nix-shell` invocations from the same
directory. Now the files are written to another, temporary
location when using `nix-shell`/`nix develop` and the correct path is
referenced by NIX_ATTRS_*_FILE.
In `nixpkgs`, it's now common to use these environment variables,
however we still fall back to checking to `.attrs.sh` & `.attrs.json`
since the minimum Nix version we support is 2.3.17[1] which doesn't have
this change.
This however makes implementing structured attrs support more
complicated than needed[2] and in fact we have a few places where the
check for `.attrs.sh`/`.attrs.json` isn't made, so these only break with
Nix 2.3[3].
The idea is now to
* get this into 2.3.18
* bump minver once again to 2.3.18 in nixpkgs
* remove all occurrences of `.attrs.sh`/`.attrs.json` from nixpkgs.
[1] f4bd97b8fa/lib/minver.nix
[2] https://github.com/NixOS/nixpkgs/pull/357053/files#diff-791a01ef89c157eb74d9c87ab8cbc3b81e2cf082cab70b8fec3472cd75ce860dR3-R5
[3] https://github.com/NixOS/nixpkgs/pull/357053#discussion_r1857362490
It is possible to exfiltrate a file descriptor out of the build sandbox
of FODs, and use it to modify the store path after it has been
registered.
To avoid that issue, don't register the output of the build, but a copy
of it (that will be free of any leaked file descriptor).
Otherwise the result of the printing can't be parsed back correctly by
Nix (because the unescaped `${` will be parsed as the begining of an
anti-quotation).
Fix#3989
(cherry picked from commit 250f8a4bba)
Without the change llvm build fails on this week's gcc-13 snapshot as:
src/libutil/json.cc: In function 'void nix::toJSON(std::ostream&, const char*, const char*)':
src/libutil/json.cc:33:22: error: 'uint16_t' was not declared in this scope
33 | put(hex[(uint16_t(*i) >> 12) & 0xf]);
| ^~~~~~~~
src/libutil/json.cc:5:1: note: 'uint16_t' is defined in header '<cstdint>'; did you forget to '#include <cstdint>'?
4 | #include <cstring>
+++ |+#include <cstdint>
5 |
(cherry picked from commit b36d5172cb)
At least on OpenBSD, tar(1) reads from /dev/rst0 not stdin by default
options must specififed consistently with or without dashes, not mixed.
Specify standard input explicitly to not rely on implementation details.
Use either option style consistently.
