Merge remote-tracking branch 'origin/master' into lazy-trees

.github/CODEOWNERS

@@ -0,0 +1,15 @@
+# Pull requests concerning the listed files will automatically invite the respective maintainers as reviewers.
+# This file is not used for denoting any kind of ownership, but is merely a tool for handling notifications.
+#
+# Merge permissions are required for maintaining an entry in this file.
+# For documentation on this mechanism, see https://help.github.com/articles/about-codeowners/
+
+# Default reviewers if nothing else matches
+* @edolstra @thufschmitt
+
+# This file
+.github/CODEOWNERS @edolstra
+
+# Public documentation
+/doc @fricklerhandwerk
+*.md @fricklerhandwerk

.github/ISSUE_TEMPLATE/bug_report.md

@@ -30,3 +30,7 @@ A clear and concise description of what you expected to happen.
 **Additional context**
 
 Add any other context about the problem here.
+
+**Priorities**
+
+Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).

.github/ISSUE_TEMPLATE/feature_request.md

@@ -18,3 +18,7 @@ A clear and concise description of any alternative solutions or features you've
 
 **Additional context**
 Add any other context or screenshots about the feature request here.
+
+**Priorities**
+
+Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).

.github/ISSUE_TEMPLATE/installer.md

@@ -0,0 +1,36 @@
+---
+name: Installer issue
+about: Report problems with installation
+title: ''
+labels: installer
+assignees: ''
+
+---
+
+## Platform
+
+<!-- select the platform on which you tried to install Nix -->
+
+- [ ] Linux: <!-- state your distribution, e.g. Arch Linux, Ubuntu, ... -->
+- [ ] macOS
+- [ ] WSL
+
+## Additional information
+
+<!-- state special circumstances on your system or additional steps you have taken prior to installation -->
+
+## Output
+
+<details><summary>Output</summary>
+
+```log
+
+<!-- paste console output here and remove this comment -->
+
+```
+
+</details>
+
+## Priorities
+
+Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).

.github/ISSUE_TEMPLATE/missing_documentation.md

@@ -26,3 +26,6 @@ assignees: ''
 
 <!-- propose a solution -->
 
+## Priorities
+
+Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).

.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

@@ -5,3 +5,7 @@ Please include relevant [release notes](https://github.com/NixOS/nix/blob/master
 **Testing**
 
 If this issue is a regression or something that should block release, please consider including a test either in the [testsuite](https://github.com/NixOS/nix/tree/master/tests) or as a [hydraJob]( https://github.com/NixOS/nix/blob/master/flake.nix#L396) so that it can be part of the [automatic checks](https://hydra.nixos.org/jobset/nix/master).
+
+**Priorities**
+
+Add :+1: to [pull requests you find important](https://github.com/NixOS/nix/pulls?q=is%3Aopen+sort%3Areactions-%2B1-desc).

.version

@@ -1 +1 @@
-2.12.0
+2.13.0

doc/manual/src/SUMMARY.md.in

@@ -65,6 +65,7 @@
   - [CLI guideline](contributing/cli-guideline.md)
 - [Release Notes](release-notes/release-notes.md)
   - [Release X.Y (202?-??-??)](release-notes/rl-next.md)
+  - [Release 2.12 (2022-12-06)](release-notes/rl-2.12.md)
   - [Release 2.11 (2022-08-25)](release-notes/rl-2.11.md)
   - [Release 2.10 (2022-07-11)](release-notes/rl-2.10.md)
   - [Release 2.9 (2022-05-30)](release-notes/rl-2.9.md)

doc/manual/src/installation/installing-binary.md

@@ -3,7 +3,7 @@
 The easiest way to install Nix is to run the following command:
 
 ```console
-sh <(curl -L https://nixos.org/nix/install)
+$ sh <(curl -L https://nixos.org/nix/install)
 ```
 
 This will run the installer interactively (causing it to explain what
@@ -27,7 +27,7 @@ you can authenticate with `sudo`.
 To explicitly select a single-user installation on your system:
 
 ```console
-sh <(curl -L https://nixos.org/nix/install) --no-daemon
+$ sh <(curl -L https://nixos.org/nix/install) --no-daemon
 ```
 
 This will perform a single-user installation of Nix, meaning that `/nix`
@@ -37,8 +37,8 @@ if it doesn’t already exist. If you don’t have `sudo`, you should
 manually create `/nix` first as root, e.g.:
 
 ```console
-mkdir /nix
-chown alice /nix
+$ mkdir /nix
+$ chown alice /nix
 ```
 
 The install script will modify the first writable file from amongst
@@ -50,7 +50,7 @@ the install script to disable this behaviour.
 You can uninstall Nix simply by running:
 
 ```console
-rm -rf /nix
+$ rm -rf /nix
 ```
 
 # Multi User Installation
@@ -66,7 +66,7 @@ You can instruct the installer to perform a multi-user installation on
 your system:
 
 ```console
-sh <(curl -L https://nixos.org/nix/install) --daemon
+$ sh <(curl -L https://nixos.org/nix/install) --daemon
 ```
 
 The multi-user installation of Nix will create build users between the
@@ -274,7 +274,7 @@ These install scripts can be used the same as the main NixOS.org
 installation script:
 
 ```console
-sh <(curl -L https://nixos.org/nix/install)
+$ sh <(curl -L https://nixos.org/nix/install)
 ```
 
 In the same directory of the install script are sha256 sums, and gpg
@@ -289,10 +289,10 @@ it somewhere (e.g. in `/tmp`), and then run the script named `install`
 inside the binary tarball:
 
 ```console
-cd /tmp
-tar xfj nix-1.8-x86_64-darwin.tar.bz2
-cd nix-1.8-x86_64-darwin
-./install
+$ cd /tmp
+$ tar xfj nix-1.8-x86_64-darwin.tar.bz2
+$ cd nix-1.8-x86_64-darwin
+$ ./install
 ```
 
 If you need to edit the multi-user installation script to use different

doc/manual/src/release-notes/rl-2.12.md

@@ -0,0 +1,43 @@
+# Release 2.12 (2022-12-06)
+
+* On Linux, Nix can now run builds in a user namespace where they run
+  as root (UID 0) and have 65,536 UIDs available.
+  <!-- FIXME: move this to its own section about system features -->
+  This is primarily useful for running containers such as `systemd-nspawn`
+  inside a Nix build. For an example, see [`tests/systemd-nspawn/nix`][nspawn].
+
+  [nspawn]: https://github.com/NixOS/nix/blob/67bcb99700a0da1395fa063d7c6586740b304598/tests/systemd-nspawn.nix.
+
+  A build can enable this by setting the derivation attribute:
+
+  ```
+  requiredSystemFeatures = [ "uid-range" ];
+  ```
+
+  The `uid-range` [system feature] requires the [`auto-allocate-uids`]
+  setting to be enabled.
+
+  [system feature]: (../command-ref/conf-file.md#conf-system-features)
+
+* Nix can now automatically pick UIDs for builds, removing the need to
+  create `nixbld*` user accounts. See [`auto-allocate-uids`].
+
+  [`auto-allocate-uids`]: (../command-ref/conf-file.md#conf-auto-allocate-uids)
+
+* On Linux, Nix has experimental support for running builds inside a
+  cgroup. See
+  [`use-cgroups`](../command-ref/conf-file.md#conf-use-cgroups).
+
+* `<nix/fetchurl.nix>` now accepts an additional argument `impure` which
+  defaults to `false`.  If it is set to `true`, the `hash` and `sha256`
+  arguments will be ignored and the resulting derivation will have
+  `__impure` set to `true`, making it an impure derivation.
+
+* If `builtins.readFile` is called on a file with context, then only
+  the parts of the context that appear in the content of the file are
+  retained.  This avoids a lot of spurious errors where strings end up
+  having a context just because they are read from a store path
+  ([#7260](https://github.com/NixOS/nix/pull/7260)).
+
+* `nix build --json` now prints some statistics about top-level
+  derivations, such as CPU statistics when cgroups are enabled.

doc/manual/src/release-notes/rl-next.md

@@ -1,58 +1,5 @@
 # Release X.Y (202?-??-??)
 
-* `<nix/fetchurl.nix>` now accepts an additional argument `impure` which
-  defaults to `false`.  If it is set to `true`, the `hash` and `sha256`
-  arguments will be ignored and the resulting derivation will have
-  `__impure` set to `true`, making it an impure derivation.
-
-* If `builtins.readFile` is called on a file with context, then only the parts
-  of that context that appear in the content of the file are retained.
-  This avoids a lot of spurious errors where some benign strings end-up having
-  a context just because they are read from a store path
-  ([#7260](https://github.com/NixOS/nix/pull/7260)).
-
-* Nix can now automatically pick UIDs for builds, removing the need to
-  create `nixbld*` user accounts. These UIDs are allocated starting at
-  872415232 (0x34000000) on Linux and 56930 on macOS.
-
-  This is an experimental feature. To enable it, add the following to
-  `nix.conf`:
-
-  ```
-  extra-experimental-features = auto-allocate-uids
-  auto-allocate-uids = true
-  ```
-
-* On Linux, Nix can now run builds in a user namespace where the build
-  runs as root (UID 0) and has 65,536 UIDs available. This is
-  primarily useful for running containers such as `systemd-nspawn`
-  inside a Nix build. For an example, see
-  https://github.com/NixOS/nix/blob/67bcb99700a0da1395fa063d7c6586740b304598/tests/systemd-nspawn.nix.
-
-  A build can enable this by requiring the `uid-range` system feature,
-  i.e. by setting the derivation attribute
-
-  ```
-  requiredSystemFeatures = [ "uid-range" ];
-  ```
-
-  The `uid-range` system feature requires the `auto-allocate-uids`
-  setting to be enabled (see above).
-
-* On Linux, Nix has experimental support for running builds inside a
-  cgroup. It can be enabled by adding
-
-  ```
-  extra-experimental-features = cgroups
-  use-cgroups = true
-  ```
-
-  to `nix.conf`. Cgroups are required for derivations that require the
-  `uid-range` system feature.
-
-* `nix build --json` now prints some statistics about top-level
-  derivations, such as CPU statistics when cgroups are enabled.
-
 * You can now use flake references in the old CLI, e.g.
 
   ```

maintainers/README.md

@@ -0,0 +1,79 @@
+# Nix maintainers team
+
+## Motivation
+
+The goal of the team is to help other people to contribute to Nix.
+
+## Members
+
+- Eelco Dolstra (@edolstra) – Team lead
+- Théophane Hufschmitt (@thufschmitt)
+- Valentin Gagarin (@fricklerhandwerk)
+- Thomas Bereknyei (@tomberek)
+- Robert Hensing (@roberth)
+
+## Meeting protocol
+
+The team meets twice a week:
+
+- Discussion meeting: [Fridays 13:00-14:00 CET](https://calendar.google.com/calendar/event?eid=MHNtOGVuNWtrZXNpZHR2bW1sM3QyN2ZjaGNfMjAyMjExMjVUMTIwMDAwWiBiOW81MmZvYnFqYWs4b3E4bGZraGczdDBxZ0Bn)
+
+  1. Triage issues and pull requests from the _No Status_ column (30 min)
+  2. Discuss issues and pull requests from the _To discuss_ column (30 min)
+
+- Work meeting: [Mondays 13:00-15:00 CET](https://calendar.google.com/calendar/event?eid=NTM1MG1wNGJnOGpmOTZhYms3bTB1bnY5cWxfMjAyMjExMjFUMTIwMDAwWiBiOW81MmZvYnFqYWs4b3E4bGZraGczdDBxZ0Bn)
+
+  1. Code review on pull requests from _In review_.
+  2. Other chores and tasks.
+
+Meeting notes are collected on a [collaborative scratchpad](https://pad.lassul.us/Cv7FpYx-Ri-4VjUykQOLAw), and published on Discourse under the [Nix category](https://discourse.nixos.org/c/dev/nix/50).
+
+## Project board protocol
+
+The team uses a [GitHub project board](https://github.com/orgs/NixOS/projects/19/views/1) for tracking its work.
+
+Issues on the board progress through the following states:
+
+- No Status
+
+  Team members can add pull requests or issues to discuss or review together.
+
+  During the discussion meeting, the team triages new items.
+  If there is disagreement on the general idea behind an issue or pull request, it is moved to _To discuss_, otherwise to _In review_.
+
+- To discuss
+
+  Pull requests and issues that are important and controversial are discussed by the team during discussion meetings.
+
+  This may be where the merit of the change itself or the implementation strategy is contested by a team member.
+
+- In review
+
+  Pull requests in this column are reviewed together during work meetings.
+  This is both for spreading implementation knowledge and for establishing common values in code reviews.
+
+  When the overall direction is agreed upon, even when further changes are required, the pull request is assigned to one team member.
+
+- Assigned for merging
+
+  One team member is assigned to each of these pull requests.
+  They will communicate with the authors, and make the final approval once all remaining issues are addressed.
+
+  If more substantive issues arise, the assignee can move the pull request back to _To discuss_ to involve the team again.
+
+The process is illustrated in the following diagram:
+
+```mermaid
+flowchart TD
+    discuss[To discuss]
+
+    review[To review]
+
+    New --> |Disagreement on idea| discuss
+    New & discuss --> |Consensus on idea| review
+
+    review --> |Consensus on implementation| Assigned
+
+    Assigned --> |Implementation issues arise| review
+    Assigned --> |Remaining issues fixed| Merged
+```

scripts/install-multi-user.sh

@@ -97,7 +97,8 @@ is_os_darwin() {
 }
 
 contact_us() {
-    echo "You can open an issue at https://github.com/nixos/nix/issues"
+    echo "You can open an issue at"
+    echo "https://github.com/NixOS/nix/issues/new?labels=installer&template=installer.md"
     echo ""
     echo "Or feel free to contact the team:"
     echo " - Matrix: #nix:nixos.org"

src/libstore/build/derivation-goal.cc

@@ -501,6 +501,14 @@ void DerivationGoal::inputsRealised()
                now-known results of dependencies. If so, we become a
                stub goal aliasing that resolved derivation goal. */
             std::optional attempt = fullDrv.tryResolve(worker.store, inputDrvOutputs);
+            if (!attempt) {
+              /* TODO (impure derivations-induced tech debt) (see below):
+                 The above attempt should have found it, but because we manage
+                 inputDrvOutputs statefully, sometimes it gets out of sync with
+                 the real source of truth (store). So we query the store
+                 directly if there's a problem. */
+              attempt = fullDrv.tryResolve(worker.store);
+            }
             assert(attempt);
             Derivation drvResolved { *std::move(attempt) };
 

src/libstore/globals.hh

@@ -284,7 +284,22 @@ public:
         )"};
 
     Setting<bool> autoAllocateUids{this, false, "auto-allocate-uids",
-        "Whether to allocate UIDs for builders automatically."};
+        R"(
+          Whether to select UIDs for builds automatically, instead of using the
+          users in `build-users-group`.
+
+          UIDs are allocated starting at 872415232 (0x34000000) on Linux and 56930 on macOS.
+
+          > **Warning**
+          > This is an experimental feature.
+
+          To enable it, add the following to [`nix.conf`](#):
+
+          ```
+          extra-experimental-features = auto-allocate-uids
+          auto-allocate-uids = true
+          ```
+        )"};
 
     Setting<uint32_t> startId{this,
         #if __linux__
@@ -308,11 +323,22 @@ public:
     Setting<bool> useCgroups{
         this, false, "use-cgroups",
         R"(
-          Whether to execute builds inside cgroups. Cgroups are
-          enabled automatically for derivations that require the
-          `uid-range` system feature.
-        )"
-    };
+          Whether to execute builds inside cgroups.
+          This is only supported on Linux.
+
+          Cgroups are required and enabled automatically for derivations 
+          that require the `uid-range` system feature.
+
+          > **Warning**
+          > This is an experimental feature.
+
+          To enable it, add the following to [`nix.conf`](#):
+
+          ```
+          extra-experimental-features = cgroups
+          use-cgroups = true
+          ```
+        )"};
     #endif
 
     Setting<bool> impersonateLinux26{this, false, "impersonate-linux-26",

src/libutil/util.cc

@@ -730,7 +730,7 @@ unsigned int getMaxCPU()
         auto cgroupFS = getCgroupFS();
         if (!cgroupFS) return 0;
 
-        auto cgroups = getCgroups("/proc/self/cgroupp");
+        auto cgroups = getCgroups("/proc/self/cgroup");
         auto cgroup = cgroups[""];
         if (cgroup == "") return 0;