there are currently multiple places with installation instructions that
all have to be updated when a change to any of them is accepted.
this reduces the number of places by one, and directs beginners to the
maintained and curated resource for Nix learning materials.
It was disabled in c6953d1ff6 because
a recent Nixpkgs bump brought in a new systemd which changed how
systemd-nspawn worked.
As far as I can tell, the issue was caused by this upstream systemd
commit:
b71a0192c0
Bind-mounting the host's `/sys` and `/proc` into the container's
`/run/host/{sys,proc}` fixes the issue and allows the test to succeed.
Our FreeBSD headers have `pthread_getattr_np`, but we get a link-time
error that is missing. The good news is that there is another similar
function which does exist, and the upstream project elsewhere does just
the [fallback code] we need.
As the fallback code indicates, the two functions are not identical
however as the other one needs explicit initialization. NetBSD supports
both in fact, and its [manpage] is therefore a good
resource on what the differences are.
[fallback code]: 07a6d0ee88/os_dep.c (L1266-L1272)
[manpage]: https://man.netbsd.org/pthread_attr_get_np.3
https://hydra.nixos.org/build/235888160
This is needed because Nixpkgs now contains dangling symlinks
(pkgs/test/nixpkgs-check-by-name/tests/symlink-invalid/pkgs/by-name/fo/foo/foo.nix).
This is broken because of a change in systemd in NixOS 23.05. It fails
with
Failed to mount proc (type proc) on /proc (MS_NOSUID|MS_NODEV|MS_NOEXEC ""): Operation not permitted
there is a very confusing warning in the Nixpkgs manual that
mischaracterises `nix-env` behavior, and this example shows what's
really happening.
note that it doesn't use `pkgs.runCommand` or other `pkgs.stdenv`
facilities, as deep down those set `meta.outputsToInstall` to very
particular defaults that do not generally apply to Nix.
Without this change, nix build processes will not drop the locks for derivation goals
which have already been built by another process when the current process gets
round to building them. This means the locks are held until the process
terminates.
If there are other nix build processes in a similar state, they will also try to
acquire the same locks when they try to build the same derivation, and so will
wait until the lock holder terminates (which might be a very long time if it has
a lot to build). In some pathological cases, those processes might be holding
their own locks on other derivations due to the same issue, and this can lead to
deadlock.
Resolves#6468
