Merge branch 'master' into biscuit-cli-master

2023-03-09 10:22:33 -05:00 · 2023-03-09 10:22:33 -05:00 · 57b37aa420
commit 57b37aa420
parent b094f644af 6b79fe8cdc
15407 changed files with 403214 additions and 362822 deletions
--- a/.editorconfig
+++ b/.editorconfig
@ -55,10 +55,13 @@ trim_trailing_whitespace = unset
 [*.lock]
 indent_size = unset

-# trailing whitespace is an actual syntax element of classic Markdown/
-# CommonMark to enforce a line break
+# Although Markdown/CommonMark allows using two trailing spaces to denote
+# a hard line break, we do not use that feature in nixpkgs since
+# it forces the surrounding paragraph to become a <literallayout> which
+# does not wrap reasonably.
+# Instead of a hard line break, start a new paragraph by inserting a blank line.
 [*.md]
-trim_trailing_whitespace = unset
+trim_trailing_whitespace = true

 # binaries
 [*.nib]
@ -92,3 +95,9 @@ trim_trailing_whitespace = unset

 [pkgs/tools/misc/timidity/timidity.cfg]
 trim_trailing_whitespace = unset
+
+[pkgs/tools/virtualization/ovftool/*.ova]
+end_of_line = unset
+insert_final_newline = unset
+trim_trailing_whitespace = unset
+charset = unset
--- a/.gitattributes
+++ b/.gitattributes
@ -1,4 +1,5 @@
 **/deps.nix linguist-generated
+**/deps.json linguist-generated
 **/node-packages.nix linguist-generated

 pkgs/applications/editors/emacs-modes/*-generated.nix linguist-generated
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@ -28,6 +28,7 @@
 /lib/cli.nix                @edolstra @nbp @Profpatsch
 /lib/debug.nix              @edolstra @nbp @Profpatsch
 /lib/asserts.nix            @edolstra @nbp @Profpatsch
+/lib/path.*                 @infinisil @fricklerhandwerk

 # Nixpkgs Internals
 /default.nix                                     @nbp
@ -48,6 +49,10 @@
 # Nixpkgs build-support
 /pkgs/build-support/writers @lassulus @Profpatsch

+# Nixpkgs make-disk-image
+/doc/builders/images/makediskimage.section.md  @raitobezarius
+/nixos/lib/make-disk-image.nix                 @raitobezarius
+
 # Nixpkgs documentation
 /maintainers/scripts/db-to-md.sh @jtojnar @ryantm
 /maintainers/scripts/doc @jtojnar @ryantm
@ -78,6 +83,8 @@
 /nixos/doc/manual/man-nixos-option.xml                @nbp
 /nixos/modules/installer/tools/nixos-option.sh        @nbp
 /nixos/modules/system                                 @dasJ
+/nixos/modules/system/activation/bootspec.nix         @grahamc @cole-h @raitobezarius
+/nixos/modules/system/activation/bootspec.cue         @grahamc @cole-h @raitobezarius

 # NixOS integration test driver
 /nixos/lib/test-driver  @tfc
@ -97,10 +104,8 @@

 # Python-related code and docs
 /maintainers/scripts/update-python-libraries	              @FRidh
-/pkgs/top-level/python-packages.nix                         @FRidh @jonringer
 /pkgs/development/interpreters/python                       @FRidh
-/pkgs/development/python-modules                            @FRidh @jonringer
-/doc/languages-frameworks/python.section.md                 @FRidh
+/doc/languages-frameworks/python.section.md                 @FRidh @mweinelt
 /pkgs/development/tools/poetry2nix                          @adisbladis
 /pkgs/development/interpreters/python/hooks                 @FRidh @jonringer

@ -127,7 +132,9 @@
 /pkgs/development/ruby-modules      @marsam

 # Rust
-/pkgs/development/compilers/rust @Mic92 @LnL7 @zowoq
+/pkgs/development/compilers/rust @Mic92 @LnL7 @zowoq @winterqt @figsoda
+/pkgs/build-support/rust @zowoq @winterqt @figsoda
+/doc/languages-frameworks/rust.section.md @zowoq @winterqt @figsoda

 # C compilers
 /pkgs/development/compilers/gcc @matthewbauer
@ -146,6 +153,11 @@
 # Browsers
 /pkgs/applications/networking/browsers/firefox @mweinelt

+# Certificate Authorities
+pkgs/data/misc/cacert/ @ajs124 @lukegb @mweinelt
+pkgs/development/libraries/nss/ @ajs124 @lukegb @mweinelt
+pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
+
 # Jetbrains
 /pkgs/applications/editors/jetbrains @edwtjo

@ -219,10 +231,10 @@
 /pkgs/top-level/emacs-packages.nix              @adisbladis

 # Neovim
-/pkgs/applications/editors/neovim      @jonringer @teto
+/pkgs/applications/editors/neovim      @figsoda @jonringer @teto

 # VimPlugins
-/pkgs/applications/editors/vim/plugins         @jonringer
+/pkgs/applications/editors/vim/plugins         @figsoda @jonringer

 # VsCode Extensions
 /pkgs/applications/editors/vscode/extensions   @jonringer
@ -263,6 +275,7 @@
 # GNOME
 /pkgs/desktops/gnome                              @jtojnar
 /pkgs/desktops/gnome/extensions       @piegamesde @jtojnar
+/pkgs/build-support/make-hardcode-gsettings-patch @jtojnar

 # Cinnamon
 /pkgs/desktops/cinnamon @mkg20001
@ -284,11 +297,8 @@
 # Matrix
 /pkgs/servers/heisenbridge                                 @piegamesde
 /pkgs/servers/matrix-conduit                               @piegamesde
-/pkgs/servers/matrix-synapse/matrix-appservice-irc         @piegamesde
 /nixos/modules/services/misc/heisenbridge.nix              @piegamesde
-/nixos/modules/services/misc/matrix-appservice-irc.nix     @piegamesde
 /nixos/modules/services/misc/matrix-conduit.nix            @piegamesde
-/nixos/tests/matrix-appservice-irc.nix                     @piegamesde
 /nixos/tests/matrix-conduit.nix                            @piegamesde

 # Dotnet
--- a/.github/ISSUE_TEMPLATE/bug_report.md
+++ b/.github/ISSUE_TEMPLATE/bug_report.md
@ -26,6 +26,7 @@ If applicable, add screenshots to help explain your problem.
 Add any other context about the problem here.

 ### Notify maintainers
+
 <!--
 Please @ people who are in the `meta.maintainers` list of the offending package or module.
 If in doubt, check `git blame` for whoever last touched something.
--- a/.github/ISSUE_TEMPLATE/build_failure.md
+++ b/.github/ISSUE_TEMPLATE/build_failure.md
@ -1,31 +1,36 @@
 ---
 name: Build failure
 about: Create a report to help us improve
-title: ''
+title: 'Build failure: PACKAGENAME'
 labels: '0.kind: build failure'
 assignees: ''

 ---

 ### Steps To Reproduce
+
 Steps to reproduce the behavior:
 1. build *X*

 ### Build log
+
 ```
 log here if short otherwise a link to a gist
 ```

 ### Additional context
+
 Add any other context about the problem here.

 ### Notify maintainers
+
 <!--
 Please @ people who are in the `meta.maintainers` list of the offending package or module.
 If in doubt, check `git blame` for whoever last touched something.
 -->

 ### Metadata
+
 Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.

 ```console
--- a/.github/ISSUE_TEMPLATE/missing_documentation.md
+++ b/.github/ISSUE_TEMPLATE/missing_documentation.md
@ -1,7 +1,7 @@
 ---
 name: Missing or incorrect documentation
 about: Help us improve the Nixpkgs and NixOS reference manuals
-title: ''
+title: 'Documentation: '
 labels: '9.needs: documentation'
 assignees: ''

@ -11,6 +11,10 @@ assignees: ''

 <!-- describe your problem -->

+## Proposal
+
+<!-- propose a solution (optional) -->
+
 ## Checklist

 <!-- make sure this issue is not redundant or obsolete -->
@ -26,7 +30,3 @@ assignees: ''
 [open documentation issues]: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+label%3A%229.needs%3A+documentation%22
 [open documentation pull requests]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+is%3Apr+label%3A%228.has%3A+documentation%22%2C%226.topic%3A+documentation%22

-## Proposal
-
-<!-- propose a solution -->
-
--- a/.github/ISSUE_TEMPLATE/out_of_date_package_report.md
+++ b/.github/ISSUE_TEMPLATE/out_of_date_package_report.md
@ -1,24 +1,17 @@
 ---
 name: Out-of-date package reports
 about: For packages that are out-of-date
-title: ''
+title: 'Update request: PACKAGENAME OLDVERSION → NEWVERSION'
 labels: '9.needs: package (update)'
 assignees: ''

 ---

-
-###### Checklist
-
-<!-- Note that these are hard requirements -->
-
-<!--
-You can use the "Go to file" functionality on GitHub to find the package
-Then you can go to the history for this package
-Find the latest "package_name: old_version -> new_version" commit
-The "new_version" is the current version of the package
-->
- [ ] Checked the [nixpkgs master branch](https://github.com/NixOS/nixpkgs)
+- Package name:
+- Latest released version:
+<!-- Search your package here: https://search.nixos.org/packages?channel=unstable -->
+- Current version on the unstable channel:
+- Current version on the stable/release channel:
 <!--
 Type the name of your package and try to find an open pull request for the package
 If you find an open pull request, you can review it!
@ -26,23 +19,10 @@ There's a high chance that you'll have the new version right away while helping
 -->
 - [ ] Checked the [nixpkgs pull requests](https://github.com/NixOS/nixpkgs/pulls)

-###### Project name
-`nix search` name:
-<!--
-The current version can be found easily with the same process as above for checking the master branch
-If an open PR is present for the package, take this version as the current one and link to the PR
-->
-current version:
-desired version:
+**Notify maintainers**

-###### Notify maintainers
-<!--
-Search your package here: https://search.nixos.org/packages?channel=unstable
-If no maintainer is listed for your package, tag the person that last updated the package
-->
+<!-- If the search.nixos.org result shows no maintainers, tag the person that last updated the package. -->

-maintainers:
+-----

-###### Note for maintainers
-
-Please tag this issue in your PR.
+Note for maintainers: Please tag this issue in your PR.
--- a/.github/ISSUE_TEMPLATE/packaging_request.md
+++ b/.github/ISSUE_TEMPLATE/packaging_request.md
@ -1,14 +1,15 @@
 ---
 name: Packaging requests
 about: For packages that are missing
-title: ''
+title: 'Package request: PACKAGENAME'
 labels: '0.kind: packaging request'
 assignees: ''

 ---

 **Project description**
-_describe the project a little_
+
+<!-- Describe the project a little: -->

 **Metadata**

--- a/.github/ISSUE_TEMPLATE/unreproducible_package.md
+++ b/.github/ISSUE_TEMPLATE/unreproducible_package.md
@ -2,7 +2,7 @@
 name: Unreproducible package
 about: A package that does not produce a bit-by-bit reproducible result each time it is built
 title: ''
-labels: '0.kind: enhancement', '6.topic: reproducible builds'
+labels: [ '0.kind: enhancement', '6.topic: reproducible builds' ]
 assignees: ''

 ---
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@ -22,11 +22,10 @@ For new packages please briefly describe the package or provide a link to its ho
  - made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages
 - [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"`. Note: all changes have to be committed, also see [nixpkgs-review usage](https://github.com/Mic92/nixpkgs-review#usage)
 - [ ] Tested basic functionality of all binary files (usually in `./result/bin/`)
- [22.11 Release Notes (or backporting 22.05 Release notes)](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2211-release-notes)
+- [23.05 Release Notes (or backporting 22.11 Release notes)](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2305-release-notes)
  - [ ] (Package updates) Added a release notes entry if the change is major or breaking
  - [ ] (Module updates) Added a release notes entry if the change is significant
  - [ ] (Module addition) Added a release notes entry if adding a new NixOS module
-  - [ ] (Release notes changes) Ran `nixos/doc/manual/md-to-db.sh` to update generated release notes
 - [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).

 <!--
--- a/.github/labeler.yml
+++ b/.github/labeler.yml
@ -19,6 +19,11 @@
  - pkgs/build-support/emacs/**/*
  - pkgs/top-level/emacs-packages.nix

+"6.topic: Enlightenment DE":
+  - nixos/modules/services/x11/desktop-managers/enlightenment.nix
+  - pkgs/desktops/enlightenment/**/*
+  - pkgs/development/python-modules/python-efl/*
+
 "6.topic: erlang":
  - doc/languages-frameworks/beam.section.md
  - pkgs/development/beam-modules/**/*
@ -65,6 +70,19 @@
  - pkgs/development/lua-modules/**/*
  - pkgs/top-level/lua-packages.nix

+"6.topic: Lumina DE":
+  - nixos/modules/services/x11/desktop-managers/lumina.nix
+  - pkgs/desktops/lumina/**/*
+
+"6.topic: LXQt":
+  - nixos/modules/services/x11/desktop-managers/lxqt.nix
+  - pkgs/desktops/lxqt/**/*
+
+"6.topic: mate":
+  - nixos/modules/services/x11/desktop-managers/mate.nix
+  - nixos/tests/mate.nix
+  - pkgs/desktops/mate/**/*
+
 "6.topic: nixos":
  - nixos/**/*
  - pkgs/os-specific/linux/nixos-rebuild/**/*
--- a/.github/workflows/backport.yml
+++ b/.github/workflows/backport.yml
@ -14,23 +14,20 @@ permissions:
 jobs:
  backport:
    permissions:
-      contents: write  # for zeebe-io/backport-action to create branch
-      pull-requests: write  # for zeebe-io/backport-action to create PR to backport
+      contents: write # for korthout/backport-action to create branch
+      pull-requests: write # for korthout/backport-action to create PR to backport
    name: Backport Pull Request
    if: github.repository_owner == 'NixOS' && github.event.pull_request.merged == true && (github.event_name != 'labeled' || startsWith('backport', github.event.label.name))
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
-          # required to find all branches
-          fetch-depth: 0
          ref: ${{ github.event.pull_request.head.sha }}
      - name: Create backport PRs
-        uses: zeebe-io/backport-action@v0.0.8
+        uses: korthout/backport-action@v1.2.0
        with:
-          # Config README: https://github.com/zeebe-io/backport-action#backport-action
-          github_token: ${{ secrets.GITHUB_TOKEN }}
-          github_workspace: ${{ github.workspace }}
+          # Config README: https://github.com/korthout/backport-action#backport-action
+          copy_labels_pattern: 'severity:\ssecurity'
          pull_description: |-
            Bot-based backport to `${target_branch}`, triggered by a label in #${pull_number}.

--- a/.github/workflows/basic-eval.yml
+++ b/.github/workflows/basic-eval.yml
@ -19,7 +19,7 @@ jobs:
    # we don't limit this action to only NixOS repo since the checks are cheap and useful developer feedback
    steps:
    - uses: actions/checkout@v3
-    - uses: cachix/install-nix-action@v18
+    - uses: cachix/install-nix-action@v20
    - uses: cachix/cachix-action@v12
      with:
        # This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
--- a/.github/workflows/editorconfig.yml
+++ b/.github/workflows/editorconfig.yml
@ -11,7 +11,7 @@ on:
 jobs:
  tests:
    runs-on: ubuntu-latest
-    if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip editorconfig]')"
+    if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
    steps:
    - name: Get list of changed files from PR
      env:
@ -28,16 +28,14 @@ jobs:
      with:
        # pull_request_target checks out the base branch by default
        ref: refs/pull/${{ github.event.pull_request.number }}/merge
-    - uses: cachix/install-nix-action@v18
+    - uses: cachix/install-nix-action@v20
      with:
        # nixpkgs commit is pinned so that it doesn't break
        # editorconfig-checker 2.4.0
        nix_path: nixpkgs=https://github.com/NixOS/nixpkgs/archive/c473cc8714710179df205b153f4e9fa007107ff9.tar.gz
-    - name: install editorconfig-checker
-      run: nix-env -iA editorconfig-checker -f '<nixpkgs>'
    - name: Checking EditorConfig
      run: |
-        cat "$HOME/changed_files" | xargs -r editorconfig-checker -disable-indent-size
+        cat "$HOME/changed_files" | nix-shell -p editorconfig-checker --run 'xargs -r editorconfig-checker -disable-indent-size'
    - if: ${{ failure() }}
      run: |
        echo "::error :: Hey! It looks like your changes don't follow our editorconfig settings. Read https://editorconfig.org/#download to configure your editor so you never see this error again."
--- a/.github/workflows/labels.yml
+++ b/.github/workflows/labels.yml
@ -16,7 +16,7 @@ permissions:
 jobs:
  labels:
    runs-on: ubuntu-latest
-    if: github.repository_owner == 'NixOS'
+    if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
    steps:
    - uses: actions/labeler@v4
      with:
--- a/.github/workflows/manual-nixos.yml
+++ b/.github/workflows/manual-nixos.yml
@ -18,7 +18,7 @@ jobs:
        with:
          # pull_request_target checks out the base branch by default
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
-      - uses: cachix/install-nix-action@v18
+      - uses: cachix/install-nix-action@v20
        with:
          # explicitly enable sandbox
          extra_nix_config: sandbox = true
--- a/.github/workflows/manual-nixpkgs.yml
+++ b/.github/workflows/manual-nixpkgs.yml
@ -8,6 +8,7 @@ on:
      - master
    paths:
      - 'doc/**'
+      - 'lib/**'

 jobs:
  nixpkgs:
@ -18,7 +19,7 @@ jobs:
        with:
          # pull_request_target checks out the base branch by default
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
-      - uses: cachix/install-nix-action@v18
+      - uses: cachix/install-nix-action@v20
        with:
          # explicitly enable sandbox
          extra_nix_config: sandbox = true
--- a/.github/workflows/manual-rendering.yml
+++ b/.github/workflows/manual-rendering.yml
@ -18,7 +18,7 @@ jobs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
-      - uses: cachix/install-nix-action@v18
+      - uses: cachix/install-nix-action@v20
        with:
          # explicitly enable sandbox
          extra_nix_config: sandbox = true
--- a/.github/workflows/nixos-manual.yml
+++ b/.github/workflows/nixos-manual.yml
@ -1,34 +0,0 @@
-name: NixOS manual checks
-
-permissions: read-all
-
-on:
-  pull_request_target:
-    branches-ignore:
-      - 'release-**'
-    paths:
-      - 'nixos/**/*.xml'
-      - 'nixos/**/*.md'
-
-jobs:
-  tests:
-    runs-on: ubuntu-latest
-    if: github.repository_owner == 'NixOS'
-    steps:
-    - uses: actions/checkout@v3
-      with:
-        # pull_request_target checks out the base branch by default
-        ref: refs/pull/${{ github.event.pull_request.number }}/merge
-    - uses: cachix/install-nix-action@v18
-    - name: Check DocBook files generated from Markdown are consistent
-      run: |
-        nixos/doc/manual/md-to-db.sh
-        git diff --exit-code || {
-          echo
-          echo 'Generated manual files are out of date.'
-          echo 'Please run'
-          echo
-          echo '    nixos/doc/manual/md-to-db.sh'
-          echo
-          exit 1
-        }
--- a/.github/workflows/periodic-merge-24h.yml
+++ b/.github/workflows/periodic-merge-24h.yml
@ -38,10 +38,6 @@ jobs:
            into: staging-next-22.11
          - from: staging-next-22.11
            into: staging-22.11
-          - from: release-22.05
-            into: staging-next-22.05
-          - from: staging-next-22.05
-            into: staging-22.05
    name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
    steps:
      - uses: actions/checkout@v3
--- a/.github/workflows/update-terraform-providers.yml
+++ b/.github/workflows/update-terraform-providers.yml
@ -11,13 +11,13 @@ permissions:
 jobs:
  tf-providers:
    permissions:
-      contents: write  # for peter-evans/create-pull-request to create branch
-      pull-requests: write  # for peter-evans/create-pull-request to create a PR, for peter-evans/create-or-update-comment to create or update comment
+      contents: write # for peter-evans/create-pull-request to create branch
+      pull-requests: write # for peter-evans/create-pull-request to create a PR, for peter-evans/create-or-update-comment to create or update comment
    if: github.repository_owner == 'NixOS' && github.ref == 'refs/heads/master' # ensure workflow_dispatch only runs on master
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
-      - uses: cachix/install-nix-action@v18
+      - uses: cachix/install-nix-action@v20
        with:
          nix_path: nixpkgs=channel:nixpkgs-unstable
      - name: setup
@ -25,6 +25,8 @@ jobs:
        run: |
          echo "title=terraform-providers: update $(date -u +"%Y-%m-%d")" >> $GITHUB_OUTPUT
      - name: update terraform-providers
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git config user.name "github-actions[bot]"
--- a/.gitignore
+++ b/.gitignore
@ -2,6 +2,8 @@
 ,*
 .*.swp
 .*.swo
+.\#*
+\#*\#
 .idea/
 .vscode/
 outputs/
--- a/.mailmap
+++ b/.mailmap
@ -1,3 +1,14 @@
+ajs124 <git@ajs124.de> <ajs124@users.noreply.github.com>
+Anderson Torres <torres.anderson.85@protonmail.com>
 Daniel Løvbrøtte Olsen <me@dandellion.xyz> <daniel.olsen99@gmail.com>
+Fabian Affolter <mail@fabian-affolter.ch> <fabian@affolter-engineering.ch>
+Janne Heß <janne@hess.ooo> <dasJ@users.noreply.github.com>
+Jörg Thalheim <joerg@thalheim.io> <Mic92@users.noreply.github.com>
+Martin Weinelt <hexa@darmstadt.ccc.de> <mweinelt@users.noreply.github.com>
 R. RyanTM <ryantm-bot@ryantm.com>
-Sandro <sandro.jaeckel@gmail.com>
+Robert Hensing <robert@roberthensing.nl> <roberth@users.noreply.github.com>
+Sandro Jäckel <sandro.jaeckel@gmail.com>
+Sandro Jäckel <sandro.jaeckel@gmail.com> <sandro.jaeckel@sap.com>
+superherointj <5861043+superherointj@users.noreply.github.com>
+Vladimír Čunát <v@cunat.cz> <vcunat@gmail.com>
+Vladimír Čunát <v@cunat.cz> <vladimir.cunat@nic.cz>
--- a/.version
+++ b/.version
@ -1 +1 @@
-22.11
+23.05
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@ -38,11 +38,14 @@ Below is a short excerpt of some points in there:
    The old config generation system used impure shell scripts and could break in specific circumstances (see #1234).

 * `meta.description` should:
+  * Be short, just one sentence.
  * Be capitalized.
  * Not start with the package name.
-  * Not have a period at the end.
+    * More generally, it should not refer to the package name.
+  * Not end with a period (or any punctuation for that matter).
 * `meta.license` must be set and fit the upstream license.
  * If there is no upstream license, `meta.license` should default to `lib.licenses.unfree`.
+  * If in doubt, try to contact the upstream developers for clarification.
 * `meta.maintainers` must be set.

 See the nixpkgs manual for more details on [standard meta-attributes](https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes).
@ -53,6 +56,10 @@ In addition to writing properly formatted commit messages, it's important to inc

 Package version upgrades usually allow for simpler commit messages, including attribute name, old and new version, as well as a reference to the relevant release notes/changelog. Every once in a while a package upgrade requires more extensive changes, and that subsequently warrants a more verbose message.

+Pull requests should not be squash merged in order to keep complete commit messages and GPG signatures intact and must not be when the change doesn't make sense as a single commit.
+This means that, when addressing review comments in order to keep the pull request in an always mergeable status, you will sometimes need to rewrite your branch's history and then force-push it with `git push --force-with-lease`.
+Useful git commands that can help a lot with this are `git commit --patch --amend` and `git rebase --interactive`. For more details consult the git man pages or online resources like [git-rebase.io](https://git-rebase.io/) or [The Pro Git Book](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History).
+
 ## Rebasing between branches (i.e. from master to staging)

 From time to time, changes between branches must be rebased, for example, if the
@ -98,17 +105,17 @@ git push origin feature --force-with-lease

 Follow these steps to backport a change into a release branch in compliance with the [commit policy](https://nixos.org/nixpkgs/manual/#submitting-changes-stable-release-branches).

-You can add a label such as `backport release-22.05` to a PR, so that merging it will
+You can add a label such as `backport release-22.11` to a PR, so that merging it will
 automatically create a backport (via [a GitHub Action](.github/workflows/backport.yml)).
 This also works for PR's that have already been merged, and might take a couple of minutes to trigger.

 You can also create the backport manually:

 1. Take note of the commits in which the change was introduced into `master` branch.
-2. Check out the target _release branch_, e.g. `release-22.05`. Do not use a _channel branch_ like `nixos-22.05` or `nixpkgs-22.05-darwin`.
+2. Check out the target _release branch_, e.g. `release-22.11`. Do not use a _channel branch_ like `nixos-22.11` or `nixpkgs-22.11-darwin`.
 3. Create a branch for your change, e.g. `git checkout -b backport`.
 4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request.
-5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-22.05`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[22.05]`.
+5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-22.11`) as the target branch of the pull request, and link to the pull request in which the original change was committed to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[22.11]`.
 6. When the backport pull request is merged and you have the necessary privileges you can also replace the label `9.needs: port to stable` with `8.has: port to stable` on the original pull request. This way maintainers can keep track of missing backports easier.

 ## Criteria for Backporting changes
@ -120,15 +127,18 @@ Anything that does not cause user or downstream dependency regressions can be ba
 - Services which require a client to be up-to-date regardless. (E.g. `spotify`, `steam`, or `discord`)
 - Security critical applications (E.g. `firefox`)

-## Generating 22.11 Release Notes
+## Generating 23.05 Release Notes
+<!--
+note: title unchanged even though we don't need regeneration because extant
+PRs will link here. definitely change the title for 23.11 though.
+-->

-Documentation in nixpkgs is transitioning to a markdown-centric workflow. Release notes now require a translation step to convert from markdown to a compatible docbook document.
+Documentation in nixpkgs is transitioning to a markdown-centric workflow. In the past release notes required a translation step to convert from markdown to a compatible docbook document, but this is no longer necessary.

-Steps for updating 22.11 Release notes:
+Steps for updating 23.05 Release notes:

-1. Edit `nixos/doc/manual/release-notes/rl-2211.section.md` with the desired changes
-2. Run `./nixos/doc/manual/md-to-db.sh` to render `nixos/doc/manual/from_md/release-notes/rl-2211.section.xml`
-3. Include changes to `rl-2211.section.md` and `rl-2211.section.xml` in the same commit.
+1. Edit `nixos/doc/manual/release-notes/rl-2305.section.md` with the desired changes
+2. Commit changes to `rl-2305.section.md`.

 ## Reviewing contributions

--- a/2
+++ b/2
@ -1,4 +1,4 @@
-Copyright (c) 2003-2022 Eelco Dolstra and the Nixpkgs/NixOS contributors
+Copyright (c) 2003-2023 Eelco Dolstra and the Nixpkgs/NixOS contributors

 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files (the
--- a/README.md
+++ b/README.md
@ -51,9 +51,9 @@ Nixpkgs and NixOS are built and tested by our continuous integration
 system, [Hydra](https://hydra.nixos.org/).

 * [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
-* [Continuous package builds for the NixOS 22.05 release](https://hydra.nixos.org/jobset/nixos/release-22.05)
+* [Continuous package builds for the NixOS 22.11 release](https://hydra.nixos.org/jobset/nixos/release-22.11)
 * [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
-* [Tests for the NixOS 22.05 release](https://hydra.nixos.org/job/nixos/release-22.05/tested#tabs-constituents)
+* [Tests for the NixOS 22.11 release](https://hydra.nixos.org/job/nixos/release-22.11/tested#tabs-constituents)

 Artifacts successfully built with Hydra are published to cache at
 https://cache.nixos.org/. When successful build and test criteria are
--- a/doc/.gitignore
+++ b/doc/.gitignore
@ -6,3 +6,5 @@ functions/library/locations.xml
 highlightjs
 manual-full.xml
 out
+result
+result-*
--- a/doc/Makefile
+++ b/doc/Makefile
@ -3,7 +3,7 @@ MD_TARGETS=$(addsuffix .xml, $(basename $(shell find . -type f -regex '.*\.md$$'
 PANDOC ?= pandoc

 pandoc_media_dir = media
-# NOTE: Keep in sync with NixOS manual (/nixos/doc/manual/md-to-db.sh) and conversion script (/maintainers/scripts/db-to-md.sh).
+# NOTE: Keep in sync with conversion script (/maintainers/scripts/db-to-md.sh).
 # TODO: Remove raw-attribute when we can get rid of DocBook altogether.
 pandoc_commonmark_enabled_extensions = +attributes+fenced_divs+footnotes+bracketed_spans+definition_lists+pipe_tables+raw_attribute
 # Not needed:
@ -11,7 +11,7 @@ pandoc_commonmark_enabled_extensions = +attributes+fenced_divs+footnotes+bracket
 pandoc_flags = --extract-media=$(pandoc_media_dir) \
 	--lua-filter=$(PANDOC_LUA_FILTERS_DIR)/diagram-generator.lua \
 	--lua-filter=build-aux/pandoc-filters/myst-reader/roles.lua \
-	--lua-filter=build-aux/pandoc-filters/link-unix-man-references.lua \
+	--lua-filter=$(PANDOC_LINK_MANPAGES_FILTER) \
 	--lua-filter=build-aux/pandoc-filters/docbook-writer/rst-roles.lua \
 	--lua-filter=build-aux/pandoc-filters/docbook-writer/labelless-link-is-xref.lua \
 	-f commonmark$(pandoc_commonmark_enabled_extensions)+smart
--- a/doc/build-aux/pandoc-filters/docbook-writer/html-elements.lua
+++ b/doc/build-aux/pandoc-filters/docbook-writer/html-elements.lua
@ -1,11 +0,0 @@
--[[
-Converts some HTML elements commonly used in Markdown to corresponding DocBook elements.
-]]
-
-function RawInline(elem)
-  if elem.format == 'html' and elem.text == '<kbd>' then
-    return pandoc.RawInline('docbook', '<keycap>')
-  elseif elem.format == 'html' and elem.text == '</kbd>' then
-    return pandoc.RawInline('docbook', '</keycap>')
-  end
-end
--- a/doc/build-aux/pandoc-filters/link-manpages.nix
+++ b/doc/build-aux/pandoc-filters/link-manpages.nix
@ -0,0 +1,28 @@
+{ pkgs ? import ../../.. {} }:
+let
+  inherit (pkgs) lib;
+  manpageURLs = builtins.fromJSON (builtins.readFile (pkgs.path + "/doc/manpage-urls.json"));
+in pkgs.writeText "link-manpages.lua" ''
+  --[[
+  Adds links to known man pages that aren't already in a link.
+  ]]
+
+  local manpage_urls = {
+  ${lib.concatStringsSep "\n" (lib.mapAttrsToList (man: url:
+    "  [${builtins.toJSON man}] = ${builtins.toJSON url},") manpageURLs)}
+  }
+
+  traverse = 'topdown'
+
+  -- Returning false as the second value aborts processing of child elements.
+  function Link(elem)
+    return elem, false
+  end
+
+  function Code(elem)
+    local is_man_role = elem.classes:includes('interpreted-text') and elem.attributes['role'] == 'manpage'
+    if is_man_role and manpage_urls[elem.text] ~= nil then
+      return pandoc.Link(elem, manpage_urls[elem.text]), false
+    end
+  end
+''
--- a/doc/build-aux/pandoc-filters/link-unix-man-references.lua
+++ b/doc/build-aux/pandoc-filters/link-unix-man-references.lua
@ -1,17 +0,0 @@
--[[
-Turns a manpage reference into a link, when a mapping is defined below.
-]]
-
-local man_urls = {
-  ["tmpfiles.d(5)"] = "https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html",
-  ["nix.conf(5)"] = "https://nixos.org/manual/nix/stable/#sec-conf-file",
-  ["systemd.time(7)"] = "https://www.freedesktop.org/software/systemd/man/systemd.time.html",
-  ["systemd.timer(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.timer.html",
-}
-
-function Code(elem)
-  local is_man_role = elem.classes:includes('interpreted-text') and elem.attributes['role'] == 'manpage'
-  if is_man_role and man_urls[elem.text] ~= nil then
-    return pandoc.Link(elem, man_urls[elem.text])
-  end
-end
--- a/doc/build-aux/pandoc-filters/myst-reader/roles.lua
+++ b/doc/build-aux/pandoc-filters/myst-reader/roles.lua
@ -17,9 +17,16 @@ function Inlines(inlines)
    if correct_tags then
      -- docutils supports alphanumeric strings separated by [-._:]
      -- We are slightly more liberal for simplicity.
-      local role = first.text:match('^{([-._+:%w]+)}$')
-      if role ~= nil then
-        inlines:remove(i)
+      -- Allow preceding punctuation (eg '('), otherwise '({file}`...`)'
+      -- does not match. Also allow anything followed by a non-breaking space
+      -- since pandoc emits those after certain abbreviations (e.g. e.g.).
+      local prefix, role = first.text:match('^(.*){([-._+:%w]+)}$')
+      if role ~= nil and (prefix == '' or prefix:match("^.*[%p ]$") ~= nil) then
+        if prefix == '' then
+          inlines:remove(i)
+        else
+          first.text = prefix
+        end
        second.attributes['role'] = role
        second.classes:insert('interpreted-text')
      end
--- a/doc/builders/fetchers.chapter.md
+++ b/doc/builders/fetchers.chapter.md
@ -14,7 +14,7 @@ For example, consider the following fetcher:
 ```nix
 fetchurl {
  url = "http://www.example.org/hello-1.0.tar.gz";
-  sha256 = "0v6r3wwnsk5pdjr188nip3pjgn1jrn5pc5ajpcfy6had6b3v4dwm";
+  hash = "sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=";
 };
 ```

@ -23,17 +23,17 @@ A common mistake is to update a fetcher’s URL, or a version parameter, without
 ```nix
 fetchurl {
  url = "http://www.example.org/hello-1.1.tar.gz";
-  sha256 = "0v6r3wwnsk5pdjr188nip3pjgn1jrn5pc5ajpcfy6had6b3v4dwm";
+  hash = "sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=";
 };
 ```

 **This will reuse the old contents**.
-Remember to invalidate the hash argument, in this case by setting the `sha256` attribute to an empty string.
+Remember to invalidate the hash argument, in this case by setting the `hash` attribute to an empty string.

 ```nix
 fetchurl {
  url = "http://www.example.org/hello-1.1.tar.gz";
-  sha256 = "";
+  hash = "";
 };
 ```

@ -42,14 +42,14 @@ Use the resulting error message to determine the correct hash.
 ```
 error: hash mismatch in fixed-output derivation '/path/to/my.drv':
         specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
-            got:    sha256-RApQUm78dswhBLC/rfU9y0u6pSAzHceIJqgmetRD24E=
+            got:    sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=
 ```

 A similar problem arises while testing changes to a fetcher's implementation. If the output of the derivation already exists in the Nix store, test failures can go undetected. The [`invalidateFetcherByDrvHash`](#tester-invalidateFetcherByDrvHash) function helps prevent reusing cached derivations.

 ## `fetchurl` and `fetchzip` {#fetchurl}

-Two basic fetchers are `fetchurl` and `fetchzip`. Both of these have two required arguments, a URL and a hash. The hash is typically `sha256`, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use `sha256`. This hash will be used by Nix to identify your source. A typical usage of `fetchurl` is provided below.
+Two basic fetchers are `fetchurl` and `fetchzip`. Both of these have two required arguments, a URL and a hash. The hash is typically `hash`, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use `hash`. This hash will be used by Nix to identify your source. A typical usage of `fetchurl` is provided below.

 ```nix
 { stdenv, fetchurl }:
@ -58,7 +58,7 @@ stdenv.mkDerivation {
  name = "hello";
  src = fetchurl {
    url = "http://www.example.org/hello.tar.gz";
-    sha256 = "1111111111111111111111111111111111111111111111111111";
+    hash = "sha256-BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=";
  };
 }
 ```
@ -76,18 +76,18 @@ The main difference between `fetchurl` and `fetchzip` is in how they store the c
 - `includes`: Include only files matching these patterns (applies after the above arguments).
 - `revert`: Revert the patch.

-Note that because the checksum is computed after applying these effects, using or modifying these arguments will have no effect unless the `sha256` argument is changed as well.
+Note that because the checksum is computed after applying these effects, using or modifying these arguments will have no effect unless the `hash` argument is changed as well.


 Most other fetchers return a directory rather than a single file.

 ## `fetchsvn` {#fetchsvn}

-Used with Subversion. Expects `url` to a Subversion directory, `rev`, and `sha256`.
+Used with Subversion. Expects `url` to a Subversion directory, `rev`, and `hash`.

 ## `fetchgit` {#fetchgit}

-Used with Git. Expects `url` to a Git repo, `rev`, and `sha256`. `rev` in this case can be full the git commit id (SHA1 hash) or a tag name like `refs/tags/v1.0`.
+Used with Git. Expects `url` to a Git repo, `rev`, and `hash`. `rev` in this case can be full the git commit id (SHA1 hash) or a tag name like `refs/tags/v1.0`.

 Additionally, the following optional arguments can be given: `fetchSubmodules = true` makes `fetchgit` also fetch the submodules of a repository. If `deepClone` is set to true, the entire repository is cloned as opposing to just creating a shallow clone. `deepClone = true` also implies `leaveDotGit = true` which means that the `.git` directory of the clone won't be removed after checkout.

@ -104,32 +104,32 @@ stdenv.mkDerivation {
      "directory/to/be/included"
      "another/directory"
    ];
-    sha256 = "0000000000000000000000000000000000000000000000000000";
+    hash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
  };
 }
 ```

 ## `fetchfossil` {#fetchfossil}

-Used with Fossil. Expects `url` to a Fossil archive, `rev`, and `sha256`.
+Used with Fossil. Expects `url` to a Fossil archive, `rev`, and `hash`.

 ## `fetchcvs` {#fetchcvs}

-Used with CVS. Expects `cvsRoot`, `tag`, and `sha256`.
+Used with CVS. Expects `cvsRoot`, `tag`, and `hash`.

 ## `fetchhg` {#fetchhg}

-Used with Mercurial. Expects `url`, `rev`, and `sha256`.
+Used with Mercurial. Expects `url`, `rev`, and `hash`.

 A number of fetcher functions wrap part of `fetchurl` and `fetchzip`. They are mainly convenience functions intended for commonly used destinations of source code in Nixpkgs. These wrapper fetchers are listed below.

 ## `fetchFromGitea` {#fetchfromgitea}

-`fetchFromGitea` expects five arguments. `domain` is the gitea server name. `owner` is a string corresponding to the Gitea user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every Gitea HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but `sha256` is currently preferred.
+`fetchFromGitea` expects five arguments. `domain` is the gitea server name. `owner` is a string corresponding to the Gitea user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every Gitea HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `hash` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but `hash` is currently preferred.

 ## `fetchFromGitHub` {#fetchfromgithub}

-`fetchFromGitHub` expects four arguments. `owner` is a string corresponding to the GitHub user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available, but `sha256` is currently preferred.
+`fetchFromGitHub` expects four arguments. `owner` is a string corresponding to the GitHub user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `hash` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available, but `hash` is currently preferred.

 `fetchFromGitHub` uses `fetchzip` to download the source archive generated by GitHub for the specified revision. If `leaveDotGit`, `deepClone` or `fetchSubmodules` are set to `true`, `fetchFromGitHub` will use `fetchgit` instead. Refer to its section for documentation of these options.

@ -156,10 +156,37 @@ This is used with repo.or.cz repositories. The arguments expected are very simil
 ## `fetchFromSourcehut` {#fetchfromsourcehut}

 This is used with sourcehut repositories. Similar to `fetchFromGitHub` above,
-it expects `owner`, `repo`, `rev` and `sha256`, but don't forget the tilde (~)
+it expects `owner`, `repo`, `rev` and `hash`, but don't forget the tilde (~)
 in front of the username! Expected arguments also include `vc` ("git" (default)
 or "hg"), `domain` and `fetchSubmodules`.

 If `fetchSubmodules` is `true`, `fetchFromSourcehut` uses `fetchgit`
 or `fetchhg` with `fetchSubmodules` or `fetchSubrepos` set to `true`,
 respectively. Otherwise, the fetcher uses `fetchzip`.
+
+## `requireFile` {#requirefile}
+
+`requireFile` allows requesting files that cannot be fetched automatically, but whose content is known.
+This is a useful last-resort workaround for license restrictions that prohibit redistribution, or for downloads that are only accessible after authenticating interactively in a browser.
+If the requested file is present in the Nix store, the resulting derivation will not be built, because its expected output is already available.
+Otherwise, the builder will run, but fail with a message explaining to the user how to provide the file. The following code, for example:
+
+```
+requireFile {
+  name = "jdk-${version}_linux-x64_bin.tar.gz";
+  url = "https://www.oracle.com/java/technologies/javase-jdk11-downloads.html";
+  sha256 = "94bd34f85ee38d3ef59e5289ec7450b9443b924c55625661fffe66b03f2c8de2";
+}
+```
+results in this error message:
+```
+***
+Unfortunately, we cannot download file jdk-11.0.10_linux-x64_bin.tar.gz automatically.
+Please go to https://www.oracle.com/java/technologies/javase-jdk11-downloads.html to download it yourself, and add it to the Nix store
+using either
+  nix-store --add-fixed sha256 jdk-11.0.10_linux-x64_bin.tar.gz
+or
+  nix-prefetch-url --type sha256 file:///path/to/jdk-11.0.10_linux-x64_bin.tar.gz
+
+***
+```
--- a/doc/builders/images.xml
+++ b/doc/builders/images.xml
@ -10,4 +10,6 @@
 <xi:include href="images/ocitools.section.xml" />
 <xi:include href="images/snaptools.section.xml" />
 <xi:include href="images/portableservice.section.xml" />
+ <xi:include href="images/makediskimage.section.xml" />
+ <xi:include href="images/binarycache.section.xml" />
 </chapter>
--- a/doc/builders/images/appimagetools.section.md
+++ b/doc/builders/images/appimagetools.section.md
@ -35,7 +35,7 @@ appimageTools.wrapType2 { # or wrapType1
  name = "patchwork";
  src = fetchurl {
    url = "https://github.com/ssbc/patchwork/releases/download/v3.11.4/Patchwork-3.11.4-linux-x86_64.AppImage";
-    sha256 = "1blsprpkvm0ws9b96gb36f0rbf8f5jgmw4x6dsb1kswr4ysf591s";
+    hash = "sha256-OqTitCeZ6xmWbqYTXp8sDrmVgTNjPZNW0hzUPW++mq4=";
  };
  extraPkgs = pkgs: with pkgs; [ ];
 }
--- a/doc/builders/images/binarycache.section.md
+++ b/doc/builders/images/binarycache.section.md
@ -0,0 +1,49 @@
+# pkgs.mkBinaryCache {#sec-pkgs-binary-cache}
+
+`pkgs.mkBinaryCache` is a function for creating Nix flat-file binary caches. Such a cache exists as a directory on disk, and can be used as a Nix substituter by passing `--substituter file:///path/to/cache` to Nix commands.
+
+Nix packages are most commonly shared between machines using [HTTP, SSH, or S3](https://nixos.org/manual/nix/stable/package-management/sharing-packages.html), but a flat-file binary cache can still be useful in some situations. For example, you can copy it directly to another machine, or make it available on a network file system. It can also be a convenient way to make some Nix packages available inside a container via bind-mounting.
+
+Note that this function is meant for advanced use-cases. The more idiomatic way to work with flat-file binary caches is via the [nix-copy-closure](https://nixos.org/manual/nix/stable/command-ref/nix-copy-closure.html) command. You may also want to consider [dockerTools](#sec-pkgs-dockerTools) for your containerization needs.
+
+## Example
+
+The following derivation will construct a flat-file binary cache containing the closure of `hello`.
+
+```nix
+mkBinaryCache {
+  rootPaths = [hello];
+}
+```
+
+- `rootPaths` specifies a list of root derivations. The transitive closure of these derivations' outputs will be copied into the cache.
+
+Here's an example of building and using the cache.
+
+Build the cache on one machine, `host1`:
+
+```shellSession
+nix-build -E 'with import <nixpkgs> {}; mkBinaryCache { rootPaths = [hello]; }'
+```
+
+```shellSession
+/nix/store/cc0562q828rnjqjyfj23d5q162gb424g-binary-cache
+```
+
+Copy the resulting directory to the other machine, `host2`:
+
+```shellSession
+scp result host2:/tmp/hello-cache
+```
+
+Substitute the derivation using the flat-file binary cache on the other machine, `host2`:
+```shellSession
+nix-build -A hello '<nixpkgs>' \
+  --option require-sigs false \
+  --option trusted-substituters file:///tmp/hello-cache \
+  --option substituters file:///tmp/hello-cache
+```
+
+```shellSession
+/nix/store/gl5a41azbpsadfkfmbilh9yk40dh5dl0-hello-2.12.1
+```
--- a/doc/builders/images/dockertools.section.md
+++ b/doc/builders/images/dockertools.section.md
@ -62,6 +62,8 @@ The above example will build a Docker image `redis/latest` from the given base i

 - `config` is used to specify the configuration of the containers that will be started off the built image in Docker. The available options are listed in the [Docker Image Specification v1.2.0](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions).

+- `architecture` is _optional_ and used to specify the image architecture, this is useful for multi-architecture builds that don't need cross compiling. If not specified it will default to `hostPlatform`.
+
 - `diskSize` is used to specify the disk size of the VM used to build the image in megabytes. By default it's 1024 MiB.

 - `buildVMMemorySize` is used to specify the memory size of the VM to build the image in megabytes. By default it's 512 MiB.
@ -141,7 +143,9 @@ Create a Docker image with many of the store paths being on their own layer to i

 `config` _optional_

-: Run-time configuration of the container. A full list of the options are available at in the [Docker Image Specification v1.2.0](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions).
+`architecture` is _optional_ and used to specify the image architecture, this is useful for multi-architecture builds that don't need cross compiling. If not specified it will default to `hostPlatform`.
+
+: Run-time configuration of the container. A full list of the options available is in the [Docker Image Specification v1.2.0](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions).

    *Default:* `{}`

@ -245,10 +249,10 @@ Its parameters are described in the example below:
 pullImage {
  imageName = "nixos/nix";
  imageDigest =
-    "sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b";
+    "sha256:473a2b527958665554806aea24d0131bacec46d23af09fef4598eeab331850fa";
  finalImageName = "nix";
-  finalImageTag = "1.11";
-  sha256 = "0mqjy3zq2v6rrhizgb9nvhczl87lcfphq9601wcprdika2jz7qh8";
+  finalImageTag = "2.11.1";
+  sha256 = "sha256-qvhj+Hlmviz+KEBVmsyPIzTB3QlVAFzwAY1zDPIBGxc=";
  os = "linux";
  arch = "x86_64";
 }
@ -394,3 +398,142 @@ buildImage {
  };
 }
 ```
+
+## buildNixShellImage {#ssec-pkgs-dockerTools-buildNixShellImage}
+
+Create a Docker image that sets up an environment similar to that of running `nix-shell` on a derivation.
+When run in Docker, this environment somewhat resembles the Nix sandbox typically used by `nix-build`, with a major difference being that access to the internet is allowed.
+It additionally also behaves like an interactive `nix-shell`, running things like `shellHook` and setting an interactive prompt.
+If the derivation is fully buildable (i.e. `nix-build` can be used on it), running `buildDerivation` inside such a Docker image will build the derivation, with all its outputs being available in the correct `/nix/store` paths, pointed to by the respective environment variables like `$out`, etc.
+
+::: {.warning}
+The behavior doesn't match `nix-shell` or `nix-build` exactly and this function is known not to work correctly for e.g. fixed-output derivations, content-addressed derivations, impure derivations and other special types of derivations.
+:::
+
+### Arguments
+
+`drv`
+
+: The derivation on which to base the Docker image.
+
+    Adding packages to the Docker image is possible by e.g. extending the list of `nativeBuildInputs` of this derivation like
+
+    ```nix
+    buildNixShellImage {
+      drv = someDrv.overrideAttrs (old: {
+        nativeBuildInputs = old.nativeBuildInputs or [] ++ [
+          somethingExtra
+        ];
+      });
+      # ...
+    }
+    ```
+
+    Similarly, you can extend the image initialization script by extending `shellHook`
+
+`name` _optional_
+
+: The name of the resulting image.
+
+    *Default:* `drv.name + "-env"`
+
+`tag` _optional_
+
+: Tag of the generated image.
+
+    *Default:* the resulting image derivation output path's hash
+
+`uid`/`gid` _optional_
+
+: The user/group ID to run the container as. This is like a `nixbld` build user.
+
+    *Default:* 1000/1000
+
+`homeDirectory` _optional_
+
+: The home directory of the user the container is running as
+
+    *Default:* `/build`
+
+`shell` _optional_
+
+: The path to the `bash` binary to use as the shell. This shell is started when running the image.
+
+    *Default:* `pkgs.bashInteractive + "/bin/bash"`
+
+`command` _optional_
+
+: Run this command in the environment of the derivation, in an interactive shell. See the `--command` option in the [`nix-shell` documentation](https://nixos.org/manual/nix/stable/command-ref/nix-shell.html?highlight=nix-shell#options).
+
+    *Default:* (none)
+
+`run` _optional_
+
+: Same as `command`, but runs the command in a non-interactive shell instead. See the `--run` option in the [`nix-shell` documentation](https://nixos.org/manual/nix/stable/command-ref/nix-shell.html?highlight=nix-shell#options).
+
+    *Default:* (none)
+
+### Example
+
+The following shows how to build the `pkgs.hello` package inside a Docker container built with `buildNixShellImage`.
+
+```nix
+with import <nixpkgs> {};
+dockerTools.buildNixShellImage {
+  drv = hello;
+}
+```
+
+Build the derivation:
+
+```console
+nix-build hello.nix
+```
+
+    these 8 derivations will be built:
+      /nix/store/xmw3a5ln29rdalavcxk1w3m4zb2n7kk6-nix-shell-rc.drv
+    ...
+    Creating layer 56 from paths: ['/nix/store/crpnj8ssz0va2q0p5ibv9i6k6n52gcya-stdenv-linux']
+    Creating layer 57 with customisation...
+    Adding manifests...
+    Done.
+    /nix/store/cpyn1lc897ghx0rhr2xy49jvyn52bazv-hello-2.12-env.tar.gz
+
+Load the image:
+
+```console
+docker load -i result
+```
+
+    0d9f4c4cd109: Loading layer [==================================================>]   2.56MB/2.56MB
+    ...
+    ab1d897c0697: Loading layer [==================================================>]  10.24kB/10.24kB
+    Loaded image: hello-2.12-env:pgj9h98nal555415faa43vsydg161bdz
+
+Run the container:
+
+```console
+docker run -it hello-2.12-env:pgj9h98nal555415faa43vsydg161bdz
+```
+
+    [nix-shell:/build]$
+
+In the running container, run the build:
+
+```console
+buildDerivation
+```
+
+    unpacking sources
+    unpacking source archive /nix/store/8nqv6kshb3vs5q5bs2k600xpj5bkavkc-hello-2.12.tar.gz
+    ...
+    patching script interpreter paths in /nix/store/z5wwy5nagzy15gag42vv61c2agdpz2f2-hello-2.12
+    checking for references to /build/ in /nix/store/z5wwy5nagzy15gag42vv61c2agdpz2f2-hello-2.12...
+
+Check the build result:
+
+```console
+$out/bin/hello
+```
+
+    Hello, world!
--- a/doc/builders/images/makediskimage.section.md
+++ b/doc/builders/images/makediskimage.section.md
@ -0,0 +1,108 @@
+# `<nixpkgs/nixos/lib/make-disk-image.nix>` {#sec-make-disk-image}
+
+`<nixpkgs/nixos/lib/make-disk-image.nix>` is a function to create _disk images_ in multiple formats: raw, QCOW2 (QEMU), QCOW2-Compressed (compressed version), VDI (VirtualBox), VPC (VirtualPC).
+
+This function can create images in two ways:
+
+- using `cptofs` without any virtual machine to create a Nix store disk image,
+- using a virtual machine to create a full NixOS installation.
+
+When testing early-boot or lifecycle parts of NixOS such as a bootloader or multiple generations, it is necessary to opt for a full NixOS system installation.
+Whereas for many web servers, applications, it is possible to work with a Nix store only disk image and is faster to build.
+
+NixOS tests also use this function when preparing the VM. The `cptofs` method is used when `virtualisation.useBootLoader` is false (the default). Otherwise the second method is used.
+
+## Features
+
+For reference, read the function signature source code for documentation on arguments: <https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-disk-image.nix>.
+Features are separated in various sections depending on if you opt for a Nix-store only image or a full NixOS image.
+
+### Common
+
+- arbitrary NixOS configuration
+- automatic or bound disk size: `diskSize` parameter, `additionalSpace` can be set when `diskSize` is `auto` to add a constant of disk space
+- multiple partition table layouts: EFI, legacy, legacy + GPT, hybrid, none through `partitionTableType` parameter
+- OVMF or EFI firmwares and variables templates can be customized
+- root filesystem `fsType` can be customized to whatever `mkfs.${fsType}` exist during operations
+- root filesystem label can be customized, defaults to `nix-store` if it's a Nix store image, otherwise `nixpkgs/nixos`
+- arbitrary code can be executed after disk image was produced with `postVM`
+- the current nixpkgs can be realized as a channel in the disk image, which will change the hash of the image when the sources are updated
+- additional store paths can be provided through `additionalPaths`
+
+### Full NixOS image
+
+- arbitrary contents with permissions can be placed in the target filesystem using `contents`
+- a `/etc/nixpkgs/nixos/configuration.nix` can be provided through `configFile`
+- bootloaders are supported
+- EFI variables can be mutated during image production and the result is exposed in `$out`
+- boot partition size when partition table is `efi` or `hybrid`
+
+### On bit-to-bit reproducibility
+
+Images are **NOT** deterministic, please do not hesitate to try to fix this, source of determinisms are (not exhaustive) :
+
+- bootloader installation have timestamps
+- SQLite Nix store database contain registration times
+- `/etc/shadow` is in a non-deterministic order
+
+A `deterministic` flag is available for best efforts determinism.
+
+## Usage
+
+To produce a Nix-store only image:
+```nix
+let
+  pkgs = import <nixpkgs> {};
+  lib = pkgs.lib;
+  make-disk-image = import <nixpkgs/nixos/lib/make-disk-image.nix>;
+in
+  make-disk-image {
+    inherit pkgs lib;
+    config = {};
+    additionalPaths = [ ];
+    format = "qcow2";
+    onlyNixStore = true;
+    partitionTableType = "none";
+    installBootLoader = false;
+    touchEFIVars = false;
+    diskSize = "auto";
+    additionalSpace = "0M"; # Defaults to 512M.
+    copyChannel = false;
+  }
+```
+
+Some arguments can be left out, they are shown explicitly for the sake of the example.
+
+Building this derivation will provide a QCOW2 disk image containing only the Nix store and its registration information.
+
+To produce a NixOS installation image disk with UEFI and bootloader installed:
+```nix
+let
+  pkgs = import <nixpkgs> {};
+  lib = pkgs.lib;
+  make-disk-image = import <nixpkgs/nixos/lib/make-disk-image.nix>;
+  evalConfig = import <nixpkgs/nixos/lib/eval-config.nix>;
+in
+  make-disk-image {
+    inherit pkgs lib;
+    config = evalConfig {
+      modules = [
+        {
+          fileSystems."/" = { device = "/dev/vda"; fsType = "ext4"; autoFormat = true; };
+          boot.grub.device = "/dev/vda";
+        }
+      ];
+    };
+    format = "qcow2";
+    onlyNixStore = false;
+    partitionTableType = "legacy+gpt";
+    installBootLoader = true;
+    touchEFIVars = true;
+    diskSize = "auto";
+    additionalSpace = "0M"; # Defaults to 512M.
+    copyChannel = false;
+    memSize = 2048; # Qemu VM memory size in megabytes. Defaults to 1024M.
+  }
+```
+
+
--- a/doc/builders/images/ocitools.section.md
+++ b/doc/builders/images/ocitools.section.md
@ -34,4 +34,4 @@ buildContainer {

 - `mounts` specifies additional mount points chosen by the user. By default only a minimal set of necessary filesystems are mounted into the container (e.g procfs, cgroupfs)

- `readonly` makes the container\'s rootfs read-only if it is set to true. The default value is false `false`.
+- `readonly` makes the container's rootfs read-only if it is set to true. The default value is false `false`.
--- a/doc/builders/packages/cataclysm-dda.section.md
+++ b/doc/builders/packages/cataclysm-dda.section.md
@ -103,7 +103,7 @@ let
        owner = "Someone";
        repo = "AwesomeMod";
        rev = "...";
-        sha256 = "...";
+        hash = "...";
      };
      # Path to be installed in the unpacked source (default: ".")
      modRoot = "contents/under/this/path/will/be/installed";
--- a/doc/builders/packages/citrix.section.md
+++ b/doc/builders/packages/citrix.section.md
@ -4,7 +4,7 @@ The [Citrix Workspace App](https://www.citrix.com/products/workspace-app/) is a

 ## Basic usage {#sec-citrix-base}

-The tarball archive needs to be downloaded manually, as the license agreements of the vendor for [Citrix Workspace](https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html) needs to be accepted first. Then run `nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz`. With the archive available in the store, the package can be built and installed with Nix.
+The tarball archive needs to be downloaded manually, as the license agreements of the vendor for [Citrix Workspace](https://www.citrix.com/downloads/workspace-app/linux/workspace-app-for-linux-latest.html) needs to be accepted first. Then run `nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz`. With the archive available in the store, the package can be built and installed with Nix.

 ## Citrix Self-service {#sec-citrix-selfservice}

@ -19,7 +19,7 @@ $ selfservice

 ## Custom certificates {#sec-citrix-custom-certs}

-The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However, several companies using Citrix might require their own corporate certificate. On distros with imperative packaging, these certs can be stored easily in [`$ICAROOT`](https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/), however this directory is a store path in `nixpkgs`. In order to work around this issue, the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
+The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However, several companies using Citrix might require their own corporate certificate. On distros with imperative packaging, these certs can be stored easily in [`$ICAROOT`](https://citrix.github.io/receiver-for-linux-command-reference/), however this directory is a store path in `nixpkgs`. In order to work around this issue, the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:

 ```nix
 with import <nixpkgs> { config.allowUnfree = true; };
--- a/doc/builders/packages/dlib.section.md
+++ b/doc/builders/packages/dlib.section.md
@ -4,7 +4,7 @@

 ## Compiling without AVX support {#compiling-without-avx-support}

-Especially older CPUs don\'t support [AVX](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions) (Advanced Vector Extensions) instructions that are used by DLib to optimize their algorithms.
+Especially older CPUs don't support [AVX](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions) (Advanced Vector Extensions) instructions that are used by DLib to optimize their algorithms.

 On the affected hardware errors like `Illegal instruction` will occur. In those cases AVX support needs to be disabled:

--- a/doc/builders/packages/eclipse.section.md
+++ b/doc/builders/packages/eclipse.section.md
@ -43,11 +43,11 @@ packageOverrides = pkgs: {
        name = "myplugin1-1.0";
        srcFeature = fetchurl {
          url = "http://…/features/myplugin1.jar";
-          sha256 = "123…";
+          hash = "sha256-123…";
        };
        srcPlugin = fetchurl {
          url = "http://…/plugins/myplugin1.jar";
-          sha256 = "123…";
+          hash = "sha256-123…";
        };
      });
      (plugins.buildEclipseUpdateSite {
@ -55,7 +55,7 @@ packageOverrides = pkgs: {
        src = fetchurl {
          stripRoot = false;
          url = "http://…/myplugin2.zip";
-          sha256 = "123…";
+          hash = "sha256-123…";
        };
      });
    ];
--- a/doc/builders/packages/firefox.section.md
+++ b/doc/builders/packages/firefox.section.md
@ -12,7 +12,7 @@ The `wrapFirefox` function allows to pass policies, preferences and extensions t
      (fetchFirefoxAddon {
        name = "ublock"; # Has to be unique!
        url = "https://addons.mozilla.org/firefox/downloads/file/3679754/ublock_origin-1.31.0-an+fx.xpi";
-        sha256 = "1h768ljlh3pi23l27qp961v1hd0nbj2vasgy11bmcrlqp40zgvnr";
+        hash = "sha256-2e73AbmYZlZXCP5ptYVcFjQYdjDp4iPoEPEOSCVF5sA=";
      })
    ];

--- a/doc/builders/packages/ibus.section.md
+++ b/doc/builders/packages/ibus.section.md
@ -4,7 +4,7 @@ This package is an ibus-based completion method to speed up typing.

 ## Activating the engine {#sec-ibus-typing-booster-activate}

-IBus needs to be configured accordingly to activate `typing-booster`. The configuration depends on the desktop manager in use. For detailed instructions, please refer to the [upstream docs](https://mike-fabian.github.io/ibus-typing-booster/documentation.html).
+IBus needs to be configured accordingly to activate `typing-booster`. The configuration depends on the desktop manager in use. For detailed instructions, please refer to the [upstream docs](https://mike-fabian.github.io/ibus-typing-booster/).

 On NixOS, you need to explicitly enable `ibus` with given engines before customizing your desktop to use `typing-booster`. This can be achieved using the `ibus` module:

--- a/doc/builders/packages/weechat.section.md
+++ b/doc/builders/packages/weechat.section.md
@ -73,7 +73,7 @@ stdenv.mkDerivation {
  name = "exemplary-weechat-script";
  src = fetchurl {
    url = "https://scripts.tld/your-scripts.tar.gz";
-    sha256 = "...";
+    hash = "...";
  };
  passthru.scripts = [ "foo.py" "bar.lua" ];
  installPhase = ''
--- a/doc/builders/special.xml
+++ b/doc/builders/special.xml
@ -6,5 +6,7 @@
  This chapter describes several special builders.
 </para>
 <xi:include href="special/fhs-environments.section.xml" />
+ <xi:include href="special/makesetuphook.section.xml" />
 <xi:include href="special/mkshell.section.xml" />
+ <xi:include href="special/darwin-builder.section.xml" />
 </chapter>
--- a/doc/builders/special/darwin-builder.section.md
+++ b/doc/builders/special/darwin-builder.section.md
@ -0,0 +1,63 @@
+# darwin.builder {#sec-darwin-builder}
+
+`darwin.builder` provides a way to bootstrap a Linux builder on a macOS machine.
+
+This requires macOS version 12.4 or later.
+
+This also requires that port 22 on your machine is free (since Nix does not
+permit specifying a non-default SSH port for builders).
+
+You will also need to be a trusted user for your Nix installation.  In other
+words, your `/etc/nix/nix.conf` should have something like:
+
+```
+extra-trusted-users = <your username goes here>
+```
+
+To launch the builder, run the following flake:
+
+```ShellSession
+$ nix run nixpkgs#darwin.builder
+```
+
+That will prompt you to enter your `sudo` password:
+
+```
+ sudo --reset-timestamp /nix/store/…-install-credentials.sh ./keys
+Password:
+```
+
+… so that it can install a private key used to `ssh` into the build server.
+After that the script will launch the virtual machine and automatically log you
+in as the `builder` user:
+
+```
+<<< Welcome to NixOS 22.11.20220901.1bd8d11 (aarch64) - ttyAMA0 >>>
+
+Run 'nixos-help' for the NixOS manual.
+
+nixos login: builder (automatic login)
+
+
+[builder@nixos:~]$
+```
+
+> Note: When you need to stop the VM, run `shutdown now` as the `builder` user.
+
+To delegate builds to the remote builder, add the following options to your
+`nix.conf` file:
+
+```
+# - Replace ${ARCH} with either aarch64 or x86_64 to match your host machine
+# - Replace ${MAX_JOBS} with the maximum number of builds (pick 4 if you're not sure)
+builders = ssh-ng://builder@localhost ${ARCH}-linux /etc/nix/builder_ed25519 ${MAX_JOBS} - - - c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUpCV2N4Yi9CbGFxdDFhdU90RStGOFFVV3JVb3RpQzVxQkorVXVFV2RWQ2Igcm9vdEBuaXhvcwo=
+
+# Not strictly necessary, but this will reduce your disk utilization
+builders-use-substitutes = true
+```
+
+… and then restart your Nix daemon to apply the change:
+
+```ShellSession
+$ sudo launchctl kickstart -k system/org.nixos.nix-daemon
+```
--- a/doc/builders/special/makesetuphook.section.md
+++ b/doc/builders/special/makesetuphook.section.md
@ -0,0 +1,37 @@
+# pkgs.makeSetupHook {#sec-pkgs.makeSetupHook}
+
+`pkgs.makeSetupHook` is a builder that produces hooks that go in to `nativeBuildInputs`
+
+## Usage {#sec-pkgs.makeSetupHook-usage}
+
+```nix
+pkgs.makeSetupHook {
+  name = "something-hook";
+  propagatedBuildInputs = [ pkgs.commandsomething ];
+  depsTargetTargetPropagated = [ pkgs.libsomething ];
+} ./script.sh
+```
+
+#### setup hook that depends on the hello package and runs hello and @shell@ is substituted with path to bash
+
+```nix
+pkgs.makeSetupHook {
+    name = "run-hello-hook";
+    propagatedBuildInputs = [ pkgs.hello ];
+    substitutions = { shell = "${pkgs.bash}/bin/bash"; };
+    passthru.tests.greeting = callPackage ./test { };
+    meta.platforms = lib.platforms.linux;
+} (writeScript "run-hello-hook.sh" ''
+    #!@shell@
+    hello
+'')
+```
+
+## Attributes
+
+* `name` Set the name of the hook.
+* `propagatedBuildInputs` Runtime dependencies (such as binaries) of the hook.
+* `depsTargetTargetPropagated` Non-binary dependencies.
+* `meta`
+* `passthru`
+* `substitutions` Variables for `substituteAll`
--- a/doc/builders/testers.chapter.md
+++ b/doc/builders/testers.chapter.md
@ -1,6 +1,19 @@
 # Testers {#chap-testers}
 This chapter describes several testing builders which are available in the <literal>testers</literal> namespace.

+## `hasPkgConfigModule` {#tester-hasPkgConfigModule}
+
+Checks whether a package exposes a certain `pkg-config` module.
+
+Example:
+
+```nix
+passthru.tests.pkg-config = testers.hasPkgConfigModule {
+  package = finalAttrs.finalPackage;
+  moduleName = "libfoo";
+}
+```
+
 ## `testVersion` {#tester-testVersion}

 Checks the command output contains the specified version
@ -62,7 +75,7 @@ runCommand "example" {
 '';
 ```

-While `testBuildFailure` is designed to keep changes to the original builder's 
+While `testBuildFailure` is designed to keep changes to the original builder's
 environment to a minimum, some small changes are inevitable.

 - The file `$TMPDIR/testBuildFailure.log` is present. It should not be deleted.
@ -147,7 +160,7 @@ tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
  name = "nix-source";
  url = "https://github.com/NixOS/nix";
  rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a";
-  sha256 = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
+  hash = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
 };
 ```

--- a/doc/contributing/coding-conventions.chapter.md
+++ b/doc/contributing/coding-conventions.chapter.md
@ -204,13 +204,13 @@ The key words _must_, _must not_, _required_, _shall_, _shall not_, _should_, _s

 In Nixpkgs, there are generally three different names associated with a package:

- The `name` attribute of the derivation (excluding the version part). This is what most users see, in particular when using `nix-env`.
+- The `pname` attribute of the derivation. This is what most users see, in particular when using `nix-env`.

 - The variable name used for the instantiated package in `all-packages.nix`, and when passing it as a dependency to other functions. Typically this is called the _package attribute name_. This is what Nix expression authors see. It can also be used when installing using `nix-env -iA`.

 - The filename for (the directory containing) the Nix expression.

-Most of the time, these are the same. For instance, the package `e2fsprogs` has a `name` attribute `"e2fsprogs-version"`, is bound to the variable name `e2fsprogs` in `all-packages.nix`, and the Nix expression is in `pkgs/os-specific/linux/e2fsprogs/default.nix`.
+Most of the time, these are the same. For instance, the package `e2fsprogs` has a `pname` attribute `"e2fsprogs"`, is bound to the variable name `e2fsprogs` in `all-packages.nix`, and the Nix expression is in `pkgs/os-specific/linux/e2fsprogs/default.nix`.

 There are a few naming guidelines:

@ -260,6 +260,10 @@ When in doubt, consider refactoring the `pkgs/` tree, e.g. creating new categori

    - `development/tools/build-managers` (e.g. `gnumake`)

+  - **If it’s a _language server_:**
+
+    - `development/tools/language-servers` (e.g. `ccls` or `rnix-lsp`)
+
  - **Else:**

    - `development/tools/misc` (e.g. `binutils`)
@ -426,9 +430,10 @@ In the file `pkgs/top-level/all-packages.nix` you can find fetch helpers, these

  ```nix
  src = fetchgit {
+    url = "git@github.com:NixOS/nix.git"
    url = "git://github.com/NixOS/nix.git";
    rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
-    sha256 = "1cw5fszffl5pkpa6s6wjnkiv6lm5k618s32sp60kvmvpy7a2v9kg";
+    hash = "sha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=";
  }
  ```

@ -438,7 +443,7 @@ In the file `pkgs/top-level/all-packages.nix` you can find fetch helpers, these
  src = fetchgit {
    url = "https://github.com/NixOS/nix.git";
    rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
-    sha256 = "1cw5fszffl5pkpa6s6wjnkiv6lm5k618s32sp60kvmvpy7a2v9kg";
+    hash = "sha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=";
  }
  ```

@ -449,14 +454,14 @@ In the file `pkgs/top-level/all-packages.nix` you can find fetch helpers, these
    owner = "NixOS";
    repo = "nix";
    rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
-    sha256 = "1i2yxndxb6yc9l6c99pypbd92lfq5aac4klq7y2v93c9qvx2cgpc";
+    hash = "ha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=;
  }
  ```

 When fetching from GitHub, commits must always be referenced by their full commit hash. This is because GitHub shares commit hashes among all forks and returns `404 Not Found` when a short commit hash is ambiguous. It already happens for some short, 6-character commit hashes in `nixpkgs`.
 It is a practical vector for a denial-of-service attack by pushing large amounts of auto generated commits into forks and was already [demonstrated against GitHub Actions Beta](https://blog.teddykatz.com/2019/11/12/github-actions-dos.html).

-Find the value to put as `sha256` by running `nix-shell -p nix-prefetch-github --run "nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS nix"`. 
+Find the value to put as `hash` by running `nix-shell -p nix-prefetch-github --run "nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS nix"`.

 ## Obtaining source hash {#sec-source-hashes}

@ -486,12 +491,12 @@ Preferred source hash type is sha256. There are several ways to get it.
   - `lib.fakeHash`
   - `lib.fakeSha256`
   - `lib.fakeSha512`
-   
+
   in the package expression, attempt build and extract correct hash from error messages.

   ::: {.warning}
   You must use one of these four fake hashes and not some arbitrarily-chosen hash.
-   
+
   See [](#sec-source-hashes-security).
   :::

@ -519,7 +524,7 @@ patches = [
  (fetchpatch {
    name = "fix-check-for-using-shared-freetype-lib.patch";
    url = "http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=8f5d285";
-    sha256 = "1f0k043rng7f0rfl9hhb89qzvvksqmkrikmm38p61yfx51l325xr";
+    hash = "sha256-uRcxaCjd+WAuGrXOmGfFeu79cUILwkRdBu48mwcBE7g=";
  })
 ];
 ```
@ -669,3 +674,18 @@ stdenv.mkDerivation {
  ...
 }
 ```
+
+### Import From Derivation {#ssec-import-from-derivation}
+
+Import From Derivation (IFD) is disallowed in Nixpkgs for performance reasons:
+[Hydra] evaluates the entire package set, and sequential builds during evaluation would increase evaluation times to become impractical.
+
+[Hydra]: https://github.com/NixOS/hydra
+
+Import From Derivation can be worked around in some cases by committing generated intermediate files to version control and reading those instead.
+
+<!-- TODO: remove the following and link to Nix manual once https://github.com/NixOS/nix/pull/7332 is merged -->
+
+See also [NixOS Wiki: Import From Derivation].
+
+[NixOS Wiki: Import From Derivation]: https://nixos.wiki/wiki/Import_From_Derivation
--- a/doc/contributing/contributing-to-documentation.chapter.md
+++ b/doc/contributing/contributing-to-documentation.chapter.md
@ -27,7 +27,7 @@ If the build succeeds, the manual will be in `./result/share/doc/nixpkgs/manual.

 As per [RFC 0072](https://github.com/NixOS/rfcs/pull/72), all new documentation content should be written in [CommonMark](https://commonmark.org/) Markdown dialect.

-Additional syntax extensions are available, though not all extensions can be used in NixOS option documentation. The following extensions are currently used:
+Additional syntax extensions are available, all of which can be used in NixOS option documentation. The following extensions are currently used:

 - []{#ssec-contributing-markup-anchors}
  Explicitly defined **anchors** on headings, to allow linking to sections. These should be always used, to ensure the anchors can be linked even when the heading text changes, and to prevent conflicts between [automatically assigned identifiers](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/auto_identifiers.md).
@ -38,6 +38,10 @@ Additional syntax extensions are available, though not all extensions can be use
  ## Syntax {#sec-contributing-markup}
  ```

+  ::: {.note}
+  NixOS option documentation does not support headings in general.
+  :::
+
 - []{#ssec-contributing-markup-anchors-inline}
  **Inline anchors**, which allow linking arbitrary place in the text (e.g. individual list items, sentences…).

@ -53,7 +57,7 @@ Additional syntax extensions are available, though not all extensions can be use
  This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/using/syntax.html#targets-and-cross-referencing).

 - []{#ssec-contributing-markup-inline-roles}
-  If you want to link to a man page, you can use `` {manpage}`nix.conf(5)` ``, which will turn into {manpage}`nix.conf(5)`. The references will turn into links when a mapping exists in {file}`doc/build-aux/pandoc-filters/link-unix-man-references.lua`.
+  If you want to link to a man page, you can use `` {manpage}`nix.conf(5)` ``, which will turn into {manpage}`nix.conf(5)`. The references will turn into links when a mapping exists in {file}`doc/manpage-urls.json`.

  A few markups for other kinds of literals are also available:

@ -67,10 +71,6 @@ Additional syntax extensions are available, though not all extensions can be use

  This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html#roles-an-in-line-extension-point). Though, the feature originates from [reStructuredText](https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-manpage) with slightly different syntax.

-  ::: {.note}
-  Inline roles are available for option documentation.
-  :::
-
 - []{#ssec-contributing-markup-admonitions}
  **Admonitions**, set off from the text to bring attention to something.

@ -96,10 +96,6 @@ Additional syntax extensions are available, though not all extensions can be use
    - [`tip`](https://tdg.docbook.org/tdg/5.0/tip.html)
    - [`warning`](https://tdg.docbook.org/tdg/5.0/warning.html)

-  ::: {.note}
-  Admonitions are available for option documentation.
-  :::
-
 - []{#ssec-contributing-markup-definition-lists}
  [**Definition lists**](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/definition_lists.md), for defining a group of terms:

--- a/doc/contributing/quick-start.chapter.md
+++ b/doc/contributing/quick-start.chapter.md
@ -34,7 +34,7 @@ To add a package to Nixpkgs:

   - Apache HTTPD: [`pkgs/servers/http/apache-httpd/2.4.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/http/apache-httpd/2.4.nix). A bunch of optional features, variable substitutions in the configure flags, a post-install hook, and miscellaneous hackery.

-   - Thunderbird: [`pkgs/applications/networking/mailreaders/thunderbird/default.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/mailreaders/thunderbird/default.nix). Lots of dependencies.
+   - buildMozillaMach: [`pkgs/applications/networking/browser/firefox/common.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/browsers/firefox/common.nix). A reusable build function for Firefox, Thunderbird and Librewolf.

   - JDiskReport, a Java utility: [`pkgs/tools/misc/jdiskreport/default.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/misc/jdiskreport/default.nix). Nixpkgs doesn’t have a decent `stdenv` for Java yet so this is pretty ad-hoc.

--- a/doc/contributing/reviewing-contributions.chapter.md
+++ b/doc/contributing/reviewing-contributions.chapter.md
@ -185,7 +185,7 @@ Sample template for a new module review is provided below.
 ##### Comments
 ```

-## Individual maintainer list {#reviewing-contributions-indvidual-maintainer-list}
+## Individual maintainer list {#reviewing-contributions-individual-maintainer-list}

 When adding users to `maintainers/maintainer-list.nix`, the following
 checks should be performed:
--- a/doc/contributing/submitting-changes.chapter.md
+++ b/doc/contributing/submitting-changes.chapter.md
@ -76,7 +76,7 @@ Security fixes are submitted in the same way as other changes and thus the same
  (fetchpatch {
    name = "CVE-2019-11068.patch";
    url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
-    sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
+    hash = "sha256-SEKe/8HcW0UBHCfPTTOnpRlzmV2nQPPeL6HOMxBZd14=";
  })
  ```

@ -199,7 +199,7 @@ It’s important to test any executables generated by a build when you change or

 ### Meets Nixpkgs contribution standards {#submitting-changes-contribution-standards}

-The last checkbox is fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md). The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc\... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
+The last checkbox is fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md). The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc... Everyone should read and understand the standards the community has for contributing before submitting a pull request.

 ## Hotfixing pull requests {#submitting-changes-hotfixing-pull-requests}

--- a/doc/default.nix
+++ b/doc/default.nix
@ -1,6 +1,5 @@
 { pkgs ? (import ./.. { }), nixpkgs ? { }}:
 let
-  lib = pkgs.lib;
  doc-support = import ./doc-support { inherit pkgs nixpkgs; };
 in pkgs.stdenv.mkDerivation {
  name = "nixpkgs-manual";
@ -15,7 +14,7 @@ in pkgs.stdenv.mkDerivation {
    xmlformat
  ];

-  src = lib.cleanSource ./.;
+  src = pkgs.nix-gitignore.gitignoreSource [] ./.;

  postPatch = ''
    ln -s ${doc-support} ./doc-support/result
@ -36,4 +35,5 @@ in pkgs.stdenv.mkDerivation {

  # Environment variables
  PANDOC_LUA_FILTERS_DIR = "${pkgs.pandoc-lua-filters}/share/pandoc/filters";
+  PANDOC_LINK_MANPAGES_FILTER = import build-aux/pandoc-filters/link-manpages.nix { inherit pkgs; };
 }
--- a/doc/doc-support/default.nix
+++ b/doc/doc-support/default.nix
@ -3,8 +3,23 @@ let
  inherit (pkgs) lib;
  inherit (lib) hasPrefix removePrefix;

-  locationsXml = import ./lib-function-locations.nix { inherit pkgs nixpkgs; };
-  functionDocs = import ./lib-function-docs.nix { inherit locationsXml pkgs; };
+  libsets = [
+    { name = "asserts"; description = "assertion functions"; }
+    { name = "attrsets"; description = "attribute set functions"; }
+    { name = "strings"; description = "string manipulation functions"; }
+    { name = "versions"; description = "version string functions"; }
+    { name = "trivial"; description = "miscellaneous functions"; }
+    { name = "lists"; description = "list manipulation functions"; }
+    { name = "debug"; description = "debugging functions"; }
+    { name = "options"; description = "NixOS / nixpkgs option handling"; }
+    { name = "path"; description = "path functions"; }
+    { name = "filesystem"; description = "filesystem functions"; }
+    { name = "sources"; description = "source filtering functions"; }
+    { name = "cli"; description = "command-line serialization functions"; }
+  ];
+
+  locationsXml = import ./lib-function-locations.nix { inherit pkgs nixpkgs libsets; };
+  functionDocs = import ./lib-function-docs.nix { inherit locationsXml pkgs libsets; };
  version = pkgs.lib.version;

  epub-xsl = pkgs.writeText "epub.xsl" ''
@ -60,7 +75,7 @@ in pkgs.runCommand "doc-support" {}
    ln -s ${epub-xsl} ./epub.xsl
    ln -s ${xhtml-xsl} ./xhtml.xsl

-    ln -s ${../../nixos/doc/xmlformat.conf} ./xmlformat.conf
+    ln -s ${./xmlformat.conf} ./xmlformat.conf
    ln -s ${pkgs.documentation-highlighter} ./highlightjs

    echo -n "${version}" > ./version
--- a/doc/doc-support/lib-function-docs.nix
+++ b/doc/doc-support/lib-function-docs.nix
@ -1,28 +1,36 @@
-# Generates the documentation for library functons via nixdoc. To add
-# another library function file to this list, the include list in the
-# file `doc/functions/library.xml` must also be updated.
+# Generates the documentation for library functions via nixdoc.

-{ pkgs ? import ./.. {}, locationsXml }:
+{ pkgs, locationsXml, libsets }:

 with pkgs; stdenv.mkDerivation {
  name = "nixpkgs-lib-docs";
-  src = ./../../lib;
+  src = ../../lib;

  buildInputs = [ nixdoc ];
  installPhase = ''
    function docgen {
-      nixdoc -c "$1" -d "$2" -f "../lib/$1.nix"  > "$out/$1.xml"
+      # TODO: wrap lib.$1 in <literal>, make nixdoc not escape it
+      if [[ -e "../lib/$1.nix" ]]; then
+        nixdoc -c "$1" -d "lib.$1: $2" -f "$1.nix" > "$out/$1.xml"
+      else
+        nixdoc -c "$1" -d "lib.$1: $2" -f "$1/default.nix" > "$out/$1.xml"
+      fi
+      echo "<xi:include href='$1.xml' />" >> "$out/index.xml"
    }

-    mkdir -p $out
-    ln -s ${locationsXml} $out/locations.xml
+    mkdir -p "$out"

-    docgen strings 'String manipulation functions'
-    docgen trivial 'Miscellaneous functions'
-    docgen lists 'List manipulation functions'
-    docgen debug 'Debugging functions'
-    docgen options 'NixOS / nixpkgs option handling'
-    docgen filesystem 'Filesystem functions'
-    docgen sources 'Source filtering functions'
+    cat > "$out/index.xml" << 'EOF'
+    <?xml version="1.0" encoding="utf-8"?>
+    <root xmlns:xi="http://www.w3.org/2001/XInclude">
+    EOF
+
+    ${lib.concatMapStrings ({ name, description }: ''
+      docgen ${name} ${lib.escapeShellArg description}
+    '') libsets}
+
+    echo "</root>" >> "$out/index.xml"
+
+    ln -s ${locationsXml} $out/locations.xml
  '';
 }
--- a/doc/doc-support/lib-function-locations.nix
+++ b/doc/doc-support/lib-function-locations.nix
@ -1,24 +1,24 @@
-{ pkgs ? (import ./.. { }), nixpkgs ? { }}:
+{ pkgs, nixpkgs ? { }, libsets }:
 let
  revision = pkgs.lib.trivial.revisionWithDefault (nixpkgs.revision or "master");

-  libDefPos = set:
-    builtins.map
-      (name: {
-        name = name;
+  libDefPos = prefix: set:
+    builtins.concatMap
+      (name: [{
+        name = builtins.concatStringsSep "." (prefix ++ [name]);
        location = builtins.unsafeGetAttrPos name set;
-      })
-      (builtins.attrNames set);
+      }] ++ nixpkgsLib.optionals
+        (builtins.length prefix == 0 && builtins.isAttrs set.${name})
+        (libDefPos (prefix ++ [name]) set.${name})
+      ) (builtins.attrNames set);

  libset = toplib:
    builtins.map
      (subsetname: {
        subsetname = subsetname;
-        functions = libDefPos toplib.${subsetname};
+        functions = libDefPos [] toplib.${subsetname};
      })
-      (builtins.filter
-        (name: builtins.isAttrs toplib.${name})
-        (builtins.attrNames toplib));
+      (builtins.map (x: x.name) libsets);

  nixpkgsLib = pkgs.lib;

--- a/doc/doc-support/parameters.xml
+++ b/doc/doc-support/parameters.xml
@ -2,12 +2,16 @@
 <xsl:stylesheet
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    version="1.0">
- <xsl:param name="section.autolabel" select="1" />
- <xsl:param name="section.label.includes.component.label" select="1" />
+ <xsl:param name="chapter.autolabel" select="0" />
+ <xsl:param name="part.autolabel" select="0" />
+ <xsl:param name="preface.autolabel" select="0" />
+ <xsl:param name="reference.autolabel" select="0" />
+ <xsl:param name="section.autolabel" select="0" />
 <xsl:param name="html.stylesheet" select="'style.css overrides.css highlightjs/mono-blue.css'" />
 <xsl:param name="html.script" select="'./highlightjs/highlight.pack.js ./highlightjs/loader.js'" />
- <xsl:param name="xref.with.number.and.title" select="1" />
+ <xsl:param name="xref.with.number.and.title" select="0" />
 <xsl:param name="use.id.as.filename" select="1" />
+ <xsl:param name="generate.section.toc.level" select="1" />
 <xsl:param name="toc.section.depth" select="0" />
 <xsl:param name="admon.style" select="''" />
 <xsl:param name="callout.graphics.extension" select="'.svg'" />
--- a/doc/doc-support/xmlformat.conf
+++ b/doc/doc-support/xmlformat.conf
--- a/doc/functions/library.xml
+++ b/doc/functions/library.xml
@ -8,25 +8,7 @@
  Nixpkgs provides a standard library at <varname>pkgs.lib</varname>, or through <code>import &lt;nixpkgs/lib&gt;</code>.
 </para>

- <xi:include href="./library/asserts.xml" />
-
- <xi:include href="./library/attrsets.xml" />
-
-<!-- These docs are generated via nixdoc. To add another generated
-      library function file to this list, the file
-      `lib-function-docs.nix` must also be updated. -->
-
- <xi:include href="./library/generated/strings.xml" />
-
- <xi:include href="./library/generated/trivial.xml" />
-
- <xi:include href="./library/generated/lists.xml" />
-
- <xi:include href="./library/generated/debug.xml" />
-
- <xi:include href="./library/generated/options.xml" />
-
- <xi:include href="./library/generated/filesystem.xml" />
-
- <xi:include href="./library/generated/sources.xml" />
+ <!-- The index must have a root element to declare namespaces, but we
+      don't want to include it, so we select all of its children. -->
+ <xi:include href="./library/generated/index.xml" xpointer="xpointer(/root/*)" />
 </section>
--- a/doc/functions/library/.gitkeep
+++ b/doc/functions/library/.gitkeep
--- a/doc/functions/library/asserts.xml
+++ b/doc/functions/library/asserts.xml
@ -1,112 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xmlns:xi="http://www.w3.org/2001/XInclude"
-         xml:id="sec-functions-library-asserts">
- <title>Assert functions</title>
-
- <section xml:id="function-library-lib.asserts.assertMsg">
-  <title><function>lib.asserts.assertMsg</function></title>
-
-  <subtitle><literal>assertMsg :: Bool -> String -> Bool</literal>
-  </subtitle>
-
-  <xi:include href="./locations.xml" xpointer="lib.asserts.assertMsg" />
-
-  <para>
-   Print a trace message if <literal>pred</literal> is false.
-  </para>
-
-  <para>
-   Intended to be used to augment asserts with helpful error messages.
-  </para>
-
-  <variablelist>
-   <varlistentry>
-    <term>
-     <varname>pred</varname>
-    </term>
-    <listitem>
-     <para>
-      Condition under which the <varname>msg</varname> should <emphasis>not</emphasis> be printed.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <varname>msg</varname>
-    </term>
-    <listitem>
-     <para>
-      Message to print.
-     </para>
-    </listitem>
-   </varlistentry>
-  </variablelist>
-
-  <example xml:id="function-library-lib.asserts.assertMsg-example-false">
-   <title>Printing when the predicate is false</title>
-<programlisting><![CDATA[
-assert lib.asserts.assertMsg ("foo" == "bar") "foo is not bar, silly"
-stderr> trace: foo is not bar, silly
-stderr> assert failed
-]]></programlisting>
-  </example>
- </section>
-
- <section xml:id="function-library-lib.asserts.assertOneOf">
-  <title><function>lib.asserts.assertOneOf</function></title>
-
-  <subtitle><literal>assertOneOf :: String -> String ->
-      StringList -> Bool</literal>
-  </subtitle>
-
-  <xi:include href="./locations.xml" xpointer="lib.asserts.assertOneOf" />
-
-  <para>
-   Specialized <function>asserts.assertMsg</function> for checking if <varname>val</varname> is one of the elements of <varname>xs</varname>. Useful for checking enums.
-  </para>
-
-  <variablelist>
-   <varlistentry>
-    <term>
-     <varname>name</varname>
-    </term>
-    <listitem>
-     <para>
-      The name of the variable the user entered <varname>val</varname> into, for inclusion in the error message.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <varname>val</varname>
-    </term>
-    <listitem>
-     <para>
-      The value of what the user provided, to be compared against the values in <varname>xs</varname>.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry>
-    <term>
-     <varname>xs</varname>
-    </term>
-    <listitem>
-     <para>
-      The list of valid values.
-     </para>
-    </listitem>
-   </varlistentry>
-  </variablelist>
-
-  <example xml:id="function-library-lib.asserts.assertOneOf-example">
-   <title>Ensuring a user provided a possible value</title>
-<programlisting><![CDATA[
-let sslLibrary = "bearssl";
-in lib.asserts.assertOneOf "sslLibrary" sslLibrary [ "openssl" "libressl" ];
-=> false
-stderr> trace: sslLibrary must be one of "openssl", "libressl", but is: "bearssl"
-        ]]></programlisting>
-  </example>
- </section>
-</section>
--- a/doc/functions/library/attrsets.xml
+++ b/doc/functions/library/attrsets.xml
--- a/doc/functions/nix-gitignore.section.md
+++ b/doc/functions/nix-gitignore.section.md
@ -4,7 +4,7 @@

 ## Usage {#sec-pkgs-nix-gitignore-usage}

-`pkgs.nix-gitignore` exports a number of functions, but you\'ll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
+`pkgs.nix-gitignore` exports a number of functions, but you'll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.

 ```nix
 { pkgs ? import <nixpkgs> {} }:
@ -30,7 +30,7 @@ gitignoreSourcePure = gitignoreFilterSourcePure (_: _: true);
 gitignoreSource = gitignoreFilterSource (_: _: true);
 ```

-Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it\'s blacklisted by either your filter or the gitignoreFilter.
+Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it's blacklisted by either your filter or the gitignoreFilter.

 If you want to make your own filter from scratch, you may use

--- a/doc/hooks/breakpoint.section.md
+++ b/doc/hooks/breakpoint.section.md
@ -10,9 +10,7 @@ nativeBuildInputs = [ breakpointHook ];
 When a build failure happens there will be an instruction printed that shows how to attach with `cntr` to the build sandbox.

 ::: {.note}
-::: {.title}
 Caution with remote builds
-:::

 This won’t work with remote builds as the build environment is on a different machine and can’t be accessed by `cntr`. Remote builds can be turned off by setting `--option builders ''` for `nix-build` or `--builders ''` for `nix build`.
 :::
--- a/doc/hooks/postgresql-test-hook.section.md
+++ b/doc/hooks/postgresql-test-hook.section.md
@ -9,7 +9,7 @@ stdenv.mkDerivation {

  # ...

-  checkInputs = [
+  nativeCheckInputs = [
    postgresql
    postgresqlTestHook
  ];
@ -46,6 +46,12 @@ Bash-only variables:
 - `postgresqlEnableTCP`: set to `1` to enable TCP listening. Flaky; not recommended.
 - `postgresqlStartCommands`: defaults to `pg_ctl start`.

+## Hooks {#sec-postgresqlTestHook-hooks}
+
+A number of additional hooks are ran in postgresqlTestHook
+
+ - `postgresqlTestSetupPost`: ran after postgresql has been set up.
+
 ## TCP and the Nix sandbox {#sec-postgresqlTestHook-tcp}

 `postgresqlEnableTCP` relies on network sandboxing, which is not available on macOS and some custom Nix installations, resulting in flaky tests.
--- a/doc/languages-frameworks/agda.section.md
+++ b/doc/languages-frameworks/agda.section.md
@ -52,7 +52,7 @@ agda.withPackages (p: [
      repo = "agda-stdlib";
      owner = "agda";
      rev = "v1.5";
-      sha256 = "16fcb7ssj6kj687a042afaa2gq48rc8abihpm14k684ncihb2k4w";
+      hash = "sha256-nEyxYGSWIDNJqBfGpRDLiOAnlHJKEKAOMnIaqfVZzJk=";
    };
  }))
 ])
@ -83,7 +83,7 @@ agda.withPackages (p: [
      owner = "owner";
      version = "...";
      rev = "...";
-      sha256 = "...";
+      hash = "...";
    };
  })
 ])
--- a/doc/languages-frameworks/android.section.md
+++ b/doc/languages-frameworks/android.section.md
@ -13,6 +13,7 @@ with import <nixpkgs> {};

 let
  androidComposition = androidenv.composeAndroidPackages {
+    cmdLineToolsVersion = "8.0";
    toolsVersion = "26.1.1";
    platformToolsVersion = "30.0.5";
    buildToolsVersions = [ "30.0.3" ];
@ -42,7 +43,10 @@ exceptions are the tools, platform-tools and build-tools sub packages.

 The following parameters are supported:

-* `toolsVersion`, specifies the version of the tools package to use
+* `cmdLineToolsVersion `, specifies the version of the `cmdline-tools` package to use
+* `toolsVersion`, specifies the version of the `tools` package. Notice `tools` is
+  obsolete, and currently only `26.1.1` is available, so there's not a lot of
+  options here, however, you can set it as `null` if you don't want it.
 * `platformsToolsVersion` specifies the version of the `platform-tools` plugin
 * `buildToolsVersions` specifies the versions of the `build-tools` plugins to
  use.
@ -232,7 +236,6 @@ androidenv.emulateApp {
  platformVersion = "24";
  abiVersion = "armeabi-v7a"; # mips, x86, x86_64
  systemImageType = "default";
-  useGoogleAPIs = false;
  app = ./MyApp.apk;
  package = "MyApp";
  activity = "MainActivity";
--- a/doc/languages-frameworks/beam.section.md
+++ b/doc/languages-frameworks/beam.section.md
@ -93,7 +93,7 @@ Practical steps:
 - run `mix2nix > mix_deps.nix` in the upstream repo.
 - pass `mixNixDeps = with pkgs; import ./mix_deps.nix { inherit lib beamPackages; };` as an argument to mixRelease.

-If there are git depencencies.
+If there are git dependencies.

 - You'll need to fix the version artificially in mix.exs and regenerate the mix.lock with fixed version (on upstream). This will enable you to run `mix2nix > mix_deps.nix`.
 - From the mix_deps.nix file, remove the dependencies that had git versions and pass them as an override to the import function.
@ -115,7 +115,7 @@ If there are git depencencies.
          owner = "elixir-libraries";
          repo = "prometheus.ex";
          rev = "a4e9beb3c1c479d14b352fd9d6dd7b1f6d7deee5";
-          sha256 = "1v0q4bi7sb253i8q016l7gwlv5562wk5zy3l2sa446csvsacnpjk";
+          hash = "sha256-U17LlN6aGUKUFnT4XyYXppRN+TvUBIBRHEUsfeIiGOw=";
        };
        # you can re-use the same beamDeps argument as generated
        beamDeps = with final; [ prometheus ];
@ -124,11 +124,11 @@ If there are git depencencies.
 };
 ```

-You will need to run the build process once to fix the sha256 to correspond to your new git src.
+You will need to run the build process once to fix the hash to correspond to your new git src.

 ###### FOD {#fixed-output-derivation}

-A fixed output derivation will download mix dependencies from the internet. To ensure reproducibility, a hash will be supplied. Note that mix is relatively reproducible. An FOD generating a different hash on each run hasn't been observed (as opposed to npm where the chances are relatively high). See [elixir_ls](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/beam-modules/elixir_ls.nix) for a usage example of FOD.
+A fixed output derivation will download mix dependencies from the internet. To ensure reproducibility, a hash will be supplied. Note that mix is relatively reproducible. An FOD generating a different hash on each run hasn't been observed (as opposed to npm where the chances are relatively high). See [elixir_ls](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/beam-modules/elixir-ls/default.nix) for a usage example of FOD.

 Practical steps

@ -138,13 +138,13 @@ Practical steps
  mixFodDeps = fetchMixDeps {
    pname = "mix-deps-${pname}";
    inherit src version;
-    sha256 = lib.fakeSha256;
+    hash = lib.fakeHash;
  };
 ```

-The first build will complain about the sha256 value, you can replace with the suggested value after that.
+The first build will complain about the hash value, you can replace with the suggested value after that.

-Note that if after you've replaced the value, nix suggests another sha256, then mix is not fetching the dependencies reproducibly. An FOD will not work in that case and you will have to use mix2nix.
+Note that if after you've replaced the value, nix suggests another hash, then mix is not fetching the dependencies reproducibly. An FOD will not work in that case and you will have to use mix2nix.

 ##### mixRelease - example {#mix-release-example}

@ -170,7 +170,8 @@ let
    pname = "mix-deps-${pname}";
    inherit src version;
    # nix will complain and tell you the right value to replace this with
-    sha256 = lib.fakeSha256;
+    hash = lib.fakeHash;
+    mixEnv = ""; # default is "prod", when empty includes all dependencies, such as "dev", "test".
    # if you have build time environment variables add them here
    MY_ENV_VAR="my_value";
  };
@ -282,7 +283,7 @@ mkShell {

 ### Using an overlay

-If you need to use an overlay to change some attributes of a derivation, e.g. if you need a bugfix from a version that is not yet available in nixpkgs, you can override attributes such as `version` (and the corresponding `sha256`) and then use this overlay in your development environment:
+If you need to use an overlay to change some attributes of a derivation, e.g. if you need a bugfix from a version that is not yet available in nixpkgs, you can override attributes such as `version` (and the corresponding `hash`) and then use this overlay in your development environment:

 #### `shell.nix`

@ -291,7 +292,7 @@ let
  elixir_1_13_1_overlay = (self: super: {
      elixir_1_13 = super.elixir_1_13.override {
        version = "1.13.1";
-        sha256 = "0z0b1w2vvw4vsnb99779c2jgn9bgslg7b1pmd9vlbv02nza9qj5p";
+        sha256 = "sha256-t0ic1LcC7EV3avWGdR7VbyX7pGDpnJSW1ZvwvQUPC3w=";
      };
    });
  pkgs = import <nixpkgs> { overlays = [ elixir_1_13_1_overlay ]; };
--- a/doc/languages-frameworks/coq.section.md
+++ b/doc/languages-frameworks/coq.section.md
@ -8,7 +8,7 @@ The Coq derivation is overridable through the `coq.override overrides`, where ov
 * `customOCamlPackages` (optional, defaults to `null`, which lets Coq choose a version automatically), which can be set to any of the ocaml packages attribute of `ocaml-ng` (such as `ocaml-ng.ocamlPackages_4_10` which is the default for Coq 8.11 for example).
 * `coq-version` (optional, defaults to the short version e.g. "8.10"), is a version number of the form "x.y" that indicates which Coq's version build behavior to mimic when using a source which is not a release. E.g. `coq.override { version = "d370a9d1328a4e1cdb9d02ee032f605a9d94ec7a"; coq-version = "8.10"; }`.

-The associated package set can be optained using `mkCoqPackages coq`, where `coq` is the derivation to use.
+The associated package set can be obtained using `mkCoqPackages coq`, where `coq` is the derivation to use.

 ## Coq packages attribute sets: `coqPackages` {#coq-packages-attribute-sets-coqpackages}

@ -24,7 +24,7 @@ The recommended way of defining a derivation for a Coq library, is to use the `c
  * if it is a string of the form `"#N"`, and the domain is github, then it tries to download the current head of the pull request `#N` from github,
 * `defaultVersion` (optional). Coq libraries may be compatible with some specific versions of Coq only. The `defaultVersion` attribute is used when no `version` is provided (or if `version = null`) to select the version of the library to use by default, depending on the context. This selection will mainly depend on a `coq` version number but also possibly on other packages versions (e.g. `mathcomp`). If its value ends up to be `null`, the package is marked for removal in end-user `coqPackages` attribute set.
 * `release` (optional, defaults to `{}`), lists all the known releases of the library and for each of them provides an attribute set with at least a `sha256` attribute (you may put the empty string `""` in order to automatically insert a fake sha256, this will trigger an error which will allow you to find the correct sha256), each attribute set of the list of releases also takes optional overloading arguments for the fetcher as below (i.e.`domain`, `owner`, `repo`, `rev` assuming the default fetcher is used) and optional overrides for the result of the fetcher (i.e. `version` and `src`).
-* `fetcher` (optional, defaults to a generic fetching mechanism supporting github or gitlab based infrastructures), is a function that takes at least an `owner`, a `repo`, a `rev`, and a `sha256` and returns an attribute set with a `version` and `src`.
+* `fetcher` (optional, defaults to a generic fetching mechanism supporting github or gitlab based infrastructures), is a function that takes at least an `owner`, a `repo`, a `rev`, and a `hash` and returns an attribute set with a `version` and `src`.
 * `repo` (optional, defaults to the value of `pname`),
 * `owner` (optional, defaults to `"coq-community"`).
 * `domain` (optional, defaults to `"github.com"`), domains including the strings `"github"` or `"gitlab"` in their names are automatically supported, otherwise, one must change the `fetcher` argument to support them (cf `pkgs/development/coq-modules/heq/default.nix` for an example),
--- a/doc/languages-frameworks/crystal.section.md
+++ b/doc/languages-frameworks/crystal.section.md
@ -27,7 +27,7 @@ crystal.buildCrystalPackage rec {
    owner = "mint-lang";
    repo = "mint";
    rev = version;
-    sha256 = "0vxbx38c390rd2ysvbwgh89v2232sh5rbsp3nk9wzb70jybpslvl";
+    hash = "sha256-dFN9l5fgrM/TtOPqlQvUYgixE4KPr629aBmkwdDoq28=";
  };

  # Insert the path to your shards.nix file here
@ -62,7 +62,7 @@ crystal.buildCrystalPackage rec {
    owner = "mint-lang";
    repo = "mint";
    rev = version;
-    sha256 = "0vxbx38c390rd2ysvbwgh89v2232sh5rbsp3nk9wzb70jybpslvl";
+    hash = "sha256-dFN9l5fgrM/TtOPqlQvUYgixE4KPr629aBmkwdDoq28=";
  };

  shardsFile = ./shards.nix;
--- a/doc/languages-frameworks/cuda.section.md
+++ b/doc/languages-frameworks/cuda.section.md
@ -32,3 +32,22 @@ mypkg = let
  }});
 in callPackage { inherit cudaPackages; };
 ```
+
+The CUDA NVCC compiler requires flags to determine which hardware you
+want to target for in terms of SASS (real hardware) or PTX (JIT kernels).
+
+Nixpkgs tries to target support real architecture defaults based on the
+CUDA toolkit version with PTX support for future hardware.  Experienced
+users may optimize this configuration for a variety of reasons such as
+reducing binary size and compile time, supporting legacy hardware, or
+optimizing for specific hardware.
+
+You may provide capabilities to add support or reduce binary size through
+`config` using `cudaCapabilities = [ "6.0" "7.0" ];` and
+`cudaForwardCompat = true;` if you want PTX support for future hardware.
+
+Please consult [GPUs supported](https://en.wikipedia.org/wiki/CUDA#GPUs_supported)
+for your specific card(s).
+
+Library maintainers should consult [NVCC Docs](https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/)
+and release notes for their software package.
--- a/doc/languages-frameworks/cuelang.section.md
+++ b/doc/languages-frameworks/cuelang.section.md
@ -0,0 +1,93 @@
+# Cue (Cuelang) {#cuelang}
+
+[Cuelang](https://cuelang.org/) is a language to:
+
+- describe schemas and validate backward-compatibility
+- generate code and schemas in various formats (e.g. JSON Schema, OpenAPI)
+- do configuration akin to [Dhall Lang](https://dhall-lang.org/)
+- perform data validation
+
+## Cuelang schema quick start
+
+Cuelang schemas are similar to JSON, here is a quick cheatsheet:
+
+- Default types includes: `null`, `string`, `bool`, `bytes`, `number`, `int`, `float`, lists as `[...T]` where `T` is a type.
+- All structures, defined by: `myStructName: { <fields> }` are **open** -- they accept fields which are not specified.
+- Closed structures can be built by doing `myStructName: close({ <fields> })` -- they are strict in what they accept.
+- `#X` are **definitions**, referenced definitions are **recursively closed**, i.e. all its children structures are **closed**.
+- `&` operator is the [unification operator](https://cuelang.org/docs/references/spec/#unification) (similar to a type-level merging operator), `|` is the [disjunction operator](https://cuelang.org/docs/references/spec/#disjunction) (similar to a type-level union operator).
+- Values **are** types, i.e. `myStruct: { a: 3 }` is a valid type definition that only allows `3` as value.
+
+- Read <https://cuelang.org/docs/concepts/logic/> to learn more about the semantics.
+- Read <https://cuelang.org/docs/references/spec/> to learn about the language specification.
+
+## `writeCueValidator`
+
+Nixpkgs provides a `pkgs.writeCueValidator` helper, which will write a validation script based on the provided Cuelang schema.
+
+Here is an example:
+```
+pkgs.writeCueValidator
+  (pkgs.writeText "schema.cue" ''
+    #Def1: {
+      field1: string
+    }
+  '')
+  { document = "#Def1"; }
+```
+
+- The first parameter is the Cue schema file.
+- The second parameter is an options parameter, currently, only: `document` can be passed.
+
+`document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but different documents based on the data you are validating.
+
+Another example, given the following `validator.nix` :
+```
+{ pkgs ? import <nixpkgs> {} }:
+let
+  genericValidator = version:
+  pkgs.writeCueValidator
+    (pkgs.writeText "schema.cue" ''
+      #Version1: {
+        field1: string
+      }
+      #Version2: #Version1 & {
+        field1: "unused"
+      }''
+    )
+    { document = "#Version${toString version}"; };
+in
+{
+  validateV1 = genericValidator 1;
+  validateV2 = genericValidator 2;
+}
+```
+
+The result is a script that will validate the file you pass as the first argument against the schema you provided `writeCueValidator`.
+
+It can be any format that `cue vet` supports, i.e. YAML or JSON for example.
+
+Here is an example, named `example.json`, given the following JSON:
+```
+{ "field1": "abc" }
+```
+
+You can run the result script (named `validate`) as the following:
+
+```console
+$ nix-build validator.nix
+$ ./result example.json
+$ ./result-2 example.json
+field1: conflicting values "unused" and "abc":
+    ./example.json:1:13
+    ../../../../../../nix/store/v64dzx3vr3glpk0cq4hzmh450lrwh6sg-schema.cue:5:11
+$ sed -i 's/"abc"/3/' example.json
+$ ./result example.json
+field1: conflicting values 3 and string (mismatched types int and string):
+    ./example.json:1:13
+    ../../../../../../nix/store/v64dzx3vr3glpk0cq4hzmh450lrwh6sg-schema.cue:5:11
+```
+
+**Known limitations**
+
+* The script will enforce **concrete** values and will not accept lossy transformations (strictness). You can add these options if you need them.
--- a/doc/languages-frameworks/dhall.section.md
+++ b/doc/languages-frameworks/dhall.section.md
@ -91,7 +91,7 @@ buildDhallPackage {
 let
  nixpkgs = builtins.fetchTarball {
    url    = "https://github.com/NixOS/nixpkgs/archive/94b2848559b12a8ed1fe433084686b2a81123c99.tar.gz";
-    sha256 = "1pbl4c2dsaz2lximgd31m96jwbps6apn3anx8cvvhk1gl9rkg107";
+    sha256 = "sha256-B4Q3c6IvTLg3Q92qYa8y+i4uTaphtFdjp+Ir3QQjdN0=";
  };

  dhallOverlay = self: super: {
@ -295,7 +295,7 @@ terms of `buildDhallPackage` that accepts the following arguments:
 * `document`: Set to `true` to generate documentation for the package

 Additionally, `buildDhallGitHubPackage` accepts the same arguments as
-`fetchFromGitHub`, such as `sha256` or `fetchSubmodules`.
+`fetchFromGitHub`, such as `hash` or `fetchSubmodules`.

 ## `dhall-to-nixpkgs` {#ssec-dhall-dhall-to-nixpkgs}

@ -316,7 +316,7 @@ $ dhall-to-nixpkgs github https://github.com/Gabriel439/dhall-semver.git
    repo = "dhall-semver";
    rev = "2d44ae605302ce5dc6c657a1216887fbb96392a4";
    fetchSubmodules = false;
-    sha256 = "0y8shvp8srzbjjpmnsvz9c12ciihnx1szs0yzyi9ashmrjvd0jcz";
+    hash = "sha256-n0nQtswVapWi/x7or0O3MEYmAkt/a1uvlOtnje6GGnk=";
    directory = "";
    file = "package.dhall";
    source = false;
--- a/doc/languages-frameworks/dotnet.section.md
+++ b/doc/languages-frameworks/dotnet.section.md
@ -28,13 +28,13 @@ mkShell {
  packages = [
    (with dotnetCorePackages; combinePackages [
      sdk_3_1
-      sdk_5_0
+      sdk_6_0
    ])
  ];
 }
 ```

-This will produce a dotnet installation that has the dotnet 3.1, 3.0, and 2.1 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output:
+This will produce a dotnet installation that has the dotnet 3.1 6.0 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output:

 ```ShellSession
 $ dotnet --info
@ -120,8 +120,7 @@ in buildDotnetModule rec {
  projectReferences = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure.

  dotnet-sdk = dotnetCorePackages.sdk_3_1;
-  dotnet-runtime = dotnetCorePackages.net_5_0;
-  dotnetFlags = [ "--runtime linux-x64" ];
+  dotnet-runtime = dotnetCorePackages.net_6_0;

  executables = [ "foo" ]; # This wraps "$out/lib/$pname/foo" to `$out/bin/foo`.
  executables = []; # Don't install any executables.
--- a/doc/languages-frameworks/emscripten.section.md
+++ b/doc/languages-frameworks/emscripten.section.md
@ -56,11 +56,11 @@ See the `zlib` example:

    zlib = (pkgs.zlib.override {
      stdenv = pkgs.emscriptenStdenv;
-    }).overrideDerivation
+    }).overrideAttrs
    (old: rec {
      buildInputs = old.buildInputs ++ [ pkg-config ];
      # we need to reset this setting!
-      NIX_CFLAGS_COMPILE="";
+      env = (old.env or { }) // { NIX_CFLAGS_COMPILE = ""; };
      configurePhase = ''
        # FIXME: Some tests require writing at $HOME
        HOME=$TMPDIR
@ -121,7 +121,7 @@ This `xmlmirror` example features a emscriptenPackage which is defined completel
      src = pkgs.fetchgit {
        url = "https://gitlab.com/odfplugfest/xmlmirror.git";
        rev = "4fd7e86f7c9526b8f4c1733e5c8b45175860a8fd";
-        sha256 = "1jasdqnbdnb83wbcnyrp32f36w3xwhwp0wq8lwwmhqagxrij1r4b";
+        hash = "sha256-i+QgY+5PYVg5pwhzcDnkfXAznBg3e8sWH2jZtixuWsk=";
      };

      configurePhase = ''
--- a/doc/languages-frameworks/gnome.section.md
+++ b/doc/languages-frameworks/gnome.section.md
@ -34,7 +34,7 @@ To allow software to use various virtual file systems, `gvfs` package can be als

 ### GdkPixbuf loaders {#ssec-gnome-gdk-pixbuf-loaders}

-GTK applications typically use [GdkPixbuf](https://developer.gnome.org/gdk-pixbuf/stable/) to load images. But `gdk-pixbuf` package only supports basic bitmap formats like JPEG, PNG or TIFF, requiring to use third-party loader modules for other formats. This is especially painful since GTK itself includes SVG icons, which cannot be rendered without a loader provided by `librsvg`.
+GTK applications typically use [GdkPixbuf](https://gitlab.gnome.org/GNOME/gdk-pixbuf/) to load images. But `gdk-pixbuf` package only supports basic bitmap formats like JPEG, PNG or TIFF, requiring to use third-party loader modules for other formats. This is especially painful since GTK itself includes SVG icons, which cannot be rendered without a loader provided by `librsvg`.

 Unlike other libraries mentioned in this section, GdkPixbuf only supports a single value in its controlling environment variable `GDK_PIXBUF_MODULE_FILE`. It is supposed to point to a cache file containing information about the available loaders. Each loader package will contain a `lib/gdk-pixbuf-2.0/2.10.0/loaders.cache` file describing the default loaders in `gdk-pixbuf` package plus the loader contained in the package itself. If you want to use multiple third-party loaders, you will need to create your own cache file manually. Fortunately, this is pretty rare as [not many loaders exist](https://gitlab.gnome.org/federico/gdk-pixbuf-survey/blob/master/src/modules.md).

@ -70,7 +70,7 @@ Also make sure that `icon-theme.cache` is installed for each theme provided by t

 ### GTK Themes {#ssec-gnome-themes}

-Previously, a GTK theme needed to be in `XDG_DATA_DIRS`. This is no longer necessary for most programs since GTK incorporated Adwaita theme. Some programs (for example, those designed for [elementary HIG](https://elementary.io/docs/human-interface-guidelines#human-interface-guidelines)) might require a special theme like `pantheon.elementary-gtk-theme`.
+Previously, a GTK theme needed to be in `XDG_DATA_DIRS`. This is no longer necessary for most programs since GTK incorporated Adwaita theme. Some programs (for example, those designed for [elementary HIG](https://docs.elementary.io/hig)) might require a special theme like `pantheon.elementary-gtk-theme`.

 ### GObject introspection typelibs {#ssec-gnome-typelibs}

--- a/doc/languages-frameworks/go.section.md
+++ b/doc/languages-frameworks/go.section.md
@ -11,7 +11,14 @@ The function `buildGoModule` builds Go programs managed with Go modules. It buil

 In the following is an example expression using `buildGoModule`, the following arguments are of special significance to the function:

- `vendorHash`: is the hash of the output of the intermediate fetcher derivation. `vendorHash` can also take `null` as an input. When `null` is used as a value, rather than fetching the dependencies and vendoring them, we use the vendoring included within the source repo. If you'd like to not have to update this field on dependency changes, run `go mod vendor` in your source repo and set `vendorHash = null;`
+- `vendorHash`: is the hash of the output of the intermediate fetcher derivation.
+
+  `vendorHash` can also be set to `null`.
+  In that case, rather than fetching the dependencies and vendoring them, the dependencies vendored in the source repo will be used.
+
+  To avoid updating this field when dependencies change, run `go mod vendor` in your source repo and set `vendorHash = null;`
+
+  To obtain the actual hash, set `vendorHash = lib.fakeSha256;` and run the build ([more details here](#sec-source-hashes)).
 - `proxyVendor`: Fetches (go mod download) and proxies the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build or if any dependency has case-insensitive conflicts which will produce platform dependant `vendorHash` checksums.

 ```nix
@ -23,7 +30,7 @@ pet = buildGoModule rec {
    owner = "knqyf263";
    repo = "pet";
    rev = "v${version}";
-    sha256 = "0m2fzpqxk7hrbxsgqplkg7h2p7gv6s1miymv3gvw0cz039skag0s";
+    hash = "sha256-Gjw1dRrgM8D3G7v6WIM2+50r4HmTXvx0Xxme2fH9TlQ=";
  };

  vendorHash = "sha256-ciBIR+a1oaYH+H1PcC8cD8ncfJczk1IiJ8iYNM+R6aA=";
@ -59,7 +66,7 @@ deis = buildGoPackage rec {
    owner = "deis";
    repo = "deis";
    rev = "v${version}";
-    sha256 = "1qv9lxqx7m18029lj8cw3k7jngvxs4iciwrypdy0gd2nnghc68sw";
+    hash = "sha256-XCPD4LNWtAd8uz7zyCLRfT8rzxycIUmTACjU03GnaeM=";
  };

  goDeps = ./deps.nix;
@ -76,11 +83,11 @@ The `goDeps` attribute can be imported from a separate `nix` file that defines w
    goPackagePath = "gopkg.in/yaml.v2";
    fetch = {
      # `fetch type` that needs to be used to get package source.
-      # If `git` is used there should be `url`, `rev` and `sha256` defined next to it.
+      # If `git` is used there should be `url`, `rev` and `hash` defined next to it.
      type = "git";
      url = "https://gopkg.in/yaml.v2";
      rev = "a83829b6f1293c91addabc89d0571c246397bbf4";
-      sha256 = "1m4dsmk90sbi17571h6pld44zxz7jc4lrnl4f27dpd1l8g5xvjhh";
+      hash = "sha256-EMrdy0M0tNuOcITaTAmT5/dPSKPXwHDKCXFpkGbVjdQ=";
    };
  }
  {
@ -89,7 +96,7 @@ The `goDeps` attribute can be imported from a separate `nix` file that defines w
      type = "git";
      url = "https://github.com/docopt/docopt-go";
      rev = "784ddc588536785e7299f7272f39101f7faccc3f";
-      sha256 = "0wwz48jl9fvl1iknvn9dqr4gfy1qs03gxaikrxxp9gry6773v3sj";
+      hash = "sha256-Uo89zjE+v3R7zzOq/gbQOHj3SMYt2W1nDHS7RCUin3M=";
    };
  }
 ]
--- a/doc/languages-frameworks/haskell.section.md
+++ b/doc/languages-frameworks/haskell.section.md
--- a/doc/languages-frameworks/hy.section.md
+++ b/doc/languages-frameworks/hy.section.md
@ -4,10 +4,10 @@

 ### Installation without packages {#installation-without-packages}

-You can install `hy` via nix-env or by adding it to `configuration.nix` by reffering to it as a `hy` attribute. This kind of installation adds `hy` to your environment and it succesfully works with `python3`.
+You can install `hy` via nix-env or by adding it to `configuration.nix` by referring to it as a `hy` attribute. This kind of installation adds `hy` to your environment and it successfully works with `python3`.

 ::: {.caution}
-Packages that are installed with your python derivation, are not accesible by `hy` this way.
+Packages that are installed with your python derivation, are not accessible by `hy` this way.
 :::

 ### Installation with packages {#installation-with-packages}
--- a/doc/languages-frameworks/idris.section.md
+++ b/doc/languages-frameworks/idris.section.md
@ -90,7 +90,7 @@ build-idris-package  {
    owner = "Heather";
    repo = "Idris.Yaml";
    rev = "5afa51ffc839844862b8316faba3bafa15656db4";
-    sha256 = "1g4pi0swmg214kndj85hj50ccmckni7piprsxfdzdfhg87s0avw7";
+    hash = "sha256-h28F9EEPuvab6zrfeE+0k1XGQJGwINnsJEG8yjWIl7w=";
  };

  meta = with lib; {
--- a/doc/languages-frameworks/index.xml
+++ b/doc/languages-frameworks/index.xml
@ -3,7 +3,7 @@
         xml:id="chap-language-support">
 <title>Languages and frameworks</title>
 <para>
-  The <link linkend="chap-stdenv">standard build environment</link> makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accomodated by overriding the appropriate phases of <literal>stdenv</literal>. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
+  The <link linkend="chap-stdenv">standard build environment</link> makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accommodated by overriding the appropriate phases of <literal>stdenv</literal>. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
 </para>
 <xi:include href="agda.section.xml" />
 <xi:include href="android.section.xml" />
@ -13,6 +13,7 @@
 <xi:include href="coq.section.xml" />
 <xi:include href="crystal.section.xml" />
 <xi:include href="cuda.section.xml" />
+ <xi:include href="cuelang.section.xml" />
 <xi:include href="dhall.section.xml" />
 <xi:include href="dotnet.section.xml" />
 <xi:include href="emscripten.section.xml" />
@ -31,11 +32,13 @@
 <xi:include href="octave.section.xml" />
 <xi:include href="perl.section.xml" />
 <xi:include href="php.section.xml" />
+ <xi:include href="pkg-config.section.xml" />
 <xi:include href="python.section.xml" />
 <xi:include href="qt.section.xml" />
 <xi:include href="r.section.xml" />
 <xi:include href="ruby.section.xml" />
 <xi:include href="rust.section.xml" />
+ <xi:include href="swift.section.xml" />
 <xi:include href="texlive.section.xml" />
 <xi:include href="titanium.section.xml" />
 <xi:include href="vim.section.xml" />
--- a/doc/languages-frameworks/javascript.section.md
+++ b/doc/languages-frameworks/javascript.section.md
@ -175,9 +175,10 @@ buildNpmPackage rec {
    hash = "sha256-BR+ZGkBBfd0dSQqAvujsbgsEPFYw/ThrylxUbOksYxM=";
  };

-  patches = [ ./remove-prepack-script.patch ];
+  npmDepsHash = "sha256-tuEfyePwlOy2/mOPdXbqJskO6IowvAP4DWg8xSZwbJw=";

-  npmDepsHash = "sha256-s8SpZY/1tKZVd3vt7sA9vsqHvEaNORQBMrSyhWpj048=";
+  # The prepack script runs the build script, which we'd rather do in the build phase.
+  npmPackFlags = [ "--ignore-scripts" ];

  NODE_OPTIONS = "--openssl-legacy-provider";

@ -242,7 +243,7 @@ If the downloaded files contain the `package.json` and `yarn.lock` files they ca
 ```nix
 offlineCache = fetchYarnDeps {
  yarnLock = src + "/yarn.lock";
-  sha256 = "....";
+  hash = "....";
 };
 ```

@ -330,13 +331,16 @@ mkYarnPackage rec {
  - The `echo 9` steps comes from this answer: <https://stackoverflow.com/a/49139496>
  - Exporting the headers in `npm_config_nodedir` comes from this issue: <https://github.com/nodejs/node-gyp/issues/1191#issuecomment-301243919>

-## Outside of nixpkgs {#javascript-outside-nixpkgs}
+## Outside Nixpkgs {#javascript-outside-nixpkgs}

-There are some other options available that can't be used inside nixpkgs. Those other options are written in Nix. Importing them in nixpkgs will require moving the source code into nixpkgs. Using [Import From Derivation](https://nixos.wiki/wiki/Import_From_Derivation) is not allowed in Hydra at present. If you are packaging something outside nixpkgs, those can be considered
+There are some other tools available, which are written in the Nix language.
+These that can't be used inside Nixpkgs because they require [Import From Derivation](#ssec-import-from-derivation), which is not allowed in Nixpkgs.
+
+If you are packaging something outside Nixpkgs, consider the following:

 ### npmlock2nix {#javascript-npmlock2nix}

-[npmlock2nix](https://github.com/nix-community/npmlock2nix) aims at building node_modules without code generation. It hasn't reached v1 yet, the API might be subject to change.
+[npmlock2nix](https://github.com/nix-community/npmlock2nix) aims at building `node_modules` without code generation. It hasn't reached v1 yet, the API might be subject to change.

 #### Pitfalls {#javascript-npmlock2nix-pitfalls}

@ -344,7 +348,7 @@ There are some [problems with npm v7](https://github.com/tweag/npmlock2nix/issue

 ### nix-npm-buildpackage {#javascript-nix-npm-buildpackage}

-[nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage) aims at building node_modules without code generation. It hasn't reached v1 yet, the API might change. It supports both package-lock.json and yarn.lock.
+[nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage) aims at building `node_modules` without code generation. It hasn't reached v1 yet, the API might change. It supports both `package-lock.json` and yarn.lock.

 #### Pitfalls {#javascript-nix-npm-buildpackage-pitfalls}

--- a/doc/languages-frameworks/lua.section.md
+++ b/doc/languages-frameworks/lua.section.md
@ -183,7 +183,7 @@ luaposix = buildLuarocksPackage {

  src = fetchurl {
    url    = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
-    sha256 = "0yrm5cn2iyd0zjd4liyj27srphvy0gjrjx572swar6zqr4dwjqp2";
+    hash = "sha256-4mLJG8n4m6y4Fqd0meUDfsOb9RHSR0qa/KD5KCwrNXs=";
  };
  disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
  propagatedBuildInputs = [ bit32 lua std_normalize ];
--- a/doc/languages-frameworks/nim.section.md
+++ b/doc/languages-frameworks/nim.section.md
@ -25,7 +25,7 @@ nimPackages.buildNimPackage rec {

  src = fetchurl {
    url = "https://git.sr.ht/~ehmry/hottext/archive/v${version}.tar.gz";
-    sha256 = "sha256-hIUofi81zowSMbt1lUsxCnVzfJGN3FEiTtN8CEFpwzY=";
+    hash = "sha256-hIUofi81zowSMbt1lUsxCnVzfJGN3FEiTtN8CEFpwzY=";
  };

  buildInputs = with nimPackages; [
@ -65,7 +65,7 @@ buildNimPackage rec {
  version = "2.0.4";
  src = fetchNimble {
    inherit pname version;
-    hash = "sha256-Vtcj8goI4zZPQs2TbFoBFlcR5UqDtOldaXSH/+/xULk=";
+    hash = "sha256-qDtVSnf+7rTq36WAxgsUZ8XoUk4sKwHyt8EJcY5WP+o=";
  };
  propagatedBuildInputs = [ SDL2 ];
 }
--- a/doc/languages-frameworks/ocaml.section.md
+++ b/doc/languages-frameworks/ocaml.section.md
@ -79,7 +79,7 @@ buildDunePackage rec {
    owner  = "inhabitedtype";
    repo   = pname;
    rev    = version;
-    sha256 = "1hmrkdcdlkwy7rxhngf3cv3sa61cznnd9p5lmqhx20664gx2ibrh";
+    hash   = "sha256-MK8o+iPGANEhrrTc1Kz9LBilx2bDPQt7Pp5P2libucI=";
  };

  checkInputs = [ alcotest ppx_let ];
@ -110,7 +110,7 @@ buildDunePackage rec {

  src = fetchurl {
    url = "https://github.com/flowtype/ocaml-${pname}/releases/download/v${version}/${pname}-v${version}.tbz";
-    sha256 = "09ygcxxd5warkdzz17rgpidrd0pg14cy2svvnvy1hna080lzg7vp";
+    hash = "sha256-d5/3KUBAWRj8tntr4RkJ74KWW7wvn/B/m1nx0npnzyc=";
  };

  meta = with lib; {
@ -129,3 +129,8 @@ packaged libraries may still use the old spelling: maintainers are invited to
 fix this when updating packages. Massive renaming is strongly discouraged as it
 would be challenging to review, difficult to test, and will cause unnecessary
 rebuild.
+
+The build will automatically fail if two distinct versions of the same library
+are added to `buildInputs` (which usually happens transitively because of
+`propagatedBuildInputs`). Set `dontDetectOcamlConflicts` to true to disable this
+behavior.
--- a/doc/languages-frameworks/perl.section.md
+++ b/doc/languages-frameworks/perl.section.md
@ -39,7 +39,7 @@ ClassC3 = buildPerlPackage rec {
  version = "0.21";
  src = fetchurl {
    url = "mirror://cpan/authors/id/F/FL/FLORA/${pname}-${version}.tar.gz";
-    sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
+    hash = "sha256-/5GE5xHT0uYGOQxroqj6LMU7CtKn2s6vMVoSXxL4iK4=";
  };
 };
 ```
@ -78,7 +78,7 @@ buildPerlPackage rec {

  src = fetchurl {
    url = "mirror://cpan/authors/id/P/PM/PMQS/${pname}-${version}.tar.gz";
-    sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
+    hash = "sha256-4Y+HGgGQqcOfdiKcFIyMrWBEccVNVAMDBWZlFTMorh8=";
  };

  preConfigure = ''
@ -96,7 +96,7 @@ ClassC3Componentised = buildPerlPackage rec {
  version = "1.0004";
  src = fetchurl {
    url = "mirror://cpan/authors/id/A/AS/ASH/${pname}-${version}.tar.gz";
-    sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
+    hash = "sha256-ASO9rV/FzJYZ0BH572Fxm2ZrFLMZLFATJng1NuU4FHc=";
  };
  propagatedBuildInputs = [
    ClassC3 ClassInspector TestException MROCompat
@ -111,11 +111,11 @@ On Darwin, if a script has too many `-Idir` flags in its first line (its “sheb

 ImageExifTool = buildPerlPackage {
  pname = "Image-ExifTool";
-  version = "11.50";
+  version = "12.50";

  src = fetchurl {
-    url = "https://www.sno.phy.queensu.ca/~phil/exiftool/${pname}-${version}.tar.gz";
-    sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3";
+    url = "https://exiftool.org/${pname}-${version}.tar.gz";
+    hash = "sha256-vOhB/FwQMC8PPvdnjDvxRpU6jAZcC6GMQfc0AH4uwKg=";
  };

  buildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
@ -146,7 +146,7 @@ $ nix-generate-from-cpan XML::Simple
    version = "2.22";
    src = fetchurl {
      url = "mirror://cpan/authors/id/G/GR/GRANTM/XML-Simple-2.22.tar.gz";
-      sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
+      hash = "sha256-uUUO8i6pZErl1q2ghtxDAPoQW+BQogMOvU79KMGY60k=";
    };
    propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
    meta = {
--- a/doc/languages-frameworks/pkg-config.section.md
+++ b/doc/languages-frameworks/pkg-config.section.md
@ -0,0 +1,51 @@
+# pkg-config {#sec-pkg-config}
+
+*pkg-config* is a unified interface for declaring and querying built C/C++ libraries.
+
+Nixpkgs provides a couple of facilities for working with this tool.
+
+## Writing packages providing pkg-config modules
+
+Packages should set `meta.pkgConfigModules` with the list of package config modules they provide.
+They should also use `testers.testMetaPkgConfig` to check that the final built package matches that list.
+Additionally, the [`validatePkgConfig` setup hook](https://nixos.org/manual/nixpkgs/stable/#validatepkgconfig), will do extra checks on to-be-installed pkg-config modules.
+
+A good example of all these things is zlib:
+
+```
+{ pkg-config, testers, ... }:
+
+stdenv.mkDerivation (finalAttrs: {
+  ...
+
+  nativeBuildInputs = [ pkg-config validatePkgConfig ];
+
+  passthru.tests.pkg-config = testers.testMetaPkgConfig finalAttrs.finalPackage;
+
+  meta = {
+    ...
+    pkgConfigModules = [ "zlib" ];
+  };
+})
+```
+
+## Accessing packages via pkg-config module name
+
+### Within Nixpkgs
+
+A [setup hook](#setup-hook-pkg-config) is bundled in the `pkg-config` package to bring a derivation's declared build inputs into the environment.
+This will populate environment variables like `PKG_CONFIG_PATH`, `PKG_CONFIG_PATH_FOR_BUILD`, and `PKG_CONFIG_PATH_HOST` based on:
+
+ - how `pkg-config` itself is depended upon
+
+ - how other dependencies are depended upon
+
+For more details see the section on [specifying dependencies in general](#ssec-stdenv-dependencies).
+
+Normal pkg-config commands to look up dependencies by name will then work with those environment variables defined by the hook.
+
+### Externally
+
+The `defaultPkgConfigPackages` package set is a set of aliases, named after the modules they provide.
+This is meant to be used by language-to-nix integrations.
+Hand-written packages should use the normal Nixpkgs attribute name instead.
--- a/doc/languages-frameworks/python.section.md
+++ b/doc/languages-frameworks/python.section.md
@ -58,7 +58,7 @@ with a nix-shell that has `numpy` and `toolz` in Python 3.9; then we will create
 a re-usable environment in a single-file Python script; then we will create a
 full Python environment for development with this same environment.

-Philosphically, this should be familiar to users who are used to a `venv` style
+Philosophically, this should be familiar to users who are used to a `venv` style
 of development: individual projects create their own Python environments without
 impacting the global environment or each other.

@ -356,7 +356,7 @@ buildPythonPackage rec {

  src = fetchPypi {
    inherit pname version;
-    sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
+    hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
  };

  doCheck = false;
@ -401,7 +401,7 @@ with import <nixpkgs> {};

      src = python39.pkgs.fetchPypi {
        inherit pname version;
-        sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
+        hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
      };

      doCheck = false;
@ -436,7 +436,7 @@ arguments `buildInputs` and `propagatedBuildInputs` to specify dependencies. If
 something is exclusively a build-time dependency, then the dependency should be
 included in `buildInputs`, but if it is (also) a runtime dependency, then it
 should be added to `propagatedBuildInputs`. Test dependencies are considered
-build-time dependencies and passed to `checkInputs`.
+build-time dependencies and passed to `nativeCheckInputs`.

 The following example shows which arguments are given to `buildPythonPackage` in
 order to build [`datashape`](https://github.com/blaze/datashape).
@ -450,10 +450,10 @@ buildPythonPackage rec {

  src = fetchPypi {
    inherit pname version;
-    sha256 = "14b2ef766d4c9652ab813182e866f493475e65e558bed0822e38bf07bba1a278";
+    hash = "sha256-FLLvdm1MllKrgTGC6Gb0k0deZeVYvtCCLji/B7uhong=";
  };

-  checkInputs = [ pytest ];
+  nativeCheckInputs = [ pytest ];
  propagatedBuildInputs = [ numpy multipledispatch python-dateutil ];

  meta = with lib; {
@ -466,7 +466,7 @@ buildPythonPackage rec {
 ```

 We can see several runtime dependencies, `numpy`, `multipledispatch`, and
-`python-dateutil`. Furthermore, we have one `checkInputs`, i.e. `pytest`. `pytest` is a
+`python-dateutil`. Furthermore, we have one `nativeCheckInputs`, i.e. `pytest`. `pytest` is a
 test runner and is only used during the `checkPhase` and is therefore not added
 to `propagatedBuildInputs`.

@ -484,7 +484,7 @@ buildPythonPackage rec {

  src = fetchPypi {
    inherit pname version;
-    sha256 = "16a0fa97hym9ysdk3rmqz32xdjqmy4w34ld3rm3jf5viqjx65lxk";
+    hash = "sha256-s9NiusRxFydHzaNRMjjxFcvWxfi45jGb9ql6eJJyQJk=";
  };

  buildInputs = [ pkgs.libxml2 pkgs.libxslt ];
@ -517,7 +517,7 @@ buildPythonPackage rec {

  src = fetchPypi {
    inherit pname version;
-    sha256 = "f6bbb6afa93085409ab24885a1a3cdb8909f095a142f4d49e346f2bd1b789074";
+    hash = "sha256-9ru2r6kwhUCaskiFoaPNuJCfCVoUL01J40byvRt4kHQ=";
  };

  buildInputs = [ pkgs.fftw pkgs.fftwFloat pkgs.fftwLongDouble];
@ -569,8 +569,14 @@ Pytest is the most common test runner for python repositories. A trivial
 test run would be:

 ```
-  checkInputs = [ pytest ];
-  checkPhase = "pytest";
+  nativeCheckInputs = [ pytest ];
+  checkPhase = ''
+    runHook preCheck
+
+    pytest
+
+    runHook postCheck
+  '';
 ```

 However, many repositories' test suites do not translate well to nix's build
@ -579,10 +585,14 @@ sandbox, and will generally need many tests to be disabled.
 To filter tests using pytest, one can do the following:

 ```
-  checkInputs = [ pytest ];
+  nativeCheckInputs = [ pytest ];
  # avoid tests which need additional data or touch network
  checkPhase = ''
+    runHook preCheck
+
    pytest tests/ --ignore=tests/integration -k 'not download and not update'
+
+    runHook postCheck
  '';
 ```

@ -605,10 +615,10 @@ been removed, in this case, it's recommended to use `pytestCheckHook`.
 `test` command for a `checkPhase` which runs `pytest`. This is also beneficial
 when a package may need many items disabled to run the test suite.

-Using the example above, the analagous `pytestCheckHook` usage would be:
+Using the example above, the analogous `pytestCheckHook` usage would be:

 ```
-  checkInputs = [ pytestCheckHook ];
+  nativeCheckInputs = [ pytestCheckHook ];

  # requires additional data
  pytestFlagsArray = [ "tests/" "--ignore=tests/integration" ];
@ -624,7 +634,7 @@ Using the example above, the analagous `pytestCheckHook` usage would be:
  ];
 ```

-This is expecially useful when tests need to be conditionally disabled,
+This is especially useful when tests need to be conditionally disabled,
 for example:

 ```
@ -734,17 +744,17 @@ work in any of the formats supported by `buildPythonPackage` currently,
 with the exception of `other` (see `format` in
 [`buildPythonPackage` parameters](#buildpythonpackage-parameters) for more details).

-### Using unittestCheckHook {#using-unittestcheckhook}
+#### Using unittestCheckHook {#using-unittestcheckhook}

 `unittestCheckHook` is a hook which will substitute the setuptools `test` command for a `checkPhase` which runs `python -m unittest discover`:

 ```
-  checkInputs = [ unittestCheckHook ];
+  nativeCheckInputs = [ unittestCheckHook ];

-  unittestFlags = [ "-s" "tests" "-v" ];
+  unittestFlagsArray = [ "-s" "tests" "-v" ];
 ```

-##### Using sphinxHook {#using-sphinxhook}
+#### Using sphinxHook {#using-sphinxhook}

 The `sphinxHook` is a helpful tool to build documentation and manpages
 using the popular Sphinx documentation generator.
@ -855,7 +865,7 @@ buildPythonPackage rec {

  src = fetchPypi {
    inherit pname version;
-    sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
+    hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
  };

  meta = with lib; {
@ -988,7 +998,7 @@ buildPythonPackage rec {

  src = fetchPypi {
    inherit pname version;
-    sha256 = "cf8436dc59d8695346fcd3ab296de46425ecab00d64096cebe79fb51ecb2eb93";
+    hash = "sha256-z4Q23FnYaVNG/NOrKW3kZCXsqwDWQJbOvnn7Ueyy65M=";
  };

  postPatch = ''
@ -996,7 +1006,7 @@ buildPythonPackage rec {
    rm testing/test_argcomplete.py
  '';

-  checkInputs = [ hypothesis ];
+  nativeCheckInputs = [ hypothesis ];
  nativeBuildInputs = [ setuptools-scm ];
  propagatedBuildInputs = [ attrs py setuptools six pluggy ];

@ -1009,7 +1019,7 @@ buildPythonPackage rec {

 The `buildPythonPackage` mainly does four things:

-* In the `buildPhase`, it calls `${python.interpreter} setup.py bdist_wheel` to
+* In the `buildPhase`, it calls `${python.pythonForBuild.interpreter} setup.py bdist_wheel` to
  build a wheel binary zipfile.
 * In the `installPhase`, it installs the wheel file using `pip install *.whl`.
 * In the `postFixup` phase, the `wrapPythonPrograms` bash function is called to
@ -1018,7 +1028,7 @@ The `buildPythonPackage` mainly does four things:
 * In the `installCheck` phase, `${python.interpreter} setup.py test` is run.

 By default tests are run because `doCheck = true`. Test dependencies, like
-e.g. the test runner, should be added to `checkInputs`.
+e.g. the test runner, should be added to `nativeCheckInputs`.

 By default `meta.platforms` is set to the same value
 as the interpreter unless overridden otherwise.
@ -1072,7 +1082,7 @@ because their behaviour is different:
 * `buildInputs ? []`: Build and/or run-time dependencies that need to be
  compiled for the host machine. Typically non-Python libraries which are being
  linked.
-* `checkInputs ? []`: Dependencies needed for running the `checkPhase`. These
+* `nativeCheckInputs ? []`: Dependencies needed for running the `checkPhase`. These
  are added to `nativeBuildInputs` when `doCheck = true`. Items listed in
  `tests_require` go here.
 * `propagatedBuildInputs ? []`: Aside from propagating dependencies,
@ -1098,7 +1108,7 @@ with import <nixpkgs> {};
        src =  super.fetchPypi {
          pname = "pandas";
          inherit version;
-          sha256 = "08blshqj9zj1wyjhhw3kl2vas75vhhicvv72flvf1z3jvapgw295";
+          hash = "sha256-JQn+rtpy/OA2deLszSKEuxyttqBzcAil50H+JDHUdCE=";
        };
      });
    };
@ -1158,7 +1168,7 @@ python3.pkgs.buildPythonApplication rec {

  src = python3.pkgs.fetchPypi {
    inherit pname version;
-    sha256 = "035w8gqql36zlan0xjrzz9j4lh9hs0qrsgnbyw07qs7lnkvbdv9x";
+    hash  = "sha256-Pe229rT0aHwA98s+nTHQMEFKZPo/yw6sot8MivFDvAw=";
  };

  propagatedBuildInputs = with python3.pkgs; [ tornado python-daemon ];
@ -1406,9 +1416,13 @@ example of such a situation is when `py.test` is used.
  buildPythonPackage {
    # ...
    # assumes the tests are located in tests
-    checkInputs = [ pytest ];
+    nativeCheckInputs = [ pytest ];
    checkPhase = ''
+      runHook preCheck
+
      py.test -k 'not function_name and not other_function' tests
+
+      runHook postCheck
    '';
  }
  ```
@ -1532,7 +1546,7 @@ of such package using the feature is `pkgs/tools/X11/xpra/default.nix`.
 As workaround install it as an extra `preInstall` step:

 ```shell
-${python.interpreter} setup.py install_data --install-dir=$out --root=$out
+${python.pythonForBuild.interpreter} setup.py install_data --install-dir=$out --root=$out
 sed -i '/ = data\_files/d' setup.py
 ```

@ -1674,9 +1688,9 @@ If you need to change a package's attribute(s) from `configuration.nix` you coul
      packageOverrides = python-self: python-super: {
        twisted = python-super.twisted.overridePythonAttrs (oldAttrs: {
          src = super.fetchPypi {
-            pname = "twisted";
+            pname = "Twisted";
            version = "19.10.0";
-            sha256 = "7394ba7f272ae722a74f3d969dcf599bc4ef093bc392038748a490f1724a515d";
+            hash = "sha256-c5S6fycq5yKnTz2Wnc9Zm8TvCTvDkgOHSKSQ8XJKUV0=";
            extension = "tar.bz2";
          };
        });
@ -1712,9 +1726,9 @@ self: super: {
    packageOverrides = python-self: python-super: {
      twisted = python-super.twisted.overrideAttrs (oldAttrs: {
        src = super.fetchPypi {
-          pname = "twisted";
+          pname = "Twisted";
          version = "19.10.0";
-          sha256 = "7394ba7f272ae722a74f3d969dcf599bc4ef093bc392038748a490f1724a515d";
+          hash = "sha256-c5S6fycq5yKnTz2Wnc9Zm8TvCTvDkgOHSKSQ8XJKUV0=";
          extension = "tar.bz2";
        };
      });
@ -1754,7 +1768,7 @@ In a `setup.py` or `setup.cfg` it is common to declare dependencies:

 * `setup_requires` corresponds to `nativeBuildInputs`
 * `install_requires` corresponds to `propagatedBuildInputs`
-* `tests_require` corresponds to `checkInputs`
+* `tests_require` corresponds to `nativeCheckInputs`

 ## Contributing {#contributing}

@ -1807,6 +1821,11 @@ hosted on GitHub, exporting a `GITHUB_API_TOKEN` is highly recommended.
 Updating packages in bulk leads to lots of breakages, which is why a
 stabilization period on the `python-unstable` branch is required.

+If a package is fragile and often breaks during these bulks updates, it
+may be reasonable to set `passthru.skipBulkUpdate = true` in the
+derivation. This decision should not be made on a whim and should
+always be supported by a qualifying comment.
+
 Once the branch is sufficiently stable it should normally be merged
 into the `staging` branch.

--- a/doc/languages-frameworks/qt.section.md
+++ b/doc/languages-frameworks/qt.section.md
@ -2,14 +2,11 @@

 Writing Nix expressions for Qt libraries and applications is largely similar as for other C++ software.
 This section assumes some knowledge of the latter.
-There are two problems that the Nixpkgs Qt infrastructure addresses,
-which are not shared by other C++ software:

-1.  There are usually multiple supported versions of Qt in Nixpkgs.
-    All of a package's dependencies must be built with the same version of Qt.
-    This is similar to the version constraints imposed on interpreted languages like Python.
-2.  Qt makes extensive use of runtime dependency detection.
-    Runtime dependencies are made into build dependencies through wrappers.
+The major caveat with Qt applications is that Qt uses a plugin system to load additional modules at runtime,
+from a list of well-known locations. In Nixpkgs, we patch QtCore to instead use an environment variable,
+and wrap Qt applications to set it to the right paths. This effectively makes the runtime dependencies
+pure and explicit at build-time, at the cost of introducing an extra indirection.

 ## Nix expression for a Qt package (default.nix) {#qt-default-nix}

@ -95,66 +92,3 @@ stdenv.mkDerivation {
 This means that scripts won't be automatically wrapped so you'll need to manually wrap them as previously mentioned.
 An example of when you'd always need to do this is with Python applications that use PyQt.
 :::
-
-## Adding a library to Nixpkgs {#adding-a-library-to-nixpkgs}
-
-Add Qt libraries to `qt5-packages.nix` to make them available for every
-supported Qt version.
-
-### Example adding a Qt library {#qt-library-all-packages-nix}
-
-The following represents the contents of `qt5-packages.nix`.
-
-```nix
-{
-  # ...
-
-  mylib = callPackage ../path/to/mylib {};
-
-  # ...
-}
-```
-
-Libraries are built with every available version of Qt.
-Use the `meta.broken` attribute to disable the package for unsupported Qt versions:
-
-```nix
-{ stdenv, lib, qtbase }:
-
-stdenv.mkDerivation {
-  # ...
-  # Disable this library with Qt < 5.9.0
-  meta.broken = lib.versionOlder qtbase.version "5.9.0";
-}
-```
-
-## Adding an application to Nixpkgs {#adding-an-application-to-nixpkgs}
-
-Add Qt applications to `qt5-packages.nix`. Add an alias to `all-packages.nix`
-to select the Qt 5 version used for the application.
-
-### Example adding a Qt application {#qt-application-all-packages-nix}
-
-The following represents the contents of `qt5-packages.nix`.
-
-```nix
-{
-  # ...
-
-  myapp = callPackage ../path/to/myapp {};
-
-  # ...
-}
-```
-
-The following represents the contents of `all-packages.nix`.
-
-```nix
-{
-  # ...
-
-  myapp = libsForQt5.myapp;
-
-  # ...
-}
-```
--- a/doc/languages-frameworks/rust.section.md
+++ b/doc/languages-frameworks/rust.section.md
@ -13,7 +13,7 @@ into your `configuration.nix` or bring them into scope with `nix-shell -p rustc

 For other versions such as daily builds (beta and nightly),
 use either `rustup` from nixpkgs (which will manage the rust installation in your home directory),
-or use a community maintained [Rust overlay](#using-community-rust-overlays).
+or use [community maintained Rust toolchains](#using-community-maintained-rust-toolchains).

 ## `buildRustPackage`: Compiling Rust applications with Cargo {#compiling-rust-applications-with-cargo}

@ -30,10 +30,10 @@ rustPlatform.buildRustPackage rec {
    owner = "BurntSushi";
    repo = pname;
    rev = version;
-    sha256 = "1hqps7l5qrjh9f914r5i6kmcz6f1yb951nv4lby0cjnp5l253kps";
+    hash = "sha256-+s5RBC3XSgb8omTbUNLywZnP6jSxZBKSS1BmXOjRF8M=";
  };

-  cargoSha256 = "03wf9r2csi6jpa7v5sw5lpxkrk4wfzwmzx7k3991q3bdjzcwnnwp";
+  cargoHash = "sha256-jtBw4ahSl88L0iuCXxQgZVm1EcboWRJMNtjxLVTtzts=";

  meta = with lib; {
    description = "A fast line-oriented regex search tool, similar to ag and ack";
@ -97,10 +97,10 @@ rustPlatform.buildRustPackage rec {

  src = fetchCrate {
    inherit pname version;
-    sha256 = "1mqaynrqaas82f5957lx31x80v74zwmwmjxxlbywajb61vh00d38";
+    sha256 = "sha256-aDQA4A5mScX9or3Lyiv/5GyAehidnpKKE0grhbP1Ctc=";
  };

-  cargoHash = "sha256-JmBZcDVYJaK1cK05cxx5BrnGWp4t8ca6FLUbvIot67s=";
+  cargoHash = "sha256-tbrTbutUs5aPSV+yE0IBUZAAytgmZV7Eqxia7g+9zRs=";
  cargoDepsName = pname;

  # ...
@ -186,6 +186,23 @@ added. To find the correct hash, you can first use `lib.fakeSha256` or
 `lib.fakeHash` as a stub hash. Building the package (and thus the
 vendored dependencies) will then inform you of the correct hash.

+For usage outside nixpkgs, `allowBuiltinFetchGit` could be used to
+avoid having to specify `outputHashes`. For example:
+
+```nix
+rustPlatform.buildRustPackage rec {
+  pname = "myproject";
+  version = "1.0.0";
+
+  cargoLock = {
+    lockFile = ./Cargo.lock;
+    allowBuiltinFetchGit = true;
+  };
+
+  # ...
+}
+```
+
 ### Cargo features {#cargo-features}

 You can disable default features using `buildNoDefaultFeatures`, and
@ -319,7 +336,7 @@ The above are just guidelines, and exceptions may be granted on a case-by-case b
 However, please check if it's possible to disable a problematic subset of the
 test suite and leave a comment explaining your reasoning.

-This can be achived with `--skip` in `checkFlags`:
+This can be achieved with `--skip` in `checkFlags`:

 ```nix
 rustPlatform.buildRustPackage {
@ -331,6 +348,20 @@ rustPlatform.buildRustPackage {
 }
 ```

+#### Using `cargo-nextest` {#using-cargo-nextest}
+
+Tests can be run with [cargo-nextest](https://github.com/nextest-rs/nextest)
+by setting `useNextest = true`. The same options still apply, but nextest
+accepts a different set of arguments and the settings might need to be
+adapted to be compatible with cargo-nextest.
+
+```nix
+rustPlatform.buildRustPackage {
+  /* ... */
+  useNextest = true;
+}
+```
+
 #### Setting `test-threads` {#setting-test-threads}

 `buildRustPackage` will use parallel test threads by default,
@ -403,8 +434,8 @@ cargoDeps = rustPlatform.fetchCargoTarball {
 ```

 The `src` attribute is required, as well as a hash specified through
-one of the `sha256` or `hash` attributes. The following optional
-attributes can also be used:
+one of the `hash` attribute. The following optional attributes can
+also be used:

 * `name`: the name that is used for the dependencies tarball.  If
  `name` is not specified, then the name `cargo-deps` will be used.
@ -474,6 +505,9 @@ you of the correct hash.
  flags can be passed to the tests using `checkFlags` and
  `checkFlagsArray`. By default, tests are run in parallel. This can
  be disabled by setting `dontUseCargoParallelTests`.
+* `cargoNextestHook`: run tests using
+  [cargo-nextest](https://github.com/nextest-rs/nextest). The same
+  options for `cargoCheckHook` also applies to `cargoNextestHook`.
 * `cargoInstallHook`: install binaries and static/shared libraries
  that were built using `cargoBuildHook`.
 * `bindgenHook`: for crates which use `bindgen` as a build dependency, lets
@ -514,7 +548,7 @@ buildPythonPackage rec {
  cargoDeps = rustPlatform.fetchCargoTarball {
    inherit src sourceRoot;
    name = "${pname}-${version}";
-    hash = "sha256-BoHIN/519Top1NUBjpB/oEMqi86Omt3zTQcXFWqrek0=";
+    hash = "sha256-miW//pnOmww2i6SOGbkrAIdc/JMDT4FJLqdMFojZeoY=";
  };

  sourceRoot = "source/bindings/python";
@ -551,7 +585,7 @@ buildPythonPackage rec {

  src = fetchPypi {
    inherit pname version;
-    sha256 = "1i1mx5y9hkyfi9jrrkcw804hmkcglxi6rmf7vin7jfnbr2bf4q64";
+    hash = "sha256-xGDilsjLOnls3MfVbGKnj80KCUCczZxlis5PmHzpNcQ=";
  };

  cargoDeps = rustPlatform.fetchCargoTarball {
@ -591,7 +625,7 @@ buildPythonPackage rec {
    owner = "Qiskit";
    repo = "retworkx";
    rev = version;
-    sha256 = "11n30ldg3y3y6qxg3hbj837pnbwjkqw3nxq6frds647mmmprrd20";
+    hash = "sha256-11n30ldg3y3y6qxg3hbj837pnbwjkqw3nxq6frds647mmmprrd20=";
  };

  cargoDeps = rustPlatform.fetchCargoTarball {
@ -608,227 +642,6 @@ buildPythonPackage rec {
 }
 ```

-## `buildRustCrate`: Compiling Rust crates using Nix instead of Cargo {#compiling-rust-crates-using-nix-instead-of-cargo}
-
-### Simple operation {#simple-operation}
-
-When run, `cargo build` produces a file called `Cargo.lock`,
-containing pinned versions of all dependencies. Nixpkgs contains a
-tool called `carnix` (`nix-env -iA nixos.carnix`), which can be used
-to turn a `Cargo.lock` into a Nix expression.
-
-That Nix expression calls `rustc` directly (hence bypassing Cargo),
-and can be used to compile a crate and all its dependencies. Here is
-an example for a minimal `hello` crate:
-
-```ShellSession
-$ cargo new hello
-$ cd hello
-$ cargo build
-     Compiling hello v0.1.0 (file:///tmp/hello)
-     Finished dev [unoptimized + debuginfo] target(s) in 0.20 secs
-$ carnix -o hello.nix --src ./. Cargo.lock --standalone
-$ nix-build hello.nix -A hello_0_1_0
-```
-
-Now, the file produced by the call to `carnix`, called `hello.nix`, looks like:
-
-```nix
-# Generated by carnix 0.6.5: carnix -o hello.nix --src ./. Cargo.lock --standalone
-{ stdenv, buildRustCrate, fetchgit }:
-let kernel = stdenv.buildPlatform.parsed.kernel.name;
-    # ... (content skipped)
-in
-rec {
-  hello = f: hello_0_1_0 { features = hello_0_1_0_features { hello_0_1_0 = f; }; };
-  hello_0_1_0_ = { dependencies?[], buildDependencies?[], features?[] }: buildRustCrate {
-    crateName = "hello";
-    version = "0.1.0";
-    authors = [ "pe@pijul.org <pe@pijul.org>" ];
-    src = ./.;
-    inherit dependencies buildDependencies features;
-  };
-  hello_0_1_0 = { features?(hello_0_1_0_features {}) }: hello_0_1_0_ {};
-  hello_0_1_0_features = f: updateFeatures f (rec {
-        hello_0_1_0.default = (f.hello_0_1_0.default or true);
-    }) [ ];
-}
-```
-
-In particular, note that the argument given as `--src` is copied
-verbatim to the source. If we look at a more complicated
-dependencies, for instance by adding a single line `libc="*"` to our
-`Cargo.toml`, we first need to run `cargo build` to update the
-`Cargo.lock`. Then, `carnix` needs to be run again, and produces the
-following nix file:
-
-```nix
-# Generated by carnix 0.6.5: carnix -o hello.nix --src ./. Cargo.lock --standalone
-{ stdenv, buildRustCrate, fetchgit }:
-let kernel = stdenv.buildPlatform.parsed.kernel.name;
-    # ... (content skipped)
-in
-rec {
-  hello = f: hello_0_1_0 { features = hello_0_1_0_features { hello_0_1_0 = f; }; };
-  hello_0_1_0_ = { dependencies?[], buildDependencies?[], features?[] }: buildRustCrate {
-    crateName = "hello";
-    version = "0.1.0";
-    authors = [ "pe@pijul.org <pe@pijul.org>" ];
-    src = ./.;
-    inherit dependencies buildDependencies features;
-  };
-  libc_0_2_36_ = { dependencies?[], buildDependencies?[], features?[] }: buildRustCrate {
-    crateName = "libc";
-    version = "0.2.36";
-    authors = [ "The Rust Project Developers" ];
-    sha256 = "01633h4yfqm0s302fm0dlba469bx8y6cs4nqc8bqrmjqxfxn515l";
-    inherit dependencies buildDependencies features;
-  };
-  hello_0_1_0 = { features?(hello_0_1_0_features {}) }: hello_0_1_0_ {
-    dependencies = mapFeatures features ([ libc_0_2_36 ]);
-  };
-  hello_0_1_0_features = f: updateFeatures f (rec {
-    hello_0_1_0.default = (f.hello_0_1_0.default or true);
-    libc_0_2_36.default = true;
-  }) [ libc_0_2_36_features ];
-  libc_0_2_36 = { features?(libc_0_2_36_features {}) }: libc_0_2_36_ {
-    features = mkFeatures (features.libc_0_2_36 or {});
-  };
-  libc_0_2_36_features = f: updateFeatures f (rec {
-    libc_0_2_36.default = (f.libc_0_2_36.default or true);
-    libc_0_2_36.use_std =
-      (f.libc_0_2_36.use_std or false) ||
-      (f.libc_0_2_36.default or false) ||
-      (libc_0_2_36.default or false);
-  }) [];
-}
-```
-
-Here, the `libc` crate has no `src` attribute, so `buildRustCrate`
-will fetch it from [crates.io](https://crates.io). A `sha256`
-attribute is still needed for Nix purity.
-
-### Handling external dependencies {#handling-external-dependencies}
-
-Some crates require external libraries. For crates from
-[crates.io](https://crates.io), such libraries can be specified in
-`defaultCrateOverrides` package in nixpkgs itself.
-
-Starting from that file, one can add more overrides, to add features
-or build inputs by overriding the hello crate in a separate file.
-
-```nix
-with import <nixpkgs> {};
-((import ./hello.nix).hello {}).override {
-  crateOverrides = defaultCrateOverrides // {
-    hello = attrs: { buildInputs = [ openssl ]; };
-  };
-}
-```
-
-Here, `crateOverrides` is expected to be a attribute set, where the
-key is the crate name without version number and the value a function.
-The function gets all attributes passed to `buildRustCrate` as first
-argument and returns a set that contains all attribute that should be
-overwritten.
-
-For more complicated cases, such as when parts of the crate's
-derivation depend on the crate's version, the `attrs` argument of
-the override above can be read, as in the following example, which
-patches the derivation:
-
-```nix
-with import <nixpkgs> {};
-((import ./hello.nix).hello {}).override {
-  crateOverrides = defaultCrateOverrides // {
-    hello = attrs: lib.optionalAttrs (lib.versionAtLeast attrs.version "1.0")  {
-      postPatch = ''
-        substituteInPlace lib/zoneinfo.rs \
-          --replace "/usr/share/zoneinfo" "${tzdata}/share/zoneinfo"
-      '';
-    };
-  };
-}
-```
-
-Another situation is when we want to override a nested
-dependency. This actually works in the exact same way, since the
-`crateOverrides` parameter is forwarded to the crate's
-dependencies. For instance, to override the build inputs for crate
-`libc` in the example above, where `libc` is a dependency of the main
-crate, we could do:
-
-```nix
-with import <nixpkgs> {};
-((import hello.nix).hello {}).override {
-  crateOverrides = defaultCrateOverrides // {
-    libc = attrs: { buildInputs = []; };
-  };
-}
-```
-
-### Options and phases configuration {#options-and-phases-configuration}
-
-Actually, the overrides introduced in the previous section are more
-general. A number of other parameters can be overridden:
-
- The version of `rustc` used to compile the crate:
-
-  ```nix
-  (hello {}).override { rust = pkgs.rust; };
-  ```
-
- Whether to build in release mode or debug mode (release mode by
-  default):
-
-  ```nix
-  (hello {}).override { release = false; };
-  ```
-
- Whether to print the commands sent to `rustc` when building
-  (equivalent to `--verbose` in cargo:
-
-  ```nix
-  (hello {}).override { verbose = false; };
-  ```
-
- Extra arguments to be passed to `rustc`:
-
-  ```nix
-  (hello {}).override { extraRustcOpts = "-Z debuginfo=2"; };
-  ```
-
- Phases, just like in any other derivation, can be specified using
-  the following attributes: `preUnpack`, `postUnpack`, `prePatch`,
-  `patches`, `postPatch`, `preConfigure` (in the case of a Rust crate,
-  this is run before calling the "build" script), `postConfigure`
-  (after the "build" script),`preBuild`, `postBuild`, `preInstall` and
-  `postInstall`. As an example, here is how to create a new module
-  before running the build script:
-
-  ```nix
-  (hello {}).override {
-    preConfigure = ''
-       echo "pub const PATH=\"${hi.out}\";" >> src/path.rs"
-    '';
-  };
-  ```
-
-### Features {#features}
-
-One can also supply features switches. For example, if we want to
-compile `diesel_cli` only with the `postgres` feature, and no default
-features, we would write:
-
-```nix
-(callPackage ./diesel.nix {}).diesel {
-  default = false;
-  postgres = true;
-}
-```
-
-Where `diesel.nix` is the file generated by Carnix, as explained above.
-
 ## Setting Up `nix-shell` {#setting-up-nix-shell}

 Oftentimes you want to develop code from within `nix-shell`. Unfortunately
@ -873,31 +686,61 @@ $ cargo build
 $ cargo test
 ```

-### Controlling Rust Version Inside `nix-shell` {#controlling-rust-version-inside-nix-shell}
+## Using community maintained Rust toolchains {#using-community-maintained-rust-toolchains}

-To control your rust version (i.e. use nightly) from within `shell.nix` (or
-other nix expressions) you can use the following `shell.nix`
+::: {.note}
+Note: The following projects cannot be used within nixpkgs since [IFD](#ssec-import-from-derivation) is disallowed.
+To package things that require Rust nightly, `RUSTC_BOOTSTRAP = true;` can sometimes be used as a hack.
+:::
+
+There are two community maintained approaches to Rust toolchain management:
+- [oxalica's Rust overlay](https://github.com/oxalica/rust-overlay)
+- [fenix](https://github.com/nix-community/fenix)
+
+Despite their names, both projects provides a similar set of packages and overlays under different APIs.
+
+Oxalica's overlay allows you to select a particular Rust version without you providing a hash or a flake input,
+but comes with a larger git repository than fenix.
+
+Fenix also provides rust-analyzer nightly in addition to the Rust toolchains.
+
+Both oxalica's overlay and fenix better integrate with nix and cache optimizations.
+Because of this and ergonomics, either of those community projects
+should be preferred to the Mozilla's Rust overlay ([nixpkgs-mozilla](https://github.com/mozilla/nixpkgs-mozilla)).
+
+The following documentation demonstrates examples using fenix and oxalica's Rust overlay
+with `nix-shell` and building derivations. More advanced usages like flake usage
+are documented in their own repositories.
+
+### Using Rust nightly with `nix-shell` {#using-rust-nightly-with-nix-shell}
+
+Here is a simple `shell.nix` that provides Rust nightly (default profile) using fenix:

 ```nix
-# Latest Nightly
-with import <nixpkgs> {};
-let src = fetchFromGitHub {
-      owner = "mozilla";
-      repo = "nixpkgs-mozilla";
-      # commit from: 2019-05-15
-      rev = "9f35c4b09fd44a77227e79ff0c1b4b6a69dff533";
-      sha256 = "18h0nvh55b5an4gmlgfbvwbyqj91bklf1zymis6lbdh75571qaz0";
-   };
+with import <nixpkgs> { };
+let
+  fenix = callPackage
+    (fetchFromGitHub {
+      owner = "nix-community";
+      repo = "fenix";
+      # commit from: 2023-03-03
+      rev = "e2ea04982b892263c4d939f1cc3bf60a9c4deaa1";
+      hash = "sha256-AsOim1A8KKtMWIxG+lXh5Q4P2bhOZjoUhFWJ1EuZNNk=";
+    })
+    { };
 in
-with import "${src.out}/rust-overlay.nix" pkgs pkgs;
-stdenv.mkDerivation {
+mkShell {
  name = "rust-env";
-  buildInputs = [
-    # Note: to use stable, just replace `nightly` with `stable`
-    latest.rustChannels.nightly.rust
+  nativeBuildInputs = [
+    # Note: to use stable, just replace `default` with `stable`
+    fenix.default.toolchain

-    # Add some extra dependencies from `pkgs`
-    pkg-config openssl
+    # Example Build-time Additional Dependencies
+    pkg-config
+  ];
+  buildInputs = [
+    # Example Run-time Additional Dependencies
+    openssl
  ];

  # Set Environment Variables
@ -905,116 +748,66 @@ stdenv.mkDerivation {
 }
 ```

-Now run:
+Save this to `shell.nix`, then run:

 ```ShellSession
 $ rustc --version
-rustc 1.26.0-nightly (188e693b3 2018-03-26)
+rustc 1.69.0-nightly (13471d3b2 2023-03-02)
 ```

 To see that you are using nightly.

-## Using community Rust overlays {#using-community-rust-overlays}
+Oxalica's Rust overlay has more complete examples of `shell.nix` (and cross compilation) under its
+[`examples` directory](https://github.com/oxalica/rust-overlay/tree/e53e8853aa7b0688bc270e9e6a681d22e01cf299/examples).

-There are two community maintained approaches to Rust toolchain management:
- [oxalica's Rust overlay](https://github.com/oxalica/rust-overlay)
- [fenix](https://github.com/nix-community/fenix)
+### Using Rust nightly in a derivation with `buildRustPackage` {#using-rust-nightly-in-a-derivation-with-buildrustpackage}

-Oxalica's overlay allows you to select a particular Rust version and components.
-See [their documentation](https://github.com/oxalica/rust-overlay#rust-overlay) for more
-detailed usage.
+You can also use Rust nightly to build rust packages using `makeRustPlatform`.
+The below snippet demonstrates invoking `buildRustPackage` with a Rust toolchain from oxalica's overlay:

-Fenix is an alternative to `rustup` and can also be used as an overlay.
-
-Both oxalica's overlay and fenix better integrate with nix and cache optimizations.
-Because of this and ergonomics, either of those community projects
-should be preferred to the Mozilla's Rust overlay (`nixpkgs-mozilla`).
-
-### How to select a specific `rustc` and toolchain version {#how-to-select-a-specific-rustc-and-toolchain-version}
-
-You can consume the oxalica overlay and use it to grab a specific Rust toolchain version.
-Here is an example `shell.nix` showing how to grab the current stable toolchain:
 ```nix
-{ pkgs ? import <nixpkgs> {
-    overlays = [
-      (import (fetchTarball "https://github.com/oxalica/rust-overlay/archive/master.tar.gz"))
-    ];
-  }
-}:
-pkgs.mkShell {
-  nativeBuildInputs = with pkgs; [
-    pkg-config
-    rust-bin.stable.latest.minimal
-  ];
-}
-```
-
-You can try this out by:
-1. Saving that to `shell.nix`
-2. Executing `nix-shell --pure --command 'rustc --version'`
-
-As of writing, this prints out `rustc 1.56.0 (09c42c458 2021-10-18)`.
-
-### How to use an overlay toolchain in a derivation  {#how-to-use-an-overlay-toolchain-in-a-derivation}
-
-You can also use an overlay's Rust toolchain with `buildRustPackage`.
-The below snippet demonstrates invoking `buildRustPackage` with an oxalica overlay selected Rust toolchain:
-```nix
-with import <nixpkgs> {
+with import <nixpkgs>
+{
  overlays = [
    (import (fetchTarball "https://github.com/oxalica/rust-overlay/archive/master.tar.gz"))
  ];
 };
+let
+  rustPlatform = makeRustPlatform {
+    cargo = rust-bin.stable.latest.minimal;
+    rustc = rust-bin.stable.latest.minimal;
+  };
+in

 rustPlatform.buildRustPackage rec {
  pname = "ripgrep";
  version = "12.1.1";
-  nativeBuildInputs = [
-    rust-bin.stable.latest.minimal
-  ];

  src = fetchFromGitHub {
    owner = "BurntSushi";
    repo = "ripgrep";
    rev = version;
-    sha256 = "1hqps7l5qrjh9f914r5i6kmcz6f1yb951nv4lby0cjnp5l253kps";
+    hash = "sha256-+s5RBC3XSgb8omTbUNLywZnP6jSxZBKSS1BmXOjRF8M=";
  };

-  cargoSha256 = "03wf9r2csi6jpa7v5sw5lpxkrk4wfzwmzx7k3991q3bdjzcwnnwp";
+  cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8=";
+
+  doCheck = false;

  meta = with lib; {
    description = "A fast line-oriented regex search tool, similar to ag and ack";
    homepage = "https://github.com/BurntSushi/ripgrep";
-    license = licenses.unlicense;
-    maintainers = [ maintainers.tailhook ];
+    license = with licenses; [ mit unlicense ];
+    maintainers = with maintainers; [ tailhook ];
  };
 }
 ```

 Follow the below steps to try that snippet.
-1. create a new directory
 1. save the above snippet as `default.nix` in that directory
-1. cd into that directory and run `nix-build`
+2. cd into that directory and run `nix-build`

-### Rust overlay installation {#rust-overlay-installation}
-
-You can use this overlay by either changing your local nixpkgs configuration,
-or by adding the overlay declaratively in a nix expression,  e.g. in `configuration.nix`.
-For more information see [the manual on installing overlays](#sec-overlays-install).
-
-### Declarative Rust overlay installation {#declarative-rust-overlay-installation}
-
-This snippet shows how to use oxalica's Rust overlay.
-Add the following to your `configuration.nix`, `home-configuration.nix`, `shell.nix`, or similar:
-
-```nix
-{ pkgs ? import <nixpkgs> {
-    overlays = [
-      (import (builtins.fetchTarball "https://github.com/oxalica/rust-overlay/archive/master.tar.gz"))
-      # Further overlays go here
-    ];
-  };
-};
-```
-
-Note that this will fetch the latest overlay version when rebuilding your system.
+Fenix also has examples with `buildRustPackage`,
+[crane](https://github.com/ipetkov/crane),
+[naersk](https://github.com/nix-community/naersk),
+and cross compilation in its [Examples](https://github.com/nix-community/fenix#examples) section.
--- a/doc/languages-frameworks/swift.section.md
+++ b/doc/languages-frameworks/swift.section.md
@ -0,0 +1,176 @@
+# Swift {#swift}
+
+The Swift compiler is provided by the `swift` package:
+
+```sh
+# Compile and link a simple executable.
+nix-shell -p swift --run 'swiftc -' <<< 'print("Hello world!")'
+# Run it!
+./main
+```
+
+The `swift` package also provides the `swift` command, with some caveats:
+
+- Swift Package Manager (SwiftPM) is packaged separately as `swiftpm`. If you
+  need functionality like `swift build`, `swift run`, `swift test`, you must
+  also add the `swiftpm` package to your closure.
+- On Darwin, the `swift repl` command requires an Xcode installation. This is
+  because it uses the system LLDB debugserver, which has special entitlements.
+
+## Module search paths {#ssec-swift-module-search-paths}
+
+Like other toolchains in Nixpkgs, the Swift compiler executables are wrapped
+to help Swift find your application's dependencies in the Nix store. These
+wrappers scan the `buildInputs` of your package derivation for specific
+directories where Swift modules are placed by convention, and automatically
+add those directories to the Swift compiler search paths.
+
+Swift follows different conventions depending on the platform. The wrappers
+look for the following directories:
+
+- On Darwin platforms: `lib/swift/macosx`
+  (If not targeting macOS, replace `macosx` with the Xcode platform name.)
+- On other platforms: `lib/swift/linux/x86_64`
+  (Where `linux` and `x86_64` are from lowercase `uname -sm`.)
+- For convenience, Nixpkgs also adds simply `lib/swift` to the search path.
+  This can save a bit of work packaging Swift modules, because many Nix builds
+  will produce output for just one target any way.
+
+## Core libraries {#ssec-swift-core-libraries}
+
+In addition to the standard library, the Swift toolchain contains some
+additional 'core libraries' that, on Apple platforms, are normally distributed
+as part of the OS or Xcode. These are packaged separately in Nixpkgs, and can
+be found (for use in `buildInputs`) as:
+
+- `swiftPackages.Dispatch`
+- `swiftPackages.Foundation`
+- `swiftPackages.XCTest`
+
+## Packaging with SwiftPM {#ssec-swift-packaging-with-swiftpm}
+
+Nixpkgs includes a small helper `swiftpm2nix` that can fetch your SwiftPM
+dependencies for you, when you need to write a Nix expression to package your
+application.
+
+The first step is to run the generator:
+
+```sh
+cd /path/to/my/project
+# Enter a Nix shell with the required tools.
+nix-shell -p swift swiftpm swiftpm2nix
+# First, make sure the workspace is up-to-date.
+swift package resolve
+# Now generate the Nix code.
+swiftpm2nix
+```
+
+This produces some files in a directory `nix`, which will be part of your Nix
+expression. The next step is to write that expression:
+
+```nix
+{ stdenv, swift, swiftpm, swiftpm2nix, fetchFromGitHub }:
+
+let
+  # Pass the generated files to the helper.
+  generated = swiftpm2nix.helpers ./nix;
+in
+
+stdenv.mkDerivation rec {
+  pname = "myproject";
+  version = "0.0.0";
+
+  src = fetchFromGitHub {
+    owner = "nixos";
+    repo = pname;
+    rev = version;
+    hash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
+  };
+
+  # Including SwiftPM as a nativeBuildInput provides a buildPhase for you.
+  # This by default performs a release build using SwiftPM, essentially:
+  #   swift build -c release
+  nativeBuildInputs = [ swift swiftpm ];
+
+  # The helper provides a configure snippet that will prepare all dependencies
+  # in the correct place, where SwiftPM expects them.
+  configurePhase = generated.configure;
+
+  installPhase = ''
+    # This is a special function that invokes swiftpm to find the location
+    # of the binaries it produced.
+    binPath="$(swiftpmBinPath)"
+    # Now perform any installation steps.
+    mkdir -p $out/bin
+    cp $binPath/myproject $out/bin/
+  '';
+}
+```
+
+### Custom build flags {#ssec-swiftpm-custom-build-flags}
+
+If you'd like to build a different configuration than `release`:
+
+```nix
+swiftpmBuildConfig = "debug";
+```
+
+It is also possible to provide additional flags to `swift build`:
+
+```nix
+swiftpmFlags = [ "--disable-dead-strip" ];
+```
+
+The default `buildPhase` already passes `-j` for parallel building.
+
+If these two customization options are insufficient, simply provide your own
+`buildPhase` that invokes `swift build`.
+
+### Running tests {#ssec-swiftpm-running-tests}
+
+Including `swiftpm` in your `nativeBuildInputs` also provides a default
+`checkPhase`, but it must be enabled with:
+
+```nix
+doCheck = true;
+```
+
+This essentially runs: `swift test -c release`
+
+### Patching dependencies {#ssec-swiftpm-patching-dependencies}
+
+In some cases, it may be necessary to patch a SwiftPM dependency. SwiftPM
+dependencies are located in `.build/checkouts`, but the `swiftpm2nix` helper
+provides these as symlinks to read-only `/nix/store` paths. In order to patch
+them, we need to make them writable.
+
+A special function `swiftpmMakeMutable` is available to replace the symlink
+with a writable copy:
+
+```
+configurePhase = generated.configure ++ ''
+  # Replace the dependency symlink with a writable copy.
+  swiftpmMakeMutable swift-crypto
+  # Now apply a patch.
+  patch -p1 -d .build/checkouts/swift-crypto -i ${./some-fix.patch}
+'';
+```
+
+## Considerations for custom build tools {#ssec-swift-considerations-for-custom-build-tools}
+
+### Linking the standard library {#ssec-swift-linking-the-standard-library}
+
+The `swift` package has a separate `lib` output containing just the Swift
+standard library, to prevent Swift applications needing a dependency on the
+full Swift compiler at run-time. Linking with the Nixpkgs Swift toolchain
+already ensures binaries correctly reference the `lib` output.
+
+Sometimes, Swift is used only to compile part of a mixed codebase, and the
+link step is manual. Custom build tools often locate the standard library
+relative to the `swift` compiler executable, and while the result will work,
+when this path ends up in the binary, it will have the Swift compiler as an
+unintended dependency.
+
+In this case, you should investigate how your build process discovers the
+standard library, and override the path. The correct path will be something
+like: `"${swift.swift.lib}/${swift.swiftModuleSubdir}"`
--- a/doc/languages-frameworks/texlive.section.md
+++ b/doc/languages-frameworks/texlive.section.md
@ -55,11 +55,11 @@ let
    srcs = [
      (fetchurl {
        url = "http://mirrors.ctan.org/macros/latex/contrib/foiltex/foiltex.dtx";
-        sha256 = "07frz0krpz7kkcwlayrwrj2a2pixmv0icbngyw92srp9fp23cqpz";
+        hash = "sha256-/2I2xHXpZi0S988uFsGuPV6hhMw8e0U5m/P8myf42R0=";
      })
      (fetchurl {
        url = "http://mirrors.ctan.org/macros/latex/contrib/foiltex/foiltex.ins";
-        sha256 = "09wkyidxk3n3zvqxfs61wlypmbhi1pxmjdi1kns9n2ky8ykbff99";
+        hash = "sha256-KTm3pkd+Cpu0nSE2WfsNEa56PeXBaNfx/sOO2Vv0kyc=";
      })
    ];

--- a/doc/languages-frameworks/vim.section.md
+++ b/doc/languages-frameworks/vim.section.md
@ -10,12 +10,21 @@ At the moment we support two different methods for managing plugins:
 - Vim packages (*recommended*)
 - vim-plug (vim only)

+Right now two Vim packages are available: `vim` which has most features that require extra
+dependencies disabled and `vim-full` which has them configurable and enabled by default.
+
+::: {.note}
+`vim_configurable` is a deprecated alias for `vim-full` and refers to the fact that its
+build-time features are configurable. It has nothing to do with user configuration,
+and both the `vim` and `vim-full` packages can be customized as explained in the next section.
+:::
+
 ## Custom configuration {#custom-configuration}

 Adding custom .vimrc lines can be done using the following code:

 ```nix
-vim_configurable.customize {
+vim-full.customize {
  # `name` optionally specifies the name of the executable and package
  name = "vim-with-plugins";

@ -62,7 +71,7 @@ neovim-qt.override {
 To store your plugins in Vim packages (the native Vim plugin manager, see `:help packages`) the following example can be used:

 ```nix
-vim_configurable.customize {
+vim-full.customize {
  vimrcConfig.packages.myVimPackage = with pkgs.vimPlugins; {
    # loaded on launch
    start = [ youcompleteme fugitive ];
@ -101,7 +110,7 @@ The resulting package can be added to `packageOverrides` in `~/.nixpkgs/config.n
 ```nix
 {
  packageOverrides = pkgs: with pkgs; {
-    myVim = vim_configurable.customize {
+    myVim = vim-full.customize {
      # `name` specifies the name of the executable and package
      name = "vim-with-plugins";
      # add here code from the example section
@ -131,7 +140,7 @@ let
      owner = "dkprice";
      repo = "vim-easygrep";
      rev = "d0c36a77cc63c22648e792796b1815b44164653a";
-      sha256 = "0y2p5mz0d5fhg6n68lhfhl8p4mlwkb82q337c22djs4w5zyzggbc";
+      hash = "sha256-bL33/S+caNmEYGcMLNCanFZyEYUOUmSsedCVBn4tV3g=";
    };
  };
 in
@ -190,7 +199,7 @@ To use [vim-plug](https://github.com/junegunn/vim-plug) to manage your Vim
 plugins the following example can be used:

 ```nix
-vim_configurable.customize {
+vim-full.customize {
  vimrcConfig.packages.myVimPackage = with pkgs.vimPlugins; {
    # loaded on launch
    plug.plugins = [ youcompleteme fugitive phpCompletion elm-vim ];
--- a/doc/manpage-urls.json
+++ b/doc/manpage-urls.json
@ -0,0 +1,32 @@
+{
+  "gnunet.conf(5)": "https://docs.gnunet.org/users/configuration.html",
+  "mpd(1)": "https://mpd.readthedocs.io/en/latest/mpd.1.html",
+  "mpd.conf(5)": "https://mpd.readthedocs.io/en/latest/mpd.conf.5.html",
+  "nix.conf(5)": "https://nixos.org/manual/nix/stable/command-ref/conf-file.html",
+
+  "journald.conf(5)": "https://www.freedesktop.org/software/systemd/man/journald.conf.html",
+  "logind.conf(5)": "https://www.freedesktop.org/software/systemd/man/logind.conf.html",
+  "networkd.conf(5)": "https://www.freedesktop.org/software/systemd/man/networkd.conf.html",
+  "systemd.automount(5)": "https://www.freedesktop.org/software/systemd/man/systemd.automount.html",
+  "systemd.exec(5)": "https://www.freedesktop.org/software/systemd/man/systemd.exec.html",
+  "systemd.link(5)": "https://www.freedesktop.org/software/systemd/man/systemd.link.html",
+  "systemd.mount(5)": "https://www.freedesktop.org/software/systemd/man/systemd.mount.html",
+  "systemd.netdev(5)": "https://www.freedesktop.org/software/systemd/man/systemd.netdev.html",
+  "systemd.network(5)": "https://www.freedesktop.org/software/systemd/man/systemd.network.html",
+  "systemd.nspawn(5)": "https://www.freedesktop.org/software/systemd/man/systemd.nspawn.html",
+  "systemd.path(5)": "https://www.freedesktop.org/software/systemd/man/systemd.path.html",
+  "systemd.resource-control(5)": "https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html",
+  "systemd.scope(5)": "https://www.freedesktop.org/software/systemd/man/systemd.scope.html",
+  "systemd.service(5)": "https://www.freedesktop.org/software/systemd/man/systemd.service.html",
+  "systemd.slice(5)": "https://www.freedesktop.org/software/systemd/man/systemd.slice.html",
+  "systemd.socket(5)": "https://www.freedesktop.org/software/systemd/man/systemd.socket.html",
+  "systemd.timer(5)": "https://www.freedesktop.org/software/systemd/man/systemd.timer.html",
+  "systemd.unit(5)": "https://www.freedesktop.org/software/systemd/man/systemd.unit.html",
+  "systemd-system.conf(5)": "https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html",
+  "systemd-user.conf(5)": "https://www.freedesktop.org/software/systemd/man/systemd-user.conf.html",
+  "timesyncd.conf(5)": "https://www.freedesktop.org/software/systemd/man/timesyncd.conf.html",
+  "tmpfiles.d(5)": "https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html",
+  "systemd.time(7)": "https://www.freedesktop.org/software/systemd/man/systemd.time.html",
+  "systemd-fstab-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html",
+  "systemd-networkd-wait-online.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html"
+}
--- a/doc/old/cross.txt
+++ b/doc/old/cross.txt
@ -61,7 +61,7 @@ stdenv.mkDerivation {
  builder = ./builder.sh;
  src = fetchurl {
    url = "http://ftp.nluug.nl/gnu/binutils/binutils-2.16.1.tar.bz2";
-    sha256 = "1ian3kwh2vg6hr3ymrv48s04gijs539vzrq62xr76bxbhbwnz2np";
+    hash = "sha256-14pv+YKrL3NyFwbnv9MoWsZHgEZk5+pHhuZtAfkcVsU=";
  };
  inherit noSysDirs;
  configureFlags = [ "--target=arm-linux" ];
@ -85,7 +85,7 @@ stdenv.mkDerivation {
  builder = ./builder.sh;
  src = fetchurl {
    url = "http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.1.tar.bz2";
-    sha256 = "12qxmc827fjhaz53kjy7vyrzsaqcg78amiqsb3qm20z26w705lma";
+    hash = "sha256-qtICDjfiA1HxWBrHqtB5DCv9s9/HyznKV1C6IxCrHYs=";
  };
 }
 ---
@ -151,8 +151,8 @@ stdenv.mkDerivation {
  name = "gcc-4.0.2-arm";
  builder = ./builder.sh;
  src = fetchurl {
-    url = ftp://ftp.nluug.nl/pub/gnu/gcc/gcc-4.0.2/gcc-core-4.0.2.tar.bz2;
-    sha256 = "02fxh0asflm8825w23l2jq1wvs7hbnam0jayrivg7zdv2ifnc0rc";
+    url = "ftp://ftp.nluug.nl/pub/gnu/gcc/gcc-4.0.2/gcc-core-4.0.2.tar.bz2";
+    hash = "sha256-LANmXRS7/fN2zF5JUJVd8OjNA5aCDsGLQKhSpxWA3Qk=";
  };
  # !!! apply only if noSysDirs is set
  patches = [./no-sys-dirs.patch ./gcc-inhibit.patch];
@ -303,7 +303,7 @@ One of the compiler flags that GCC uses for this compiler is called X_CFLAGS.
 This is used by the Nix build process to set the dynamic linker, glibc
 in the case of i686-linux using the default Nix packages collection.

-Obiously, since we need to compile libstc++ for arm-linux with uClibc linking
+Obviously, since we need to compile libstc++ for arm-linux with uClibc linking
 will not be done correctly: you can't link object files built for arm-linux
 with a glibc built for i686-linux.

--- a/doc/preface.chapter.md
+++ b/doc/preface.chapter.md
@ -24,8 +24,8 @@ Packages, including the Nix packages collection, are distributed through
 [channels](https://nixos.org/nix/manual/#sec-channels). The collection is
 distributed for users of Nix on non-NixOS distributions through the channel
 `nixpkgs`. Users of NixOS generally use one of the `nixos-*` channels, e.g.
-`nixos-19.09`, which includes all packages and modules for the stable NixOS
-19.09. Stable NixOS releases are generally only given
+`nixos-22.11`, which includes all packages and modules for the stable NixOS
+22.11. Stable NixOS releases are generally only given
 security updates. More up to date packages and modules are available via the
 `nixos-unstable` channel.

@ -43,4 +43,4 @@ The binaries are made available via a [binary cache](https://cache.nixos.org).

 The current Nix expressions of the channels are available in the
 [`nixpkgs`](https://github.com/NixOS/nixpkgs) repository in branches
-that correspond to the channel names (e.g. `nixos-19.09-small`).
+that correspond to the channel names (e.g. `nixos-22.11-small`).
--- a/Show More
+++ b/Show More
 @ -1 +1 @@
 .11
 .05