Release 22.05

(cherry picked from commit cbaacfb8df)

.editorconfig

@@ -60,13 +60,6 @@ indent_size = unset
 [*.md]
 trim_trailing_whitespace = unset
 
-# binaries
-[*.nib]
-end_of_line = unset
-insert_final_newline = unset
-trim_trailing_whitespace = unset
-charset = unset
-
 [eggs.nix]
 trim_trailing_whitespace = unset
 

.git-blame-ignore-revs

@@ -28,14 +28,5 @@
 # nixos/modules/rename: Sort alphabetically
 1f71224fe86605ef4cd23ed327b3da7882dad382
 
-# manual: fix typos
-feddd5e7f8c6f8167b48a077fa2a5394dc008999
-
 # nixos: fix module paths in rename.nix
 d08ede042b74b8199dc748323768227b88efcf7c
-
-# fix indentation in mk-python-derivation.nix
-d1c1a0c656ccd8bd3b25d3c4287f2d075faf3cf3
-
-# fix indentation in meteor default.nix
-a37a6de881ec4c6708e6b88fd16256bbc7f26bbd

.github/CODEOWNERS

@@ -37,7 +37,6 @@
 /pkgs/top-level/splice.nix                       @Ericson2314 @matthewbauer
 /pkgs/top-level/release-cross.nix                @Ericson2314 @matthewbauer
 /pkgs/stdenv/generic                             @Ericson2314 @matthewbauer
-/pkgs/stdenv/generic/check-meta.nix              @Ericson2314 @matthewbauer @piegamesde
 /pkgs/stdenv/cross                               @Ericson2314 @matthewbauer
 /pkgs/build-support/cc-wrapper                   @Ericson2314
 /pkgs/build-support/bintools-wrapper             @Ericson2314
@@ -51,14 +50,8 @@
 # Nixpkgs documentation
 /maintainers/scripts/db-to-md.sh @jtojnar @ryantm
 /maintainers/scripts/doc @jtojnar @ryantm
-
-/doc/* @fricklerhandwerk
 /doc/build-aux/pandoc-filters @jtojnar
-/doc/builders/trivial-builders.chapter.md @fricklerhandwerk
-/doc/contributing/ @fricklerhandwerk
-/doc/contributing/contributing-to-documentation.chapter.md @jtojnar @fricklerhandwerk
-/doc/stdenv @fricklerhandwerk
-/doc/using @fricklerhandwerk
+/doc/contributing/contributing-to-documentation.chapter.md @jtojnar
 
 # NixOS Internals
 /nixos/default.nix          @nbp @infinisil
@@ -105,18 +98,18 @@
 /pkgs/development/interpreters/python/hooks                 @FRidh @jonringer
 
 # Haskell
-/doc/languages-frameworks/haskell.section.md  @cdepillabout @sternenseemann @maralorn
-/maintainers/scripts/haskell                  @cdepillabout @sternenseemann @maralorn
-/pkgs/development/compilers/ghc               @cdepillabout @sternenseemann @maralorn
-/pkgs/development/haskell-modules             @cdepillabout @sternenseemann @maralorn
-/pkgs/test/haskell                            @cdepillabout @sternenseemann @maralorn
-/pkgs/top-level/release-haskell.nix           @cdepillabout @sternenseemann @maralorn
-/pkgs/top-level/haskell-packages.nix          @cdepillabout @sternenseemann @maralorn
+/doc/languages-frameworks/haskell.section.md  @cdepillabout @sternenseemann @maralorn @expipiplus1
+/maintainers/scripts/haskell                  @cdepillabout @sternenseemann @maralorn @expipiplus1
+/pkgs/development/compilers/ghc               @cdepillabout @sternenseemann @maralorn @expipiplus1
+/pkgs/development/haskell-modules             @cdepillabout @sternenseemann @maralorn @expipiplus1
+/pkgs/test/haskell                            @cdepillabout @sternenseemann @maralorn @expipiplus1
+/pkgs/top-level/release-haskell.nix           @cdepillabout @sternenseemann @maralorn @expipiplus1
+/pkgs/top-level/haskell-packages.nix          @cdepillabout @sternenseemann @maralorn @expipiplus1
 
 # Perl
-/pkgs/development/interpreters/perl @stigtsp @zakame @dasJ
-/pkgs/top-level/perl-packages.nix   @stigtsp @zakame @dasJ
-/pkgs/development/perl-modules      @stigtsp @zakame @dasJ
+/pkgs/development/interpreters/perl @stigtsp @zakame
+/pkgs/top-level/perl-packages.nix   @stigtsp @zakame
+/pkgs/development/perl-modules      @stigtsp @zakame
 
 # R
 /pkgs/applications/science/math/R   @jbedo
@@ -128,6 +121,8 @@
 
 # Rust
 /pkgs/development/compilers/rust @Mic92 @LnL7 @zowoq
+/pkgs/build-support/rust @zowoq
+/doc/languages-frameworks/rust.section.md @zowoq
 
 # C compilers
 /pkgs/development/compilers/gcc @matthewbauer
@@ -192,7 +187,6 @@
 /nixos/modules/services/networking/babeld.nix @mweinelt
 /nixos/modules/services/networking/kea.nix @mweinelt
 /nixos/modules/services/networking/knot.nix @mweinelt
-/nixos/modules/services/monitoring/prometheus/exporters/kea.nix @mweinelt
 /nixos/tests/babeld.nix @mweinelt
 /nixos/tests/kea.nix @mweinelt
 /nixos/tests/knot.nix @mweinelt
@@ -257,12 +251,13 @@
 
 # Go
 /doc/languages-frameworks/go.section.md @kalbasit @Mic92 @zowoq
-/pkgs/build-support/go @kalbasit @Mic92 @zowoq
 /pkgs/development/compilers/go @kalbasit @Mic92 @zowoq
+/pkgs/development/go-modules   @kalbasit @Mic92 @zowoq
+/pkgs/development/go-packages  @kalbasit @Mic92 @zowoq
 
 # GNOME
-/pkgs/desktops/gnome                              @jtojnar
-/pkgs/desktops/gnome/extensions       @piegamesde @jtojnar
+/pkgs/desktops/gnome                              @jtojnar @hedning
+/pkgs/desktops/gnome/extensions       @piegamesde @jtojnar @hedning
 
 # Cinnamon
 /pkgs/desktops/cinnamon @mkg20001
@@ -294,8 +289,3 @@
 # Dotnet
 /pkgs/build-support/dotnet          @IvarWithoutBones
 /pkgs/development/compilers/dotnet  @IvarWithoutBones
-
-# Node.js
-/pkgs/build-support/node/build-npm-package      @winterqt
-/pkgs/build-support/node/fetch-npm-deps         @winterqt
-/doc/languages-frameworks/javascript.section.md @winterqt

.github/ISSUE_TEMPLATE/missing_documentation.md

@@ -1,32 +0,0 @@
----
-name: Missing or incorrect documentation
-about: Help us improve the Nixpkgs and NixOS reference manuals
-title: ''
-labels: '9.needs: documentation'
-assignees: ''
-
----
-
-## Problem
-
-<!-- describe your problem -->
-
-## Checklist
-
-<!-- make sure this issue is not redundant or obsolete -->
-
-- [ ] checked [latest Nixpkgs manual] \([source][nixpkgs-source]) and [latest NixOS manual] \([source][nixos-source])
-- [ ] checked [open documentation issues] for possible duplicates
-- [ ] checked [open documentation pull requests] for possible solutions
-
-[latest Nixpkgs manual]: https://nixos.org/manual/nixpkgs/unstable/
-[latest NixOS manual]: https://nixos.org/manual/nixos/unstable/
-[nixpkgs-source]: https://github.com/NixOS/nixpkgs/tree/master/doc
-[nixos-source]: https://github.com/NixOS/nixpkgs/tree/master/nixos/doc/manual
-[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/unreproducible_package.md

@@ -1,31 +0,0 @@
----
-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'
-assignees: ''
-
----
-
-Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible-builds.org/ .
-
-Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems.
-
-### Steps To Reproduce
-
-```
-nix-build '<nixpkgs>' -A ... --check --keep-failed
-```
-
-You can use `diffoscope` to analyze the differences in the output of the two builds.
-
-To view the build log of the build that produced the artifact in the binary cache:
-
-```
-nix-store --read-log $(nix-instantiate '<nixpkgs>' -A ...)
-```
-
-### Additional context
-
-(please share the relevant fragment of the diffoscope output here,
-and any additional analysis you may have done)

.github/PULL_REQUEST_TEMPLATE.md

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

.github/STALE-BOT.md

@@ -1,7 +1,6 @@
 # Stale bot information
 
 - Thanks for your contribution!
-- Our stale bot will never close an issue or PR.
 - To remove the stale label, just leave a new comment.
 - _How to find the right people to ping?_ → [`git blame`](https://git-scm.com/docs/git-blame) to the rescue! (or GitHub's history and blame buttons.)
 - You can always ask for help on [our Discourse Forum](https://discourse.nixos.org/), [our Matrix room](https://matrix.to/#/#nix:nixos.org), or on the [#nixos IRC channel](https://web.libera.chat/#nixos).

.github/dependabot.yml

@@ -1,6 +0,0 @@
-version: 2
-updates:
-  - package-ecosystem: "github-actions"
-    directory: "/"
-    schedule:
-      interval: "weekly"

.github/labeler.yml

@@ -7,8 +7,6 @@
 
 "6.topic: cinnamon":
   - pkgs/desktops/cinnamon/**/*
-  - nixos/modules/services/x11/desktop-managers/cinnamon.nix
-  - nixos/tests/cinnamon.nix
 
 "6.topic: emacs":
   - nixos/modules/services/editors/emacs.nix
@@ -42,8 +40,9 @@
 
 "6.topic: golang":
   - doc/languages-frameworks/go.section.md
-  - pkgs/build-support/go/**/*
   - pkgs/development/compilers/go/**/*
+  - pkgs/development/go-modules/**/*
+  - pkgs/development/go-packages/**/*
 
 "6.topic: haskell":
   - doc/languages-frameworks/haskell.section.md
@@ -143,9 +142,6 @@
   - nixos/modules/programs/neovim.nix
   - pkgs/applications/editors/neovim/**/*
 
-"6.topic: vscode":
-  - pkgs/applications/editors/vscode/**/*
-
 "6.topic: xfce":
   - nixos/doc/manual/configuration/xfce.xml
   - nixos/modules/services/x11/desktop-managers/xfce.nix

.github/stale.yml

@@ -5,5 +5,6 @@ exemptLabels:
   - "1.severity: security"
   - "2.status: never-stale"
 staleLabel: "2.status: stale"
-markComment: false
+markComment: |
+  I marked this as stale due to inactivity. → [More info](https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md)
 closeComment: false

.github/workflows/backport.yml

@@ -8,14 +8,8 @@ on:
 # the GitHub repository. This means that it should not evaluate user input in a
 # way that allows code injection.
 
-permissions:
-  contents: read
-
 jobs:
   backport:
-    permissions:
-      contents: write  # for zeebe-io/backport-action to create branch
-      pull-requests: write  # for zeebe-io/backport-action to create PR to backport
     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
@@ -26,11 +20,14 @@ jobs:
           fetch-depth: 0
           ref: ${{ github.event.pull_request.head.sha }}
       - name: Create backport PRs
-        uses: zeebe-io/backport-action@v0.0.8
+        # should be kept in sync with `version`
+        uses: zeebe-io/backport-action@v0.0.5
         with:
           # Config README: https://github.com/zeebe-io/backport-action#backport-action
           github_token: ${{ secrets.GITHUB_TOKEN }}
           github_workspace: ${{ github.workspace }}
+          # should be kept in sync with `uses`
+          version: v0.0.5
           pull_description: |-
             Bot-based backport to `${target_branch}`, triggered by a label in #${pull_number}.
 

.github/workflows/basic-eval.yml

@@ -10,17 +10,14 @@ on:
   #   branches:
   #    - master
   #    - release-**
-permissions:
-  contents: read
-
 jobs:
   tests:
     runs-on: ubuntu-latest
     # we don't limit this action to only NixOS repo since the checks are cheap and useful developer feedback
     steps:
     - uses: actions/checkout@v3
-    - uses: cachix/install-nix-action@v18
-    - uses: cachix/cachix-action@v12
+    - uses: cachix/install-nix-action@v17
+    - uses: cachix/cachix-action@v10
       with:
         # This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
         name: nixpkgs-ci

.github/workflows/compare-manuals.sh

@@ -1,21 +0,0 @@
-#!/usr/bin/env nix-shell
-#! nix-shell -i bash -p html-tidy
-
-set -euo pipefail
-shopt -s inherit_errexit
-
-normalize() {
-  tidy \
-      --anchor-as-name no \
-      --coerce-endtags no \
-      --escape-scripts no \
-      --fix-backslash no \
-      --fix-style-tags no \
-      --fix-uri no \
-      --indent yes \
-      --wrap 0 \
-      < "$1" \
-      2> /dev/null
-}
-
-diff -U3 <(normalize "$1") <(normalize "$2")

.github/workflows/direct-push.yml

@@ -4,13 +4,8 @@ on:
     branches:
      - master
      - release-**
-permissions:
-  contents: read
-
 jobs:
   build:
-    permissions:
-      contents: write  # for peter-evans/commit-comment to comment on commit
     runs-on: ubuntu-latest
     if: github.repository_owner == 'NixOS'
     env:
@@ -21,7 +16,7 @@ jobs:
       id: ismerge
       run: |
         ISMERGE=$(curl -H 'Accept: application/vnd.github.groot-preview+json' -H "authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" https://api.github.com/repos/${{ env.GITHUB_REPOSITORY }}/commits/${{ env.GITHUB_SHA }}/pulls | jq -r '.[] | select(.merge_commit_sha == "${{ env.GITHUB_SHA }}") | any')
-        echo "ismerge=$ISMERGE" >> $GITHUB_OUTPUT
+        echo "::set-output name=ismerge::$ISMERGE"
     # github events are eventually consistent, so wait until changes propagate to thier DB
     - run: sleep 60
       if: steps.ismerge.outputs.ismerge != 'true'

.github/workflows/editorconfig.yml

@@ -28,7 +28,7 @@ jobs:
       with:
         # pull_request_target checks out the base branch by default
         ref: refs/pull/${{ github.event.pull_request.number }}/merge
-    - uses: cachix/install-nix-action@v18
+    - uses: cachix/install-nix-action@v17
       with:
         # nixpkgs commit is pinned so that it doesn't break
         # editorconfig-checker 2.4.0

.github/workflows/manual-nixos.yml

@@ -18,22 +18,14 @@ jobs:
         with:
           # pull_request_target checks out the base branch by default
           ref: refs/pull/${{ github.event.pull_request.number }}/merge
-      - uses: cachix/install-nix-action@v18
+      - uses: cachix/install-nix-action@v17
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true
-      - uses: cachix/cachix-action@v12
+      - uses: cachix/cachix-action@v10
         with:
           # This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
           name: nixpkgs-ci
           signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
-      - name: Building NixOS manual with DocBook options
+      - name: Building NixOS manual
         run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true nixos/release.nix -A manual.x86_64-linux
-      - name: Building NixOS manual with Markdown options
-        run: |
-          export NIX_PATH=nixpkgs=$(pwd)
-          nix-build \
-            --option restrict-eval true \
-            --arg configuration '{ documentation.nixos.options.allowDocBook = false; }' \
-            nixos/release.nix \
-            -A manual.x86_64-linux

.github/workflows/manual-nixpkgs.yml

@@ -18,11 +18,11 @@ jobs:
         with:
           # pull_request_target checks out the base branch by default
           ref: refs/pull/${{ github.event.pull_request.number }}/merge
-      - uses: cachix/install-nix-action@v18
+      - uses: cachix/install-nix-action@v17
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true
-      - uses: cachix/cachix-action@v12
+      - uses: cachix/cachix-action@v10
         with:
           # This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
           name: nixpkgs-ci

.github/workflows/manual-rendering.yml

@@ -1,64 +0,0 @@
-name: "Check NixOS Manual DocBook rendering against MD rendering"
-
-
-on:
-  schedule:
-    # * is a special character in YAML so you have to quote this string
-    # Check every 24 hours
-    - cron:  '0 0 * * *'
-
-permissions:
-  contents: read
-
-jobs:
-  check-rendering-equivalence:
-    permissions:
-      pull-requests: write  # for peter-evans/create-or-update-comment to create or update comment
-    if: github.repository_owner == 'NixOS'
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v3
-      - uses: cachix/install-nix-action@v18
-        with:
-          # explicitly enable sandbox
-          extra_nix_config: sandbox = true
-      - uses: cachix/cachix-action@v12
-        with:
-          # This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
-          name: nixpkgs-ci
-          signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
-
-      - name: Build DocBook and MD manuals
-        run: |
-          export NIX_PATH=nixpkgs=$(pwd)
-          nix-build \
-            --option restrict-eval true \
-            -o docbook nixos/release.nix \
-            -A manual.x86_64-linux
-          nix-build \
-            --option restrict-eval true \
-            --arg configuration '{ documentation.nixos.options.allowDocBook = false; }' \
-            -o md nixos/release.nix \
-            -A manual.x86_64-linux
-
-      - name: Compare DocBook and MD manuals
-        id: check
-        run: |
-          export NIX_PATH=nixpkgs=$(pwd)
-          .github/workflows/compare-manuals.sh \
-            docbook/share/doc/nixos/options.html \
-            md/share/doc/nixos/options.html
-
-      # if the manual can't be built we don't want to notify anyone.
-      # while this may temporarily hide rendering failures it will be a lot
-      # 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@v2
-        if: ${{ failure() && steps.check.conclusion == 'failure' }}
-        with:
-          issue-number: 189318
-          body: |
-            Markdown and DocBook manuals do not agree.
-
-            Check https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }} for details.

.github/workflows/nixos-manual.yml

@@ -19,16 +19,8 @@ jobs:
       with:
         # pull_request_target checks out the base branch by default
         ref: refs/pull/${{ github.event.pull_request.number }}/merge
-    - uses: cachix/install-nix-action@v18
+    - uses: cachix/install-nix-action@v17
     - 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
-        }
+        git diff --exit-code

.github/workflows/no-channel.yml

@@ -6,13 +6,8 @@ on:
       - 'nixos-**'
       - 'nixpkgs-**'
 
-permissions:
-  contents: read
-
 jobs:
   fail:
-    permissions:
-      contents: none
     name: "This PR is is targeting a channel branch"
     runs-on: ubuntu-latest
     steps:

.github/workflows/ofborg-pending.yml

@@ -1,33 +0,0 @@
-name: "Set pending OfBorg status"
-on:
-  pull_request_target:
-
-# Sets the ofborg-eval status to "pending" to signal that we are waiting for
-# OfBorg even if it is running late. The status will be overwritten by OfBorg
-# once it starts evaluation.
-
-# WARNING:
-# When extending this action, be aware that $GITHUB_TOKEN allows (restricted) write access to
-# the GitHub repository. This means that it should not evaluate user input in a
-# way that allows code injection.
-
-permissions:
-  contents: read
-
-jobs:
-  action:
-    if: github.repository_owner == 'NixOS'
-    permissions:
-      statuses: write
-    runs-on: ubuntu-latest
-    steps:
-    - name: "Set pending OfBorg status"
-      env:
-        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      run: |
-        curl \
-          -X POST \
-          -H "Accept: application/vnd.github.v3+json" \
-          -H "Authorization: Bearer $GITHUB_TOKEN" \
-          -d '{"context": "ofborg-eval", "state": "pending", "description": "Waiting for OfBorg..."}' \
-          "https://api.github.com/repos/NixOS/nixpkgs/commits/${{ github.event.pull_request.head.sha }}/statuses"

.github/workflows/pending-clear.yml

@@ -0,0 +1,21 @@
+name: "clear pending status"
+
+on:
+  check_suite:
+    types: [ completed ]
+
+jobs:
+  action:
+    runs-on: ubuntu-latest
+    steps:
+    - name: clear pending status
+      if: github.repository_owner == 'NixOS' && github.event.check_suite.app.name == 'OfBorg'
+      env:
+        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      run: |
+        curl \
+          -X POST \
+          -H "Accept: application/vnd.github.v3+json" \
+          -H "Authorization: token $GITHUB_TOKEN" \
+          -d '{"state": "success", "target_url": " ", "description": " ", "context": "Wait for ofborg"}' \
+          "https://api.github.com/repos/NixOS/nixpkgs/statuses/${{ github.event.check_suite.head_sha }}"

.github/workflows/pending-set.yml

@@ -0,0 +1,25 @@
+name: "set pending status"
+
+on:
+  pull_request_target:
+
+# WARNING:
+# When extending this action, be aware that $GITHUB_TOKEN allows write access to
+# the GitHub repository. This means that it should not evaluate user input in a
+# way that allows code injection.
+
+jobs:
+  action:
+    runs-on: ubuntu-latest
+    steps:
+    - name: set pending status
+      if: github.repository_owner == 'NixOS'
+      env:
+        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      run: |
+        curl \
+          -X POST \
+          -H "Accept: application/vnd.github.v3+json" \
+          -H "Authorization: token $GITHUB_TOKEN" \
+          -d '{"state": "pending", "target_url": " ", "description": "This pending status will be cleared when ofborg starts eval.", "context": "Wait for ofborg"}' \
+          "https://api.github.com/repos/NixOS/nixpkgs/statuses/${{ github.event.pull_request.head.sha }}"

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

@@ -14,14 +14,8 @@ on:
     # Merge every 24 hours
     - cron:  '0 0 * * *'
 
-permissions:
-  contents: read
-
 jobs:
   periodic-merge:
-    permissions:
-      contents: write  # for devmasx/merge-branch to merge branches
-      pull-requests: write  # for peter-evans/create-or-update-comment to create or update comment
     if: github.repository_owner == 'NixOS'
     runs-on: ubuntu-latest
     strategy:
@@ -34,10 +28,10 @@ jobs:
         pairs:
           - from: master
             into: haskell-updates
-          - from: release-22.11
-            into: staging-next-22.11
-          - from: staging-next-22.11
-            into: staging-22.11
+          - from: release-21.11
+            into: staging-next-21.11
+          - from: staging-next-21.11
+            into: staging-21.11
           - from: release-22.05
             into: staging-next-22.05
           - from: staging-next-22.05

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

@@ -14,14 +14,8 @@ on:
     # Merge every 6 hours
     - cron:  '0 */6 * * *'
 
-permissions:
-  contents: read
-
 jobs:
   periodic-merge:
-    permissions:
-      contents: write  # for devmasx/merge-branch to merge branches
-      pull-requests: write  # for peter-evans/create-or-update-comment to create or update comment
     if: github.repository_owner == 'NixOS'
     runs-on: ubuntu-latest
     strategy:

.github/workflows/update-terraform-providers.yml

@@ -2,54 +2,47 @@ name: "Update terraform-providers"
 
 on:
   schedule:
-    - cron: "0 3 * * *"
+    - cron: "14 3 * * 1"
   workflow_dispatch:
 
-permissions:
-  contents: read
-
 jobs:
   tf-providers:
-    permissions:
-      contents: write  # for peter-evans/create-pull-request to create branch
-      pull-requests: write  # for peter-evans/create-pull-request to create a PR, for peter-evans/create-or-update-comment to create or update comment
     if: github.repository_owner == 'NixOS' && github.ref == 'refs/heads/master' # ensure workflow_dispatch only runs on master
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
-      - uses: cachix/install-nix-action@v18
-        with:
-          nix_path: nixpkgs=channel:nixpkgs-unstable
+      - uses: cachix/install-nix-action@v17
       - name: setup
         id: setup
         run: |
-          echo "title=terraform-providers: update $(date -u +"%Y-%m-%d")" >> $GITHUB_OUTPUT
+          echo ::set-output name=title::"terraform-providers: update $(date -u +"%Y-%m-%d")"
       - name: update terraform-providers
         run: |
           git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
           git config user.name "github-actions[bot]"
-          echo | nix-shell \
-            maintainers/scripts/update.nix \
-            --argstr commit true \
-            --argstr keep-going true \
-            --argstr max-workers 2 \
-            --argstr path terraform-providers
-      - name: clean repo
-        run: |
-          git clean -f
+          pushd pkgs/applications/networking/cluster/terraform-providers
+          ./update-all-providers --no-build
+          git commit -m "${{ steps.setup.outputs.title }}" providers.json
+          popd
       - name: create PR
         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 }}
-
             Check that all providers build with:
             ```
-            @ofborg build terraform.full
+            @ofborg build terraform-full
             ```
           branch: terraform-providers-update
           delete-branch: false
+          labels: "2.status: work-in-progress"
           title: ${{ steps.setup.outputs.title }}
           token: ${{ secrets.GITHUB_TOKEN }}
+      - name: comment on failure
+        uses: peter-evans/create-or-update-comment@v2
+        if: ${{ failure() }}
+        with:
+          issue-number: 153416
+          body: |
+            Automatic update of terraform providers [failed](https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}).

.gitignore

@@ -5,15 +5,13 @@
 .idea/
 .vscode/
 outputs/
-result-*
 result
-!pkgs/development/python-modules/result
+result-*
+source/
 /doc/NEWS.html
 /doc/NEWS.txt
 /doc/manual.html
 /doc/manual.pdf
-/result
-/source/
 .version-suffix
 
 .DS_Store

.mailmap

@@ -1,3 +0,0 @@
-Daniel Løvbrøtte Olsen <me@dandellion.xyz> <daniel.olsen99@gmail.com>
-R. RyanTM <ryantm-bot@ryantm.com>
-Sandro <sandro.jaeckel@gmail.com>

.version

@@ -1 +1 @@
-22.11
+22.05

CONTRIBUTING.md

@@ -51,7 +51,7 @@ See the nixpkgs manual for more details on [standard meta-attributes](https://ni
 
 In addition to writing properly formatted commit messages, it's important to include relevant information so other developers can later understand *why* a change was made. While this information usually can be found by digging code, mailing list/Discourse archives, pull request discussions or upstream changes, it may require a lot of work.
 
-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.
+For package version upgrades and such a one-line commit message is usually sufficient.
 
 ## Rebasing between branches (i.e. from master to staging)
 
@@ -62,26 +62,25 @@ many CODEOWNERS will be inadvertently requested for review.  To achieve this,
 rebasing should not be performed directly on the target branch, but on the merge
 base between the current and target branch.
 
-In the following example, we assume that the current branch, called `feature`,
-is based on `master`, and we rebase it onto the merge base between
-`master` and `staging` so that the PR can eventually be retargeted to
-`staging` without causing a mess. The example uses `upstream` as the remote for `NixOS/nixpkgs.git`
-while `origin` is the remote you are pushing to.
+In the following example, we see a rebase from `master` onto the merge base
+between `master` and `staging`, so that a change can eventually be retargeted to
+`staging`. The example uses `upstream` as the remote for `NixOS/nixpkgs.git`
+while the `origin` remote is used for the remote you are pushing to.
 
 
 ```console
-# Rebase your commits onto the common merge base
-git rebase --onto upstream/staging... upstream/master
+# Find the common base between two branches
+common=$(git merge-base upstream/master upstream/staging)
+# Find the common base between your feature branch and master
+commits=$(git merge-base $(git branch --show-current) upstream/master)
+# Rebase all commits onto the common base
+git rebase --onto=$common $commits
 # Force push your changes
-git push origin feature --force-with-lease
+git push origin $(git branch --show-current) --force-with-lease
 ```
 
-The syntax `upstream/staging...` is equivalent to `upstream/staging...HEAD` and
-stands for the merge base between `upstream/staging` and `HEAD` (hence between
-`upstream/staging` and `upstream/master`).
-
 Then change the base branch in the GitHub PR using the *Edit* button in the upper
-right corner, and switch from `master` to `staging`. *After* the PR has been
+right corner, and switch from `master` to `staging`. After the PR has been
 retargeted it might be necessary to do a final rebase onto the target branch, to
 resolve any outstanding merge conflicts.
 
@@ -91,7 +90,7 @@ git rebase upstream/staging
 # Review and fixup possible conflicts
 git status
 # Force push your changes
-git push origin feature --force-with-lease
+git push origin $(git branch --show-current) --force-with-lease
 ```
 
 ## Backporting changes
@@ -105,10 +104,10 @@ This also works for PR's that have already been merged, and might take a couple
 You can also create the backport manually:
 
 1. Take note of the commits in which the change was introduced into `master` branch.
-2. Check out the target _release branch_, e.g. `release-22.05`. Do not use a _channel branch_ like `nixos-22.05` or `nixpkgs-22.05-darwin`.
+2. Check out the target _release branch_, e.g. `release-21.11`. Do not use a _channel branch_ like `nixos-21.11` or `nixpkgs-21.11-darwin`.
 3. Create a branch for your change, e.g. `git checkout -b backport`.
 4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request.
-5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-22.05`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[22.05]`.
+5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-21.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. `[21.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

README.md

@@ -51,9 +51,9 @@ Nixpkgs and NixOS are built and tested by our continuous integration
 system, [Hydra](https://hydra.nixos.org/).
 
 * [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
-* [Continuous package builds for the NixOS 22.05 release](https://hydra.nixos.org/jobset/nixos/release-22.05)
+* [Continuous package builds for the NixOS 21.11 release](https://hydra.nixos.org/jobset/nixos/release-21.11)
 * [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
-* [Tests for the NixOS 22.05 release](https://hydra.nixos.org/job/nixos/release-22.05/tested#tabs-constituents)
+* [Tests for the NixOS 21.11 release](https://hydra.nixos.org/job/nixos/release-21.11/tested#tabs-constituents)
 
 Artifacts successfully built with Hydra are published to cache at
 https://cache.nixos.org/. When successful build and test criteria are

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

@@ -1,11 +0,0 @@
---[[
-Converts some HTML elements commonly used in Markdown to corresponding DocBook elements.
-]]
-
-function RawInline(elem)
-  if elem.format == 'html' and elem.text == '<kbd>' then
-    return pandoc.RawInline('docbook', '<keycap>')
-  elseif elem.format == 'html' and elem.text == '</kbd>' then
-    return pandoc.RawInline('docbook', '</keycap>')
-  end
-end

doc/build-aux/pandoc-filters/docbook-writer/rst-roles.lua

@@ -27,14 +27,6 @@ function Code(elem)
       content = '<refentrytitle>' .. title .. '</refentrytitle>' .. (volnum ~= nil and ('<manvolnum>' .. volnum .. '</manvolnum>') or '')
     elseif elem.attributes['role'] == 'file' then
       tag = 'filename'
-    elseif elem.attributes['role'] == 'command' then
-      tag = 'command'
-    elseif elem.attributes['role'] == 'option' then
-      tag = 'option'
-    elseif elem.attributes['role'] == 'var' then
-      tag = 'varname'
-    elseif elem.attributes['role'] == 'env' then
-      tag = 'envar'
     end
 
     if tag ~= nil then

doc/builders/fetchers.chapter.md

@@ -1,51 +1,12 @@
 # Fetchers {#chap-pkgs-fetchers}
 
-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.
+When using Nix, you will frequently need to download source code and other files from the internet. For this purpose, Nix provides the [_fixed output derivation_](https://nixos.org/manual/nix/stable/#fixed-output-drvs) feature and Nixpkgs provides various functions that implement the actual fetching from various protocols and services.
 
 ## 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.
+Because fixed output derivations are _identified_ by their hash, a common mistake is to update a fetcher's URL or a version parameter, without updating the hash. **This will cause the old contents to be used.** So remember to always invalidate the hash argument.
 
-The fact that the hash belongs to the Nix derivation output and not the file itself can lead to confusion.
-For example, consider the following fetcher:
-
-```nix
-fetchurl {
-  url = "http://www.example.org/hello-1.0.tar.gz";
-  sha256 = "0v6r3wwnsk5pdjr188nip3pjgn1jrn5pc5ajpcfy6had6b3v4dwm";
-};
-```
-
-A common mistake is to update a fetcher’s URL, or a version parameter, without updating the hash.
-
-```nix
-fetchurl {
-  url = "http://www.example.org/hello-1.1.tar.gz";
-  sha256 = "0v6r3wwnsk5pdjr188nip3pjgn1jrn5pc5ajpcfy6had6b3v4dwm";
-};
-```
-
-**This will reuse the old contents**.
-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";
-  sha256 = "";
-};
-```
-
-Use the resulting error message to determine the correct hash.
-
-```
-error: hash mismatch in fixed-output derivation '/path/to/my.drv':
-         specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
-            got:    sha256-RApQUm78dswhBLC/rfU9y0u6pSAzHceIJqgmetRD24E=
-```
-
-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.
+For those who develop and maintain fetchers, a similar problem arises with changes to the implementation of a fetcher. These may cause a fixed output derivation to fail, but won't normally be caught by tests because the supposed output is already in the store or cache. For the purpose of testing, you can use a trick that is embodied by the [`invalidateFetcherByDrvHash`](#tester-invalidateFetcherByDrvHash) function. It uses the derivation `name` to create a unique output path per fetcher implementation, defeating the caching precisely where it would be harmful.
 
 ## `fetchurl` and `fetchzip` {#fetchurl}
 
@@ -65,20 +26,8 @@ stdenv.mkDerivation {
 
 The main difference between `fetchurl` and `fetchzip` is in how they store the contents. `fetchurl` will store the unaltered contents of the URL within the Nix store. `fetchzip` on the other hand, will decompress the archive for you, making files and directories directly accessible in the future. `fetchzip` can only be used with archives. Despite the name, `fetchzip` is not limited to .zip files and can also be used with any tarball.
 
-## `fetchpatch` {#fetchpatch}
-
 `fetchpatch` works very similarly to `fetchurl` with the same arguments expected. It expects patch files as a source and performs normalization on them before computing the checksum. For example, it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
 
-- `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.
-- `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 `sha256` argument is changed as well.
-
-
 Most other fetchers return a directory rather than a single file.
 
 ## `fetchsvn` {#fetchsvn}
@@ -91,7 +40,7 @@ Used with Git. Expects `url` to a Git repo, `rev`, and `sha256`. `rev` in this c
 
 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.
 
-If only parts of the repository are needed, `sparseCheckout` can be used. This will prevent git from fetching unnecessary blobs from server, see [git sparse-checkout](https://git-scm.com/docs/git-sparse-checkout) for more information:
+If only parts of the repository are needed, `sparseCheckout` can be used. This will prevent git from fetching unnecessary blobs from server, see [git sparse-checkout](https://git-scm.com/docs/git-sparse-checkout) and [git clone --filter](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---filterltfilter-specgt) for more information:
 
 ```nix
 { stdenv, fetchgit }:
@@ -100,10 +49,10 @@ stdenv.mkDerivation {
   name = "hello";
   src = fetchgit {
     url = "https://...";
-    sparseCheckout = [
-      "directory/to/be/included"
-      "another/directory"
-    ];
+    sparseCheckout = ''
+      path/to/be/included
+      another/path
+    '';
     sha256 = "0000000000000000000000000000000000000000000000000000";
   };
 }

doc/builders/images.xml

@@ -9,5 +9,4 @@
  <xi:include href="images/dockertools.section.xml" />
  <xi:include href="images/ocitools.section.xml" />
  <xi:include href="images/snaptools.section.xml" />
- <xi:include href="images/portableservice.section.xml" />
 </chapter>

doc/builders/images/dockertools.section.md

@@ -20,12 +20,7 @@ buildImage {
   fromImageName = null;
   fromImageTag = "latest";
 
-  copyToRoot = pkgs.buildEnv {
-    name = "image-root";
-    paths = [ pkgs.redis ];
-    pathsToLink = [ "/bin" ];
-  };
-
+  contents = pkgs.redis;
   runAsRoot = ''
     #!${pkgs.runtimeShell}
     mkdir -p /data
@@ -36,9 +31,6 @@ buildImage {
     WorkingDir = "/data";
     Volumes = { "/data" = { }; };
   };
-
-  diskSize = 1024;
-  buildVMMemorySize = 512;
 }
 ```
 
@@ -54,7 +46,7 @@ The above example will build a Docker image `redis/latest` from the given base i
 
 - `fromImageTag` can be used to further specify the tag of the base image within the repository, in case an image contains multiple tags. By default it's `null`, in which case `buildImage` will peek the first tag available for the base image.
 
-- `copyToRoot` is a derivation that will be copied in the new layer of the resulting image. This can be similarly seen as `ADD contents/ /` in a `Dockerfile`. By default it's `null`.
+- `contents` is a derivation that will be copied in the new layer of the resulting image. This can be similarly seen as `ADD contents/ /` in a `Dockerfile`. By default it's `null`.
 
 - `runAsRoot` is a bash script that will run as root in an environment that overlays the existing layers of the base image with the new resulting layer, including the previously copied `contents` derivation. This can be similarly seen as `RUN ...` in a `Dockerfile`.
 
@@ -62,10 +54,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).
 
-- `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.
-
 After the new layer has been created, its closure (to which `contents`, `config` and `runAsRoot` contribute) will be copied in the layer itself. Only new dependencies that are not already in the existing layers will be copied.
 
 At the end of the process, only one new single layer will be produced and added to the resulting image.
@@ -93,11 +81,7 @@ pkgs.dockerTools.buildImage {
   name = "hello";
   tag = "latest";
   created = "now";
-  copyToRoot = pkgs.buildEnv {
-    name = "image-root";
-    paths = [ pkgs.hello ];
-    pathsToLink = [ "/bin" ];
-  };
+  contents = pkgs.hello;
 
   config.Cmd = [ "/bin/hello" ];
 }
@@ -308,44 +292,7 @@ The parameters relative to the base image have the same synopsis as described in
 
 The `name` argument is the name of the derivation output, which defaults to `fromImage.name`.
 
-## Environment Helpers {#ssec-pkgs-dockerTools-helpers}
-
-Some packages expect certain files to be available globally.
-When building an image from scratch (i.e. without `fromImage`), these files are missing.
-`pkgs.dockerTools` provides some helpers to set up an environment with the necessary files.
-You can include them in `copyToRoot` like this:
-
-```nix
-buildImage {
-  name = "environment-example";
-  copyToRoot = with pkgs.dockerTools; [
-    usrBinEnv
-    binSh
-    caCertificates
-    fakeNss
-  ];
-}
-```
-
-### usrBinEnv {#sssec-pkgs-dockerTools-helpers-usrBinEnv}
-
-This provides the `env` utility at `/usr/bin/env`.
-
-### binSh {#sssec-pkgs-dockerTools-helpers-binSh}
-
-This provides `bashInteractive` at `/bin/sh`.
-
-### caCertificates {#sssec-pkgs-dockerTools-helpers-caCertificates}
-
-This sets up `/etc/ssl/certs/ca-certificates.crt`.
-
-### fakeNss {#sssec-pkgs-dockerTools-helpers-fakeNss}
-
-Provides `/etc/passwd` and `/etc/group` that contain root and nobody.
-Useful when packaging binaries that insist on using nss to look up
-username/groups (like nginx).
-
-### shadowSetup {#ssec-pkgs-dockerTools-shadowSetup}
+## shadowSetup {#ssec-pkgs-dockerTools-shadowSetup}
 
 This constant string is a helper for setting up the base files for managing users and groups, only if such files don't exist already. It is suitable for being used in a [`buildImage` `runAsRoot`](#ex-dockerTools-buildImage-runAsRoot) script for cases like in the example below:
 
@@ -355,7 +302,7 @@ buildImage {
 
   runAsRoot = ''
     #!${pkgs.runtimeShell}
-    ${pkgs.dockerTools.shadowSetup}
+    ${shadowSetup}
     groupadd -r redis
     useradd -r -g redis redis
     mkdir /data
@@ -365,32 +312,3 @@ buildImage {
 ```
 
 Creating base files like `/etc/passwd` or `/etc/login.defs` is necessary for shadow-utils to manipulate users and groups.
-
-## fakeNss {#ssec-pkgs-dockerTools-fakeNss}
-
-If your primary goal is providing a basic skeleton for user lookups to work,
-and/or a lesser privileged user, adding `pkgs.fakeNss` to
-the container image root might be the better choice than a custom script
-running `useradd` and friends.
-
-It provides a `/etc/passwd` and `/etc/group`, containing `root` and `nobody`
-users and groups.
-
-It also provides a `/etc/nsswitch.conf`, configuring NSS host resolution to
-first check `/etc/hosts`, before checking DNS, as the default in the absence of
-a config file (`dns [!UNAVAIL=return] files`) is quite unexpected.
-
-You can pair it with `binSh`, which provides `bin/sh` as a symlink
-to `bashInteractive` (as `/bin/sh` is configured as a shell).
-
-```nix
-buildImage {
-  name = "shadow-basic";
-
-  copyToRoot = pkgs.buildEnv {
-    name = "image-root";
-    paths = [ binSh pkgs.fakeNss ];
-    pathsToLink = [ "/bin" "/etc" "/var" ];
-  };
-}
-```

doc/builders/images/portableservice.section.md

@@ -1,81 +0,0 @@
-# pkgs.portableService {#sec-pkgs-portableService}
-
-`pkgs.portableService` is a function to create _portable service images_,
-as read-only, immutable, `squashfs` archives.
-
-systemd supports a concept of [Portable Services](https://systemd.io/PORTABLE_SERVICES/).
-Portable Services are a delivery method for system services that uses two specific features of container management:
-
-* Applications are bundled. I.e. multiple services, their binaries and
-  all their dependencies are packaged in an image, and are run directly from it.
-* Stricter default security policies, i.e. sandboxing of applications.
-
-This allows using Nix to build images which can be run on many recent Linux distributions.
-
-The primary tool for interacting with Portable Services is `portablectl`,
-and they are managed by the `systemd-portabled` system service.
-
-::: {.note}
-Portable services are supported starting with systemd 239 (released on 2018-06-22).
-:::
-
-A very simple example of using `portableService` is described below:
-
-[]{#ex-pkgs-portableService}
-
-```nix
-pkgs.portableService {
-  pname = "demo";
-  version = "1.0";
-  units = [ demo-service demo-socket ];
-}
-```
-
-The above example will build an squashfs archive image in `result/$pname_$version.raw`. The image will contain the
-file system structure as required by the portable service specification, and a subset of the Nix store with all the
-dependencies of the two derivations in the `units` list.
-`units` must be a list of derivations, and their names must be prefixed with the service name (`"demo"` in this case).
-Otherwise `systemd-portabled` will ignore them.
-
-::: {.note}
-The `.raw` file extension of the image is required by the portable services specification.
-:::
-
-Some other options available are:
-- `description`, `homepage`
-
-  Are added to the `/etc/os-release` in the image and are shown by the portable services tooling.
-  Default to empty values, not added to os-release.
-- `symlinks`
-
-  A list of attribute sets {object, symlink}. Symlinks will be created  in the root filesystem of the image to
-  objects in the Nix store. Defaults to an empty list.
-- `contents`
-
-  A list of additional derivations to be included in the image Nix store, as-is. Defaults to an empty list.
-- `squashfsTools`
-
-  Defaults to `pkgs.squashfsTools`, allows you to override the package that provides `mksquashfs`.
-- `squash-compression`, `squash-block-size`
-
-  Options to `mksquashfs`. Default to `"xz -Xdict-size 100%"` and `"1M"` respectively.
-
-A typical usage of `symlinks` would be:
-```nix
-  symlinks = [
-    { object = "${pkgs.cacert}/etc/ssl"; symlink = "/etc/ssl"; }
-    { object = "${pkgs.bash}/bin/bash"; symlink = "/bin/sh"; }
-    { object = "${pkgs.php}/bin/php"; symlink = "/usr/bin/php"; }
-  ];
-```
-to create these symlinks for legacy applications that assume them existing globally.
-
-Once the image is created, and deployed on a host in `/var/lib/portables/`, you can attach the image and run the service. As root run:
-```console
-portablectl attach demo_1.0.raw
-systemctl enable --now demo.socket
-systemctl enable --now demo.service
-```
-::: {.note}
-See the [man page](https://www.freedesktop.org/software/systemd/man/portablectl.html) of `portablectl` for more info on its usage.
-:::

doc/builders/packages/firefox.section.md

@@ -26,14 +26,10 @@ The `wrapFirefox` function allows to pass policies, preferences and extensions t
         Pocket = false;
         Snippets = false;
       };
-      UserMessaging = {
-        ExtensionRecommendations = false;
-        SkipOnboarding = true;
-      };
-      SecurityDevices = {
-        # Use a proxy module rather than `nixpkgs.config.firefox.smartcardSupport = true`
-        "PKCS#11 Proxy Module" = "${pkgs.p11-kit}/lib/p11-kit-proxy.so";
-      };
+       UserMessaging = {
+         ExtensionRecommendations = false;
+         SkipOnboarding = true;
+       };
     };
 
     extraPrefs = ''

doc/builders/packages/unfree.xml

@@ -0,0 +1,13 @@
+<section xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xml:id="unfree-software">
+ <title>Unfree software</title>
+
+ <para>
+  All users of Nixpkgs are free software users, and many users (and developers) of Nixpkgs want to limit and tightly control their exposure to unfree software. At the same time, many users need (or want) to run some specific pieces of proprietary software. Nixpkgs includes some expressions for unfree software packages. By default unfree software cannot be installed and doesn’t show up in searches. To allow installing unfree software in a single Nix invocation one can export <literal>NIXPKGS_ALLOW_UNFREE=1</literal>. For a persistent solution, users can set <literal>allowUnfree</literal> in the Nixpkgs configuration.
+ </para>
+
+ <para>
+  Fine-grained control is possible by defining <literal>allowUnfreePredicate</literal> function in config; it takes the <literal>mkDerivation</literal> parameter attrset and returns <literal>true</literal> for unfree packages that should be allowed.
+ </para>
+</section>

doc/builders/testers.chapter.md

@@ -14,89 +14,19 @@ for example when using an 'old' hash in a fixed-output derivation.
 Examples:
 
 ```nix
-passthru.tests.version = testers.testVersion { package = hello; };
+passthru.tests.version = testVersion { package = hello; };
 
-passthru.tests.version = testers.testVersion {
+passthru.tests.version = testVersion {
   package = seaweedfs;
   command = "weed version";
 };
 
-passthru.tests.version = testers.testVersion {
+passthru.tests.version = testVersion {
   package = key;
   command = "KeY --help";
   # Wrong '2.5' version in the code. Drop on next version.
   version = "2.5";
 };
-
-passthru.tests.version = testers.testVersion {
-  package = ghr;
-  # The output needs to contain the 'version' string without any prefix or suffix.
-  version = "v${version}";
-};
-```
-
-## `testBuildFailure` {#tester-testBuildFailure}
-
-Make sure that a build does not succeed. This is useful for testing testers.
-
-This returns a derivation with an override on the builder, with the following effects:
-
- - Fail the build when the original builder succeeds
- - Move `$out` to `$out/result`, if it exists (assuming `out` is the default output)
- - Save the build log to `$out/testBuildFailure.log` (same)
-
-Example:
-
-```nix
-runCommand "example" {
-  failed = testers.testBuildFailure (runCommand "fail" {} ''
-    echo ok-ish >$out
-    echo failing though
-    exit 3
-  '');
-} ''
-  grep -F 'ok-ish' $failed/result
-  grep -F 'failing though' $failed/testBuildFailure.log
-  [[ 3 = $(cat $failed/testBuildFailure.exit) ]]
-  touch $out
-'';
-```
-
-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.
- - `stdout` and `stderr` are a pipe instead of a tty. This could be improved.
- - One or two extra processes are present in the sandbox during the original
-   builder's execution.
- - The derivation and output hashes are different, but not unusual.
- - The derivation includes a dependency on `buildPackages.bash` and
-   `expect-failure.sh`, which is built to include a transitive dependency on
-   `buildPackages.coreutils` and possibly more. These are not added to `PATH`
-   or any other environment variable, so they should be hard to observe.
-
-## `testEqualContents` {#tester-equalContents}
-
-Check that two paths have the same contents.
-
-Example:
-
-```nix
-testers.testEqualContents {
-  assertion = "sed -e performs replacement";
-  expected = writeText "expected" ''
-    foo baz baz
-  '';
-  actual = runCommand "actual" {
-    # not really necessary for a package that's in stdenv
-    nativeBuildInputs = [ gnused ];
-    base = writeText "base" ''
-      foo bar baz
-    '';
-  } ''
-    sed -e 's/bar/baz/g' $base >$out
-  '';
-}
 ```
 
 ## `testEqualDerivation` {#tester-testEqualDerivation}
@@ -112,7 +42,7 @@ Otherwise, the build log explains the difference via `nix-diff`.
 Example:
 
 ```nix
-testers.testEqualDerivation
+testEqualDerivation
   "The hello package must stay the same when enabling checks."
   hello
   (hello.overrideAttrs(o: { doCheck = true; }))
@@ -143,7 +73,7 @@ fixed output derivation.
 Example:
 
 ```nix
-tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
+tests.fetchgit = invalidateFetcherByDrvHash fetchgit {
   name = "nix-source";
   url = "https://github.com/NixOS/nix";
   rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a";

doc/contributing/coding-conventions.chapter.md

@@ -338,10 +338,6 @@ A (typically large) program with a distinct user interface, primarily used inter
 
   - `applications/terminal-emulators` (e.g. `alacritty` or `rxvt` or `termite`)
 
-- **If it’s a _file manager_:**
-
-  - `applications/file-managers` (e.g. `mc` or `ranger` or `pcmanfm`)
-
 - **If it’s for _video playback / editing_:**
 
   - `applications/video` (e.g. `vlc`)
@@ -453,10 +449,7 @@ In the file `pkgs/top-level/all-packages.nix` you can find fetch helpers, these
   }
   ```
 
-When fetching from GitHub, commits must always be referenced by their full commit hash. This is because GitHub shares commit hashes among all forks and returns `404 Not Found` when a short commit hash is ambiguous. It already happens for some short, 6-character commit hashes in `nixpkgs`.
-It is a practical vector for a denial-of-service attack by pushing large amounts of auto generated commits into forks and was already [demonstrated against GitHub Actions Beta](https://blog.teddykatz.com/2019/11/12/github-actions-dos.html).
-
-Find the value to put as `sha256` by running `nix-shell -p nix-prefetch-github --run "nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS nix"`. 
+  Find the value to put as `sha256` by running `nix run -f '<nixpkgs>' nix-prefetch-github -c nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS nix` or `nix-prefetch-url --unpack https://github.com/NixOS/nix/archive/1f795f9f44607cc5bec70d1300150bfefcef2aae.tar.gz`.
 
 ## Obtaining source hash {#sec-source-hashes}
 
@@ -480,23 +473,15 @@ Preferred source hash type is sha256. There are several ways to get it.
 
 4. Extracting hash from local source tarball can be done with `sha256sum`. Use `nix-prefetch-url file:///path/to/tarball` if you want base32 hash.
 
-5. Fake hash: set the hash to one of
+5. Fake hash: set fake hash in package expression, perform build and extract correct hash from error Nix prints.
 
-   - `""`
-   - `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).
-   :::
+    For package updates it is enough to change one symbol to make hash fake. For new packages, you can use `lib.fakeSha256`, `lib.fakeSha512` or any other fake hash.
 
     This is last resort method when reconstructing source URL is non-trivial and `nix-prefetch-url -A` isn’t applicable (for example, [one of `kodi` dependencies](https://github.com/NixOS/nixpkgs/blob/d2ab091dd308b99e4912b805a5eb088dd536adb9/pkgs/applications/video/kodi/default.nix#L73)). The easiest way then would be replace hash with a fake one and rebuild. Nix build will fail and error message will contain desired hash.
 
+::: {.warning}
+This method has security problems. Check below for details.
+:::
 
 ### Obtaining hashes securely {#sec-source-hashes-security}
 
@@ -508,7 +493,7 @@ Let's say Man-in-the-Middle (MITM) sits close to your network. Then instead of f
 
 - `https://` URLs are secure in methods 1, 2, 3;
 
-- `https://` URLs are secure in method 5 *only if* you use one of the listed fake hashes. If you use any other hash, `fetchurl` will pass `--insecure` to `curl` and may then degrade to HTTP in case of TLS certificate expiration.
+- `https://` URLs are not secure in method 5. When obtaining hashes with fake hash method, TLS checks are disabled. So refetch source hash from several different networks to exclude MITM scenario. Alternatively, use fake hash method to make Nix error, but instead of extracting hash from error, extract `https://` URL and prefetch it with method 1.
 
 ## Patches {#sec-patches}
 
@@ -526,8 +511,6 @@ patches = [
 
 Otherwise, you can add a `.patch` file to the `nixpkgs` repository. In the interest of keeping our maintenance burden to a minimum, only patches that are unique to `nixpkgs` should be added in this way.
 
-If a patch is available online but does not cleanly apply, it can be modified in some fixed ways by using additional optional arguments for `fetchpatch`. Check [](#fetchpatch) for details.
-
 ```nix
 patches = [ ./0001-changes.patch ];
 ```
@@ -555,6 +538,17 @@ If you do need to do create this sort of patch file, one way to do so is with gi
     $ git diff -a > nixpkgs/pkgs/the/package/0001-changes.patch
     ```
 
+If a patch is available online but does not cleanly apply, it can be modified in some fixed ways by using additional optional arguments for `fetchpatch`:
+
+- `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.
+- `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 `sha256` argument is changed as well.
+
 ## Package tests {#sec-package-tests}
 
 Tests are important to ensure quality and make reviews and automatic updates easy.

doc/contributing/contributing-to-documentation.chapter.md

@@ -27,7 +27,7 @@ If the build succeeds, the manual will be in `./result/share/doc/nixpkgs/manual.
 
 As per [RFC 0072](https://github.com/NixOS/rfcs/pull/72), all new documentation content should be written in [CommonMark](https://commonmark.org/) Markdown dialect.
 
-Additional syntax extensions are available, though not all extensions can be used in NixOS option documentation. The following extensions are currently used:
+Additionally, the following syntax 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).
@@ -53,24 +53,12 @@ Additional syntax extensions are available, though not all extensions can be use
   This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/using/syntax.html#targets-and-cross-referencing).
 
 - []{#ssec-contributing-markup-inline-roles}
-  If you want to link to a man page, you can use `` {manpage}`nix.conf(5)` ``, which will turn into {manpage}`nix.conf(5)`. The references will turn into links when a mapping exists in {file}`doc/build-aux/pandoc-filters/link-unix-man-references.lua`.
+  If you want to link to a man page, you can use `` {manpage}`nix.conf(5)` ``, which will turn into {manpage}`nix.conf(5)`.
 
-  A few markups for other kinds of literals are also available:
-
-  - `` {command}`rm -rfi` `` turns into {command}`rm -rfi`
-  - `` {env}`XDG_DATA_DIRS` `` turns into {env}`XDG_DATA_DIRS`
-  - `` {file}`/etc/passwd` `` turns into {file}`/etc/passwd`
-  - `` {option}`networking.useDHCP` `` turns into {option}`networking.useDHCP`
-  - `` {var}`/etc/passwd` `` turns into {var}`/etc/passwd`
-
-  These literal kinds are used mostly in NixOS option documentation.
+  The references will turn into links when a mapping exists in {file}`doc/build-aux/pandoc-filters/link-unix-man-references.lua`.
 
   This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html#roles-an-in-line-extension-point). Though, the feature originates from [reStructuredText](https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-manpage) with slightly different syntax.
 
-  ::: {.note}
-  Inline roles are available for option documentation.
-  :::
-
 - []{#ssec-contributing-markup-admonitions}
   **Admonitions**, set off from the text to bring attention to something.
 
@@ -96,10 +84,6 @@ Additional syntax extensions are available, though not all extensions can be use
     - [`tip`](https://tdg.docbook.org/tdg/5.0/tip.html)
     - [`warning`](https://tdg.docbook.org/tdg/5.0/warning.html)
 
-  ::: {.note}
-  Admonitions are available for option documentation.
-  :::
-
 - []{#ssec-contributing-markup-definition-lists}
   [**Definition lists**](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/definition_lists.md), for defining a group of terms:
 

doc/contributing/reviewing-contributions.chapter.md

@@ -185,111 +185,6 @@ Sample template for a new module review is provided below.
 ##### Comments
 ```
 
-## Individual maintainer list {#reviewing-contributions-indvidual-maintainer-list}
-
-When adding users to `maintainers/maintainer-list.nix`, the following
-checks should be performed:
-
--   If the user has specified a GPG key, verify that the commit is
-    signed by their key.
-
-    First, validate that the commit adding the maintainer is signed by
-    the key the maintainer listed. Check out the pull request and
-    compare its signing key with the listed key in the commit.
-
-    If the commit is not signed or it is signed by a different user, ask
-    them to either recommit using that key or to remove their key
-    information.
-
-    Given a maintainter entry like this:
-
-    ``` nix
-    {
-      example = {
-        email = "user@example.com";
-        name = "Example User";
-        keys = [{
-          fingerprint = "0000 0000 2A70 6423 0AED  3C11 F04F 7A19 AAA6 3AFE";
-        }];
-      }
-    };
-    ```
-
-    First receive their key from a keyserver:
-
-        $ gpg --recv-keys 0xF04F7A19AAA63AFE
-        gpg: key 0xF04F7A19AAA63AFE: public key "Example <user@example.com>" imported
-        gpg: Total number processed: 1
-        gpg:               imported: 1
-
-    Then check the commit is signed by that key:
-
-        $ git log --show-signature
-        commit b87862a4f7d32319b1de428adb6cdbdd3a960153
-        gpg: Signature made Wed Mar 12 13:32:24 2003 +0000
-        gpg:                using RSA key 000000002A7064230AED3C11F04F7A19AAA63AFE
-        gpg: Good signature from "Example User <user@example.com>
-        Author: Example User <user@example.com>
-        Date:   Wed Mar 12 13:32:24 2003 +0000
-
-            maintainers: adding example
-
-    and validate that there is a `Good signature` and the printed key
-    matches the user's submitted key.
-
-    Note: GitHub's "Verified" label does not display the user's full key
-    fingerprint, and should not be used for validating the key matches.
-
--   If the user has specified a `github` account name, ensure they have
-    also specified a `githubId` and verify the two match.
-
-    Maintainer entries that include a `github` field must also include
-    their `githubId`. People can and do change their GitHub name
-    frequently, and the ID is used as the official and stable identity
-    of the maintainer.
-
-    Given a maintainer entry like this:
-
-    ``` nix
-    {
-      example = {
-        email = "user@example.com";
-        name = "Example User";
-        github = "ghost";
-        githubId = 10137;
-      }
-    };
-    ```
-
-    First, make sure that the listed GitHub handle matches the author of
-    the commit.
-
-    Then, visit the URL `https://api.github.com/users/ghost` and
-    validate that the `id` field matches the provided `githubId`.
-
-## Maintainer teams {#reviewing-contributions-maintainer-teams}
-
-Feel free to create a new maintainer team in `maintainers/team-list.nix`
-when a group is collectively responsible for a collection of packages.
-Use taste and personal judgement when deciding if a team is warranted.
-
-Teams are allowed to define their own rules about membership.
-
-For example, some teams will represent a business or other group which
-wants to carefully track its members. Other teams may be very open about
-who can join, and allow anybody to participate.
-
-When reviewing changes to a team, read the team's scope and the context
-around the member list for indications about the team's membership
-policy.
-
-In any case, request reviews from the existing team members. If the team
-lists no specific membership policy, feel free to merge changes to the
-team after giving the existing members a few days to respond.
-
-*Important:* If a team says it is a closed group, do not merge additions
-to the team without an approval by at least one existing member.
-
 ## Other submissions {#reviewing-contributions-other-submissions}
 
 Other type of submissions requires different reviewing steps.
@@ -302,12 +197,6 @@ Container system, boot system and library changes are some examples of the pull
 
 It is possible for community members that have enough knowledge and experience on a special topic to contribute by merging pull requests.
 
-In case the PR is stuck waiting for the original author to apply a trivial
-change (a typo, capitalisation change, etc.) and the author allowed the members
-to modify the PR, consider applying it yourself. (or commit the existing review
-suggestion) You should pay extra attention to make sure the addition doesn't go
-against the idea of the original PR and would not be opposed by the author.
-
 <!--
 The following paragraphs about how to deal with unactive contributors is just a proposition and should be modified to what the community agrees to be the right policy.
 

doc/contributing/submitting-changes.chapter.md

@@ -167,30 +167,24 @@ Packages with automated tests are much more likely to be merged in a timely fash
 
 ### Tested compilation of all pkgs that depend on this change using `nixpkgs-review` {#submitting-changes-tested-compilation}
 
-If you are updating a package’s version, you can use `nixpkgs-review` to make sure all packages that depend on the updated package still compile correctly. The `nixpkgs-review` utility can look for and build all dependencies either based on uncommitted changes with the `wip` option or specifying a GitHub pull request number.
+If you are updating a package’s version, you can use nixpkgs-review to make sure all packages that depend on the updated package still compile correctly. The `nixpkgs-review` utility can look for and build all dependencies either based on uncommited changes with the `wip` option or specifying a github pull request number.
 
-Review changes from pull request number 12345:
+review changes from pull request number 12345:
 
 ```ShellSession
-nix-shell -p nixpkgs-review --run "nixpkgs-review pr 12345"
+nix run nixpkgs.nixpkgs-review -c nixpkgs-review pr 12345
 ```
 
-Alternatively, with flakes (and analogously for the other commands below):
+review uncommitted changes:
 
 ```ShellSession
-nix run nixpkgs#nixpkgs-review -- pr 12345
+nix run nixpkgs.nixpkgs-review -c nixpkgs-review wip
 ```
 
-Review uncommitted changes:
+review changes from last commit:
 
 ```ShellSession
-nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
-```
-
-Review changes from last commit:
-
-```ShellSession
-nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
+nix run nixpkgs.nixpkgs-review -c nixpkgs-review rev HEAD
 ```
 
 ### Tested execution of all binary files (usually in `./result/bin/`) {#submitting-changes-tested-execution}
@@ -233,7 +227,7 @@ digraph {
 }
 ```
 
-[This GitHub Action](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/periodic-merge-6h.yml) brings changes from `master` to `staging-next` and from `staging-next` to `staging` every 6 hours; these are the blue arrows in the diagram above.  The purple arrows in the diagram above are done manually and much less frequently.  You can get an idea of how often these merges occur by looking at the git history.
+[This GitHub Action](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/periodic-merge-6h.yml) brings changes from `master` to `staging-next` and from `staging-next` to `staging` every 6 hours.
 
 
 ### Master branch {#submitting-changes-master-branch}
@@ -244,16 +238,12 @@ The `master` branch is the main development branch. It should only see non-break
 
 The `staging` branch is a development branch where mass-rebuilds go. Mass rebuilds are commits that cause rebuilds for many packages, like more than 500 (or perhaps, if it's 'light' packages, 1000). It should only see non-breaking mass-rebuild commits. That means it is not to be used for testing, and changes must have been well tested already. If the branch is already in a broken state, please refrain from adding extra new breakages.
 
-During the process of a releasing a new NixOS version, this branch or the release-critical packages can be restricted to non-breaking changes.
-
 ### Staging-next branch {#submitting-changes-staging-next-branch}
 
-The `staging-next` branch is for stabilizing mass-rebuilds submitted to the `staging` branch prior to merging them into `master`. Mass-rebuilds must go via the `staging` branch. It must only see non-breaking commits that are fixing issues blocking it from being merged into the `master` branch.
+The `staging-next` branch is for stabilizing mass-rebuilds submitted to the `staging` branch prior to merging them into `master`. Mass-rebuilds must go via the `staging` branch. It must only see non-breaking commits that are fixing issues blocking it from being merged into the `master ` branch.
 
 If the branch is already in a broken state, please refrain from adding extra new breakages. Stabilize it for a few days and then merge into master.
 
-During the process of a releasing a new NixOS version, this branch or the release-critical packages can be restricted to non-breaking changes.
-
 ### Stable release branches {#submitting-changes-stable-release-branches}
 
 The same staging workflow applies to stable release branches, but the main branch is called `release-*` instead of `master`.

doc/doc-support/default.nix

@@ -1,8 +1,5 @@
 { pkgs ? (import ../.. {}), nixpkgs ? { }}:
 let
-  inherit (pkgs) lib;
-  inherit (lib) hasPrefix removePrefix;
-
   locationsXml = import ./lib-function-locations.nix { inherit pkgs nixpkgs; };
   functionDocs = import ./lib-function-docs.nix { inherit locationsXml pkgs; };
   version = pkgs.lib.version;
@@ -32,18 +29,6 @@ let
   optionsDoc = pkgs.nixosOptionsDoc {
     inherit (pkgs.lib.evalModules { modules = [ ../../pkgs/top-level/config.nix ]; }) options;
     documentType = "none";
-    transformOptions = opt:
-      opt // {
-        declarations =
-          map
-            (decl:
-              if hasPrefix (toString ../..) (toString decl)
-              then
-                let subpath = removePrefix "/" (removePrefix (toString ../..) (toString decl));
-                in { url = "https://github.com/NixOS/nixpkgs/blob/master/${subpath}"; name = subpath; }
-              else decl)
-            opt.declarations;
-        };
   };
 
 in pkgs.runCommand "doc-support" {}

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

@@ -22,7 +22,6 @@ with pkgs; stdenv.mkDerivation {
     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/parameters.xml

@@ -11,5 +11,4 @@
  <xsl:param name="toc.section.depth" select="0" />
  <xsl:param name="admon.style" select="''" />
  <xsl:param name="callout.graphics.extension" select="'.svg'" />
- <xsl:param name="generate.consistent.ids" select="1" />
 </xsl:stylesheet>

doc/functions/library.xml

@@ -26,7 +26,5 @@
 
  <xi:include href="./library/generated/options.xml" />
 
- <xi:include href="./library/generated/filesystem.xml" />
-
  <xi:include href="./library/generated/sources.xml" />
 </section>

doc/hooks/autoconf.section.md

@@ -1,4 +0,0 @@
-
-### Autoconf {#setup-hook-autoconf}
-
-The `autoreconfHook` derivation adds `autoreconfPhase`, which runs autoreconf, libtoolize and automake, essentially preparing the configure script in autotools-based builds. Most autotools-based packages come with the configure script pre-generated, but this hook is necessary for a few packages and when you need to patch the package’s configure scripts.

doc/hooks/automake.section.md

@@ -1,4 +0,0 @@
-
-### Automake {#setup-hook-automake}
-
-Adds the `share/aclocal` subdirectory of each build input to the `ACLOCAL_PATH` environment variable.

doc/hooks/autopatchelf.section.md

@@ -1,12 +0,0 @@
-
-### autoPatchelfHook {#setup-hook-autopatchelfhook}
-
-This is a special setup hook which helps in packaging proprietary software in that it automatically tries to find missing shared library dependencies of ELF files based on the given `buildInputs` and `nativeBuildInputs`.
-
-You can also specify a `runtimeDependencies` variable which lists dependencies to be unconditionally added to rpath of all executables. This is useful for programs that use dlopen 3 to load libraries at runtime.
-
-In certain situations you may want to run the main command (`autoPatchelf`) of the setup hook on a file or a set of directories instead of unconditionally patching all outputs. This can be done by setting the `dontAutoPatchelf` environment variable to a non-empty value.
-
-By default `autoPatchelf` will fail as soon as any ELF file requires a dependency which cannot be resolved via the given build inputs. In some situations you might prefer to just leave missing dependencies unpatched and continue to patch the rest. This can be achieved by setting the `autoPatchelfIgnoreMissingDeps` environment variable to a non-empty value. `autoPatchelfIgnoreMissingDeps` can be set to a list like `autoPatchelfIgnoreMissingDeps = [ "libcuda.so.1" "libcudart.so.1" ];` or to simply `[ "*" ]` to ignore all missing dependencies.
-
-The `autoPatchelf` command also recognizes a `--no-recurse` command line flag, which prevents it from recursing into subdirectories.

doc/hooks/breakpoint.section.md

@@ -1,18 +0,0 @@
-
-### breakpointHook {#breakpointhook}
-
-This hook will make a build pause instead of stopping when a failure happens. It prevents nix from cleaning up the build environment immediately and allows the user to attach to a build environment using the `cntr` command. Upon build error it will print instructions on how to use `cntr`, which can be used to enter the environment for debugging. Installing cntr and running the command will provide shell access to the build sandbox of failed build. At `/var/lib/cntr` the sandboxed filesystem is mounted. All commands and files of the system are still accessible within the shell. To execute commands from the sandbox use the cntr exec subcommand. `cntr` is only supported on Linux-based platforms. To use it first add `cntr` to your `environment.systemPackages` on NixOS or alternatively to the root user on non-NixOS systems. Then in the package that is supposed to be inspected, add `breakpointHook` to `nativeBuildInputs`.
-
-```nix
-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/cmake.section.md

@@ -1,4 +0,0 @@
-
-### cmake {#cmake}
-
-Overrides the default configure phase to run the CMake command. By default, we use the Make generator of CMake. In addition, dependencies are added automatically to `CMAKE_PREFIX_PATH` so that packages are correctly detected by CMake. Some additional flags are passed in to give similar behavior to configure-based packages. You can disable this hook’s behavior by setting `configurePhase` to a custom value, or by setting `dontUseCmakeConfigure`. `cmakeFlags` controls flags passed only to CMake. By default, parallel building is enabled as CMake supports parallel building almost everywhere. When Ninja is also in use, CMake will detect that and use the ninja generator.

doc/hooks/gdk-pixbuf.section.md

@@ -1,4 +0,0 @@
-
-### gdk-pixbuf {#setup-hook-gdk-pixbuf}
-
-Exports `GDK_PIXBUF_MODULE_FILE` environment variable to the builder. Add librsvg package to `buildInputs` to get svg support. See also the [setup hook description in GNOME platform docs](#ssec-gnome-hooks-gdk-pixbuf).

doc/hooks/ghc.section.md

@@ -1,4 +0,0 @@
-
-### GHC {#ghc}
-
-Creates a temporary package database and registers every Haskell build input in it (TODO: how?).

doc/hooks/gnome.section.md

@@ -1,4 +0,0 @@
-
-### GNOME platform {#gnome-platform}
-
-Hooks related to GNOME platform and related libraries like GLib, GTK and GStreamer are described in [](#sec-language-gnome).

doc/hooks/index.xml

@@ -6,32 +6,5 @@
  <para>
   Nixpkgs has several hook packages that augment the stdenv phases.
  </para>
- <para>
-  The stdenv built-in hooks are documented in <xref linkend="ssec-setup-hooks"/>.
- </para>
- <xi:include href="./autoconf.section.xml" />
- <xi:include href="./automake.section.xml" />
- <xi:include href="./autopatchelf.section.xml" />
- <xi:include href="./breakpoint.section.xml" />
- <xi:include href="./cmake.section.xml" />
- <xi:include href="./gdk-pixbuf.section.xml" />
- <xi:include href="./ghc.section.xml" />
- <xi:include href="./gnome.section.xml" />
- <xi:include href="./installShellFiles.section.xml" />
- <xi:include href="./libiconv.section.xml" />
- <xi:include href="./libxml2.section.xml" />
- <xi:include href="./meson.section.xml" />
- <xi:include href="./ninja.section.xml" />
- <xi:include href="./patch-rc-path-hooks.section.xml" />
- <xi:include href="./perl.section.xml" />
- <xi:include href="./pkg-config.section.xml" />
  <xi:include href="./postgresql-test-hook.section.xml" />
- <xi:include href="./python.section.xml" />
- <xi:include href="./qt-4.section.xml" />
- <xi:include href="./scons.section.xml" />
- <xi:include href="./tetex-tex-live.section.xml" />
- <xi:include href="./unzip.section.xml" />
- <xi:include href="./validatePkgConfig.section.xml" />
- <xi:include href="./waf.section.xml" />
- <xi:include href="./xcbuild.section.xml" />
 </chapter>

doc/hooks/installShellFiles.section.md

@@ -1,26 +0,0 @@
-
-### `installShellFiles` {#installshellfiles}
-
-This hook helps with installing manpages and shell completion files. It exposes 2 shell functions `installManPage` and `installShellCompletion` that can be used from your `postInstall` hook.
-
-The `installManPage` function takes one or more paths to manpages to install. The manpages must have a section suffix, and may optionally be compressed (with `.gz` suffix). This function will place them into the correct directory.
-
-The `installShellCompletion` function takes one or more paths to shell completion files. By default it will autodetect the shell type from the completion file extension, but you may also specify it by passing one of `--bash`, `--fish`, or `--zsh`. These flags apply to all paths listed after them (up until another shell flag is given). Each path may also have a custom installation name provided by providing a flag `--name NAME` before the path. If this flag is not provided, zsh completions will be renamed automatically such that `foobar.zsh` becomes `_foobar`. A root name may be provided for all paths using the flag `--cmd NAME`; this synthesizes the appropriate name depending on the shell (e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for zsh). The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which case the shell and name must be provided.
-
-```nix
-nativeBuildInputs = [ installShellFiles ];
-postInstall = ''
-  installManPage doc/foobar.1 doc/barfoo.3
-  # explicit behavior
-  installShellCompletion --bash --name foobar.bash share/completions.bash
-  installShellCompletion --fish --name foobar.fish share/completions.fish
-  installShellCompletion --zsh --name _foobar share/completions.zsh
-  # implicit behavior
-  installShellCompletion share/completions/foobar.{bash,fish,zsh}
-  # using named fd
-  installShellCompletion --cmd foobar \
-    --bash <($out/bin/foobar --bash-completion) \
-    --fish <($out/bin/foobar --fish-completion) \
-    --zsh <($out/bin/foobar --zsh-completion)
-'';
-```

doc/hooks/libiconv.section.md

@@ -1,4 +0,0 @@
-
-### libiconv, libintl {#libiconv-libintl}
-
-A few libraries automatically add to `NIX_LDFLAGS` their library, making their symbols automatically available to the linker. This includes libiconv and libintl (gettext). This is done to provide compatibility between GNU Linux, where libiconv and libintl are bundled in, and other systems where that might not be the case. Sometimes, this behavior is not desired. To disable this behavior, set `dontAddExtraLibs`.

doc/hooks/libxml2.section.md

@@ -1,4 +0,0 @@
-
-### libxml2 {#setup-hook-libxml2}
-
-Adds every file named `catalog.xml` found under the `xml/dtd` and `xml/xsl` subdirectories of each build input to the `XML_CATALOG_FILES` environment variable.

doc/hooks/meson.section.md

@@ -1,26 +0,0 @@
-
-### Meson {#meson}
-
-Overrides the configure phase to run meson to generate Ninja files. To run these files, you should accompany Meson with ninja. By default, `enableParallelBuilding` is enabled as Meson supports parallel building almost everywhere.
-
-#### Variables controlling Meson {#variables-controlling-meson}
-
-##### `mesonFlags` {#mesonflags}
-
-Controls the flags passed to meson.
-
-##### `mesonBuildType` {#mesonbuildtype}
-
-Which [`--buildtype`](https://mesonbuild.com/Builtin-options.html#core-options) to pass to Meson. We default to `plain`.
-
-##### `mesonAutoFeatures` {#mesonautofeatures}
-
-What value to set [`-Dauto_features=`](https://mesonbuild.com/Builtin-options.html#core-options) to. We default to `enabled`.
-
-##### `mesonWrapMode` {#mesonwrapmode}
-
-What value to set [`-Dwrap_mode=`](https://mesonbuild.com/Builtin-options.html#core-options) to. We default to `nodownload` as we disallow network access.
-
-##### `dontUseMesonConfigure` {#dontusemesonconfigure}
-
-Disables using Meson’s `configurePhase`.

doc/hooks/ninja.section.md

@@ -1,4 +0,0 @@
-
-### ninja {#ninja}
-
-Overrides the build, install, and check phase to run ninja instead of make. You can disable this behavior with the `dontUseNinjaBuild`, `dontUseNinjaInstall`, and `dontUseNinjaCheck`, respectively. Parallel building is enabled by default in Ninja.

doc/hooks/patch-rc-path-hooks.section.md

@@ -1,50 +0,0 @@
-
-# `patchRcPath` hooks {#sec-patchRcPathHooks}
-
-These hooks provide shell-specific utilities (with the same name as the hook) to patch shell scripts meant to be sourced by software users.
-
-The typical usage is to patch initialisation or [rc](https://unix.stackexchange.com/questions/3467/what-does-rc-in-bashrc-stand-for) scripts inside `$out/bin` or `$out/etc`.
-Such scripts, when being sourced, would insert the binary locations of certain commands into `PATH`, modify other environment variables or run a series of start-up commands.
-When shipped from the upstream, they sometimes use commands that might not be available in the environment they are getting sourced in.
-
-The compatible shells for each hook are:
-
- - `patchRcPathBash`: [Bash](https://www.gnu.org/software/bash/), [ksh](http://www.kornshell.org/), [zsh](https://www.zsh.org/) and other shells supporting the Bash-like parameter expansions.
- - `patchRcPathCsh`: Csh scripts, such as those targeting [tcsh](https://www.tcsh.org/).
- - `patchRcPathFish`: [Fish](https://fishshell.com/) scripts.
- - `patchRcPathPosix`: POSIX-conformant shells supporting the limited parameter expansions specified by the POSIX standard. Current implementation uses the parameter expansion `${foo-}` only.
-
-For each supported shell, it modifies the script with a `PATH` prefix that is later removed when the script ends.
-It allows nested patching, which guarantees that a patched script may source another patched script.
-
-Syntax to apply the utility to a script:
-
-```sh
-patchRcPath<shell> <file> <PATH-prefix>
-```
-
-Example usage:
-
-Given a package `foo` containing an init script `this-foo.fish` that depends on `coreutils`, `man` and `which`,
-patch the init script for users to source without having the above dependencies in their `PATH`:
-
-```nix
-{ lib, stdenv, patchRcPathFish}:
-stdenv.mkDerivation {
-
-  # ...
-
-  nativeBuildInputs = [
-    patchRcPathFish
-  ];
-
-  postFixup = ''
-    patchRcPathFish $out/bin/this-foo.fish ${lib.makeBinPath [ coreutils man which ]}
-  '';
-}
-```
-
-::: {.note}
-`patchRcPathCsh` and `patchRcPathPosix` implementation depends on `sed` to do the string processing.
-The others are in vanilla shell and have no third-party dependencies.
-:::

doc/hooks/perl.section.md

@@ -1,4 +0,0 @@
-
-### Perl {#setup-hook-perl}
-
-Adds the `lib/site_perl` subdirectory of each build input to the `PERL5LIB` environment variable. For instance, if `buildInputs` contains Perl, then the `lib/site_perl` subdirectory of each input is added to the `PERL5LIB` environment variable.

doc/hooks/pkg-config.section.md

@@ -1,4 +0,0 @@
-
-### pkg-config {#setup-hook-pkg-config}
-
-Adds the `lib/pkgconfig` and `share/pkgconfig` subdirectories of each build input to the `PKG_CONFIG_PATH` environment variable.

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

@@ -40,7 +40,7 @@ Exported variables:
 
 Bash-only variables:
 
- - `postgresqlTestUserOptions`: SQL options to use when creating the `$PGUSER` role, default: `"LOGIN"`. Example: `"LOGIN SUPERUSER"`
+ - `postgresqlTestUserOptions`: SQL options to use when creating the `$PGUSER` role, default: `LOGIN`.
  - `postgresqlTestSetupSQL`: SQL commands to run as database administrator after startup, default: statements that create `$PGUSER` and `$PGDATABASE`.
  - `postgresqlTestSetupCommands`: bash commands to run after database start, defaults to running `$postgresqlTestSetupSQL` as database administrator.
  - `postgresqlEnableTCP`: set to `1` to enable TCP listening. Flaky; not recommended.

doc/hooks/python.section.md

@@ -1,4 +0,0 @@
-
-### Python {#setup-hook-python}
-
-Adds the `lib/${python.libPrefix}/site-packages` subdirectory of each build input to the `PYTHONPATH` environment variable.

doc/hooks/qt-4.section.md

@@ -1,4 +0,0 @@
-
-### Qt 4 {#qt-4}
-
-Sets the `QTDIR` environment variable to Qt’s path.

doc/hooks/scons.section.md

@@ -1,4 +0,0 @@
-
-### scons {#scons}
-
-Overrides the build, install, and check phases. This uses the scons build system as a replacement for make. scons does not provide a configure phase, so everything is managed at build and install time.

doc/hooks/tetex-tex-live.section.md

@@ -1,4 +0,0 @@
-
-### teTeX / TeX Live {#tetex-tex-live}
-
-Adds the `share/texmf-nix` subdirectory of each build input to the `TEXINPUTS` environment variable.

doc/hooks/unzip.section.md

@@ -1,4 +0,0 @@
-
-### unzip {#unzip}
-
-This setup hook will allow you to unzip .zip files specified in `$src`. There are many similar packages like `unrar`, `undmg`, etc.

doc/hooks/validatePkgConfig.section.md

@@ -1,4 +0,0 @@
-
-### validatePkgConfig {#validatepkgconfig}
-
-The `validatePkgConfig` hook validates all pkg-config (`.pc`) files in a package. This helps catching some common errors in pkg-config files, such as undefined variables.

doc/hooks/waf.section.md

@@ -1,4 +0,0 @@
-
-### wafHook {#wafhook}
-
-Overrides the configure, build, and install phases. This will run the “waf” script used by many projects. If `wafPath` (default `./waf`) doesn’t exist, it will copy the version of waf available in Nixpkgs. `wafFlags` can be used to pass flags to the waf script.

doc/hooks/xcbuild.section.md

@@ -1,4 +0,0 @@
-
-### xcbuildHook {#xcbuildhook}
-
-Overrides the build and install phases to run the "xcbuild" command. This hook is needed when a project only comes with build files for the XCode build system. You can disable this behavior by setting buildPhase and configurePhase to a custom value. xcbuildFlags controls flags passed only to xcbuild.

doc/languages-frameworks/coq.section.md

@@ -5,11 +5,9 @@
 The Coq derivation is overridable through the `coq.override overrides`, where overrides is an attribute set which contains the arguments to override. We recommend overriding either of the following
 
 * `version` (optional, defaults to the latest version of Coq selected for nixpkgs, see `pkgs/top-level/coq-packages` to witness this choice), which follows the conventions explained in the `coqPackages` section below,
-* `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).
+* `customOCamlPackage` (optional, defaults to `null`, which lets Coq choose a version automatically), which can be set to any of the ocaml packages attribute of `ocaml-ng` (such as `ocaml-ng.ocamlPackages_4_10` which is the default for Coq 8.11 for example).
 * `coq-version` (optional, defaults to the short version e.g. "8.10"), is a version number of the form "x.y" that indicates which Coq's version build behavior to mimic when using a source which is not a release. E.g. `coq.override { version = "d370a9d1328a4e1cdb9d02ee032f605a9d94ec7a"; coq-version = "8.10"; }`.
 
-The associated package set can be optained using `mkCoqPackages coq`, where `coq` is the derivation to use.
-
 ## Coq packages attribute sets: `coqPackages` {#coq-packages-attribute-sets-coqpackages}
 
 The recommended way of defining a derivation for a Coq library, is to use the `coqPackages.mkCoqDerivation` function, which is essentially a specialization of `mkDerivation` taking into account most of the specifics of Coq libraries. The following attributes are supported:
@@ -31,16 +29,11 @@ The recommended way of defining a derivation for a Coq library, is to use the `c
 * `releaseRev` (optional, defaults to `(v: v)`), provides a default mapping from release names to revision hashes/branch names/tags,
 * `displayVersion` (optional), provides a way to alter the computation of `name` from `pname`, by explaining how to display version numbers,
 * `namePrefix` (optional, defaults to `[ "coq" ]`), provides a way to alter the computation of `name` from `pname`, by explaining which dependencies must occur in `name`,
-* `nativeBuildInputs` (optional), is a list of executables that are required to build the current derivation, in addition to the default ones (namely `which`, `dune` and `ocaml` depending on whether `useDune`, `useDuneifVersion` and `mlPlugin` are set).
-* `extraNativeBuildInputs` (optional, deprecated), an additional list of derivation to add to `nativeBuildInputs`,
-* `overrideNativeBuildInputs` (optional) replaces the default list of derivation to which `nativeBuildInputs` and `extraNativeBuildInputs` adds extra elements,
-* `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 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.
+* `extraNativeBuildInputs` (optional), by default `nativeBuildInputs` just contains `coq`, this allows to add more native build inputs, `nativeBuildInputs` are executables and `buildInputs` are libraries and dependencies,
+* `extraBuildInputs` (optional), this allows to add more build inputs,
+* `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 `extraBuildInputs` to depend on the same package set Coq was built against.
+* `useDune2ifVersion` (optional, default to `(x: false)` uses Dune2 to build the package if the provided predicate evaluates to true on the version, e.g. `useDune2if = versions.isGe "1.1"`  will use dune if the version of the package is greater or equal to `"1.1"`,
+* `useDune2` (optional, defaults to `false`) uses Dune2 to build the package if set to true, the presence of this attribute overrides the behavior of the previous one.
 * `opam-name` (optional, defaults to concatenating with a dash separator the components of `namePrefix` and `pname`), name of the Dune package to build.
 * `enableParallelBuilding` (optional, defaults to `true`), since it is activated by default, we provide a way to disable it.
 * `extraInstallFlags` (optional), allows to extend `installFlags` which initializes the variable `COQMF_COQLIB` so as to install in the proper subdirectory. Indeed Coq libraries should be installed in `$(out)/lib/coq/${coq.coq-version}/user-contrib/`. Such directories are automatically added to the `$COQPATH` environment variable by the hook defined in the Coq derivation.
@@ -88,58 +81,3 @@ with lib; mkCoqDerivation {
   };
 }
 ```
-
-## Three ways of overriding Coq packages {#coq-overriding-packages}
-
-There are three distinct ways of changing a Coq package by overriding one of its values: `.override`, `overrideCoqDerivation`, and `.overrideAttrs`.  This section explains what sort of values can be overridden with each of these methods.
-
-### `.override` {#coq-override}
-
-`.override` lets you change arguments to a Coq derivation.  In the case of the `multinomials` package above, `.override` would let you override arguments like `mkCoqDerivation`, `version`, `coq`, `mathcomp`, `mathcom-finmap`, etc.
-
-For example, assuming you have a special `mathcomp` dependency you want to use, here is how you could override the `mathcomp` dependency:
-
-```nix
-multinomials.override {
-  mathcomp = my-special-mathcomp;
-}
-```
-
-In Nixpkgs, all Coq derivations take a `version` argument.  This can be overridden in order to easily use a different version:
-
-```nix
-coqPackages.multinomials.override {
-  version = "1.5.1";
-}
-```
-
-Refer to [](#coq-packages-attribute-sets-coqpackages) for all the different formats that you can potentially pass to `version`, as well as the restrictions.
-
-### `overrideCoqDerivation` {#coq-overrideCoqDerivation}
-
-The `overrideCoqDerivation` function lets you easily change arguments to `mkCoqDerivation`.  These arguments are described in [](#coq-packages-attribute-sets-coqpackages).
-
-For example, here is how you could locally add a new release of the `multinomials` library, and set the `defaultVersion` to use this release:
-
-```nix
-coqPackages.lib.overrideCoqDerivation
-  {
-    defaultVersion = "2.0";
-    release."2.0".sha256 = "1lq8x86vd3vqqh2yq6hvyagpnhfq5wmk5pg2z0xq7b7dbbbhyfkk";
-  }
-  coqPackages.multinomials
-```
-
-### `.overrideAttrs` {#coq-overrideAttrs}
-
-`.overrideAttrs` lets you override arguments to the underlying `stdenv.mkDerivation` call. Internally, `mkCoqDerivation` uses `stdenv.mkDerivation` to create derivations for Coq libraries.  You can override arguments to `stdenv.mkDerivation` with `.overrideAttrs`.
-
-For instance, here is how you could add some code to be performed in the derivation after installation is complete:
-
-```nix
-coqPackages.multinomials.overrideAttrs (oldAttrs: {
-  postInstall = oldAttrs.postInstall or "" + ''
-    echo "you can do anything you want here"
-  '';
-})
-```

doc/languages-frameworks/dotnet.section.md

@@ -71,8 +71,8 @@ The `dotnetCorePackages.sdk` contains both a runtime and the full sdk of a given
 
 To package Dotnet applications, you can use `buildDotnetModule`. This has similar arguments to `stdenv.mkDerivation`, with the following additions:
 
-* `projectFile` is used for specifying the dotnet project file, relative to the source root. These usually have `.sln` or `.csproj` file extensions. This can be a list of multiple projects as well. Most of the time dotnet can figure this location out by itself, so this should only be set if necessary.
-* `nugetDeps` takes either a path to a `deps.nix` file, or a derivation. The `deps.nix` file can be generated using the script attached to `passthru.fetch-deps`. This file can also be generated manually using `nuget-to-nix` tool, which is available in nixpkgs. If the argument is a derivation, it will be used directly and assume it has the same output as `mkNugetDeps`.
+* `projectFile` has to be used for specifying the dotnet project file relative to the source root. These usually have `.sln` or `.csproj` file extensions. This can be an array of multiple projects as well.
+* `nugetDeps` has to be used to specify the NuGet dependency file. Unfortunately, these cannot be deterministically fetched without a lockfile. A script to fetch these is available as `passthru.fetch-deps`. This file can also be generated manually using `nuget-to-nix` tool, which is available in nixpkgs.
 * `packNupkg` is used to pack project as a `nupkg`, and installs it to `$out/share`. If set to `true`, the derivation can be used as a dependency for another dotnet project by adding it to `projectReferences`.
 * `projectReferences` can be used to resolve `ProjectReference` project items. Referenced projects can be packed with `buildDotnetModule` by setting the `packNupkg = true` attribute and passing a list of derivations to `projectReferences`. Since we are sharing referenced projects as NuGets they must be added to csproj/fsproj files as `PackageReference` as well.
  For example, your project has a local dependency:
@@ -87,7 +87,6 @@ To package Dotnet applications, you can use `buildDotnetModule`. This has simila
 * `executables` is used to specify which executables get wrapped to `$out/bin`, relative to `$out/lib/$pname`. If this is unset, all executables generated will get installed. If you do not want to install any, set this to `[]`. This gets done in the `preFixup` phase.
 * `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.
 * `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.
@@ -100,7 +99,7 @@ To package Dotnet applications, you can use `buildDotnetModule`. This has simila
 * `dotnetPackFlags` can be used to pass flags to `dotnet pack`. Used only if `packNupkg` is set to `true`.
 * `dotnetFlags` can be used to pass flags to all of the above phases.
 
-When packaging a new application, you need to fetch its dependencies. You can run `nix-build -A package.fetch-deps` to generate a script that will build a lockfile for you. After running the script you should have the location of the generated lockfile printed to the console, which can be copied to a stable directory. Then set `nugetDeps = ./deps.nix` and you're ready to build the derivation.
+When packaging a new application, you need to fetch it's dependencies. You can set `nugetDeps` to an empty string to make the derivation temporarily evaluate, and then run `nix-build -A package.passthru.fetch-deps` to generate it's dependency fetching script. After running the script, you should have the location of the generated lockfile printed to the console. This can be copied to a stable directory. Note that if either `projectFile` or `nugetDeps` are unset, this script cannot be generated!
 
 Here is an example `default.nix`, using some of the previously discussed arguments:
 ```nix

doc/languages-frameworks/go.section.md

@@ -11,8 +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 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.
+- `vendorSha256`: is the hash of the output of the intermediate fetcher derivation. `vendorSha256` 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 `vendorSha256 = 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 `vendorSha256` checksums.
 
 ```nix
 pet = buildGoModule rec {
@@ -26,7 +26,7 @@ pet = buildGoModule rec {
     sha256 = "0m2fzpqxk7hrbxsgqplkg7h2p7gv6s1miymv3gvw0cz039skag0s";
   };
 
-  vendorHash = "sha256-ciBIR+a1oaYH+H1PcC8cD8ncfJczk1IiJ8iYNM+R6aA=";
+  vendorSha256 = "1879j77k96684wi554rkjxydrj8g3hpp0kvxz03sd8dmwr3lh83j";
 
   meta = with lib; {
     description = "Simple command-line snippet manager, written in Go";

doc/languages-frameworks/javascript.section.md

@@ -157,61 +157,6 @@ git config --global url."https://github.com/".insteadOf git://github.com/
 
 ## Tool specific instructions {#javascript-tool-specific}
 
-### buildNpmPackage {#javascript-buildNpmPackage}
-
-`buildNpmPackage` allows you to package npm-based projects in Nixpkgs without the use of an auto-generated dependencies file (as used in [node2nix](#javascript-node2nix)). It works by utilizing npm's cache functionality -- creating a reproducible cache that contains the dependencies of a project, and pointing npm to it.
-
-```nix
-{ lib, buildNpmPackage, fetchFromGitHub }:
-
-buildNpmPackage rec {
-  pname = "flood";
-  version = "4.7.0";
-
-  src = fetchFromGitHub {
-    owner = "jesec";
-    repo = pname;
-    rev = "v${version}";
-    hash = "sha256-BR+ZGkBBfd0dSQqAvujsbgsEPFYw/ThrylxUbOksYxM=";
-  };
-
-  patches = [ ./remove-prepack-script.patch ];
-
-  npmDepsHash = "sha256-s8SpZY/1tKZVd3vt7sA9vsqHvEaNORQBMrSyhWpj048=";
-
-  NODE_OPTIONS = "--openssl-legacy-provider";
-
-  meta = with lib; {
-    description = "A modern web UI for various torrent clients with a Node.js backend and React frontend";
-    homepage = "https://flood.js.org";
-    license = licenses.gpl3Only;
-    maintainers = with maintainers; [ winter ];
-  };
-}
-```
-
-#### Arguments {#javascript-buildNpmPackage-arguments}
-
-* `npmDepsHash`: The output hash of the dependencies for this project. Can be calculated in advance with [`prefetch-npm-deps`](#javascript-buildNpmPackage-prefetch-npm-deps).
-* `makeCacheWritable`: Whether to make the cache writable prior to installing dependencies. Don't set this unless npm tries to write to the cache directory, as it can slow down the build.
-* `npmBuildScript`: The script to run to build the project. Defaults to `"build"`.
-* `npmFlags`: Flags to pass to all npm commands.
-* `npmInstallFlags`: Flags to pass to `npm ci` and `npm prune`.
-* `npmBuildFlags`: Flags to pass to `npm run ${npmBuildScript}`.
-* `npmPackFlags`: Flags to pass to `npm pack`.
-
-#### prefetch-npm-deps {#javascript-buildNpmPackage-prefetch-npm-deps}
-
-`prefetch-npm-deps` can calculate the hash of the dependencies of an npm project ahead of time.
-
-```console
-$ ls
-package.json package-lock.json index.js
-$ prefetch-npm-deps package-lock.json
-...
-sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
-```
-
 ### node2nix {#javascript-node2nix}
 
 #### Preparation {#javascript-node2nix-preparation}
@@ -235,27 +180,18 @@ See `node2nix` [docs](https://github.com/svanderburg/node2nix) for more info.
 
 #### Preparation {#javascript-yarn2nix-preparation}
 
-You will need at least a `yarn.lock` file. If upstream does not have one you need to generate it and reference it in your package definition.
+You will need at least a yarn.lock and yarn.nix file.
 
-If the downloaded files contain the `package.json` and `yarn.lock` files they can be used like this:
-
-```nix
-offlineCache = fetchYarnDeps {
-  yarnLock = src + "/yarn.lock";
-  sha256 = "....";
-};
-```
+- Generate a yarn.lock in upstream if it is not already there.
+- `yarn2nix > yarn.nix` will generate the dependencies in a Nix format.
 
 #### mkYarnPackage {#javascript-yarn2nix-mkYarnPackage}
 
-`mkYarnPackage` will by default try to generate a binary. For package only generating static assets (Svelte, Vue, React, WebPack, ...), you will need to explicitly override the build step with your instructions.
-
-It's important to use the `--offline` flag. For example if you script is `"build": "something"` in `package.json` use:
+This will by default try to generate a binary. For package only generating static assets (Svelte, Vue, React...), you will need to explicitly override the build step with your instructions. It's important to use the `--offline` flag. For example if you script is `"build": "something"` in package.json use:
 
 ```nix
 buildPhase = ''
-  export HOME=$(mktemp -d)
-  yarn --offline build
+  yarn build --offline
 '';
 ```
 
@@ -265,27 +201,15 @@ The dist phase is also trying to build a binary, the only way to override it is
 distPhase = "true";
 ```
 
-The configure phase can sometimes fail because it makes many assumptions which may not always apply. One common override is:
+The configure phase can sometimes fail because it tries to be too clever. One common override is:
 
 ```nix
-configurePhase = ''
-  ln -s $node_modules node_modules
-'';
-```
-
-or if you need a writeable node_modules directory:
-
-```nix
-configurePhase = ''
-  cp -r $node_modules node_modules
-  chmod +w node_modules
-'';
+configurePhase = "ln -s $node_modules node_modules";
 ```
 
 #### mkYarnModules {#javascript-yarn2nix-mkYarnModules}
 
-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.
+This will generate a derivation including the node_modules. If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way. [Plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39) offers a good example of how to do this.
 
 #### Overriding dependency behavior
 

doc/languages-frameworks/lua.section.md

@@ -200,7 +200,7 @@ luaposix = buildLuarocksPackage {
 The `buildLuarocksPackage` delegates most tasks to luarocks:
 
 * it adds `luarocks` as an unpacker for `src.rock` files (zip files really).
-* `configurePhase` writes a temporary luarocks configuration file which location
+* configurePhase` writes a temporary luarocks configuration file which location
 is exported via the environment variable `LUAROCKS_CONFIG`.
 * the `buildPhase` does nothing.
 * `installPhase` calls `luarocks make --deps-mode=none --tree $out` to build and

doc/languages-frameworks/maven.section.md

@@ -233,8 +233,7 @@ in stdenv.mkDerivation rec {
 
   src = builtins.fetchTarball
     "https://github.com/fzakaria/nixos-maven-example/archive/main.tar.gz";
-  nativeBuildInputs = [ makeWrapper ];
-  buildInputs = [ maven ];
+  buildInputs = [ maven makeWrapper ];
 
   buildPhase = ''
     echo "Using repository ${repository}"
@@ -311,8 +310,7 @@ in stdenv.mkDerivation rec {
 
   src = builtins.fetchTarball
     "https://github.com/fzakaria/nixos-maven-example/archive/main.tar.gz";
-  nativeBuildInputs = [ makeWrapper ];
-  buildInputs = [ maven ];
+  buildInputs = [ maven makeWrapper ];
 
   buildPhase = ''
     echo "Using repository ${repository}"

doc/languages-frameworks/perl.section.md

@@ -1,6 +1,6 @@
 # Perl {#sec-language-perl}
 
-## Running Perl programs on the shell {#ssec-perl-running}
+## Running perl programs on the shell {#ssec-perl-running}
 
 When executing a Perl script, it is possible you get an error such as `./myscript.pl: bad interpreter: /usr/bin/perl: no such file or directory`. This happens when the script expects Perl to be installed at `/usr/bin/perl`, which is not the case when using Perl from nixpkgs. You can fix the script by changing the first line to:
 
@@ -35,16 +35,15 @@ Perl packages from CPAN are defined in [pkgs/top-level/perl-packages.nix](https:
 
 ```nix
 ClassC3 = buildPerlPackage rec {
-  pname = "Class-C3";
-  version = "0.21";
+  name = "Class-C3-0.21";
   src = fetchurl {
-    url = "mirror://cpan/authors/id/F/FL/FLORA/${pname}-${version}.tar.gz";
+    url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz";
     sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
   };
 };
 ```
 
-Note the use of `mirror://cpan/`, and the `pname` and `version` in the URL definition to ensure that the `pname` attribute is consistent with the source that we’re actually downloading. Perl packages are made available in `all-packages.nix` through the variable `perlPackages`. For instance, if you have a package that needs `ClassC3`, you would typically write
+Note the use of `mirror://cpan/`, and the `${name}` in the URL definition to ensure that the name attribute is consistent with the source that we’re actually downloading. Perl packages are made available in `all-packages.nix` through the variable `perlPackages`. For instance, if you have a package that needs `ClassC3`, you would typically write
 
 ```nix
 foo = import ../path/to/foo.nix {
@@ -73,11 +72,10 @@ So what does `buildPerlPackage` do? It does the following:
 { buildPerlPackage, fetchurl, db }:
 
 buildPerlPackage rec {
-  pname = "BerkeleyDB";
-  version = "0.36";
+  name = "BerkeleyDB-0.36";
 
   src = fetchurl {
-    url = "mirror://cpan/authors/id/P/PM/PMQS/${pname}-${version}.tar.gz";
+    url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz";
     sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
   };
 
@@ -92,10 +90,9 @@ Dependencies on other Perl packages can be specified in the `buildInputs` and `p
 
 ```nix
 ClassC3Componentised = buildPerlPackage rec {
-  pname = "Class-C3-Componentised";
-  version = "1.0004";
+  name = "Class-C3-Componentised-1.0004";
   src = fetchurl {
-    url = "mirror://cpan/authors/id/A/AS/ASH/${pname}-${version}.tar.gz";
+    url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz";
     sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
   };
   propagatedBuildInputs = [
@@ -114,7 +111,7 @@ ImageExifTool = buildPerlPackage {
   version = "11.50";
 
   src = fetchurl {
-    url = "https://www.sno.phy.queensu.ca/~phil/exiftool/${pname}-${version}.tar.gz";
+    url = "https://www.sno.phy.queensu.ca/~phil/exiftool/Image-ExifTool-11.50.tar.gz";
     sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3";
   };
 
@@ -142,10 +139,9 @@ This program takes a Perl module name, looks it up on CPAN, fetches and unpacks
 ```ShellSession
 $ nix-generate-from-cpan XML::Simple
   XMLSimple = buildPerlPackage rec {
-    pname = "XML-Simple";
-    version = "2.22";
+    name = "XML-Simple-2.22";
     src = fetchurl {
-      url = "mirror://cpan/authors/id/G/GR/GRANTM/XML-Simple-2.22.tar.gz";
+      url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz";
       sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
     };
     propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];

doc/languages-frameworks/php.section.md

@@ -9,7 +9,7 @@ wide variety of extensions and libraries available.
 
 The different versions of PHP that nixpkgs provides are located under
 attributes named based on major and minor version number; e.g.,
-`php81` is PHP 8.1.
+`php74` is PHP 7.4.
 
 Only versions of PHP that are supported by upstream for the entirety
 of a given NixOS release will be included in that release of
@@ -23,7 +23,7 @@ NixOS - not necessarily the latest major release from upstream.
 All available PHP attributes are wrappers around their respective
 binary PHP package and provide commonly used extensions this way. The
 real PHP 7.4 package, i.e. the unwrapped one, is available as
-`php81.unwrapped`; see the next section for more details.
+`php74.unwrapped`; see the next section for more details.
 
 Interactive tools built on PHP are put in `php.packages`; composer is
 for example available at `php.packages.composer`.

doc/languages-frameworks/python.section.md

@@ -8,9 +8,9 @@
 
 Several versions of the Python interpreter are available on Nix, as well as a
 high amount of packages. The attribute `python3` refers to the default
-interpreter, which is currently CPython 3.10. The attribute `python` refers to
+interpreter, which is currently CPython 3.9. The attribute `python` refers to
 CPython 2.7 for backwards-compatibility. It is also possible to refer to
-specific versions, e.g. `python39` refers to CPython 3.9, and `pypy` refers to
+specific versions, e.g. `python38` refers to CPython 3.8, and `pypy` refers to
 the default PyPy interpreter.
 
 Python is used a lot, and in different ways. This affects also how it is
@@ -26,10 +26,10 @@ however, are in separate sets, with one set per interpreter version.
 The interpreters have several common attributes. One of these attributes is
 `pkgs`, which is a package set of Python libraries for this specific
 interpreter. E.g., the `toolz` package corresponding to the default interpreter
-is `python.pkgs.toolz`, and the CPython 3.9 version is `python39.pkgs.toolz`.
+is `python.pkgs.toolz`, and the CPython 3.8 version is `python38.pkgs.toolz`.
 The main package set contains aliases to these package sets, e.g.
-`pythonPackages` refers to `python.pkgs` and `python39Packages` to
-`python39.pkgs`.
+`pythonPackages` refers to `python.pkgs` and `python38Packages` to
+`python38.pkgs`.
 
 #### Installing Python and packages {#installing-python-and-packages}
 
@@ -54,7 +54,7 @@ with `python.buildEnv` or `python.withPackages` where the interpreter and other
 executables are wrapped to be able to find each other and all of the modules.
 
 In the following examples we will start by creating a simple, ad-hoc environment
-with a nix-shell that has `numpy` and `toolz` in Python 3.9; then we will create
+with a nix-shell that has `numpy` and `toolz` in Python 3.8; 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.
 
@@ -70,10 +70,10 @@ temporary shell session with a Python and a *precise* list of packages (plus
 their runtime dependencies), with no other Python packages in the Python
 interpreter's scope.
 
-To create a Python 3.9 session with `numpy` and `toolz` available, run:
+To create a Python 3.8 session with `numpy` and `toolz` available, run:
 
 ```sh
-$ nix-shell -p 'python39.withPackages(ps: with ps; [ numpy toolz ])'
+$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy toolz ])'
 ```
 
 By default `nix-shell` will start a `bash` session with this interpreter in our
@@ -81,8 +81,8 @@ By default `nix-shell` will start a `bash` session with this interpreter in our
 
 ```Python console
 [nix-shell:~/src/nixpkgs]$ python3
-Python 3.9.12 (main, Mar 23 2022, 21:36:19)
-[GCC 11.3.0] on linux
+Python 3.8.1 (default, Dec 18 2019, 19:06:26)
+[GCC 9.2.0] on linux
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import numpy; import toolz
 ```
@@ -102,16 +102,13 @@ will still get 1 wrapped Python interpreter. We can start the interpreter
 directly like so:
 
 ```sh
-$ nix-shell -p "python39.withPackages (ps: with ps; [ numpy toolz requests ])" --run python3
-this derivation will be built:
-  /nix/store/mpn7k6bkjl41fm51342rafaqfsl10qs4-python3-3.9.12-env.drv
-this path will be fetched (0.09 MiB download, 0.41 MiB unpacked):
-  /nix/store/5gaiacnzi096b6prc6aa1pwrhncmhc8b-python3.9-toolz-0.11.2
-copying path '/nix/store/5gaiacnzi096b6prc6aa1pwrhncmhc8b-python3.9-toolz-0.11.2' from 'https://cache.nixos.org'...
-building '/nix/store/mpn7k6bkjl41fm51342rafaqfsl10qs4-python3-3.9.12-env.drv'...
-created 279 symlinks in user environment
-Python 3.9.12 (main, Mar 23 2022, 21:36:19)
-[GCC 11.3.0] on linux
+$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy toolz requests ])' --run python3
+these derivations will be built:
+  /nix/store/xbdsrqrsfa1yva5s7pzsra8k08gxlbz1-python3-3.8.1-env.drv
+building '/nix/store/xbdsrqrsfa1yva5s7pzsra8k08gxlbz1-python3-3.8.1-env.drv'...
+created 277 symlinks in user environment
+Python 3.8.1 (default, Dec 18 2019, 19:06:26)
+[GCC 9.2.0] on linux
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import requests
 >>>
@@ -150,7 +147,7 @@ Executing this script requires a `python3` that has `numpy`. Using what we learn
 in the previous section, we could startup a shell and just run it like so:
 
 ```ShellSession
-$ nix-shell -p 'python39.withPackages(ps: with ps; [ numpy ])' --run 'python3 foo.py'
+$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy ])' --run 'python3 foo.py'
 The dot product of [1 2] and [3 4] is: 11
 ```
 
@@ -213,12 +210,12 @@ create a single script with Python dependencies, but in the course of normal
 development we're usually working in an entire package repository.
 
 As explained in the Nix manual, `nix-shell` can also load an expression from a
-`.nix` file. Say we want to have Python 3.9, `numpy` and `toolz`, like before,
+`.nix` file. Say we want to have Python 3.8, `numpy` and `toolz`, like before,
 in an environment. We can add a `shell.nix` file describing our dependencies:
 
 ```nix
 with import <nixpkgs> {};
-(python39.withPackages (ps: [ps.numpy ps.toolz])).env
+(python38.withPackages (ps: [ps.numpy ps.toolz])).env
 ```
 
 And then at the command line, just typing `nix-shell` produces the same
@@ -232,7 +229,7 @@ What's happening here?
    imports the `<nixpkgs>` function, `{}` calls it and the `with` statement
    brings all attributes of `nixpkgs` in the local scope. These attributes form
    the main package set.
-2. Then we create a Python 3.9 environment with the `withPackages` function, as before.
+2. Then we create a Python 3.8 environment with the `withPackages` function, as before.
 3. The `withPackages` function expects us to provide a function as an argument
    that takes the set of all Python packages and returns a list of packages to
    include in the environment. Here, we select the packages `numpy` and `toolz`
@@ -243,7 +240,7 @@ To combine this with `mkShell` you can:
 ```nix
 with import <nixpkgs> {};
 let
-  pythonEnv = python39.withPackages (ps: [
+  pythonEnv = python38.withPackages (ps: [
     ps.numpy
     ps.toolz
   ]);
@@ -381,8 +378,8 @@ information. The output of the function is a derivation.
 
 An expression for `toolz` can be found in the Nixpkgs repository. As explained
 in the introduction of this Python section, a derivation of `toolz` is available
-for each interpreter version, e.g. `python39.pkgs.toolz` refers to the `toolz`
-derivation corresponding to the CPython 3.9 interpreter.
+for each interpreter version, e.g. `python38.pkgs.toolz` refers to the `toolz`
+derivation corresponding to the CPython 3.8 interpreter.
 
 The above example works when you're directly working on
 `pkgs/top-level/python-packages.nix` in the Nixpkgs repository. Often though,
@@ -395,11 +392,11 @@ and adds it along with a `numpy` package to a Python environment.
 with import <nixpkgs> {};
 
 ( let
-    my_toolz = python39.pkgs.buildPythonPackage rec {
+    my_toolz = python38.pkgs.buildPythonPackage rec {
       pname = "toolz";
       version = "0.10.0";
 
-      src = python39.pkgs.fetchPypi {
+      src = python38.pkgs.fetchPypi {
         inherit pname version;
         sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
       };
@@ -417,7 +414,7 @@ with import <nixpkgs> {};
 ```
 
 Executing `nix-shell` will result in an environment in which you can use
-Python 3.9 and the `toolz` package. As you can see we had to explicitly mention
+Python 3.8 and the `toolz` package. As you can see we had to explicitly mention
 for which Python version we want to build a package.
 
 So, what did we do here? Well, we took the Nix expression that we used earlier
@@ -602,10 +599,10 @@ been removed, in this case, it's recommended to use `pytestCheckHook`.
 #### Using pytestCheckHook {#using-pytestcheckhook}
 
 `pytestCheckHook` is a convenient hook which will substitute the setuptools
-`test` command for a `checkPhase` which runs `pytest`. This is also beneficial
+`test` command for a checkPhase which runs `pytest`. This is also beneficial
 when a package may need many items disabled to run the test suite.
 
-Using the example above, the analagous `pytestCheckHook` usage would be:
+Using the example above, the analagous pytestCheckHook usage would be:
 
 ```
   checkInputs = [ pytestCheckHook ];
@@ -624,7 +621,7 @@ Using the example above, the analagous `pytestCheckHook` usage would be:
   ];
 ```
 
-This is expecially useful when tests need to be conditionally disabled,
+This is expecially useful when tests need to be conditionallydisabled,
 for example:
 
 ```
@@ -640,156 +637,31 @@ for example:
     "socket"
   ];
 ```
-
-Trying to concatenate the related strings to disable tests in a regular
-`checkPhase` would be much harder to read. This also enables us to comment on
-why specific tests are disabled.
+Trying to concatenate the related strings to disable tests in a regular checkPhase
+would be much harder to read. This also enables us to comment on why specific tests
+are disabled.
 
 #### Using pythonImportsCheck {#using-pythonimportscheck}
 
-Although unit tests are highly preferred to validate correctness of a package, not
-all packages have test suites that can be run easily, and some have none at all.
+Although unit tests are highly prefered to validate correctness of a package, not
+all packages have test suites that can be ran easily, and some have none at all.
 To help ensure the package still works, `pythonImportsCheck` can attempt to import
 the listed modules.
 
 ```
   pythonImportsCheck = [ "requests" "urllib" ];
 ```
-
 roughly translates to:
-
 ```
   postCheck = ''
     PYTHONPATH=$out/${python.sitePackages}:$PYTHONPATH
     python -c "import requests; import urllib"
   '';
 ```
-
-However, this is done in its own phase, and not dependent on whether `doCheck = true;`.
+However, this is done in it's own phase, and not dependent on whether `doCheck = true;`
 
 This can also be useful in verifying that the package doesn't assume commonly
-present packages (e.g. `setuptools`).
-
-#### Using pythonRelaxDepsHook {#using-pythonrelaxdepshook}
-
-It is common for upstream to specify a range of versions for its package
-dependencies. This makes sense, since it ensures that the package will be built
-with a subset of packages that is well tested. However, this commonly causes
-issues when packaging in Nixpkgs, because the dependencies that this package
-may need are too new or old for the package to build correctly. We also cannot
-package multiple versions of the same package since this may cause conflicts
-in `PYTHONPATH`.
-
-One way to side step this issue is to relax the dependencies. This can be done
-by either removing the package version range or by removing the package
-declaration entirely. This can be done using the `pythonRelaxDepsHook` hook. For
-example, given the following `requirements.txt` file:
-
-```
-pkg1<1.0
-pkg2
-pkg3>=1.0,<=2.0
-```
-
-we can do:
-
-```
-  nativeBuildInputs = [ pythonRelaxDepsHook ];
-  pythonRelaxDeps = [ "pkg1" "pkg3" ];
-  pythonRemoveDeps = [ "pkg2" ];
-```
-
-which would result in the following `requirements.txt` file:
-
-```
-pkg1
-pkg3
-```
-
-Another option is to pass `true`, that will relax/remove all dependencies, for
-example:
-
-```
-  nativeBuildInputs = [ pythonRelaxDepsHook ];
-  pythonRelaxDeps = true;
-```
-
-which would result in the following `requirements.txt` file:
-
-```
-pkg1
-pkg2
-pkg3
-```
-
-In general you should always use `pythonRelaxDeps`, because `pythonRemoveDeps`
-will convert build errors into runtime errors. However `pythonRemoveDeps` may
-still be useful in exceptional cases, and also to remove dependencies wrongly
-declared by upstream (for example, declaring `black` as a runtime dependency
-instead of a dev dependency).
-
-Keep in mind that while the examples above are done with `requirements.txt`,
-`pythonRelaxDepsHook` works by modifying the resulting wheel file, so it should
-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}
-
-`unittestCheckHook` is a hook which will substitute the setuptools `test` command for a `checkPhase` which runs `python -m unittest discover`:
-
-```
-  checkInputs = [ unittestCheckHook ];
-
-  unittestFlags = [ "-s" "tests" "-v" ];
-```
-
-##### Using sphinxHook {#using-sphinxhook}
-
-The `sphinxHook` is a helpful tool to build documentation and manpages
-using the popular Sphinx documentation generator.
-It is setup to automatically find common documentation source paths and
-render them using the default `html` style.
-
-```
-  outputs = [
-    "out"
-    "doc"
-  ];
-
-  nativeBuildInputs = [
-    sphinxHook
-  ];
-```
-
-The hook will automatically build and install the artifact into the
-`doc` output, if it exists. It also provides an automatic diversion
-for the artifacts of the `man` builder into the `man` target.
-
-```
-  outputs = [
-    "out"
-    "doc"
-    "man"
-  ];
-
-  # Use multiple builders
-  sphinxBuilders = [
-    "singlehtml"
-    "man"
-  ];
-```
-
-Overwrite `sphinxRoot` when the hook is unable to find your
-documentation source root.
-
-```
-  # Configure sphinxRoot for uncommon paths
-  sphinxRoot = "weird/docs/path";
-```
-
-The hook is also available to packages outside the python ecosystem by
-referencing it using `sphinxHook` from top-level.
+present packages (e.g. `setuptools`)
 
 ### Develop local package {#develop-local-package}
 
@@ -799,14 +671,14 @@ creates a special link to the project code. That way, you can run updated code
 without having to reinstall after each and every change you make. Development
 mode is also available. Let's see how you can use it.
 
-In the previous Nix expression the source was fetched from a url. We can also
+In the previous Nix expression the source was fetched from an url. We can also
 refer to a local source instead using `src = ./path/to/source/tree;`
 
 If we create a `shell.nix` file which calls `buildPythonPackage`, and if `src`
 is a local source, and if the local source has a `setup.py`, then development
 mode is activated.
 
-In the following example, we create a simple environment that has a Python 3.9
+In the following example we create a simple environment that has a Python 3.8
 version of our package in it, as well as its dependencies and other packages we
 like to have in the environment, all specified with `propagatedBuildInputs`.
 Indeed, we can just add any package we like to have in our environment to
@@ -814,7 +686,7 @@ Indeed, we can just add any package we like to have in our environment to
 
 ```nix
 with import <nixpkgs> {};
-with python39Packages;
+with python38Packages;
 
 buildPythonPackage rec {
   name = "mypackage";
@@ -892,9 +764,9 @@ and in this case the `python38` interpreter is automatically used.
 
 ### Interpreters {#interpreters}
 
-Versions 2.7, 3.7, 3.8, 3.9 and 3.10 of the CPython interpreter are available
-as respectively `python27`, `python37`, `python38`, `python39` and `python310`.
-The aliases `python2` and `python3` correspond to respectively `python27` and
+Versions 2.7, 3.7, 3.8 and 3.9 of the CPython interpreter are available as
+respectively `python27`, `python37`, `python38` and `python39`. The
+aliases `python2` and `python3` correspond to respectively `python27` and
 `python39`. The attribute `python` maps to `python2`. The PyPy interpreters
 compatible with Python 2.7 and 3 are available as `pypy27` and `pypy3`, with
 aliases `pypy2` mapping to `pypy27` and `pypy` mapping to `pypy2`. The Nix
@@ -923,7 +795,7 @@ Each interpreter has the following attributes:
 
 ### Optimizations {#optimizations}
 
-The Python interpreters are by default not built with optimizations enabled, because
+The Python interpreters are by default not build with optimizations enabled, because
 the builds are in that case not reproducible. To enable optimizations, override the
 interpreter of interest, e.g using
 
@@ -974,7 +846,7 @@ and the aliases
 #### `buildPythonPackage` function {#buildpythonpackage-function}
 
 The `buildPythonPackage` function is implemented in
-`pkgs/development/interpreters/python/mk-python-derivation.nix`
+`pkgs/development/interpreters/python/mk-python-derivation`
 using setup hooks.
 
 The following is an example:
@@ -1015,7 +887,7 @@ The `buildPythonPackage` mainly does four things:
 * In the `postFixup` phase, the `wrapPythonPrograms` bash function is called to
   wrap all programs in the `$out/bin/*` directory to include `$PATH`
   environment variable and add dependent libraries to script's `sys.path`.
-* In the `installCheck` phase, `${python.interpreter} setup.py test` is run.
+* In the `installCheck` phase, `${python.interpreter} setup.py test` is ran.
 
 By default tests are run because `doCheck = true`. Test dependencies, like
 e.g. the test runner, should be added to `checkInputs`.
@@ -1030,7 +902,7 @@ following are specific to `buildPythonPackage`:
 
 * `catchConflicts ? true`: If `true`, abort package build if a package name
   appears more than once in dependency tree. Default is `true`.
-* `disabled ? false`: If `true`, package is not built for the particular Python
+* `disabled` ? false: If `true`, package is not built for the particular Python
   interpreter version.
 * `dontWrapPythonPrograms ? false`: Skip wrapping of Python programs.
 * `permitUserSite ? false`: Skip setting the `PYTHONNOUSERSITE` environment
@@ -1317,18 +1189,14 @@ are used in `buildPythonPackage`.
 - `pytestCheckHook` to run tests with `pytest`. See [example usage](#using-pytestcheckhook).
 - `pythonCatchConflictsHook` to check whether a Python package is not already existing.
 - `pythonImportsCheckHook` to check whether importing the listed modules works.
-- `pythonRelaxDepsHook` will relax Python dependencies restrictions for the package.
-  See [example usage](#using-pythonrelaxdepshook).
 - `pythonRemoveBinBytecode` to remove bytecode from the `/bin` folder.
 - `setuptoolsBuildHook` to build a wheel using `setuptools`.
 - `setuptoolsCheckHook` to run tests with `python setup.py test`.
-- `sphinxHook` to build documentation and manpages using Sphinx.
 - `venvShellHook` to source a Python 3 `venv` at the `venvDir` location. A
   `venv` is created if it does not yet exist. `postVenvCreation` can be used to
   to run commands only after venv is first created.
 - `wheelUnpackHook` to move a wheel to the correct folder so it can be installed
   with the `pipInstallHook`.
-- `unittestCheckHook` will run tests with `python -m unittest discover`. See [example usage](#using-unittestcheckhook).
 
 ### Development mode {#development-mode}
 
@@ -1484,8 +1352,7 @@ in newpkgs.inkscape
 
 ### `python setup.py bdist_wheel` cannot create .whl {#python-setup.py-bdist_wheel-cannot-create-.whl}
 
-Executing `python setup.py bdist_wheel` in a `nix-shell`fails with
-
+Executing `python setup.py bdist_wheel` in a `nix-shell `fails with
 ```
 ValueError: ZIP does not support timestamps before 1980
 ```
@@ -1577,7 +1444,7 @@ in pkgs.mkShell rec {
     # the environment.
     pythonPackages.python
 
-    # This executes some shell code to initialize a venv in $venvDir before
+    # This execute some shell code to initialize a venv in $venvDir before
     # dropping into the shell
     pythonPackages.venvShellHook
 
@@ -1670,9 +1537,9 @@ If you need to change a package's attribute(s) from `configuration.nix` you coul
 
 ```nix
   nixpkgs.config.packageOverrides = super: {
-    python3 = super.python3.override {
+    python = super.python.override {
       packageOverrides = python-self: python-super: {
-        twisted = python-super.twisted.overridePythonAttrs (oldAttrs: {
+        twisted = python-super.twisted.overrideAttrs (oldAttrs: {
           src = super.fetchPypi {
             pname = "twisted";
             version = "19.10.0";
@@ -1723,26 +1590,6 @@ self: super: {
 }
 ```
 
-### How to override a Python package for all Python versions using extensions? {#how-to-override-a-python-package-for-all-python-versions-using-extensions}
-
-The following overlay overrides the call to `buildPythonPackage` for the
-`foo` package for all interpreters by appending a Python extension to the
-`pythonPackagesExtensions` list of extensions.
-
-```nix
-final: prev: {
-  pythonPackagesExtensions = prev.pythonPackagesExtensions ++ [
-    (
-      python-final: python-prev: {
-        foo = python-prev.foo.overridePythonAttrs (oldAttrs: {
-          ...
-        });
-      }
-    )
-  ];
-}
-```
-
 ### How to use Intel’s MKL with numpy and scipy? {#how-to-use-intels-mkl-with-numpy-and-scipy}
 
 MKL can be configured using an overlay. See the section "[Using overlays to
@@ -1780,10 +1627,6 @@ The following rules are desired to be respected:
   that characters should be converted to lowercase and `.` and `_` should be
   replaced by a single `-` (foo-bar-baz instead of Foo__Bar.baz).
   If necessary, `pname` has to be given a different value within `fetchPypi`.
-* Packages from sources such as GitHub and GitLab that do not exist on PyPI
-  should not use a name that is already used on PyPI. When possible, they should
-  use the package repository name prefixed with the owner (e.g. organization) name
-  and using a `-` as delimiter.
 * Attribute names in `python-packages.nix` should be sorted alphanumerically to
   avoid merge conflicts and ease locating attributes.
 

doc/languages-frameworks/ruby.section.md

@@ -274,7 +274,7 @@ bundlerApp {
   gemdir = ./.;
   exes = [ "r10k" ];
 
-  nativeBuildInputs = [ makeWrapper ];
+  buildInputs = [ makeWrapper ];
 
   postBuild = ''
     wrapProgram $out/bin/r10k --prefix PATH : ${lib.makeBinPath [ git gnutar gzip ]}

doc/languages-frameworks/rust.section.md

@@ -15,7 +15,7 @@ For other versions such as daily builds (beta and nightly),
 use either `rustup` from nixpkgs (which will manage the rust installation in your home directory),
 or use a community maintained [Rust overlay](#using-community-rust-overlays).
 
-## `buildRustPackage`: Compiling Rust applications with Cargo {#compiling-rust-applications-with-cargo}
+## Compiling Rust applications with Cargo {#compiling-rust-applications-with-cargo}
 
 Rust applications are packaged by using the `buildRustPackage` helper from `rustPlatform`:
 
@@ -319,18 +319,6 @@ The above are just guidelines, and exceptions may be granted on a case-by-case b
 However, please check if it's possible to disable a problematic subset of the
 test suite and leave a comment explaining your reasoning.
 
-This can be achived with `--skip` in `checkFlags`:
-
-```nix
-rustPlatform.buildRustPackage {
-  /* ... */
-  checkFlags = [
-    # reason for disabling test
-    "--skip=example::tests:example_test"
-  ];
-}
-```
-
 #### Setting `test-threads` {#setting-test-threads}
 
 `buildRustPackage` will use parallel test threads by default,
@@ -470,7 +458,7 @@ you of the correct hash.
   `maturinBuildFlags`.
 * `cargoCheckHook`: run tests using Cargo. The build type for checks
   can be set using `cargoCheckType`. Features can be specified with
-  `cargoCheckNoDefaultFeatures` and `cargoCheckFeatures`. Additional
+  `cargoCheckNoDefaultFeaatures` and `cargoCheckFeatures`. Additional
   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`.
@@ -608,7 +596,7 @@ buildPythonPackage rec {
 }
 ```
 
-## `buildRustCrate`: Compiling Rust crates using Nix instead of Cargo {#compiling-rust-crates-using-nix-instead-of-cargo}
+## Compiling Rust crates using Nix instead of Cargo {#compiling-rust-crates-using-nix-instead-of-cargo}
 
 ### Simple operation {#simple-operation}
 

doc/languages-frameworks/vim.section.md

@@ -5,10 +5,12 @@ and additional libraries.
 
 Loading can be deferred; see examples.
 
-At the moment we support two different methods for managing plugins:
+At the moment we support three different methods for managing plugins:
 
-- Vim packages (*recommended*)
-- vim-plug (vim only)
+- Vim packages (*recommend*)
+- VAM (=vim-addon-manager)
+- Pathogen
+- vim-plug
 
 ## Custom configuration {#custom-configuration}
 
@@ -43,7 +45,7 @@ neovim.override {
 ```
 
 If you want to use `neovim-qt` as a graphical editor, you can configure it by overriding Neovim in an overlay
-or passing it an overridden Neovim:
+or passing it an overridden Neovimn:
 
 ```nix
 neovim-qt.override {
@@ -59,7 +61,7 @@ neovim-qt.override {
 
 ## Managing plugins with Vim packages {#managing-plugins-with-vim-packages}
 
-To store your plugins in Vim packages (the native Vim plugin manager, see `:help packages`) the following example can be used:
+To store you plugins in Vim packages (the native Vim plugin manager, see `:help packages`) the following example can be used:
 
 ```nix
 vim_configurable.customize {
@@ -108,7 +110,7 @@ The resulting package can be added to `packageOverrides` in `~/.nixpkgs/config.n
     };
     myNeovim = neovim.override {
       configure = {
-      # add code from the example section here
+      # add here code from the example section
       };
     };
   };
@@ -125,7 +127,7 @@ If one of your favourite plugins isn't packaged, you can package it yourself:
 { config, pkgs, ... }:
 
 let
-  easygrep = pkgs.vimUtils.buildVimPluginFrom2Nix {
+  easygrep = pkgs.vimUtils.buildVimPlugin {
     name = "vim-easygrep";
     src = pkgs.fetchFromGitHub {
       owner = "dkprice";
@@ -155,13 +157,11 @@ in
 }
 ```
 
-If your package requires building specific parts, use instead `pkgs.vimUtils.buildVimPlugin`.
-
 ### Specificities for some plugins
-#### Treesitter
+#### Tree sitter
 
 By default `nvim-treesitter` encourages you to download, compile and install
-the required Treesitter grammars at run time with `:TSInstall`. This works
+the required tree-sitter grammars at run time with `:TSInstall`. This works
 poorly on NixOS.  Instead, to install the `nvim-treesitter` plugins with a set
 of precompiled grammars, you can use `nvim-treesitter.withPlugins` function:
 
@@ -172,8 +172,8 @@ of precompiled grammars, you can use `nvim-treesitter.withPlugins` function:
       start = [
         (nvim-treesitter.withPlugins (
           plugins: with plugins; [
-            nix
-            python
+            tree-sitter-nix
+            tree-sitter-python
           ]
         ))
       ];
@@ -182,7 +182,7 @@ of precompiled grammars, you can use `nvim-treesitter.withPlugins` function:
 })
 ```
 
-To enable all grammars packaged in nixpkgs, use `pkgs.vimPlugins.nvim-treesitter.withAllGrammars`.
+To enable all grammars packaged in nixpkgs, use `(pkgs.vimPlugins.nvim-treesitter.withPlugins (plugins: pkgs.tree-sitter.allGrammars))`.
 
 ## Managing plugins with vim-plug {#managing-plugins-with-vim-plug}
 
@@ -198,15 +198,122 @@ vim_configurable.customize {
 }
 ```
 
-Note: this is not possible anymore for Neovim.
+For Neovim the syntax is:
 
+```nix
+neovim.override {
+  configure = {
+    customRC = ''
+      # here your custom configuration goes!
+    '';
+    plug.plugins = with pkgs.vimPlugins; [
+      vim-go
+    ];
+  };
+}
+```
+
+## Managing plugins with VAM {#managing-plugins-with-vam}
+
+### Handling dependencies of Vim plugins {#handling-dependencies-of-vim-plugins}
+
+VAM introduced .json files supporting dependencies without versioning
+assuming that "using latest version" is ok most of the time.
+
+### Example {#example}
+
+First create a vim-scripts file having one plugin name per line. Example:
+
+```vim
+"tlib"
+{'name': 'vim-addon-sql'}
+{'filetype_regex': '\%(vim)$', 'names': ['reload', 'vim-dev-plugin']}
+```
+
+Such vim-scripts file can be read by VAM as well like this:
+
+```vim
+call vam#Scripts(expand('~/.vim-scripts'), {})
+```
+
+Create a default.nix file:
+
+```nix
+{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7102" }:
+nixpkgs.vim_configurable.customize { name = "vim"; vimrcConfig.vam.pluginDictionaries = [ "vim-addon-vim2nix" ]; }
+```
+
+Create a generate.vim file:
+
+```vim
+ActivateAddons vim-addon-vim2nix
+let vim_scripts = "vim-scripts"
+call nix#ExportPluginsForNix({
+\  'path_to_nixpkgs': eval('{"'.substitute(substitute(substitute($NIX_PATH, ':', ',', 'g'), '=',':', 'g'), '\([:,]\)', '"\1"',"g").'"}')["nixpkgs"],
+\  'cache_file': '/tmp/vim2nix-cache',
+\  'try_catch': 0,
+\  'plugin_dictionaries': ["vim-addon-manager"]+map(readfile(vim_scripts), 'eval(v:val)')
+\ })
+```
+
+Then run
+
+```bash
+nix-shell -p vimUtils.vim_with_vim2nix --command "vim -c 'source generate.vim'"
+```
+
+You should get a Vim buffer with the nix derivations (output1) and vam.pluginDictionaries (output2).
+You can add your Vim to your system's configuration file like this and start it by "vim-my":
+
+```nix
+my-vim =
+  let plugins = let inherit (vimUtils) buildVimPluginFrom2Nix; in {
+    copy paste output1 here
+  }; in vim_configurable.customize {
+    name = "vim-my";
+
+    vimrcConfig.vam.knownPlugins = plugins; # optional
+    vimrcConfig.vam.pluginDictionaries = [
+       copy paste output2 here
+    ];
+
+    # Pathogen would be
+    # vimrcConfig.pathogen.knownPlugins = plugins; # plugins
+    # vimrcConfig.pathogen.pluginNames = ["tlib"];
+  };
+```
+
+Sample output1:
+
+```nix
+"reload" = buildVimPluginFrom2Nix { # created by nix#NixDerivation
+  name = "reload";
+  src = fetchgit {
+    url = "https://github.com/xolox/vim-reload";
+    rev = "0a601a668727f5b675cb1ddc19f6861f3f7ab9e1";
+    sha256 = "0vb832l9yxj919f5hfg6qj6bn9ni57gnjd3bj7zpq7d4iv2s4wdh";
+  };
+  dependencies = ["nim-misc"];
+
+};
+[...]
+```
+
+Sample output2:
+
+```nix
+[
+  ''vim-addon-manager''
+  ''tlib''
+  { "name" = ''vim-addon-sql''; }
+  { "filetype_regex" = ''\%(vim)$$''; "names" = [ ''reload'' ''vim-dev-plugin'' ]; }
+]
+```
 
 ## Adding new plugins to nixpkgs {#adding-new-plugins-to-nixpkgs}
 
 Nix expressions for Vim plugins are stored in [pkgs/applications/editors/vim/plugins](https://github.com/NixOS/nixpkgs/tree/master/pkgs/applications/editors/vim/plugins). For the vast majority of plugins, Nix expressions are automatically generated by running [`./update.py`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/update.py). This creates a [generated.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/generated.nix) file based on the plugins listed in [vim-plugin-names](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/vim-plugin-names). Plugins are listed in alphabetical order in `vim-plugin-names` using the format `[github username]/[repository]@[gitref]`. For example https://github.com/scrooloose/nerdtree becomes `scrooloose/nerdtree`.
 
-After running `./update.py`, if nvim-treesitter received an update, also run [`nvim-treesitter/update.py`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/update.py) to update the tree sitter grammars for `nvim-treesitter`.
-
 Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:
 
 ```nix
@@ -219,7 +326,7 @@ Sometimes plugins require an override that must be changed when the plugin is up
 
 To add a new plugin, run `./update.py --add "[owner]/[name]"`. **NOTE**: This script automatically commits to your git repository. Be sure to check out a fresh branch before running.
 
-Finally, there are some plugins that are also packaged in nodePackages because they have Javascript-related build steps, such as running webpack. Those plugins are not listed in `vim-plugin-names` or managed by `update.py` at all, and are included separately in `overrides.nix`. Currently, all these plugins are related to the `coc.nvim` ecosystem of the Language Server Protocol integration with Vim/Neovim.
+Finally, there are some plugins that are also packaged in nodePackages because they have Javascript-related build steps, such as running webpack. Those plugins are not listed in `vim-plugin-names` or managed by `update.py` at all, and are included separately in `overrides.nix`. Currently, all these plugins are related to the `coc.nvim` ecosystem of Language Server Protocol integration with vim/neovim.
 
 ## Updating plugins in nixpkgs {#updating-plugins-in-nixpkgs}
 
@@ -235,27 +342,10 @@ Alternatively, set the number of processes to a lower count to avoid rate-limiti
 ./pkgs/applications/editors/vim/plugins/update.py --proc 1
 ```
 
-## How to maintain an out-of-tree overlay of vim plugins ?
+## Important repositories {#important-repositories}
 
-You can use the updater script to generate basic packages out of a custom vim
-plugin list:
-
-```
-pkgs/applications/editors/vim/plugins/update.py -i vim-plugin-names -o generated.nix --no-commit
-```
-
-with the contents of `vim-plugin-names` being for example:
-
-```
-repo,branch,alias
-pwntester/octo.nvim,,
-```
-
-You can then reference the generated vim plugins via:
-
-```nix
-myVimPlugins = pkgs.vimPlugins.extend (
-  (pkgs.callPackage generated.nix {})
-);
-```
+- [vim-pi](https://bitbucket.org/vimcommunity/vim-pi) is a plugin repository
+  from VAM plugin manager meant to be used by others as well used by
 
+- [vim2nix](https://github.com/MarcWeber/vim-addon-vim2nix) which generates the
+  .nix code

doc/release-notes.xml

@@ -0,0 +1,650 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<article xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink">
+ <title>Nixpkgs Release Notes</title>
+ <section xml:id="release-notes-0.14">
+  <title>Release 0.14 (June 4, 2012)</title>
+
+  <para>
+   In preparation for the switch from Subversion to Git, this release is mainly the prevent the Nixpkgs version number from going backwards. (This would happen because prerelease version numbers produced for the Git repository are lower than those for the Subversion repository.)
+  </para>
+
+  <para>
+   Since the last release, there have been thousands of changes and new packages by numerous contributors. For details, see the commit logs.
+  </para>
+ </section>
+ <section xml:id="release-notes-0.13">
+  <title>Release 0.13 (February 5, 2010)</title>
+
+  <para>
+   As always, there are many changes. Some of the most important updates are:
+   <itemizedlist>
+    <listitem>
+     <para>
+      Glibc 2.9.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      GCC 4.3.3.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Linux 2.6.32.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      X.org 7.5.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      KDE 4.3.4.
+     </para>
+    </listitem>
+   </itemizedlist>
+  </para>
+ </section>
+ <section xml:id="release-notes-0.12">
+  <title>Release 0.12 (April 24, 2009)</title>
+
+  <para>
+   There are way too many additions to Nixpkgs since the last release to list here: for example, the number of packages on Linux has increased from 1002 to 2159. However, some specific improvements are worth listing:
+   <itemizedlist>
+    <listitem>
+     <para>
+      Nixpkgs now has a manual. In particular, it describes the standard build environment in detail.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Major new packages:
+      <itemizedlist>
+       <listitem>
+        <para>
+         KDE 4.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         TeXLive.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         VirtualBox.
+        </para>
+       </listitem>
+      </itemizedlist>
+      … and many others.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Important updates:
+      <itemizedlist>
+       <listitem>
+        <para>
+         Glibc 2.7.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         GCC 4.2.4.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         Linux 2.6.25 — 2.6.28.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         Firefox 3.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         X.org 7.3.
+        </para>
+       </listitem>
+      </itemizedlist>
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Support for building derivations in a virtual machine, including RPM and Debian builds in automatically generated VM images. See <filename>pkgs/build-support/vm/default.nix</filename> for details.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Improved support for building Haskell packages.
+     </para>
+    </listitem>
+   </itemizedlist>
+  </para>
+
+  <para>
+   The following people contributed to this release: Andres Löh, Arie Middelkoop, Armijn Hemel, Eelco Dolstra, Lluís Batlle, Ludovic Courtès, Marc Weber, Mart Kolthof, Martin Bravenboer, Michael Raskin, Nicolas Pierron, Peter Simons, Pjotr Prins, Rob Vermaas, Sander van der Burg, Tobias Hammerschmidt, Valentin David, Wouter den Breejen and Yury G. Kudryashov. In addition, several people contributed patches on the <literal>nix-dev</literal> mailing list.
+  </para>
+ </section>
+ <section xml:id="release-notes-0.11">
+  <title>Release 0.11 (September 11, 2007)</title>
+
+  <para>
+   This release has the following improvements:
+   <itemizedlist>
+    <listitem>
+     <para>
+      The standard build environment (<literal>stdenv</literal>) is now pure on the <literal>x86_64-linux</literal> and <literal>powerpc-linux</literal> platforms, just as on <literal>i686-linux</literal>. (Purity means that building and using the standard environment has no dependencies outside of the Nix store. For instance, it doesn’t require an external C compiler such as <filename>/usr/bin/gcc</filename>.) Also, the statically linked binaries used in the bootstrap process are now automatically reproducible, making it easy to update the bootstrap tools and to add support for other Linux platforms. See <filename>pkgs/stdenv/linux/make-bootstrap-tools.nix</filename> for details.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Hook variables in the generic builder are now executed using the <function>eval</function> shell command. This has a major advantage: you can write hooks directly in Nix expressions. For instance, rather than writing a builder like this:
+<programlisting>
+source $stdenv/setup
+
+postInstall=postInstall
+postInstall() {
+    ln -sf gzip $out/bin/gunzip
+    ln -sf gzip $out/bin/zcat
+}
+
+genericBuild</programlisting>
+      (the <literal>gzip</literal> builder), you can just add this attribute to the derivation:
+<programlisting>
+postInstall = "ln -sf gzip $out/bin/gunzip; ln -sf gzip $out/bin/zcat";</programlisting>
+      and so a separate build script becomes unnecessary. This should allow us to get rid of most builders in Nixpkgs.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      It is now possible to have the generic builder pass arguments to <command>configure</command> and <command>make</command> that contain whitespace. Previously, for example, you could say in a builder,
+<programlisting>
+configureFlags="CFLAGS=-O0"</programlisting>
+      but not
+<programlisting>
+configureFlags="CFLAGS=-O0 -g"</programlisting>
+      since the <literal>-g</literal> would be interpreted as a separate argument to <command>configure</command>. Now you can say
+<programlisting>
+configureFlagsArray=("CFLAGS=-O0 -g")</programlisting>
+      or similarly
+<programlisting>
+configureFlagsArray=("CFLAGS=-O0 -g" "LDFLAGS=-L/foo -L/bar")</programlisting>
+      which does the right thing. Idem for <literal>makeFlags</literal>, <literal>installFlags</literal>, <literal>checkFlags</literal> and <literal>distFlags</literal>.
+     </para>
+     <para>
+      Unfortunately you can't pass arrays to Bash through the environment, so you can't put the array above in a Nix expression, e.g.,
+<programlisting>
+configureFlagsArray = ["CFLAGS=-O0 -g"];</programlisting>
+      since it would just be flattened to a since string. However, you <emphasis>can</emphasis> use the inline hooks described above:
+<programlisting>
+preConfigure = "configureFlagsArray=(\"CFLAGS=-O0 -g\")";</programlisting>
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      The function <function>fetchurl</function> now has support for two different kinds of mirroring of files. First, it has support for <emphasis>content-addressable mirrors</emphasis>. For example, given the <function>fetchurl</function> call
+<programlisting>
+fetchurl {
+  url = "http://releases.mozilla.org/<replaceable>...</replaceable>/firefox-2.0.0.6-source.tar.bz2";
+  sha1 = "eb72f55e4a8bf08e8c6ef227c0ade3d068ba1082";
+}</programlisting>
+      <function>fetchurl</function> will first try to download this file from <link
+  xlink:href="http://tarballs.nixos.org/sha1/eb72f55e4a8bf08e8c6ef227c0ade3d068ba1082"/>. If that file doesn’t exist, it will try the original URL. In general, the “content-addressed” location is <replaceable>mirror</replaceable><literal>/</literal><replaceable>hash-type</replaceable><literal>/</literal><replaceable>hash</replaceable>. There is currently only one content-addressable mirror (<link
+  xlink:href="http://tarballs.nixos.org"/>), but more can be specified in the <varname>hashedMirrors</varname> attribute in <filename>pkgs/build-support/fetchurl/mirrors.nix</filename>, or by setting the <envar>NIX_HASHED_MIRRORS</envar> environment variable to a whitespace-separated list of URLs.
+     </para>
+     <para>
+      Second, <function>fetchurl</function> has support for widely-mirrored distribution sites such as SourceForge or the Linux kernel archives. Given a URL of the form <literal>mirror://<replaceable>site</replaceable>/<replaceable>path</replaceable></literal>, it will try to download <replaceable>path</replaceable> from a configurable list of mirrors for <replaceable>site</replaceable>. (This idea was borrowed from Gentoo Linux.) Example:
+<programlisting>
+fetchurl {
+  url = mirror://gnu/gcc/gcc-4.2.0/gcc-core-4.2.0.tar.bz2;
+  sha256 = "0ykhzxhr8857dr97z0j9wyybfz1kjr71xk457cfapfw5fjas4ny1";
+}</programlisting>
+      Currently <replaceable>site</replaceable> can be <literal>sourceforge</literal>, <literal>gnu</literal> and <literal>kernel</literal>. The list of mirrors is defined in <filename>pkgs/build-support/fetchurl/mirrors.nix</filename>. You can override the list of mirrors for a particular site by setting the environment variable <envar>NIX_MIRRORS_<replaceable>site</replaceable></envar>, e.g.
+<programlisting>
+export NIX_MIRRORS_sourceforge=http://osdn.dl.sourceforge.net/sourceforge/</programlisting>
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Important updates:
+      <itemizedlist>
+       <listitem>
+        <para>
+         Glibc 2.5.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         GCC 4.1.2.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         Gnome 2.16.3.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         X11R7.2.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         Linux 2.6.21.7 and 2.6.22.6.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         Emacs 22.1.
+        </para>
+       </listitem>
+      </itemizedlist>
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Major new packages:
+      <itemizedlist>
+       <listitem>
+        <para>
+         KDE 3.5.6 Base.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         Wine 0.9.43.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         OpenOffice 2.2.1.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         Many Linux system packages to support NixOS.
+        </para>
+       </listitem>
+      </itemizedlist>
+     </para>
+    </listitem>
+   </itemizedlist>
+  </para>
+
+  <para>
+   The following people contributed to this release: Andres Löh, Arie Middelkoop, Armijn Hemel, Eelco Dolstra, Marc Weber, Mart Kolthof, Martin Bravenboer, Michael Raskin, Wouter den Breejen and Yury G. Kudryashov.
+  </para>
+ </section>
+ <section xml:id="release-notes-0.10">
+  <title>Release 0.10 (October 12, 2006)</title>
+
+  <note>
+   <para>
+    This release of Nixpkgs requires <link
+xlink:href='https://nixos.org/releases/nix/nix-0.10/'>Nix 0.10</link> or higher.
+   </para>
+  </note>
+
+  <para>
+   This release has the following improvements:
+  </para>
+
+  <itemizedlist>
+   <listitem>
+    <para>
+     <filename>pkgs/system/all-packages-generic.nix</filename> is gone, we now just have <filename>pkgs/top-level/all-packages.nix</filename> that contains all available packages. This should cause much less confusion with users. <filename>all-packages.nix</filename> is a function that by default returns packages for the current platform, but you can override this by specifying a different <varname>system</varname> argument.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Certain packages in Nixpkgs are now user-configurable through a configuration file, i.e., without having to edit the Nix expressions in Nixpkgs. For instance, the Firefox provided in the Nixpkgs channel is built without the RealPlayer plugin (for legal reasons). Previously, you could easily enable RealPlayer support by editing the call to the Firefox function in <filename>all-packages.nix</filename>, but such changes are not respected when Firefox is subsequently updated through the Nixpkgs channel.
+    </para>
+    <para>
+     The Nixpkgs configuration file (found in <filename>~/.nixpkgs/config.nix</filename> or through the <envar>NIXPKGS_CONFIG</envar> environment variable) is an attribute set that contains configuration options that <filename>all-packages.nix</filename> reads and uses for certain packages. For instance, the following configuration file:
+<programlisting>
+{
+  firefox = {
+    enableRealPlayer = true;
+  };
+}</programlisting>
+     persistently enables RealPlayer support in the Firefox build.
+    </para>
+    <para>
+     (Actually, <literal>firefox.enableRealPlayer</literal> is the <emphasis>only</emphasis> configuration option currently available, but more are sure to be added.)
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Support for new platforms:
+     <itemizedlist>
+      <listitem>
+       <para>
+        <literal>i686-cygwin</literal>, i.e., Windows (using <link xlink:href="http://www.cygwin.com/">Cygwin</link>). The standard environment on <literal>i686-cygwin</literal> by default builds binaries for the Cygwin environment (i.e., it uses Cygwin tools and produces executables that use the Cygwin library). However, there is also a standard environment that produces binaries that use <link
+      xlink:href="http://www.mingw.org/">MinGW</link>. You can use it by calling <filename>all-package.nix</filename> with the <varname>stdenvType</varname> argument set to <literal>"i686-mingw"</literal>.
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        <literal>i686-darwin</literal>, i.e., Mac OS X on Intel CPUs.
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        <literal>powerpc-linux</literal>.
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        <literal>x86_64-linux</literal>, i.e., Linux on 64-bit AMD/Intel CPUs. Unlike <literal>i686-linux</literal>, this platform doesn’t have a pure <literal>stdenv</literal> yet.
+       </para>
+      </listitem>
+     </itemizedlist>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     The default compiler is now GCC 4.1.1.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     X11 updated to X.org’s X11R7.1.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Notable new packages:
+     <itemizedlist>
+      <listitem>
+       <para>
+        Opera.
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        Microsoft Visual C++ 2005 Express Edition and the Windows SDK.
+       </para>
+      </listitem>
+     </itemizedlist>
+     In total there are now around 809 packages in Nixpkgs.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     It is now <emphasis>much</emphasis> easier to override the default C compiler and other tools in <literal>stdenv</literal> for specific packages. <filename>all-packages.nix</filename> provides two utility functions for this purpose: <function>overrideGCC</function> and <function>overrideInStdenv</function>. Both take a <literal>stdenv</literal> and return an augmented <literal>stdenv</literal>; the formed changes the C compiler, and the latter adds additional packages to the front of <literal>stdenv</literal>’s initial <envar>PATH</envar>, allowing tools to be overridden.
+    </para>
+    <para>
+     For instance, the package <varname>strategoxt</varname> doesn’t build with the GNU Make in <literal>stdenv</literal> (version 3.81), so we call it with an augmented <literal>stdenv</literal> that uses GNU Make 3.80:
+<programlisting>
+strategoxt = (import ../development/compilers/strategoxt) {
+  inherit fetchurl pkgconfig sdf aterm;
+  stdenv = overrideInStdenv stdenv [gnumake380];
+};
+
+gnumake380 = <replaceable>...</replaceable>;</programlisting>
+     Likewise, there are many packages that don’t compile with the default GCC (4.1.1), but that’s easily fixed:
+<programlisting>
+exult = import ../games/exult {
+  inherit fetchurl SDL SDL_mixer zlib libpng unzip;
+  stdenv = overrideGCC stdenv gcc34;
+};</programlisting>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     It has also become much easier to experiment with changes to the <literal>stdenv</literal> setup script (which notably contains the generic builder). Since edits to <filename>pkgs/stdenv/generic/setup.sh</filename> trigger a rebuild of <emphasis>everything</emphasis>, this was formerly quite painful. But now <literal>stdenv</literal> contains a function to “regenerate” <literal>stdenv</literal> with a different setup script, allowing the use of a different setup script for specific packages:
+<programlisting>
+pkg = import <replaceable>...</replaceable> {
+  stdenv = stdenv.regenerate ./my-setup.sh;
+  <replaceable>...</replaceable>
+}</programlisting>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Packages can now have a human-readable <emphasis>description</emphasis> field. Package descriptions are shown by <literal>nix-env -qa --description</literal>. In addition, they’re shown on the Nixpkgs release page. A description can be added to a package as follows:
+<programlisting>
+stdenv.mkDerivation {
+  name = "exult-1.2";
+  <replaceable>...</replaceable>
+  meta = {
+    description = "A reimplementation of the Ultima VII game engine";
+  };
+}</programlisting>
+     The <varname>meta</varname> attribute is not passed to the builder, so changes to the description do not trigger a rebuild. Additional <varname>meta</varname> attributes may be defined in the future (such as the URL of the package’s homepage, the license, etc.).
+    </para>
+   </listitem>
+  </itemizedlist>
+
+  <para>
+   The following people contributed to this release: Andres Löh, Armijn Hemel, Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof, Martin Bravenboer, Merijn de Jonge, Rob Vermaas and Roy van den Broek.
+  </para>
+ </section>
+ <section xml:id="release-notes-0.9">
+  <title>Release 0.9 (January 31, 2006)</title>
+
+  <para>
+   There have been zillions of changes since the last release of Nixpkgs. Many packages have been added or updated. The following are some of the more notable changes:
+  </para>
+
+  <itemizedlist>
+   <listitem>
+    <para>
+     Distribution files have been moved to <link
+  xlink:href="https://nixos.org/" />.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     The C library on Linux, Glibc, has been updated to version 2.3.6.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     The default compiler is now GCC 3.4.5. GCC 4.0.2 is also available.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     The old, unofficial Xlibs has been replaced by the official modularised X11 distribution from X.org, i.e., X11R7.0. X11R7.0 consists of 287 (!) packages, all of which are in Nixpkgs though not all have been tested. It is now possible to build a working X server (previously we only had X client libraries). We use a fully Nixified X server on NixOS.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     The Sun JDK 5 has been purified, i.e., it doesn’t require any non-Nix components such as <filename>/lib/ld-linux.so.2</filename>. This means that Java applications such as Eclipse and Azureus can run on NixOS.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Hardware-accelerated OpenGL support, used by games like Quake 3 (which is now built from source).
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Improved support for FreeBSD on x86.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Improved Haskell support; e.g., the GHC build is now pure.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Some support for cross-compilation: cross-compiling builds of GCC and Binutils, and cross-compiled builds of the C library uClibc.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Notable new packages:
+     <itemizedlist>
+      <listitem>
+       <para>
+        teTeX, including support for building LaTeX documents using Nix (with automatic dependency determination).
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        Ruby.
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        System-level packages to support NixOS, e.g. Grub, GNU <literal>parted</literal> and so on.
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        <literal>ecj</literal>, the Eclipse Compiler for Java, so we finally have a freely distributable compiler that supports Java 5.0.
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        <literal>php</literal>.
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        The GIMP.
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        Inkscape.
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        GAIM.
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        <literal>kdelibs</literal>. This allows us to add KDE-based packages (such as <literal>kcachegrind</literal>).
+       </para>
+      </listitem>
+     </itemizedlist>
+    </para>
+   </listitem>
+  </itemizedlist>
+
+  <para>
+   The following people contributed to this release: Andres Löh, Armijn Hemel, Bogdan Dumitriu, Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof, Martin Bravenboer, Rob Vermaas and Roy van den Broek.
+  </para>
+ </section>
+ <section xml:id="release-notes-0.8">
+  <title>Release 0.8 (April 11, 2005)</title>
+
+  <para>
+   This release is mostly to remain synchronised with the changed hashing scheme in Nix 0.8.
+  </para>
+
+  <para>
+   Notable updates:
+   <itemizedlist>
+    <listitem>
+     <para>
+      Adobe Reader 7.0
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Various security updates (zlib 1.2.2, etc.)
+     </para>
+    </listitem>
+   </itemizedlist>
+  </para>
+ </section>
+ <section xml:id="release-notes-0.7">
+  <title>Release 0.7 (March 14, 2005)</title>
+
+  <itemizedlist>
+   <listitem>
+    <para>
+     The bootstrap process for the standard build environment on Linux (stdenv-linux) has been improved. It is no longer dependent in its initial bootstrap stages on the system Glibc, GCC, and other tools. Rather, Nixpkgs contains a statically linked bash and curl, and uses that to download other statically linked tools. These are then used to build a Glibc and dynamically linked versions of all other tools.
+    </para>
+    <para>
+     This change also makes the bootstrap process faster. For instance, GCC is built only once instead of three times.
+    </para>
+    <para>
+     (Contributed by Armijn Hemel.)
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Tarballs used by Nixpkgs are now obtained from the same server that hosts Nixpkgs (<link
+  xlink:href="http://catamaran.labs.cs.uu.nl/" />). This reduces the risk of packages being unbuildable due to moved or deleted files on various servers.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     There now is a generic mechanism for building Perl modules. See the various Perl modules defined in pkgs/system/all-packages-generic.nix.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Notable new packages:
+     <itemizedlist>
+      <listitem>
+       <para>
+        Qt 3
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        MySQL
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        MythTV
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        Mono
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        MonoDevelop (alpha)
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        Xine
+       </para>
+      </listitem>
+     </itemizedlist>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Notable updates:
+     <itemizedlist>
+      <listitem>
+       <para>
+        GCC 3.4.3
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        Glibc 2.3.4
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        GTK 2.6
+       </para>
+      </listitem>
+     </itemizedlist>
+    </para>
+   </listitem>
+  </itemizedlist>
+ </section>
+</article>

doc/stdenv/cross-compilation.chapter.md

@@ -153,24 +153,6 @@ Add the following to your `mkDerivation` invocation.
 doCheck = stdenv.hostPlatform == stdenv.buildPlatform;
 ```
 
-#### Package using Meson needs to run binaries for the host platform during build. {#cross-meson-runs-host-code}
-
-Add `mesonEmulatorHook` to `nativeBuildInputs` conditionally on if the target binaries can be executed.
-
-e.g.
-
-```
-nativeBuildInputs = [
-  meson
-] ++ lib.optionals (!stdenv.buildPlatform.canExecute stdenv.hostPlatform) [
-  mesonEmulatorHook
-];
-```
-
-Example of an error which this fixes.
-
-`[Errno 8] Exec format error: './gdk3-scan'`
-
 ## Cross-building packages {#sec-cross-usage}
 
 Nixpkgs can be instantiated with `localSystem` alone, in which case there is no cross-compiling and everything is built by and for that system, or also with `crossSystem`, in which case packages run on the latter, but all building happens on the former. Both parameters take the same schema as the 3 (build, host, and target) platforms defined in the previous section. As mentioned above, `lib.systems.examples` has some platforms which are used as arguments for these parameters in practice. You can use them programmatically, or on the command line:
@@ -250,5 +232,5 @@ Thirdly, it is because everything target-mentioning only exists to accommodate c
 :::
 
 ::: {.note}
-If one explores Nixpkgs, they will see derivations with names like `gccCross`. Such `*Cross` derivations is a holdover from before we properly distinguished between the host and target platforms—the derivation with “Cross” in the name covered the `build = host != target` case, while the other covered the `host = target`, with build platform the same or not based on whether one was using its `.__spliced.buildHost` or `.__spliced.hostTarget`.
+If one explores Nixpkgs, they will see derivations with names like `gccCross`. Such `*Cross` derivations is a holdover from before we properly distinguished between the host and target platforms—the derivation with “Cross” in the name covered the `build = host != target` case, while the other covered the `host = target`, with build platform the same or not based on whether one was using its `.nativeDrv` or `.crossDrv`. This ugliness will disappear soon.
 :::

doc/stdenv/meta.chapter.md

@@ -44,8 +44,8 @@ $ nix-env -qa hello --json
                 "mips32-linux",
                 "x86_64-darwin",
                 "i686-cygwin",
-                "i686-freebsd13",
-                "x86_64-freebsd13",
+                "i686-freebsd",
+                "x86_64-freebsd",
                 "i686-openbsd",
                 "x86_64-openbsd"
             ],
@@ -80,7 +80,7 @@ Right: `"A library for decoding PNG images"`
 
 ### `longDescription` {#var-meta-longDescription}
 
-An arbitrarily long description of the package in [CommonMark](https://commonmark.org) Markdown.
+An arbitrarily long description of the package.
 
 ### `branch` {#var-meta-branch}
 
@@ -213,10 +213,6 @@ runCommand "my-package-test" {
 
 A timeout (in seconds) for building the derivation. If the derivation takes longer than this time to build, it can fail due to breaking the timeout. However, all computers do not have the same computing power, hence some builders may decide to apply a multiplicative factor to this value. When filling this value in, try to keep it approximately consistent with other values already present in `nixpkgs`.
 
-`meta` attributes are not stored in the instantiated derivation.
-Therefore, this setting may be lost when the package is used as a dependency.
-To be effective, it must be presented directly to an evaluation process that handles the `meta.timeout` attribute.
-
 ### `hydraPlatforms` {#var-meta-hydraPlatforms}
 
 The list of Nix platform types for which the Hydra instance at `hydra.nixos.org` will build the package. (Hydra is the Nix-based continuous build system.) It defaults to the value of `meta.platforms`. Thus, the only reason to set `meta.hydraPlatforms` is if you want `hydra.nixos.org` to build the package on a subset of `meta.platforms`, or not at all, e.g.
@@ -253,31 +249,3 @@ Unfree package that cannot be redistributed. You can build it yourself, but you
 ### `lib.licenses.unfreeRedistributableFirmware`, `"unfree-redistributable-firmware"` {#lib.licenses.unfreeredistributablefirmware-unfree-redistributable-firmware}
 
 This package supplies unfree, redistributable firmware. This is a separate value from `unfree-redistributable` because not everybody cares whether firmware is free.
-
-## Source provenance {#sec-meta-sourceProvenance}
-
-The value of a package's `meta.sourceProvenance` attribute specifies the provenance of the package's derivation outputs.
-
-If a package contains elements that are not built from the original source by a nixpkgs derivation, the `meta.sourceProvenance` attribute should be a list containing one or more value from `lib.sourceTypes` defined in [`nixpkgs/lib/source-types.nix`](https://github.com/NixOS/nixpkgs/blob/master/lib/source-types.nix).
-
-Adding this information helps users who have needs related to build transparency and supply-chain security to gain some visibility into their installed software or set policy to allow or disallow installation based on source provenance.
-
-The presence of a particular `sourceType` in a package's `meta.sourceProvenance` list indicates that the package contains some components falling into that category, though the *absence* of that `sourceType` does not *guarantee* the absence of that category of `sourceType` in the package's contents. A package with no `meta.sourceProvenance` set implies it has no *known* `sourceType`s other than `fromSource`.
-
-The meaning of the `meta.sourceProvenance` attribute does not depend on the value of the `meta.license` attribute.
-
-### `lib.sourceTypes.fromSource` {#lib.sourceTypes.fromSource}
-
-Package elements which are produced by a nixpkgs derivation which builds them from source code.
-
-### `lib.sourceTypes.binaryNativeCode` {#lib.sourceTypes.binaryNativeCode}
-
-Native code to be executed on the target system's CPU, built by a third party. This includes packages which wrap a downloaded AppImage or Debian package.
-
-### `lib.sourceTypes.binaryFirmware` {#lib.sourceTypes.binaryFirmware}
-
-Code to be executed on a peripheral device or embedded controller, built by a third party.
-
-### `lib.sourceTypes.binaryBytecode` {#lib.sourceTypes.binaryBytecode}
-
-Code to run on a VM interpreter or JIT compiled into bytecode by a third party. This includes packages which download Java `.jar` files from another source.

doc/stdenv/multiple-output.chapter.md

@@ -77,7 +77,7 @@ There is a special handling of the `debug` output, described at [](#stdenv-separ
 
 A commonly adopted convention in `nixpkgs` is that executables provided by the package are contained within its first output. This convention allows the dependent packages to reference the executables provided by packages in a uniform manner. For instance, provided with the knowledge that the `perl` package contains a `perl` executable it can be referenced as `${pkgs.perl}/bin/perl` within a Nix derivation that needs to execute a Perl script.
 
-The `glibc` package is a deliberate single exception to the “binaries first” convention. The `glibc` has `libs` as its first output allowing the libraries provided by `glibc` to be referenced directly (e.g. `${glibc}/lib/ld-linux-x86-64.so.2`). The executables provided by `glibc` can be accessed via its `bin` attribute (e.g. `${lib.getBin stdenv.cc.libc}/bin/ldd`).
+The `glibc` package is a deliberate single exception to the “binaries first” convention. The `glibc` has `libs` as its first output allowing the libraries provided by `glibc` to be referenced directly (e.g. `${stdenv.glibc}/lib/ld-linux-x86-64.so.2`). The executables provided by `glibc` can be accessed via its `bin` attribute (e.g. `${stdenv.glibc.bin}/bin/ldd`).
 
 The reason for why `glibc` deviates from the convention is because referencing a library provided by `glibc` is a very common operation among Nix packages. For instance, third-party executables packaged by Nix are typically patched and relinked with the relevant version of `glibc` libraries from Nix packages (please see the documentation on [patchelf](https://github.com/NixOS/patchelf) for more details).
 

doc/stdenv/platform-notes.chapter.md

@@ -60,8 +60,3 @@ Some common issues when packaging software for Darwin:
   ```
 
   The package `xcbuild` can be used to build projects that really depend on Xcode. However, this replacement is not 100% compatible with Xcode and can occasionally cause issues.
-
-- x86_64-darwin uses the 10.12 SDK by default, but some software is not compatible with that version of the SDK. In that case,
-  the 11.0 SDK used by aarch64-darwin is available for use on x86_64-darwin. To use it, reference `apple_sdk_11_0` instead of
-  `apple_sdk` in your derivation and use `pkgs.darwin.apple_sdk_11_0.callPackage` instead of `pkgs.callPackage`. On Linux, this will
-  have the same effect as `pkgs.callPackage`, so you can use `pkgs.darwin.apple_sdk_11_0.callPackage` regardless of platform.

doc/stdenv/stdenv.chapter.md

@@ -77,7 +77,7 @@ where the builder can do anything it wants, but typically starts with
 source $stdenv/setup
 ```
 
-to let `stdenv` set up the environment (e.g. by resetting `PATH` and populating it from build inputs). If you want, you can still use `stdenv`’s generic builder:
+to let `stdenv` set up the environment (e.g., process the `buildInputs`). If you want, you can still use `stdenv`’s generic builder:
 
 ```bash
 source $stdenv/setup
@@ -309,7 +309,7 @@ The attribute can also contain a list, a script followed by arguments to be pass
 passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ];
 ```
 
-The script will be run with the `UPDATE_NIX_NAME`, `UPDATE_NIX_PNAME`, `UPDATE_NIX_OLD_VERSION` and `UPDATE_NIX_ATTR_PATH` environment variables set respectively to the name, pname, old version and attribute path of the package it is supposed to update.
+The script will be run with `UPDATE_NIX_ATTR_PATH` environment variable set to the attribute path it is supposed to update.
 
 ::: {.note}
 The script will be usually run from the root of the Nixpkgs repository but you should not rely on that. Also note that the update scripts will be run in parallel by default; you should avoid running `git commit` or any other commands that cannot handle that.
@@ -317,7 +317,7 @@ The script will be usually run from the root of the Nixpkgs repository but you s
 
 For information about how to run the updates, execute `nix-shell maintainers/scripts/update.nix`.
 
-### Recursive attributes in `mkDerivation` {#mkderivation-recursive-attributes}
+### Recursive attributes in `mkDerivation`
 
 If you pass a function to `mkDerivation`, it will receive as its argument the final arguments, including the overrides when reinvoked via `overrideAttrs`. For example:
 
@@ -452,8 +452,6 @@ The list of source files or directories to be unpacked or copied. One of these m
 
 After running `unpackPhase`, the generic builder changes the current directory to the directory created by unpacking the sources. If there are multiple source directories, you should set `sourceRoot` to the name of the intended directory. Set `sourceRoot = ".";` if you use `srcs` and control the unpack phase yourself.
 
-By default the `sourceRoot` is set to `"source"`. If you want to point to a sub-directory inside your project, you therefore need to set `sourceRoot = "source/my-sub-directory"`.
-
 ##### `setSourceRoot` {#var-stdenv-setSourceRoot}
 
 Alternatively to setting `sourceRoot`, you can set `setSourceRoot` to a shell command to be evaluated by the unpack phase after the sources have been unpacked. This command must set `sourceRoot`.
@@ -700,12 +698,12 @@ Hook executed at the end of the install phase.
 
 ### The fixup phase {#ssec-fixup-phase}
 
-The fixup phase performs (Nix-specific) post-processing actions on the files installed under `$out` by the install phase. The default `fixupPhase` does the following:
+The fixup phase performs some (Nix-specific) post-processing actions on the files installed under `$out` by the install phase. The default `fixupPhase` does the following:
 
 - It moves the `man/`, `doc/` and `info/` subdirectories of `$out` to `share/`.
 - It strips libraries and executables of debug information.
 - On Linux, it applies the `patchelf` command to ELF executables and libraries to remove unused directories from the `RPATH` in order to prevent unnecessary runtime dependencies.
-- It rewrites the interpreter paths of shell scripts to paths found in `PATH`. E.g., `/usr/bin/perl` will be rewritten to `/nix/store/some-perl/bin/perl` found in `PATH`. See [](#patch-shebangs.sh) for details.
+- It rewrites the interpreter paths of shell scripts to paths found in `PATH`. E.g., `/usr/bin/perl` will be rewritten to `/nix/store/some-perl/bin/perl` found in `PATH`.
 
 #### Variables controlling the fixup phase {#variables-controlling-the-fixup-phase}
 
@@ -733,10 +731,6 @@ If set, files in `$out/sbin` are not moved to `$out/bin`. By default, they are.
 
 List of directories to search for libraries and executables from which *all* symbols should be stripped. By default, it’s empty. Stripping all symbols is risky, since it may remove not just debug symbols but also ELF information necessary for normal execution.
 
-##### `stripAllListTarget` {#var-stdenv-stripAllListTarget}
-
-Like `stripAllList`, but only applies to packages’ target platform. By default, it’s empty. Useful when supporting cross compilation.
-
 ##### `stripAllFlags` {#var-stdenv-stripAllFlags}
 
 Flags passed to the `strip` command applied to the files in the directories listed in `stripAllList`. Defaults to `-s` (i.e. `--strip-all`).
@@ -745,10 +739,6 @@ Flags passed to the `strip` command applied to the files in the directories list
 
 List of directories to search for libraries and executables from which only debugging-related symbols should be stripped. It defaults to `lib lib32 lib64 libexec bin sbin`.
 
-##### `stripDebugListTarget` {#var-stdenv-stripDebugListTarget}
-
-Like `stripDebugList`, but only applies to packages’ target platform. By default, it’s empty. Useful when supporting cross compilation.
-
 ##### `stripDebugFlags` {#var-stdenv-stripDebugFlags}
 
 Flags passed to the `strip` command applied to the files in the directories listed in `stripDebugList`. Defaults to `-S` (i.e. `--strip-debug`).
@@ -759,7 +749,7 @@ If set, the `patchelf` command is not used to remove unnecessary `RPATH` entries
 
 ##### `dontPatchShebangs` {#var-stdenv-dontPatchShebangs}
 
-If set, scripts starting with `#!` do not have their interpreter paths rewritten to paths in the Nix store. See [](#patch-shebangs.sh) on how patching shebangs works.
+If set, scripts starting with `#!` do not have their interpreter paths rewritten to paths in the Nix store.
 
 ##### `dontPruneLibtoolFiles` {#var-stdenv-dontPruneLibtoolFiles}
 
@@ -873,27 +863,12 @@ Constructs a wrapper for a program with various possible arguments. It is define
 # adds `FOOBAR=baz` to `$out/bin/foo`’s environment
 makeWrapper $out/bin/foo $wrapperfile --set FOOBAR baz
 
-# Prefixes the binary paths of `hello` and `git`
-# and suffixes the binary path of `xdg-utils`.
+# prefixes the binary paths of `hello` and `git`
 # Be advised that paths often should be patched in directly
 # (via string replacements or in `configurePhase`).
-makeWrapper $out/bin/foo $wrapperfile \
-  --prefix PATH : ${lib.makeBinPath [ hello git ]} \
-  --suffix PATH : ${lib.makeBinPath [ xdg-utils ]}
+makeWrapper $out/bin/foo $wrapperfile --prefix PATH : ${lib.makeBinPath [ hello git ]}
 ```
 
-Packages may expect or require other utilities to be available at runtime.
-`makeWrapper` can be used to add packages to a `PATH` environment variable local to a wrapper.
-
-Use `--prefix` to explicitly set dependencies in `PATH`.
-
-::: {.note}
-`--prefix` essentially hard-codes dependencies into the wrapper.
-They cannot be overridden without rebuilding the package.
-:::
-
-If dependencies should be resolved at runtime, use `--suffix` to append fallback values to `PATH`.
-
 There’s many more kinds of arguments, they are documented in `nixpkgs/pkgs/build-support/setup-hooks/make-wrapper.sh` for the `makeWrapper` implementation and in `nixpkgs/pkgs/build-support/setup-hooks/make-binary-wrapper/make-binary-wrapper.sh` for the `makeBinaryWrapper` implementation.
 
 `wrapProgram` is a convenience function you probably want to use most of the time, implemented by both `makeWrapper` and `makeBinaryWrapper`.
@@ -938,9 +913,9 @@ substitute ./foo.in ./foo.out \
     --subst-var someVar
 ```
 
-### `substituteInPlace` \<multiple files\> \<subs\> {#fun-substituteInPlace}
+### `substituteInPlace` \<file\> \<subs\> {#fun-substituteInPlace}
 
-Like `substitute`, but performs the substitutions in place on the files passed.
+Like `substitute`, but performs the substitutions in place on the file \<file\>.
 
 ### `substituteAll` \<infile\> \<outfile\> {#fun-substituteAll}
 
@@ -1008,7 +983,7 @@ addEnvHooks "$hostOffset" myBashFunction
 
 The *existence* of setups hooks has long been documented and packages inside Nixpkgs are free to use this mechanism. Other packages, however, should not rely on these mechanisms not changing between Nixpkgs versions. Because of the existing issues with this system, there’s little benefit from mandating it be stable for any period of time.
 
-First, let’s cover some setup hooks that are part of Nixpkgs default `stdenv`. This means that they are run for every package built using `stdenv.mkDerivation` or when using a custom builder that has `source $stdenv/setup`. Some of these are platform specific, so they may run on Linux but not Darwin or vice-versa.
+First, let’s cover some setup hooks that are part of Nixpkgs default stdenv. This means that they are run for every package built using `stdenv.mkDerivation`. Some of these are platform specific, so they may run on Linux but not Darwin or vice-versa.
 
 ### `move-docs.sh` {#move-docs.sh}
 
@@ -1024,70 +999,7 @@ This runs the strip command on installed binaries and libraries. This removes un
 
 ### `patch-shebangs.sh` {#patch-shebangs.sh}
 
-This setup hook patches installed scripts to add Nix store paths to their shebang interpreter as found in the build environment. The [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) line tells a Unix-like operating system which interpreter to use to execute the script's contents.
-
-::: note
-The [generic builder][generic-builder] populates `PATH` from inputs of the derivation.
-:::
-
-[generic-builder]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/stdenv/generic/builder.sh
-
-#### Invocation {#patch-shebangs.sh-invocation}
-
-Multiple paths can be specified.
-
-```
-patchShebangs [--build | --host] PATH...
-```
-
-##### Flags
-
-`--build`
-: Look up commands available at build time
-
-`--host`
-: Look up commands available at run time
-
-##### Examples
-
-```sh
-patchShebangs --host /nix/store/<hash>-hello-1.0/bin
-```
-
-```sh
-patchShebangs --build configure
-```
-
-`#!/bin/sh` will be rewritten to `#!/nix/store/<hash>-some-bash/bin/sh`.
-
-`#!/usr/bin/env` gets special treatment: `#!/usr/bin/env python` is rewritten to `/nix/store/<hash>/bin/python`.
-
-Interpreter paths that point to a valid Nix store location are not changed.
-
-::: note
-A script file must be marked as executable, otherwise it will not be
-considered.
-:::
-
-This mechanism ensures that the interpreter for a given script is always found and is exactly the one specified by the build.
-
-It can be disabled by setting [`dontPatchShebangs`](#var-stdenv-dontPatchShebangs):
-
-```nix
-stdenv.mkDerivation {
-  # ...
-  dontPatchShebangs = true;
-  # ...
-}
-```
-
-The file [`patch-shebangs.sh`][patch-shebangs.sh] defines the [`patchShebangs`][patchShebangs] function. It is used to implement [`patchShebangsAuto`][patchShebangsAuto], the [setup hook](#ssec-setup-hooks) that is registered to run during the [fixup phase](#ssec-fixup-phase) by default.
-
-If you need to run `patchShebangs` at build time, it must be called explicitly within [one of the build phases](#sec-stdenv-phases).
-
-[patch-shebangs.sh]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/build-support/setup-hooks/patch-shebangs.sh
-[patchShebangs]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/build-support/setup-hooks/patch-shebangs.sh#L24-L105
-[patchShebangsAuto]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/build-support/setup-hooks/patch-shebangs.sh#L107-L119
+This setup hook patches installed scripts to use the full path to the shebang interpreter. A shebang interpreter is the first commented line of a script telling the operating system which program will run the script (e.g `#!/bin/bash`). In Nix, we want an exact path to that interpreter to be used. This often replaces `/bin/sh` with a path in the Nix store.
 
 ### `audit-tmpdir.sh` {#audit-tmpdir.sh}
 
@@ -1109,15 +1021,13 @@ This setup hook moves any libraries installed in the `lib64/` subdirectory into
 
 This setup hook moves any systemd user units installed in the `lib/` subdirectory into `share/`. In addition, a link is provided from `share/` to `lib/` for compatibility. This is needed for systemd to find user services when installed into the user profile.
 
-This hook only runs when compiling for Linux.
-
 ### `set-source-date-epoch-to-latest.sh` {#set-source-date-epoch-to-latest.sh}
 
 This sets `SOURCE_DATE_EPOCH` to the modification time of the most recent file.
 
-### Bintools Wrapper and hook {#bintools-wrapper}
+### Bintools Wrapper {#bintools-wrapper}
 
-The Bintools Wrapper wraps the binary utilities for a bunch of miscellaneous purposes. These are GNU Binutils when targeting Linux, and a mix of cctools and GNU binutils for Darwin. \[The “Bintools” name is supposed to be a compromise between “Binutils” and “cctools” not denoting any specific implementation.\] Specifically, the underlying bintools package, and a C standard library (glibc or Darwin’s libSystem, just for the dynamic loader) are all fed in, and dependency finding, hardening (see below), and purity checks for each are handled by the Bintools Wrapper. Packages typically depend on CC Wrapper, which in turn (at run time) depends on the Bintools Wrapper.
+The Bintools Wrapper wraps the binary utilities for a bunch of miscellaneous purposes. These are GNU Binutils when targetting Linux, and a mix of cctools and GNU binutils for Darwin. \[The “Bintools” name is supposed to be a compromise between “Binutils” and “cctools” not denoting any specific implementation.\] Specifically, the underlying bintools package, and a C standard library (glibc or Darwin’s libSystem, just for the dynamic loader) are all fed in, and dependency finding, hardening (see below), and purity checks for each are handled by the Bintools Wrapper. Packages typically depend on CC Wrapper, which in turn (at run time) depends on the Bintools Wrapper.
 
 The Bintools Wrapper was only just recently split off from CC Wrapper, so the division of labor is still being worked out. For example, it shouldn’t care about the C standard library, but just take a derivation with the dynamic loader (which happens to be the glibc on linux). Dependency finding however is a task both wrappers will continue to need to share, and probably the most important to understand. It is currently accomplished by collecting directories of host-platform dependencies (i.e. `buildInputs` and `nativeBuildInputs`) in environment variables. The Bintools Wrapper’s setup hook causes any `lib` and `lib64` subdirectories to be added to `NIX_LDFLAGS`. Since the CC Wrapper and the Bintools Wrapper use the same strategy, most of the Bintools Wrapper code is sparsely commented and refers to the CC Wrapper. But the CC Wrapper’s code, by contrast, has quite lengthy comments. The Bintools Wrapper merely cites those, rather than repeating them, to avoid falling out of sync.
 
@@ -1125,27 +1035,173 @@ A final task of the setup hook is defining a number of standard environment vari
 
 A problem with this final task is that the Bintools Wrapper is honest and defines `LD` as `ld`. Most packages, however, firstly use the C compiler for linking, secondly use `LD` anyways, defining it as the C compiler, and thirdly, only so define `LD` when it is undefined as a fallback. This triple-threat means Bintools Wrapper will break those packages, as LD is already defined as the actual linker which the package won’t override yet doesn’t want to use. The workaround is to define, just for the problematic package, `LD` as the C compiler. A good way to do this would be `preConfigure = "LD=$CC"`.
 
-### CC Wrapper and hook {#cc-wrapper}
+### CC Wrapper {#cc-wrapper}
 
 The CC Wrapper wraps a C toolchain for a bunch of miscellaneous purposes. Specifically, a C compiler (GCC or Clang), wrapped binary tools, and a C standard library (glibc or Darwin’s libSystem, just for the dynamic loader) are all fed in, and dependency finding, hardening (see below), and purity checks for each are handled by the CC Wrapper. Packages typically depend on the CC Wrapper, which in turn (at run-time) depends on the Bintools Wrapper.
 
-Dependency finding is undoubtedly the main task of the CC Wrapper. This works just like the Bintools Wrapper, except that any `include` subdirectory of any relevant dependency is added to `NIX_CFLAGS_COMPILE`. The setup hook itself contains elaborate comments describing the exact mechanism by which this is accomplished.
+Dependency finding is undoubtedly the main task of the CC Wrapper. This works just like the Bintools Wrapper, except that any `include` subdirectory of any relevant dependency is added to `NIX_CFLAGS_COMPILE`. The setup hook itself contains some lengthy comments describing the exact convoluted mechanism by which this is accomplished.
 
 Similarly, the CC Wrapper follows the Bintools Wrapper in defining standard environment variables with the names of the tools it wraps, for the same reasons described above. Importantly, while it includes a `cc` symlink to the c compiler for portability, the `CC` will be defined using the compiler’s “real name” (i.e. `gcc` or `clang`). This helps lousy build systems that inspect on the name of the compiler rather than run it.
 
 Here are some more packages that provide a setup hook. Since the list of hooks is extensible, this is not an exhaustive list. The mechanism is only to be used as a last resort, so it might cover most uses.
 
-### Other hooks
+### Perl {#setup-hook-perl}
 
-Many other packages provide hooks, that are not part of `stdenv`. You can find
-these in the [Hooks Reference](#chap-hooks).
+Adds the `lib/site_perl` subdirectory of each build input to the `PERL5LIB` environment variable. For instance, if `buildInputs` contains Perl, then the `lib/site_perl` subdirectory of each input is added to the `PERL5LIB` environment variable.
 
-### Compiler and Linker wrapper hooks {#compiler-linker-wrapper-hooks}
+### Python {#setup-hook-python}
 
-If the file `${cc}/nix-support/cc-wrapper-hook` exists, it will be run at the end of the [compiler wrapper](#cc-wrapper).
-If the file `${binutils}/nix-support/post-link-hook` exists, it will be run at the end of the linker wrapper.
-These hooks allow a user to inject code into the wrappers.
-As an example, these hooks can be used to extract `extraBefore`, `params` and `extraAfter` which store all the command line arguments passed to the compiler and linker respectively.
+Adds the `lib/${python.libPrefix}/site-packages` subdirectory of each build input to the `PYTHONPATH` environment variable.
+
+### pkg-config {#setup-hook-pkg-config}
+
+Adds the `lib/pkgconfig` and `share/pkgconfig` subdirectories of each build input to the `PKG_CONFIG_PATH` environment variable.
+
+### Automake {#setup-hook-automake}
+
+Adds the `share/aclocal` subdirectory of each build input to the `ACLOCAL_PATH` environment variable.
+
+### Autoconf {#setup-hook-autoconf}
+
+The `autoreconfHook` derivation adds `autoreconfPhase`, which runs autoreconf, libtoolize and automake, essentially preparing the configure script in autotools-based builds. Most autotools-based packages come with the configure script pre-generated, but this hook is necessary for a few packages and when you need to patch the package’s configure scripts.
+
+### libxml2 {#setup-hook-libxml2}
+
+Adds every file named `catalog.xml` found under the `xml/dtd` and `xml/xsl` subdirectories of each build input to the `XML_CATALOG_FILES` environment variable.
+
+### teTeX / TeX Live {#tetex-tex-live}
+
+Adds the `share/texmf-nix` subdirectory of each build input to the `TEXINPUTS` environment variable.
+
+### Qt 4 {#qt-4}
+
+Sets the `QTDIR` environment variable to Qt’s path.
+
+### gdk-pixbuf {#setup-hook-gdk-pixbuf}
+
+Exports `GDK_PIXBUF_MODULE_FILE` environment variable to the builder. Add librsvg package to `buildInputs` to get svg support. See also the [setup hook description in GNOME platform docs](#ssec-gnome-hooks-gdk-pixbuf).
+
+### GHC {#ghc}
+
+Creates a temporary package database and registers every Haskell build input in it (TODO: how?).
+
+### GNOME platform {#gnome-platform}
+
+Hooks related to GNOME platform and related libraries like GLib, GTK and GStreamer are described in [](#sec-language-gnome).
+
+### autoPatchelfHook {#setup-hook-autopatchelfhook}
+
+This is a special setup hook which helps in packaging proprietary software in that it automatically tries to find missing shared library dependencies of ELF files based on the given `buildInputs` and `nativeBuildInputs`.
+
+You can also specify a `runtimeDependencies` variable which lists dependencies to be unconditionally added to rpath of all executables. This is useful for programs that use dlopen 3 to load libraries at runtime.
+
+In certain situations you may want to run the main command (`autoPatchelf`) of the setup hook on a file or a set of directories instead of unconditionally patching all outputs. This can be done by setting the `dontAutoPatchelf` environment variable to a non-empty value.
+
+By default `autoPatchelf` will fail as soon as any ELF file requires a dependency which cannot be resolved via the given build inputs. In some situations you might prefer to just leave missing dependencies unpatched and continue to patch the rest. This can be achieved by setting the `autoPatchelfIgnoreMissingDeps` environment variable to a non-empty value. `autoPatchelfIgnoreMissingDeps` can be set to a list like `autoPatchelfIgnoreMissingDeps = [ "libcuda.so.1" "libcudart.so.1" ];` or to simply `[ "*" ]` to ignore all missing dependencies.
+
+The `autoPatchelf` command also recognizes a `--no-recurse` command line flag, which prevents it from recursing into subdirectories.
+
+### breakpointHook {#breakpointhook}
+
+This hook will make a build pause instead of stopping when a failure happens. It prevents nix from cleaning up the build environment immediately and allows the user to attach to a build environment using the `cntr` command. Upon build error it will print instructions on how to use `cntr`, which can be used to enter the environment for debugging. Installing cntr and running the command will provide shell access to the build sandbox of failed build. At `/var/lib/cntr` the sandboxed filesystem is mounted. All commands and files of the system are still accessible within the shell. To execute commands from the sandbox use the cntr exec subcommand. `cntr` is only supported on Linux-based platforms. To use it first add `cntr` to your `environment.systemPackages` on NixOS or alternatively to the root user on non-NixOS systems. Then in the package that is supposed to be inspected, add `breakpointHook` to `nativeBuildInputs`.
+
+```nix
+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`.
+:::
+
+### installShellFiles {#installshellfiles}
+
+This hook helps with installing manpages and shell completion files. It exposes 2 shell functions `installManPage` and `installShellCompletion` that can be used from your `postInstall` hook.
+
+The `installManPage` function takes one or more paths to manpages to install. The manpages must have a section suffix, and may optionally be compressed (with `.gz` suffix). This function will place them into the correct directory.
+
+The `installShellCompletion` function takes one or more paths to shell completion files. By default it will autodetect the shell type from the completion file extension, but you may also specify it by passing one of `--bash`, `--fish`, or `--zsh`. These flags apply to all paths listed after them (up until another shell flag is given). Each path may also have a custom installation name provided by providing a flag `--name NAME` before the path. If this flag is not provided, zsh completions will be renamed automatically such that `foobar.zsh` becomes `_foobar`. A root name may be provided for all paths using the flag `--cmd NAME`; this synthesizes the appropriate name depending on the shell (e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for zsh). The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which case the shell and name must be provided.
+
+```nix
+nativeBuildInputs = [ installShellFiles ];
+postInstall = ''
+  installManPage doc/foobar.1 doc/barfoo.3
+  # explicit behavior
+  installShellCompletion --bash --name foobar.bash share/completions.bash
+  installShellCompletion --fish --name foobar.fish share/completions.fish
+  installShellCompletion --zsh --name _foobar share/completions.zsh
+  # implicit behavior
+  installShellCompletion share/completions/foobar.{bash,fish,zsh}
+  # using named fd
+  installShellCompletion --cmd foobar \
+    --bash <($out/bin/foobar --bash-completion) \
+    --fish <($out/bin/foobar --fish-completion) \
+    --zsh <($out/bin/foobar --zsh-completion)
+'';
+```
+
+### libiconv, libintl {#libiconv-libintl}
+
+A few libraries automatically add to `NIX_LDFLAGS` their library, making their symbols automatically available to the linker. This includes libiconv and libintl (gettext). This is done to provide compatibility between GNU Linux, where libiconv and libintl are bundled in, and other systems where that might not be the case. Sometimes, this behavior is not desired. To disable this behavior, set `dontAddExtraLibs`.
+
+### validatePkgConfig {#validatepkgconfig}
+
+The `validatePkgConfig` hook validates all pkg-config (`.pc`) files in a package. This helps catching some common errors in pkg-config files, such as undefined variables.
+
+### cmake {#cmake}
+
+Overrides the default configure phase to run the CMake command. By default, we use the Make generator of CMake. In addition, dependencies are added automatically to CMAKE_PREFIX_PATH so that packages are correctly detected by CMake. Some additional flags are passed in to give similar behavior to configure-based packages. You can disable this hook’s behavior by setting configurePhase to a custom value, or by setting dontUseCmakeConfigure. cmakeFlags controls flags passed only to CMake. By default, parallel building is enabled as CMake supports parallel building almost everywhere. When Ninja is also in use, CMake will detect that and use the ninja generator.
+
+### xcbuildHook {#xcbuildhook}
+
+Overrides the build and install phases to run the "xcbuild" command. This hook is needed when a project only comes with build files for the XCode build system. You can disable this behavior by setting buildPhase and configurePhase to a custom value. xcbuildFlags controls flags passed only to xcbuild.
+
+### Meson {#meson}
+
+Overrides the configure phase to run meson to generate Ninja files. To run these files, you should accompany Meson with ninja. By default, `enableParallelBuilding` is enabled as Meson supports parallel building almost everywhere.
+
+#### Variables controlling Meson {#variables-controlling-meson}
+
+##### `mesonFlags` {#mesonflags}
+
+Controls the flags passed to meson.
+
+##### `mesonBuildType` {#mesonbuildtype}
+
+Which [`--buildtype`](https://mesonbuild.com/Builtin-options.html#core-options) to pass to Meson. We default to `plain`.
+
+##### `mesonAutoFeatures` {#mesonautofeatures}
+
+What value to set [`-Dauto_features=`](https://mesonbuild.com/Builtin-options.html#core-options) to. We default to `enabled`.
+
+##### `mesonWrapMode` {#mesonwrapmode}
+
+What value to set [`-Dwrap_mode=`](https://mesonbuild.com/Builtin-options.html#core-options) to. We default to `nodownload` as we disallow network access.
+
+##### `dontUseMesonConfigure` {#dontusemesonconfigure}
+
+Disables using Meson’s `configurePhase`.
+
+### ninja {#ninja}
+
+Overrides the build, install, and check phase to run ninja instead of make. You can disable this behavior with the `dontUseNinjaBuild`, `dontUseNinjaInstall`, and `dontUseNinjaCheck`, respectively. Parallel building is enabled by default in Ninja.
+
+### unzip {#unzip}
+
+This setup hook will allow you to unzip .zip files specified in `$src`. There are many similar packages like `unrar`, `undmg`, etc.
+
+### wafHook {#wafhook}
+
+Overrides the configure, build, and install phases. This will run the “waf” script used by many projects. If `wafPath` (default `./waf`) doesn’t exist, it will copy the version of waf available in Nixpkgs. `wafFlags` can be used to pass flags to the waf script.
+
+### scons {#scons}
+
+Overrides the build, install, and check phases. This uses the scons build system as a replacement for make. scons does not provide a configure phase, so everything is managed at build and install time.
 
 ## Purity in Nixpkgs {#sec-purity-in-nixpkgs}
 
@@ -1260,7 +1316,7 @@ If the libraries lack `-fPIE`, you will get the error `recompile with -fPIE`.
 
 [^footnote-stdenv-ignored-build-platform]: The build platform is ignored because it is a mere implementation detail of the package satisfying the dependency: As a general programming principle, dependencies are always *specified* as interfaces, not concrete implementation.
 [^footnote-stdenv-native-dependencies-in-path]: Currently, this means for native builds all dependencies are put on the `PATH`. But in the future that may not be the case for sake of matching cross: the platforms would be assumed to be unique for native and cross builds alike, so only the `depsBuild*` and `nativeBuildInputs` would be added to the `PATH`.
-[^footnote-stdenv-propagated-dependencies]: Nix itself already takes a package’s transitive dependencies into account, but this propagation ensures nixpkgs-specific infrastructure like [setup hooks](#ssec-setup-hooks) also are run as if it were a propagated dependency.
+[^footnote-stdenv-propagated-dependencies]: Nix itself already takes a package’s transitive dependencies into account, but this propagation ensures nixpkgs-specific infrastructure like setup hooks (mentioned above) also are run as if the propagated dependency.
 [^footnote-stdenv-find-inputs-location]: The `findInputs` function, currently residing in `pkgs/stdenv/generic/setup.sh`, implements the propagation logic.
 [^footnote-stdenv-sys-lib-search-path]: It clears the `sys_lib_*search_path` variables in the Libtool script to prevent Libtool from using libraries in `/usr/lib` and such.
 [^footnote-stdenv-build-time-guessing-impurity]: Eventually these will be passed building natively as well, to improve determinism: build-time guessing, as is done today, is a risk of impurity.

doc/using/configuration.chapter.md

@@ -77,11 +77,6 @@ The difference between a package being unsupported on some system and being brok
 
 ## Installing unfree packages {#sec-allow-unfree}
 
-All users of Nixpkgs are free software users, and many users (and developers) of Nixpkgs want to limit and tightly control their exposure to unfree software.
-At the same time, many users need (or want) to run some specific pieces of proprietary software.
-Nixpkgs includes some expressions for unfree software packages.
-By default unfree software cannot be installed and doesn’t show up in searches.
-
 There are several ways to tweak how Nix handles a package which has been marked as unfree.
 
 -   To temporarily allow all unfree packages, you can use an environment variable for a single invocation of the nix tools:
@@ -169,6 +164,14 @@ There are several ways to tweak how Nix handles a package which has been marked
 
     Note that `permittedInsecurePackages` is only checked if `allowInsecurePredicate` is not specified.
 
+### `config` Options Reference
+
+The following attributes can be passed in [`config`](#chap-packageconfig).
+
+```{=docbook}
+<include xmlns="http://www.w3.org/2001/XInclude" href="../doc-support/result/config-options.docbook.xml"/>
+```
+
 ## Modify packages via `packageOverrides` {#sec-modify-via-packageOverrides}
 
 You can define a function called `packageOverrides` in your local `~/.config/nixpkgs/config.nix` to override Nix packages. It must be a function that takes pkgs as an argument and returns a modified set of packages.
@@ -181,15 +184,6 @@ You can define a function called `packageOverrides` in your local `~/.config/nix
 }
 ```
 
-## `config` Options Reference {#sec-config-options-reference}
-
-The following attributes can be passed in [`config`](#chap-packageconfig).
-
-```{=docbook}
-<include xmlns="http://www.w3.org/2001/XInclude" href="../doc-support/result/config-options.docbook.xml"/>
-```
-
-
 ## Declarative Package Management {#sec-declarative-package-management}
 
 ### Build an environment {#sec-building-environment}

flake.nix

@@ -11,7 +11,8 @@
 
       lib = import ./lib;
 
-      forAllSystems = lib.genAttrs lib.systems.flakeExposed;
+      forAllSystems = f: lib.genAttrs lib.systems.flakeExposed (system: f system);
+
     in
     {
       lib = lib.extend (final: prev: {
@@ -19,20 +20,13 @@
         nixos = import ./nixos/lib { lib = final; };
 
         nixosSystem = args:
-          import ./nixos/lib/eval-config.nix (
-            args // {
-              modules = args.modules ++ [{
-                system.nixos.versionSuffix =
-                  ".${final.substring 0 8 (self.lastModifiedDate or self.lastModified or "19700101")}.${self.shortRev or "dirty"}";
-                system.nixos.revision = final.mkIf (self ? rev) self.rev;
-              }];
-            } // lib.optionalAttrs (! args?system) {
-              # Allow system to be set modularly in nixpkgs.system.
-              # We set it to null, to remove the "legacy" entrypoint's
-              # non-hermetic default.
-              system = null;
-            }
-          );
+          import ./nixos/lib/eval-config.nix (args // {
+            modules = args.modules ++ [ {
+              system.nixos.versionSuffix =
+                ".${final.substring 0 8 (self.lastModifiedDate or self.lastModified or "19700101")}.${self.shortRev or "dirty"}";
+              system.nixos.revision = final.mkIf (self ? rev) self.rev;
+            } ];
+          });
       });
 
       checks.x86_64-linux.tarball = jobs.tarball;
@@ -44,19 +38,10 @@
         }).nixos.manual.x86_64-linux;
       };
 
-      # The "legacy" in `legacyPackages` doesn't imply that the packages exposed
-      # through this attribute are "legacy" packages. Instead, `legacyPackages`
-      # is used here as a substitute attribute name for `packages`. The problem
-      # with `packages` is that it makes operations like `nix flake show
-      # nixpkgs` unusably slow due to the sheer number of packages the Nix CLI
-      # needs to evaluate. But when the Nix CLI sees a `legacyPackages`
-      # attribute it displays `omitted` instead of evaluating all packages,
-      # which keeps `nix flake show` on Nixpkgs reasonably fast, though less
-      # information rich.
       legacyPackages = forAllSystems (system: import ./. { inherit system; });
 
       nixosModules = {
-        notDetected = ./nixos/modules/installer/scan/not-detected.nix;
+        notDetected = import ./nixos/modules/installer/scan/not-detected.nix;
       };
     };
 }

lib/ascii-table.nix

@@ -1,96 +0,0 @@
-{ " "  = 32;
-  "!"  = 33;
-  "\"" = 34;
-  "#"  = 35;
-  "$"  = 36;
-  "%"  = 37;
-  "&"  = 38;
-  "'"  = 39;
-  "("  = 40;
-  ")"  = 41;
-  "*"  = 42;
-  "+"  = 43;
-  ","  = 44;
-  "-"  = 45;
-  "."  = 46;
-  "/"  = 47;
-  "0"  = 48;
-  "1"  = 49;
-  "2"  = 50;
-  "3"  = 51;
-  "4"  = 52;
-  "5"  = 53;
-  "6"  = 54;
-  "7"  = 55;
-  "8"  = 56;
-  "9"  = 57;
-  ":"  = 58;
-  ";"  = 59;
-  "<"  = 60;
-  "="  = 61;
-  ">"  = 62;
-  "?"  = 63;
-  "@"  = 64;
-  "A"  = 65;
-  "B"  = 66;
-  "C"  = 67;
-  "D"  = 68;
-  "E"  = 69;
-  "F"  = 70;
-  "G"  = 71;
-  "H"  = 72;
-  "I"  = 73;
-  "J"  = 74;
-  "K"  = 75;
-  "L"  = 76;
-  "M"  = 77;
-  "N"  = 78;
-  "O"  = 79;
-  "P"  = 80;
-  "Q"  = 81;
-  "R"  = 82;
-  "S"  = 83;
-  "T"  = 84;
-  "U"  = 85;
-  "V"  = 86;
-  "W"  = 87;
-  "X"  = 88;
-  "Y"  = 89;
-  "Z"  = 90;
-  "["  = 91;
-  "\\" = 92;
-  "]"  = 93;
-  "^"  = 94;
-  "_"  = 95;
-  "`"  = 96;
-  "a"  = 97;
-  "b"  = 98;
-  "c"  = 99;
-  "d"  = 100;
-  "e"  = 101;
-  "f"  = 102;
-  "g"  = 103;
-  "h"  = 104;
-  "i"  = 105;
-  "j"  = 106;
-  "k"  = 107;
-  "l"  = 108;
-  "m"  = 109;
-  "n"  = 110;
-  "o"  = 111;
-  "p"  = 112;
-  "q"  = 113;
-  "r"  = 114;
-  "s"  = 115;
-  "t"  = 116;
-  "u"  = 117;
-  "v"  = 118;
-  "w"  = 119;
-  "x"  = 120;
-  "y"  = 121;
-  "z"  = 122;
-  "{"  = 123;
-  "|"  = 124;
-  "}"  = 125;
-  "~"  = 126;
-}

lib/attrsets.nix

@@ -3,7 +3,7 @@
 
 let
   inherit (builtins) head tail length;
-  inherit (lib.trivial) flip id mergeAttrs pipe;
+  inherit (lib.trivial) id;
   inherit (lib.strings) concatStringsSep concatMapStringsSep escapeNixIdentifier sanitizeDerivationName;
   inherit (lib.lists) foldr foldl' concatMap concatLists elemAt all partition groupBy take foldl;
 in
@@ -77,25 +77,6 @@ rec {
     let errorMsg = "cannot find attribute `" + concatStringsSep "." attrPath + "'";
     in attrByPath attrPath (abort errorMsg);
 
-  /* Map each attribute in the given set and merge them into a new attribute set.
-
-     Type:
-       concatMapAttrs ::
-         (String -> a -> AttrSet)
-         -> AttrSet
-         -> AttrSet
-
-     Example:
-       concatMapAttrs
-         (name: value: {
-           ${name} = value;
-           ${name + value} = value;
-         })
-         { x = "a"; y = "b"; }
-       => { x = "a"; xa = "a"; y = "b"; yb = "b"; }
-  */
-  concatMapAttrs = f: flip pipe [ (mapAttrs f) attrValues (foldl' mergeAttrs { }) ];
-
 
   /* Update or set specific paths of an attribute set.
 
@@ -267,7 +248,7 @@ rec {
   /* Apply fold functions to values grouped by key.
 
      Example:
-       foldAttrs (item: acc: [item] ++ acc) [] [{ a = 2; } { a = 3; }]
+       foldAttrs (n: a: [n] ++ a) [] [{ a = 2; } { a = 3; }]
        => { a = [ 2 3 ]; }
   */
   foldAttrs = op: nul:
@@ -625,7 +606,7 @@ rec {
   getMan = getOutput "man";
 
   /* Pick the outputs of packages to place in buildInputs */
-  chooseDevOutputs = builtins.map getDev;
+  chooseDevOutputs = drvs: builtins.map getDev drvs;
 
   /* Make various Nix tools consider the contents of the resulting
      attribute set when looking for what to build, find, etc.
@@ -641,20 +622,6 @@ rec {
   dontRecurseIntoAttrs =
     attrs: attrs // { recurseForDerivations = false; };
 
-  /* `unionOfDisjoint x y` is equal to `x // y // z` where the
-     attrnames in `z` are the intersection of the attrnames in `x` and
-     `y`, and all values `assert` with an error message.  This
-      operator is commutative, unlike (//). */
-  unionOfDisjoint = x: y:
-    let
-      intersection = builtins.intersectAttrs x y;
-      collisions = lib.concatStringsSep " " (builtins.attrNames intersection);
-      mask = builtins.mapAttrs (name: value: builtins.throw
-        "unionOfDisjoint: collision on ${name}; complete list: ${collisions}")
-        intersection;
-    in
-      (x // y) // mask;
-
   /*** deprecated stuff ***/
 
   zipWithNames = zipAttrsWithNames;

lib/customisation.nix

@@ -38,15 +38,12 @@ rec {
       //
       (drv.passthru or {})
       //
-      # TODO(@Artturin): remove before release 23.05 and only have __spliced.
-      (lib.optionalAttrs (drv ? crossDrv && drv ? nativeDrv) {
-        crossDrv = overrideDerivation drv.crossDrv f;
-        nativeDrv = overrideDerivation drv.nativeDrv f;
-      })
-      //
-      lib.optionalAttrs (drv ? __spliced) {
-        __spliced = {} // (lib.mapAttrs (_: sDrv: overrideDerivation sDrv f) drv.__spliced);
-      });
+      (if (drv ? crossDrv && drv ? nativeDrv)
+       then {
+         crossDrv = overrideDerivation drv.crossDrv f;
+         nativeDrv = overrideDerivation drv.nativeDrv f;
+       }
+       else { }));
 
 
   /* `makeOverridable` takes a function from attribute set to attribute set and

lib/default.nix

@@ -23,7 +23,6 @@ let
 
     # packaging
     customisation = callLibs ./customisation.nix;
-    derivations = callLibs ./derivations.nix;
     maintainers = import ../maintainers/maintainer-list.nix;
     teams = callLibs ../maintainers/team-list.nix;
     meta = callLibs ./meta.nix;
@@ -37,7 +36,6 @@ let
 
     # constants
     licenses = callLibs ./licenses.nix;
-    sourceTypes = callLibs ./source-types.nix;
     systems = callLibs ./systems;
 
     # serialization
@@ -72,13 +70,13 @@ let
       info showWarnings nixpkgsVersion version isInOldestRelease
       mod compare splitByAndCompare
       functionArgs setFunctionArgs isFunction toFunction
-      toHexString toBaseDigits inPureEvalMode;
+      toHexString toBaseDigits;
     inherit (self.fixedPoints) fix fix' converge extends composeExtensions
       composeManyExtensions makeExtensible makeExtensibleWithCustomName;
     inherit (self.attrsets) attrByPath hasAttrByPath setAttrByPath
       getAttrFromPath attrVals attrValues getAttrs catAttrs filterAttrs
       filterAttrsRecursive foldAttrs collect nameValuePair mapAttrs
-      mapAttrs' mapAttrsToList concatMapAttrs mapAttrsRecursive mapAttrsRecursiveCond
+      mapAttrs' mapAttrsToList mapAttrsRecursive mapAttrsRecursiveCond
       genAttrs isDerivation toDerivation optionalAttrs
       zipAttrsWithNames zipAttrsWith zipAttrs recursiveUpdateUntil
       recursiveUpdate matchAttrs overrideExisting showAttrPath getOutput getBin
@@ -103,13 +101,12 @@ let
       getName getVersion
       nameFromURL enableFeature enableFeatureAs withFeature
       withFeatureAs fixedWidthString fixedWidthNumber isStorePath
-      toInt toIntBase10 readPathsFromFile fileContents;
+      toInt readPathsFromFile fileContents;
     inherit (self.stringsWithDeps) textClosureList textClosureMap
       noDepEntry fullDepEntry packEntry stringAfter;
     inherit (self.customisation) overrideDerivation makeOverridable
       callPackageWith callPackagesWith extendDerivation hydraJob
       makeScope makeScopeWithSplicing;
-    inherit (self.derivations) lazyDerivation;
     inherit (self.meta) addMetaAttrs dontDistribute setName updateName
       appendToName mapDerivationAttrset setPrio lowPrio lowPrioSet hiPrio
       hiPrioSet getLicenseFromSpdxId getExe;
@@ -133,9 +130,7 @@ let
       getValues getFiles
       optionAttrSetToDocList optionAttrSetToDocList'
       scrubOptionValue literalExpression literalExample literalDocBook
-      showOption showOptionWithDefLocs showFiles
-      unknownModule mkOption mkPackageOption
-      mdDoc literalMD;
+      showOption showFiles unknownModule mkOption mkPackageOption;
     inherit (self.types) isType setType defaultTypeMerge defaultFunctor
       isOptionType mkOptionType;
     inherit (self.asserts)

lib/deprecated.nix

@@ -157,36 +157,7 @@ rec {
                                 }
                       );
 
-  closePropagationSlow = list: (uniqList {inputList = (innerClosePropagation [] list);});
-
-  # This is an optimisation of lib.closePropagation which avoids the O(n^2) behavior
-  # Using a list of derivations, it generates the full closure of the propagatedXXXBuildInputs
-  # The ordering / sorting / comparison is done based on the `outPath`
-  # attribute of each derivation.
-  # On some benchmarks, it performs up to 15 times faster than lib.closePropagation.
-  # See https://github.com/NixOS/nixpkgs/pull/194391 for details.
-  closePropagationFast = list:
-    builtins.map (x: x.val) (builtins.genericClosure {
-      startSet = builtins.map (x: {
-        key = x.outPath;
-        val = x;
-      }) (builtins.filter (x: x != null) list);
-      operator = item:
-        if !builtins.isAttrs item.val then
-          [ ]
-        else
-          builtins.concatMap (x:
-            if x != null then [{
-              key = x.outPath;
-              val = x;
-            }] else
-              [ ]) ((item.val.propagatedBuildInputs or [ ])
-                ++ (item.val.propagatedNativeBuildInputs or [ ]));
-    });
-
-  closePropagation = if builtins ? genericClosure
-    then closePropagationFast
-    else closePropagationSlow;
+  closePropagation = list: (uniqList {inputList = (innerClosePropagation [] list);});
 
   # calls a function (f attr value ) for each record item. returns a list
   mapAttrsFlatten = f: r: map (attr: f attr r.${attr}) (attrNames r);

lib/derivations.nix

@@ -1,101 +0,0 @@
-{ lib }:
-
-let
-  inherit (lib) throwIfNot;
-in
-{
-  /*
-    Restrict a derivation to a predictable set of attribute names, so
-    that the returned attrset is not strict in the actual derivation,
-    saving a lot of computation when the derivation is non-trivial.
-
-    This is useful in situations where a derivation might only be used for its
-    passthru attributes, improving evaluation performance.
-
-    The returned attribute set is lazy in `derivation`. Specifically, this
-    means that the derivation will not be evaluated in at least the
-    situations below.
-
-    For illustration and/or testing, we define derivation such that its
-    evaluation is very noticable.
-
-        let derivation = throw "This won't be evaluated.";
-
-    In the following expressions, `derivation` will _not_ be evaluated:
-
-        (lazyDerivation { inherit derivation; }).type
-
-        attrNames (lazyDerivation { inherit derivation; })
-
-        (lazyDerivation { inherit derivation; } // { foo = true; }).foo
-
-        (lazyDerivation { inherit derivation; meta.foo = true; }).meta
-
-    In these expressions, it `derivation` _will_ be evaluated:
-
-        "${lazyDerivation { inherit derivation }}"
-
-        (lazyDerivation { inherit derivation }).outPath
-
-        (lazyDerivation { inherit derivation }).meta
-
-    And the following expressions are not valid, because the refer to
-    implementation details and/or attributes that may not be present on
-    some derivations:
-
-        (lazyDerivation { inherit derivation }).buildInputs
-
-        (lazyDerivation { inherit derivation }).passthru
-
-        (lazyDerivation { inherit derivation }).pythonPath
-
-  */
-  lazyDerivation =
-    args@{
-      # The derivation to be wrapped.
-      derivation
-    , # Optional meta attribute.
-      #
-      # While this function is primarily about derivations, it can improve
-      # the `meta` package attribute, which is usually specified through
-      # `mkDerivation`.
-      meta ? null
-    , # Optional extra values to add to the returned attrset.
-      #
-      # This can be used for adding package attributes, such as `tests`.
-      passthru ? { }
-    }:
-    let
-      # These checks are strict in `drv` and some `drv` attributes, but the
-      # attrset spine returned by lazyDerivation does not depend on it.
-      # Instead, the individual derivation attributes do depend on it.
-      checked =
-        throwIfNot (derivation.type or null == "derivation")
-          "lazySimpleDerivation: input must be a derivation."
-          throwIfNot
-          (derivation.outputs == [ "out" ])
-          # Supporting multiple outputs should be a matter of inheriting more attrs.
-          "The derivation ${derivation.name or "<unknown>"} has multiple outputs. This is not supported by lazySimpleDerivation yet. Support could be added, and be useful as long as the set of outputs is known in advance, without evaluating the actual derivation."
-          derivation;
-    in
-    {
-      # Hardcoded `type`
-      #
-      # `lazyDerivation` requires its `derivation` argument to be a derivation,
-      # so if it is not, that is a programming error by the caller and not
-      # something that `lazyDerivation` consumers should be able to correct
-      # for after the fact.
-      # So, to improve laziness, we assume correctness here and check it only
-      # when actual derivation values are accessed later.
-      type = "derivation";
-
-      # A fixed set of derivation values, so that `lazyDerivation` can return
-      # its attrset before evaluating `derivation`.
-      # This must only list attributes that are available on _all_ derivations.
-      inherit (checked) outputs out outPath outputName drvPath name system;
-
-      # The meta attribute can either be taken from the derivation, or if the
-      # `lazyDerivation` caller knew a shortcut, be taken from there.
-      meta = args.meta or checked.meta;
-    } // passthru;
-}