Merge remote-tracking branch 'origin/master' into multithreaded-eval

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,3 +1,22 @@
+<!--
+
+IMPORTANT
+
+Nix is a non-trivial project, so for your contribution to be successful,
+it really is important to follow the contributing guidelines:
+
+https://github.com/NixOS/nix/blob/master/CONTRIBUTING.md
+
+Even if you've contributed to open source before, take a moment to read it,
+so you understand the process and the expectations.
+
+- what information to include in commit messages
+- proper attribution
+- volunteering contributions effectively
+- how to get help and our review process.
+
+-->
+
 # Motivation
 <!-- Briefly explain what the change is about and why it is desirable. -->
 

.github/workflows/ci.yml

@@ -49,6 +49,7 @@ jobs:
           done
         ) &
     - run: nix --experimental-features 'nix-command flakes' flake check -L
+    - run: nix --experimental-features 'nix-command flakes' flake show --all-systems --json
 
   # Steps to test CI automation in your own fork.
   # Cachix:
@@ -145,7 +146,7 @@ jobs:
       with:
         install_url: https://releases.nixos.org/nix/nix-2.20.3/install
     - run: echo CACHIX_NAME="$(echo $GITHUB_REPOSITORY-install-tests | tr "[A-Z]/" "[a-z]-")" >> $GITHUB_ENV
-    - run: echo NIX_VERSION="$(nix --experimental-features 'nix-command flakes' eval .\#default.version | tr -d \")" >> $GITHUB_ENV
+    - run: echo NIX_VERSION="$(nix --experimental-features 'nix-command flakes' eval .\#nix.version | tr -d \")" >> $GITHUB_ENV
     - uses: cachix/cachix-action@v15
       if: needs.check_secrets.outputs.cachix == 'true'
       with:
@@ -195,20 +196,6 @@ jobs:
       - uses: DeterminateSystems/magic-nix-cache-action@main
       - run: nix build -L .#hydraJobs.tests.githubFlakes .#hydraJobs.tests.tarballFlakes .#hydraJobs.tests.functional_user
 
-  meson_build:
-    strategy:
-      fail-fast: false
-      matrix:
-        os: [ubuntu-latest, macos-latest]
-    runs-on: ${{ matrix.os }}
-    steps:
-      - uses: actions/checkout@v4
-      - uses: DeterminateSystems/nix-installer-action@main
-      - uses: DeterminateSystems/magic-nix-cache-action@main
-      # Only meson packages that don't have a tests.run derivation.
-      # Those that have it are already built and tested as part of nix flake check.
-      - run: nix build -L .#hydraJobs.build.{nix-cmd,nix-main}.$(nix-instantiate --eval --expr builtins.currentSystem | sed -e 's/"//g')
-
   flake_regressions:
     needs: vm_tests
     runs-on: ubuntu-22.04

CONTRIBUTING.md

@@ -52,6 +52,20 @@ Check out the [security policy](https://github.com/NixOS/nix/security/policy).
 
      Link related issues to inform interested parties and future contributors about your change.
      If your pull request closes one or multiple issues, mention that in the description using `Closes: #<number>`, as it will then happen automatically when your change is merged.
+   * Credit original authors when you're reusing or building on their work.
+   * Link to relevant changes in other projects, so that others can understand the full context of the change in the future when you or someone else will change or troubleshoot the code.
+     This is especially important when your change is based on work done in other repositories.
+
+     Example:
+     ```
+     This is based on the work of @user in <url>.
+     This solution took inspiration from <url>.
+
+     Co-authored-by: User Name <[email protected]>
+     ```
+
+     When cherry-picking from a different repository, use the `-x` flag, and then amend the commits to turn the hashes into URLs.
+
    * Make sure to have [a clean history of commits on your branch by using rebase](https://www.digitalocean.com/community/tutorials/how-to-rebase-and-update-a-pull-request).
    * [Mark the pull request as draft](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request) if you're not done with the changes.
 
@@ -83,4 +97,4 @@ For larger changes see the [Nix reference manual](https://nix.dev/manual/nix/dev
 ## Getting help
 
 Whenever you're stuck or do not know how to proceed, you can always ask for help.
-The appropriate channels to do so can be found on the [NixOS Community](https://nixos.org/community/) page.
+We invite you to use our [Matrix room](https://matrix.to/#/#nix-dev:nixos.org) to ask questions.

README.md

@@ -15,7 +15,7 @@ Full reference documentation can be found in the [Nix manual](https://nix.dev/re
 
 ## Building and developing
 
-Follow instructions in the Nix reference manual to [set up a development environment and build Nix from source](https://nix.dev/manual/nix/development/building.html).
+Follow instructions in the Nix reference manual to [set up a development environment and build Nix from source](https://nix.dev/manual/nix/development/development/building.html).
 
 ## Contributing
 

doc/manual/custom.css

@@ -12,8 +12,8 @@ h1.menu-title::before {
 }
 
 
-h1.menu-title {
-  padding: 0.5em;
+.menu-bar {
+  padding: 0.5em 0em;
 }
 
 .sidebar .sidebar-scrollbox {

doc/manual/rl-next/build-hook-default.md

@@ -0,0 +1,22 @@
+---
+synopsis: |-
+  The `build-hook` setting's default is less useful when using `libnixstore` as a library
+prs:
+- 11178
+---
+
+*This is an obscure issue that only affects usage of the `libnixstore` library outside of the Nix executable.*
+
+As part the ongoing [rewrite of the build system](https://github.com/NixOS/nix/issues/2503) to use [Meson](https://mesonbuild.com/), we are also switching to packaging individual Nix components separately (and building them in separate derivations).
+This means that when building `libnixstore` we do not know where the Nix binaries will be installed --- `libnixstore` doesn't know about downstream consumers like the Nix binaries at all.
+
+*This is also unrelated to the _`post`_-`build-hook`*, which is often used for pushing to a cache.*
+
+This has a small adverse affect on remote building --- the `build-remote` executable that is specified from the [`build-hook`](@docroot@/command-ref/conf-file.md#conf-build-hook) setting will not be gotten from the (presumed) installation location, but instead looked up on the `PATH`.
+This means that other applications linking `libnixstore` that wish to use remote building must arrange for the `nix` command to be on the PATH (or manually overriding `build-hook`) in order for that to work.
+
+Long term we don't envision this being a downside, because we plan to [get rid of `build-remote` and the build hook setting entirely](https://github.com/NixOS/nix/issues/1221).
+There is simply no need to add a second layer of remote-procedure-calling when we want to connect to a remote builder.
+The build hook protocol did in principle support custom ways of remote building, but that can also be accomplished with a custom service for the ssh or daemon/ssh-ng protocols, or with a custom [store type](@docroot@/store/types/index.md) i.e. `Store` subclass. <!-- we normally don't mention classes, but consider that this release note is about a library use case -->
+
+The Perl bindings no longer expose `getBinDir` either, since they libraries those bindings wrap no longer know the location of installed binaries as described above.

doc/manual/rl-next/homeless-shelter-to-proc.md

@@ -0,0 +1,9 @@
+---
+synopsis: On linux, set $HOME=/proc/homeless-shelter instead of /homeless-shelter
+issues: [8313, 11295]
+prs: [11300]
+---
+
+When building, $HOME is set to a non-existing directory. Previously it was always set to `/homeless-shelter`. Before a build, Nix verifies that it doesn't exist. In some scenarios (specifically when using the Linux sandbox with a single-user installation), it is possible to create the `/homeless-shelter` directory, and some tools will create it, resulting in a build error.
+
+Now, on Linux, $HOME is set to `/proc/homeless-shelter`. This directory can never be created, since `/proc` is a virtual filesystem. This resolves the issue.

doc/manual/rl-next/nix-flake-show-description.md

@@ -0,0 +1,25 @@
+---
+synopsis: Show package descriptions with `nix flake show`
+issues: [10977]
+prs: [10980]
+---
+
+`nix flake show` will now display a package's `meta.description` if it exists. If the description does not fit in the terminal it will be truncated to fit the terminal width. If the size of the terminal width is unknown the description will be capped at 80 characters.
+
+```
+$ nix flake show
+└───packages
+    └───x86_64-linux
+        ├───builderImage: package 'docker-image-ara-builder-image.tar.gz' - 'Docker image hosting the nix build environment'
+        └───runnerImage: package 'docker-image-gitlab-runner.tar.gz' - 'Docker image hosting the gitlab-runner executable'
+```
+
+In a narrower terminal:
+
+```
+$ nix flake show
+└───packages
+    └───x86_64-linux
+        ├───builderImage: package 'docker-image-ara-builder-image.tar.gz' - 'Docker image hosting the nix b...
+        └───runnerImage: package 'docker-image-gitlab-runner.tar.gz' - 'Docker image hosting the gitlab-run...
+```

doc/manual/src/development/building.md

@@ -34,16 +34,21 @@ $ nix-shell --attr devShells.x86_64-linux.native-clangStdenvPackages
 To build Nix itself in this shell:
 
 ```console
-[nix-shell]$ autoreconfPhase
-[nix-shell]$ ./configure $configureFlags --prefix=$(pwd)/outputs/out
-[nix-shell]$ make -j $NIX_BUILD_CORES
+[nix-shell]$ mesonFlags+=" --prefix=$(pwd)/outputs/out"
+[nix-shell]$ dontAddPrefix=1 mesonConfigurePhase
+[nix-shell]$ ninjaBuildPhase
 ```
 
-To install it in `$(pwd)/outputs` and test it:
+To test it:
 
 ```console
-[nix-shell]$ make install
-[nix-shell]$ make installcheck -j $NIX_BUILD_CORES
+[nix-shell]$ mesonCheckPhase
+```
+
+To install it in `$(pwd)/outputs`:
+
+```console
+[nix-shell]$ ninjaInstallPhase
 [nix-shell]$ ./outputs/out/bin/nix --version
 nix (Nix) 2.12
 ```
@@ -85,16 +90,20 @@ $ nix develop .#native-clangStdenvPackages
 To build Nix itself in this shell:
 
 ```console
-[nix-shell]$ autoreconfPhase
-[nix-shell]$ configurePhase
-[nix-shell]$ make -j $NIX_BUILD_CORES OPTIMIZE=0
+[nix-shell]$ mesonConfigurePhase
+[nix-shell]$ ninjaBuildPhase
 ```
 
-To install it in `$(pwd)/outputs` and test it:
+To test it:
 
 ```console
-[nix-shell]$ make install OPTIMIZE=0
-[nix-shell]$ make installcheck check -j $NIX_BUILD_CORES
+[nix-shell]$ mesonCheckPhase
+```
+
+To install it in `$(pwd)/outputs`:
+
+```console
+[nix-shell]$ ninjaInstallPhase
 [nix-shell]$ nix --version
 nix (Nix) 2.12
 ```
@@ -110,25 +119,6 @@ $ nix build
 
 You can also build Nix for one of the [supported platforms](#platforms).
 
-## Makefile variables
-
-You may need `profiledir=$out/etc/profile.d` and `sysconfdir=$out/etc` to run `make install`.
-
-Run `make` with [`-e` / `--environment-overrides`](https://www.gnu.org/software/make/manual/make.html#index-_002de) to allow environment variables to override `Makefile` variables:
-
-- `ENABLE_BUILD=yes` to enable building the C++ code.
-- `ENABLE_DOC_GEN=yes` to enable building the documentation (manual, man pages, etc.).
-
-  The docs can take a while to build, so you may want to disable this for local development.
-- `ENABLE_FUNCTIONAL_TESTS=yes` to enable building the functional tests.
-- `OPTIMIZE=1` to enable optimizations.
-- `libraries=libutil programs=` to only build a specific library.
-
-  This will fail in the linking phase if the other libraries haven't been built, but is useful for checking types.
-- `libraries= programs=nix` to only build a specific program.
-
-  This will not work in general, because the programs need the libraries.
-
 ## Platforms
 
 Nix can be built for various platforms, as specified in [`flake.nix`]:
@@ -175,27 +165,38 @@ Add more [system types](#system-type) to `crossSystems` in `flake.nix` to bootst
 
 It is useful to perform multiple cross and native builds on the same source tree,
 for example to ensure that better support for one platform doesn't break the build for another.
-In order to facilitate this, Nix has some support for being built out of tree – that is, placing build artefacts in a different directory than the source code:
+Meson thankfully makes this very easy by confining all build products to the build directory --- one simple shares the source directory between multiple build directories, each of which contains the build for Nix to a different platform.
+
+Nixpkgs's `mesonConfigurePhase` always chooses `build` in the current directory as the name and location of the build.
+This makes having multiple build directories slightly more inconvenient.
+The good news is that Meson/Ninja seem to cope well with relocating the build directory after it is created.
 
-1. Create a directory for the build, e.g.
+Here's how to do that
+
+1. Configure as usual
 
    ```bash
-   mkdir build
+   mesonConfigurePhase
    ```
 
-2. Run the configure script from that directory, e.g.
+2. Rename the build directory
 
    ```bash
-   cd build
-   ../configure <configure flags>
+   cd .. # since `mesonConfigurePhase` cd'd inside
+   mv build build-linux # or whatever name we want
+   cd build-linux
    ```
 
-3. Run make from the source directory, but with the build directory specified, e.g.
+3. Build as usual
 
    ```bash
-   make builddir=build <make flags>
+   ninjaBuildPhase
    ```
 
+> **N.B.**
+> [`nixpkgs#335818`](https://github.com/NixOS/nixpkgs/issues/335818) tracks giving `mesonConfigurePhase` proper support for custom build directories.
+> When it is fixed, we can simplify these instructions and then remove this notice.
+
 ## System type
 
 Nix uses a string with the following format to identify the *system type* or *platform* it runs on:
@@ -257,11 +258,8 @@ You can use any of the other supported environments in place of `nix-ccacheStden
 The `clangd` LSP server is installed by default on the `clang`-based `devShell`s.
 See [supported compilation environments](#compilation-environments) and instructions how to set up a shell [with flakes](#nix-with-flakes) or in [classic Nix](#classic-nix).
 
-To use the LSP with your editor, you first need to [set up `clangd`](https://clangd.llvm.org/installation#project-setup) by running:
-
-```console
-make compile_commands.json
-```
+To use the LSP with your editor, you will want a `compile_commands.json` file telling `clangd` how we are compiling the code.
+Meson's configure always produces this inside the build directory.
 
 Configure your editor to use the `clangd` from the `.#native-clangStdenvPackages` shell. You can do that either by running it inside the development shell, or by using [nix-direnv](https://github.com/nix-community/nix-direnv) and [the appropriate editor plugin](https://github.com/direnv/direnv/wiki#editor-integration).
 
@@ -276,7 +274,7 @@ Configure your editor to use the `clangd` from the `.#native-clangStdenvPackages
 You may run the formatters as a one-off using:
 
 ```console
-make format
+./maintainers/format.sh
 ```
 
 If you'd like to run the formatters before every commit, install the hooks: