Release NixOS 22.11

(cherry picked from commit f1b9cc23aa)

.editorconfig

@@ -55,13 +55,10 @@ trim_trailing_whitespace = unset
 [*.lock]
 indent_size = unset
 
-# 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.
+# trailing whitespace is an actual syntax element of classic Markdown/
+# CommonMark to enforce a line break
 [*.md]
-trim_trailing_whitespace = true
+trim_trailing_whitespace = unset
 
 # binaries
 [*.nib]

.gitattributes

@@ -1,5 +1,4 @@
 **/deps.nix linguist-generated
-**/deps.json linguist-generated
 **/node-packages.nix linguist-generated
 
 pkgs/applications/editors/emacs-modes/*-generated.nix linguist-generated

.github/CODEOWNERS

@@ -28,7 +28,6 @@
 /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
@@ -49,10 +48,6 @@
 # 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
@@ -83,8 +78,6 @@
 /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
@@ -107,7 +100,7 @@
 /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 @mweinelt
+/doc/languages-frameworks/python.section.md                 @FRidh
 /pkgs/development/tools/poetry2nix                          @adisbladis
 /pkgs/development/interpreters/python/hooks                 @FRidh @jonringer
 
@@ -134,9 +127,7 @@
 /pkgs/development/ruby-modules      @marsam
 
 # Rust
-/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
+/pkgs/development/compilers/rust @Mic92 @LnL7 @zowoq
 
 # C compilers
 /pkgs/development/compilers/gcc @matthewbauer
@@ -155,11 +146,6 @@
 # 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
 
@@ -233,10 +219,10 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 /pkgs/top-level/emacs-packages.nix              @adisbladis
 
 # Neovim
-/pkgs/applications/editors/neovim      @figsoda @jonringer @teto
+/pkgs/applications/editors/neovim      @jonringer @teto
 
 # VimPlugins
-/pkgs/applications/editors/vim/plugins         @figsoda @jonringer
+/pkgs/applications/editors/vim/plugins         @jonringer
 
 # VsCode Extensions
 /pkgs/applications/editors/vscode/extensions   @jonringer
@@ -277,7 +263,6 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 # GNOME
 /pkgs/desktops/gnome                              @jtojnar
 /pkgs/desktops/gnome/extensions       @piegamesde @jtojnar
-/pkgs/build-support/make-hardcode-gsettings-patch @jtojnar
 
 # Cinnamon
 /pkgs/desktops/cinnamon @mkg20001
@@ -299,8 +284,11 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 # 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

.github/ISSUE_TEMPLATE/bug_report.md

@@ -26,7 +26,6 @@ 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.

.github/ISSUE_TEMPLATE/build_failure.md

@@ -1,36 +1,31 @@
 ---
 name: Build failure
 about: Create a report to help us improve
-title: 'Build failure: PACKAGENAME'
+title: ''
 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

.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: 'Documentation: '
+title: ''
 labels: '9.needs: documentation'
 assignees: ''
 
@@ -11,10 +11,6 @@ assignees: ''
 
 <!-- describe your problem -->
 
-## Proposal
-
-<!-- propose a solution (optional) -->
-
 ## Checklist
 
 <!-- make sure this issue is not redundant or obsolete -->
@@ -30,3 +26,7 @@ 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 -->
+

.github/ISSUE_TEMPLATE/out_of_date_package_report.md

@@ -1,17 +1,24 @@
 ---
 name: Out-of-date package reports
 about: For packages that are out-of-date
-title: 'Update request: PACKAGENAME OLDVERSION → NEWVERSION'
+title: ''
 labels: '9.needs: package (update)'
 assignees: ''
 
 ---
 
-- 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:
+
+###### 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)
 <!--
 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!
@@ -19,10 +26,23 @@ 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)
 
-**Notify maintainers**
+###### 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:
 
-<!-- If the search.nixos.org result shows no maintainers, tag the person that last updated the package. -->
+###### 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
+-->
 
------
+maintainers:
 
-Note for maintainers: Please tag this issue in your PR.
+###### Note for maintainers
+
+Please tag this issue in your PR.

.github/ISSUE_TEMPLATE/packaging_request.md

@@ -1,15 +1,14 @@
 ---
 name: Packaging requests
 about: For packages that are missing
-title: 'Package request: PACKAGENAME'
+title: ''
 labels: '0.kind: packaging request'
 assignees: ''
 
 ---
 
 **Project description**
-
-<!-- Describe the project a little: -->
+_describe the project a little_
 
 **Metadata**
 

.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: ''
 
 ---

.github/PULL_REQUEST_TEMPLATE.md

@@ -26,6 +26,7 @@ For new packages please briefly describe the package or provide a link to its ho
   - [ ] (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).
 
 <!--

.github/labeler.yml

@@ -19,11 +19,6 @@
   - 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/**/*
@@ -70,19 +65,6 @@
   - 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/**/*

.github/workflows/backport.yml

@@ -14,19 +14,23 @@ permissions:
 jobs:
   backport:
     permissions:
-      contents: write # for korthout/backport-action to create branch
-      pull-requests: write # for korthout/backport-action to create PR to backport
+      contents: write  # for zeebe-io/backport-action to create branch
+      pull-requests: write  # for zeebe-io/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: korthout/backport-action@v1.1.0
+        uses: zeebe-io/backport-action@v0.0.8
         with:
-          # Config README: https://github.com/korthout/backport-action#backport-action
+          # Config README: https://github.com/zeebe-io/backport-action#backport-action
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          github_workspace: ${{ github.workspace }}
           pull_description: |-
             Bot-based backport to `${target_branch}`, triggered by a label in #${pull_number}.
 

.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@v19
+    - uses: cachix/install-nix-action@v18
     - uses: cachix/cachix-action@v12
       with:
         # This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.

.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 treewide]')"
+    if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip editorconfig]')"
     steps:
     - name: Get list of changed files from PR
       env:
@@ -28,7 +28,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@v19
+    - uses: cachix/install-nix-action@v18
       with:
         # nixpkgs commit is pinned so that it doesn't break
         # editorconfig-checker 2.4.0

.github/workflows/labels.yml

@@ -16,7 +16,7 @@ permissions:
 jobs:
   labels:
     runs-on: ubuntu-latest
-    if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
+    if: github.repository_owner == 'NixOS'
     steps:
     - uses: actions/labeler@v4
       with:

.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@v19
+      - uses: cachix/install-nix-action@v18
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true

.github/workflows/manual-nixpkgs.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@v19
+      - uses: cachix/install-nix-action@v18
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true

.github/workflows/manual-rendering.yml

@@ -18,7 +18,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
-      - uses: cachix/install-nix-action@v19
+      - uses: cachix/install-nix-action@v18
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true

.github/workflows/nixos-manual.yml

@@ -0,0 +1,34 @@
+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
+        }

.github/workflows/periodic-merge-24h.yml

@@ -38,6 +38,10 @@ 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

.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@v19
+      - uses: cachix/install-nix-action@v18
         with:
           nix_path: nixpkgs=channel:nixpkgs-unstable
       - name: setup
@@ -25,8 +25,6 @@ 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]"

.gitignore

@@ -2,8 +2,6 @@
 ,*
 .*.swp
 .*.swo
-.\#*
-\#*\#
 .idea/
 .vscode/
 outputs/

.mailmap

@@ -1,14 +1,3 @@
-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>
-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>
+Sandro <sandro.jaeckel@gmail.com>

.version

@@ -1 +1 @@
-23.05
+22.11

CONTRIBUTING.md

@@ -38,14 +38,11 @@ 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.
-    * More generally, it should not refer to the package name.
-  * Not end with a period (or any punctuation for that matter).
+  * Not have a period at the end.
 * `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).
@@ -56,10 +53,6 @@ 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
@@ -115,7 +108,7 @@ You can also create the backport manually:
 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.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]`.
+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 comitted 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
@@ -128,17 +121,14 @@ Anything that does not cause user or downstream dependency regressions can be ba
 - Security critical applications (E.g. `firefox`)
 
 ## 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. In the past release notes required a translation step to convert from markdown to a compatible docbook document, but this is no longer necessary.
+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.
 
 Steps for updating 23.05 Release notes:
 
 1. Edit `nixos/doc/manual/release-notes/rl-2305.section.md` with the desired changes
-2. Commit changes to `rl-2305.section.md`.
+2. Run `./nixos/doc/manual/md-to-db.sh` to render `nixos/doc/manual/from_md/release-notes/rl-2305.section.xml`
+3. Include changes to `rl-2305.section.md` and `rl-2305.section.xml` in the same commit.
 
 ## Reviewing contributions
 

COPYING

@@ -1,4 +1,4 @@
-Copyright (c) 2003-2023 Eelco Dolstra and the Nixpkgs/NixOS contributors
+Copyright (c) 2003-2022 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

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 conversion script (/maintainers/scripts/db-to-md.sh).
+# NOTE: Keep in sync with NixOS manual (/nixos/doc/manual/md-to-db.sh) and 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=$(PANDOC_LINK_MANPAGES_FILTER) \
+	--lua-filter=build-aux/pandoc-filters/link-unix-man-references.lua \
 	--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

doc/build-aux/pandoc-filters/docbook-writer/html-elements.lua

@@ -0,0 +1,11 @@
+--[[
+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

doc/build-aux/pandoc-filters/link-manpages.nix

@@ -1,28 +0,0 @@
-{ 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
-''

doc/build-aux/pandoc-filters/link-unix-man-references.lua

@@ -0,0 +1,17 @@
+--[[
+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

doc/build-aux/pandoc-filters/myst-reader/roles.lua

@@ -17,16 +17,9 @@ function Inlines(inlines)
     if correct_tags then
       -- docutils supports alphanumeric strings separated by [-._:]
       -- We are slightly more liberal for simplicity.
-      -- 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
+      local role = first.text:match('^{([-._+:%w]+)}$')
+      if role ~= nil then
+        inlines:remove(i)
         second.attributes['role'] = role
         second.classes:insert('interpreted-text')
       end

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";
-  hash = "sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=";
+  sha256 = "0v6r3wwnsk5pdjr188nip3pjgn1jrn5pc5ajpcfy6had6b3v4dwm";
 };
 ```
 
@@ -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";
-  hash = "sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=";
+  sha256 = "0v6r3wwnsk5pdjr188nip3pjgn1jrn5pc5ajpcfy6had6b3v4dwm";
 };
 ```
 
 **This will reuse the old contents**.
-Remember to invalidate the hash argument, in this case by setting the `hash` attribute to an empty string.
+Remember to invalidate the hash argument, in this case by setting the `sha256` attribute to an empty string.
 
 ```nix
 fetchurl {
   url = "http://www.example.org/hello-1.1.tar.gz";
-  hash = "";
+  sha256 = "";
 };
 ```
 
@@ -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-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=
+            got:    sha256-RApQUm78dswhBLC/rfU9y0u6pSAzHceIJqgmetRD24E=
 ```
 
 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 `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.
+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.
 
 ```nix
 { stdenv, fetchurl }:
@@ -58,7 +58,7 @@ stdenv.mkDerivation {
   name = "hello";
   src = fetchurl {
     url = "http://www.example.org/hello.tar.gz";
-    hash = "sha256-BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=";
+    sha256 = "1111111111111111111111111111111111111111111111111111";
   };
 }
 ```
@@ -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 `hash` 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 `sha256` 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 `hash`.
+Used with Subversion. Expects `url` to a Subversion directory, `rev`, and `sha256`.
 
 ## `fetchgit` {#fetchgit}
 
-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`.
+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`.
 
 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"
     ];
-    hash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
+    sha256 = "0000000000000000000000000000000000000000000000000000";
   };
 }
 ```
 
 ## `fetchfossil` {#fetchfossil}
 
-Used with Fossil. Expects `url` to a Fossil archive, `rev`, and `hash`.
+Used with Fossil. Expects `url` to a Fossil archive, `rev`, and `sha256`.
 
 ## `fetchcvs` {#fetchcvs}
 
-Used with CVS. Expects `cvsRoot`, `tag`, and `hash`.
+Used with CVS. Expects `cvsRoot`, `tag`, and `sha256`.
 
 ## `fetchhg` {#fetchhg}
 
-Used with Mercurial. Expects `url`, `rev`, and `hash`.
+Used with Mercurial. Expects `url`, `rev`, and `sha256`.
 
 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, `hash` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but `hash` 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, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but `sha256` 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, `hash` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available, but `hash` 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, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available, but `sha256` 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,37 +156,10 @@ 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 `hash`, but don't forget the tilde (~)
+it expects `owner`, `repo`, `rev` and `sha256`, 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
-
-***
-```

doc/builders/images.xml

@@ -10,6 +10,4 @@
  <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>

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";
-    hash = "sha256-OqTitCeZ6xmWbqYTXp8sDrmVgTNjPZNW0hzUPW++mq4=";
+    sha256 = "1blsprpkvm0ws9b96gb36f0rbf8f5jgmw4x6dsb1kswr4ysf591s";
   };
   extraPkgs = pkgs: with pkgs; [ ];
 }

doc/builders/images/binarycache.section.md

@@ -1,49 +0,0 @@
-# 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
-```

doc/builders/images/dockertools.section.md

@@ -62,8 +62,6 @@ 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.
@@ -143,9 +141,7 @@ Create a Docker image with many of the store paths being on their own layer to i
 
 `config` _optional_
 
-`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).
+: 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).
 
     *Default:* `{}`
 
@@ -249,10 +245,10 @@ Its parameters are described in the example below:
 pullImage {
   imageName = "nixos/nix";
   imageDigest =
-    "sha256:473a2b527958665554806aea24d0131bacec46d23af09fef4598eeab331850fa";
+    "sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b";
   finalImageName = "nix";
-  finalImageTag = "2.11.1";
-  sha256 = "sha256-qvhj+Hlmviz+KEBVmsyPIzTB3QlVAFzwAY1zDPIBGxc=";
+  finalImageTag = "1.11";
+  sha256 = "0mqjy3zq2v6rrhizgb9nvhczl87lcfphq9601wcprdika2jz7qh8";
   os = "linux";
   arch = "x86_64";
 }
@@ -398,142 +394,3 @@ 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!

doc/builders/images/makediskimage.section.md

@@ -1,107 +0,0 @@
-# `<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;
-  }
-```
-
-

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`.

doc/builders/packages/cataclysm-dda.section.md

@@ -103,7 +103,7 @@ let
         owner = "Someone";
         repo = "AwesomeMod";
         rev = "...";
-        hash = "...";
+        sha256 = "...";
       };
       # Path to be installed in the unpacked source (default: ".")
       modRoot = "contents/under/this/path/will/be/installed";

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.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.
+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.
 
 ## 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://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`:
+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`:
 
 ```nix
 with import <nixpkgs> { config.allowUnfree = true; };

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:
 

doc/builders/packages/eclipse.section.md

@@ -43,11 +43,11 @@ packageOverrides = pkgs: {
         name = "myplugin1-1.0";
         srcFeature = fetchurl {
           url = "http://…/features/myplugin1.jar";
-          hash = "sha256-123…";
+          sha256 = "123…";
         };
         srcPlugin = fetchurl {
           url = "http://…/plugins/myplugin1.jar";
-          hash = "sha256-123…";
+          sha256 = "123…";
         };
       });
       (plugins.buildEclipseUpdateSite {
@@ -55,7 +55,7 @@ packageOverrides = pkgs: {
         src = fetchurl {
           stripRoot = false;
           url = "http://…/myplugin2.zip";
-          hash = "sha256-123…";
+          sha256 = "123…";
         };
       });
     ];

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";
-        hash = "sha256-2e73AbmYZlZXCP5ptYVcFjQYdjDp4iPoEPEOSCVF5sA=";
+        sha256 = "1h768ljlh3pi23l27qp961v1hd0nbj2vasgy11bmcrlqp40zgvnr";
       })
     ];
 

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/).
+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).
 
 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:
 

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";
-    hash = "...";
+    sha256 = "...";
   };
   passthru.scripts = [ "foo.py" "bar.lua" ];
   installPhase = ''

doc/builders/special.xml

@@ -7,5 +7,4 @@
  </para>
  <xi:include href="special/fhs-environments.section.xml" />
  <xi:include href="special/mkshell.section.xml" />
- <xi:include href="special/darwin-builder.section.xml" />
 </chapter>

doc/builders/special/darwin-builder.section.md

@@ -1,63 +0,0 @@
-# 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
-```

doc/builders/testers.chapter.md

@@ -1,19 +1,6 @@
 # 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
@@ -75,7 +62,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.
@@ -160,7 +147,7 @@ tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
   name = "nix-source";
   url = "https://github.com/NixOS/nix";
   rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a";
-  hash = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
+  sha256 = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
 };
 ```
 

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 `pname` attribute of the derivation. This is what most users see, in particular when using `nix-env`.
+- The `name` attribute of the derivation (excluding the version part). 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 `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`.
+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`.
 
 There are a few naming guidelines:
 
@@ -260,10 +260,6 @@ 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`)
@@ -430,10 +426,9 @@ 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";
-    hash = "sha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=";
+    sha256 = "1cw5fszffl5pkpa6s6wjnkiv6lm5k618s32sp60kvmvpy7a2v9kg";
   }
   ```
 
@@ -443,7 +438,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";
-    hash = "sha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=";
+    sha256 = "1cw5fszffl5pkpa6s6wjnkiv6lm5k618s32sp60kvmvpy7a2v9kg";
   }
   ```
 
@@ -454,14 +449,14 @@ In the file `pkgs/top-level/all-packages.nix` you can find fetch helpers, these
     owner = "NixOS";
     repo = "nix";
     rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
-    hash = "ha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=;
+    sha256 = "1i2yxndxb6yc9l6c99pypbd92lfq5aac4klq7y2v93c9qvx2cgpc";
   }
   ```
 
 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 `hash` by running `nix-shell -p nix-prefetch-github --run "nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS nix"`.
+Find the value to put as `sha256` by running `nix-shell -p nix-prefetch-github --run "nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS nix"`. 
 
 ## Obtaining source hash {#sec-source-hashes}
 
@@ -491,12 +486,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).
    :::
 
@@ -524,7 +519,7 @@ patches = [
   (fetchpatch {
     name = "fix-check-for-using-shared-freetype-lib.patch";
     url = "http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=8f5d285";
-    hash = "sha256-uRcxaCjd+WAuGrXOmGfFeu79cUILwkRdBu48mwcBE7g=";
+    sha256 = "1f0k043rng7f0rfl9hhb89qzvvksqmkrikmm38p61yfx51l325xr";
   })
 ];
 ```
@@ -674,18 +669,3 @@ 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

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, all of which can be used in NixOS option documentation. The following extensions are currently used:
+Additional syntax extensions are available, though not all extensions 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,10 +38,6 @@ Additional syntax extensions are available, all of which can be used in NixOS op
   ## 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…).
 
@@ -57,7 +53,7 @@ Additional syntax extensions are available, all of which can be used in NixOS op
   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/manpage-urls.json`.
+  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`.
 
   A few markups for other kinds of literals are also available:
 
@@ -71,6 +67,10 @@ Additional syntax extensions are available, all of which can be used in NixOS op
 
   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,6 +96,10 @@ Additional syntax extensions are available, all of which can be used in NixOS op
     - [`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:
 

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.
 
-   - 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.
+   - 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.
 
    - 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.
 

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-individual-maintainer-list}
+## Individual maintainer list {#reviewing-contributions-indvidual-maintainer-list}
 
 When adding users to `maintainers/maintainer-list.nix`, the following
 checks should be performed:

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";
-    hash = "sha256-SEKe/8HcW0UBHCfPTTOnpRlzmV2nQPPeL6HOMxBZd14=";
+    sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
   })
   ```
 
@@ -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}
 

doc/default.nix

@@ -1,5 +1,6 @@
 { pkgs ? (import ./.. { }), nixpkgs ? { }}:
 let
+  lib = pkgs.lib;
   doc-support = import ./doc-support { inherit pkgs nixpkgs; };
 in pkgs.stdenv.mkDerivation {
   name = "nixpkgs-manual";
@@ -14,7 +15,7 @@ in pkgs.stdenv.mkDerivation {
     xmlformat
   ];
 
-  src = pkgs.nix-gitignore.gitignoreSource [] ./.;
+  src = lib.cleanSource ./.;
 
   postPatch = ''
     ln -s ${doc-support} ./doc-support/result
@@ -35,5 +36,4 @@ 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; };
 }

doc/doc-support/default.nix

@@ -3,23 +3,8 @@ let
   inherit (pkgs) lib;
   inherit (lib) hasPrefix removePrefix;
 
-  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; };
+  locationsXml = import ./lib-function-locations.nix { inherit pkgs nixpkgs; };
+  functionDocs = import ./lib-function-docs.nix { inherit locationsXml pkgs; };
   version = pkgs.lib.version;
 
   epub-xsl = pkgs.writeText "epub.xsl" ''

doc/doc-support/lib-function-docs.nix

@@ -1,36 +1,28 @@
-# Generates the documentation for library functions via nixdoc.
+# 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.
 
-{ pkgs, locationsXml, libsets }:
+{ pkgs ? import ./.. {}, locationsXml }:
 
 with pkgs; stdenv.mkDerivation {
   name = "nixpkgs-lib-docs";
-  src = ../../lib;
+  src = ./../../lib;
 
   buildInputs = [ nixdoc ];
   installPhase = ''
     function docgen {
-      # 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"
+      nixdoc -c "$1" -d "$2" -f "../lib/$1.nix"  > "$out/$1.xml"
     }
 
-    mkdir -p "$out"
-
-    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"
-
+    mkdir -p $out
     ln -s ${locationsXml} $out/locations.xml
+
+    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'
   '';
 }

doc/doc-support/lib-function-locations.nix

@@ -1,24 +1,24 @@
-{ pkgs, nixpkgs ? { }, libsets }:
+{ pkgs ? (import ./.. { }), nixpkgs ? { }}:
 let
   revision = pkgs.lib.trivial.revisionWithDefault (nixpkgs.revision or "master");
 
-  libDefPos = prefix: set:
-    builtins.concatMap
-      (name: [{
-        name = builtins.concatStringsSep "." (prefix ++ [name]);
+  libDefPos = set:
+    builtins.map
+      (name: {
+        name = name;
         location = builtins.unsafeGetAttrPos name set;
-      }] ++ nixpkgsLib.optionals
-        (builtins.length prefix == 0 && builtins.isAttrs set.${name})
-        (libDefPos (prefix ++ [name]) set.${name})
-      ) (builtins.attrNames set);
+      })
+      (builtins.attrNames set);
 
   libset = toplib:
     builtins.map
       (subsetname: {
         subsetname = subsetname;
-        functions = libDefPos [] toplib.${subsetname};
+        functions = libDefPos toplib.${subsetname};
       })
-      (builtins.map (x: x.name) libsets);
+      (builtins.filter
+        (name: builtins.isAttrs toplib.${name})
+        (builtins.attrNames toplib));
 
   nixpkgsLib = pkgs.lib;
 

doc/doc-support/parameters.xml

@@ -2,16 +2,12 @@
 <xsl:stylesheet
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
     version="1.0">
- <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="section.autolabel" select="1" />
+ <xsl:param name="section.label.includes.component.label" select="1" />
  <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="0" />
+ <xsl:param name="xref.with.number.and.title" select="1" />
  <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'" />

doc/functions/library.xml

@@ -8,7 +8,25 @@
   Nixpkgs provides a standard library at <varname>pkgs.lib</varname>, or through <code>import &lt;nixpkgs/lib&gt;</code>.
  </para>
 
- <!-- 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/*)" />
+ <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" />
 </section>

doc/functions/library/asserts.xml

@@ -0,0 +1,112 @@
+<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>

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
 

doc/hooks/breakpoint.section.md

@@ -10,7 +10,9 @@ 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`.
 :::

doc/hooks/postgresql-test-hook.section.md

@@ -9,7 +9,7 @@ stdenv.mkDerivation {
 
   # ...
 
-  nativeCheckInputs = [
+  checkInputs = [
     postgresql
     postgresqlTestHook
   ];
@@ -46,12 +46,6 @@ 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.

doc/languages-frameworks/agda.section.md

@@ -52,7 +52,7 @@ agda.withPackages (p: [
       repo = "agda-stdlib";
       owner = "agda";
       rev = "v1.5";
-      hash = "sha256-nEyxYGSWIDNJqBfGpRDLiOAnlHJKEKAOMnIaqfVZzJk=";
+      sha256 = "16fcb7ssj6kj687a042afaa2gq48rc8abihpm14k684ncihb2k4w";
     };
   }))
 ])
@@ -83,7 +83,7 @@ agda.withPackages (p: [
       owner = "owner";
       version = "...";
       rev = "...";
-      hash = "...";
+      sha256 = "...";
     };
   })
 ])

doc/languages-frameworks/android.section.md

@@ -13,7 +13,6 @@ with import <nixpkgs> {};
 
 let
   androidComposition = androidenv.composeAndroidPackages {
-    cmdLineToolsVersion = "8.0";
     toolsVersion = "26.1.1";
     platformToolsVersion = "30.0.5";
     buildToolsVersions = [ "30.0.3" ];
@@ -43,10 +42,7 @@ exceptions are the tools, platform-tools and build-tools sub packages.
 
 The following parameters are supported:
 
-* `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.
+* `toolsVersion`, specifies the version of the tools package to use
 * `platformsToolsVersion` specifies the version of the `platform-tools` plugin
 * `buildToolsVersions` specifies the versions of the `build-tools` plugins to
   use.
@@ -236,6 +232,7 @@ androidenv.emulateApp {
   platformVersion = "24";
   abiVersion = "armeabi-v7a"; # mips, x86, x86_64
   systemImageType = "default";
+  useGoogleAPIs = false;
   app = ./MyApp.apk;
   package = "MyApp";
   activity = "MainActivity";

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 dependencies.
+If there are git depencencies.
 
 - 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 dependencies.
           owner = "elixir-libraries";
           repo = "prometheus.ex";
           rev = "a4e9beb3c1c479d14b352fd9d6dd7b1f6d7deee5";
-          hash = "sha256-U17LlN6aGUKUFnT4XyYXppRN+TvUBIBRHEUsfeIiGOw=";
+          sha256 = "1v0q4bi7sb253i8q016l7gwlv5562wk5zy3l2sa446csvsacnpjk";
         };
         # you can re-use the same beamDeps argument as generated
         beamDeps = with final; [ prometheus ];
@@ -124,11 +124,11 @@ If there are git dependencies.
 };
 ```
 
-You will need to run the build process once to fix the hash to correspond to your new git src.
+You will need to run the build process once to fix the sha256 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/default.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.nix) for a usage example of FOD.
 
 Practical steps
 
@@ -138,13 +138,13 @@ Practical steps
   mixFodDeps = fetchMixDeps {
     pname = "mix-deps-${pname}";
     inherit src version;
-    hash = lib.fakeHash;
+    sha256 = lib.fakeSha256;
   };
 ```
 
-The first build will complain about the hash value, you can replace with the suggested value after that.
+The first build will complain about the sha256 value, you can replace with the suggested value after that.
 
-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.
+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.
 
 ##### mixRelease - example {#mix-release-example}
 
@@ -170,8 +170,7 @@ let
     pname = "mix-deps-${pname}";
     inherit src version;
     # nix will complain and tell you the right value to replace this with
-    hash = lib.fakeHash;
-    mixEnv = ""; # default is "prod", when empty includes all dependencies, such as "dev", "test".
+    sha256 = lib.fakeSha256;
     # if you have build time environment variables add them here
     MY_ENV_VAR="my_value";
   };
@@ -283,7 +282,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 `hash`) 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 `sha256`) and then use this overlay in your development environment:
 
 #### `shell.nix`
 
@@ -292,7 +291,7 @@ let
   elixir_1_13_1_overlay = (self: super: {
       elixir_1_13 = super.elixir_1_13.override {
         version = "1.13.1";
-        sha256 = "sha256-t0ic1LcC7EV3avWGdR7VbyX7pGDpnJSW1ZvwvQUPC3w=";
+        sha256 = "0z0b1w2vvw4vsnb99779c2jgn9bgslg7b1pmd9vlbv02nza9qj5p";
       };
     });
   pkgs = import <nixpkgs> { overlays = [ elixir_1_13_1_overlay ]; };

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 obtained using `mkCoqPackages coq`, where `coq` is the derivation to use.
+The associated package set can be optained 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 `hash` 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 `sha256` 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),

doc/languages-frameworks/crystal.section.md

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

doc/languages-frameworks/cuda.section.md

@@ -32,22 +32,3 @@ 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.

doc/languages-frameworks/cuelang.section.md

@@ -1,93 +0,0 @@
-# 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.

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 = "sha256-B4Q3c6IvTLg3Q92qYa8y+i4uTaphtFdjp+Ir3QQjdN0=";
+    sha256 = "1pbl4c2dsaz2lximgd31m96jwbps6apn3anx8cvvhk1gl9rkg107";
   };
 
   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 `hash` or `fetchSubmodules`.
+`fetchFromGitHub`, such as `sha256` 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;
-    hash = "sha256-n0nQtswVapWi/x7or0O3MEYmAkt/a1uvlOtnje6GGnk=";
+    sha256 = "0y8shvp8srzbjjpmnsvz9c12ciihnx1szs0yzyi9ashmrjvd0jcz";
     directory = "";
     file = "package.dhall";
     source = false;

doc/languages-frameworks/dotnet.section.md

@@ -28,13 +28,13 @@ mkShell {
   packages = [
     (with dotnetCorePackages; combinePackages [
       sdk_3_1
-      sdk_6_0
+      sdk_5_0
     ])
   ];
 }
 ```
 
-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:
+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:
 
 ```ShellSession
 $ dotnet --info
@@ -120,7 +120,8 @@ in buildDotnetModule rec {
   projectReferences = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure.
 
   dotnet-sdk = dotnetCorePackages.sdk_3_1;
-  dotnet-runtime = dotnetCorePackages.net_6_0;
+  dotnet-runtime = dotnetCorePackages.net_5_0;
+  dotnetFlags = [ "--runtime linux-x64" ];
 
   executables = [ "foo" ]; # This wraps "$out/lib/$pname/foo" to `$out/bin/foo`.
   executables = []; # Don't install any executables.

doc/languages-frameworks/emscripten.section.md

@@ -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";
-        hash = "sha256-i+QgY+5PYVg5pwhzcDnkfXAznBg3e8sWH2jZtixuWsk=";
+        sha256 = "1jasdqnbdnb83wbcnyrp32f36w3xwhwp0wq8lwwmhqagxrij1r4b";
       };
 
       configurePhase = ''

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://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`.
+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`.
 
 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://docs.elementary.io/hig)) 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://elementary.io/docs/human-interface-guidelines#human-interface-guidelines)) might require a special theme like `pantheon.elementary-gtk-theme`.
 
 ### GObject introspection typelibs {#ssec-gnome-typelibs}
 

doc/languages-frameworks/go.section.md

@@ -11,14 +11,7 @@ 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 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)).
+- `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;`
 - `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
@@ -30,7 +23,7 @@ pet = buildGoModule rec {
     owner = "knqyf263";
     repo = "pet";
     rev = "v${version}";
-    hash = "sha256-Gjw1dRrgM8D3G7v6WIM2+50r4HmTXvx0Xxme2fH9TlQ=";
+    sha256 = "0m2fzpqxk7hrbxsgqplkg7h2p7gv6s1miymv3gvw0cz039skag0s";
   };
 
   vendorHash = "sha256-ciBIR+a1oaYH+H1PcC8cD8ncfJczk1IiJ8iYNM+R6aA=";
@@ -66,7 +59,7 @@ deis = buildGoPackage rec {
     owner = "deis";
     repo = "deis";
     rev = "v${version}";
-    hash = "sha256-XCPD4LNWtAd8uz7zyCLRfT8rzxycIUmTACjU03GnaeM=";
+    sha256 = "1qv9lxqx7m18029lj8cw3k7jngvxs4iciwrypdy0gd2nnghc68sw";
   };
 
   goDeps = ./deps.nix;
@@ -83,11 +76,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 `hash` defined next to it.
+      # If `git` is used there should be `url`, `rev` and `sha256` defined next to it.
       type = "git";
       url = "https://gopkg.in/yaml.v2";
       rev = "a83829b6f1293c91addabc89d0571c246397bbf4";
-      hash = "sha256-EMrdy0M0tNuOcITaTAmT5/dPSKPXwHDKCXFpkGbVjdQ=";
+      sha256 = "1m4dsmk90sbi17571h6pld44zxz7jc4lrnl4f27dpd1l8g5xvjhh";
     };
   }
   {
@@ -96,7 +89,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";
-      hash = "sha256-Uo89zjE+v3R7zzOq/gbQOHj3SMYt2W1nDHS7RCUin3M=";
+      sha256 = "0wwz48jl9fvl1iknvn9dqr4gfy1qs03gxaikrxxp9gry6773v3sj";
     };
   }
 ]

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 referring to it as a `hy` attribute. This kind of installation adds `hy` to your environment and it successfully works with `python3`.
+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`.
 
 ::: {.caution}
-Packages that are installed with your python derivation, are not accessible by `hy` this way.
+Packages that are installed with your python derivation, are not accesible by `hy` this way.
 :::
 
 ### Installation with packages {#installation-with-packages}

doc/languages-frameworks/idris.section.md

@@ -90,7 +90,7 @@ build-idris-package  {
     owner = "Heather";
     repo = "Idris.Yaml";
     rev = "5afa51ffc839844862b8316faba3bafa15656db4";
-    hash = "sha256-h28F9EEPuvab6zrfeE+0k1XGQJGwINnsJEG8yjWIl7w=";
+    sha256 = "1g4pi0swmg214kndj85hj50ccmckni7piprsxfdzdfhg87s0avw7";
   };
 
   meta = with lib; {

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 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.
+  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.
  </para>
  <xi:include href="agda.section.xml" />
  <xi:include href="android.section.xml" />
@@ -13,7 +13,6 @@
  <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" />
@@ -32,13 +31,11 @@
  <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" />

doc/languages-frameworks/javascript.section.md

@@ -175,10 +175,9 @@ buildNpmPackage rec {
     hash = "sha256-BR+ZGkBBfd0dSQqAvujsbgsEPFYw/ThrylxUbOksYxM=";
   };
 
-  npmDepsHash = "sha256-tuEfyePwlOy2/mOPdXbqJskO6IowvAP4DWg8xSZwbJw=";
+  patches = [ ./remove-prepack-script.patch ];
 
-  # The prepack script runs the build script, which we'd rather do in the build phase.
-  npmPackFlags = [ "--ignore-scripts" ];
+  npmDepsHash = "sha256-tuEfyePwlOy2/mOPdXbqJskO6IowvAP4DWg8xSZwbJw=";
 
   NODE_OPTIONS = "--openssl-legacy-provider";
 
@@ -243,7 +242,7 @@ If the downloaded files contain the `package.json` and `yarn.lock` files they ca
 ```nix
 offlineCache = fetchYarnDeps {
   yarnLock = src + "/yarn.lock";
-  hash = "....";
+  sha256 = "....";
 };
 ```
 
@@ -331,16 +330,13 @@ 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 Nixpkgs {#javascript-outside-nixpkgs}
+## Outside of nixpkgs {#javascript-outside-nixpkgs}
 
-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:
+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
 
 ### 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}
 
@@ -348,7 +344,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}
 

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";
-    hash = "sha256-4mLJG8n4m6y4Fqd0meUDfsOb9RHSR0qa/KD5KCwrNXs=";
+    sha256 = "0yrm5cn2iyd0zjd4liyj27srphvy0gjrjx572swar6zqr4dwjqp2";
   };
   disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
   propagatedBuildInputs = [ bit32 lua std_normalize ];

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";
-    hash = "sha256-hIUofi81zowSMbt1lUsxCnVzfJGN3FEiTtN8CEFpwzY=";
+    sha256 = "sha256-hIUofi81zowSMbt1lUsxCnVzfJGN3FEiTtN8CEFpwzY=";
   };
 
   buildInputs = with nimPackages; [
@@ -65,7 +65,7 @@ buildNimPackage rec {
   version = "2.0.4";
   src = fetchNimble {
     inherit pname version;
-    hash = "sha256-qDtVSnf+7rTq36WAxgsUZ8XoUk4sKwHyt8EJcY5WP+o=";
+    hash = "sha256-Vtcj8goI4zZPQs2TbFoBFlcR5UqDtOldaXSH/+/xULk=";
   };
   propagatedBuildInputs = [ SDL2 ];
 }

doc/languages-frameworks/ocaml.section.md

@@ -79,7 +79,7 @@ buildDunePackage rec {
     owner  = "inhabitedtype";
     repo   = pname;
     rev    = version;
-    hash   = "sha256-MK8o+iPGANEhrrTc1Kz9LBilx2bDPQt7Pp5P2libucI=";
+    sha256 = "1hmrkdcdlkwy7rxhngf3cv3sa61cznnd9p5lmqhx20664gx2ibrh";
   };
 
   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";
-    hash = "sha256-d5/3KUBAWRj8tntr4RkJ74KWW7wvn/B/m1nx0npnzyc=";
+    sha256 = "09ygcxxd5warkdzz17rgpidrd0pg14cy2svvnvy1hna080lzg7vp";
   };
 
   meta = with lib; {
@@ -129,8 +129,3 @@ 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.

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";
-    hash = "sha256-/5GE5xHT0uYGOQxroqj6LMU7CtKn2s6vMVoSXxL4iK4=";
+    sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
   };
 };
 ```
@@ -78,7 +78,7 @@ buildPerlPackage rec {
 
   src = fetchurl {
     url = "mirror://cpan/authors/id/P/PM/PMQS/${pname}-${version}.tar.gz";
-    hash = "sha256-4Y+HGgGQqcOfdiKcFIyMrWBEccVNVAMDBWZlFTMorh8=";
+    sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
   };
 
   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";
-    hash = "sha256-ASO9rV/FzJYZ0BH572Fxm2ZrFLMZLFATJng1NuU4FHc=";
+    sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
   };
   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 = "12.50";
+  version = "11.50";
 
   src = fetchurl {
-    url = "https://exiftool.org/${pname}-${version}.tar.gz";
-    hash = "sha256-vOhB/FwQMC8PPvdnjDvxRpU6jAZcC6GMQfc0AH4uwKg=";
+    url = "https://www.sno.phy.queensu.ca/~phil/exiftool/${pname}-${version}.tar.gz";
+    sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3";
   };
 
   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";
-      hash = "sha256-uUUO8i6pZErl1q2ghtxDAPoQW+BQogMOvU79KMGY60k=";
+      sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
     };
     propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
     meta = {

doc/languages-frameworks/pkg-config.section.md

@@ -1,51 +0,0 @@
-# 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.

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.
 
-Philosophically, this should be familiar to users who are used to a `venv` style
+Philosphically, 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;
-    hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
+    sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
   };
 
   doCheck = false;
@@ -401,7 +401,7 @@ with import <nixpkgs> {};
 
       src = python39.pkgs.fetchPypi {
         inherit pname version;
-        hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
+        sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
       };
 
       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 `nativeCheckInputs`.
+build-time dependencies and passed to `checkInputs`.
 
 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;
-    hash = "sha256-FLLvdm1MllKrgTGC6Gb0k0deZeVYvtCCLji/B7uhong=";
+    sha256 = "14b2ef766d4c9652ab813182e866f493475e65e558bed0822e38bf07bba1a278";
   };
 
-  nativeCheckInputs = [ pytest ];
+  checkInputs = [ 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 `nativeCheckInputs`, i.e. `pytest`. `pytest` is a
+`python-dateutil`. Furthermore, we have one `checkInputs`, 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;
-    hash = "sha256-s9NiusRxFydHzaNRMjjxFcvWxfi45jGb9ql6eJJyQJk=";
+    sha256 = "16a0fa97hym9ysdk3rmqz32xdjqmy4w34ld3rm3jf5viqjx65lxk";
   };
 
   buildInputs = [ pkgs.libxml2 pkgs.libxslt ];
@@ -517,7 +517,7 @@ buildPythonPackage rec {
 
   src = fetchPypi {
     inherit pname version;
-    hash = "sha256-9ru2r6kwhUCaskiFoaPNuJCfCVoUL01J40byvRt4kHQ=";
+    sha256 = "f6bbb6afa93085409ab24885a1a3cdb8909f095a142f4d49e346f2bd1b789074";
   };
 
   buildInputs = [ pkgs.fftw pkgs.fftwFloat pkgs.fftwLongDouble];
@@ -569,14 +569,8 @@ Pytest is the most common test runner for python repositories. A trivial
 test run would be:
 
 ```
-  nativeCheckInputs = [ pytest ];
-  checkPhase = ''
-    runHook preCheck
-
-    pytest
-
-    runHook postCheck
-  '';
+  checkInputs = [ pytest ];
+  checkPhase = "pytest";
 ```
 
 However, many repositories' test suites do not translate well to nix's build
@@ -585,14 +579,10 @@ sandbox, and will generally need many tests to be disabled.
 To filter tests using pytest, one can do the following:
 
 ```
-  nativeCheckInputs = [ pytest ];
+  checkInputs = [ 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
   '';
 ```
 
@@ -615,10 +605,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 analogous `pytestCheckHook` usage would be:
+Using the example above, the analagous `pytestCheckHook` usage would be:
 
 ```
-  nativeCheckInputs = [ pytestCheckHook ];
+  checkInputs = [ pytestCheckHook ];
 
   # requires additional data
   pytestFlagsArray = [ "tests/" "--ignore=tests/integration" ];
@@ -634,7 +624,7 @@ Using the example above, the analogous `pytestCheckHook` usage would be:
   ];
 ```
 
-This is especially useful when tests need to be conditionally disabled,
+This is expecially useful when tests need to be conditionally disabled,
 for example:
 
 ```
@@ -744,17 +734,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`:
 
 ```
-  nativeCheckInputs = [ unittestCheckHook ];
+  checkInputs = [ unittestCheckHook ];
 
-  unittestFlagsArray = [ "-s" "tests" "-v" ];
+  unittestFlags = [ "-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.
@@ -865,7 +855,7 @@ buildPythonPackage rec {
 
   src = fetchPypi {
     inherit pname version;
-    hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
+    sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
   };
 
   meta = with lib; {
@@ -998,7 +988,7 @@ buildPythonPackage rec {
 
   src = fetchPypi {
     inherit pname version;
-    hash = "sha256-z4Q23FnYaVNG/NOrKW3kZCXsqwDWQJbOvnn7Ueyy65M=";
+    sha256 = "cf8436dc59d8695346fcd3ab296de46425ecab00d64096cebe79fb51ecb2eb93";
   };
 
   postPatch = ''
@@ -1006,7 +996,7 @@ buildPythonPackage rec {
     rm testing/test_argcomplete.py
   '';
 
-  nativeCheckInputs = [ hypothesis ];
+  checkInputs = [ hypothesis ];
   nativeBuildInputs = [ setuptools-scm ];
   propagatedBuildInputs = [ attrs py setuptools six pluggy ];
 
@@ -1028,7 +1018,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 `nativeCheckInputs`.
+e.g. the test runner, should be added to `checkInputs`.
 
 By default `meta.platforms` is set to the same value
 as the interpreter unless overridden otherwise.
@@ -1082,7 +1072,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.
-* `nativeCheckInputs ? []`: Dependencies needed for running the `checkPhase`. These
+* `checkInputs ? []`: 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,
@@ -1108,7 +1098,7 @@ with import <nixpkgs> {};
         src =  super.fetchPypi {
           pname = "pandas";
           inherit version;
-          hash = "sha256-JQn+rtpy/OA2deLszSKEuxyttqBzcAil50H+JDHUdCE=";
+          sha256 = "08blshqj9zj1wyjhhw3kl2vas75vhhicvv72flvf1z3jvapgw295";
         };
       });
     };
@@ -1168,7 +1158,7 @@ python3.pkgs.buildPythonApplication rec {
 
   src = python3.pkgs.fetchPypi {
     inherit pname version;
-    hash  = "sha256-Pe229rT0aHwA98s+nTHQMEFKZPo/yw6sot8MivFDvAw=";
+    sha256 = "035w8gqql36zlan0xjrzz9j4lh9hs0qrsgnbyw07qs7lnkvbdv9x";
   };
 
   propagatedBuildInputs = with python3.pkgs; [ tornado python-daemon ];
@@ -1416,13 +1406,9 @@ example of such a situation is when `py.test` is used.
   buildPythonPackage {
     # ...
     # assumes the tests are located in tests
-    nativeCheckInputs = [ pytest ];
+    checkInputs = [ pytest ];
     checkPhase = ''
-      runHook preCheck
-
       py.test -k 'not function_name and not other_function' tests
-
-      runHook postCheck
     '';
   }
   ```
@@ -1688,9 +1674,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";
-            hash = "sha256-c5S6fycq5yKnTz2Wnc9Zm8TvCTvDkgOHSKSQ8XJKUV0=";
+            sha256 = "7394ba7f272ae722a74f3d969dcf599bc4ef093bc392038748a490f1724a515d";
             extension = "tar.bz2";
           };
         });
@@ -1726,9 +1712,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";
-          hash = "sha256-c5S6fycq5yKnTz2Wnc9Zm8TvCTvDkgOHSKSQ8XJKUV0=";
+          sha256 = "7394ba7f272ae722a74f3d969dcf599bc4ef093bc392038748a490f1724a515d";
           extension = "tar.bz2";
         };
       });
@@ -1768,7 +1754,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 `nativeCheckInputs`
+* `tests_require` corresponds to `checkInputs`
 
 ## Contributing {#contributing}
 

doc/languages-frameworks/qt.section.md

@@ -2,11 +2,14 @@
 
 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:
 
-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.
+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.
 
 ## Nix expression for a Qt package (default.nix) {#qt-default-nix}
 
@@ -92,3 +95,66 @@ 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;
+
+  # ...
+}
+```

doc/languages-frameworks/rust.section.md

@@ -30,10 +30,10 @@ rustPlatform.buildRustPackage rec {
     owner = "BurntSushi";
     repo = pname;
     rev = version;
-    hash = "sha256-+s5RBC3XSgb8omTbUNLywZnP6jSxZBKSS1BmXOjRF8M=";
+    sha256 = "1hqps7l5qrjh9f914r5i6kmcz6f1yb951nv4lby0cjnp5l253kps";
   };
 
-  cargoHash = "sha256-jtBw4ahSl88L0iuCXxQgZVm1EcboWRJMNtjxLVTtzts=";
+  cargoSha256 = "03wf9r2csi6jpa7v5sw5lpxkrk4wfzwmzx7k3991q3bdjzcwnnwp";
 
   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 = "sha256-aDQA4A5mScX9or3Lyiv/5GyAehidnpKKE0grhbP1Ctc=";
+    sha256 = "1mqaynrqaas82f5957lx31x80v74zwmwmjxxlbywajb61vh00d38";
   };
 
-  cargoHash = "sha256-tbrTbutUs5aPSV+yE0IBUZAAytgmZV7Eqxia7g+9zRs=";
+  cargoHash = "sha256-JmBZcDVYJaK1cK05cxx5BrnGWp4t8ca6FLUbvIot67s=";
   cargoDepsName = pname;
 
   # ...
@@ -186,23 +186,6 @@ 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
@@ -336,7 +319,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 achieved with `--skip` in `checkFlags`:
+This can be achived with `--skip` in `checkFlags`:
 
 ```nix
 rustPlatform.buildRustPackage {
@@ -348,20 +331,6 @@ 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,
@@ -434,8 +403,8 @@ cargoDeps = rustPlatform.fetchCargoTarball {
 ```
 
 The `src` attribute is required, as well as a hash specified through
-one of the `hash` attribute. The following optional attributes can
-also be used:
+one of the `sha256` or `hash` attributes. 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.
@@ -505,9 +474,6 @@ 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
@@ -548,7 +514,7 @@ buildPythonPackage rec {
   cargoDeps = rustPlatform.fetchCargoTarball {
     inherit src sourceRoot;
     name = "${pname}-${version}";
-    hash = "sha256-miW//pnOmww2i6SOGbkrAIdc/JMDT4FJLqdMFojZeoY=";
+    hash = "sha256-BoHIN/519Top1NUBjpB/oEMqi86Omt3zTQcXFWqrek0=";
   };
 
   sourceRoot = "source/bindings/python";
@@ -585,7 +551,7 @@ buildPythonPackage rec {
 
   src = fetchPypi {
     inherit pname version;
-    hash = "sha256-xGDilsjLOnls3MfVbGKnj80KCUCczZxlis5PmHzpNcQ=";
+    sha256 = "1i1mx5y9hkyfi9jrrkcw804hmkcglxi6rmf7vin7jfnbr2bf4q64";
   };
 
   cargoDeps = rustPlatform.fetchCargoTarball {
@@ -625,7 +591,7 @@ buildPythonPackage rec {
     owner = "Qiskit";
     repo = "retworkx";
     rev = version;
-    hash = "sha256-11n30ldg3y3y6qxg3hbj837pnbwjkqw3nxq6frds647mmmprrd20=";
+    sha256 = "11n30ldg3y3y6qxg3hbj837pnbwjkqw3nxq6frds647mmmprrd20";
   };
 
   cargoDeps = rustPlatform.fetchCargoTarball {
@@ -642,6 +608,227 @@ 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
@@ -699,7 +886,7 @@ let src = fetchFromGitHub {
       repo = "nixpkgs-mozilla";
       # commit from: 2019-05-15
       rev = "9f35c4b09fd44a77227e79ff0c1b4b6a69dff533";
-      hash = "sha256-18h0nvh55b5an4gmlgfbvwbyqj91bklf1zymis6lbdh75571qaz0=";
+      sha256 = "18h0nvh55b5an4gmlgfbvwbyqj91bklf1zymis6lbdh75571qaz0";
    };
 in
 with import "${src.out}/rust-overlay.nix" pkgs pkgs;
@@ -790,7 +977,7 @@ rustPlatform.buildRustPackage rec {
     owner = "BurntSushi";
     repo = "ripgrep";
     rev = version;
-    hash = "sha256-1hqps7l5qrjh9f914r5i6kmcz6f1yb951nv4lby0cjnp5l253kps=";
+    sha256 = "1hqps7l5qrjh9f914r5i6kmcz6f1yb951nv4lby0cjnp5l253kps";
   };
 
   cargoSha256 = "03wf9r2csi6jpa7v5sw5lpxkrk4wfzwmzx7k3991q3bdjzcwnnwp";

doc/languages-frameworks/swift.section.md

@@ -1,176 +0,0 @@
-# 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}"`

doc/languages-frameworks/texlive.section.md

@@ -55,11 +55,11 @@ let
     srcs = [
       (fetchurl {
         url = "http://mirrors.ctan.org/macros/latex/contrib/foiltex/foiltex.dtx";
-        hash = "sha256-/2I2xHXpZi0S988uFsGuPV6hhMw8e0U5m/P8myf42R0=";
+        sha256 = "07frz0krpz7kkcwlayrwrj2a2pixmv0icbngyw92srp9fp23cqpz";
       })
       (fetchurl {
         url = "http://mirrors.ctan.org/macros/latex/contrib/foiltex/foiltex.ins";
-        hash = "sha256-KTm3pkd+Cpu0nSE2WfsNEa56PeXBaNfx/sOO2Vv0kyc=";
+        sha256 = "09wkyidxk3n3zvqxfs61wlypmbhi1pxmjdi1kns9n2ky8ykbff99";
       })
     ];
 

doc/languages-frameworks/vim.section.md

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

doc/manpage-urls.json

@@ -1,32 +0,0 @@
-{
-  "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"
-}

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";
-    hash = "sha256-14pv+YKrL3NyFwbnv9MoWsZHgEZk5+pHhuZtAfkcVsU=";
+    sha256 = "1ian3kwh2vg6hr3ymrv48s04gijs539vzrq62xr76bxbhbwnz2np";
   };
   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";
-    hash = "sha256-qtICDjfiA1HxWBrHqtB5DCv9s9/HyznKV1C6IxCrHYs=";
+    sha256 = "12qxmc827fjhaz53kjy7vyrzsaqcg78amiqsb3qm20z26w705lma";
   };
 }
 ---
@@ -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";
-    hash = "sha256-LANmXRS7/fN2zF5JUJVd8OjNA5aCDsGLQKhSpxWA3Qk=";
+    url = ftp://ftp.nluug.nl/pub/gnu/gcc/gcc-4.0.2/gcc-core-4.0.2.tar.bz2;
+    sha256 = "02fxh0asflm8825w23l2jq1wvs7hbnam0jayrivg7zdv2ifnc0rc";
   };
   # !!! 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.
 
-Obviously, since we need to compile libstc++ for arm-linux with uClibc linking
+Obiously, 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.
 

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-22.11`, which includes all packages and modules for the stable NixOS
-22.11. Stable NixOS releases are generally only given
+`nixos-19.09`, which includes all packages and modules for the stable NixOS
+19.09. 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-22.11-small`).
+that correspond to the channel names (e.g. `nixos-19.09-small`).

doc/stdenv/cross-compilation.chapter.md

@@ -150,7 +150,7 @@ depsBuildBuild = [ buildPackages.stdenv.cc ];
 Add the following to your `mkDerivation` invocation.
 
 ```nix
-doCheck = stdenv.buildPlatform.canExecute stdenv.hostPlatform;
+doCheck = stdenv.hostPlatform == stdenv.buildPlatform;
 ```
 
 #### Package using Meson needs to run binaries for the host platform during build. {#cross-meson-runs-host-code}

doc/stdenv/meta.chapter.md

@@ -11,12 +11,58 @@ meta = with lib; {
   '';
   homepage = "https://www.gnu.org/software/hello/manual/";
   license = licenses.gpl3Plus;
-  maintainers = with maintainers; [ eelco ];
+  maintainers = [ maintainers.eelco ];
   platforms = platforms.all;
 };
 ```
 
-Meta-attributes are not passed to the builder of the package. Thus, a change to a meta-attribute doesn’t trigger a recompilation of the package.
+Meta-attributes are not passed to the builder of the package. Thus, a change to a meta-attribute doesn’t trigger a recompilation of the package. The value of a meta-attribute must be a string.
+
+The meta-attributes of a package can be queried from the command-line using `nix-env`:
+
+```ShellSession
+$ nix-env -qa hello --json
+{
+    "hello": {
+        "meta": {
+            "description": "A program that produces a familiar, friendly greeting",
+            "homepage": "https://www.gnu.org/software/hello/manual/",
+            "license": {
+                "fullName": "GNU General Public License version 3 or later",
+                "shortName": "GPLv3+",
+                "url": "http://www.fsf.org/licensing/licenses/gpl.html"
+            },
+            "longDescription": "GNU Hello is a program that prints \"Hello, world!\" when you run it.\nIt is fully customizable.\n",
+            "maintainers": [
+                "Ludovic Court\u00e8s <ludo@gnu.org>"
+            ],
+            "platforms": [
+                "i686-linux",
+                "x86_64-linux",
+                "armv5tel-linux",
+                "armv7l-linux",
+                "mips32-linux",
+                "x86_64-darwin",
+                "i686-cygwin",
+                "i686-freebsd13",
+                "x86_64-freebsd13",
+                "i686-openbsd",
+                "x86_64-openbsd"
+            ],
+            "position": "/home/user/dev/nixpkgs/pkgs/applications/misc/hello/default.nix:14"
+        },
+        "name": "hello-2.9",
+        "system": "x86_64-linux"
+    }
+}
+```
+
+`nix-env` knows about the `description` field specifically:
+
+```ShellSession
+$ nix-env -qa hello --description
+hello-2.3  A program that produces a familiar, friendly greeting
+```
 
 ## Standard meta-attributes {#sec-standard-meta-attributes}
 
@@ -66,7 +112,7 @@ For details, see [Licenses](#sec-meta-license).
 
 ### `maintainers` {#var-meta-maintainers}
 
-A list of the maintainers of this Nix expression. Maintainers are defined in [`nixpkgs/maintainers/maintainer-list.nix`](https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix). There is no restriction to becoming a maintainer, just add yourself to that list in a separate commit titled “maintainers: add alice” in the same pull request, and reference maintainers with `maintainers = with lib.maintainers; [ alice bob ]`.
+A list of the maintainers of this Nix expression. Maintainers are defined in [`nixpkgs/maintainers/maintainer-list.nix`](https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix). There is no restriction to becoming a maintainer, just add yourself to that list in a separate commit titled “maintainers: add alice”, and reference maintainers with `maintainers = with lib.maintainers; [ alice bob ]`.
 
 ### `mainProgram` {#var-meta-mainProgram}
 

doc/stdenv/multiple-output.chapter.md

@@ -29,7 +29,7 @@ NixOS provides two ways to select the outputs to install for packages listed in
 `nix-env` lacks an easy way to select the outputs to install. When installing a package, `nix-env` always installs the outputs listed in `meta.outputsToInstall`, even when the user explicitly selects an output.
 
 ::: {.warning}
-`nix-env` silently disregards the outputs selected by the user, and instead installs the outputs from `meta.outputsToInstall`. For example,
+`nix-env` silenty disregards the outputs selected by the user, and instead installs the outputs from `meta.outputsToInstall`. For example,
 
 ```ShellSession
 $ nix-env -iA nixpkgs.coreutils.info

doc/stdenv/stdenv.chapter.md

@@ -11,7 +11,7 @@ stdenv.mkDerivation {
   name = "libfoo-1.2.3";
   src = fetchurl {
     url = "http://example.org/libfoo-1.2.3.tar.bz2";
-    hash = "sha256-tWxU/LANbQE32my+9AXyt3nCT7NBVfJ45CX757EMT3Q=";
+    sha256 = "0x2g1jqygyr5wiwg4ma1nd7w4ydpy82z9gkcv8vh2v8dn3y58v5m";
   };
 }
 ```
@@ -24,7 +24,7 @@ stdenv.mkDerivation rec {
   version = "1.2.3";
   src = fetchurl {
     url = "http://example.org/libfoo-source-${version}.tar.bz2";
-    hash = "sha256-tWxU/LANbQE32my+9AXyt3nCT7NBVfJ45CX757EMT3Q=";
+    sha256 = "0x2g1jqygyr5wiwg4ma1nd7w4ydpy82z9gkcv8vh2v8dn3y58v5m";
   };
 }
 ```
@@ -95,27 +95,6 @@ installPhase() {
 genericBuild
 ```
 
-### Building a `stdenv` package in `nix-shell` {#sec-building-stdenv-package-in-nix-shell}
-
-To build a `stdenv` package in a [`nix-shell`](https://nixos.org/manual/nix/unstable/command-ref/nix-shell.html), use
-
-```bash
-nix-shell '<nixpkgs>' -A some_package
-eval ${unpackPhase:-unpackPhase}
-cd $sourceRoot
-eval ${patchPhase:-patchPhase}
-eval ${configurePhase:-configurePhase}
-eval ${buildPhase:-buildPhase}
-```
-
-To modify a [phase](#sec-stdenv-phases), first print it with
-
-```bash
-type buildPhase
-```
-
-then change it in a text editor, and paste it back to the terminal.
-
 ## Tools provided by `stdenv` {#sec-tools-of-stdenv}
 
 The standard environment provides the following packages:
@@ -137,82 +116,6 @@ On Linux, `stdenv` also includes the `patchelf` utility.
 
 ## Specifying dependencies {#ssec-stdenv-dependencies}
 
-Build systems often require more dependencies than just what `stdenv` provides. This section describes attributes accepted by `stdenv.mkDerivation` that can be used to make these dependencies available to the build system.
-
-### Overview {#ssec-stdenv-dependencies-overview}
-
-A full reference of the different kinds of dependencies is provided in [](#ssec-stdenv-dependencies-reference), but here is an overview of the most common ones.
-It should cover most use cases.
-
-Add dependencies to `nativeBuildInputs` if they are executed during the build:
-- those which are needed on `$PATH` during the build, for example `cmake` and `pkg-config`
-- [setup hooks](#ssec-setup-hooks), for example [`makeWrapper`](#fun-makeWrapper)
-- interpreters needed by [`patchShebangs`](#patch-shebangs.sh) for build scripts (with the `--build` flag), which can be the case for e.g. `perl`
-
-Add dependencies to `buildInputs` if they will end up copied or linked into the final output or otherwise used at runtime:
-- libraries used by compilers, for example `zlib`,
-- interpreters needed by [`patchShebangs`](#patch-shebangs.sh) for scripts which are installed, which can be the case for e.g. `perl`
-
-::: {.note}
-These criteria are independent.
-
-For example, software using Wayland usually needs the `wayland` library at runtime, so `wayland` should be added to `buildInputs`.
-But it also executes the `wayland-scanner` program as part of the build to generate code, so `wayland` should also be added to `nativeBuildInputs`.
-:::
-
-Dependencies needed only to run tests are similarly classified between native (executed during build) and non-native (executed at runtime):
-- `nativeCheckInputs` for test tools needed on `$PATH` (such as `ctest`) and [setup hooks](#ssec-setup-hooks) (for example [`pytestCheckHook`](#python))
-- `checkInputs` for libraries linked into test executables (for example the `qcheck` OCaml package)
-
-These dependencies are only injected when [`doCheck`](#var-stdenv-doCheck) is set to `true`.
-
-#### Example {#ssec-stdenv-dependencies-overview-example}
-
-Consider for example this simplified derivation for `solo5`, a sandboxing tool:
-```nix
-stdenv.mkDerivation rec {
-  pname = "solo5";
-  version = "0.7.5";
-
-  src = fetchurl {
-    url = "https://github.com/Solo5/solo5/releases/download/v${version}/solo5-v${version}.tar.gz";
-    sha256 = "sha256-viwrS9lnaU8sTGuzK/+L/PlMM/xRRtgVuK5pixVeDEw=";
-  };
-
-  nativeBuildInputs = [ makeWrapper pkg-config ];
-  buildInputs = [ libseccomp ];
-
-  postInstall = ''
-    substituteInPlace $out/bin/solo5-virtio-mkimage \
-      --replace "/usr/lib/syslinux" "${syslinux}/share/syslinux" \
-      --replace "/usr/share/syslinux" "${syslinux}/share/syslinux" \
-      --replace "cp " "cp --no-preserve=mode "
-
-    wrapProgram $out/bin/solo5-virtio-mkimage \
-      --prefix PATH : ${lib.makeBinPath [ dosfstools mtools parted syslinux ]}
-  '';
-
-  doCheck = true;
-  nativeCheckInputs = [ util-linux qemu ];
-  checkPhase = '' [elided] '';
-}
-```
-
-- `makeWrapper` is a setup hook, i.e., a shell script sourced by the generic builder of `stdenv`.
-  It is thus executed during the build and must be added to `nativeBuildInputs`.
-- `pkg-config` is a build tool which the configure script of `solo5` expects to be on `$PATH` during the build:
-  therefore, it must be added to `nativeBuildInputs`.
-- `libseccomp` is a library linked into `$out/bin/solo5-elftool`.
-  As it is used at runtime, it must be added to `buildInputs`.
-- Tests need `qemu` and `getopt` (from `util-linux`) on `$PATH`, these must be added to `nativeCheckInputs`.
-- Some dependencies are injected directly in the shell code of phases: `syslinux`, `dosfstools`, `mtools`, and `parted`.
-In this specific case, they will end up in the output of the derivation (`$out` here).
-As Nix marks dependencies whose absolute path is present in the output as runtime dependencies, adding them to `buildInputs` is not required.
-
-For more complex cases, like libraries linked into an executable which is then executed as part of the build system, see [](#ssec-stdenv-dependencies-reference).
-
-### Reference {#ssec-stdenv-dependencies-reference}
-
 As described in the Nix manual, almost any `*.drv` store path in a derivation’s attribute set will induce a dependency on that derivation. `mkDerivation`, however, takes a few attributes intended to include all the dependencies of a package. This is done both for structure and consistency, but also so that certain other setup can take place. For example, certain dependencies need their bin directories added to the `PATH`. That is built-in, but other setup is done via a pluggable mechanism that works in conjunction with these dependency attributes. See [](#ssec-setup-hooks) for details.
 
 Dependencies can be broken down along three axes: their host and target platforms relative to the new derivation’s, and whether they are propagated. The platform distinctions are motivated by cross compilation; see [](#chap-cross) for exactly what each platform means. [^footnote-stdenv-ignored-build-platform] But even if one is not cross compiling, the platforms imply whether or not the dependency is needed at run-time or build-time, a concept that makes perfect sense outside of cross compilation. By default, the run-time/build-time distinction is just a hint for mental clarity, but with `strictDeps` set it is mostly enforced even in the native case.
@@ -284,21 +187,21 @@ Because of the bounds checks, the uncommon cases are `h = t` and `h + 2 = t`. In
 
 Overall, the unifying theme here is that propagation shouldn’t be introducing transitive dependencies involving platforms the depending package is unaware of. \[One can imagine the dependending package asking for dependencies with the platforms it knows about; other platforms it doesn’t know how to ask for. The platform description in that scenario is a kind of unforagable capability.\] The offset bounds checking and definition of `mapOffset` together ensure that this is the case. Discovering a new offset is discovering a new platform, and since those platforms weren’t in the derivation “spec” of the needing package, they cannot be relevant. From a capability perspective, we can imagine that the host and target platforms of a package are the capabilities a package requires, and the depending package must provide the capability to the dependency.
 
-#### Variables specifying dependencies {#variables-specifying-dependencies}
+### Variables specifying dependencies {#variables-specifying-dependencies}
 
-##### `depsBuildBuild` {#var-stdenv-depsBuildBuild}
+#### `depsBuildBuild` {#var-stdenv-depsBuildBuild}
 
 A list of dependencies whose host and target platforms are the new derivation’s build platform. These are programs and libraries used at build time that produce programs and libraries also used at build time. If the dependency doesn’t care about the target platform (i.e. isn’t a compiler or similar tool), put it in `nativeBuildInputs` instead. The most common use of this `buildPackages.stdenv.cc`, the default C compiler for this role. That example crops up more than one might think in old commonly used C libraries.
 
 Since these packages are able to be run at build-time, they are always added to the `PATH`, as described above. But since these packages are only guaranteed to be able to run then, they shouldn’t persist as run-time dependencies. This isn’t currently enforced, but could be in the future.
 
-##### `nativeBuildInputs` {#var-stdenv-nativeBuildInputs}
+#### `nativeBuildInputs` {#var-stdenv-nativeBuildInputs}
 
 A list of dependencies whose host platform is the new derivation’s build platform, and target platform is the new derivation’s host platform. These are programs and libraries used at build-time that, if they are a compiler or similar tool, produce code to run at run-time—i.e. tools used to build the new derivation. If the dependency doesn’t care about the target platform (i.e. isn’t a compiler or similar tool), put it here, rather than in `depsBuildBuild` or `depsBuildTarget`. This could be called `depsBuildHost` but `nativeBuildInputs` is used for historical continuity.
 
 Since these packages are able to be run at build-time, they are added to the `PATH`, as described above. But since these packages are only guaranteed to be able to run then, they shouldn’t persist as run-time dependencies. This isn’t currently enforced, but could be in the future.
 
-##### `depsBuildTarget` {#var-stdenv-depsBuildTarget}
+#### `depsBuildTarget` {#var-stdenv-depsBuildTarget}
 
 A list of dependencies whose host platform is the new derivation’s build platform, and target platform is the new derivation’s target platform. These are programs used at build time that produce code to run with code produced by the depending package. Most commonly, these are tools used to build the runtime or standard library that the currently-being-built compiler will inject into any code it compiles. In many cases, the currently-being-built-compiler is itself employed for that task, but when that compiler won’t run (i.e. its build and host platform differ) this is not possible. Other times, the compiler relies on some other tool, like binutils, that is always built separately so that the dependency is unconditional.
 
@@ -306,41 +209,41 @@ This is a somewhat confusing concept to wrap one’s head around, and for good r
 
 Since these packages are able to run at build time, they are added to the `PATH`, as described above. But since these packages are only guaranteed to be able to run then, they shouldn’t persist as run-time dependencies. This isn’t currently enforced, but could be in the future.
 
-##### `depsHostHost` {#var-stdenv-depsHostHost}
+#### `depsHostHost` {#var-stdenv-depsHostHost}
 
 A list of dependencies whose host and target platforms match the new derivation’s host platform. In practice, this would usually be tools used by compilers for macros or a metaprogramming system, or libraries used by the macros or metaprogramming code itself. It’s always preferable to use a `depsBuildBuild` dependency in the derivation being built over a `depsHostHost` on the tool doing the building for this purpose.
 
-##### `buildInputs` {#var-stdenv-buildInputs}
+#### `buildInputs` {#var-stdenv-buildInputs}
 
 A list of dependencies whose host platform and target platform match the new derivation’s. This would be called `depsHostTarget` but for historical continuity. If the dependency doesn’t care about the target platform (i.e. isn’t a compiler or similar tool), put it here, rather than in `depsBuildBuild`.
 
 These are often programs and libraries used by the new derivation at *run*-time, but that isn’t always the case. For example, the machine code in a statically-linked library is only used at run-time, but the derivation containing the library is only needed at build-time. Even in the dynamic case, the library may also be needed at build-time to appease the linker.
 
-##### `depsTargetTarget` {#var-stdenv-depsTargetTarget}
+#### `depsTargetTarget` {#var-stdenv-depsTargetTarget}
 
 A list of dependencies whose host platform matches the new derivation’s target platform. These are packages that run on the target platform, e.g. the standard library or run-time deps of standard library that a compiler insists on knowing about. It’s poor form in almost all cases for a package to depend on another from a future stage \[future stage corresponding to positive offset\]. Do not use this attribute unless you are packaging a compiler and are sure it is needed.
 
-##### `depsBuildBuildPropagated` {#var-stdenv-depsBuildBuildPropagated}
+#### `depsBuildBuildPropagated` {#var-stdenv-depsBuildBuildPropagated}
 
 The propagated equivalent of `depsBuildBuild`. This perhaps never ought to be used, but it is included for consistency \[see below for the others\].
 
-##### `propagatedNativeBuildInputs` {#var-stdenv-propagatedNativeBuildInputs}
+#### `propagatedNativeBuildInputs` {#var-stdenv-propagatedNativeBuildInputs}
 
 The propagated equivalent of `nativeBuildInputs`. This would be called `depsBuildHostPropagated` but for historical continuity. For example, if package `Y` has `propagatedNativeBuildInputs = [X]`, and package `Z` has `buildInputs = [Y]`, then package `Z` will be built as if it included package `X` in its `nativeBuildInputs`. If instead, package `Z` has `nativeBuildInputs = [Y]`, then `Z` will be built as if it included `X` in the `depsBuildBuild` of package `Z`, because of the sum of the two `-1` host offsets.
 
-##### `depsBuildTargetPropagated` {#var-stdenv-depsBuildTargetPropagated}
+#### `depsBuildTargetPropagated` {#var-stdenv-depsBuildTargetPropagated}
 
 The propagated equivalent of `depsBuildTarget`. This is prefixed for the same reason of alerting potential users.
 
-##### `depsHostHostPropagated` {#var-stdenv-depsHostHostPropagated}
+#### `depsHostHostPropagated` {#var-stdenv-depsHostHostPropagated}
 
 The propagated equivalent of `depsHostHost`.
 
-##### `propagatedBuildInputs` {#var-stdenv-propagatedBuildInputs}
+#### `propagatedBuildInputs` {#var-stdenv-propagatedBuildInputs}
 
 The propagated equivalent of `buildInputs`. This would be called `depsHostTargetPropagated` but for historical continuity.
 
-##### `depsTargetTargetPropagated` {#var-stdenv-depsTargetTargetPropagated}
+#### `depsTargetTargetPropagated` {#var-stdenv-depsTargetTargetPropagated}
 
 The propagated equivalent of `depsTargetTarget`. This is prefixed for the same reason of alerting potential users.
 
@@ -350,7 +253,7 @@ The propagated equivalent of `depsTargetTarget`. This is prefixed for the same r
 
 #### `NIX_DEBUG` {#var-stdenv-NIX_DEBUG}
 
-A number between 0 and 7 indicating how much information to log. If set to 1 or higher, `stdenv` will print moderate debugging information during the build. In particular, the `gcc` and `ld` wrapper scripts will print out the complete command line passed to the wrapped tools. If set to 6 or higher, the `stdenv` setup script will be run with `set -x` tracing. If set to 7 or higher, the `gcc` and `ld` wrapper scripts will also be run with `set -x` tracing.
+A natural number indicating how much information to log. If set to 1 or higher, `stdenv` will print moderate debugging information during the build. In particular, the `gcc` and `ld` wrapper scripts will print out the complete command line passed to the wrapped tools. If set to 6 or higher, the `stdenv` setup script will be run with `set -x` tracing. If set to 7 or higher, the `gcc` and `ld` wrapper scripts will also be run with `set -x` tracing.
 
 ### Attributes affecting build properties {#attributes-affecting-build-properties}
 
@@ -723,7 +626,7 @@ Before and after running `make`, the hooks `preBuild` and `postBuild` are called
 
 ### The check phase {#ssec-check-phase}
 
-The check phase checks whether the package was built correctly by running its test suite. The default `checkPhase` calls `make $checkTarget`, but only if the [`doCheck` variable](#var-stdenv-doCheck) is enabled.
+The check phase checks whether the package was built correctly by running its test suite. The default `checkPhase` calls `make check`, but only if the `doCheck` variable is enabled.
 
 #### Variables controlling the check phase {#variables-controlling-the-check-phase}
 
@@ -743,8 +646,7 @@ See the [build phase](#var-stdenv-makeFlags) for details.
 
 ##### `checkTarget` {#var-stdenv-checkTarget}
 
-The `make` target that runs the tests.
-If unset, use `check` if it exists, otherwise `test`; if neither is found, do nothing.
+The make target that runs the tests. Defaults to `check`.
 
 ##### `checkFlags` / `checkFlagsArray` {#var-stdenv-checkFlags}
 
@@ -752,11 +654,7 @@ A list of strings passed as additional flags to `make`. Like `makeFlags` and `ma
 
 ##### `checkInputs` {#var-stdenv-checkInputs}
 
-A list of host dependencies used by the phase, usually libraries linked into executables built during tests. This gets included in `buildInputs` when `doCheck` is set.
-
-##### `nativeCheckInputs` {#var-stdenv-nativeCheckInputs}
-
-A list of native dependencies used by the phase, notably tools needed on `$PATH`. This gets included in `nativeBuildInputs` when `doCheck` is set.
+A list of dependencies used by the phase. This gets included in `nativeBuildInputs` when `doCheck` is set.
 
 ##### `preCheck` {#var-stdenv-preCheck}
 
@@ -821,11 +719,11 @@ If set, libraries and executables are not stripped. By default, they are.
 
 ##### `dontStripHost` {#var-stdenv-dontStripHost}
 
-Like `dontStrip`, but only affects the `strip` command targeting the package’s host platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
+Like `dontStrip`, but only affects the `strip` command targetting the package’s host platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
 
 ##### `dontStripTarget` {#var-stdenv-dontStripTarget}
 
-Like `dontStrip`, but only affects the `strip` command targeting the packages’ target platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
+Like `dontStrip`, but only affects the `strip` command targetting the packages’ target platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
 
 ##### `dontMoveSbin` {#var-stdenv-dontMoveSbin}
 
@@ -923,11 +821,7 @@ A list of strings passed as additional flags to `make`. Like `makeFlags` and `ma
 
 ##### `installCheckInputs` {#var-stdenv-installCheckInputs}
 
-A list of host dependencies used by the phase, usually libraries linked into executables built during tests. This gets included in `buildInputs` when `doInstallCheck` is set.
-
-##### `nativeInstallCheckInputs` {#var-stdenv-nativeInstallCheckInputs}
-
-A list of native dependencies used by the phase, notably tools needed on `$PATH`. This gets included in `nativeBuildInputs` when `doInstallCheck` is set.
+A list of dependencies used by the phase. This gets included in `nativeBuildInputs` when `doInstallCheck` is set.
 
 ##### `preInstallCheck` {#var-stdenv-preInstallCheck}
 
@@ -943,10 +837,6 @@ The distribution phase is intended to produce a source distribution of the packa
 
 #### Variables controlling the distribution phase {#variables-controlling-the-distribution-phase}
 
-##### `doDist` {#var-stdenv-doDist}
-
-If set, the distribution phase is executed.
-
 ##### `distTarget` {#var-stdenv-distTarget}
 
 The make target that produces the distribution. Defaults to `dist`.
@@ -1100,32 +990,6 @@ Convenience function for `makeWrapper` that replaces `<\executable\>` with a wra
 
 If you will apply it multiple times, it will overwrite the wrapper file and you will end up with double wrapping, which should be avoided.
 
-### `prependToVar` \<variableName\> \<elements...\> {#fun-prependToVar}
-
-Prepend elements to a variable.
-
-Example:
-
-```shellSession
-$ configureFlags="--disable-static"
-$ prependToVar configureFlags --disable-dependency-tracking --enable-foo
-$ echo $configureFlags
---disable-dependency-tracking --enable-foo --disable-static
-```
-
-### `appendToVar` \<variableName\> \<elements...\> {#fun-appendToVar}
-
-Append elements to a variable.
-
-Example:
-
-```shellSession
-$ configureFlags="--disable-static"
-$ appendToVar configureFlags --disable-dependency-tracking --enable-foo
-$ echo $configureFlags
---disable-static --disable-dependency-tracking --enable-foo
-```
-
 ## Package setup hooks {#ssec-setup-hooks}
 
 Nix itself considers a build-time dependency as merely something that should previously be built and accessible at build time—packages themselves are on their own to perform any additional setup. In most cases, that is fine, and the downstream derivation can deal with its own dependencies. But for a few common tasks, that would result in almost every package doing the same sort of setup work—depending not on the package itself, but entirely on which dependencies were used.