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]
@@ -95,13 +92,3 @@ trim_trailing_whitespace = unset
 
 [pkgs/tools/misc/timidity/timidity.cfg]
 trim_trailing_whitespace = unset
-
-[pkgs/tools/virtualization/ovftool/*.ova]
-end_of_line = unset
-insert_final_newline = unset
-trim_trailing_whitespace = unset
-charset = unset
-
-[lib/tests/*.plist]
-indent_style = tab
-insert_final_newline = unset

.gitattributes

@@ -1,6 +1,4 @@
 **/deps.nix linguist-generated
-**/deps.json linguist-generated
-**/deps.toml lingust-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
@@ -45,15 +44,10 @@
 /pkgs/build-support/setup-hooks                  @Ericson2314
 /pkgs/build-support/setup-hooks/auto-patchelf.sh @layus
 /pkgs/build-support/setup-hooks/auto-patchelf.py @layus
-/pkgs/pkgs-lib                                   @infinisil
 
 # 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
@@ -84,15 +78,10 @@
 /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
 
-# NixOS QEMU virtualisation
-/nixos/virtualisation/qemu-vm.nix           @raitobezarius
-
 # Systemd
 /nixos/modules/system/boot/systemd.nix      @NixOS/systemd
 /nixos/modules/system/boot/systemd          @NixOS/systemd
@@ -108,8 +97,10 @@
 
 # Python-related code and docs
 /maintainers/scripts/update-python-libraries	              @FRidh
+/pkgs/top-level/python-packages.nix                         @FRidh @jonringer
 /pkgs/development/interpreters/python                       @FRidh
-/doc/languages-frameworks/python.section.md                 @FRidh @mweinelt
+/pkgs/development/python-modules                            @FRidh @jonringer
+/doc/languages-frameworks/python.section.md                 @FRidh
 /pkgs/development/tools/poetry2nix                          @adisbladis
 /pkgs/development/interpreters/python/hooks                 @FRidh @jonringer
 
@@ -136,13 +127,11 @@
 /pkgs/development/ruby-modules      @marsam
 
 # Rust
-/pkgs/development/compilers/rust @Mic92 @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
-/pkgs/development/compilers/llvm @matthewbauer @RaitoBezarius
+/pkgs/development/compilers/llvm @matthewbauer
 
 # Compatibility stuff
 /pkgs/top-level/unix-tools.nix @matthewbauer
@@ -157,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
 
@@ -235,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
@@ -279,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
@@ -301,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
@@ -313,8 +299,3 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 /pkgs/build-support/node/build-npm-package      @winterqt
 /pkgs/build-support/node/fetch-npm-deps         @winterqt
 /doc/languages-frameworks/javascript.section.md @winterqt
-
-# OCaml
-/pkgs/build-support/ocaml           @romildo @ulrikstrid
-/pkgs/development/compilers/ocaml   @romildo @ulrikstrid
-/pkgs/development/ocaml-modules     @romildo @ulrikstrid

.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,20 +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.2.0
+        uses: zeebe-io/backport-action@v0.0.8
         with:
-          # Config README: https://github.com/korthout/backport-action#backport-action
-          copy_labels_pattern: 'severity:\ssecurity'
+          # 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@v20
+    - 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/check-maintainers-sorted.yaml

@@ -1,24 +0,0 @@
-name: "Check that maintainer list is sorted"
-
-on:
-  pull_request_target:
-    paths:
-      - 'maintainers/maintainer-list.nix'
-permissions:
-  contents: read
-
-jobs:
-  nixos:
-    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@v20
-        with:
-          # explicitly enable sandbox
-          extra_nix_config: sandbox = true
-      - name: Check that maintainer-list.nix is sorted
-        run: nix-instantiate --eval maintainers/scripts/check-maintainers-sorted.nix

.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,14 +28,16 @@ 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@v20
+    - uses: cachix/install-nix-action@v18
       with:
         # nixpkgs commit is pinned so that it doesn't break
         # editorconfig-checker 2.4.0
         nix_path: nixpkgs=https://github.com/NixOS/nixpkgs/archive/c473cc8714710179df205b153f4e9fa007107ff9.tar.gz
+    - name: install editorconfig-checker
+      run: nix-env -iA editorconfig-checker -f '<nixpkgs>'
     - name: Checking EditorConfig
       run: |
-        cat "$HOME/changed_files" | nix-shell -p editorconfig-checker --run 'xargs -r editorconfig-checker -disable-indent-size'
+        cat "$HOME/changed_files" | xargs -r editorconfig-checker -disable-indent-size
     - if: ${{ failure() }}
       run: |
         echo "::error :: Hey! It looks like your changes don't follow our editorconfig settings. Read https://editorconfig.org/#download to configure your editor so you never see this error again."

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

.github/workflows/manual-nixpkgs.yml

@@ -8,7 +8,6 @@ on:
       - master
     paths:
       - 'doc/**'
-      - 'lib/**'
 
 jobs:
   nixpkgs:
@@ -19,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@v20
+      - 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@v20
+      - uses: cachix/install-nix-action@v18
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true
@@ -54,7 +54,7 @@ jobs:
       # less noisy until all nixpkgs pull requests have stopped using
       # docbook for option docs.
       - name: Comment on failure
-        uses: peter-evans/create-or-update-comment@v3
+        uses: peter-evans/create-or-update-comment@v2
         if: ${{ failure() && steps.check.conclusion == 'failure' }}
         with:
           issue-number: 189318

.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
@@ -51,7 +55,7 @@ jobs:
           github_token: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Comment on failure
-        uses: peter-evans/create-or-update-comment@v3
+        uses: peter-evans/create-or-update-comment@v2
         if: ${{ failure() }}
         with:
           issue-number: 105153

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

@@ -49,7 +49,7 @@ jobs:
           github_token: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Comment on failure
-        uses: peter-evans/create-or-update-comment@v3
+        uses: peter-evans/create-or-update-comment@v2
         if: ${{ failure() }}
         with:
           issue-number: 105153

.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
+      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@v20
+      - 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]"
@@ -36,33 +34,21 @@ jobs:
             --argstr keep-going true \
             --argstr max-workers 2 \
             --argstr path terraform-providers
-      - name: get failed updates
-        run: |
-          echo 'FAILED<<EOF' >> $GITHUB_ENV
-          git ls-files --others >> $GITHUB_ENV
-          echo 'EOF' >> $GITHUB_ENV
-      # cleanup logs of failed updates so they aren't included in the PR
       - name: clean repo
         run: |
           git clean -f
       - name: create PR
-        uses: peter-evans/create-pull-request@v5
+        uses: peter-evans/create-pull-request@v4
         with:
           body: |
             Automatic update by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action.
 
             https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}
 
-            These providers failed to update:
-            ```
-            ${{ env.FAILED }}
-            ```
-
             Check that all providers build with:
             ```
             @ofborg build terraform.full
             ```
-            If there is more than ten commits in the PR `ofborg` won't build it automatically and you will need to use the above command.
           branch: terraform-providers-update
           delete-branch: false
           title: ${{ steps.setup.outputs.title }}

.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,15 +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).
-  * Aim to inform while avoiding subjective language.
+  * 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).
@@ -57,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
@@ -116,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
@@ -129,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/.gitignore

@@ -6,6 +6,3 @@ functions/library/locations.xml
 highlightjs
 manual-full.xml
 out
-result
-result-*
-media

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
@@ -19,9 +19,6 @@ pandoc_flags = --extract-media=$(pandoc_media_dir) \
 .PHONY: all
 all: validate format out/html/index.html out/epub/manual.epub
 
-.PHONY: render-md
-render-md: ${MD_TARGETS}
-
 .PHONY: debug
 debug:
 	nix-shell --run "xmloscopy --docbook5 ./manual.xml ./manual-full.xml"

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 = lib.importJSON (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

@@ -3,7 +3,7 @@
 Building software with Nix often requires downloading source code and other files from the internet.
 `nixpkgs` provides *fetchers* for different protocols and services. Fetchers are functions that simplify downloading files.
 
-## Caveats {#chap-pkgs-fetchers-caveats}
+## Caveats
 
 Fetchers create [fixed output derivations](https://nixos.org/manual/nix/stable/#fixed-output-drvs) from downloaded files.
 Nix can reuse the downloaded files via the hash of the resulting derivation.
@@ -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";
   };
 }
 ```
@@ -71,24 +71,23 @@ The main difference between `fetchurl` and `fetchzip` is in how they store the c
 
 - `relative`: Similar to using `git-diff`'s `--relative` flag, only keep changes inside the specified directory, making paths relative to it.
 - `stripLen`: Remove the first `stripLen` components of pathnames in the patch.
-- `decode`: Pipe the downloaded data through this command before processing it as a patch.
 - `extraPrefix`: Prefix pathnames by this string.
 - `excludes`: Exclude files matching these patterns (applies after the above arguments).
 - `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.
 
@@ -105,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.
 
@@ -157,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 {#sec-pkgs-binary-cache-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 {#ssec-pkgs-dockerTools-buildNixShellImage-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 {#ssec-pkgs-dockerTools-buildNixShellImage-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,108 +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 {#sec-make-disk-image-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 {#sec-make-disk-image-features-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 {#sec-make-disk-image-features-full-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 {#sec-make-disk-image-features-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 {#sec-make-disk-image-usage}
-
-To produce a Nix-store only image:
-```nix
-let
-  pkgs = import <nixpkgs> {};
-  lib = pkgs.lib;
-  make-disk-image = import <nixpkgs/nixos/lib/make-disk-image.nix>;
-in
-  make-disk-image {
-    inherit pkgs lib;
-    config = {};
-    additionalPaths = [ ];
-    format = "qcow2";
-    onlyNixStore = true;
-    partitionTableType = "none";
-    installBootLoader = false;
-    touchEFIVars = false;
-    diskSize = "auto";
-    additionalSpace = "0M"; # Defaults to 512M.
-    copyChannel = false;
-  }
-```
-
-Some arguments can be left out, they are shown explicitly for the sake of the example.
-
-Building this derivation will provide a QCOW2 disk image containing only the Nix store and its registration information.
-
-To produce a NixOS installation image disk with UEFI and bootloader installed:
-```nix
-let
-  pkgs = import <nixpkgs> {};
-  lib = pkgs.lib;
-  make-disk-image = import <nixpkgs/nixos/lib/make-disk-image.nix>;
-  evalConfig = import <nixpkgs/nixos/lib/eval-config.nix>;
-in
-  make-disk-image {
-    inherit pkgs lib;
-    config = evalConfig {
-      modules = [
-        {
-          fileSystems."/" = { device = "/dev/vda"; fsType = "ext4"; autoFormat = true; };
-          boot.grub.device = "/dev/vda";
-        }
-      ];
-    };
-    format = "qcow2";
-    onlyNixStore = false;
-    partitionTableType = "legacy+gpt";
-    installBootLoader = true;
-    touchEFIVars = true;
-    diskSize = "auto";
-    additionalSpace = "0M"; # Defaults to 512M.
-    copyChannel = false;
-    memSize = 2048; # Qemu VM memory size in megabytes. Defaults to 1024M.
-  }
-```
-
-

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

@@ -6,8 +6,5 @@
   This chapter describes several special builders.
  </para>
  <xi:include href="special/fhs-environments.section.xml" />
- <xi:include href="special/makesetuphook.section.xml" />
  <xi:include href="special/mkshell.section.xml" />
- <xi:include href="special/darwin-builder.section.xml" />
- <xi:include href="special/vm-tools.section.xml" />
 </chapter>

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

@@ -1,149 +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
-```
-
-## Example flake usage
-
-```
-{
-  inputs = {
-    nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-22.11-darwin";
-    darwin.url = "github:lnl7/nix-darwin/master";
-    darwin.inputs.nixpkgs.follows = "nixpkgs";
-  };
-
-  outputs = { self, darwin, nixpkgs, ... }@inputs:
-  let
-
-    inherit (darwin.lib) darwinSystem;
-    system = "aarch64-darwin";
-    pkgs = nixpkgs.legacyPackages."${system}";
-    linuxSystem = builtins.replaceStrings [ "darwin" ] [ "linux" ] system;
-
-    darwin-builder = nixpkgs.lib.nixosSystem {
-      system = linuxSystem;
-      modules = [
-        "${nixpkgs}/nixos/modules/profiles/macos-builder.nix"
-        { virtualisation.host.pkgs = pkgs; }
-      ];
-    };
-  in {
-
-    darwinConfigurations = {
-      machine1 = darwinSystem {
-        inherit system;
-        modules = [
-          {
-            nix.distributedBuilds = true;
-            nix.buildMachines = [{
-              hostName = "ssh://builder@localhost";
-              system = linuxSystem;
-              maxJobs = 4;
-              supportedFeatures = [ "kvm" "benchmark" "big-parallel" ];
-            }];
-
-            launchd.daemons.darwin-builder = {
-              command = "${darwin-builder.config.system.build.macos-builder-installer}/bin/create-builder";
-              serviceConfig = {
-                KeepAlive = true;
-                RunAtLoad = true;
-                StandardOutPath = "/var/log/darwin-builder.log";
-                StandardErrorPath = "/var/log/darwin-builder.log";
-              };
-            };
-          }
-        ];
-      };
-    };
-
-  };
-}
-```
-
-## Reconfiguring the builder
-
-Initially you should not change the builder configuration else you will not be
-able to use the binary cache. However, after you have the builder running locally
-you may use it to build a modified builder with additional storage or memory.
-
-To do this, you just need to set the `virtualisation.darwin-builder.*` parameters as
-in the example below and rebuild.
-
-```
-    darwin-builder = nixpkgs.lib.nixosSystem {
-      system = linuxSystem;
-      modules = [
-        "${nixpkgs}/nixos/modules/profiles/macos-builder.nix"
-        {
-          virtualisation.host.pkgs = pkgs;
-          virtualisation.darwin-builder.diskSize = 5120;
-          virtualisation.darwin-builder.memorySize = 1024;
-          virtualisation.darwin-builder.hostPort = 33022;
-          virtualisation.darwin-builder.workingDirectory = "/var/lib/darwin-builder";
-        }
-      ];
-```
-
-You may make any other changes to your VM in this attribute set. For example,
-you could enable Docker or X11 forwarding to your Darwin host.
-

doc/builders/special/fhs-environments.section.md

@@ -1,6 +1,6 @@
-# buildFHSEnv {#sec-fhs-environments}
+# buildFHSUserEnv {#sec-fhs-environments}
 
-`buildFHSEnv` provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root with bound `/nix/store`, so its footprint in terms of disk space needed is quite small. This allows one to run software which is hard or unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries. It uses Linux namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without root user rights requirement. Accepted arguments are:
+`buildFHSUserEnv` provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root with bound `/nix/store`, so its footprint in terms of disk space needed is quite small. This allows one to run software which is hard or unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries. It uses Linux namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without root user rights requirement. Accepted arguments are:
 
 - `name`
         Environment name.
@@ -26,7 +26,7 @@ One can create a simple environment using a `shell.nix` like that:
 ```nix
 { pkgs ? import <nixpkgs> {} }:
 
-(pkgs.buildFHSEnv {
+(pkgs.buildFHSUserEnv {
   name = "simple-x11-env";
   targetPkgs = pkgs: (with pkgs;
     [ udev

doc/builders/special/makesetuphook.section.md

@@ -1,37 +0,0 @@
-# pkgs.makeSetupHook {#sec-pkgs.makeSetupHook}
-
-`pkgs.makeSetupHook` is a builder that produces hooks that go in to `nativeBuildInputs`
-
-## Usage {#sec-pkgs.makeSetupHook-usage}
-
-```nix
-pkgs.makeSetupHook {
-  name = "something-hook";
-  propagatedBuildInputs = [ pkgs.commandsomething ];
-  depsTargetTargetPropagated = [ pkgs.libsomething ];
-} ./script.sh
-```
-
-#### setup hook that depends on the hello package and runs hello and @shell@ is substituted with path to bash {#sec-pkgs.makeSetupHook-usage-example}
-
-```nix
-pkgs.makeSetupHook {
-    name = "run-hello-hook";
-    propagatedBuildInputs = [ pkgs.hello ];
-    substitutions = { shell = "${pkgs.bash}/bin/bash"; };
-    passthru.tests.greeting = callPackage ./test { };
-    meta.platforms = lib.platforms.linux;
-} (writeScript "run-hello-hook.sh" ''
-    #!@shell@
-    hello
-'')
-```
-
-## Attributes {#sec-pkgs.makeSetupHook-attributes}
-
-* `name` Set the name of the hook.
-* `propagatedBuildInputs` Runtime dependencies (such as binaries) of the hook.
-* `depsTargetTargetPropagated` Non-binary dependencies.
-* `meta`
-* `passthru`
-* `substitutions` Variables for `substituteAll`

doc/builders/special/mkshell.section.md

@@ -20,7 +20,7 @@ pkgs.mkShell {
 }
 ```
 
-## Attributes {#sec-pkgs-mkShell-attributes}
+## Attributes
 
 * `name` (default: `nix-shell`). Set the name of the derivation.
 * `packages` (default: `[]`). Add executable packages to the `nix-shell` environment.
@@ -29,7 +29,7 @@ pkgs.mkShell {
 
 ... all the attributes of `stdenv.mkDerivation`.
 
-## Building the shell {#sec-pkgs-mkShell-building}
+## Building the shell
 
 This derivation output will contain a text file that contains a reference to
 all the build inputs. This is useful in CI where we want to make sure that

doc/builders/special/vm-tools.section.md

@@ -1,148 +0,0 @@
-# vmTools {#sec-vm-tools}
-
-A set of VM related utilities, that help in building some packages in more advanced scenarios.
-
-## `vmTools.createEmptyImage` {#vm-tools-createEmptyImage}
-
-A bash script fragment that produces a disk image at `destination`.
-
-### Attributes
-
-* `size`. The disk size, in MiB.
-* `fullName`. Name that will be written to `${destination}/nix-support/full-name`.
-* `destination` (optional, default `$out`). Where to write the image files.
-
-## `vmTools.runInLinuxVM` {#vm-tools-runInLinuxVM}
-
-Run a derivation in a Linux virtual machine (using Qemu/KVM).
-By default, there is no disk image; the root filesystem is a `tmpfs`, and the Nix store is shared with the host (via the [9P protocol](https://wiki.qemu.org/Documentation/9p#9p_Protocol)).
-Thus, any pure Nix derivation should run unmodified.
-
-If the build fails and Nix is run with the `-K/--keep-failed` option, a script `run-vm` will be left behind in the temporary build directory that allows you to boot into the VM and debug it interactively.
-
-### Attributes
-
-* `preVM` (optional). Shell command to be evaluated *before* the VM is started (i.e., on the host).
-* `memSize` (optional, default `512`). The memory size of the VM in MiB.
-* `diskImage` (optional). A file system image to be attached to `/dev/sda`.
-  Note that currently we expect the image to contain a filesystem, not a full disk image with a partition table etc.
-
-### Examples
-
-Build the derivation hello inside a VM:
-```nix
-{ pkgs }: with pkgs; with vmTools;
-runInLinuxVM hello
-```
-
-Build inside a VM with extra memory:
-```nix
-{ pkgs }: with pkgs; with vmTools;
-runInLinuxVM (hello.overrideAttrs (_: { memSize = 1024; }))
-```
-
-Use VM with a disk image (implicitly sets `diskImage`, see [`vmTools.createEmptyImage`](#vm-tools-createEmptyImage)):
-```nix
-{ pkgs }: with pkgs; with vmTools;
-runInLinuxVM (hello.overrideAttrs (_: {
-  preVM = createEmptyImage {
-    size = 1024;
-    fullName = "vm-image";
-  };
-}))
-```
-
-## `vmTools.extractFs` {#vm-tools-extractFs}
-
-Takes a file, such as an ISO, and extracts its contents into the store.
-
-### Attributes
-
-* `file`. Path to the file to be extracted.
-  Note that currently we expect the image to contain a filesystem, not a full disk image with a partition table etc.
-* `fs` (optional). Filesystem of the contents of the file.
-
-### Examples
-
-Extract the contents of an ISO file:
-```nix
-{ pkgs }: with pkgs; with vmTools;
-extractFs { file = ./image.iso; }
-```
-
-## `vmTools.extractMTDfs` {#vm-tools-extractMTDfs}
-
-Like [](#vm-tools-extractFs), but it makes use of a [Memory Technology Device (MTD)](https://en.wikipedia.org/wiki/Memory_Technology_Device).
-
-## `vmTools.runInLinuxImage` {#vm-tools-runInLinuxImage}
-
-Like [](#vm-tools-runInLinuxVM), but instead of using `stdenv` from the Nix store, run the build using the tools provided by `/bin`, `/usr/bin`, etc. from the specified filesystem image, which typically is a filesystem containing a [FHS](https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard)-based Linux distribution.
-
-## `vmTools.makeImageTestScript` {#vm-tools-makeImageTestScript}
-
-Generate a script that can be used to run an interactive session in the given image.
-
-### Examples
-
-Create a script for running a Fedora 27 VM:
-```nix
-{ pkgs }: with pkgs; with vmTools;
-makeImageTestScript diskImages.fedora27x86_64
-```
-
-Create a script for running an Ubuntu 20.04 VM:
-```nix
-{ pkgs }: with pkgs; with vmTools;
-makeImageTestScript diskImages.ubuntu2004x86_64
-```
-
-## `vmTools.diskImageFuns` {#vm-tools-diskImageFuns}
-
-A set of functions that build a predefined set of minimal Linux distributions images.
-
-### Images
-
-* Fedora
-  * `fedora26x86_64`
-  * `fedora27x86_64`
-* CentOS
-  * `centos6i386`
-  * `centos6x86_64`
-  * `centos7x86_64`
-* Ubuntu
-  * `ubuntu1404i386`
-  * `ubuntu1404x86_64`
-  * `ubuntu1604i386`
-  * `ubuntu1604x86_64`
-  * `ubuntu1804i386`
-  * `ubuntu1804x86_64`
-  * `ubuntu2004i386`
-  * `ubuntu2004x86_64`
-  * `ubuntu2204i386`
-  * `ubuntu2204x86_64`
-* Debian
-  * `debian10i386`
-  * `debian10x86_64`
-  * `debian11i386`
-  * `debian11x86_64`
-
-### Attributes
-
-* `size` (optional, defaults to `4096`). The size of the image, in MiB.
-* `extraPackages` (optional). A list names of additional packages from the distribution that should be included in the image.
-
-### Examples
-
-8GiB image containing Firefox in addition to the default packages:
-```nix
-{ pkgs }: with pkgs; with vmTools;
-diskImageFuns.ubuntu2004x86_64 { extraPackages = [ "firefox" ]; size = 8192; }
-```
-
-## `vmTools.diskImageExtraFuns` {#vm-tools-diskImageExtraFuns}
-
-Shorthand for `vmTools.diskImageFuns.<attr> { extraPackages = ... }`.
-
-## `vmTools.diskImages` {#vm-tools-diskImages}
-
-Shorthand for `vmTools.diskImageFuns.<attr> { }`.

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=";
 };
 ```
 
@@ -178,7 +165,7 @@ letting NixOS invoke Nixpkgs anew.
 If a test machine needs to set NixOS options under `nixpkgs`, it must set only the
 `nixpkgs.pkgs` option.
 
-### Parameter {#tester-nixosTest-parameter}
+### Parameter
 
 A [NixOS VM test network](https://nixos.org/nixos/manual/index.html#sec-nixos-tests), or path to it. Example:
 
@@ -200,7 +187,7 @@ A [NixOS VM test network](https://nixos.org/nixos/manual/index.html#sec-nixos-te
 }
 ```
 
-### Result {#tester-nixosTest-result}
+### Result
 
 A derivation that runs the VM test.
 

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}
 
@@ -290,7 +290,7 @@ Other examples of reasons are:
 - The previous download links were all broken
 - Crash when starting on some X11 systems
 
-#### Acceptable backport criteria {#acceptable-backport-criteria}
+#### Acceptable backport criteria
 
 The stable branch does have some changes which cannot be backported. Most notable are breaking changes. The desire is to have stable users be uninterrupted when updating packages.
 

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,16 +15,12 @@ in pkgs.stdenv.mkDerivation {
     xmlformat
   ];
 
-  src = pkgs.nix-gitignore.gitignoreSource [] ./.;
+  src = lib.cleanSource ./.;
 
   postPatch = ''
     ln -s ${doc-support} ./doc-support/result
   '';
 
-  preBuild = ''
-    make -j$NIX_BUILD_CORES render-md
-  '';
-
   installPhase = ''
     dest="$out/share/doc/nixpkgs"
     mkdir -p "$(dirname "$dest")"
@@ -39,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" ''
@@ -45,10 +30,7 @@ let
   # NB: This file describes the Nixpkgs manual, which happens to use module
   #     docs infra originally developed for NixOS.
   optionsDoc = pkgs.nixosOptionsDoc {
-    inherit (pkgs.lib.evalModules {
-      modules = [ ../../pkgs/top-level/config.nix ];
-      class = "nixpkgsConfig";
-    }) options;
+    inherit (pkgs.lib.evalModules { modules = [ ../../pkgs/top-level/config.nix ]; }) options;
     documentType = "none";
     transformOptions = opt:
       opt // {
@@ -78,7 +60,7 @@ in pkgs.runCommand "doc-support" {}
     ln -s ${epub-xsl} ./epub.xsl
     ln -s ${xhtml-xsl} ./xhtml.xsl
 
-    ln -s ${./xmlformat.conf} ./xmlformat.conf
+    ln -s ${../../nixos/doc/xmlformat.conf} ./xmlformat.conf
     ln -s ${pkgs.documentation-highlighter} ./highlightjs
 
     echo -n "${version}" > ./version

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.rev or "master");
+  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 = "...";
     };
   })
 ])
@@ -216,7 +216,7 @@ you can test whether it builds correctly by writing in a comment:
 @ofborg build agdaPackages.iowa-stdlib
 ```
 
-### Maintaining Agda packages {#agda-maintaining-packages}
+### Maintaining Agda packages
 
 As mentioned before, the aim is to have a compatible, and up-to-date package set.
 These two conditions sometimes exclude each other:

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

@@ -14,7 +14,7 @@ nixpkgs follows the [official elixir deprecation schedule](https://hexdocs.pm/el
 
 All BEAM-related expressions are available via the top-level `beam` attribute, which includes:
 
-- `interpreters`: a set of compilers running on the BEAM, including multiple Erlang/OTP versions (`beam.interpreters.erlang_22`, etc), Elixir (`beam.interpreters.elixir`) and LFE (Lisp Flavoured Erlang) (`beam.interpreters.lfe`).
+- `interpreters`: a set of compilers running on the BEAM, including multiple Erlang/OTP versions (`beam.interpreters.erlangR22`, etc), Elixir (`beam.interpreters.elixir`) and LFE (Lisp Flavoured Erlang) (`beam.interpreters.lfe`).
 
 - `packages`: a set of package builders (Mix and rebar3), each compiled with a specific Erlang/OTP version, e.g. `beam.packages.erlang22`.
 
@@ -22,7 +22,7 @@ The default Erlang compiler, defined by `beam.interpreters.erlang`, is aliased a
 
 To create a package builder built with a custom Erlang version, use the lambda, `beam.packagesWith`, which accepts an Erlang/OTP derivation and produces a package builder similar to `beam.packages.erlang`.
 
-Many Erlang/OTP distributions available in `beam.interpreters` have versions with ODBC and/or Java enabled or without wx (no observer support). For example, there's `beam.interpreters.erlang_22_odbc_javac`, which corresponds to `beam.interpreters.erlang_22` and `beam.interpreters.erlang_22_nox`, which corresponds to `beam.interpreters.erlang_22`.
+Many Erlang/OTP distributions available in `beam.interpreters` have versions with ODBC and/or Java enabled or without wx (no observer support). For example, there's `beam.interpreters.erlangR22_odbc_javac`, which corresponds to `beam.interpreters.erlangR22` and `beam.interpreters.erlangR22_nox`, which corresponds to `beam.interpreters.erlangR22`.
 
 ## Build Tools {#build-tools}
 
@@ -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}
 
@@ -154,7 +154,7 @@ Here is how your `default.nix` file would look for a phoenix project.
 with import <nixpkgs> { };
 
 let
-  # beam.interpreters.erlang_23 is available if you need a particular version
+  # beam.interpreters.erlangR23 is available if you need a particular version
   packages = beam.packagesWith beam.interpreters.erlang;
 
   pname = "your_project";
@@ -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";
   };
@@ -274,25 +273,25 @@ Usually, we need to create a `shell.nix` file and do our development inside of t
 
 with pkgs;
 let
-  elixir = beam.packages.erlang_24.elixir_1_12;
+  elixir = beam.packages.erlangR24.elixir_1_12;
 in
 mkShell {
   buildInputs = [ elixir ];
 }
 ```
 
-### Using an overlay {#beam-using-overlays}
+### 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` {#beam-using-overlays-shell.nix}
+#### `shell.nix`
 
 ```nix
 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/chicken.section.md

@@ -4,7 +4,7 @@
 [R⁵RS](https://schemers.org/Documents/Standards/R5RS/HTML/)-compliant Scheme
 compiler. It includes an interactive mode and a custom package format, "eggs".
 
-## Using Eggs {#sec-chicken-using}
+## Using Eggs
 
 Eggs described in nixpkgs are available inside the
 `chickenPackages.chickenEggs` attrset. Including an egg as a build input is
@@ -22,7 +22,7 @@ might write:
 Both `chicken` and its eggs have a setup hook which configures the environment
 variables `CHICKEN_INCLUDE_PATH` and `CHICKEN_REPOSITORY_PATH`.
 
-## Updating Eggs {#sec-chicken-updating-eggs}
+## Updating Eggs
 
 nixpkgs only knows about a subset of all published eggs. It uses
 [egg2nix](https://github.com/the-kenny/egg2nix) to generate a
@@ -36,7 +36,7 @@ $ cd pkgs/development/compilers/chicken/5/
 $ egg2nix eggs.scm > eggs.nix
 ```
 
-## Adding Eggs {#sec-chicken-adding-eggs}
+## Adding Eggs
 
 When we run `egg2nix`, we obtain one collection of eggs with
 mutually-compatible versions. This means that when we add new eggs, we may

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),
@@ -37,7 +37,7 @@ The recommended way of defining a derivation for a Coq library, is to use the `c
 * `buildInputs` (optional), is a list of libraries and dependencies that are required to build and run the current derivation, in addition to the default one `[ coq ]`,
 * `extraBuildInputs` (optional, deprecated), an additional list of derivation to add to `buildInputs`,
 * `overrideBuildInputs` (optional) replaces the default list of derivation to which `buildInputs` and `extraBuildInputs` adds extras elements,
-* `propagatedBuildInputs` (optional) is passed as is to `mkDerivation`, we recommend to use this for Coq libraries and Coq plugin dependencies, as this makes sure the paths of the compiled libraries and plugins will always be added to the build environments of subsequent derivation, which is necessary for Coq packages to work correctly,
+* `propagatedBuildInputs` (optional) is passed as is to `mkDerivation`, we recommend to use this for Coq libraries and Coq plugin dependencies, as this makes sure the paths of the compiled libraries and plugins will always be added to the build environements of subsequent derivation, which is necessary for Coq packages to work correctly,
 * `mlPlugin` (optional, defaults to `false`). Some extensions (plugins) might require OCaml and sometimes other OCaml packages. Standard dependencies can be added by setting the current option to `true`. For a finer grain control, the `coq.ocamlPackages` attribute can be used in `nativeBuildInputs`, `buildInputs`, and `propagatedBuildInputs` to depend on the same package set Coq was built against.
 * `useDuneifVersion` (optional, default to `(x: false)` uses Dune to build the package if the provided predicate evaluates to true on the version, e.g. `useDuneifVersion = versions.isGe "1.1"`  will use dune if the version of the package is greater or equal to `"1.1"`,
 * `useDune` (optional, defaults to `false`) uses Dune to build the package if set to true, the presence of this attribute overrides the behavior of the previous one.

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-quickstart}
-
-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` {#cuelang-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

@@ -11,7 +11,7 @@ with import <nixpkgs> {};
 mkShell {
   name = "dotnet-env";
   packages = [
-    dotnet-sdk
+    dotnet-sdk_3
   ];
 }
 ```
@@ -27,57 +27,36 @@ mkShell {
   name = "dotnet-env";
   packages = [
     (with dotnetCorePackages; combinePackages [
-      sdk_6_0
-      sdk_7_0
+      sdk_3_1
+      sdk_5_0
     ])
   ];
 }
 ```
 
-This will produce a dotnet installation that has the dotnet 6.0 7.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
-.NET SDK:
- Version:   7.0.202
- Commit:    6c74320bc3
+.NET Core SDK (reflecting any global.json):
+ Version:   3.1.101
+ Commit:    b377529961
 
-Środowisko uruchomieniowe:
- OS Name:     nixos
- OS Version:  23.05
- OS Platform: Linux
- RID:         linux-x64
- Base Path:   /nix/store/n2pm44xq20hz7ybsasgmd7p3yh31gnh4-dotnet-sdk-7.0.202/sdk/7.0.202/
+...
 
-Host:
-  Version:      7.0.4
-  Architecture: x64
-  Commit:       0a396acafe
+.NET Core SDKs installed:
+  2.1.803 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/sdk]
+  3.0.102 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/sdk]
+  3.1.101 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/sdk]
 
-.NET SDKs installed:
-  6.0.407 [/nix/store/3b19303vwrhv0xxz1hg355c7f2hgxxgd-dotnet-core-combined/sdk]
-  7.0.202 [/nix/store/3b19303vwrhv0xxz1hg355c7f2hgxxgd-dotnet-core-combined/sdk]
-
-.NET runtimes installed:
-  Microsoft.AspNetCore.App 6.0.15 [/nix/store/3b19303vwrhv0xxz1hg355c7f2hgxxgd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
-  Microsoft.AspNetCore.App 7.0.4 [/nix/store/3b19303vwrhv0xxz1hg355c7f2hgxxgd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
-  Microsoft.NETCore.App 6.0.15 [/nix/store/3b19303vwrhv0xxz1hg355c7f2hgxxgd-dotnet-core-combined/shared/Microsoft.NETCore.App]
-  Microsoft.NETCore.App 7.0.4 [/nix/store/3b19303vwrhv0xxz1hg355c7f2hgxxgd-dotnet-core-combined/shared/Microsoft.NETCore.App]
-
-Other architectures found:
-  None
-
-Environment variables:
-  Not set
-
-global.json file:
-  Not found
-
-Learn more:
-  https://aka.ms/dotnet/info
-
-Download .NET:
-  https://aka.ms/dotnet/download
+.NET Core runtimes installed:
+  Microsoft.AspNetCore.All 2.1.15 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.All]
+  Microsoft.AspNetCore.App 2.1.15 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
+  Microsoft.AspNetCore.App 3.0.2 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
+  Microsoft.AspNetCore.App 3.1.1 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
+  Microsoft.NETCore.App 2.1.15 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.NETCore.App]
+  Microsoft.NETCore.App 3.0.2 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.NETCore.App]
+  Microsoft.NETCore.App 3.1.1 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.NETCore.App]
 ```
 
 ## dotnet-sdk vs dotnetCorePackages.sdk {#dotnet-sdk-vs-dotnetcorepackages.sdk}
@@ -109,7 +88,7 @@ To package Dotnet applications, you can use `buildDotnetModule`. This has simila
 * `runtimeDeps` is used to wrap libraries into `LD_LIBRARY_PATH`. This is how dotnet usually handles runtime dependencies.
 * `buildType` is used to change the type of build. Possible values are `Release`, `Debug`, etc. By default, this is set to `Release`.
 * `selfContainedBuild` allows to enable the [self-contained](https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained) build flag. By default, it is set to false and generated applications have a dependency on the selected dotnet runtime. If enabled, the dotnet runtime is bundled into the executable and the built app has no dependency on Dotnet.
-* `dotnet-sdk` is useful in cases where you need to change what dotnet SDK is being used. You can also set this to the result of `dotnetSdkPackages.combinePackages`, if the project uses multiple SDKs to build.
+* `dotnet-sdk` is useful in cases where you need to change what dotnet SDK is being used.
 * `dotnet-runtime` is useful in cases where you need to change what dotnet runtime is being used. This can be either a regular dotnet runtime, or an aspnetcore.
 * `dotnet-test-sdk` is useful in cases where unit tests expect a different dotnet SDK. By default, this is set to the `dotnet-sdk` attribute.
 * `testProjectFile` is useful in cases where the regular project file does not contain the unit tests. It gets restored and build, but not installed. You may need to regenerate your nuget lockfile after setting this.
@@ -140,8 +119,9 @@ in buildDotnetModule rec {
 
   projectReferences = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure.
 
-  dotnet-sdk = dotnetCorePackages.sdk_6.0;
-  dotnet-runtime = dotnetCorePackages.runtime_6_0;
+  dotnet-sdk = dotnetCorePackages.sdk_3_1;
+  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

@@ -56,11 +56,11 @@ See the `zlib` example:
 
     zlib = (pkgs.zlib.override {
       stdenv = pkgs.emscriptenStdenv;
-    }).overrideAttrs
+    }).overrideDerivation
     (old: rec {
       buildInputs = old.buildInputs ++ [ pkg-config ];
       # we need to reset this setting!
-      env = (old.env or { }) // { NIX_CFLAGS_COMPILE = ""; };
+      NIX_CFLAGS_COMPILE="";
       configurePhase = ''
         # FIXME: Some tests require writing at $HOME
         HOME=$TMPDIR
@@ -121,7 +121,7 @@ This `xmlmirror` example features a emscriptenPackage which is defined completel
       src = pkgs.fetchgit {
         url = "https://gitlab.com/odfplugfest/xmlmirror.git";
         rev = "4fd7e86f7c9526b8f4c1733e5c8b45175860a8fd";
-        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}
 
@@ -116,6 +116,10 @@ For convenience, it also adds `dconf.lib` for a GIO module implementing a GSetti
 
 - []{#ssec-gnome-hooks-gobject-introspection} `gobject-introspection` setup hook populates `GI_TYPELIB_PATH` variable with `lib/girepository-1.0` directories of dependencies, which is then added to wrapper by `wrapGAppsHook`. It also adds `share` directories of dependencies to `XDG_DATA_DIRS`, which is intended to promote GIR files but it also [pollutes the closures](https://github.com/NixOS/nixpkgs/issues/32790) of packages using `wrapGAppsHook`.
 
+  ::: {.warning}
+  The setup hook [currently](https://github.com/NixOS/nixpkgs/issues/56943) does not work in expressions with `strictDeps` enabled, like Python packages. In those cases, you will need to disable it with `strictDeps = false;`.
+  :::
+
 - []{#ssec-gnome-hooks-gst-grl-plugins} Setup hooks of `gst_all_1.gstreamer` and `grilo` will populate the `GST_PLUGIN_SYSTEM_PATH_1_0` and `GRL_PLUGIN_PATH` variables, respectively, which will then be added to the wrapper by `wrapGAppsHook`.
 
 You can also pass additional arguments to `makeWrapper` using `gappsWrapperArgs` in `preFixup` hook:

doc/languages-frameworks/go.section.md

@@ -11,16 +11,8 @@ 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.
-- `modPostBuild`: Shell commands to run after the build of the go-modules executes `go mod vendor`, and before calculating fixed output derivation's `vendorHash` (or `vendorSha256`). Note that if you change this attribute, you need to update `vendorHash` (or `vendorSha256`) attribute.
 
 ```nix
 pet = buildGoModule rec {
@@ -31,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=";
@@ -67,7 +59,7 @@ deis = buildGoPackage rec {
     owner = "deis";
     repo = "deis";
     rev = "v${version}";
-    hash = "sha256-XCPD4LNWtAd8uz7zyCLRfT8rzxycIUmTACjU03GnaeM=";
+    sha256 = "1qv9lxqx7m18029lj8cw3k7jngvxs4iciwrypdy0gd2nnghc68sw";
   };
 
   goDeps = ./deps.nix;
@@ -84,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";
     };
   }
   {
@@ -97,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";
     };
   }
 ]
@@ -115,16 +107,7 @@ done
 
 ## Attributes used by the builders {#ssec-go-common-attributes}
 
-Many attributes [controlling the build phase](#variables-controlling-the-build-phase) are respected by both `buildGoModule` and `buildGoPackage`. Note that `buildGoModule` reads the following attributes also when building the `vendor/` go-modules fixed output derivation as well:
-
-- [`sourceRoot`](#var-stdenv-sourceRoot)
-- [`prePatch`](#var-stdenv-prePatch)
-- [`patches`](#var-stdenv-patches)
-- [`patchFlags`](#var-stdenv-patchFlags)
-- [`postPatch`](#var-stdenv-postPatch)
-- [`preBuild`](#var-stdenv-preBuild)
-
-In addition to the above attributes, and the many more variables respected also by `stdenv.mkDerivation`, both `buildGoModule` and `buildGoPackage` respect Go-specific attributes that tweak them to behave slightly differently:
+Both `buildGoModule` and `buildGoPackage` can be tweaked to behave slightly differently, if the following attributes are used:
 
 ### `ldflags` {#var-go-ldflags}
 

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" />
@@ -25,7 +24,6 @@
  <xi:include href="ios.section.xml" />
  <xi:include href="java.section.xml" />
  <xi:include href="javascript.section.xml" />
- <xi:include href="lisp.section.xml" />
  <xi:include href="lua.section.xml" />
  <xi:include href="maven.section.xml" />
  <xi:include href="nim.section.xml" />
@@ -33,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

@@ -6,16 +6,16 @@ This contains instructions on how to package javascript applications.
 
 The various tools available will be listed in the [tools-overview](#javascript-tools-overview). Some general principles for packaging will follow. Finally some tool specific instructions will be given.
 
-## Getting unstuck / finding code examples {#javascript-finding-examples}
+## Getting unstuck / finding code examples
 
 If you find you are lacking inspiration for packing javascript applications, the links below might prove useful. Searching online for prior art can be helpful if you are running into solved problems.
 
-### Github {#javascript-finding-examples-github}
+### Github
 
 - Searching Nix files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+language%3ANix&type=code>
 - Searching just `flake.nix` files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+filename%3Aflake.nix&type=code>
 
-### Gitlab {#javascript-finding-examples-gitlab}
+### Gitlab
 
 - Searching Nix files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+extension%3Anix>
 - Searching just `flake.nix` files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+filename%3Aflake.nix>
@@ -105,7 +105,7 @@ After you have identified the correct system, you need to override your package
     });
 ```
 
-### Adding and Updating Javascript packages in nixpkgs {#javascript-adding-or-updating-packages}
+### Adding and Updating Javascript packages in nixpkgs
 
 To add a package from NPM to nixpkgs:
 
@@ -140,7 +140,7 @@ To update NPM packages in nixpkgs, run the same `generate.sh` script:
 ./pkgs/development/node-packages/generate.sh
 ```
 
-#### Git protocol error {#javascript-git-error}
+#### Git protocol error
 
 Some packages may have Git dependencies from GitHub specified with `git://`.
 GitHub has [disabled unecrypted Git connections](https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git), so you may see the following error when running the generate script:
@@ -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";
 
@@ -229,7 +228,7 @@ See `node2nix` [docs](https://github.com/svanderburg/node2nix) for more info.
 #### Pitfalls {#javascript-node2nix-pitfalls}
 
 - If upstream package.json does not have a "version" attribute, `node2nix` will crash. You will need to add it like shown in [the package.json section](#javascript-upstream-package-json).
-- `node2nix` has some [bugs](https://github.com/svanderburg/node2nix/issues/238) related to working with lock files from NPM distributed with `nodejs_16`.
+- `node2nix` has some [bugs](https://github.com/svanderburg/node2nix/issues/238) related to working with lock files from NPM distributed with `nodejs-16_x`.
 - `node2nix` does not like missing packages from NPM. If you see something like `Cannot resolve version: vue-loader-v16@undefined` then you might want to try another tool. The package might have been pulled off of NPM.
 
 ### yarn2nix {#javascript-yarn2nix}
@@ -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 = "....";
 };
 ```
 
@@ -288,7 +287,7 @@ configurePhase = ''
 This will generate a derivation including the `node_modules` directory.
 If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way.
 
-#### Overriding dependency behavior {#javascript-mkYarnPackage-overriding-dependencies}
+#### Overriding dependency behavior
 
 In the `mkYarnPackage` record the property `pkgConfig` can be used to override packages when you encounter problems building.
 
@@ -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/lisp.section.md

@@ -1,304 +0,0 @@
-# lisp-modules {#lisp}
-
-This document describes the Nixpkgs infrastructure for building Common Lisp
-libraries that use ASDF (Another System Definition Facility). It lives in
-`pkgs/development/lisp-modules`.
-
-## Overview {#lisp-overview}
-
-The main entry point of the API are the Common Lisp implementation packages
-(e.g. `abcl`, `ccl`, `clasp-common-lisp`, `clisp` `ecl`, `sbcl`)
-themselves. They have the `pkgs` and `withPackages` attributes, which can be
-used to discover available packages and to build wrappers, respectively.
-
-The `pkgs` attribute set contains packages that were automatically imported from
-Quicklisp, and any other manually defined ones. Not every package works for all
-the CL implementations (e.g. `nyxt` only makes sense for `sbcl`).
-
-The `withPackages` function is of primary utility. It is used to build runnable
-wrappers, with a pinned and pre-built ASDF FASL available in the `ASDF`
-environment variable, and `CL_SOURCE_REGISTRY`/`ASDF_OUTPUT_TRANSLATIONS`
-configured to find the desired systems on runtime.
-
-With a few exceptions, the primary thing that the infrastructure does is to run
-`asdf:load-system` for each system specified in the `systems` argument to
-`build-asdf-system`, and save the FASLs to the Nix store. Then, it makes these
-FASLs available to wrappers. Any other use-cases, such as producing SBCL
-executables with `sb-ext:save-lisp-and-die`, are achieved via overriding the
-`buildPhase` etc.
-
-In addition, Lisps have the `withOverrides` function, which can be used to
-substitute any package in the scope of their `pkgs`. This will be useful
-together with `overrideLispAttrs` when dealing with slashy ASDF systems, because
-they should stay in the main package and be build by specifying the `systems`
-argument to `build-asdf-system`.
-
-## The 90% use case example {#lisp-use-case-example}
-
-The most common way to use the library is to run ad-hoc wrappers like this:
-
-`nix-shell -p 'sbcl.withPackages (ps: with ps; [ alexandria ])'`
-
-Then, in a shell:
-
-```
-$ result/bin/sbcl
-* (load (sb-ext:posix-getenv "ASDF"))
-* (asdf:load-system 'alexandria)
-```
-
-Also one can create a `pkgs.mkShell` environment in `shell.nix`/`flake.nix`:
-
-```
-let
-  sbcl' = sbcl.withPackages (ps: [ ps.alexandria ]);
-in mkShell {
-  buildInputs = [ sbcl' ];
-}
-```
-
-Such a Lisp can be now used e.g. to compile your sources:
-
-```
-buildPhase = ''
-  ${sbcl'}/bin/sbcl --load my-build-file.lisp
-''
-```
-
-## Importing packages from Quicklisp {#lisp-importing-packages-from-quicklisp}
-
-The library is able to very quickly import all the packages distributed by
-Quicklisp by parsing its `releases.txt` and `systems.txt` files. These files are
-available from [http://beta.quicklisp.org/dist/quicklisp.txt].
-
-The import process is implemented in the `import` directory as Common Lisp
-functions in the `org.lispbuilds.nix` ASDF system. To run the script, one can
-execute `ql-import.lisp`:
-
-```
-nix-shell --run 'sbcl --script ql-import.lisp'
-```
-
-The script will:
-
-1. Download the latest Quicklisp `systems.txt` and `releases.txt` files
-2. Generate an SQLite database of all QL systems in `packages.sqlite`
-3. Generate an `imported.nix` file from the database
-
-The maintainer's job there is to:
-
-1. Re-run the `ql-import.lisp` script
-2. Add missing native dependencies in `ql.nix`
-3. For packages that still don't build, package them manually in `packages.nix`
-
-Also, the `imported.nix` file **must not be edited manually**! It should only be
-generated as described in this section.
-
-### Adding native dependencies {#lisp-quicklisp-adding-native-dependencies}
-
-The Quicklisp files contain ASDF dependency data, but don't include native
-library (CFFI) dependencies, and, in the case of ABCL, Java dependencies.
-
-The `ql.nix` file contains a long list of overrides, where these dependencies
-can be added.
-
-Packages defined in `packages.nix` contain these dependencies naturally.
-
-### Trusting `systems.txt` and `releases.txt` {#lisp-quicklisp-trusting}
-
-The previous implementation of `lisp-modules` didn't fully trust the Quicklisp
-data, because there were times where the dependencies specified were not
-complete, and caused broken builds. It instead used a `nix-shell` environment to
-discover real dependencies by using the ASDF APIs.
-
-The current implementation has chosen to trust this data, because it's faster to
-parse a text file than to build each system to generate its Nix file, and
-because that way packages can be mass-imported. Because of that, there may come
-a day where some packages will break, due to bugs in Quicklisp. In that case,
-the fix could be a manual override in `packages.nix` and `ql.nix`.
-
-A known fact is that Quicklisp doesn't include dependencies on slashy systems in
-its data. This is an example of a situation where such fixes were used, e.g. to
-replace the `systems` attribute of the affected packages. (See the definition of
-`iolib`).
-
-### Quirks {#lisp-quicklisp-quirks}
-
-During Quicklisp import:
-
-- `+` in names are converted to `_plus{_,}`: `cl+ssl`->`cl_plus_ssl`, `alexandria+`->`alexandria_plus`
-- `.` to `_dot_`: `iolib.base`->`iolib_dot_base`
-- names starting with a number have a `_` prepended (`3d-vectors`->`_3d-vectors`)
-- `_` in names is converted to `__` for reversibility
-
-
-## Defining packages manually inside Nixpkgs {#lisp-defining-packages-inside}
-
-New packages, that for some reason are not in Quicklisp, and so cannot be
-auto-imported, can be written in the `packages.nix` file.
-
-In that file, use the `build-asdf-system` function, which is a wrapper around
-`mkDerivation` for building ASDF systems. Various other hacks are present, such
-as `build-with-compile-into-pwd` for systems which create files during
-compilation.
-
-The `build-asdf-system` function is documented with comments in
-`nix-cl.nix`. Also, `packages.nix` is full of examples of how to use it.
-
-## Defining packages manually outside Nixpkgs {#lisp-defining-packages-outside}
-
-Lisp derivations (`abcl`, `sbcl` etc.) also export the `buildASDFSystem`
-function, which is the same as `build-asdf-system`, except for the `lisp`
-argument which is set to the given CL implementation.
-
-It can be used to define packages outside Nixpkgs, and, for example, add them
-into the package scope with `withOverrides` which will be discussed later on.
-
-### Including an external package in scope {#lisp-including-external-pkg-in-scope}
-
-A package defined outside Nixpkgs using `buildASDFSystem` can be woven into the
-Nixpkgs-provided scope like this:
-
-```
-let
-  alexandria = sbcl.buildASDFSystem rec {
-    pname = "alexandria";
-    version = "1.4";
-    src = fetchFromGitLab {
-      domain = "gitlab.common-lisp.net";
-      owner = "alexandria";
-      repo = "alexandria";
-      rev = "v${version}";
-      hash = "sha256-1Hzxt65dZvgOFIljjjlSGgKYkj+YBLwJCACi5DZsKmQ=";
-    };
-  };
-  sbcl' = sbcl.withOverrides (self: super: {
-    inherit alexandria;
-  });
-in sbcl'.pkgs.alexandria
-```
-
-## Overriding package attributes {#lisp-overriding-package-attributes}
-
-Packages export the `overrideLispAttrs` function, which can be used to build a
-new package with different parameters.
-
-Example of overriding `alexandria`:
-
-```
-sbcl.pkgs.alexandria.overrideLispAttrs (oldAttrs: rec {
-  version = "1.4";
-  src = fetchFromGitLab {
-    domain = "gitlab.common-lisp.net";
-    owner = "alexandria";
-    repo = "alexandria";
-    rev = "v${version}";
-    hash = "sha256-1Hzxt65dZvgOFIljjjlSGgKYkj+YBLwJCACi5DZsKmQ=";
-  };
-})
-```
-
-## Overriding packages in scope {#lisp-overriding-packages-in-scope}
-
-Packages can be woven into a new scope by using `withOverrides`:
-
-```
-let
-  sbcl' = sbcl.withOverrides (self: super: {
-    alexandria = super.alexandria.overrideLispAttrs (oldAttrs: rec {
-      pname = "alexandria";
-      version = "1.4";
-      src = fetchFromGitLab {
-        domain = "gitlab.common-lisp.net";
-        owner = "alexandria";
-        repo = "alexandria";
-        rev = "v${version}";
-        hash = "sha256-1Hzxt65dZvgOFIljjjlSGgKYkj+YBLwJCACi5DZsKmQ=";
-      };
-    });
-  });
-in builtins.elemAt sbcl'.pkgs.bordeaux-threads.lispLibs 0
-```
-
-### Dealing with slashy systems {#lisp-dealing-with-slashy-systems}
-
-Slashy (secondary) systems should not exist in their own packages! Instead, they
-should be included in the parent package as an extra entry in the `systems`
-argument to the `build-asdf-system`/`buildASDFSystem` functions.
-
-The reason is that ASDF searches for a secondary system in the `.asd` of the
-parent package. Thus, having them separate would cause either one of them not to
-load cleanly, because one will contains FASLs of itself but not the other, and
-vice versa.
-
-To package slashy systems, use `overrideLispAttrs`, like so:
-
-```
-ecl.pkgs.alexandria.overrideLispAttrs (oldAttrs: {
-  systems = oldAttrs.systems ++ [ "alexandria/tests" ];
-  lispLibs = oldAttrs.lispLibs ++ [ ecl.pkgs.rt ];
-})
-```
-
-See the respective section on using `withOverrides` for how to weave it back
-into `ecl.pkgs`.
-
-Note that sometimes the slashy systems might not only have more dependencies
-than the main one, but create a circular dependency between `.asd`
-files. Unfortunately, in this case an adhoc solution becomes necessary.
-
-## Building Wrappers {#lisp-building-wrappers}
-
-Wrappers can be built using the `withPackages` function of Common Lisp
-implementations (`abcl`, `ecl`, `sbcl` etc.):
-
-```
-sbcl.withPackages (ps: [ ps.alexandria ps.bordeaux-threads ])
-```
-
-Such a wrapper can then be executed like this:
-
-```
-result/bin/sbcl
-```
-
-### Loading ASDF {#lisp-loading-asdf}
-
-For best results, avoid calling `(require 'asdf)` When using the
-library-generated wrappers.
-
-Use `(load (ext:getenv "ASDF"))` instead, supplying your implementation's way of
-getting an environment variable for `ext:getenv`. This will load the
-(pre-compiled to FASL) Nixpkgs-provided version of ASDF.
-
-### Loading systems {#lisp-loading-systems}
-
-There, you can simply use `asdf:load-system`. This works by setting the right
-values for the `CL_SOURCE_REGISTRY`/`ASDF_OUTPUT_TRANSLATIONS` environment
-variables, so that systems are found in the Nix store and pre-compiled FASLs are
-loaded.
-
-## Adding a new Lisp {#lisp-adding-a-new-lisp}
-
-The function `wrapLisp` is used to wrap Common Lisp implementations. It adds the
-`pkgs`, `withPackages`, `withOverrides` and `buildASDFSystem` attributes to the
-derivation.
-
-`wrapLisp` takes these arguments:
-
-- `pkg`: the Lisp package
-- `faslExt`: Implementation-specific extension for FASL files
-- `program`: The name of executable file in `${pkg}/bin/` (Default: `pkg.pname`)
-- `flags`: A list of flags to always pass to `program` (Default: `[]`)
-- `asdf`: The ASDF version to use (Default: `pkgs.asdf_3_3`)
-- `packageOverrides`: Package overrides config (Default: `(self: super: {})`)
-
-This example wraps CLISP:
-
-```
-wrapLisp {
-  pkg = clisp;
-  faslExt = "fas";
-  flags = ["-E" "UTF8"];
-}
-```

doc/languages-frameworks/lua.section.md

@@ -129,21 +129,16 @@ Let's present the luarocks way first and the manual one in a second time.
 ### Packaging a library on luarocks {#packaging-a-library-on-luarocks}
 
 [Luarocks.org](https://luarocks.org/) is the main repository of lua packages.
-The site proposes two types of packages, the `rockspec` and the `src.rock`
+The site proposes two types of packages, the rockspec and the src.rock
 (equivalent of a [rockspec](https://github.com/luarocks/luarocks/wiki/Rockspec-format) but with the source).
+These packages can have different build types such as `cmake`, `builtin` etc .
 
-Luarocks-based packages are generated in [pkgs/development/lua-modules/generated-packages.nix](https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/lua-modules/generated-packages.nix) from
-the whitelist maintainers/scripts/luarocks-packages.csv and updated by running
-the script
-[maintainers/scripts/update-luarocks-packages](https://github.com/NixOS/nixpkgs/tree/master/maintainers/scripts/update-luarocks-packages):
-
-```sh
-./maintainers/scripts/update-luarocks-packages update
-```
+Luarocks-based packages are generated in pkgs/development/lua-modules/generated-packages.nix from
+the whitelist maintainers/scripts/luarocks-packages.csv and updated by running maintainers/scripts/update-luarocks-packages.
 
 [luarocks2nix](https://github.com/nix-community/luarocks) is a tool capable of generating nix derivations from both rockspec and src.rock (and favors the src.rock).
 The automation only goes so far though and some packages need to be customized.
-These customizations go in [pkgs/development/lua-modules/overrides.nix](https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/lua-modules/overrides.nix).
+These customizations go in `pkgs/development/lua-modules/overrides.nix`.
 For instance if the rockspec defines `external_dependencies`, these need to be manually added to the overrides.nix.
 
 You can try converting luarocks packages to nix packages with the command `nix-shell -p luarocks-nix` and then `luarocks nix PKG_NAME`.
@@ -188,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

@@ -38,12 +38,12 @@ Here is a simple package example.
 
 - It uses the `fetchFromGitHub` fetcher to get its source.
 
-- It also accept `duneVersion` parameter (valid value are `"1"`, `"2"`, and
-  `"3"`). The recommended practice it to set only if you don't want the default
-  value and/or it depends on something else like package version. You might see
-  a not-supported argument `useDune2`. The behavior was `useDune2 = true;` =>
-  `duneVersion = "2";` and `useDune2 = false;` => `duneVersion = "1";`. It was
-  used at the time when dune3 didn't existed.
+- `duneVersion = "2"` ensures that Dune version 2 is used for the
+  build (this is the default; valid values are `"1"`, `"2"`, and `"3"`);
+  note that there is also a legacy `useDune2` boolean attribute:
+  set to `false` it corresponds to `duneVersion = "1"`; set to `true` it
+  corresponds to `duneVersion = "2"`. If both arguments (`duneVersion` and
+  `useDune2`) are given, the second one (`useDune2`) is silently ignored.
 
 - It sets the optional `doCheck` attribute such that tests will be run with
   `dune runtest -p angstrom` after the build (`dune build -p angstrom`) is
@@ -71,6 +71,7 @@ Here is a simple package example.
 buildDunePackage rec {
   pname = "angstrom";
   version = "0.15.0";
+  duneVersion = "2";
 
   minimalOCamlVersion = "4.04";
 
@@ -78,7 +79,7 @@ buildDunePackage rec {
     owner  = "inhabitedtype";
     repo   = pname;
     rev    = version;
-    hash   = "sha256-MK8o+iPGANEhrrTc1Kz9LBilx2bDPQt7Pp5P2libucI=";
+    sha256 = "1hmrkdcdlkwy7rxhngf3cv3sa61cznnd9p5lmqhx20664gx2ibrh";
   };
 
   checkInputs = [ alcotest ppx_let ];
@@ -103,11 +104,13 @@ buildDunePackage rec {
   pname = "wtf8";
   version = "1.0.2";
 
+  useDune2 = true;
+
   minimalOCamlVersion = "4.02";
 
   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; {
@@ -126,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 {#pkg-config-writing-packages}
-
-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 {#sec-pkg-config-usage}
-
-### Within Nixpkgs {#sec-pkg-config-usage-internal}
-
-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 {#sec-pkg-config-usage-external}
-
-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 ];
 
@@ -1019,7 +1009,7 @@ buildPythonPackage rec {
 
 The `buildPythonPackage` mainly does four things:
 
-* In the `buildPhase`, it calls `${python.pythonForBuild.interpreter} setup.py bdist_wheel` to
+* In the `buildPhase`, it calls `${python.interpreter} setup.py bdist_wheel` to
   build a wheel binary zipfile.
 * In the `installPhase`, it installs the wheel file using `pip install *.whl`.
 * In the `postFixup` phase, the `wrapPythonPrograms` bash function is called to
@@ -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";
         };
       });
     };
@@ -1117,7 +1107,7 @@ with import <nixpkgs> {};
 in python.withPackages(ps: [ps.blaze])).env
 ```
 
-#### Optional extra dependencies {#python-optional-dependencies}
+#### Optional extra dependencies
 
 Some packages define optional dependencies for additional features. With
 `setuptools` this is called `extras_require` and `flit` calls it
@@ -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
     '';
   }
   ```
@@ -1546,7 +1532,7 @@ of such package using the feature is `pkgs/tools/X11/xpra/default.nix`.
 As workaround install it as an extra `preInstall` step:
 
 ```shell
-${python.pythonForBuild.interpreter} setup.py install_data --install-dir=$out --root=$out
+${python.interpreter} setup.py install_data --install-dir=$out --root=$out
 sed -i '/ = data\_files/d' setup.py
 ```
 
@@ -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}
 
@@ -1801,14 +1787,14 @@ The following rules are desired to be respected:
 * Attribute names in `python-packages.nix` should be sorted alphanumerically to
   avoid merge conflicts and ease locating attributes.
 
-## Package set maintenance {#python-package-set-maintenance}
+## Package set maintenance
 
 The whole Python package set has a lot of packages that do not see regular
 updates, because they either are a very fragile component in the Python
 ecosystem, like for example the `hypothesis` package, or packages that have
 no maintainer, so maintenance falls back to the package set maintainers.
 
-### Updating packages in bulk {#python-package-bulk-updates}
+### Updating packages in bulk
 
 There is a tool to update alot of python libraries in bulk, it exists at
 `maintainers/scripts/update-python-libraries` with this repository.
@@ -1821,11 +1807,6 @@ hosted on GitHub, exporting a `GITHUB_API_TOKEN` is highly recommended.
 Updating packages in bulk leads to lots of breakages, which is why a
 stabilization period on the `python-unstable` branch is required.
 
-If a package is fragile and often breaks during these bulks updates, it
-may be reasonable to set `passthru.skipBulkUpdate = true` in the
-derivation. This decision should not be made on a whim and should
-always be supported by a qualifying comment.
-
 Once the branch is sufficiently stable it should normally be merged
 into the `staging` branch.
 
@@ -1836,7 +1817,7 @@ would be:
 $ maintainers/scripts/update-python-libraries --target minor --commit --use-pkgs-prefix pkgs/development/python-modules/**/default.nix
 ```
 
-## CPython Update Schedule {#python-cpython-update-schedule}
+## CPython Update Schedule
 
 With [PEP 602](https://www.python.org/dev/peps/pep-0602/), CPython now
 follows a yearly release cadence. In nixpkgs, all supported interpreters

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/ruby.section.md

@@ -201,7 +201,7 @@ $ nix-shell --run 'ruby -rpg -e "puts PG.library_version"'
 
 Of course for this use-case one could also use overlays since the configuration for `pg` depends on the `postgresql` alias, but for demonstration purposes this has to suffice.
 
-### Platform-specific gems {#ruby-platform-specif-gems}
+### Platform-specific gems
 
 Right now, bundix has some issues with pre-built, platform-specific gems: [bundix PR #68](https://github.com/nix-community/bundix/pull/68).
 Until this is solved, you can tell bundler to not use platform-specific gems and instead build them from source each time:

doc/languages-frameworks/rust.section.md

@@ -13,7 +13,7 @@ into your `configuration.nix` or bring them into scope with `nix-shell -p rustc
 
 For other versions such as daily builds (beta and nightly),
 use either `rustup` from nixpkgs (which will manage the rust installation in your home directory),
-or use [community maintained Rust toolchains](#using-community-maintained-rust-toolchains).
+or use a community maintained [Rust overlay](#using-community-rust-overlays).
 
 ## `buildRustPackage`: Compiling Rust applications with Cargo {#compiling-rust-applications-with-cargo}
 
@@ -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";
@@ -50,11 +50,6 @@ package. `cargoHash256` is used for traditional Nix SHA-256 hashes,
 such as the one in the example above. `cargoHash` should instead be
 used for [SRI](https://www.w3.org/TR/SRI/) hashes. For example:
 
-Exception: If the application has cargo `git` dependencies, the `cargoHash`/`cargoSha256`
-approach will not work, and you will need to copy the `Cargo.lock` file of the application
-to nixpkgs and continue with the next section for specifying the options of the`cargoLock`
-section.
-
 ```nix
   cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8=";
 ```
@@ -102,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;
 
   # ...
@@ -162,7 +157,7 @@ required to build a rust package. A simple fix is to use:
 
 ```nix
 postPatch = ''
-  ln -s ${./Cargo.lock} Cargo.lock
+  cp ${./Cargo.lock} Cargo.lock
 '';
 ```
 
@@ -191,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
@@ -341,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 {
@@ -353,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,
@@ -416,13 +380,13 @@ rustPlatform.buildRustPackage rec {
 }
 ```
 
-### Compiling non-Rust packages that include Rust code {#compiling-non-rust-packages-that-include-rust-code}
+## Compiling non-Rust packages that include Rust code {#compiling-non-rust-packages-that-include-rust-code}
 
 Several non-Rust packages incorporate Rust code for performance- or
 security-sensitive parts. `rustPlatform` exposes several functions and
 hooks that can be used to integrate Cargo in non-Rust packages.
 
-#### Vendoring of dependencies {#vendoring-of-dependencies}
+### Vendoring of dependencies {#vendoring-of-dependencies}
 
 Since network access is not allowed in sandboxed builds, Rust crate
 dependencies need to be retrieved using a fetcher. `rustPlatform`
@@ -439,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.
@@ -482,7 +446,7 @@ added. To find the correct hash, you can first use `lib.fakeSha256` or
 `lib.fakeHash` as a stub hash. Building `cargoDeps` will then inform
 you of the correct hash.
 
-#### Hooks {#hooks}
+### Hooks {#hooks}
 
 `rustPlatform` provides the following hooks to automate Cargo builds:
 
@@ -510,15 +474,12 @@ 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
   `bindgen` find `libclang` and `libclang` find the libraries in `buildInputs`.
 
-#### Examples {#examples}
+### Examples {#examples}
 
 #### Python package using `setuptools-rust` {#python-package-using-setuptools-rust}
 
@@ -553,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";
@@ -590,7 +551,7 @@ buildPythonPackage rec {
 
   src = fetchPypi {
     inherit pname version;
-    hash = "sha256-xGDilsjLOnls3MfVbGKnj80KCUCczZxlis5PmHzpNcQ=";
+    sha256 = "1i1mx5y9hkyfi9jrrkcw804hmkcglxi6rmf7vin7jfnbr2bf4q64";
   };
 
   cargoDeps = rustPlatform.fetchCargoTarball {
@@ -630,7 +591,7 @@ buildPythonPackage rec {
     owner = "Qiskit";
     repo = "retworkx";
     rev = version;
-    hash = "sha256-11n30ldg3y3y6qxg3hbj837pnbwjkqw3nxq6frds647mmmprrd20=";
+    sha256 = "11n30ldg3y3y6qxg3hbj837pnbwjkqw3nxq6frds647mmmprrd20";
   };
 
   cargoDeps = rustPlatform.fetchCargoTarball {
@@ -653,13 +614,99 @@ buildPythonPackage rec {
 
 When run, `cargo build` produces a file called `Cargo.lock`,
 containing pinned versions of all dependencies. Nixpkgs contains a
-tool called `crate2Nix` (`nix-shell -p crate2nix`), 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.
+tool called `carnix` (`nix-env -iA nixos.carnix`), which can be used
+to turn a `Cargo.lock` into a Nix expression.
 
-See [`crate2nix`'s documentation](https://github.com/kolloch/crate2nix#known-restrictions)
-for instructions on how to use it.
+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}
 
@@ -767,7 +814,22 @@ general. A number of other parameters can be overridden:
   };
   ```
 
-### Setting Up `nix-shell` {#setting-up-nix-shell}
+### 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
 `buildRustCrate` does not support common `nix-shell` operations directly
@@ -811,61 +873,31 @@ $ cargo build
 $ cargo test
 ```
 
-## Using community maintained Rust toolchains {#using-community-maintained-rust-toolchains}
+### Controlling Rust Version Inside `nix-shell` {#controlling-rust-version-inside-nix-shell}
 
-::: {.note}
-Note: The following projects cannot be used within nixpkgs since [IFD](#ssec-import-from-derivation) is disallowed.
-To package things that require Rust nightly, `RUSTC_BOOTSTRAP = true;` can sometimes be used as a hack.
-:::
-
-There are two community maintained approaches to Rust toolchain management:
-- [oxalica's Rust overlay](https://github.com/oxalica/rust-overlay)
-- [fenix](https://github.com/nix-community/fenix)
-
-Despite their names, both projects provides a similar set of packages and overlays under different APIs.
-
-Oxalica's overlay allows you to select a particular Rust version without you providing a hash or a flake input,
-but comes with a larger git repository than fenix.
-
-Fenix also provides rust-analyzer nightly in addition to the Rust toolchains.
-
-Both oxalica's overlay and fenix better integrate with nix and cache optimizations.
-Because of this and ergonomics, either of those community projects
-should be preferred to the Mozilla's Rust overlay ([nixpkgs-mozilla](https://github.com/mozilla/nixpkgs-mozilla)).
-
-The following documentation demonstrates examples using fenix and oxalica's Rust overlay
-with `nix-shell` and building derivations. More advanced usages like flake usage
-are documented in their own repositories.
-
-### Using Rust nightly with `nix-shell` {#using-rust-nightly-with-nix-shell}
-
-Here is a simple `shell.nix` that provides Rust nightly (default profile) using fenix:
+To control your rust version (i.e. use nightly) from within `shell.nix` (or
+other nix expressions) you can use the following `shell.nix`
 
 ```nix
-with import <nixpkgs> { };
-let
-  fenix = callPackage
-    (fetchFromGitHub {
-      owner = "nix-community";
-      repo = "fenix";
-      # commit from: 2023-03-03
-      rev = "e2ea04982b892263c4d939f1cc3bf60a9c4deaa1";
-      hash = "sha256-AsOim1A8KKtMWIxG+lXh5Q4P2bhOZjoUhFWJ1EuZNNk=";
-    })
-    { };
+# Latest Nightly
+with import <nixpkgs> {};
+let src = fetchFromGitHub {
+      owner = "mozilla";
+      repo = "nixpkgs-mozilla";
+      # commit from: 2019-05-15
+      rev = "9f35c4b09fd44a77227e79ff0c1b4b6a69dff533";
+      sha256 = "18h0nvh55b5an4gmlgfbvwbyqj91bklf1zymis6lbdh75571qaz0";
+   };
 in
-mkShell {
+with import "${src.out}/rust-overlay.nix" pkgs pkgs;
+stdenv.mkDerivation {
   name = "rust-env";
-  nativeBuildInputs = [
-    # Note: to use stable, just replace `default` with `stable`
-    fenix.default.toolchain
-
-    # Example Build-time Additional Dependencies
-    pkg-config
-  ];
   buildInputs = [
-    # Example Run-time Additional Dependencies
-    openssl
+    # Note: to use stable, just replace `nightly` with `stable`
+    latest.rustChannels.nightly.rust
+
+    # Add some extra dependencies from `pkgs`
+    pkg-config openssl
   ];
 
   # Set Environment Variables
@@ -873,66 +905,116 @@ mkShell {
 }
 ```
 
-Save this to `shell.nix`, then run:
+Now run:
 
 ```ShellSession
 $ rustc --version
-rustc 1.69.0-nightly (13471d3b2 2023-03-02)
+rustc 1.26.0-nightly (188e693b3 2018-03-26)
 ```
 
 To see that you are using nightly.
 
-Oxalica's Rust overlay has more complete examples of `shell.nix` (and cross compilation) under its
-[`examples` directory](https://github.com/oxalica/rust-overlay/tree/e53e8853aa7b0688bc270e9e6a681d22e01cf299/examples).
+## Using community Rust overlays {#using-community-rust-overlays}
 
-### Using Rust nightly in a derivation with `buildRustPackage` {#using-rust-nightly-in-a-derivation-with-buildrustpackage}
+There are two community maintained approaches to Rust toolchain management:
+- [oxalica's Rust overlay](https://github.com/oxalica/rust-overlay)
+- [fenix](https://github.com/nix-community/fenix)
 
-You can also use Rust nightly to build rust packages using `makeRustPlatform`.
-The below snippet demonstrates invoking `buildRustPackage` with a Rust toolchain from oxalica's overlay:
+Oxalica's overlay allows you to select a particular Rust version and components.
+See [their documentation](https://github.com/oxalica/rust-overlay#rust-overlay) for more
+detailed usage.
 
+Fenix is an alternative to `rustup` and can also be used as an overlay.
+
+Both oxalica's overlay and fenix better integrate with nix and cache optimizations.
+Because of this and ergonomics, either of those community projects
+should be preferred to the Mozilla's Rust overlay (`nixpkgs-mozilla`).
+
+### How to select a specific `rustc` and toolchain version {#how-to-select-a-specific-rustc-and-toolchain-version}
+
+You can consume the oxalica overlay and use it to grab a specific Rust toolchain version.
+Here is an example `shell.nix` showing how to grab the current stable toolchain:
 ```nix
-with import <nixpkgs>
-{
+{ pkgs ? import <nixpkgs> {
+    overlays = [
+      (import (fetchTarball "https://github.com/oxalica/rust-overlay/archive/master.tar.gz"))
+    ];
+  }
+}:
+pkgs.mkShell {
+  nativeBuildInputs = with pkgs; [
+    pkg-config
+    rust-bin.stable.latest.minimal
+  ];
+}
+```
+
+You can try this out by:
+1. Saving that to `shell.nix`
+2. Executing `nix-shell --pure --command 'rustc --version'`
+
+As of writing, this prints out `rustc 1.56.0 (09c42c458 2021-10-18)`.
+
+### How to use an overlay toolchain in a derivation  {#how-to-use-an-overlay-toolchain-in-a-derivation}
+
+You can also use an overlay's Rust toolchain with `buildRustPackage`.
+The below snippet demonstrates invoking `buildRustPackage` with an oxalica overlay selected Rust toolchain:
+```nix
+with import <nixpkgs> {
   overlays = [
     (import (fetchTarball "https://github.com/oxalica/rust-overlay/archive/master.tar.gz"))
   ];
 };
-let
-  rustPlatform = makeRustPlatform {
-    cargo = rust-bin.stable.latest.minimal;
-    rustc = rust-bin.stable.latest.minimal;
-  };
-in
 
 rustPlatform.buildRustPackage rec {
   pname = "ripgrep";
   version = "12.1.1";
+  nativeBuildInputs = [
+    rust-bin.stable.latest.minimal
+  ];
 
   src = fetchFromGitHub {
     owner = "BurntSushi";
     repo = "ripgrep";
     rev = version;
-    hash = "sha256-+s5RBC3XSgb8omTbUNLywZnP6jSxZBKSS1BmXOjRF8M=";
+    sha256 = "1hqps7l5qrjh9f914r5i6kmcz6f1yb951nv4lby0cjnp5l253kps";
   };
 
-  cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8=";
-
-  doCheck = false;
+  cargoSha256 = "03wf9r2csi6jpa7v5sw5lpxkrk4wfzwmzx7k3991q3bdjzcwnnwp";
 
   meta = with lib; {
     description = "A fast line-oriented regex search tool, similar to ag and ack";
     homepage = "https://github.com/BurntSushi/ripgrep";
-    license = with licenses; [ mit unlicense ];
-    maintainers = with maintainers; [ tailhook ];
+    license = licenses.unlicense;
+    maintainers = [ maintainers.tailhook ];
   };
 }
 ```
 
 Follow the below steps to try that snippet.
+1. create a new directory
 1. save the above snippet as `default.nix` in that directory
-2. cd into that directory and run `nix-build`
+1. cd into that directory and run `nix-build`
 
-Fenix also has examples with `buildRustPackage`,
-[crane](https://github.com/ipetkov/crane),
-[naersk](https://github.com/nix-community/naersk),
-and cross compilation in its [Examples](https://github.com/nix-community/fenix#examples) section.
+### Rust overlay installation {#rust-overlay-installation}
+
+You can use this overlay by either changing your local nixpkgs configuration,
+or by adding the overlay declaratively in a nix expression,  e.g. in `configuration.nix`.
+For more information see [the manual on installing overlays](#sec-overlays-install).
+
+### Declarative Rust overlay installation {#declarative-rust-overlay-installation}
+
+This snippet shows how to use oxalica's Rust overlay.
+Add the following to your `configuration.nix`, `home-configuration.nix`, `shell.nix`, or similar:
+
+```nix
+{ pkgs ? import <nixpkgs> {
+    overlays = [
+      (import (builtins.fetchTarball "https://github.com/oxalica/rust-overlay/archive/master.tar.gz"))
+      # Further overlays go here
+    ];
+  };
+};
+```
+
+Note that this will fetch the latest overlay version when rebuilding your system.