Release NixOS 23.11

(cherry picked from commit 04220ed676)

.editorconfig

@@ -17,10 +17,6 @@ end_of_line = unset
 insert_final_newline = unset
 trim_trailing_whitespace = unset
 
-# We want readFile .version to return the version without a newline.
-[.version]
-insert_final_newline = false
-
 # see https://nixos.org/nixpkgs/manual/#chap-conventions
 
 # Match json/lockfiles/markdown/nix/perl/python/ruby/shell/docbook files, set indent to spaces
@@ -94,9 +90,6 @@ insert_final_newline = unset
 indent_style = unset
 trim_trailing_whitespace = unset
 
-[pkgs/misc/documentation-highlighter/**]
-insert_final_newline = unset
-
 [pkgs/servers/dict/wordnet_structures.py]
 trim_trailing_whitespace = unset
 
@@ -112,7 +105,3 @@ charset = unset
 [lib/tests/*.plist]
 indent_style = tab
 insert_final_newline = unset
-
-[pkgs/kde/generated/**]
-insert_final_newline = unset
-end_of_line = unset

.git-blame-ignore-revs

@@ -96,24 +96,3 @@ fb0e5be84331188a69b3edd31679ca6576edb75a
 
 # nixos/*: add trivial defaultText for options with simple defaults
 25124556397ba17bfd70297000270de1e6523b0a
-
-# systemd: rewrite comments
-92dfeb7b3dab820ae307c56c216d175c69ee93cd
-
-# systemd: break too long lines of Nix code
-67643f8ec84bef1482204709073e417c9f07eb87
-
-# {pkgs/development/cuda-modules,pkgs/test/cuda,pkgs/top-level/cuda-packages.nix}: reformat all CUDA files with nixfmt-rfc-style 2023-03-01
-802a1b4d3338f24cbc4efd704616654456d75a94
-
-# postgresql: move packages.nix to ext/default.nix
-719034f6f6749d624faa28dff259309fc0e3e730
-
-# pkgs/os-specific/bsd: Reformat with nixfmt-rfc-style 2024-03-01
-3fe3b055adfc020e6a923c466b6bcd978a13069a
-
-# k3s: format with nixfmt-rfc-style
-6cfcd3c75428ede517bc6b15a353d704837a2830
-
-# python3Packages: format with nixfmt
-59b1aef59071cae6e87859dc65de973d2cc595c0

.github/CODEOWNERS

@@ -13,25 +13,20 @@
 
 # GitHub actions
 /.github/workflows @NixOS/Security @Mic92 @zowoq
+/.github/workflows/merge-staging @FRidh
 
 # EditorConfig
 /.editorconfig @Mic92 @zowoq
 
 # Libraries
 /lib                        @infinisil
-/lib/systems                @alyssais @ericson2314
+/lib/systems                @alyssais @ericson2314 @amjoseph-nixpkgs
 /lib/generators.nix         @infinisil @Profpatsch
 /lib/cli.nix                @infinisil @Profpatsch
 /lib/debug.nix              @infinisil @Profpatsch
 /lib/asserts.nix            @infinisil @Profpatsch
-/lib/path.*                 @infinisil
+/lib/path.*                 @infinisil @fricklerhandwerk
 /lib/fileset                @infinisil
-## Libraries / Module system
-/lib/modules.nix            @infinisil @roberth
-/lib/types.nix              @infinisil @roberth
-/lib/options.nix            @infinisil @roberth
-/lib/tests/modules.sh       @infinisil @roberth
-/lib/tests/modules          @infinisil @roberth
 
 # Nixpkgs Internals
 /default.nix                                     @Ericson2314
@@ -40,21 +35,20 @@
 /pkgs/top-level/stage.nix                        @Ericson2314
 /pkgs/top-level/splice.nix                       @Ericson2314
 /pkgs/top-level/release-cross.nix                @Ericson2314
-/pkgs/stdenv/generic                             @Ericson2314
-/pkgs/stdenv/generic/check-meta.nix              @Ericson2314
-/pkgs/stdenv/cross                               @Ericson2314
-/pkgs/build-support/cc-wrapper                   @Ericson2314
+/pkgs/stdenv/generic                             @Ericson2314 @amjoseph-nixpkgs
+/pkgs/stdenv/generic/check-meta.nix              @Ericson2314 @piegamesde
+/pkgs/stdenv/cross                               @Ericson2314 @amjoseph-nixpkgs
+/pkgs/build-support/cc-wrapper                   @Ericson2314 @amjoseph-nixpkgs
 /pkgs/build-support/bintools-wrapper             @Ericson2314
 /pkgs/build-support/setup-hooks                  @Ericson2314
 /pkgs/build-support/setup-hooks/auto-patchelf.sh @layus
 /pkgs/build-support/setup-hooks/auto-patchelf.py @layus
 /pkgs/pkgs-lib                                   @infinisil
 ## Format generators/serializers
-/pkgs/pkgs-lib/formats/libconfig                 @ckiee @h7x4
-/pkgs/pkgs-lib/formats/hocon                     @h7x4
+/pkgs/pkgs-lib/formats/libconfig                 @ckiee
 
 # pkgs/by-name
-/pkgs/test/check-by-name @infinisil
+/pkgs/test/nixpkgs-check-by-name @infinisil
 /pkgs/by-name/README.md @infinisil
 /pkgs/top-level/by-name-overlay.nix @infinisil
 /.github/workflows/check-by-name.yml @infinisil
@@ -66,10 +60,6 @@
 /doc/build-helpers/images/makediskimage.section.md  @raitobezarius
 /nixos/lib/make-disk-image.nix                 @raitobezarius
 
-# Nix, the package manager
-pkgs/tools/package-management/nix/                    @raitobezarius @ma27
-nixos/modules/installer/tools/nix-fallback-paths.nix  @raitobezarius @ma27
-
 # Nixpkgs documentation
 /maintainers/scripts/db-to-md.sh @jtojnar @ryantm
 /maintainers/scripts/doc @jtojnar @ryantm
@@ -77,8 +67,8 @@ nixos/modules/installer/tools/nix-fallback-paths.nix  @raitobezarius @ma27
 # Contributor documentation
 /CONTRIBUTING.md @infinisil
 /.github/PULL_REQUEST_TEMPLATE.md @infinisil
-/doc/contributing/ @infinisil
-/doc/contributing/contributing-to-documentation.chapter.md @jtojnar @infinisil
+/doc/contributing/ @fricklerhandwerk @infinisil
+/doc/contributing/contributing-to-documentation.chapter.md @jtojnar @fricklerhandwerk @infinisil
 /lib/README.md @infinisil
 /doc/README.md @infinisil
 /nixos/README.md @infinisil
@@ -109,9 +99,6 @@ nixos/modules/installer/tools/nix-fallback-paths.nix  @raitobezarius @ma27
 /nixos/lib/systemd-*.nix                    @NixOS/systemd
 /pkgs/os-specific/linux/systemd             @NixOS/systemd
 
-# Systemd-boot
-/nixos/modules/system/boot/loader/systemd-boot      @JulienMalka
-
 # Images and installer media
 /nixos/modules/installer/cd-dvd/            @samueldr
 /nixos/modules/installer/sd-card/           @samueldr
@@ -124,34 +111,41 @@ nixos/modules/installer/tools/nix-fallback-paths.nix  @raitobezarius @ma27
 /pkgs/common-updater/scripts/update-source-version    @jtojnar
 
 # Python-related code and docs
-/doc/languages-frameworks/python.section.md                 @mweinelt
-/pkgs/development/interpreters/python/hooks                 @jonringer
+/maintainers/scripts/update-python-libraries	              @FRidh
+/pkgs/development/interpreters/python                       @FRidh
+/doc/languages-frameworks/python.section.md                 @FRidh @mweinelt
+/pkgs/development/interpreters/python/hooks                 @FRidh @jonringer
 
 # Haskell
-/doc/languages-frameworks/haskell.section.md  @sternenseemann @maralorn @ncfavier
-/maintainers/scripts/haskell                  @sternenseemann @maralorn @ncfavier
-/pkgs/development/compilers/ghc               @sternenseemann @maralorn @ncfavier
-/pkgs/development/haskell-modules             @sternenseemann @maralorn @ncfavier
-/pkgs/test/haskell                            @sternenseemann @maralorn @ncfavier
-/pkgs/top-level/release-haskell.nix           @sternenseemann @maralorn @ncfavier
-/pkgs/top-level/haskell-packages.nix          @sternenseemann @maralorn @ncfavier
+/doc/languages-frameworks/haskell.section.md  @cdepillabout @sternenseemann @maralorn @ncfavier
+/maintainers/scripts/haskell                  @cdepillabout @sternenseemann @maralorn @ncfavier
+/pkgs/development/compilers/ghc               @cdepillabout @sternenseemann @maralorn @ncfavier
+/pkgs/development/haskell-modules             @cdepillabout @sternenseemann @maralorn @ncfavier
+/pkgs/test/haskell                            @cdepillabout @sternenseemann @maralorn @ncfavier
+/pkgs/top-level/release-haskell.nix           @cdepillabout @sternenseemann @maralorn @ncfavier
+/pkgs/top-level/haskell-packages.nix          @cdepillabout @sternenseemann @maralorn @ncfavier
 
 # Perl
-/pkgs/development/interpreters/perl @stigtsp @zakame @dasJ @marcusramberg
-/pkgs/top-level/perl-packages.nix   @stigtsp @zakame @dasJ @marcusramberg
-/pkgs/development/perl-modules      @stigtsp @zakame @dasJ @marcusramberg
+/pkgs/development/interpreters/perl @stigtsp @zakame @dasJ
+/pkgs/top-level/perl-packages.nix   @stigtsp @zakame @dasJ
+/pkgs/development/perl-modules      @stigtsp @zakame @dasJ
 
 # R
 /pkgs/applications/science/math/R   @jbedo
 /pkgs/development/r-modules         @jbedo
 
+# Ruby
+/pkgs/development/interpreters/ruby @marsam
+/pkgs/development/ruby-modules      @marsam
+
 # Rust
 /pkgs/development/compilers/rust @Mic92 @zowoq @winterqt @figsoda
 /pkgs/build-support/rust @zowoq @winterqt @figsoda
 /doc/languages-frameworks/rust.section.md @zowoq @winterqt @figsoda
 
 # C compilers
-/pkgs/development/compilers/gcc
+/pkgs/development/compilers/gcc @amjoseph-nixpkgs
+/pkgs/development/compilers/llvm @RaitoBezarius
 /pkgs/development/compilers/emscripten @raitobezarius
 /doc/languages-frameworks/emscripten.section.md @raitobezarius
 
@@ -163,8 +157,6 @@ nixos/modules/installer/tools/nix-fallback-paths.nix  @raitobezarius @ma27
 
 # Browsers
 /pkgs/applications/networking/browsers/firefox @mweinelt
-/pkgs/applications/networking/browsers/chromium @emilylange
-/nixos/tests/chromium.nix @emilylange
 
 # Certificate Authorities
 pkgs/data/misc/cacert/ @ajs124 @lukegb @mweinelt
@@ -177,21 +169,14 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 # Licenses
 /lib/licenses.nix @alyssais
 
-# Qt
-/pkgs/development/libraries/qt-5 @K900 @NickCao @SuperSandro2000 @ttuegel
-/pkgs/development/libraries/qt-6 @K900 @NickCao @SuperSandro2000 @ttuegel
-
-# KDE / Plasma 5
-/pkgs/applications/kde @K900 @NickCao @SuperSandro2000 @ttuegel
-/pkgs/desktops/plasma-5 @K900 @NickCao @SuperSandro2000 @ttuegel
-/pkgs/development/libraries/kde-frameworks @K900 @NickCao @SuperSandro2000 @ttuegel
-
-# KDE / Plasma 6
-/pkgs/kde @K900 @NickCao @SuperSandro2000 @ttuegel
-/maintainers/scripts/kde @K900 @NickCao @SuperSandro2000 @ttuegel
+# Qt / KDE
+/pkgs/applications/kde @ttuegel
+/pkgs/desktops/plasma-5 @ttuegel
+/pkgs/development/libraries/kde-frameworks @ttuegel
+/pkgs/development/libraries/qt-5 @ttuegel
 
 # PostgreSQL and related stuff
-/pkgs/servers/sql/postgresql @thoughtpolice
+/pkgs/servers/sql/postgresql @thoughtpolice @marsam
 /nixos/modules/services/databases/postgresql.xml @thoughtpolice
 /nixos/modules/services/databases/postgresql.nix @thoughtpolice
 /nixos/tests/postgresql.nix @thoughtpolice
@@ -219,18 +204,15 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
 /nixos/modules/services/networking/ntp @thoughtpolice
 
 # Network
-/pkgs/tools/networking/octodns @Janik-Haag
 /pkgs/tools/networking/kea/default.nix @mweinelt
 /pkgs/tools/networking/babeld/default.nix @mweinelt
 /nixos/modules/services/networking/babeld.nix @mweinelt
 /nixos/modules/services/networking/kea.nix @mweinelt
 /nixos/modules/services/networking/knot.nix @mweinelt
-nixos/modules/services/networking/networkmanager.nix @Janik-Haag
 /nixos/modules/services/monitoring/prometheus/exporters/kea.nix @mweinelt
 /nixos/tests/babeld.nix @mweinelt
 /nixos/tests/kea.nix @mweinelt
 /nixos/tests/knot.nix @mweinelt
-/nixos/tests/networking/* @Janik-Haag
 
 # Web servers
 /doc/packages/nginx.section.md @raitobezarius
@@ -268,13 +250,20 @@ nixos/modules/services/networking/networkmanager.nix @Janik-Haag
 /pkgs/applications/editors/vscode/extensions   @jonringer
 
 # PHP interpreter, packages, extensions, tests and documentation
-/doc/languages-frameworks/php.section.md          @aanderse @drupol @globin @ma27 @talyz
-/nixos/tests/php                                  @aanderse @drupol @globin @ma27 @talyz
-/pkgs/build-support/php/build-pecl.nix            @aanderse @drupol @globin @ma27 @talyz
-/pkgs/build-support/php                                     @drupol
-/pkgs/development/interpreters/php       @jtojnar @aanderse @drupol @globin @ma27 @talyz
-/pkgs/development/php-packages                    @aanderse @drupol @globin @ma27 @talyz
-/pkgs/top-level/php-packages.nix         @jtojnar @aanderse @drupol @globin @ma27 @talyz
+/doc/languages-frameworks/php.section.md          @aanderse @drupol @etu @globin @ma27 @talyz
+/nixos/tests/php                                  @aanderse @drupol @etu @globin @ma27 @talyz
+/pkgs/build-support/php/build-pecl.nix            @aanderse @drupol @etu @globin @ma27 @talyz
+/pkgs/build-support/php                                     @drupol @etu
+/pkgs/development/interpreters/php       @jtojnar @aanderse @drupol @etu @globin @ma27 @talyz
+/pkgs/development/php-packages                    @aanderse @drupol @etu @globin @ma27 @talyz
+/pkgs/top-level/php-packages.nix         @jtojnar @aanderse @drupol @etu @globin @ma27 @talyz
+
+# Podman, CRI-O modules and related
+/nixos/modules/virtualisation/containers.nix @adisbladis
+/nixos/modules/virtualisation/cri-o.nix      @adisbladis
+/nixos/modules/virtualisation/podman         @adisbladis
+/nixos/tests/cri-o.nix                       @adisbladis
+/nixos/tests/podman                          @adisbladis
 
 # Docker tools
 /pkgs/build-support/docker                   @roberth
@@ -291,7 +280,7 @@ nixos/modules/services/networking/networkmanager.nix @Janik-Haag
 
 # GNOME
 /pkgs/desktops/gnome                              @jtojnar
-/pkgs/desktops/gnome/extensions                   @jtojnar
+/pkgs/desktops/gnome/extensions       @piegamesde @jtojnar
 /pkgs/build-support/make-hardcode-gsettings-patch @jtojnar
 
 # Cinnamon
@@ -305,9 +294,16 @@ nixos/modules/services/networking/networkmanager.nix @Janik-Haag
 # terraform providers
 /pkgs/applications/networking/cluster/terraform-providers @zowoq
 
+# Matrix
+/pkgs/servers/heisenbridge                                 @piegamesde
+/pkgs/servers/matrix-conduit                               @piegamesde
+/nixos/modules/services/misc/heisenbridge.nix              @piegamesde
+/nixos/modules/services/misc/matrix-conduit.nix            @piegamesde
+/nixos/tests/matrix-conduit.nix                            @piegamesde
+
 # Forgejo
-nixos/modules/services/misc/forgejo.nix @adamcstephens @bendlas @emilylange
-pkgs/by-name/fo/forgejo/package.nix     @adamcstephens @bendlas @emilylange
+nixos/modules/services/misc/forgejo.nix      @bendlas @emilylange
+pkgs/applications/version-management/forgejo @bendlas @emilylange
 
 # Dotnet
 /pkgs/build-support/dotnet                  @IvarWithoutBones
@@ -320,46 +316,21 @@ pkgs/by-name/fo/forgejo/package.nix     @adamcstephens @bendlas @emilylange
 /pkgs/build-support/node/fetch-npm-deps         @lilyinstarlight @winterqt
 /doc/languages-frameworks/javascript.section.md @lilyinstarlight @winterqt
 
-# environment.noXlibs option aka NoX
-/nixos/modules/config/no-x-libs.nix  @SuperSandro2000
-
 # OCaml
 /pkgs/build-support/ocaml           @ulrikstrid
 /pkgs/development/compilers/ocaml   @ulrikstrid
 /pkgs/development/ocaml-modules     @ulrikstrid
 
 # ZFS
-pkgs/os-specific/linux/zfs/2_1.nix        @raitobezarius
-pkgs/os-specific/linux/zfs/generic.nix    @raitobezarius
+pkgs/os-specific/linux/zfs                @raitobezarius
+nixos/lib/make-single-disk-zfs-image.nix  @raitobezarius
+nixos/lib/make-multi-disk-zfs-image.nix   @raitobezarius
 nixos/modules/tasks/filesystems/zfs.nix   @raitobezarius
 nixos/tests/zfs.nix                       @raitobezarius
 
 # Zig
-/pkgs/development/compilers/zig @figsoda
-/doc/hooks/zig.section.md       @figsoda
-
-# Buildbot
-nixos/modules/services/continuous-integration/buildbot @Mic92 @zowoq
-nixos/tests/buildbot.nix                               @Mic92 @zowoq
-pkgs/development/tools/continuous-integration/buildbot @Mic92 @zowoq
-
-# Pretix
-pkgs/by-name/pr/pretix/ @mweinelt
-pkgs/by-name/pr/pretalx/ @mweinelt
-nixos/modules/services/web-apps/pretix.nix @mweinelt
-nixos/modules/services/web-apps/pretalx.nix @mweinelt
-nixos/tests/web-apps/pretix.nix @mweinelt
-nixos/tests/web-apps/pretalx.nix @mweinelt
-
-# incus/lxc/lxd
-nixos/maintainers/scripts/lxd/          @adamcstephens
-nixos/modules/virtualisation/incus.nix  @adamcstephens
-nixos/modules/virtualisation/lxc*       @adamcstephens
-nixos/modules/virtualisation/lxd*       @adamcstephens
-nixos/tests/incus/                      @adamcstephens
-nixos/tests/lxd/                        @adamcstephens
-pkgs/by-name/in/incus/                  @adamcstephens
-pkgs/by-name/lx/lxc*                    @adamcstephens
-pkgs/by-name/lx/lxd*                    @adamcstephens
-pkgs/os-specific/linux/lxc/             @adamcstephens
+/pkgs/development/compilers/zig @AndersonTorres @figsoda
+/doc/hooks/zig.section.md @AndersonTorres @figsoda
 
+# Linux Kernel
+pkgs/os-specific/linux/kernel/manual-config.nix   @amjoseph-nixpkgs

.github/ISSUE_TEMPLATE/bug_report.md

@@ -40,7 +40,7 @@ Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.
 output here
 ```
 
----
+### Priorities
 
 Add a :+1: [reaction] to [issues you find important].
 

.github/ISSUE_TEMPLATE/build_failure.md

@@ -38,7 +38,7 @@ Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.
 output here
 ```
 
----
+### Priorities
 
 Add a :+1: [reaction] to [issues you find important].
 

.github/ISSUE_TEMPLATE/missing_documentation.md

@@ -30,7 +30,7 @@ assignees: ''
 [open documentation issues]: https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+label%3A%229.needs%3A+documentation%22
 [open documentation pull requests]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+is%3Apr+label%3A%228.has%3A+documentation%22%2C%226.topic%3A+documentation%22
 
----
+### Priorities
 
 Add a :+1: [reaction] to [issues you find important].
 

.github/ISSUE_TEMPLATE/out_of_date_package_report.md

@@ -27,7 +27,7 @@ There's a high chance that you'll have the new version right away while helping
 
 Note for maintainers: Please tag this issue in your PR.
 
----
+**Priorities**
 
 Add a :+1: [reaction] to [issues you find important].
 

.github/ISSUE_TEMPLATE/packaging_request.md

@@ -18,7 +18,7 @@ assignees: ''
 * license: mit, bsd, gpl2+ , ...
 * platforms: unix, linux, darwin, ...
 
----
+**Priorities**
 
 Add a :+1: [reaction] to [issues you find important].
 

.github/ISSUE_TEMPLATE/unreproducible_package.md

@@ -86,7 +86,7 @@ nix log $(nix path-info --derivation nixpkgs#<package>)
 (please share the relevant fragment of the diffoscope output here, and any
 additional analysis you may have done)
 
----
+### Priorities
 
 Add a :+1: [reaction] to [issues you find important].
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -19,12 +19,12 @@ For new packages please briefly describe the package or provide a link to its ho
   - [ ] `sandbox = true`
 - [ ] Tested, as applicable:
   - [NixOS test(s)](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
-  - and/or [package tests](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests)
+  - and/or [package tests](https://nixos.org/manual/nixpkgs/unstable/#sec-package-tests)
   - or, for functions and "core" functionality, tests in [lib/tests](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or [pkgs/test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test)
   - 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/`)
-- [24.05 Release Notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2405.section.md) (or backporting [23.05](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2305.section.md) and [23.11](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2311.section.md) Release notes)
+- [23.11 Release Notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2311.section.md) (or backporting [23.05 Release notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2305.section.md))
   - [ ] (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
@@ -38,10 +38,10 @@ Reviewing helps to reduce the average time-to-merge for everyone.
 Thanks a lot if you do!
 
 List of open PRs: https://github.com/NixOS/nixpkgs/pulls
-Reviewing guidelines: https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#reviewing-contributions
+Reviewing guidelines: https://nixos.org/manual/nixpkgs/unstable/#chap-reviewing-contributions
 -->
 
----
+### Priorities
 
 Add a :+1: [reaction] to [pull requests you find important].
 

.github/labeler.yml

@@ -1,384 +1,209 @@
 "6.topic: agda":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/agda.section.md
-        - nixos/tests/agda.nix
-        - pkgs/build-support/agda/**/*
-        - pkgs/development/libraries/agda/**/*
-        - pkgs/top-level/agda-packages.nix
+  - doc/languages-frameworks/agda.section.md
+  - nixos/tests/agda.nix
+  - pkgs/build-support/agda/**/*
+  - pkgs/development/libraries/agda/**/*
+  - pkgs/top-level/agda-packages.nix
 
 "6.topic: cinnamon":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - pkgs/desktops/cinnamon/**/*
-        - nixos/modules/services/x11/desktop-managers/cinnamon.nix
-        - nixos/tests/cinnamon.nix
+  - pkgs/desktops/cinnamon/**/*
+  - nixos/modules/services/x11/desktop-managers/cinnamon.nix
+  - nixos/tests/cinnamon.nix
 
 "6.topic: emacs":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/modules/services/editors/emacs.nix
-        - nixos/modules/services/editors/emacs.xml
-        - nixos/tests/emacs-daemon.nix
-        - pkgs/applications/editors/emacs/elisp-packages/**/*
-        - pkgs/applications/editors/emacs/**/*
-        - pkgs/build-support/emacs/**/*
-        - pkgs/top-level/emacs-packages.nix
+  - nixos/modules/services/editors/emacs.nix
+  - nixos/modules/services/editors/emacs.xml
+  - nixos/tests/emacs-daemon.nix
+  - pkgs/applications/editors/emacs/elisp-packages/**/*
+  - pkgs/applications/editors/emacs/**/*
+  - pkgs/build-support/emacs/**/*
+  - pkgs/top-level/emacs-packages.nix
 
 "6.topic: Enlightenment DE":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/modules/services/x11/desktop-managers/enlightenment.nix
-        - pkgs/desktops/enlightenment/**/*
-        - pkgs/development/python-modules/python-efl/*
+  - nixos/modules/services/x11/desktop-managers/enlightenment.nix
+  - pkgs/desktops/enlightenment/**/*
+  - pkgs/development/python-modules/python-efl/*
 
 "6.topic: erlang":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/beam.section.md
-        - pkgs/development/beam-modules/**/*
-        - pkgs/development/interpreters/elixir/**/*
-        - pkgs/development/interpreters/erlang/**/*
-        - pkgs/development/tools/build-managers/rebar/**/*
-        - pkgs/development/tools/build-managers/rebar3/**/*
-        - pkgs/development/tools/erlang/**/*
-        - pkgs/top-level/beam-packages.nix
+  - doc/languages-frameworks/beam.section.md
+  - pkgs/development/beam-modules/**/*
+  - pkgs/development/interpreters/elixir/**/*
+  - pkgs/development/interpreters/erlang/**/*
+  - pkgs/development/tools/build-managers/rebar/**/*
+  - pkgs/development/tools/build-managers/rebar3/**/*
+  - pkgs/development/tools/erlang/**/*
+  - pkgs/top-level/beam-packages.nix
 
 "6.topic: fetch":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - pkgs/build-support/fetch*/**/*
+  - pkgs/build-support/fetch*/**/*
 
 "6.topic: flakes":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - '**/flake.nix'
-        - lib/systems/flake-systems.nix
-        - nixos/modules/config/nix-flakes.nix
+  - '**/flake.nix'
+  - lib/systems/flake-systems.nix
+  - nixos/modules/config/nix-flakes.nix
 
 "6.topic: GNOME":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/gnome.section.md
-        - nixos/modules/services/desktops/gnome/**/*
-        - nixos/modules/services/x11/desktop-managers/gnome.nix
-        - nixos/tests/gnome-xorg.nix
-        - nixos/tests/gnome.nix
-        - pkgs/desktops/gnome/**/*
+  - doc/languages-frameworks/gnome.section.md
+  - nixos/modules/services/desktops/gnome/**/*
+  - nixos/modules/services/x11/desktop-managers/gnome.nix
+  - nixos/tests/gnome-xorg.nix
+  - nixos/tests/gnome.nix
+  - pkgs/desktops/gnome/**/*
 
 "6.topic: golang":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/go.section.md
-        - pkgs/build-support/go/**/*
-        - pkgs/development/compilers/go/**/*
+  - doc/languages-frameworks/go.section.md
+  - pkgs/build-support/go/**/*
+  - pkgs/development/compilers/go/**/*
 
 "6.topic: haskell":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/haskell.section.md
-        - maintainers/scripts/haskell/**/*
-        - pkgs/development/compilers/ghc/**/*
-        - pkgs/development/haskell-modules/**/*
-        - pkgs/development/tools/haskell/**/*
-        - pkgs/test/haskell/**/*
-        - pkgs/top-level/haskell-packages.nix
-        - pkgs/top-level/release-haskell.nix
-
-"6.topic: julia":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/julia.section.md
-        - pkgs/development/compilers/julia/**/*
-        - pkgs/development/julia-modules/**/*
-
-"6.topic: jupyter":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - pkgs/development/python-modules/jupyter*/**/*
-        - pkgs/development/python-modules/mkdocs-jupyter/*
-        - nixos/modules/services/development/jupyter/**/*
-        - pkgs/applications/editors/jupyter-kernels/**/*
-        - pkgs/applications/editors/jupyter/**/*
-
-"6.topic: k3s":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/modules/services/cluster/k3s/**/*
-        - nixos/tests/k3s/**/*
-        - pkgs/applications/networking/cluster/k3s/**/*
+  - doc/languages-frameworks/haskell.section.md
+  - maintainers/scripts/haskell/**/*
+  - pkgs/development/compilers/ghc/**/*
+  - pkgs/development/haskell-modules/**/*
+  - pkgs/development/tools/haskell/**/*
+  - pkgs/test/haskell/**/*
+  - pkgs/top-level/haskell-packages.nix
+  - pkgs/top-level/release-haskell.nix
 
 "6.topic: kernel":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - pkgs/build-support/kernel/**/*
-        - pkgs/os-specific/linux/kernel/**/*
+  - pkgs/build-support/kernel/**/*
+  - pkgs/os-specific/linux/kernel/**/*
 
 "6.topic: lib":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - lib/**
+  - lib/**
 
 "6.topic: lua":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - pkgs/development/tools/misc/luarocks/*
-        - pkgs/development/interpreters/lua-5/**/*
-        - pkgs/development/interpreters/luajit/**/*
-        - pkgs/development/lua-modules/**/*
-        - pkgs/top-level/lua-packages.nix
+  - pkgs/development/interpreters/lua-5/**/*
+  - pkgs/development/interpreters/luajit/**/*
+  - pkgs/development/lua-modules/**/*
+  - pkgs/top-level/lua-packages.nix
 
 "6.topic: Lumina DE":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/modules/services/x11/desktop-managers/lumina.nix
-        - pkgs/desktops/lumina/**/*
+  - nixos/modules/services/x11/desktop-managers/lumina.nix
+  - pkgs/desktops/lumina/**/*
 
 "6.topic: LXQt":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/modules/services/x11/desktop-managers/lxqt.nix
-        - pkgs/desktops/lxqt/**/*
+  - nixos/modules/services/x11/desktop-managers/lxqt.nix
+  - pkgs/desktops/lxqt/**/*
 
 "6.topic: mate":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/modules/services/x11/desktop-managers/mate.nix
-        - nixos/tests/mate.nix
-        - pkgs/desktops/mate/**/*
+  - nixos/modules/services/x11/desktop-managers/mate.nix
+  - nixos/tests/mate.nix
+  - pkgs/desktops/mate/**/*
 
 "6.topic: module system":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - lib/modules.nix
-        - lib/types.nix
-        - lib/options.nix
-        - lib/tests/modules.sh
-        - lib/tests/modules/**
+  - lib/modules.nix
+  - lib/types.nix
+  - lib/options.nix
+  - lib/tests/modules.sh
+  - lib/tests/modules/**
 
 "6.topic: nixos":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/**/*
-        - pkgs/os-specific/linux/nixos-rebuild/**/*
+  - nixos/**/*
+  - pkgs/os-specific/linux/nixos-rebuild/**/*
 
 "6.topic: nim":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/nim.section.md
-        - pkgs/development/compilers/nim/*
-        - pkgs/development/nim-packages/**/*
-        - pkgs/top-level/nim-packages.nix
+  - doc/languages-frameworks/nim.section.md
+  - pkgs/development/compilers/nim/*
+  - pkgs/development/nim-packages/**/*
+  - pkgs/top-level/nim-packages.nix
 
 "6.topic: nodejs":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/javascript.section.md
-        - pkgs/build-support/node/**/*
-        - pkgs/development/node-packages/**/*
-        - pkgs/development/tools/yarn/*
-        - pkgs/development/tools/yarn2nix-moretea/**/*
-        - pkgs/development/web/nodejs/*
+  - doc/languages-frameworks/javascript.section.md
+  - pkgs/build-support/node/**/*
+  - pkgs/development/node-packages/**/*
+  - pkgs/development/tools/yarn/*
+  - pkgs/development/tools/yarn2nix-moretea/**/*
+  - pkgs/development/web/nodejs/*
 
 "6.topic: ocaml":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/ocaml.section.md
-        - pkgs/development/compilers/ocaml/**/*
-        - pkgs/development/compilers/reason/**/*
-        - pkgs/development/ocaml-modules/**/*
-        - pkgs/development/tools/ocaml/**/*
-        - pkgs/top-level/ocaml-packages.nix
+  - doc/languages-frameworks/ocaml.section.md
+  - pkgs/development/compilers/ocaml/**/*
+  - pkgs/development/compilers/reason/**/*
+  - pkgs/development/ocaml-modules/**/*
+  - pkgs/development/tools/ocaml/**/*
+  - pkgs/top-level/ocaml-packages.nix
 
 "6.topic: pantheon":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/modules/services/desktops/pantheon/**/*
-        - nixos/modules/services/x11/desktop-managers/pantheon.nix
-        - nixos/modules/services/x11/display-managers/lightdm-greeters/pantheon.nix
-        - nixos/tests/pantheon.nix
-        - pkgs/desktops/pantheon/**/*
-
-"6.topic: php":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/php.section.md
-        - pkgs/build-support/php/**/*
-        - pkgs/development/interpreters/php/*
-        - pkgs/development/php-packages/**/*
-        - pkgs/test/php/default.nix
-        - pkgs/top-level/php-packages.nix
+  - nixos/modules/services/desktops/pantheon/**/*
+  - nixos/modules/services/x11/desktop-managers/pantheon.nix
+  - nixos/modules/services/x11/display-managers/lightdm-greeters/pantheon.nix
+  - nixos/tests/pantheon.nix
+  - pkgs/desktops/pantheon/**/*
 
 "6.topic: policy discussion":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - .github/**/*
+  - .github/**/*
 
 "6.topic: printing":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/modules/services/printing/cupsd.nix
-        - pkgs/misc/cups/**/*
+  - nixos/modules/services/printing/cupsd.nix
+  - pkgs/misc/cups/**/*
 
 "6.topic: python":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/python.section.md
-        - pkgs/development/interpreters/python/**/*
-        - pkgs/development/python-modules/**/*
-        - pkgs/top-level/python-packages.nix
+  - doc/languages-frameworks/python.section.md
+  - pkgs/development/interpreters/python/**/*
+  - pkgs/development/python-modules/**/*
+  - pkgs/top-level/python-packages.nix
 
 "6.topic: qt/kde":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/qt.section.md
-        - nixos/modules/services/x11/desktop-managers/plasma5.nix
-        - nixos/tests/plasma5.nix
-        - pkgs/applications/kde/**/*
-        - pkgs/desktops/plasma-5/**/*
-        - pkgs/development/libraries/kde-frameworks/**/*
-        - pkgs/development/libraries/qt-5/**/*
+  - doc/languages-frameworks/qt.section.md
+  - nixos/modules/services/x11/desktop-managers/plasma5.nix
+  - nixos/tests/plasma5.nix
+  - pkgs/applications/kde/**/*
+  - pkgs/desktops/plasma-5/**/*
+  - pkgs/development/libraries/kde-frameworks/**/*
+  - pkgs/development/libraries/qt-5/**/*
 
 "6.topic: ruby":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/ruby.section.md
-        - pkgs/development/interpreters/ruby/**/*
-        - pkgs/development/ruby-modules/**/*
+  - doc/languages-frameworks/ruby.section.md
+  - pkgs/development/interpreters/ruby/**/*
+  - pkgs/development/ruby-modules/**/*
 
 "6.topic: rust":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/rust.section.md
-        - pkgs/build-support/rust/**/*
-        - pkgs/development/compilers/rust/**/*
+  - doc/languages-frameworks/rust.section.md
+  - pkgs/build-support/rust/**/*
+  - pkgs/development/compilers/rust/**/*
 
 "6.topic: stdenv":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - pkgs/stdenv/**/*
+  - pkgs/stdenv/**/*
 
 "6.topic: steam":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - pkgs/games/steam/**/*
+  - pkgs/games/steam/**/*
 
 "6.topic: systemd":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - pkgs/os-specific/linux/systemd/**/*
-        - nixos/modules/system/boot/systemd*/**/*
+  - pkgs/os-specific/linux/systemd/**/*
+  - nixos/modules/system/boot/systemd*/**/*
 
 "6.topic: TeX":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/texlive.section.md
-        - pkgs/test/texlive/**
-        - pkgs/tools/typesetting/tex/**/*
-
-"6.topic: testing":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        # NOTE: Let's keep the scope limited to test frameworks that are
-        #       *developed in this repo*;
-        #       - not individual tests
-        #       - not packages for test frameworks
-        - nixos/lib/testing/**
-        - nixos/lib/test-driver/**
-        - nixos/tests/nixos-test-driver/**
-        - nixos/lib/testing-python.nix      # legacy
-        - nixos/tests/make-test-python.nix  # legacy
-        # lib/debug.nix has a test framework (runTests) but it's not the main focus
+  - doc/languages-frameworks/texlive.section.md
+  - pkgs/test/texlive/**
+  - pkgs/tools/typesetting/tex/**/*
 
 "6.topic: vim":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/languages-frameworks/vim.section.md
-        - pkgs/applications/editors/vim/**/*
-        - pkgs/applications/editors/vim/plugins/**/*
-        - nixos/modules/programs/neovim.nix
-        - pkgs/applications/editors/neovim/**/*
+  - doc/languages-frameworks/vim.section.md
+  - pkgs/applications/editors/vim/**/*
+  - pkgs/applications/editors/vim/plugins/**/*
+  - nixos/modules/programs/neovim.nix
+  - pkgs/applications/editors/neovim/**/*
 
 "6.topic: vscode":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - pkgs/applications/editors/vscode/**/*
+  - pkgs/applications/editors/vscode/**/*
 
 "6.topic: xfce":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/doc/manual/configuration/xfce.xml
-        - nixos/modules/services/x11/desktop-managers/xfce.nix
-        - nixos/tests/xfce.nix
-        - pkgs/desktops/xfce/**/*
+  - nixos/doc/manual/configuration/xfce.xml
+  - nixos/modules/services/x11/desktop-managers/xfce.nix
+  - nixos/tests/xfce.nix
+  - pkgs/desktops/xfce/**/*
 
 "6.topic: zig":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - pkgs/development/compilers/zig/**/*
-        - doc/hooks/zig.section.md
+  - pkgs/development/compilers/zig/**/*
+  - doc/hooks/zig.section.md
 
 "8.has: changelog":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/doc/manual/release-notes/**/*
+  - nixos/doc/manual/release-notes/**/*
 
 "8.has: documentation":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - doc/**/*
-        - nixos/doc/**/*
+  - doc/**/*
+  - nixos/doc/**/*
 
 "8.has: module (update)":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - nixos/modules/**/*
-"8.has: maintainer-list (update)":
-  - any:
-    - changed-files:
-      - any-glob-to-any-file:
-        - maintainers/maintainer-list.nix
+  - nixos/modules/**/*

.github/workflows/backport.yml

@@ -20,11 +20,11 @@ jobs:
     if: github.repository_owner == 'NixOS' && github.event.pull_request.merged == true && (github.event_name != 'labeled' || startsWith('backport', github.event.label.name))
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
+      - uses: actions/checkout@v4
         with:
           ref: ${{ github.event.pull_request.head.sha }}
       - name: Create backport PRs
-        uses: korthout/backport-action@ef20d86abccbac3ee3a73cb2efbdc06344c390e5 # v2.5.0
+        uses: korthout/backport-action@v2.1.1
         with:
           # Config README: https://github.com/korthout/backport-action#backport-action
           copy_labels_pattern: 'severity:\ssecurity'

.github/workflows/basic-eval.yml

@@ -18,12 +18,12 @@ jobs:
     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@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
-    - uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
-    - uses: cachix/cachix-action@18cf96c7c98e048e10a83abd92116114cd8504be # v14
+    - uses: actions/checkout@v4
+    - uses: cachix/install-nix-action@v23
+    - 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 }}'
     # explicit list of supportedSystems is needed until aarch64-darwin becomes part of the trunk jobset
-    - run: nix-build pkgs/top-level/release.nix -A release-checks --arg supportedSystems '[ "aarch64-darwin" "aarch64-linux" "x86_64-linux" "x86_64-darwin"  ]'
+    - run: nix-build pkgs/top-level/release.nix -A tarball.nixpkgs-basic-release-checks --arg supportedSystems '[ "aarch64-darwin" "aarch64-linux" "x86_64-linux" "x86_64-darwin"  ]'

.github/workflows/check-by-name.yml

@@ -1,52 +1,28 @@
 # Checks pkgs/by-name (see pkgs/by-name/README.md)
-# using the nixpkgs-check-by-name tool (see https://github.com/NixOS/nixpkgs-check-by-name)
-#
-# When you make changes to this workflow, also update pkgs/test/check-by-name/run-local.sh adequately
+# using the nixpkgs-check-by-name tool (see pkgs/test/nixpkgs-check-by-name)
 name: Check pkgs/by-name
 
+# The pre-built tool is fetched from a channel,
+# making it work predictable on all PRs.
 on:
   # Using pull_request_target instead of pull_request avoids having to approve first time contributors
-  pull_request_target:
-    # This workflow depends on the base branch of the PR,
-    # but changing the base branch is not included in the default trigger events,
-    # which would be `opened`, `synchronize` or `reopened`.
-    # Instead it causes an `edited` event, so we need to add it explicitly here
-    # While `edited` is also triggered when the PR title/body is changed,
-    # this PR action is fairly quick, and PR's don't get edited that often,
-    # so it shouldn't be a problem
-    types: [opened, synchronize, reopened, edited]
+  pull_request_target
 
+# The tool doesn't need any permissions, it only outputs success or not based on the checkout
 permissions: {}
 
-# Create a check-by-name concurrency group based on the pull request number. if
-# an event triggers a run on the same PR while a previous run is still in
-# progress, the previous run will be canceled and the new one will start.
-concurrency:
-  group: check-by-name-${{ github.event.pull_request.number }}
-  cancel-in-progress: true
-
 jobs:
   check:
-    # This needs to be x86_64-linux, because we depend on the tooling being pre-built in the GitHub releases
+    # This is x86_64-linux, for which the tool is always prebuilt on the nixos-* channels,
+    # as specified in nixos/release-combined.nix
     runs-on: ubuntu-latest
-    # This should take 1 minute at most, but let's be generous.
-    # The default of 6 hours is definitely too long
-    timeout-minutes: 10
     steps:
-      # This step has to be in this file,
-      # because it's needed to determine which revision of the repository to fetch,
-      # and we can only use other files from the repository once it's fetched.
       - name: Resolving the merge commit
         env:
           GH_TOKEN: ${{ github.token }}
         run: |
           # This checks for mergeability of a pull request as recommended in
           # https://docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-your-git-database?apiVersion=2022-11-28#checking-mergeability-of-pull-requests
-
-          # Retry the API query this many times
-          retryCount=5
-          # Start with 5 seconds, but double every retry
-          retryInterval=5
           while true; do
             echo "Checking whether the pull request can be merged"
             prInfo=$(gh api \
@@ -57,19 +33,10 @@ jobs:
             mergedSha=$(jq -r .merge_commit_sha <<< "$prInfo")
 
             if [[ "$mergeable" == "null" ]]; then
-              if (( retryCount == 0 )); then
-                echo "Not retrying anymore, probably GitHub is having internal issues"
-                exit 1
-              else
-                (( retryCount -= 1 )) || true
-
-                # null indicates that GitHub is still computing whether it's mergeable
-                # Wait a couple seconds before trying again
-                echo "GitHub is still computing whether this PR can be merged, waiting $retryInterval seconds before trying again ($retryCount retries left)"
-                sleep "$retryInterval"
-
-                (( retryInterval *= 2 )) || true
-              fi
+              # null indicates that GitHub is still computing whether it's mergeable
+              # Wait a couple seconds before trying again
+              echo "GitHub is still computing whether this PR can be merged, waiting 5 seconds before trying again"
+              sleep 5
             else
               break
             fi
@@ -77,47 +44,136 @@ jobs:
 
           if [[ "$mergeable" == "true" ]]; then
             echo "The PR can be merged, checking the merge commit $mergedSha"
-            echo "mergedSha=$mergedSha" >> "$GITHUB_ENV"
           else
-            echo "The PR cannot be merged, it has a merge conflict, skipping the rest.."
+            echo "The PR cannot be merged, it has a merge conflict"
+            exit 1
           fi
-      - uses: actions/checkout@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
-        if: env.mergedSha
+          echo "mergedSha=$mergedSha" >> "$GITHUB_ENV"
+      - uses: actions/checkout@v4
         with:
           # pull_request_target checks out the base branch by default
           ref: ${{ env.mergedSha }}
           # Fetches the merge commit and its parents
           fetch-depth: 2
-      - name: Checking out base branch
-        if: env.mergedSha
+      - name: Determining PR git hashes
         run: |
-          base=$(mktemp -d)
-          git worktree add "$base" "$(git rev-parse HEAD^1)"
-          echo "base=$base" >> "$GITHUB_ENV"
-      - uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
-        if: env.mergedSha
-      - name: Fetching the pinned tool
-        if: env.mergedSha
-        # Update the pinned version using pkgs/test/check-by-name/update-pinned-tool.sh
+          # For pull_request_target this is the same as $GITHUB_SHA
+          echo "baseSha=$(git rev-parse HEAD^1)" >> "$GITHUB_ENV"
+
+          echo "headSha=$(git rev-parse HEAD^2)" >> "$GITHUB_ENV"
+      - uses: cachix/install-nix-action@v23
+      - name: Determining channel to use for dependencies
         run: |
-          # The pinned version of the tooling to use
-          toolVersion=$(<pkgs/test/check-by-name/pinned-version.txt)
-          # Fetch the x86_64-linux-specific release artifact containing the Gzipped NAR of the pre-built tool
-          toolPath=$(curl -sSfL https://github.com/NixOS/nixpkgs-check-by-name/releases/download/"$toolVersion"/x86_64-linux.nar.gz \
-            | gzip -cd | nix-store --import | tail -1)
-          # Adds a result symlink as a GC root
-          nix-store --realise "$toolPath" --add-root result
-      - name: Running nixpkgs-check-by-name
-        if: env.mergedSha
-        env:
-          # Force terminal colors to be enabled. The library that
-          # nixpkgs-check-by-name uses respects: https://bixense.com/clicolors/
-          CLICOLOR_FORCE: 1
-        run: |
-          if result/bin/nixpkgs-check-by-name --base "$base" .; then
-            exit 0
+          echo "Determining the preferred channel to use for PR base branch $GITHUB_BASE_REF"
+          if [[ "$GITHUB_BASE_REF" =~ ^(release|staging|staging-next)-([0-9][0-9]\.[0-9][0-9])$ ]]; then
+              # Use the release channel for all PRs to release-XX.YY, staging-XX.YY and staging-next-XX.YY
+              channel=nixos-${BASH_REMATCH[2]}
+              echo "PR is for a release branch, preferred channel is $channel"
           else
-            exitCode=$?
-            echo "To run locally: ./maintainers/scripts/check-by-name.sh $GITHUB_BASE_REF https://github.com/$GITHUB_REPOSITORY.git"
-            exit "$exitCode"
+              # Use the nixos-unstable channel for all other PRs
+              channel=nixos-unstable
+              echo "PR is for a non-release branch, preferred channel is $channel"
           fi
+          # Check that the channel exists. It doesn't exist for fresh release branches
+          if ! curl -fSs "https://channels.nixos.org/$channel"; then
+            # Fall back to nixos-unstable, makes sense for fresh release branches
+            echo "Preferred channel $channel could not be fetched, falling back to nixos-unstable"
+            channel=nixos-unstable
+          fi
+          echo "channel=$channel" >> "$GITHUB_ENV"
+      - name: Fetching latest version of channel
+        run: |
+          echo "Fetching latest version of channel $channel"
+          # This is probably the easiest way to get Nix to output the path to a downloaded channel!
+          nixpkgs=$(nix-instantiate --find-file nixpkgs -I nixpkgs=channel:"$channel")
+          # This file only exists in channels
+          rev=$(<"$nixpkgs"/.git-revision)
+          echo "Channel $channel is at revision $rev"
+          echo "nixpkgs=$nixpkgs" >> "$GITHUB_ENV"
+          echo "rev=$rev" >> "$GITHUB_ENV"
+      - name: Fetching pre-built nixpkgs-check-by-name from the channel
+        run: |
+          echo "Fetching pre-built nixpkgs-check-by-name from channel $channel at revision $rev"
+          # Passing --max-jobs 0 makes sure that we won't build anything
+          nix-build "$nixpkgs" -A tests.nixpkgs-check-by-name --max-jobs 0
+      - name: Running nixpkgs-check-by-name
+        run: |
+          echo "Checking whether the check succeeds on the base branch $GITHUB_BASE_REF"
+          git checkout -q "$baseSha"
+          if baseOutput=$(result/bin/nixpkgs-check-by-name . 2>&1); then
+            baseSuccess=1
+          else
+            baseSuccess=
+          fi
+          printf "%s\n" "$baseOutput"
+
+          echo "Checking whether the check would succeed after merging this pull request"
+          git checkout -q "$mergedSha"
+          if mergedOutput=$(result/bin/nixpkgs-check-by-name . 2>&1); then
+            mergedSuccess=1
+            exitCode=0
+          else
+            mergedSuccess=
+            exitCode=1
+          fi
+          printf "%s\n" "$mergedOutput"
+
+          resultToEmoji() {
+            if [[ -n "$1" ]]; then
+              echo ":heavy_check_mark:"
+            else
+              echo ":x:"
+            fi
+          }
+
+          # Print a markdown summary in GitHub actions
+          {
+            echo "| Nixpkgs version | Check result |"
+            echo "| --- | --- |"
+            echo "| Latest base commit | $(resultToEmoji "$baseSuccess") |"
+            echo "| After merging this PR | $(resultToEmoji "$mergedSuccess") |"
+            echo ""
+
+            if [[ -n "$baseSuccess" ]]; then
+              if [[ -n "$mergedSuccess" ]]; then
+                echo "The check succeeds on both the base branch and after merging this PR"
+              else
+                echo "The check succeeds on the base branch, but would fail after merging this PR:"
+                echo "\`\`\`"
+                echo "$mergedOutput"
+                echo "\`\`\`"
+                echo ""
+              fi
+            else
+              if [[ -n "$mergedSuccess" ]]; then
+                echo "The check fails on the base branch, but this PR fixes it, nicely done!"
+              else
+                echo "The check fails on both the base branch and after merging this PR, unknown if only this PRs changes would satisfy the check, the base branch needs to be fixed first."
+                echo ""
+                echo "Failure on the base branch:"
+                echo "\`\`\`"
+                echo "$baseOutput"
+                echo "\`\`\`"
+                echo ""
+                echo "Failure after merging this PR:"
+                echo "\`\`\`"
+                echo "$mergedOutput"
+                echo "\`\`\`"
+                echo ""
+              fi
+            fi
+
+            echo "### Details"
+            echo "- nixpkgs-check-by-name tool:"
+            echo "  - Channel: $channel"
+            echo "  - Nixpkgs commit: [$rev](https://github.com/${GITHUB_REPOSITORY}/commit/$rev)"
+            echo "  - Store path: \`$(realpath result)\`"
+            echo "- Tested Nixpkgs:"
+            echo "  - Base branch: $GITHUB_BASE_REF"
+            echo "  - Latest base branch commit: [$baseSha](https://github.com/${GITHUB_REPOSITORY}/commit/$baseSha)"
+            echo "  - Latest PR commit: [$headSha](https://github.com/${GITHUB_REPOSITORY}/commit/$headSha)"
+            echo "  - Merge commit: [$mergedSha](https://github.com/${GITHUB_REPOSITORY}/commit/$mergedSha)"
+          } >> "$GITHUB_STEP_SUMMARY"
+
+          exit "$exitCode"
+

.github/workflows/check-cherry-picks.yml

@@ -1,24 +0,0 @@
-name: "Check cherry-picks"
-on:
-  pull_request_target:
-    branches:
-     - 'release-**'
-     - 'staging-**'
-
-permissions: {}
-
-jobs:
-  check:
-    runs-on: ubuntu-latest
-    if: github.repository_owner == 'NixOS'
-    steps:
-    - uses: actions/checkout@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
-      with:
-        fetch-depth: 0
-        filter: blob:none
-    - name: Check cherry-picks
-      env:
-        BASE_SHA: ${{ github.event.pull_request.base.sha }}
-        HEAD_SHA: ${{ github.event.pull_request.head.sha }}
-      run: |
-        ./maintainers/scripts/check-cherry-picks.sh "$BASE_SHA" "$HEAD_SHA"

.github/workflows/check-maintainers-sorted.yaml

@@ -12,15 +12,11 @@ jobs:
     runs-on: ubuntu-latest
     if: github.repository_owner == 'NixOS'
     steps:
-      - uses: actions/checkout@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
+      - uses: actions/checkout@v4
         with:
           # pull_request_target checks out the base branch by default
           ref: refs/pull/${{ github.event.pull_request.number }}/merge
-          # Only these directories to perform the check
-          sparse-checkout: |
-            lib
-            maintainers
-      - uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
+      - uses: cachix/install-nix-action@v23
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true

.github/workflows/check-nix-format.yml

@@ -1,62 +0,0 @@
-# This file was copied mostly from check-maintainers-sorted.yaml.
-# NOTE: Formatting with the RFC-style nixfmt command is not yet stable. See
-# https://github.com/NixOS/rfcs/pull/166.
-# Because of this, this action is not yet enabled for all files -- only for
-# those who have opted in.
-name: Check that Nix files are formatted
-
-on:
-  pull_request_target:
-permissions:
-  contents: read
-
-jobs:
-  nixos:
-    runs-on: ubuntu-latest
-    if: github.repository_owner == 'NixOS'
-    steps:
-      - uses: actions/checkout@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
-        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@8887e596b4ee1134dae06b98d573bd674693f47c # v26
-        with:
-          # explicitly enable sandbox
-          extra_nix_config: sandbox = true
-          # fix a commit from nixpkgs-unstable to avoid e.g. building nixfmt
-          # from staging
-          nix_path: nixpkgs=https://github.com/NixOS/nixpkgs/archive/4b455dc2048f73a79eb3713f342369ff58f93e0b.tar.gz
-      - name: Install nixfmt
-        run: "nix-env -f '<nixpkgs>' -iAP nixfmt-rfc-style"
-      - name: Check that Nix files are formatted according to the RFC style
-        # Each environment variable beginning with NIX_FMT_PATHS_ is a list of
-        # paths to check with nixfmt.
-        env:
-          NIX_FMT_PATHS_BSD: pkgs/os-specific/bsd
-          NIX_FMT_PATHS_MPVSCRIPTS: pkgs/applications/video/mpv/scripts
-          # Format paths related to the Nixpkgs CUDA ecosystem.
-          NIX_FMT_PATHS_CUDA: |
-            pkgs/development/cuda-modules
-            pkgs/test/cuda
-            pkgs/top-level/cuda-packages.nix
-          NIX_FMT_PATHS_K3S: |
-            nixos/modules/services/cluster/k3s
-            nixos/tests/k3s
-            pkgs/applications/networking/cluster/k3s
-          NIX_FMT_PATHS_VSCODE_EXTS: pkgs/applications/editors/vscode/extensions
-          NIX_FMT_PATHS_PHP_PACKAGES: pkgs/development/php-packages
-          NIX_FMT_PATHS_BUILD_SUPPORT_PHP: pkgs/build-support/php
-        # Iterate over all environment variables beginning with NIX_FMT_PATHS_.
-        run: |
-          for env_var in "${!NIX_FMT_PATHS_@}"; do
-            readarray -t paths <<< "${!env_var}"
-            if [[ "${paths[*]}" == "" ]]; then
-              echo "Error: $env_var is empty."
-              exit 1
-            fi
-            echo "Checking paths: ${paths[@]}"
-            if ! nixfmt --check "${paths[@]}"; then
-              echo "Error: nixfmt failed."
-              exit 1
-            fi
-          done

.github/workflows/editorconfig.yml

@@ -24,11 +24,11 @@ jobs:
     - name: print list of changed files
       run: |
         cat "$HOME/changed_files"
-    - uses: actions/checkout@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
+    - uses: actions/checkout@v4
       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@8887e596b4ee1134dae06b98d573bd674693f47c # v26
+    - uses: cachix/install-nix-action@v23
       with:
         # nixpkgs commit is pinned so that it doesn't break
         # editorconfig-checker 2.4.0

.github/workflows/labels.yml

@@ -18,7 +18,7 @@ jobs:
     runs-on: ubuntu-latest
     if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
     steps:
-    - uses: actions/labeler@8558fd74291d67161a8a78ce36a881fa63b766a9 # v5.0.0
+    - uses: actions/labeler@v4
       with:
         repo-token: ${{ secrets.GITHUB_TOKEN }}
         sync-labels: true

.github/workflows/manual-nixos.yml

@@ -14,18 +14,18 @@ jobs:
     runs-on: ubuntu-latest
     if: github.repository_owner == 'NixOS'
     steps:
-      - uses: actions/checkout@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
+      - uses: actions/checkout@v4
         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@8887e596b4ee1134dae06b98d573bd674693f47c # v26
+      - uses: cachix/install-nix-action@v23
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true
-      - uses: cachix/cachix-action@18cf96c7c98e048e10a83abd92116114cd8504be # v14
+      - 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
-          authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
+          signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
       - name: Building NixOS manual
         run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true nixos/release.nix -A manual.x86_64-linux

.github/workflows/manual-nixpkgs.yml

@@ -9,25 +9,24 @@ on:
     paths:
       - 'doc/**'
       - 'lib/**'
-      - 'pkgs/tools/nix/nixdoc/**'
 
 jobs:
   nixpkgs:
     runs-on: ubuntu-latest
     if: github.repository_owner == 'NixOS'
     steps:
-      - uses: actions/checkout@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
+      - uses: actions/checkout@v4
         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@8887e596b4ee1134dae06b98d573bd674693f47c # v26
+      - uses: cachix/install-nix-action@v23
         with:
           # explicitly enable sandbox
           extra_nix_config: sandbox = true
-      - uses: cachix/cachix-action@18cf96c7c98e048e10a83abd92116114cd8504be # v14
+      - 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
-          authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
+          signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
       - name: Building Nixpkgs manual
-        run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true pkgs/top-level/release.nix -A manual -A manual.tests
+        run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true pkgs/top-level/release.nix -A manual

.github/workflows/nix-parse.yml

@@ -1,42 +0,0 @@
-name: "Check whether nix files are parseable"
-
-permissions: read-all
-
-on:
-  # avoids approving first time contributors
-  pull_request_target:
-    branches-ignore:
-      - 'release-**'
-
-jobs:
-  tests:
-    runs-on: ubuntu-latest
-    if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip treewide]')"
-    steps:
-    - name: Get list of changed files from PR
-      env:
-        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      run: |
-        gh api \
-          repos/NixOS/nixpkgs/pulls/${{github.event.number}}/files --paginate \
-          | jq --raw-output '.[] | select(.status != "removed" and (.filename | endswith(".nix"))) | .filename' \
-          > "$HOME/changed_files"
-        if [[ -s "$HOME/changed_files" ]]; then
-          echo "CHANGED_FILES=$HOME/changed_files" > "$GITHUB_ENV"
-        fi
-    - uses: actions/checkout@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
-      with:
-        # pull_request_target checks out the base branch by default
-        ref: refs/pull/${{ github.event.pull_request.number }}/merge
-      if: ${{ env.CHANGED_FILES && env.CHANGED_FILES != '' }}
-    - uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
-      with:
-        nix_path: nixpkgs=channel:nixpkgs-unstable
-    - name: Parse all changed or added nix files
-      run: |
-        ret=0
-        while IFS= read -r file; do
-          out="$(nix-instantiate --parse "$file")" || { echo "$out" && ret=1; }
-        done < "$HOME/changed_files"
-        exit "$ret"
-      if: ${{ env.CHANGED_FILES && env.CHANGED_FILES != '' }}

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

@@ -13,7 +13,6 @@ on:
     # * is a special character in YAML so you have to quote this string
     # Merge every 24 hours
     - cron:  '0 0 * * *'
-  workflow_dispatch:
 
 permissions:
   contents: read
@@ -35,16 +34,16 @@ jobs:
         pairs:
           - from: master
             into: haskell-updates
-          - from: release-23.11
-            into: staging-next-23.11
-          - from: staging-next-23.11
-            into: staging-23.11
+          - from: release-23.05
+            into: staging-next-23.05
+          - from: staging-next-23.05
+            into: staging-23.05
     name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
     steps:
-      - uses: actions/checkout@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
+      - uses: actions/checkout@v4
 
       - name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
-        uses: devmasx/merge-branch@854d3ac71ed1e9deb668e0074781b81fdd6e771f # 1.4.0
+        uses: devmasx/merge-branch@1.4.0
         with:
           type: now
           from_branch: ${{ matrix.pairs.from }}
@@ -52,7 +51,7 @@ jobs:
           github_token: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Comment on failure
-        uses: peter-evans/create-or-update-comment@71345be0265236311c031f5c7866368bd1eff043 # v4.0.0
+        uses: peter-evans/create-or-update-comment@v3
         if: ${{ failure() }}
         with:
           issue-number: 105153

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

@@ -13,7 +13,6 @@ on:
     # * is a special character in YAML so you have to quote this string
     # Merge every 6 hours
     - cron:  '0 */6 * * *'
-  workflow_dispatch:
 
 permissions:
   contents: read
@@ -39,10 +38,10 @@ jobs:
             into: staging
     name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
     steps:
-      - uses: actions/checkout@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
+      - uses: actions/checkout@v4
 
       - name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
-        uses: devmasx/merge-branch@854d3ac71ed1e9deb668e0074781b81fdd6e771f # 1.4.0
+        uses: devmasx/merge-branch@1.4.0
         with:
           type: now
           from_branch: ${{ matrix.pairs.from }}
@@ -50,7 +49,7 @@ jobs:
           github_token: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Comment on failure
-        uses: peter-evans/create-or-update-comment@71345be0265236311c031f5c7866368bd1eff043 # v4.0.0
+        uses: peter-evans/create-or-update-comment@v3
         if: ${{ failure() }}
         with:
           issue-number: 105153

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

@@ -16,8 +16,8 @@ jobs:
     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@44c2b7a8a4ea60a981eaca3cf939b5f4305c123b # v4.1.5
-      - uses: cachix/install-nix-action@8887e596b4ee1134dae06b98d573bd674693f47c # v26
+      - uses: actions/checkout@v4
+      - uses: cachix/install-nix-action@v23
         with:
           nix_path: nixpkgs=channel:nixpkgs-unstable
       - name: setup
@@ -46,7 +46,7 @@ jobs:
         run: |
           git clean -f
       - name: create PR
-        uses: peter-evans/create-pull-request@9153d834b60caba6d51c9b9510b087acf9f33f83 # v6.0.4
+        uses: peter-evans/create-pull-request@v5
         with:
           body: |
             Automatic update by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action.
@@ -60,7 +60,7 @@ jobs:
 
             Check that all providers build with:
             ```
-            @ofborg build opentofu.full
+            @ofborg build terraform.full
             ```
             If there is more than ten commits in the PR `ofborg` won't build it automatically and you will need to use the above command.
           branch: terraform-providers-update

.gitignore

@@ -11,12 +11,12 @@ outputs/
 result-*
 result
 repl-result-*
-tags
 !pkgs/development/python-modules/result
 /doc/NEWS.html
 /doc/NEWS.txt
 /doc/manual.html
 /doc/manual.pdf
+/result
 /source/
 .version-suffix
 

.mailmap

@@ -12,5 +12,3 @@ Sandro Jäckel <sandro.jaeckel@gmail.com> <sandro.jaeckel@sap.com>
 superherointj <5861043+superherointj@users.noreply.github.com>
 Vladimír Čunát <v@cunat.cz> <vcunat@gmail.com>
 Vladimír Čunát <v@cunat.cz> <vladimir.cunat@nic.cz>
-Yifei Sun <ysun@hey.com> StepBroBD <Hi@StepBroBD.com>
-Yifei Sun <ysun@hey.com> <ysun+git@stepbrobd.com>

.version

@@ -1 +0,0 @@
-lib/.version

.version

@@ -0,0 +1 @@
+23.11

CONTRIBUTING.md

@@ -26,7 +26,7 @@ This file contains general contributing information, but individual parts also h
 
 This section describes in some detail how changes can be made and proposed with pull requests.
 
-> [!Note]
+> **Note**
 > Be aware that contributing implies licensing those contributions under the terms of [COPYING](./COPYING), an MIT-like license.
 
 0. Set up a local version of Nixpkgs to work with using GitHub and Git
@@ -129,17 +129,19 @@ When a PR is created, it will be pre-populated with some checkboxes detailed bel
 
 #### Tested using sandboxing
 
-When sandbox builds are enabled, Nix will set up an isolated environment for each build process.
-It is used to remove further hidden dependencies set by the build environment to improve reproducibility.
-This includes access to the network during the build outside of `fetch*` functions and files outside the Nix store.
-Depending on the operating system, access to other resources is blocked as well (e.g., inter-process communication is isolated on Linux); see [sandbox](https://nixos.org/manual/nix/stable/command-ref/conf-file#conf-sandbox) in the Nix manual for details.
+When sandbox builds are enabled, Nix will setup an isolated environment for each build process. It is used to remove further hidden dependencies set by the build environment to improve reproducibility. This includes access to the network during the build outside of `fetch*` functions and files outside the Nix store. Depending on the operating system access to other resources are blocked as well (ex. inter process communication is isolated on Linux); see [sandbox](https://nixos.org/manual/nix/stable/command-ref/conf-file#conf-sandbox) in the Nix manual for details.
 
-In pull requests for [nixpkgs](https://github.com/NixOS/nixpkgs/) people are asked to test builds with sandboxing enabled (see `Tested using sandboxing` in the pull request template) because in [Hydra](https://nixos.org/hydra/) sandboxing is also used.
+Sandboxing is not enabled by default in Nix due to a small performance hit on each build. In pull requests for [nixpkgs](https://github.com/NixOS/nixpkgs/) people are asked to test builds with sandboxing enabled (see `Tested using sandboxing` in the pull request template) because in [Hydra](https://nixos.org/hydra/) sandboxing is also used.
 
-If you are on Linux, sandboxing is enabled by default.
-On other platforms, sandboxing is disabled by default due to a small performance hit on each build.
+Depending if you use NixOS or other platforms you can use one of the following methods to enable sandboxing **before** building the package:
 
-Please enable sandboxing **before** building the package by adding the following to: `/etc/nix/nix.conf`:
+- **Globally enable sandboxing on NixOS**: add the following to `configuration.nix`
+
+  ```nix
+  nix.settings.sandbox = true;
+  ```
+
+- **Globally enable sandboxing on non-NixOS platforms**: add the following to: `/etc/nix/nix.conf`
 
   ```ini
   sandbox = true
@@ -271,7 +273,7 @@ Once a pull request has been merged into `master`, a backport pull request to th
 
 ### Automatically backporting changes
 
-> [!Note]
+> **Note**
 > You have to be a [Nixpkgs maintainer](./maintainers) to automatically create a backport pull request.
 
 Add the [`backport release-YY.MM` label](https://github.com/NixOS/nixpkgs/labels?q=backport) to the pull request on the `master` branch.
@@ -283,17 +285,16 @@ This can be done on both open or already merged pull requests.
 To manually create a backport pull request, follow [the standard pull request process][pr-create], with these notable differences:
 
 - Use `release-YY.MM` for the base branch, both for the local branch and the pull request.
-
-> [!Warning]
-> Do not use the `nixos-YY.MM` branch, that is a branch pointing to the tested release channel commit
+  > **Warning**
+  > Do not use the `nixos-YY.MM` branch, that is a branch pointing to the tested release channel commit
 
 - Instead of manually making and committing the changes, use [`git cherry-pick -x`](https://git-scm.com/docs/git-cherry-pick) for each commit from the pull request you'd like to backport.
   Either `git cherry-pick -x <commit>` when the reason for the backport is obvious (such as minor versions, fixes, etc.), otherwise use `git cherry-pick -xe <commit>` to add a reason for the backport to the commit message.
   Here is [an example](https://github.com/nixos/nixpkgs/commit/5688c39af5a6c5f3d646343443683da880eaefb8) of this.
 
-> [!Warning]
-> 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.
+  > **Warning**
+  > 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.
 
 - In the pull request description, link to the original pull request to `master`.
   The pull request title should include `[YY.MM]` matching the release you're backporting to.
@@ -304,7 +305,7 @@ To manually create a backport pull request, follow [the standard pull request pr
 ## How to review pull requests
 [pr-review]: #how-to-review-pull-requests
 
-> [!Warning]
+> **Warning**
 > The following section is a draft, and the policy for reviewing is still being discussed in issues such as [#11166](https://github.com/NixOS/nixpkgs/issues/11166) and [#20836](https://github.com/NixOS/nixpkgs/issues/20836).
 
 The Nixpkgs project receives a fairly high number of contributions via GitHub pull requests. Reviewing and approving these is an important task and a way to contribute to the project.
@@ -321,7 +322,7 @@ All the review template samples provided in this section are generic and meant a
 
 To get more information about how to review specific parts of Nixpkgs, refer to the documents linked to in the [overview section][overview].
 
-If a pull request contains documentation changes that might require feedback from the documentation team, ping [@NixOS/documentation-team](https://github.com/orgs/nixos/teams/documentation-team) on the pull request.
+If a pull request contains documentation changes that might require feedback from the documentation team, ping @NixOS/documentation-team on the pull request.
 
 If you consider having enough knowledge and experience in a topic and would like to be a long-term reviewer for related submissions, please contact the current reviewers for that topic. They will give you information about the reviewing process. The main reviewers for a topic can be hard to find as there is no list, but checking past pull requests to see who reviewed or git-blaming the code to see who committed to that topic can give some hints.
 
@@ -359,7 +360,7 @@ See [Nix Channel Status](https://status.nixos.org/) for the current channels and
 Here's a brief overview of the main Git branches and what channels they're used for:
 
 - `master`: The main branch, used for the unstable channels such as `nixpkgs-unstable`, `nixos-unstable` and `nixos-unstable-small`.
-- `release-YY.MM` (e.g. `release-23.11`): The NixOS release branches, used for the stable channels such as `nixos-23.11`, `nixos-23.11-small` and `nixpkgs-23.11-darwin`.
+- `release-YY.MM` (e.g. `release-23.05`): The NixOS release branches, used for the stable channels such as `nixos-23.05`, `nixos-23.05-small` and `nixpkgs-23.05-darwin`.
 
 When a channel is updated, a corresponding Git branch is also updated to point to the corresponding commit.
 So e.g. the [`nixpkgs-unstable` branch](https://github.com/nixos/nixpkgs/tree/nixpkgs-unstable) corresponds to the Git commit from the [`nixpkgs-unstable` channel](https://channels.nixos.org/nixpkgs-unstable).
@@ -376,14 +377,14 @@ The staging workflow exists to batch Hydra builds of many packages together.
 It works by directing commits that cause [mass rebuilds][mass-rebuild] to a separate `staging` branch that isn't directly built by Hydra.
 Regularly, the `staging` branch is _manually_ merged into a `staging-next` branch to be built by Hydra using the [`nixpkgs:staging-next` jobset](https://hydra.nixos.org/jobset/nixpkgs/staging-next).
 The `staging-next` branch should then only receive direct commits in order to fix Hydra builds.
-Once it is verified that there are no major regressions, it is merged into `master` using [a pull request](https://github.com/NixOS/nixpkgs/pulls?q=head%3Astaging-next).
+Once it is verified that there are no major regressions, it is merged into `master` using [a pull requests](https://github.com/NixOS/nixpkgs/pulls?q=head%3Astaging-next).
 This is done manually in order to ensure it's a good use of Hydra's computing resources.
 By keeping the `staging-next` branch separate from `staging`, this batching does not block developers from merging changes into `staging`.
 
 In order for the `staging` and `staging-next` branches to be up-to-date with the latest commits on `master`, there are regular _automated_ merges from `master` into `staging-next` and `staging`.
 This is implemented using GitHub workflows [here](.github/workflows/periodic-merge-6h.yml) and [here](.github/workflows/periodic-merge-24h.yml).
 
-> [!Note]
+> **Note**
 > Changes must be sufficiently tested before being merged into any branch.
 > Hydra builds should not be used as testing platform.
 
@@ -439,14 +440,14 @@ gitGraph
 
 Here's an overview of the different branches:
 
-| branch | `master` | `staging-next` | `staging` |
+| branch | `master` | `staging` | `staging-next` |
 | --- | --- | --- | --- |
-| Used for development | ✔️ | ❌ | ✔️ |
-| Built by Hydra | ✔️ | ✔️ | ❌ |
-| [Mass rebuilds][mass-rebuild] | ❌ | ⚠️  Only to fix Hydra builds | ✔️ |
-| Critical security fixes | ✔️ for non-mass-rebuilds | ✔️ for mass-rebuilds | ❌ |
-| Automatically merged into | `staging-next` | `staging` | - |
-| Manually merged into | - | `master` | `staging-next` |
+| Used for development | ✔️ | ✔️ | ❌ |
+| Built by Hydra | ✔️ | ❌ | ✔️ |
+| [Mass rebuilds][mass-rebuild] | ❌ | ✔️ | ⚠️  Only to fix Hydra builds |
+| Critical security fixes | ✔️ for non-mass-rebuilds | ❌ | ✔️ for mass-rebuilds |
+| Automatically merged into | `staging-next` | - | `staging` |
+| Manually merged into | - | `staging-next` | `master` |
 
 The staging workflow is used for all main branches, `master` and `release-YY.MM`, with corresponding names:
 - `master`/`release-YY.MM`
@@ -512,7 +513,6 @@ To get a sense for what changes are considered mass rebuilds, see [previously me
 - Check for unnecessary whitespace with `git diff --check` before committing.
 
 - If you have commits `pkg-name: oh, forgot to insert whitespace`: squash commits in this case. Use `git rebase -i`.
-  See [Squashing Commits](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing) for additional information.
 
 - For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message).
 
@@ -558,7 +558,7 @@ Names of files and directories should be in lowercase, with dashes between words
 
   ```nix
   foo {
-    arg = <...>;
+    arg = ...;
   }
   ```
 
@@ -567,14 +567,14 @@ Names of files and directories should be in lowercase, with dashes between words
   ```nix
   foo
   {
-    arg = <...>;
+    arg = ...;
   }
   ```
 
   Also fine is
 
   ```nix
-  foo { arg = <...>; }
+  foo { arg = ...; }
   ```
 
   if it's a short call.
@@ -582,45 +582,41 @@ Names of files and directories should be in lowercase, with dashes between words
 - In attribute sets or lists that span multiple lines, the attribute names or list elements should be aligned:
 
   ```nix
-  {
-    # A long list.
-    list = [
-      elem1
-      elem2
-      elem3
-    ];
+  # A long list.
+  list = [
+    elem1
+    elem2
+    elem3
+  ];
 
-    # A long attribute set.
-    attrs = {
-      attr1 = short_expr;
-      attr2 =
-        if true then big_expr else big_expr;
-    };
+  # A long attribute set.
+  attrs = {
+    attr1 = short_expr;
+    attr2 =
+      if true then big_expr else big_expr;
+  };
 
-    # Combined
-    listOfAttrs = [
-      {
-        attr1 = 3;
-        attr2 = "fff";
-      }
-      {
-        attr1 = 5;
-        attr2 = "ggg";
-      }
-    ];
-  }
+  # Combined
+  listOfAttrs = [
+    {
+      attr1 = 3;
+      attr2 = "fff";
+    }
+    {
+      attr1 = 5;
+      attr2 = "ggg";
+    }
+  ];
   ```
 
 - Short lists or attribute sets can be written on one line:
 
   ```nix
-  {
-    # A short list.
-    list = [ elem1 elem2 elem3 ];
+  # A short list.
+  list = [ elem1 elem2 elem3 ];
 
-    # A short set.
-    attrs = { x = 1280; y = 1024; };
-  }
+  # A short set.
+  attrs = { x = 1280; y = 1024; };
   ```
 
 - Breaking in the middle of a function argument can give hard-to-read code, like
@@ -654,7 +650,7 @@ Names of files and directories should be in lowercase, with dashes between words
   ```nix
   { arg1, arg2 }:
   assert system == "i686-linux";
-  stdenv.mkDerivation { /* ... */ }
+  stdenv.mkDerivation { ...
   ```
 
   not
@@ -662,41 +658,41 @@ Names of files and directories should be in lowercase, with dashes between words
   ```nix
   { arg1, arg2 }:
     assert system == "i686-linux";
-      stdenv.mkDerivation { /* ... */ }
+      stdenv.mkDerivation { ...
   ```
 
 - Function formal arguments are written as:
 
   ```nix
-  { arg1, arg2, arg3 }: { /* ... */ }
+  { arg1, arg2, arg3 }:
   ```
 
   but if they don't fit on one line they're written as:
 
   ```nix
   { arg1, arg2, arg3
-  , arg4
-  # Some comment...
-  ,  argN
-  }: { }
+  , arg4, ...
+  , # Some comment...
+    argN
+  }:
   ```
 
 - Functions should list their expected arguments as precisely as possible. That is, write
 
   ```nix
-  { stdenv, fetchurl, perl }: <...>
+  { stdenv, fetchurl, perl }: ...
   ```
 
   instead of
 
   ```nix
-  args: with args; <...>
+  args: with args; ...
   ```
 
   or
 
   ```nix
-  { stdenv, fetchurl, perl, ... }: <...>
+  { stdenv, fetchurl, perl, ... }: ...
   ```
 
   For functions that are truly generic in the number of arguments (such as wrappers around `mkDerivation`) that have some required arguments, you should write them using an `@`-pattern:
@@ -705,7 +701,7 @@ Names of files and directories should be in lowercase, with dashes between words
   { stdenv, doCoverageAnalysis ? false, ... } @ args:
 
   stdenv.mkDerivation (args // {
-    foo = if doCoverageAnalysis then "bla" else "";
+    ... if doCoverageAnalysis then "bla" else "" ...
   })
   ```
 
@@ -715,40 +711,32 @@ Names of files and directories should be in lowercase, with dashes between words
   args:
 
   args.stdenv.mkDerivation (args // {
-    foo = if args ? doCoverageAnalysis && args.doCoverageAnalysis then "bla" else "";
+    ... if args ? doCoverageAnalysis && args.doCoverageAnalysis then "bla" else "" ...
   })
   ```
 
 - Unnecessary string conversions should be avoided. Do
 
   ```nix
-  {
-    rev = version;
-  }
+  rev = version;
   ```
 
   instead of
 
   ```nix
-  {
-    rev = "${version}";
-  }
+  rev = "${version}";
   ```
 
 - Building lists conditionally _should_ be done with `lib.optional(s)` instead of using `if cond then [ ... ] else null` or `if cond then [ ... ] else [ ]`.
 
   ```nix
-  {
-    buildInputs = lib.optional stdenv.isDarwin iconv;
-  }
+  buildInputs = lib.optional stdenv.isDarwin iconv;
   ```
 
   instead of
 
   ```nix
-  {
-    buildInputs = if stdenv.isDarwin then [ iconv ] else null;
-  }
+  buildInputs = if stdenv.isDarwin then [ iconv ] else null;
   ```
 
   As an exception, an explicit conditional expression with null can be used when fixing a important bug without triggering a mass rebuild.

COPYING

@@ -1,4 +1,4 @@
-Copyright (c) 2003-2024 Eelco Dolstra and the Nixpkgs/NixOS contributors
+Copyright (c) 2003-2023 Eelco Dolstra and the Nixpkgs/NixOS contributors
 
 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files (the

README.md

@@ -1,10 +1,9 @@
 <p align="center">
-  <a href="https://nixos.org">
-    <picture>
-      <source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png">
-      <source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png">
-      <img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/main/public/logo/nixos-hires.png" width="500px" alt="NixOS logo">
-    </picture>
+  <a href="https://nixos.org#gh-light-mode-only">
+    <img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/master/logo/nixos-hires.png" width="500px" alt="NixOS logo"/>
+  </a>
+  <a href="https://nixos.org#gh-dark-mode-only">
+    <img src="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png" width="500px" alt="NixOS logo"/>
   </a>
 </p>
 
@@ -14,7 +13,7 @@
 </p>
 
 [Nixpkgs](https://github.com/nixos/nixpkgs) is a collection of over
-100,000 software packages that can be installed with the
+80,000 software packages that can be installed with the
 [Nix](https://nixos.org/nix/) package manager. It also implements
 [NixOS](https://nixos.org/nixos/), a purely-functional Linux distribution.
 
@@ -29,8 +28,8 @@
 * [Discourse Forum](https://discourse.nixos.org/)
 * [Matrix Chat](https://matrix.to/#/#community:nixos.org)
 * [NixOS Weekly](https://weekly.nixos.org/)
-* [Official wiki](https://wiki.nixos.org/)
-* [Community-maintained list of ways to get in touch](https://wiki.nixos.org/wiki/Get_In_Touch#Chat) (Discord, Telegram, IRC, etc.)
+* [Community-maintained wiki](https://nixos.wiki/)
+* [Community-maintained list of ways to get in touch](https://nixos.wiki/wiki/Get_In_Touch#Chat) (Discord, Telegram, IRC, etc.)
 
 # Other Project Repositories
 
@@ -52,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 24.05 release](https://hydra.nixos.org/jobset/nixos/release-24.05)
+* [Continuous package builds for the NixOS 23.11 release](https://hydra.nixos.org/jobset/nixos/release-23.11)
 * [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
-* [Tests for the NixOS 24.05 release](https://hydra.nixos.org/job/nixos/release-24.05/tested#tabs-constituents)
+* [Tests for the NixOS 23.11 release](https://hydra.nixos.org/job/nixos/release-23.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/README.md

@@ -1,18 +1,14 @@
-# Contributing to the Nixpkgs reference manual
+# Contributing to the Nixpkgs manual
 
-This directory houses the sources files for the Nixpkgs reference manual.
-
-Going forward, it should only contain [reference](https://nix.dev/contributing/documentation/diataxis#reference) documentation.
-For tutorials, guides and explanations, contribute to <https://nix.dev/> instead.
-
-For documentation only relevant for contributors, use Markdown files and code comments in the source code.
-
-Rendered documentation:
-- [Unstable (from master)](https://nixos.org/manual/nixpkgs/unstable/)
-- [Stable (from latest release)](https://nixos.org/manual/nixpkgs/stable/)
+This directory houses the sources files for the Nixpkgs manual.
 
+You can find the [rendered documentation for Nixpkgs `unstable` on nixos.org](https://nixos.org/manual/nixpkgs/unstable/).
 The rendering tool is [nixos-render-docs](../pkgs/tools/nix/nixos-render-docs/src/nixos_render_docs), sometimes abbreviated `nrd`.
 
+[Docs for Nixpkgs stable](https://nixos.org/manual/nixpkgs/stable/) are also available.
+
+If you're only getting started with Nix, go to [nixos.org/learn](https://nixos.org/learn).
+
 ## Contributing to this documentation
 
 You can quickly check your edits with `nix-build`:
@@ -52,7 +48,7 @@ It uses the widely compatible [header attributes](https://github.com/jgm/commonm
 ## Syntax {#sec-contributing-markup}
 ```
 
-> [!Note]
+> **Note**
 > NixOS option documentation does not support headings in general.
 
 #### Inline Anchors
@@ -62,7 +58,7 @@ Allow linking arbitrary place in the text (e.g. individual list items, sentences
 They are defined using a hybrid of the link syntax with the attributes syntax known from headings, called [bracketed spans](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/bracketed_spans.md):
 
 ```markdown
-- []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGApps*` hook will prepend it to `XDG_DATA_DIRS`.
+- []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGAppsHook` will prepend it to `XDG_DATA_DIRS`.
 ```
 
 #### Automatic links
@@ -71,11 +67,6 @@ If you **omit a link text** for a link pointing to a section, the text will be s
 
 This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/using/syntax.html#targets-and-cross-referencing).
 
-
-#### HTML
-
-Inlining HTML is not allowed. Parts of the documentation gets rendered to various non-HTML formats, such as man pages in the case of NixOS manual.
-
 #### Roles
 
 If you want to link to a man page, you can use `` {manpage}`nix.conf(5)` ``. The references will turn into links when a mapping exists in [`doc/manpage-urls.json`](./manpage-urls.json).
@@ -106,24 +97,11 @@ This is a warning
 
 The following are supported:
 
-- `caution`
-- `important`
-- `note`
-- `tip`
-- `warning`
-- `example`
-
-Example admonitions require a title to work.
-If you don't provide one, the manual won't be built.
-
-```markdown
-::: {.example #ex-showing-an-example}
-
-# Title for this example
-
-Text for the example.
-:::
-```
+- [`caution`](https://tdg.docbook.org/tdg/5.0/caution.html)
+- [`important`](https://tdg.docbook.org/tdg/5.0/important.html)
+- [`note`](https://tdg.docbook.org/tdg/5.0/note.html)
+- [`tip`](https://tdg.docbook.org/tdg/5.0/tip.html)
+- [`warning`](https://tdg.docbook.org/tdg/5.0/warning.html)
 
 #### [Definition lists](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/definition_lists.md)
 
@@ -157,192 +135,3 @@ watermelon
     Closes #216321.
 
 - If the commit contains more than just documentation changes, follow the commit message format relevant for the rest of the changes.
-
-## Documentation conventions
-
-In an effort to keep the Nixpkgs manual in a consistent style, please follow the conventions below, unless they prevent you from properly documenting something.
-In that case, please open an issue about the particular documentation convention and tag it with a "needs: documentation" label.
-When needed, each convention explain why it exists, so you can make a decision whether to follow it or not based on your particular case.
-Note that these conventions are about the **structure** of the manual (and its source files), not about the content that goes in it.
-You, as the writer of documentation, are still in charge of its content.
-
-- Put each sentence in its own line.
-  This makes reviews and suggestions much easier, since GitHub's review system is based on lines.
-  It also helps identifying long sentences at a glance.
-
-- Use the [admonition syntax](#admonitions) for callouts and examples.
-
-- Provide at least one example per function, and make examples self-contained.
-  This is easier to understand for beginners.
-  It also helps with testing that it actually works – especially once we introduce automation.
-
-  Example code should be such that it can be passed to `pkgs.callPackage`.
-  Instead of something like:
-
-  ```nix
-  pkgs.dockerTools.buildLayeredImage {
-    name = "hello";
-    contents = [ pkgs.hello ];
-  }
-  ```
-
-  Write something like:
-
-  ```nix
-  { dockerTools, hello }:
-  dockerTools.buildLayeredImage {
-    name = "hello";
-    contents = [ hello ];
-  }
-  ```
-
-- When showing inputs/outputs of any [REPL](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop), such as a shell or the Nix REPL, use a format as you'd see in the REPL, while trying to visually separate inputs from outputs.
-  This means that for a shell, you should use a format like the following:
-  ```shell
-  $ nix-build -A hello '<nixpkgs>' \
-    --option require-sigs false \
-    --option trusted-substituters file:///tmp/hello-cache \
-    --option substituters file:///tmp/hello-cache
-  /nix/store/zhl06z4lrfrkw5rp0hnjjfrgsclzvxpm-hello-2.12.1
-  ```
-  Note how the input is preceded by `$` on the first line and indented on subsequent lines, and how the output is provided as you'd see on the shell.
-
-  For the Nix REPL, you should use a format like the following:
-  ```shell
-  nix-repl> builtins.attrNames { a = 1; b = 2; }
-  [ "a" "b" ]
-  ```
-  Note how the input is preceded by `nix-repl>` and the output is provided as you'd see on the Nix REPL.
-
-- When documenting functions or anything that has inputs/outputs and example usage, use nested headings to clearly separate inputs, outputs, and examples.
-  Keep examples as the last nested heading, and link to the examples wherever applicable in the documentation.
-
-  The purpose of this convention is to provide a familiar structure for navigating the manual, so any reader can expect to find content related to inputs in an "inputs" heading, examples in an "examples" heading, and so on.
-  An example:
-  ```
-  ## buildImage
-
-  Some explanation about the function here.
-  Describe a particular scenario, and point to [](#ex-dockerTools-buildImage), which is an example demonstrating it.
-
-  ### Inputs
-
-  Documentation for the inputs of `buildImage`.
-  Perhaps even point to [](#ex-dockerTools-buildImage) again when talking about something specifically linked to it.
-
-  ### Passthru outputs
-
-  Documentation for any passthru outputs of `buildImage`.
-
-  ### Examples
-
-  Note that this is the last nested heading in the `buildImage` section.
-
-  :::{.example #ex-dockerTools-buildImage}
-
-  # Using `buildImage`
-
-  Example of how to use `buildImage` goes here.
-
-  :::
-  ```
-
-- Use [definition lists](#definition-lists) to document function arguments, and the attributes of such arguments as well as their [types](https://nixos.org/manual/nix/stable/language/values).
-  For example:
-
-  ```markdown
-  # pkgs.coolFunction
-
-  Description of what `coolFunction` does.
-
-  ## Inputs
-
-  `coolFunction` expects a single argument which should be an attribute set, with the following possible attributes:
-
-  `name` (String)
-
-  : The name of the resulting image.
-
-  `tag` (String; _optional_)
-
-  : Tag of the generated image.
-
-    _Default:_ the output path's hash.
-  ```
-
-#### Examples
-
-To define a referenceable figure use the following fencing:
-
-```markdown
-:::{.example #an-attribute-set-example}
-# An attribute set example
-
-You can add text before
-
-    ```nix
-    { a = 1; b = 2;}
-    ```
-
-and after code fencing
-:::
-```
-
-Defining examples through the `example` fencing class adds them to a "List of Examples" section after the Table of Contents.
-Though this is not shown in the rendered documentation on nixos.org.
-
-#### Figures
-
-To define a referencable figure use the following fencing:
-
-```markdown
-::: {.figure #nixos-logo}
-# NixOS Logo
-![NixOS logo](./nixos_logo.png)
-:::
-```
-
-Defining figures through the `figure` fencing class adds them to a `List  of Figures` after the `Table of Contents`.
-Though this is not shown in the rendered documentation on nixos.org.
-
-#### Footnotes
-
-To add a foonote explanation, use the following syntax:
-
-```markdown
-Sometimes it's better to add context [^context] in a footnote.
-
-[^context]: This explanation will be rendered at the end of the chapter.
-```
-
-#### Inline comments
-
-Inline comments are supported with following syntax:
-
-```markdown
-<!-- This is an inline comment -->
-```
-
-The comments will not be rendered in the rendered HTML.
-
-#### Link reference definitions
-
-Links can reference a label, for example, to make the link target reusable:
-
-```markdown
-::: {.note}
-Reference links can also be used to [shorten URLs][url-id] and keep the markdown readable.
-:::
-
-[url-id]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/doc/README.md
-```
-
-This syntax is taken from [CommonMark](https://spec.commonmark.org/0.30/#link-reference-definitions).
-
-#### Typographic replacements
-
-Typographic replacements are enabled. Check the [list of possible replacement patterns check](https://github.com/executablebooks/markdown-it-py/blob/3613e8016ecafe21709471ee0032a90a4157c2d1/markdown_it/rules_core/replacements.py#L1-L15).
-
-## Getting help
-
-If you need documentation-specific help or reviews, ping [@NixOS/documentation-team](https://github.com/orgs/nixos/teams/documentation-team) on your pull request.

doc/anchor-use.js

@@ -1,3 +0,0 @@
-document.addEventListener('DOMContentLoaded', function(event) {
-  anchors.add('h1[id]:not(div.note h1, div.warning h1, div.tip h1, div.caution h1, div.important h1), h2[id]:not(div.note h2, div.warning h2, div.tip h2, div.caution h2, div.important h2), h3[id]:not(div.note h3, div.warning h3, div.tip h3, div.caution h3, div.important h3), h4[id]:not(div.note h4, div.warning h4, div.tip h4, div.caution h4, div.important h4), h5[id]:not(div.note h5, div.warning h5, div.tip h5, div.caution h5, div.important h5), h6[id]:not(div.note h6, div.warning h6, div.tip h6, div.caution h6, div.important h6)');
-});

doc/build-helpers/fetchers.chapter.md

@@ -1,681 +1,84 @@
 # Fetchers {#chap-pkgs-fetchers}
 
 Building software with Nix often requires downloading source code and other files from the internet.
-To this end, we use functions that we call _fetchers_, which obtain remote sources via various protocols and services.
-
-Nix provides built-in fetchers such as [`builtins.fetchTarball`](https://nixos.org/manual/nix/stable/language/builtins.html#builtins-fetchTarball).
-Nixpkgs provides its own fetchers, which work differently:
+To this end, Nixpkgs provides *fetchers*: functions to obtain remote sources via various protocols and services.
 
+Nixpkgs fetchers differ from built-in fetchers such as [`builtins.fetchTarball`](https://nixos.org/manual/nix/stable/language/builtins.html#builtins-fetchTarball):
 - A built-in fetcher will download and cache files at evaluation time and produce a [store path](https://nixos.org/manual/nix/stable/glossary#gloss-store-path).
-  A Nixpkgs fetcher will create a ([fixed-output](https://nixos.org/manual/nix/stable/glossary#gloss-fixed-output-derivation)) [derivation](https://nixos.org/manual/nix/stable/glossary#gloss-derivation), and files are downloaded at build time.
+  A Nixpkgs fetcher will create a ([fixed-output](https://nixos.org/manual/nix/stable/glossary#gloss-fixed-output-derivation)) [derivation](https://nixos.org/manual/nix/stable/language/derivations), and files are downloaded at build time.
 - Built-in fetchers will invalidate their cache after [`tarball-ttl`](https://nixos.org/manual/nix/stable/command-ref/conf-file#conf-tarball-ttl) expires, and will require network activity to check if the cache entry is up to date.
-  Nixpkgs fetchers only re-download if the specified hash changes or the store object is not available.
+  Nixpkgs fetchers only re-download if the specified hash changes or the store object is not otherwise available.
 - Built-in fetchers do not use [substituters](https://nixos.org/manual/nix/stable/command-ref/conf-file#conf-substituters).
   Derivations produced by Nixpkgs fetchers will use any configured binary cache transparently.
 
-This significantly reduces the time needed to evaluate Nixpkgs, and allows [Hydra](https://nixos.org/hydra) to retain and re-distribute sources used by Nixpkgs in the [public binary cache](https://cache.nixos.org).
-For these reasons, Nix's built-in fetchers are not allowed in Nixpkgs.
+This significantly reduces the time needed to evaluate the entirety of Nixpkgs, and allows [Hydra](https://nixos.org/hydra) to retain and re-distribute sources used by Nixpkgs in the [public binary cache](https://cache.nixos.org).
+For these reasons, built-in fetchers are not allowed in Nixpkgs source code.
 
-The following table summarises the differences:
+The following table shows an overview of the differences:
 
 | Fetchers | Download | Output | Cache | Re-download when |
 |-|-|-|-|-|
 | `builtins.fetch*` | evaluation time | store path | `/nix/store`, `~/.cache/nix` | `tarball-ttl` expires, cache miss in `~/.cache/nix`, output store object not in local store |
 | `pkgs.fetch*` | build time | derivation | `/nix/store`, substituters | output store object not available |
 
-:::{.tip}
-`pkgs.fetchFrom*` helpers retrieve _snapshots_ of version-controlled sources, as opposed to the entire version history, which is more efficient.
-`pkgs.fetchgit` by default also has the same behaviour, but can be changed through specific attributes given to it.
-:::
-
 ## Caveats {#chap-pkgs-fetchers-caveats}
 
-Because Nixpkgs fetchers are fixed-output derivations, an [output hash](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-outputHash) has to be specified, usually indirectly through a `hash` attribute.
-This hash refers to the derivation output, which can be different from the remote source itself!
-
-This has the following implications that you should be aware of:
-
-- Use Nix (or Nix-aware) tooling to produce the output hash.
-
-- When changing any fetcher parameters, always update the output hash.
-  Use one of the methods from [](#sec-pkgs-fetchers-updating-source-hashes).
-  Otherwise, existing store objects that match the output hash will be re-used rather than fetching new content.
-
-  :::{.note}
-  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.
-  :::
-
-## Updating source hashes {#sec-pkgs-fetchers-updating-source-hashes}
-
-There are several ways to obtain the hash corresponding to a remote source.
-Unless you understand how the fetcher you're using calculates the hash from the downloaded contents, you should use [the fake hash method](#sec-pkgs-fetchers-updating-source-hashes-fakehash-method).
-
-1. []{#sec-pkgs-fetchers-updating-source-hashes-fakehash-method} The fake hash method: In your package recipe, set the hash to one of
-
-   - `""`
-   - `lib.fakeHash`
-   - `lib.fakeSha256`
-   - `lib.fakeSha512`
-
-   Attempt to build, extract the calculated hashes from error messages, and put them into the recipe.
-
-   :::{.warning}
-   You must use one of these four fake hashes and not some arbitrarily-chosen hash.
-   See [](#sec-pkgs-fetchers-secure-hashes) for details.
-   :::
-
-   :::{.example #ex-fetchers-update-fod-hash}
-   # Update source hash with the fake hash method
-
-   Consider the following recipe that produces a plain file:
-
-   ```nix
-   { fetchurl }:
-   fetchurl {
-     url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.05/.version";
-     hash = "sha256-ZHl1emidXVojm83LCVrwULpwIzKE/mYwfztVkvpruOM=";
-   }
-   ```
-
-   A common mistake is to update a fetcher parameter, such as `url`, without updating the hash:
-
-   ```nix
-   { fetchurl }:
-   fetchurl {
-     url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version";
-     hash = "sha256-ZHl1emidXVojm83LCVrwULpwIzKE/mYwfztVkvpruOM=";
-   }
-   ```
-
-   **This will produce the same output as before!**
-   Set the hash to an empty string:
-
-   ```nix
-   { fetchurl }:
-   fetchurl {
-     url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version";
-     hash = "";
-   }
-   ```
-
-   When building the package, use the error message to determine the correct hash:
-
-   ```shell
-   $ nix-build
-   (some output removed for clarity)
-   error: hash mismatch in fixed-output derivation '/nix/store/7yynn53jpc93l76z9zdjj4xdxgynawcw-version.drv':
-           specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
-               got:    sha256-BZqI7r0MNP29yGH5+yW2tjU9OOpOCEvwWKrWCv5CQ0I=
-   error: build of '/nix/store/bqdjcw5ij5ymfbm41dq230chk9hdhqff-version.drv' failed
-   ```
-   :::
-
-2. Prefetch the source with [`nix-prefetch-<type> <URL>`](https://search.nixos.org/packages?buckets={%22package_attr_set%22%3A[%22No%20package%20set%22]%2C%22package_license_set%22%3A[]%2C%22package_maintainers_set%22%3A[]%2C%22package_platforms%22%3A[]}&query=nix-prefetch), where `<type>` is one of
-
-   - `url`
-   - `git`
-   - `hg`
-   - `cvs`
-   - `bzr`
-   - `svn`
-
-   The hash is printed to stdout.
-
-3. Prefetch by package source (with `nix-prefetch-url '<nixpkgs>' -A <package>.src`, where `<package>` is package attribute name).
-   The hash is printed to stdout.
-
-   This works well when you've upgraded the existing package version and want to find out new hash, but is useless if the package can't be accessed by attribute or the package has multiple sources (`.srcs`, architecture-dependent sources, etc).
-
-4. Upstream hash: use it when upstream provides `sha256` or `sha512`.
-   Don't use it when upstream provides `md5`, compute `sha256` instead.
-
-   A little nuance is that `nix-prefetch-*` tools produce hashes with the `nix32` encoding (a Nix-specific base32 adaptation), but upstream usually provides hexadecimal (`base16`) encoding.
-   Fetchers understand both formats.
-   Nixpkgs does not standardise on any one format.
-
-   You can convert between hash formats with [`nix-hash`](https://nixos.org/manual/nix/stable/command-ref/nix-hash).
-
-5. Extract the hash from a local source archive with `sha256sum`.
-   Use `nix-prefetch-url file:///path/to/archive` if you want the custom Nix `base32` hash.
-
-## Obtaining hashes securely {#sec-pkgs-fetchers-secure-hashes}
-
-It's always a good idea to avoid Man-in-the-Middle (MITM) attacks when downloading source contents.
-Otherwise, you could unknowingly download malware instead of the intended source, and instead of the actual source hash, you'll end up using the hash of malware.
-Here are security considerations for this scenario:
-
-- `http://` URLs are not secure to prefetch hashes.
-
-- Upstream hashes should be obtained via a secure protocol.
-
-- `https://` URLs give you more protections when using `nix-prefetch-*` or for upstream hashes.
-
-- `https://` URLs are secure when using the [fake hash method](#sec-pkgs-fetchers-updating-source-hashes-fakehash-method) *only if* you use one of the listed fake hashes.
-  If you use any other hash, the download will be exposed to MITM attacks even if you use HTTPS URLs.
-
-  In more concrete terms, if you use any other hash, the [`--insecure` flag](https://curl.se/docs/manpage.html#-k) will be passed to the underlying call to `curl` when downloading content.
-
-[]{#fetchurl}
-## `fetchurl` {#sec-pkgs-fetchers-fetchurl}
-
-`fetchurl` returns a [fixed-output derivation](https://nixos.org/manual/nix/stable/glossary.html#gloss-fixed-output-derivation) which downloads content from a given URL and stores the unaltered contents within the Nix store.
-
-It uses {manpage}`curl(1)` internally, and allows its behaviour to be modified by specifying a few attributes in the argument to `fetchurl` (see the documentation for attributes `curlOpts`, `curlOptsList`, and `netrcPhase`).
-
-The resulting [store path](https://nixos.org/manual/nix/stable/store/store-path) is determined by the hash given to `fetchurl`, and also the `name` (or `pname` and `version`) values.
-
-If neither `name` nor `pname` and `version` are specified when calling `fetchurl`, it will default to using the [basename](https://nixos.org/manual/nix/stable/language/builtins.html#builtins-baseNameOf) of `url` or the first element of `urls`.
-If `pname` and `version` are specified, `fetchurl` will use those values and will ignore `name`, even if it is also specified.
-
-### Inputs {#sec-pkgs-fetchers-fetchurl-inputs}
-
-`fetchurl` requires an attribute set with the following attributes:
-
-`url` (String; _optional_)
-: The URL to download from.
-
-  :::{.note}
-  Either `url` or `urls` must be specified, but not both.
-  :::
-
-  All URLs of the format [specified here](https://curl.se/docs/url-syntax.html#rfc-3986-plus) are supported.
-
-  _Default value:_ `""`.
-
-`urls` (List of String; _optional_)
-: A list of URLs, specifying download locations for the same content.
-  Each URL will be tried in order until one of them succeeds with some content or all of them fail.
-  See [](#ex-fetchers-fetchurl-nixpkgs-version-multiple-urls) to understand how this attribute affects the behaviour of `fetchurl`.
-
-  :::{.note}
-  Either `url` or `urls` must be specified, but not both.
-  :::
-
-  _Default value:_ `[]`.
-
-`hash` (String; _optional_)
-: Hash of the derivation output of `fetchurl`, following the format for integrity metadata as defined by [SRI](https://www.w3.org/TR/SRI/).
-  For more information, see [](#chap-pkgs-fetchers-caveats).
-
-  :::{.note}
-  It is recommended that you use the `hash` attribute instead of the other hash-specific attributes that exist for backwards compatibility.
-
-  If `hash` is not specified, you must specify `outputHash` and `outputHashAlgo`, or one of `sha512`, `sha256`, or `sha1`.
-  :::
-
-  _Default value:_ `""`.
-
-`outputHash` (String; _optional_)
-: Hash of the derivation output of `fetchurl` in the format expected by Nix.
-  See [the documentation on the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-outputHash) for more information about its format.
-
-  :::{.note}
-  It is recommended that you use the `hash` attribute instead.
-
-  If `outputHash` is specified, you must also specify `outputHashAlgo`.
-  :::
-
-  _Default value:_ `""`.
-
-`outputHashAlgo` (String; _optional_)
-: Algorithm used to generate the value specified in `outputHash`.
-  See [the documentation on the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-outputHashAlgo) for more information about the values it supports.
-
-  :::{.note}
-  It is recommended that you use the `hash` attribute instead.
-
-  The value specified in `outputHashAlgo` will be ignored if `outputHash` isn't also specified.
-  :::
-
-  _Default value:_ `""`.
-
-`sha1` (String; _optional_)
-: SHA-1 hash of the derivation output of `fetchurl` in the format expected by Nix.
-  See [the documentation on the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-outputHash) for more information about its format.
-
-  :::{.note}
-  It is recommended that you use the `hash` attribute instead.
-  :::
-
-  _Default value:_ `""`.
-
-`sha256` (String; _optional_)
-: SHA-256 hash of the derivation output of `fetchurl` in the format expected by Nix.
-  See [the documentation on the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-outputHash) for more information about its format.
-
-  :::{.note}
-  It is recommended that you use the `hash` attribute instead.
-  :::
-
-  _Default value:_ `""`.
-
-`sha512` (String; _optional_)
-: SHA-512 hash of the derivation output of `fetchurl` in the format expected by Nix.
-  See [the documentation on the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-outputHash) for more information about its format.
-
-  :::{.note}
-  It is recommended that you use the `hash` attribute instead.
-  :::
-
-  _Default value:_ `""`.
-
-`name` (String; _optional_)
-: The symbolic name of the downloaded file when saved in the Nix store.
-  See [the `fetchurl` overview](#sec-pkgs-fetchers-fetchurl) for details on how the name of the file is decided.
-
-  _Default value:_ `""`.
-
-`pname` (String; _optional_)
-: A base name, which will be combined with `version` to form the symbolic name of the downloaded file when saved in the Nix store.
-  See [the `fetchurl` overview](#sec-pkgs-fetchers-fetchurl) for details on how the name of the file is decided.
-
-  :::{.note}
-  If `pname` is specified, you must also specify `version`, otherwise `fetchurl` will ignore the value of `pname`.
-  :::
-
-  _Default value:_ `""`.
-
-`version` (String; _optional_)
-: A version, which will be combined with `pname` to form the symbolic name of the downloaded file when saved in the Nix store.
-  See [the `fetchurl` overview](#sec-pkgs-fetchers-fetchurl) for details on how the name of the file is decided.
-
-  _Default value:_ `""`.
-
-`recursiveHash` (Boolean; _optional_) []{#sec-pkgs-fetchers-fetchurl-inputs-recursiveHash}
-: If set to `true`, will signal to Nix that the hash given to `fetchurl` was calculated using the `"recursive"` mode.
-  See [the documentation on the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-outputHashMode) for more information about the existing modes.
-
-  By default, `fetchurl` uses `"recursive"` mode when the `executable` attribute is set to `true`, so you don't need to specify `recursiveHash` in this case.
-
-  _Default value:_ `false`.
-
-`executable` (Boolean; _optional_)
-: If `true`, sets the executable bit on the downloaded file.
-
-  _Default value_: `false`.
-
-`downloadToTemp` (Boolean; _optional_) []{#sec-pkgs-fetchers-fetchurl-inputs-downloadToTemp}
-: If `true`, saves the downloaded file to a temporary location instead of the expected Nix store location.
-  This is useful when used in conjunction with `postFetch` attribute, otherwise `fetchurl` will not produce any meaningful output.
-
-  The location of the downloaded file will be set in the `$downloadedFile` variable, which should be used by the script in the `postFetch` attribute.
-  See [](#ex-fetchers-fetchurl-nixpkgs-version-postfetch) to understand how to work with this attribute.
-
-  _Default value:_ `false`.
-
-`postFetch` (String; _optional_)
-: Script executed after the file has been downloaded successfully, and before `fetchurl` finishes running.
-  Useful for post-processing, to check or transform the file in some way.
-  See [](#ex-fetchers-fetchurl-nixpkgs-version-postfetch) to understand how to work with this attribute.
-
-  _Default value:_ `""`.
-
-`netrcPhase` (String or Null; _optional_)
-: Script executed to create a {manpage}`netrc(5)` file to be used with {manpage}`curl(1)`.
-  The script should create the `netrc` file (note that it does not begin with a ".") in the directory it's currently running in (`$PWD`).
-
-  The script is executed during the setup done by `fetchurl` before it runs any of its code to download the specified content.
-
-  :::{.note}
-  If specified, `fetchurl` will automatically alter its invocation of {manpage}`curl(1)` to use the `netrc` file, so you don't need to add anything to `curlOpts` or `curlOptsList`.
-  :::
-
-  :::{.caution}
-  Since `netrcPhase` needs to be specified in your source Nix code, any secrets that you put directly in it will be world-readable by design (both in your source code, and when the derivation gets created in the Nix store).
-
-  If you want to avoid this behaviour, see the documentation of `netrcImpureEnvVars` for an alternative way of dealing with these secrets.
-  :::
-
-  _Default value_: `null`.
-
-`netrcImpureEnvVars` (List of String; _optional_)
-: If specified, `fetchurl` will add these environment variable names to the list of [impure environment variables](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-impureEnvVars), which will be passed from the environment of the calling user to the builder running the `fetchurl` code.
-
-  This is useful when used with `netrcPhase` to hide any secrets that are used in it, because the script in `netrcPhase` only needs to reference the environment variables with the secrets in them instead.
-  However, note that these are called _impure_ variables for a reason:
-  the environment that starts the build needs to have these variables declared for everything to work properly, which means that additional setup is required outside what Nix controls.
-
-  _Default value:_ `[]`.
-
-`curlOpts` (String; _optional_)
-: If specified, this value will be appended to the invocation of {manpage}`curl(1)` when downloading the URL(s) given to `fetchurl`.
-  Multiple arguments can be separated by spaces normally, but values with whitespaces will be interpreted as multiple arguments (instead of a single value), even if the value is escaped.
-  See `curlOptsList` for a way to pass values with whitespaces in them.
-
-  _Default value:_ `""`.
-
-`curlOptsList` (List of String; _optional_)
-: If specified, each element of this list will be passed as an argument to the invocation of {manpage}`curl(1)` when downloading the URL(s) given to `fetchurl`.
-  This allows passing values that contain spaces, with no escaping needed.
-
-  _Default value:_ `[]`.
-
-`showURLs` (Boolean; _optional_)
-: If set to `true`, this will stop `fetchurl` from downloading anything at all.
-  Instead, it will output a list of all the URLs it would've used to download the content (after resolving `mirror://` URLs, for example).
-  This is useful for debugging.
-
-  _Default value:_ `false`.
-
-`meta` (Attribute Set; _optional_)
-: Specifies any [meta-attributes](#chap-meta) for the derivation returned by `fetchurl`.
-
-  _Default value:_ `{}`.
-
-`passthru` (Attribute Set; _optional_)
-: Specifies any extra [passthru](#var-stdenv-passthru) attributes for the derivation returned by `fetchurl`.
-  Note that `fetchurl` defines [passthru attributes of its own](#ssec-pkgs-fetchers-fetchurl-passthru-outputs).
-  Attributes specified in `passthru` can override the default attributes returned by `fetchurl`.
-
-  _Default value:_ `{}`.
-
-`preferLocalBuild` (Boolean; _optional_)
-: This is the same attribute as [defined in the Nix manual](https://nixos.org/manual/nix/stable/language/advanced-attributes.html#adv-attr-preferLocalBuild).
-  It is `true` by default because making a remote machine download the content just duplicates network traffic (since the local machine might download the results from the derivation anyway), but this could be useful in cases where network access is restricted on local machines.
-
-  _Default value:_ `true`.
-
-`nativeBuildInputs` (List of Attribute Set; _optional_)
-: Additional packages needed to download the content.
-  This is useful if you need extra packages for `postFetch` or `netrcPhase`, for example.
-  Has the same semantics as in [](#var-stdenv-nativeBuildInputs).
-  See [](#ex-fetchers-fetchurl-nixpkgs-version-postfetch) to understand how this can be used with `postFetch`.
-
-  _Default value:_ `[]`.
-
-### Passthru outputs {#ssec-pkgs-fetchers-fetchurl-passthru-outputs}
-
-`fetchurl` also defines its own [`passthru`](#var-stdenv-passthru) attributes:
-
-`url` (String)
-
-: The same `url` attribute passed in the argument to `fetchurl`.
-
-### Examples {#ssec-pkgs-fetchers-fetchurl-examples}
-
-:::{.example #ex-fetchers-fetchurl-nixpkgs-version}
-# Using `fetchurl` to download a file
-
-The following package downloads a small file from a URL and shows the most common way to use `fetchurl`:
+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 }:
 fetchurl {
-  url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version";
-  hash = "sha256-BZqI7r0MNP29yGH5+yW2tjU9OOpOCEvwWKrWCv5CQ0I=";
-}
+  url = "http://www.example.org/hello-1.0.tar.gz";
+  hash = "sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=";
+};
 ```
 
-After building the package, the file will be downloaded and place into the Nix store:
-
-```shell
-$ nix-build
-(output removed for clarity)
-/nix/store/4g9y3x851wqrvim4zcz5x2v3zivmsq8n-version
-
-$ cat /nix/store/4g9y3x851wqrvim4zcz5x2v3zivmsq8n-version
-23.11
-```
-:::
-
-:::{.example #ex-fetchers-fetchurl-nixpkgs-version-multiple-urls}
-# Using `fetchurl` to download a file with multiple possible URLs
-
-The following package adapts [](#ex-fetchers-fetchurl-nixpkgs-version) to use multiple URLs.
-The first URL was crafted to intentionally return an error to illustrate how `fetchurl` will try multiple URLs until it finds one that works (or all URLs fail).
+A common mistake is to update a fetcher’s URL, or a version parameter, without updating the hash.
 
 ```nix
-{ fetchurl }:
 fetchurl {
-  urls = [
-    "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/does-not-exist"
-    "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version"
-  ];
-  hash = "sha256-BZqI7r0MNP29yGH5+yW2tjU9OOpOCEvwWKrWCv5CQ0I=";
-}
+  url = "http://www.example.org/hello-1.1.tar.gz";
+  hash = "sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=";
+};
 ```
 
-After building the package, both URLs will be used to download the file:
-
-```shell
-$ nix-build
-(some output removed for clarity)
-trying https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/does-not-exist
-(some output removed for clarity)
-curl: (22) The requested URL returned error: 404
-
-trying https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version
-(some output removed for clarity)
-/nix/store/n9asny31z32q7sdw6a8r1gllrsfy53kl-does-not-exist
-
-$ cat /nix/store/n9asny31z32q7sdw6a8r1gllrsfy53kl-does-not-exist
-23.11
-```
-
-However, note that the name of the file was derived from the first URL (this is further explained in [the `fetchurl` overview](#sec-pkgs-fetchers-fetchurl)).
-To ensure the result will have the same name regardless of which URLs are used, we can modify the package:
+**This will reuse the old contents**.
+Remember to invalidate the hash argument, in this case by setting the `hash` attribute to an empty string.
 
 ```nix
-{ fetchurl }:
 fetchurl {
-  name = "nixpkgs-version";
-  urls = [
-    "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/does-not-exist"
-    "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version"
-  ];
-  hash = "sha256-BZqI7r0MNP29yGH5+yW2tjU9OOpOCEvwWKrWCv5CQ0I=";
-}
+  url = "http://www.example.org/hello-1.1.tar.gz";
+  hash = "";
+};
 ```
 
-After building the package, the result will have the name we specified:
+Use the resulting error message to determine the correct hash.
 
-```shell
-$ nix-build
-(output removed for clarity)
-/nix/store/zczb6wl3al6jm9sm5h3pr6nqn0i5ji9z-nixpkgs-version
 ```
-:::
+error: hash mismatch in fixed-output derivation '/path/to/my.drv':
+         specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
+            got:    sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=
+```
 
-:::{.example #ex-fetchers-fetchurl-nixpkgs-version-postfetch}
-# Manipulating the content downloaded by `fetchurl`
+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.
 
-It might be useful to manipulate the content downloaded by `fetchurl` directly in its derivation.
-In this example, we'll adapt [](#ex-fetchers-fetchurl-nixpkgs-version) to append the result of running the `hello` package to the contents we download, purely to illustrate how to manipulate the content.
+## `fetchurl` and `fetchzip` {#fetchurl}
+
+Two basic fetchers are `fetchurl` and `fetchzip`. Both of these have two required arguments, a URL and a hash. The hash is typically `hash`, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use `hash`. This hash will be used by Nix to identify your source. A typical usage of `fetchurl` is provided below.
 
 ```nix
-{ fetchurl, hello, lib }:
-fetchurl {
-  url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version";
+{ stdenv, fetchurl }:
 
-  nativeBuildInputs = [ hello ];
-
-  downloadToTemp = true;
-  postFetch = ''
-    ${lib.getExe hello} >> $downloadedFile
-    mv $downloadedFile $out
-  '';
-
-  hash = "sha256-ceooQQYmDx5+0nfg40uU3NNI2yKrixP7HZ/xLZUNv+w=";
+stdenv.mkDerivation {
+  name = "hello";
+  src = fetchurl {
+    url = "http://www.example.org/hello.tar.gz";
+    hash = "sha256-BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=";
+  };
 }
 ```
 
-After building the package, the resulting file will have "Hello, world!" appended to it:
-
-```shell
-$ nix-build
-(output removed for clarity)
-/nix/store/ifi6pp7q0ag5h7c5v9h1c1c7bhd10c7f-version
-
-$ cat /nix/store/ifi6pp7q0ag5h7c5v9h1c1c7bhd10c7f-version
-23.11
-Hello, world!
-```
-
-Note that the `hash` specified in the package is different than the hash specified in [](#ex-fetchers-fetchurl-nixpkgs-version), because the contents of the output have changed (even though the actual file that was downloaded is the same).
-See [](#chap-pkgs-fetchers-caveats) for more details on how to work with the `hash` attribute when the output changes.
-:::
-
-## `fetchzip` {#sec-pkgs-fetchers-fetchzip}
-
-Returns a [fixed-output derivation](https://nixos.org/manual/nix/stable/glossary.html#gloss-fixed-output-derivation) which downloads an archive from a given URL and decompresses it.
-
-Despite its name, `fetchzip` is not limited to `.zip` files but can also be used with [various compressed tarball formats](#tar-files) by default.
-This can extended by specifying additional attributes, see [](#ex-fetchers-fetchzip-rar-archive) to understand how to do that.
-
-### Inputs {#sec-pkgs-fetchers-fetchzip-inputs}
-
-`fetchzip` requires an attribute set, and most attributes are passed to the underlying call to [`fetchurl`](#sec-pkgs-fetchers-fetchurl).
-
-The attributes below are treated differently by `fetchzip` when compared to what `fetchurl` expects:
-
-`name` (String; _optional_)
-: Works as defined in `fetchurl`, but has a different default value than `fetchurl`.
-
-  _Default value:_ `"source"`.
-
-`nativeBuildInputs` (List of Attribute Set; _optional_)
-: Works as defined in `fetchurl`, but it is also augmented by `fetchzip` to include packages to deal with additional archives (such as `.zip`).
-
-  _Default value:_ `[]`.
-
-`postFetch` (String; _optional_)
-: Works as defined in `fetchurl`, but it is also augmented with the code needed to make `fetchzip` work.
-
-  :::{.caution}
-  It is only safe to modify files in `$out` in `postFetch`.
-  Consult the implementation of `fetchzip` for anything more involved.
-  :::
-
-  _Default value:_ `""`.
-
-`stripRoot` (Boolean; _optional_)
-: If `true`, the decompressed contents are moved one level up the directory tree.
-
-  This is useful for archives that decompress into a single directory which commonly includes some values that change with time, such as version numbers.
-  When this is the case (and `stripRoot` is `true`), `fetchzip` will remove this directory and make the decompressed contents available in the top-level directory.
-
-  [](#ex-fetchers-fetchzip-simple-striproot) shows what this attribute does.
-
-  This attribute is **not** passed through to `fetchurl`.
-
-  _Default value:_ `true`.
-
-`extension` (String or Null; _optional_)
-: If set, the archive downloaded by `fetchzip` will be renamed to a filename with the extension specified in this attribute.
-
-  This is useful when making `fetchzip` support additional types of archives, because the implementation may use the extension of an archive to determine whether they can decompress it.
-  If the URL you're using to download the contents doesn't end with the extension associated with the archive, use this attribute to fix the filename of the archive.
-
-  This attribute is **not** passed through to `fetchurl`.
-
-  _Default value:_ `null`.
-
-`recursiveHash` (Boolean; _optional_)
-: Works [as defined in `fetchurl`](#sec-pkgs-fetchers-fetchurl-inputs-recursiveHash), but its default value is different than for `fetchurl`.
-
-  _Default value:_ `true`.
-
-`downloadToTemp` (Boolean; _optional_)
-: Works [as defined in `fetchurl`](#sec-pkgs-fetchers-fetchurl-inputs-downloadToTemp), but its default value is different than for `fetchurl`.
-
-  _Default value:_ `true`.
-
-`extraPostFetch` **DEPRECATED**
-: This attribute is deprecated.
-  Please use `postFetch` instead.
-
-  This attribute is **not** passed through to `fetchurl`.
-
-### Examples {#sec-pkgs-fetchers-fetchzip-examples}
-
-::::{.example #ex-fetchers-fetchzip-simple-striproot}
-# Using `fetchzip` to output contents directly
-
-The following recipe shows how to use `fetchzip` to decompress a `.tar.gz` archive:
-
-```nix
-{ fetchzip }:
-fetchzip {
-  url = "https://github.com/NixOS/patchelf/releases/download/0.18.0/patchelf-0.18.0.tar.gz";
-  hash = "sha256-3ABYlME9R8klcpJ7MQpyFEFwHmxDDEzIYBqu/CpDYmg=";
-}
-```
-
-This archive has all its contents in a directory named `patchelf-0.18.0`.
-This means that after decompressing, you'd have to enter this directory to see the contents of the archive.
-However, `fetchzip` makes this easier through the attribute `stripRoot` (enabled by default).
-
-After building the recipe, the derivation output will show all the files in the archive at the top level:
-
-```shell
-$ nix-build
-(output removed for clarity)
-/nix/store/1b7h3fvmgrcddvs0m299hnqxlgli1yjw-source
-
-$ ls /nix/store/1b7h3fvmgrcddvs0m299hnqxlgli1yjw-source
-aclocal.m4  completions  configure.ac  m4           Makefile.in  patchelf.spec     README.md  tests
-build-aux   configure    COPYING       Makefile.am  patchelf.1   patchelf.spec.in  src        version
-```
-
-If `stripRoot` is set to `false`, the derivation output will be the decompressed archive as-is:
-
-```nix
-{ fetchzip }:
-fetchzip {
-  url = "https://github.com/NixOS/patchelf/releases/download/0.18.0/patchelf-0.18.0.tar.gz";
-  hash = "sha256-uv3FuKE4DqpHT3yfE0qcnq0gYjDNQNKZEZt2+PUAneg=";
-  stripRoot = false;
-}
-```
-
-:::{.caution}
-The hash changed!
-Whenever changing attributes of a Nixpkgs fetcher, [remember to invalidate the hash](#chap-pkgs-fetchers-caveats), otherwise you won't get the results you're expecting!
-:::
-
-After building the recipe:
-
-```shell
-$ nix-build
-(output removed for clarity)
-/nix/store/2hy5bxw7xgbgxkn0i4x6hjr8w3dbx16c-source
-
-$ ls /nix/store/2hy5bxw7xgbgxkn0i4x6hjr8w3dbx16c-source
-patchelf-0.18.0
-```
-::::
-
-::::{.example #ex-fetchers-fetchzip-rar-archive}
-# Using `fetchzip` to decompress a `.rar` file
-
-The `unrar` package provides a [setup hook](#ssec-setup-hooks) to decompress `.rar` archives during the [unpack phase](#ssec-unpack-phase), which can be used with `fetchzip` to decompress those archives:
-
-```nix
-{ fetchzip, unrar }:
-fetchzip {
-  url = "https://archive.org/download/SpaceCadet_Plus95/Space_Cadet.rar";
-  hash = "sha256-fC+zsR8BY6vXpUkVd6i1jF0IZZxVKVvNi6VWCKT+pA4=";
-  stripRoot = false;
-  nativeBuildInputs = [ unrar ];
-}
-```
-
-Since this particular `.rar` file doesn't put its contents in a directory inside the archive, `stripRoot` must be set to `false`.
-
-After building the recipe, the derivation output will show the decompressed files:
-
-```shell
-$ nix-build
-(output removed for clarity)
-/nix/store/zpn7knxfva6rfjja2gbb4p3l9w1f0d36-source
-
-$ ls /nix/store/zpn7knxfva6rfjja2gbb4p3l9w1f0d36-source
-FONT.DAT      PINBALL.DAT  PINBALL.EXE	PINBALL2.MID  TABLE.BMP    WMCONFIG.EXE
-MSCREATE.DIR  PINBALL.DOC  PINBALL.MID	Sounds	     WAVEMIX.INF
-```
-::::
+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}
 
@@ -716,7 +119,7 @@ Here is an example of `fetchDebianPatch` in action:
 buildPythonPackage rec {
   pname = "pysimplesoap";
   version = "1.16.2";
-  src = <...>;
+  src = ...;
 
   patches = [
     (fetchDebianPatch {
@@ -727,7 +130,7 @@ buildPythonPackage rec {
     })
   ];
 
-  # ...
+  ...
 }
 ```
 
@@ -836,7 +239,7 @@ This is a useful last-resort workaround for license restrictions that prohibit r
 If the requested file is present in the Nix store, the resulting derivation will not be built, because its expected output is already available.
 Otherwise, the builder will run, but fail with a message explaining to the user how to provide the file. The following code, for example:
 
-```nix
+```
 requireFile {
   name = "jdk-${version}_linux-x64_bin.tar.gz";
   url = "https://www.oracle.com/java/technologies/javase-jdk11-downloads.html";
@@ -855,15 +258,11 @@ or
 
 ***
 ```
-
-This function should only be used by non-redistributable software with an unfree license that we need to require the user to download manually.
-It produces packages that cannot be built automatically.
-
 ## `fetchtorrent` {#fetchtorrent}
 
 `fetchtorrent` expects two arguments. `url` which can either be a Magnet URI (Magnet Link) such as `magnet:?xt=urn:btih:dd8255ecdc7ca55fb0bbf81323d87062db1f6d1c` or an HTTP URL pointing to a `.torrent` file. It can also take a `config` argument which will craft a `settings.json` configuration file and give it to `transmission`, the underlying program that is performing the fetch. The available config options for `transmission` can be found [here](https://github.com/transmission/transmission/blob/main/docs/Editing-Configuration-Files.md#options)
 
-```nix
+```
 { fetchtorrent }:
 
 fetchtorrent {

doc/build-helpers/images.md

@@ -6,6 +6,7 @@ This chapter describes tools for creating various types of images.
 images/appimagetools.section.md
 images/dockertools.section.md
 images/ocitools.section.md
+images/snaptools.section.md
 images/portableservice.section.md
 images/makediskimage.section.md
 images/binarycache.section.md

doc/build-helpers/images/appimagetools.section.md

@@ -1,167 +1,48 @@
 # pkgs.appimageTools {#sec-pkgs-appimageTools}
 
-`pkgs.appimageTools` is a set of functions for extracting and wrapping [AppImage](https://appimage.org/) files.
-They are meant to be used if traditional packaging from source is infeasible, or if it would take too long.
-To quickly run an AppImage file, `pkgs.appimage-run` can be used as well.
+`pkgs.appimageTools` is a set of functions for extracting and wrapping [AppImage](https://appimage.org/) files. They are meant to be used if traditional packaging from source is infeasible, or it would take too long. To quickly run an AppImage file, `pkgs.appimage-run` can be used as well.
 
 ::: {.warning}
 The `appimageTools` API is unstable and may be subject to backwards-incompatible changes in the future.
 :::
 
+## AppImage formats {#ssec-pkgs-appimageTools-formats}
+
+There are different formats for AppImages, see [the specification](https://github.com/AppImage/AppImageSpec/blob/74ad9ca2f94bf864a4a0dac1f369dd4f00bd1c28/draft.md#image-format) for details.
+
+- Type 1 images are ISO 9660 files that are also ELF executables.
+- Type 2 images are ELF executables with an appended filesystem.
+
+They can be told apart with `file -k`:
+
+```ShellSession
+$ file -k type1.AppImage
+type1.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) ISO 9660 CD-ROM filesystem data 'AppImage' (Lepton 3.x), scale 0-0,
+spot sensor temperature 0.000000, unit celsius, color scheme 0, calibration: offset 0.000000, slope 0.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=d629f6099d2344ad82818172add1d38c5e11bc6d, stripped\012- data
+
+$ file -k type2.AppImage
+type2.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) (Lepton 3.x), scale 232-60668, spot sensor temperature -4.187500, color scheme 15, show scale bar, calibration: offset -0.000000, slope 0.000000 (Lepton 2.x), scale 4111-45000, spot sensor temperature 412442.250000, color scheme 3, minimum point enabled, calibration: offset -75402534979642766821519867692934234112.000000, slope 5815371847733706829839455140374904832.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=79dcc4e55a61c293c5e19edbd8d65b202842579f, stripped\012- data
+```
+
+Note how the type 1 AppImage is described as an `ISO 9660 CD-ROM filesystem`, and the type 2 AppImage is not.
+
 ## Wrapping {#ssec-pkgs-appimageTools-wrapping}
 
-Use `wrapType2` to wrap any AppImage.
-This will create a FHS environment with many packages [expected to exist](https://github.com/AppImage/pkg2appimage/blob/master/excludelist) for the AppImage to work.
-`wrapType2` expects an argument with the `src` attribute, and either a `name` attribute or `pname` and `version` attributes.
-
-It will eventually call into [`buildFHSEnv`](#sec-fhs-environments), and any extra attributes in the argument to `wrapType2` will be passed through to it.
-This means that you can pass the `extraInstallCommands` attribute, for example, and it will have the same effect as described in [`buildFHSEnv`](#sec-fhs-environments).
-
-::: {.note}
-In the past, `appimageTools` provided both `wrapType1` and `wrapType2`, to be used depending on the type of AppImage that was being wrapped.
-However, [those were unified early 2020](https://github.com/NixOS/nixpkgs/pull/81833), meaning that both `wrapType1` and `wrapType2` have the same behaviour now.
-:::
-
-:::{.example #ex-wrapping-appimage-from-github}
-
-# Wrapping an AppImage from GitHub
+Depending on the type of AppImage you're wrapping, you'll have to use `wrapType1` or `wrapType2`.
 
 ```nix
-{ appimageTools, fetchurl }:
-let
-  pname = "nuclear";
-  version = "0.6.30";
-
+appimageTools.wrapType2 { # or wrapType1
+  name = "patchwork";
   src = fetchurl {
-    url = "https://github.com/nukeop/nuclear/releases/download/v${version}/${pname}-v${version}.AppImage";
-    hash = "sha256-he1uGC1M/nFcKpMM9JKY4oeexJcnzV0ZRxhTjtJz6xw=";
+    url = "https://github.com/ssbc/patchwork/releases/download/v3.11.4/Patchwork-3.11.4-linux-x86_64.AppImage";
+    hash = "sha256-OqTitCeZ6xmWbqYTXp8sDrmVgTNjPZNW0hzUPW++mq4=";
   };
-in
-appimageTools.wrapType2 {
-  inherit pname version src;
+  extraPkgs = pkgs: with pkgs; [ ];
 }
 ```
 
-:::
-
-The argument passed to `wrapType2` can also contain an `extraPkgs` attribute, which allows you to include additional packages inside the FHS environment your AppImage is going to run in.
-`extraPkgs` must be a function that returns a list of packages.
-There are a few ways to learn which dependencies an application needs:
-
-  - Looking through the extracted AppImage files, reading its scripts and running `patchelf` and `ldd` on its executables.
-    This can also be done in `appimage-run`, by setting `APPIMAGE_DEBUG_EXEC=bash`.
+- `name` specifies the name of the resulting image.
+- `src` specifies the AppImage file to extract.
+- `extraPkgs` allows you to pass a function to include additional packages inside the FHS environment your AppImage is going to run in. There are a few ways to learn which dependencies an application needs:
+  - Looking through the extracted AppImage files, reading its scripts and running `patchelf` and `ldd` on its executables. This can also be done in `appimage-run`, by setting `APPIMAGE_DEBUG_EXEC=bash`.
   - Running `strace -vfefile` on the wrapped executable, looking for libraries that can't be found.
-
-:::{.example #ex-wrapping-appimage-with-extrapkgs}
-
-# Wrapping an AppImage with extra packages
-
-```nix
-{ appimageTools, fetchurl }:
-let
-  pname = "irccloud";
-  version = "0.16.0";
-
-  src = fetchurl {
-    url = "https://github.com/irccloud/irccloud-desktop/releases/download/v${version}/IRCCloud-${version}-linux-x86_64.AppImage";
-    sha256 = "sha256-/hMPvYdnVB1XjKgU2v47HnVvW4+uC3rhRjbucqin4iI=";
-  };
-in appimageTools.wrapType2 {
-  inherit pname version src;
-  extraPkgs = pkgs: [ pkgs.at-spi2-core ];
-}
-```
-
-:::
-
-## Extracting {#ssec-pkgs-appimageTools-extracting}
-
-Use `extract` if you need to extract the contents of an AppImage.
-This is usually used in Nixpkgs to install extra files in addition to [wrapping](#ssec-pkgs-appimageTools-wrapping) the AppImage.
-`extract` expects an argument with the `src` attribute, and either a `name` attribute or `pname` and `version` attributes.
-
-::: {.note}
-In the past, `appimageTools` provided both `extractType1` and `extractType2`, to be used depending on the type of AppImage that was being extracted.
-However, [those were unified early 2020](https://github.com/NixOS/nixpkgs/pull/81572), meaning that both `extractType1` and `extractType2` have the same behaviour as `extract` now.
-:::
-
-:::{.example #ex-extracting-appimage}
-
-# Extracting an AppImage to install extra files
-
-This example was adapted from a real package in Nixpkgs to show how `extract` is usually used in combination with `wrapType2`.
-Note how `appimageContents` is used in `extraInstallCommands` to install additional files that were extracted from the AppImage.
-
-```nix
-{ appimageTools, fetchurl }:
-let
-  pname = "irccloud";
-  version = "0.16.0";
-
-  src = fetchurl {
-    url = "https://github.com/irccloud/irccloud-desktop/releases/download/v${version}/IRCCloud-${version}-linux-x86_64.AppImage";
-    sha256 = "sha256-/hMPvYdnVB1XjKgU2v47HnVvW4+uC3rhRjbucqin4iI=";
-  };
-
-  appimageContents = appimageTools.extract {
-    inherit pname version src;
-  };
-in appimageTools.wrapType2 {
-  inherit pname version src;
-
-  extraPkgs = pkgs: [ pkgs.at-spi2-core ];
-
-  extraInstallCommands = ''
-    mv $out/bin/${pname}-${version} $out/bin/${pname}
-    install -m 444 -D ${appimageContents}/irccloud.desktop $out/share/applications/irccloud.desktop
-    install -m 444 -D ${appimageContents}/usr/share/icons/hicolor/512x512/apps/irccloud.png \
-      $out/share/icons/hicolor/512x512/apps/irccloud.png
-    substituteInPlace $out/share/applications/irccloud.desktop \
-      --replace 'Exec=AppRun' 'Exec=${pname}'
-  '';
-}
-```
-
-:::
-
-The argument passed to `extract` can also contain a `postExtract` attribute, which allows you to execute additional commands after the files are extracted from the AppImage.
-`postExtract` must be a string with commands to run.
-
-:::{.example #ex-extracting-appimage-with-postextract}
-
-# Extracting an AppImage to install extra files, using `postExtract`
-
-This is a rewrite of [](#ex-extracting-appimage) to use `postExtract`.
-
-```nix
-{ appimageTools, fetchurl }:
-let
-  pname = "irccloud";
-  version = "0.16.0";
-
-  src = fetchurl {
-    url = "https://github.com/irccloud/irccloud-desktop/releases/download/v${version}/IRCCloud-${version}-linux-x86_64.AppImage";
-    sha256 = "sha256-/hMPvYdnVB1XjKgU2v47HnVvW4+uC3rhRjbucqin4iI=";
-  };
-
-  appimageContents = appimageTools.extract {
-    inherit pname version src;
-    postExtract = ''
-      substituteInPlace $out/irccloud.desktop --replace 'Exec=AppRun' 'Exec=${pname}'
-    '';
-  };
-in appimageTools.wrapType2 {
-  inherit pname version src;
-
-  extraPkgs = pkgs: [ pkgs.at-spi2-core ];
-
-  extraInstallCommands = ''
-    mv $out/bin/${pname}-${version} $out/bin/${pname}
-    install -m 444 -D ${appimageContents}/irccloud.desktop $out/share/applications/irccloud.desktop
-    install -m 444 -D ${appimageContents}/usr/share/icons/hicolor/512x512/apps/irccloud.png \
-      $out/share/icons/hicolor/512x512/apps/irccloud.png
-  '';
-}
-```
-
-:::

doc/build-helpers/images/binarycache.section.md

@@ -1,58 +1,49 @@
 # pkgs.mkBinaryCache {#sec-pkgs-binary-cache}
 
-`pkgs.mkBinaryCache` is a function for creating Nix flat-file binary caches.
-Such a cache exists as a directory on disk, and can be used as a Nix substituter by passing `--substituter file:///path/to/cache` to Nix commands.
+`pkgs.mkBinaryCache` is a function for creating Nix flat-file binary caches. Such a cache exists as a directory on disk, and can be used as a Nix substituter by passing `--substituter file:///path/to/cache` to Nix commands.
 
-Nix packages are most commonly shared between machines using [HTTP, SSH, or S3](https://nixos.org/manual/nix/stable/package-management/sharing-packages.html), but a flat-file binary cache can still be useful in some situations.
-For example, you can copy it directly to another machine, or make it available on a network file system.
-It can also be a convenient way to make some Nix packages available inside a container via bind-mounting.
+Nix packages are most commonly shared between machines using [HTTP, SSH, or S3](https://nixos.org/manual/nix/stable/package-management/sharing-packages.html), but a flat-file binary cache can still be useful in some situations. For example, you can copy it directly to another machine, or make it available on a network file system. It can also be a convenient way to make some Nix packages available inside a container via bind-mounting.
 
-`mkBinaryCache` expects an argument with the `rootPaths` attribute.
-`rootPaths` must be a list of derivations.
-The transitive closure of these derivations' outputs will be copied into the cache.
+Note that this function is meant for advanced use-cases. The more idiomatic way to work with flat-file binary caches is via the [nix-copy-closure](https://nixos.org/manual/nix/stable/command-ref/nix-copy-closure.html) command. You may also want to consider [dockerTools](#sec-pkgs-dockerTools) for your containerization needs.
 
-::: {.note}
-This function is meant for advanced use cases.
-The more idiomatic way to work with flat-file binary caches is via the [nix-copy-closure](https://nixos.org/manual/nix/stable/command-ref/nix-copy-closure.html) command.
-You may also want to consider [dockerTools](#sec-pkgs-dockerTools) for your containerization needs.
-:::
-
-[]{#sec-pkgs-binary-cache-example}
-:::{.example #ex-mkbinarycache-copying-package-closure}
-
-# Copying a package and its closure to another machine with `mkBinaryCache`
+## Example {#sec-pkgs-binary-cache-example}
 
 The following derivation will construct a flat-file binary cache containing the closure of `hello`.
 
 ```nix
-{ mkBinaryCache, hello }:
 mkBinaryCache {
   rootPaths = [hello];
 }
 ```
 
-Build the cache on a machine.
-Note that the command still builds the exact nix package above, but adds some boilerplate to build it directly from an expression.
+- `rootPaths` specifies a list of root derivations. The transitive closure of these derivations' outputs will be copied into the cache.
+
+Here's an example of building and using the cache.
+
+Build the cache on one machine, `host1`:
 
 ```shellSession
-$ nix-build -E 'let pkgs = import <nixpkgs> {}; in pkgs.callPackage ({ mkBinaryCache, hello }: mkBinaryCache { rootPaths = [hello]; }) {}'
-/nix/store/azf7xay5xxdnia4h9fyjiv59wsjdxl0g-binary-cache
+nix-build -E 'with import <nixpkgs> {}; mkBinaryCache { rootPaths = [hello]; }'
 ```
 
-Copy the resulting directory to another machine, which we'll call `host2`:
-
 ```shellSession
-$ scp result host2:/tmp/hello-cache
+/nix/store/cc0562q828rnjqjyfj23d5q162gb424g-binary-cache
 ```
 
-At this point, the cache can be used as a substituter when building derivations on `host2`:
+Copy the resulting directory to the other machine, `host2`:
 
 ```shellSession
-$ nix-build -A hello '<nixpkgs>' \
+scp result host2:/tmp/hello-cache
+```
+
+Substitute the derivation using the flat-file binary cache on the other machine, `host2`:
+```shellSession
+nix-build -A hello '<nixpkgs>' \
   --option require-sigs false \
   --option trusted-substituters file:///tmp/hello-cache \
   --option substituters file:///tmp/hello-cache
-/nix/store/zhl06z4lrfrkw5rp0hnjjfrgsclzvxpm-hello-2.12.1
 ```
 
-:::
+```shellSession
+/nix/store/gl5a41azbpsadfkfmbilh9yk40dh5dl0-hello-2.12.1
+```

doc/build-helpers/images/ocitools.section.md

@@ -1,104 +1,37 @@
 # pkgs.ociTools {#sec-pkgs-ociTools}
 
-`pkgs.ociTools` is a set of functions for creating runtime container bundles according to the [OCI runtime specification v1.0.0](https://github.com/opencontainers/runtime-spec/blob/v1.0.0/spec.md).
-It makes no assumptions about the container runner you choose to use to run the created container.
-
-The set of functions in `pkgs.ociTools` currently does not handle the [OCI image specification](https://github.com/opencontainers/image-spec).
-
-At a high-level an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle.
-At this point the OCI Runtime Bundle would be run by an OCI Runtime.
-`pkgs.ociTools` provides utilities to create OCI Runtime bundles.
+`pkgs.ociTools` is a set of functions for creating containers according to the [OCI container specification v1.0.0](https://github.com/opencontainers/runtime-spec). Beyond that, it makes no assumptions about the container runner you choose to use to run the created container.
 
 ## buildContainer {#ssec-pkgs-ociTools-buildContainer}
 
-This function creates an OCI runtime container (consisting of a `config.json` and a root filesystem directory) that runs a single command inside of it.
-The nix store of the container will contain all referenced dependencies of the given command.
+This function creates a simple OCI container that runs a single command inside of it. An OCI container consists of a `config.json` and a rootfs directory. The nix store of the container will contain all referenced dependencies of the given command.
 
-This function has an assumption that the container will run on POSIX platforms, and sets configurations (such as the user running the process or certain mounts) according to this assumption.
-Because of this, a container built with `buildContainer` will not work on Windows or other non-POSIX platforms without modifications to the container configuration.
-These modifications aren't supported by `buildContainer`.
-
-For `linux` platforms, `buildContainer` also configures the following namespaces (see {manpage}`unshare(1)`) to isolate the OCI container from the global namespace:
-PID, network, mount, IPC, and UTS.
-
-Note that no user namespace is created, which means that you won't be able to run the container unless you are the `root` user.
-
-### Inputs {#ssec-pkgs-ociTools-buildContainer-inputs}
-
-`buildContainer` expects an argument with the following attributes:
-
-`args` (List of String)
-
-: Specifies a set of arguments to run inside the container.
-  Any packages referenced by `args` will be made available inside the container.
-
-`mounts` (Attribute Set; _optional_)
-
-: Would specify additional mounts that the runtime must make available to the container.
-
-  :::{.warning}
-  As explained in [issue #290879](https://github.com/NixOS/nixpkgs/issues/290879), this attribute is currently ignored.
-  :::
-
-  :::{.note}
-  `buildContainer` includes a minimal set of necessary filesystems to be mounted into the container, and this set can't be changed with the `mounts` attribute.
-  :::
-
-  _Default value:_ `{}`.
-
-`readonly` (Boolean; _optional_)
-
-: If `true`, sets the container's root filesystem as read-only.
-
-  _Default value:_ `false`.
-
-`os` **DEPRECATED**
-
-: Specifies the operating system on which the container filesystem is based on.
-  If specified, its value should follow the [OCI Image Configuration Specification](https://github.com/opencontainers/image-spec/blob/main/config.md#properties).
-  According to the linked specification, all possible values for `$GOOS` in [the Go docs](https://go.dev/doc/install/source#environment) should be valid, but will commonly be one of `darwin` or `linux`.
-
-  _Default value:_ `"linux"`.
-
-`arch` **DEPRECATED**
-
-: Used to specify the architecture for which the binaries in the container filesystem have been compiled.
-  If specified, its value should follow the [OCI Image Configuration Specification](https://github.com/opencontainers/image-spec/blob/main/config.md#properties).
-  According to the linked specification, all possible values for `$GOARCH` in [the Go docs](https://go.dev/doc/install/source#environment) should be valid, but will commonly be one of `386`, `amd64`, `arm`, or `arm64`.
-
-  _Default value:_ `x86_64`.
-
-### Examples {#ssec-pkgs-ociTools-buildContainer-examples}
-
-::: {.example #ex-ociTools-buildContainer-bash}
-# Creating an OCI runtime container that runs `bash`
-
-This example uses `ociTools.buildContainer` to create a simple container that runs `bash`.
+The parameters of `buildContainer` with an example value are described below:
 
 ```nix
-{ ociTools, lib, bash }:
-ociTools.buildContainer {
+buildContainer {
   args = [
-    (lib.getExe bash)
+    (with pkgs;
+      writeScript "run.sh" ''
+        #!${bash}/bin/bash
+        exec ${bash}/bin/bash
+      '').outPath
   ];
 
+  mounts = {
+    "/data" = {
+      type = "none";
+      source = "/var/lib/mydata";
+      options = [ "bind" ];
+    };
+  };
+
   readonly = false;
 }
 ```
 
-As an example of how to run the container generated by this package, we'll use `runc` to start the container.
-Any other tool that supports OCI containers could be used instead.
+- `args` specifies a set of arguments to run inside the container. This is the only required argument for `buildContainer`. All referenced packages inside the derivation will be made available inside the container.
 
-```shell
-$ nix-build
-(some output removed for clarity)
-/nix/store/7f9hgx0arvhzp2a3qphp28rxbn748l25-join
+- `mounts` specifies additional mount points chosen by the user. By default only a minimal set of necessary filesystems are mounted into the container (e.g procfs, cgroupfs)
 
-$ cd /nix/store/7f9hgx0arvhzp2a3qphp28rxbn748l25-join
-$ nix-shell -p runc
-[nix-shell:/nix/store/7f9hgx0arvhzp2a3qphp28rxbn748l25-join]$ sudo runc run ocitools-example
-help
-GNU bash, version 5.2.26(1)-release (x86_64-pc-linux-gnu)
-(some output removed for clarity)
-```
-:::
+- `readonly` makes the container's rootfs read-only if it is set to true. The default value is false `false`.

doc/build-helpers/images/portableservice.section.md

@@ -1,174 +1,81 @@
 # pkgs.portableService {#sec-pkgs-portableService}
 
-`pkgs.portableService` is a function to create [Portable Services](https://systemd.io/PORTABLE_SERVICES/) in a read-only, immutable, `squashfs` raw disk image.
-This lets you use Nix to build images which can be run on many recent Linux distributions.
+`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).
 :::
 
-The generated image will contain the file system structure as required by the Portable Services specification, along with the packages given to `portableService` and all of their dependencies.
-When generated, the image will exist in the Nix store with the `.raw` file extension, as required by the specification.
-See [](#ex-portableService-hello) to understand how to use the output of `portableService`.
-
-## Inputs {#ssec-pkgs-portableService-inputs}
-
-`portableService` expects one argument with the following attributes:
-
-`pname` (String)
-
-: The name of the portable service.
-  The generated image will be named according to the template `$pname_$version.raw`, which is supported by the Portable Services specification.
-
-`version` (String)
-
-: The version of the portable service.
-  The generated image will be named according to the template `$pname_$version.raw`, which is supported by the Portable Services specification.
-
-`units` (List of Attribute Set)
-
-: A list of derivations for systemd unit files.
-  Each derivation must produce a single file, and must have a name that starts with the value of `pname` and ends with the suffix of the unit type (e.g. ".service", ".socket", ".timer", and so on).
-  See [](#ex-portableService-hello) to better understand this naming constraint.
-
-`description` (String or Null; _optional_)
-
-: If specified, the value is added as `PORTABLE_PRETTY_NAME` to the `/etc/os-release` file in the generated image.
-  This could be used to provide more information to anyone inspecting the image.
-
-  _Default value:_ `null`.
-
-`homepage` (String or Null; _optional_)
-
-: If specified, the value is added as `HOME_URL` to the `/etc/os-release` file in the generated image.
-  This could be used to provide more information to anyone inspecting the image.
-
-  _Default value:_ `null`.
-
-`symlinks` (List of Attribute Set; _optional_)
-
-: A list of attribute sets in the format `{object, symlink}`.
-  For each item in the list, `portableService` will create a symlink in the path specified by `symlink` (relative to the root of the image) that points to `object`.
-
-  All packages that `object` depends on and their dependencies are automatically copied into the image.
-
-  This can be used to create symlinks for applications that assume some files to exist globally (`/etc/ssl` or `/bin/bash`, for example).
-  See [](#ex-portableService-symlinks) to understand how to do that.
-
-  _Default value:_ `[]`.
-
-`contents` (List of Attribute Set; _optional_)
-
-: A list of additional derivations to be included as-is in the image.
-  These derivations will be included directly in a `/nix/store` directory inside the image.
-
-  _Default value:_ `[]`.
-
-`squashfsTools` (Attribute Set; _optional_)
-
-: Allows you to override the package that provides {manpage}`mksquashfs(1)`, which is used internally by `portableService`.
-
-  _Default value:_ `pkgs.squashfsTools`.
-
-`squash-compression` (String; _optional_)
-
-: Passed as the compression option to {manpage}`mksquashfs(1)`, which is used internally by `portableService`.
-
-  _Default value:_ `"xz -Xdict-size 100%"`.
-
-`squash-block-size` (String; _optional_)
-
-: Passed as the block size option to {manpage}`mksquashfs(1)`, which is used internally by `portableService`.
-
-  _Default value:_ `"1M"`.
-
-## Examples {#ssec-pkgs-portableService-examples}
+A very simple example of using `portableService` is described below:
 
 []{#ex-pkgs-portableService}
-:::{.example #ex-portableService-hello}
-# Building a Portable Service image
-
-The following example builds a Portable Service image with the `hello` package, along with a service unit that runs it.
 
 ```nix
-{ lib, writeText, portableService, hello }:
-let
-  hello-service = writeText "hello.service" ''
-    [Unit]
-    Description=Hello world service
-
-    [Service]
-    Type=oneshot
-    ExecStart=${lib.getExe hello}
-  '';
-in
-portableService {
-  pname = "hello";
-  inherit (hello) version;
-  units = [ hello-service ];
+pkgs.portableService {
+  pname = "demo";
+  version = "1.0";
+  units = [ demo-service demo-socket ];
 }
 ```
 
-After building the package, the generated image can be loaded into a system through {manpage}`portablectl(1)`:
+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.
 
-```shell
-$ nix-build
-(some output removed for clarity)
-/nix/store/8c20z1vh7z8w8dwagl8w87b45dn5k6iq-hello-img-2.12.1
-
-$ portablectl attach /nix/store/8c20z1vh7z8w8dwagl8w87b45dn5k6iq-hello-img-2.12.1/hello_2.12.1.raw
-Created directory /etc/systemd/system.attached.
-Created directory /etc/systemd/system.attached/hello.service.d.
-Written /etc/systemd/system.attached/hello.service.d/20-portable.conf.
-Created symlink /etc/systemd/system.attached/hello.service.d/10-profile.conf → /usr/lib/systemd/portable/profile/default/service.conf.
-Copied /etc/systemd/system.attached/hello.service.
-Created symlink /etc/portables/hello_2.12.1.raw → /nix/store/8c20z1vh7z8w8dwagl8w87b45dn5k6iq-hello-img-2.12.1/hello_2.12.1.raw.
-
-$ systemctl start hello
-$ journalctl -u hello
-Feb 28 22:39:16 hostname systemd[1]: Starting Hello world service...
-Feb 28 22:39:16 hostname hello[102887]: Hello, world!
-Feb 28 22:39:16 hostname systemd[1]: hello.service: Deactivated successfully.
-Feb 28 22:39:16 hostname systemd[1]: Finished Hello world service.
-
-$ portablectl detach hello_2.12.1
-Removed /etc/systemd/system.attached/hello.service.
-Removed /etc/systemd/system.attached/hello.service.d/10-profile.conf.
-Removed /etc/systemd/system.attached/hello.service.d/20-portable.conf.
-Removed /etc/systemd/system.attached/hello.service.d.
-Removed /etc/portables/hello_2.12.1.raw.
-Removed /etc/systemd/system.attached.
-```
+::: {.note}
+The `.raw` file extension of the image is required by the portable services specification.
 :::
 
-:::{.example #ex-portableService-symlinks}
-# Specifying symlinks when building a Portable Service image
+Some other options available are:
+- `description`, `homepage`
 
-Some services may expect files or directories to be available globally.
-An example is a service which expects all trusted SSL certificates to exist in a specific location by default.
+  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`
 
-To make things available globally, you must specify the `symlinks` attribute when using `portableService`.
-The following package builds on the package from [](#ex-portableService-hello) to make `/etc/ssl` available globally (this is only for illustrative purposes, because `hello` doesn't use `/etc/ssl`).
+  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
-{ lib, writeText, portableService, hello, cacert }:
-let
-  hello-service = writeText "hello.service" ''
-    [Unit]
-    Description=Hello world service
-
-    [Service]
-    Type=oneshot
-    ExecStart=${lib.getExe hello}
-  '';
-in
-portableService {
-  pname = "hello";
-  inherit (hello) version;
-  units = [ hello-service ];
   symlinks = [
-    { object = "${cacert}/etc/ssl"; symlink = "/etc/ssl"; }
+    { 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/build-helpers/images/snaptools.section.md

@@ -0,0 +1,71 @@
+# pkgs.snapTools {#sec-pkgs-snapTools}
+
+`pkgs.snapTools` is a set of functions for creating Snapcraft images. Snap and Snapcraft is not used to perform these operations.
+
+## The makeSnap Function {#ssec-pkgs-snapTools-makeSnap-signature}
+
+`makeSnap` takes a single named argument, `meta`. This argument mirrors [the upstream `snap.yaml` format](https://docs.snapcraft.io/snap-format) exactly.
+
+The `base` should not be specified, as `makeSnap` will force set it.
+
+Currently, `makeSnap` does not support creating GUI stubs.
+
+## Build a Hello World Snap {#ssec-pkgs-snapTools-build-a-snap-hello}
+
+The following expression packages GNU Hello as a Snapcraft snap.
+
+``` {#ex-snapTools-buildSnap-hello .nix}
+let
+  inherit (import <nixpkgs> { }) snapTools hello;
+in snapTools.makeSnap {
+  meta = {
+    name = "hello";
+    summary = hello.meta.description;
+    description = hello.meta.longDescription;
+    architectures = [ "amd64" ];
+    confinement = "strict";
+    apps.hello.command = "${hello}/bin/hello";
+  };
+}
+```
+
+`nix-build` this expression and install it with `snap install ./result --dangerous`. `hello` will now be the Snapcraft version of the package.
+
+## Build a Graphical Snap {#ssec-pkgs-snapTools-build-a-snap-firefox}
+
+Graphical programs require many more integrations with the host. This example uses Firefox as an example because it is one of the most complicated programs we could package.
+
+``` {#ex-snapTools-buildSnap-firefox .nix}
+let
+  inherit (import <nixpkgs> { }) snapTools firefox;
+in snapTools.makeSnap {
+  meta = {
+    name = "nix-example-firefox";
+    summary = firefox.meta.description;
+    architectures = [ "amd64" ];
+    apps.nix-example-firefox = {
+      command = "${firefox}/bin/firefox";
+      plugs = [
+        "pulseaudio"
+        "camera"
+        "browser-support"
+        "avahi-observe"
+        "cups-control"
+        "desktop"
+        "desktop-legacy"
+        "gsettings"
+        "home"
+        "network"
+        "mount-observe"
+        "removable-media"
+        "x11"
+      ];
+    };
+    confinement = "strict";
+  };
+}
+```
+
+`nix-build` this expression and install it with `snap install ./result --dangerous`. `nix-example-firefox` will now be the Snapcraft version of the Firefox package.
+
+The specific meaning behind plugs can be looked up in the [Snapcraft interface documentation](https://docs.snapcraft.io/supported-interfaces).

doc/build-helpers/special.md

@@ -3,10 +3,8 @@
 This chapter describes several special build helpers.
 
 ```{=include=} sections
-special/fakenss.section.md
 special/fhs-environments.section.md
 special/makesetuphook.section.md
 special/mkshell.section.md
 special/vm-tools.section.md
-special/checkpoint-build.section.md
 ```

doc/build-helpers/special/checkpoint-build.section.md

@@ -1,43 +0,0 @@
-# pkgs.checkpointBuildTools  {#sec-checkpoint-build}
-
-`pkgs.checkpointBuildTools` provides a way to build derivations incrementally. It consists of two functions to make checkpoint builds using Nix possible.
-
-For hermeticity, Nix derivations do not allow any state to be carried over between builds, making a transparent incremental build within a derivation impossible.
-
-However, we can tell Nix explicitly what the previous build state was, by representing that previous state as a derivation output. This allows the passed build state to be used for an incremental build.
-
-To change a normal derivation to a checkpoint based build, these steps must be taken:
-  - apply `prepareCheckpointBuild` on the desired derivation, e.g.
-```nix
-{
-  checkpointArtifacts = (pkgs.checkpointBuildTools.prepareCheckpointBuild pkgs.virtualbox);
-}
-```
-  - change something you want in the sources of the package, e.g. use a source override:
-```nix
-{
-  changedVBox = pkgs.virtualbox.overrideAttrs (old: {
-    src = path/to/vbox/sources;
-  });
-}
-```
-  - use `mkCheckpointBuild changedVBox checkpointArtifacts`
-  - enjoy shorter build times
-
-## Example {#sec-checkpoint-build-example}
-```nix
-{ pkgs ? import <nixpkgs> {} }:
-let
-  inherit (pkgs.checkpointBuildTools)
-    prepareCheckpointBuild
-    mkCheckpointBuild
-    ;
-  helloCheckpoint = prepareCheckpointBuild pkgs.hello;
-  changedHello = pkgs.hello.overrideAttrs (_: {
-    doCheck = false;
-    patchPhase = ''
-      sed -i 's/Hello, world!/Hello, Nix!/g' src/hello.c
-    '';
-  });
-in mkCheckpointBuild changedHello helloCheckpoint
-```

doc/build-helpers/special/fakenss.section.md

@@ -1,77 +0,0 @@
-# fakeNss {#sec-fakeNss}
-
-Provides `/etc/passwd` and `/etc/group` files that contain `root` and `nobody`, allowing user/group lookups to work in binaries that insist on doing those.
-This might be a better choice than a custom script running `useradd` and related utilities if you only need those files to exist with some entries.
-
-`fakeNss` also provides `/etc/nsswitch.conf`, configuring NSS host resolution to first check `/etc/hosts` before checking DNS, since the default in the absence of a config file (`dns [!UNAVAIL=return] files`) is quite unexpected.
-
-It also creates an empty directory at `/var/empty` because it uses that as the home directory for the `root` and `nobody` users.
-The `/var/empty` directory can also be used as a `chroot` target to prevent file access in processes that do not need to access files, if your container runs such processes.
-
-The user entries created by `fakeNss` use the `/bin/sh` shell, which is not provided by `fakeNss` because in most cases it won't be used.
-If you need that to be available, see [`dockerTools.binSh`](#sssec-pkgs-dockerTools-helpers-binSh) or provide your own.
-
-## Inputs {#sec-fakeNss-inputs}
-
-`fakeNss` is made available in Nixpkgs as a package rather than a function, but it has two attributes that can be overridden and might be useful in particular cases.
-For more details on how overriding works, see [](#ex-fakeNss-overriding) and [](#sec-pkg-override).
-
-`extraPasswdLines` (List of Strings; _optional_)
-
-: A list of lines that will be added to `/etc/passwd`.
-  Useful if extra users need to exist in the output of `fakeNss`.
-  If `extraPasswdLines` is specified, it will **not** override the `root` and `nobody` entries created by `fakeNss`.
-  Those entries will always exist.
-
-  Lines specified here must follow the format in {manpage}`passwd(5)`.
-
-  _Default value:_ `[]`.
-
-`extraGroupLines` (List of Strings; _optional_)
-
-: A list of lines that will be added to `/etc/group`.
-  Useful if extra groups need to exist in the output of `fakeNss`.
-  If `extraGroupLines` is specified, it will **not** override the `root` and `nobody` entries created by `fakeNss`.
-  Those entries will always exist.
-
-  Lines specified here must follow the format in {manpage}`group(5)`.
-
-  _Default value:_ `[]`.
-
-## Examples {#sec-fakeNss-examples}
-
-:::{.example #ex-fakeNss-dockerTools-buildImage}
-# Using `fakeNss` with `dockerTools.buildImage`
-
-This example shows how to use `fakeNss` as-is.
-It is useful with functions in `dockerTools` to allow building Docker images that have the `/etc/passwd` and `/etc/group` files.
-This example includes the `hello` binary in the image so it can do something besides just have the extra files.
-
-```nix
-{ dockerTools, fakeNss, hello }:
-dockerTools.buildImage {
-  name = "image-with-passwd";
-  tag = "latest";
-
-  copyToRoot = [ fakeNss hello ];
-
-  config = {
-    Cmd = [ "/bin/hello" ];
-  };
-}
-```
-:::
-
-:::{.example #ex-fakeNss-overriding}
-# Using `fakeNss` with an override to add extra lines
-
-The following code uses `override` to add extra lines to `/etc/passwd` and `/etc/group` to create another user and group entry.
-
-```nix
-{ fakeNss }:
-fakeNss.override {
-  extraPasswdLines = ["newuser:x:9001:9001:new user:/var/empty:/bin/sh"];
-  extraGroupLines = ["newuser:x:9001:"];
-}
-```
-:::

doc/build-helpers/special/fhs-environments.section.md

@@ -6,11 +6,7 @@ It uses Linux' namespaces feature to create temporary lightweight environments w
 Accepted arguments are:
 
 - `name`
-        The name of the environment, and the wrapper executable if `pname` is unset.
-- `pname`
-        The pname of the environment and the wrapper executable.
-- `version`
-        The version of the environment.
+        The name of the environment and the wrapper executable.
 - `targetPkgs`
         Packages to be installed for the main host's architecture (i.e. x86_64 on x86_64 installations). Along with libraries binaries are also installed.
 - `multiPkgs`
@@ -57,4 +53,4 @@ You can create a simple environment using a `shell.nix` like this:
 Running `nix-shell` on it would drop you into a shell inside an FHS env where those libraries and binaries are available in FHS-compliant paths. Applications that expect an FHS structure (i.e. proprietary binaries) can run inside this environment without modification.
 You can build a wrapper by running your binary in `runScript`, e.g. `./bin/start.sh`. Relative paths work as expected.
 
-Additionally, the FHS builder links all relocated gsettings-schemas (the glib setup-hook moves them to `share/gsettings-schemas/${name}/glib-2.0/schemas`) to their standard FHS location. This means you don't need to wrap binaries with `wrapGApps*` hook.
+Additionally, the FHS builder links all relocated gsettings-schemas (the glib setup-hook moves them to `share/gsettings-schemas/${name}/glib-2.0/schemas`) to their standard FHS location. This means you don't need to wrap binaries with `wrapGAppsHook`.

doc/build-helpers/special/mkshell.section.md

@@ -29,10 +29,6 @@ pkgs.mkShell {
 
 ... all the attributes of `stdenv.mkDerivation`.
 
-## Variants {#sec-pkgs-mkShell-variants}
-
-`pkgs.mkShellNoCC` is a variant that uses `stdenvNoCC` instead of `stdenv` as base environment. This is useful if no C compiler is needed in the shell environment.
-
 ## Building the shell {#sec-pkgs-mkShell-building}
 
 This derivation output will contain a text file that contains a reference to

doc/build-helpers/testers.chapter.md

@@ -1,5 +1,4 @@
 # Testers {#chap-testers}
-
 This chapter describes several testing builders which are available in the `testers` namespace.
 
 ## `hasPkgConfigModules` {#tester-hasPkgConfigModules}
@@ -7,164 +6,62 @@ This chapter describes several testing builders which are available in the `test
 <!-- Old anchor name so links still work -->
 []{#tester-hasPkgConfigModule}
 Checks whether a package exposes a given list of `pkg-config` modules.
-If the `moduleNames` argument is omitted, `hasPkgConfigModules` will use `meta.pkgConfigModules`.
+If the `moduleNames` argument is omitted, `hasPkgConfigModules` will
+use `meta.pkgConfigModules`.
 
-:::{.example #ex-haspkgconfigmodules-defaultvalues}
-
-# Check that `pkg-config` modules are exposed using default values
+Example:
 
 ```nix
-{
-  passthru.tests.pkg-config = testers.hasPkgConfigModules {
-    package = finalAttrs.finalPackage;
-  };
-
-  meta.pkgConfigModules = [ "libfoo" ];
-}
+passthru.tests.pkg-config = testers.hasPkgConfigModules {
+  package = finalAttrs.finalPackage;
+  moduleNames = [ "libfoo" ];
+};
 ```
 
-:::
-
-:::{.example #ex-haspkgconfigmodules-explicitmodules}
-
-# Check that `pkg-config` modules are exposed using explicit module names
+If the package in question has `meta.pkgConfigModules` set, it is even simpler:
 
 ```nix
-{
-  passthru.tests.pkg-config = testers.hasPkgConfigModules {
-    package = finalAttrs.finalPackage;
-    moduleNames = [ "libfoo" ];
-  };
-}
+passthru.tests.pkg-config = testers.hasPkgConfigModules {
+  package = finalAttrs.finalPackage;
+};
+
+meta.pkgConfigModules = [ "libfoo" ];
 ```
 
-:::
-
-## `lycheeLinkCheck` {#tester-lycheeLinkCheck}
-
-Check a packaged static site's links with the [`lychee` package](https://search.nixos.org/packages?show=lychee&type=packages&query=lychee).
-
-You may use Nix to reproducibly build static websites, such as for software documentation.
-Some packages will install documentation in their `out` or `doc` outputs, or maybe you have dedicated package where you've made your static site reproducible by running a generator, such as [Hugo](https://gohugo.io/) or [mdBook](https://rust-lang.github.io/mdBook/), in a derivation.
-
-If you have a static site that can be built with Nix, you can use `lycheeLinkCheck` to check that the hyperlinks in your site are correct, and do so as part of your Nix workflow and CI.
-
-:::{.example #ex-lycheelinkcheck}
-
-# Check hyperlinks in the `nix` documentation
-
-```nix
-testers.lycheeLinkCheck {
-  site = nix.doc + "/share/doc/nix/manual";
-}
-```
-
-:::
-
-### Return value {#tester-lycheeLinkCheck-return}
-
-This tester produces a package that does not produce useful outputs, but only succeeds if the hyperlinks in your site are correct. The build log will list the broken links.
-
-It has two modes:
-
-- Build the returned derivation; its build process will check that internal hyperlinks are correct. This runs in the sandbox, so it will not check external hyperlinks, but it is quick and reliable.
-
-- Invoke the `.online` attribute with [`nix run`](https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-run) ([experimental](https://nixos.org/manual/nix/stable/contributing/experimental-features#xp-feature-nix-command)). This runs outside the sandbox, and checks that both internal and external hyperlinks are correct.
-  Example:
-
-  ```shell
-  nix run nixpkgs#lychee.tests.ok.online
-  ```
-
-### Inputs {#tester-lycheeLinkCheck-inputs}
-
-`site` (path or derivation) {#tester-lycheeLinkCheck-param-site}
-
-: The path to the files to check.
-
-`remap` (attribe set, optional) {#tester-lycheeLinkCheck-param-remap}
-
-: An attribute set where the attribute names are regular expressions.
-  The values should be strings, derivations, or path values.
-
-  In the returned check's default configuration, external URLs are only checked when you run the `.online` attribute.
-
-  By adding remappings, you can check offline that URLs to external resources are correct, by providing a stand-in from the file system.
-
-  Before checking the existence of a URL, the regular expressions are matched and replaced by their corresponding values.
-
-  Example:
-
-  ```nix
-  {
-    "https://nix\\.dev/manual/nix/[a-z0-9.-]*" = "${nix.doc}/share/doc/nix/manual";
-    "https://nixos\\.org/manual/nix/(un)?stable" = "${emptyDirectory}/placeholder-to-disallow-old-nix-docs-urls";
-  }
-  ```
-
-  Store paths in the attribute values are automatically prefixed with `file://`, because lychee requires this for paths in the file system.
-  If this is a problem, or if you need to control the order in which replacements are performed, use `extraConfig.remap` instead.
-
-`extraConfig` (attribute set) {#tester-lycheeLinkCheck-param-extraConfig}
-
-: Extra configuration to pass to `lychee` in its [configuration file](https://github.com/lycheeverse/lychee/blob/master/lychee.example.toml).
-  It is automatically [translated](https://nixos.org/manual/nixos/stable/index.html#sec-settings-nix-representable) to TOML.
-
-  Example: `{ "include_verbatim" = true; }`
-
-`lychee` (derivation, optional) {#tester-lycheeLinkCheck-param-lychee}
-
-: The `lychee` package to use.
-
 ## `testVersion` {#tester-testVersion}
 
-Checks that the output from running a command contains the specified version string in it as a whole word.
+Checks the command output contains the specified version
 
-Although simplistic, this test assures that the main program can run.
-While there's no substitute for a real test case, it does catch dynamic linking errors and such.
-It also provides some protection against accidentally building the wrong version, for example when using an "old" hash in a fixed-output derivation.
+Although simplistic, this test assures that the main program
+can run. While there's no substitute for a real test case,
+it does catch dynamic linking errors and such. It also provides
+some protection against accidentally building the wrong version,
+for example when using an 'old' hash in a fixed-output derivation.
 
-By default, the command to be run will be inferred from the given `package` attribute:
-it will check `meta.mainProgram` first, and fall back to `pname` or `name`.
-The default argument to the command is `--version`, and the version to be checked will be inferred from the given `package` attribute as well.
-
-:::{.example #ex-testversion-hello}
-
-# Check a program version using all the default values
-
-This example will run the command `hello --version`, and then check that the version of the `hello` package is in the output of the command.
+Examples:
 
 ```nix
-{
-  passthru.tests.version = testers.testVersion { package = hello; };
-}
+passthru.tests.version = testers.testVersion { package = hello; };
+
+passthru.tests.version = testers.testVersion {
+  package = seaweedfs;
+  command = "weed version";
+};
+
+passthru.tests.version = testers.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}";
+};
 ```
 
-:::
-
-:::{.example #ex-testversion-different-commandversion}
-
-# Check the program version using a specified command and expected version string
-
-This example will run the command `leetcode -V`, and then check that `leetcode 0.4.2` is in the output of the command as a whole word (separated by whitespaces).
-This means that an output like "leetcode 0.4.21" would fail the tests, and an output like "You're running leetcode 0.4.2" would pass the tests.
-
-A common usage of the `version` attribute is to specify `version = "v${version}"`.
-
-```nix
-{
-  version = "0.4.2";
-
-  passthru.tests.version = testers.testVersion {
-    package = leetcode-cli;
-    command = "leetcode -V";
-    version = "leetcode ${version}";
-  };
-}
-```
-
-:::
-
 ## `testBuildFailure` {#tester-testBuildFailure}
 
 Make sure that a build does not succeed. This is useful for testing testers.
@@ -175,18 +72,7 @@ This returns a derivation with an override on the builder, with the following ef
  - Move `$out` to `$out/result`, if it exists (assuming `out` is the default output)
  - Save the build log to `$out/testBuildFailure.log` (same)
 
-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.
-
-:::{.example #ex-testBuildFailure-showingenvironmentchanges}
-
-# Check that a build fails, and verify the changes made during build
+Example:
 
 ```nix
 runCommand "example" {
@@ -200,18 +86,27 @@ runCommand "example" {
   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.
 
-## `testEqualContents` {#tester-testEqualContents}
+ - 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 #ex-testEqualContents-toyexample}
-
-# Check that two paths have the same contents
+Example:
 
 ```nix
 testers.testEqualContents {
@@ -231,20 +126,17 @@ testers.testEqualContents {
 }
 ```
 
-:::
-
 ## `testEqualDerivation` {#tester-testEqualDerivation}
 
 Checks that two packages produce the exact same build instructions.
 
-This can be used to make sure that a certain difference of configuration, such as the presence of an overlay does not cause a cache miss.
+This can be used to make sure that a certain difference of configuration,
+such as the presence of an overlay does not cause a cache miss.
 
 When the derivations are equal, the return value is an empty file.
 Otherwise, the build log explains the difference via `nix-diff`.
 
-:::{.example #ex-testEqualDerivation-hello}
-
-# Check that two packages produce the same derivation
+Example:
 
 ```nix
 testers.testEqualDerivation
@@ -253,51 +145,46 @@ testers.testEqualDerivation
   (hello.overrideAttrs(o: { doCheck = true; }))
 ```
 
-:::
-
 ## `invalidateFetcherByDrvHash` {#tester-invalidateFetcherByDrvHash}
 
 Use the derivation hash to invalidate the output via name, for testing.
 
 Type: `(a@{ name, ... } -> Derivation) -> a -> Derivation`
 
-Normally, fixed output derivations can and should be cached by their output hash only, but for testing we want to re-fetch everytime the fetcher changes.
+Normally, fixed output derivations can and should be cached by their output
+hash only, but for testing we want to re-fetch everytime the fetcher changes.
 
-Changes to the fetcher become apparent in the drvPath, which is a hash of how to fetch, rather than a fixed store path.
-By inserting this hash into the name, we can make sure to re-run the fetcher every time the fetcher changes.
+Changes to the fetcher become apparent in the drvPath, which is a hash of
+how to fetch, rather than a fixed store path.
+By inserting this hash into the name, we can make sure to re-run the fetcher
+every time the fetcher changes.
 
-This relies on the assumption that Nix isn't clever enough to reuse its database of local store contents to optimize fetching.
+This relies on the assumption that Nix isn't clever enough to reuse its
+database of local store contents to optimize fetching.
 
-You might notice that the "salted" name derives from the normal invocation, not the final derivation.
-`invalidateFetcherByDrvHash` has to invoke the fetcher function twice:
-once to get a derivation hash, and again to produce the final fixed output derivation.
+You might notice that the "salted" name derives from the normal invocation,
+not the final derivation. `invalidateFetcherByDrvHash` has to invoke the fetcher
+function twice: once to get a derivation hash, and again to produce the final
+fixed output derivation.
 
-:::{.example #ex-invalidateFetcherByDrvHash-nix}
-
-# Prevent nix from reusing the output of a fetcher
+Example:
 
 ```nix
-{
-  tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
-    name = "nix-source";
-    url = "https://github.com/NixOS/nix";
-    rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a";
-    hash = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
-  };
-}
+tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
+  name = "nix-source";
+  url = "https://github.com/NixOS/nix";
+  rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a";
+  hash = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
+};
 ```
 
-:::
-
 ## `runNixOSTest` {#tester-runNixOSTest}
 
 A helper function that behaves exactly like the NixOS `runTest`, except it also assigns this Nixpkgs package set as the `pkgs` of the test and makes the `nixpkgs.*` options read-only.
 
 If your test is part of the Nixpkgs repository, or if you need a more general entrypoint, see ["Calling a test" in the NixOS manual](https://nixos.org/manual/nixos/stable/index.html#sec-calling-nixos-tests).
 
-:::{.example #ex-runNixOSTest-hello}
-
-# Run a NixOS test using `runNixOSTest`
+Example:
 
 ```nix
 pkgs.testers.runNixOSTest ({ lib, ... }: {
@@ -311,17 +198,19 @@ pkgs.testers.runNixOSTest ({ lib, ... }: {
 })
 ```
 
-:::
-
 ## `nixosTest` {#tester-nixosTest}
 
 Run a NixOS VM network test using this evaluation of Nixpkgs.
 
 NOTE: This function is primarily for external use. NixOS itself uses `make-test-python.nix` directly. Packages defined in Nixpkgs [reuse NixOS tests via `nixosTests`, plural](#ssec-nixos-tests-linking).
 
-It is mostly equivalent to the function `import ./make-test-python.nix` from the [NixOS manual](https://nixos.org/nixos/manual/index.html#sec-nixos-tests), except that the current application of Nixpkgs (`pkgs`) will be used, instead of letting NixOS invoke Nixpkgs anew.
+It is mostly equivalent to the function `import ./make-test-python.nix` from the
+[NixOS manual](https://nixos.org/nixos/manual/index.html#sec-nixos-tests),
+except that the current application of Nixpkgs (`pkgs`) will be used, instead of
+letting NixOS invoke Nixpkgs anew.
 
-If a test machine needs to set NixOS options under `nixpkgs`, it must set only the `nixpkgs.pkgs` option.
+If a test machine needs to set NixOS options under `nixpkgs`, it must set only the
+`nixpkgs.pkgs` option.
 
 ### Parameter {#tester-nixosTest-parameter}
 

doc/build-helpers/trivial-build-helpers.chapter.md

@@ -1,15 +1,12 @@
 # Trivial build helpers {#chap-trivial-builders}
 
-Nixpkgs provides a variety of wrapper functions that help build commonly useful derivations.
-Like [`stdenv.mkDerivation`](#sec-using-stdenv), each of these build helpers creates a derivation, but the arguments passed are different (usually simpler) from those required by `stdenv.mkDerivation`.
+Nixpkgs provides a couple of functions that help with building derivations. The most important one, `stdenv.mkDerivation`, has already been documented above. The following functions wrap `stdenv.mkDerivation`, making it easier to use in certain cases.
 
 ## `runCommand` {#trivial-builder-runCommand}
 
 `runCommand :: String -> AttrSet -> String -> Derivation`
 
-The result of `runCommand name drvAttrs buildCommand` is a derivation that is built by running the specified shell commands.
-
-By default `runCommand` runs in a stdenv with no compiler environment, whereas [`runCommandCC`](#trivial-builder-runCommandCC) uses the default stdenv, `pkgs.stdenv`.
+`runCommand name drvAttrs buildCommand` returns a derivation that is built by running the specified shell commands.
 
 `name :: String`
 :   The name that Nix will append to the store path in the same way that `stdenv.mkDerivation` uses its `name` attribute.
@@ -61,525 +58,63 @@ Variant of `runCommand` that forces the derivation to be built locally, it is no
 This sets [`allowSubstitutes` to `false`](https://nixos.org/nix/manual/#adv-attr-allowSubstitutes), so only use `runCommandLocal` if you are certain the user will always have a builder for the `system` of the derivation. This should be true for most trivial use cases (e.g., just copying some files to a different location or adding symlinks) because there the `system` is usually the same as `builtins.currentSystem`.
 :::
 
-## Writing text files {#trivial-builder-text-writing}
+## `writeTextFile`, `writeText`, `writeTextDir`, `writeScript`, `writeScriptBin` {#trivial-builder-writeText}
 
-Nixpkgs provides the following functions for producing derivations which write text files or executable scripts into the Nix store.
-They are useful for creating files from Nix expression, and are all implemented as convenience wrappers around `writeTextFile`.
+These functions write `text` to the Nix store. This is useful for creating scripts from Nix expressions. `writeTextFile` takes an attribute set and expects two arguments, `name` and `text`. `name` corresponds to the name used in the Nix store path. `text` will be the contents of the file. You can also set `executable` to true to make this file have the executable bit set.
 
-Each of these functions will cause a derivation to be produced.
-When you coerce the result of each of these functions to a string with [string interpolation](https://nixos.org/manual/nix/stable/language/string-interpolation) or [`builtins.toString`](https://nixos.org/manual/nix/stable/language/builtins#builtins-toString), it will evaluate to the [store path](https://nixos.org/manual/nix/stable/store/store-path) of this derivation.
-
-:::: {.note}
-Some of these functions will put the resulting files within a directory inside the [derivation output](https://nixos.org/manual/nix/stable/language/derivations#attr-outputs).
-If you need to refer to the resulting files somewhere else in a Nix expression, append their path to the derivation's store path.
-
-For example, if the file destination is a directory:
-
-```nix
-{
-  my-file = writeTextFile {
-    name = "my-file";
-    text = ''
-      Contents of File
-    '';
-    destination = "/share/my-file";
-  };
-}
-```
-
-Remember to append "/share/my-file" to the resulting store path when using it elsewhere:
-
-```nix
-writeShellScript "evaluate-my-file.sh" ''
-  cat ${my-file}/share/my-file
-''
-```
-::::
-
-### `makeDesktopItem` {#trivial-builder-makeDesktopItem}
-
-Write an [XDG desktop file](https://specifications.freedesktop.org/desktop-entry-spec/1.4/) to the Nix store.
-
-This function is usually used to add desktop items to a package through the `copyDesktopItems` hook.
-
-`makeDesktopItem` adheres to version 1.4 of the specification.
-
-#### Inputs {#trivial-builder-makeDesktopItem-inputs}
-
-`makeDesktopItem` takes an attribute set that accepts most values from the [XDG specification](https://specifications.freedesktop.org/desktop-entry-spec/1.4/ar01s06.html).
-
-All recognised keys from the specification are supported with the exception of the "Hidden" field. The keys are converted into camelCase format, but correspond 1:1 to their equivalent in the specification: `genericName`, `noDisplay`, `comment`, `icon`, `onlyShowIn`, `notShowIn`, `dbusActivatable`, `tryExec`, `exec`, `path`, `terminal`, `mimeTypes`, `categories`, `implements`, `keywords`, `startupNotify`, `startupWMClass`, `url`, `prefersNonDefaultGPU`.
-
-The "Version" field is hardcoded to the version `makeDesktopItem` currently adheres to.
-
-The following fields are either required, are of a different type than in the specification, carry specific default values, or are additional fields supported by `makeDesktopItem`:
-
-`name` (String)
-
-: The name of the desktop file in the Nix store.
-
-`type` (String; _optional_)
-
-: Default value: `"Application"`
-
-`desktopName` (String)
-
-: Corresponds to the "Name" field of the specification.
-
-`actions` (List of Attribute set; _optional_)
-
-: A list of attribute sets {name, exec?, icon?}
-
-`extraConfig` (Attribute set; _optional_)
-
-: Additional key/value pairs to be added verbatim to the desktop file. Attributes need to be prefixed with 'X-'.
-
-#### Examples {#trivial-builder-makeDesktopItem-examples}
-
-::: {.example #ex-makeDesktopItem}
-# Usage 1 of `makeDesktopItem`
-
-Write a desktop file `/nix/store/<store path>/my-program.desktop` to the Nix store.
-
-```nix
-{makeDesktopItem}:
-makeDesktopItem {
-  name = "my-program";
-  desktopName = "My Program";
-  genericName = "Video Player";
-  noDisplay = false;
-  comment = "Cool video player";
-  icon = "/path/to/icon";
-  onlyShowIn = [ "KDE" ];
-  dbusActivatable = true;
-  tryExec = "my-program";
-  exec = "my-program --someflag";
-  path = "/some/working/path";
-  terminal = false;
-  actions.example = {
-    name = "New Window";
-    exec = "my-program --new-window";
-    icon = "/some/icon";
-  };
-  mimeTypes = [ "video/mp4" ];
-  categories = [ "Utility" ];
-  implements = [ "org.my-program" ];
-  keywords = [ "Video" "Player" ];
-  startupNotify = false;
-  startupWMClass = "MyProgram";
-  prefersNonDefaultGPU = false;
-  extraConfig.X-SomeExtension = "somevalue";
-}
-```
-
-:::
-
-::: {.example #ex2-makeDesktopItem}
-# Usage 2 of `makeDesktopItem`
-
-Override the `hello` package to add a desktop item.
-
-```nix
-{ copyDesktopItems
-, hello
-, makeDesktopItem }:
-
-hello.overrideAttrs {
-  nativeBuildInputs = [ copyDesktopItems ];
-
-  desktopItems = [(makeDesktopItem {
-    name = "hello";
-    desktopName = "Hello";
-    exec = "hello";
-  })];
-}
-```
-
-:::
-
-### `writeTextFile` {#trivial-builder-writeTextFile}
-
-Write a text file to the Nix store.
-
-`writeTextFile` takes an attribute set with the following possible attributes:
-
-`name` (String)
-
-: Corresponds to the name used in the Nix store path identifier.
-
-`text` (String)
-
-: The contents of the file.
-
-`executable` (Bool, _optional_)
-
-: Make this file have the executable bit set.
-
-  Default: `false`
-
-`destination` (String, _optional_)
-
-: A subpath under the derivation's output path into which to put the file.
-  Subdirectories are created automatically when the derivation is realised.
-
-  By default, the store path itself will be a file containing the text contents.
-
-  Default: `""`
-
-`checkPhase` (String, _optional_)
-
-: Commands to run after generating the file.
-
-  Default: `""`
-
-`meta` (Attribute set, _optional_)
-
-: Additional metadata for the derivation.
-
-  Default: `{}`
-
-`allowSubstitutes` (Bool, _optional_)
-
-: Whether to allow substituting from a binary cache.
-  Passed through to [`allowSubsitutes`](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-allowSubstitutes) of the underlying call to `builtins.derivation`.
-
-  It defaults to `false`, as running the derivation's simple `builder` executable locally is assumed to be faster than network operations.
-  Set it to true if the `checkPhase` step is expensive.
-
-  Default: `false`
-
-`preferLocalBuild` (Bool, _optional_)
-
-: Whether to prefer building locally, even if faster [remote build machines](https://nixos.org/manual/nix/stable/command-ref/conf-file#conf-substituters) are available.
-
-  Passed through to [`preferLocalBuild`](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-preferLocalBuild) of the underlying call to `builtins.derivation`.
-
-  It defaults to `true` for the same reason `allowSubstitutes` defaults to `false`.
-
-  Default: `true`
-
-`derivationArgs` (Attribute set, _optional_)
-
-: Extra arguments to pass to the underlying call to `stdenv.mkDerivation`.
-
-  Default: `{}`
-
-The resulting store path will include some variation of the name, and it will be a file unless `destination` is used, in which case it will be a directory.
-
-::: {.example #ex-writeTextFile}
-# Usage 1 of `writeTextFile`
-
-Write `my-file` to `/nix/store/<store path>/some/subpath/my-cool-script`, making it executable.
-Also run a check on the resulting file in a `checkPhase`, and supply values for the less-used options.
-
-```nix
-writeTextFile {
-  name = "my-cool-script";
-  text = ''
-    #!/bin/sh
-    echo "This is my cool script!"
-  '';
-  executable = true;
-  destination = "/some/subpath/my-cool-script";
-  checkPhase = ''
-    ${pkgs.shellcheck}/bin/shellcheck $out/some/subpath/my-cool-script
-  '';
-  meta = {
-    license = pkgs.lib.licenses.cc0;
-  };
-  allowSubstitutes = true;
-  preferLocalBuild = false;
-}
-```
-:::
-
-::: {.example #ex2-writeTextFile}
-# Usage 2 of `writeTextFile`
-
-Write the string `Contents of File` to `/nix/store/<store path>`.
-See also the [](#trivial-builder-writeText) helper function.
+Many more commands wrap `writeTextFile` including `writeText`, `writeTextDir`, `writeScript`, and `writeScriptBin`. These are convenience functions over `writeTextFile`.
 
+Here are a few examples:
 ```nix
+# Writes my-file to /nix/store/<store path>
 writeTextFile {
   name = "my-file";
   text = ''
     Contents of File
   '';
 }
-```
-:::
+# See also the `writeText` helper function below.
 
-::: {.example #ex3-writeTextFile}
-# Usage 3 of `writeTextFile`
-
-Write an executable script `my-script` to `/nix/store/<store path>/bin/my-script`.
-See also the [](#trivial-builder-writeScriptBin) helper function.
-
-```nix
+# Writes executable my-file to /nix/store/<store path>/bin/my-file
 writeTextFile {
-  name = "my-script";
+  name = "my-file";
   text = ''
-    echo "hi"
+    Contents of File
   '';
   executable = true;
-  destination = "/bin/my-script";
+  destination = "/bin/my-file";
 }
-```
-:::
-
-### `writeText` {#trivial-builder-writeText}
-
-Write a text file to the Nix store
-
-`writeText` takes the following arguments:
-a string.
-
-`name` (String)
-
-: The name used in the Nix store path.
-
-`text` (String)
-
-: The contents of the file.
-
-The store path will include the name, and it will be a file.
-
-::: {.example #ex-writeText}
-# Usage of `writeText`
-
-Write the string `Contents of File` to `/nix/store/<store path>`:
-
-```nix
+# Writes contents of file to /nix/store/<store path>
 writeText "my-file"
   ''
   Contents of File
-  ''
-```
-:::
-
-This is equivalent to:
-
-```nix
-writeTextFile {
-  name = "my-file";
-  text = ''
-    Contents of File
   '';
-}
-```
-
-### `writeTextDir` {#trivial-builder-writeTextDir}
-
-Write a text file within a subdirectory of the Nix store.
-
-`writeTextDir` takes the following arguments:
-
-`path` (String)
-
-: The destination within the Nix store path under which to create the file.
-
-`text` (String)
-
-: The contents of the file.
-
-The store path will be a directory.
-
-::: {.example #ex-writeTextDir}
-# Usage of `writeTextDir`
-
-Write the string `Contents of File` to `/nix/store/<store path>/share/my-file`:
-
-```nix
+# Writes contents of file to /nix/store/<store path>/share/my-file
 writeTextDir "share/my-file"
   ''
   Contents of File
-  ''
-```
-:::
-
-This is equivalent to:
-
-```nix
-writeTextFile {
-  name = "my-file";
-  text = ''
-    Contents of File
   '';
-  destination = "share/my-file";
-}
-```
-
-### `writeScript` {#trivial-builder-writeScript}
-
-Write an executable script file to the Nix store.
-
-`writeScript` takes the following arguments:
-
-`name` (String)
-
-: The name used in the Nix store path.
-
-`text` (String)
-
-: The contents of the file.
-
-The created file is marked as executable.
-The store path will include the name, and it will be a file.
-
-::: {.example #ex-writeScript}
-# Usage of `writeScript`
-
-Write the string `Contents of File` to `/nix/store/<store path>` and make the file executable.
-
-```nix
+# Writes my-file to /nix/store/<store path> and makes executable
 writeScript "my-file"
   ''
   Contents of File
-  ''
-```
-:::
-
-This is equivalent to:
-
-```nix
-writeTextFile {
-  name = "my-file";
-  text = ''
-    Contents of File
   '';
-  executable = true;
-}
-```
-
-### `writeScriptBin` {#trivial-builder-writeScriptBin}
-
-Write a script within a `bin` subirectory of a directory in the Nix store.
-This is for consistency with the convention of software packages placing executables under `bin`.
-
-`writeScriptBin` takes the following arguments:
-
-`name` (String)
-
-: The name used in the Nix store path and within the file created under the store path.
-
-`text` (String)
-
-: The contents of the file.
-
-The created file is marked as executable.
-The file's contents will be put into `/nix/store/<store path>/bin/<name>`.
-The store path will include the the name, and it will be a directory.
-
-::: {.example #ex-writeScriptBin}
-# Usage of `writeScriptBin`
-
-```nix
-writeScriptBin "my-script"
+# Writes my-file to /nix/store/<store path>/bin/my-file and makes executable.
+writeScriptBin "my-file"
   ''
-  echo "hi"
-  ''
-```
-:::
-
-This is equivalent to:
-
-```nix
-writeTextFile {
-  name = "my-script";
-  text = ''
-    echo "hi"
+  Contents of File
   '';
-  executable = true;
-  destination = "bin/my-script";
-}
-```
-
-### `writeShellScript` {#trivial-builder-writeShellScript}
-
-Write a Bash script to the store.
-
-`writeShellScript` takes the following arguments:
-
-`name` (String)
-
-: The name used in the Nix store path.
-
-`text` (String)
-
-: The contents of the file.
-
-The created file is marked as executable.
-The store path will include the name, and it will be a file.
-
-This function is almost exactly like [](#trivial-builder-writeScript), except that it prepends to the file a [shebang](https://en.wikipedia.org/wiki/Shebang_%28Unix%29) line that points to the version of Bash used in Nixpkgs.
-<!-- this cannot be changed in practice, so there is no point pretending it's somehow generic -->
-
-::: {.example #ex-writeShellScript}
-# Usage of `writeShellScript`
-
-```nix
-writeShellScript "my-script"
+# Writes my-file to /nix/store/<store path> and makes executable.
+writeShellScript "my-file"
   ''
-  echo "hi"
-  ''
-```
-:::
-
-This is equivalent to:
-
-```nix
-writeTextFile {
-  name = "my-script";
-  text = ''
-    #! ${pkgs.runtimeShell}
-    echo "hi"
+  Contents of File
   '';
-  executable = true;
-}
-```
-
-### `writeShellScriptBin` {#trivial-builder-writeShellScriptBin}
-
-Write a Bash script to a "bin" subdirectory of a directory in the Nix store.
-
-`writeShellScriptBin` takes the following arguments:
-
-`name` (String)
-
-: The name used in the Nix store path and within the file generated under the store path.
-
-`text` (String)
-
-: The contents of the file.
-
-The file's contents will be put into `/nix/store/<store path>/bin/<name>`.
-The store path will include the the name, and it will be a directory.
-
-This function is a combination of [](#trivial-builder-writeShellScript) and [](#trivial-builder-writeScriptBin).
-
-::: {.example #ex-writeShellScriptBin}
-# Usage of `writeShellScriptBin`
-
-```nix
-writeShellScriptBin "my-script"
+# Writes my-file to /nix/store/<store path>/bin/my-file and makes executable.
+writeShellScriptBin "my-file"
   ''
-  echo "hi"
-  ''
-```
-:::
-
-This is equivalent to:
-
-```nix
-writeTextFile {
-  name = "my-script";
-  text = ''
-    #! ${pkgs.runtimeShell}
-    echo "hi"
+  Contents of File
   '';
-  executable = true;
-  destination = "bin/my-script";
-}
+
 ```
 
 ## `concatTextFile`, `concatText`, `concatScript` {#trivial-builder-concatText}
@@ -613,14 +148,9 @@ concatScript "my-file" [ file1 file2 ]
 
 ## `writeShellApplication` {#trivial-builder-writeShellApplication}
 
-`writeShellApplication` is similar to `writeShellScriptBin` and `writeScriptBin` but supports runtime dependencies with `runtimeInputs`.
-Writes an executable shell script to `/nix/store/<store path>/bin/<name>` and checks its syntax with [`shellcheck`](https://github.com/koalaman/shellcheck) and the `bash`'s `-n` option.
-Some basic Bash options are set by default (`errexit`, `nounset`, and `pipefail`), but can be overridden with `bashOptions`.
+This can be used to easily produce a shell script that has some dependencies (`runtimeInputs`). It automatically sets the `PATH` of the script to contain all of the listed inputs, sets some sanity shellopts (`errexit`, `nounset`, `pipefail`), and checks the resulting script with [`shellcheck`](https://github.com/koalaman/shellcheck).
 
-Extra arguments may be passed to `stdenv.mkDerivation` by setting `derivationArgs`; note that variables set in this manner will be set when the shell script is _built,_ not when it's run.
-Runtime environment variables can be set with the `runtimeEnv` argument.
-
-For example, the following shell application can refer to `curl` directly, rather than needing to write `${curl}/bin/curl`:
+For example, look at the following code:
 
 ```nix
 writeShellApplication {
@@ -634,6 +164,10 @@ writeShellApplication {
 }
 ```
 
+Unlike with normal `writeShellScriptBin`, there is no need to manually write out `${curl}/bin/curl`, setting the PATH
+was handled by `writeShellApplication`. Moreover, the script is being checked with `shellcheck` for more strict
+validation.
+
 ## `symlinkJoin` {#trivial-builder-symlinkJoin}
 
 This can be used to put many derivations into the same directory structure. It works by creating a new derivation and adding symlinks to each of the paths listed. It expects two arguments, `name`, and `paths`. `name` is the name used in the Nix store path for the created derivation. `paths` is a list of paths that will be symlinked. These paths can be to Nix store derivations or any other subdirectory contained within.
@@ -660,23 +194,19 @@ This creates a derivation with a directory structure like the following:
 
 ## `writeReferencesToFile` {#trivial-builder-writeReferencesToFile}
 
-Deprecated. Use [`writeClosure`](#trivial-builder-writeClosure) instead.
+Writes the closure of transitive dependencies to a file.
 
-## `writeClosure` {#trivial-builder-writeClosure}
-
-Given a list of [store paths](https://nixos.org/manual/nix/stable/glossary#gloss-store-path) (or string-like expressions coercible to store paths), write their collective [closure](https://nixos.org/manual/nix/stable/glossary#gloss-closure) to a text file.
-
-The result is equivalent to the output of `nix-store -q --requisites`.
+This produces the equivalent of `nix-store -q --requisites`.
 
 For example,
 
 ```nix
-writeClosure [ (writeScriptBin "hi" ''${hello}/bin/hello'') ]
+writeReferencesToFile (writeScriptBin "hi" ''${hello}/bin/hello'')
 ```
 
 produces an output path `/nix/store/<hash>-runtime-deps` containing
 
-```
+```nix
 /nix/store/<hash>-hello-2.10
 /nix/store/<hash>-hi
 /nix/store/<hash>-libidn2-2.3.0
@@ -702,7 +232,7 @@ writeDirectReferencesToFile (writeScriptBin "hi" ''${hello}/bin/hello'')
 
 produces an output path `/nix/store/<hash>-runtime-references` containing
 
-```
+```nix
 /nix/store/<hash>-hello-2.10
 ```
 

doc/default.nix

@@ -25,7 +25,6 @@ let
       { name = "gvariant"; description = "GVariant formatted string serialization functions"; }
       { name = "customisation"; description = "Functions to customise (derivation-related) functions, derivatons, or attribute sets"; }
       { name = "meta"; description = "functions for derivation metadata"; }
-      { name = "derivations"; description = "miscellaneous derivation-specific functions"; }
     ];
   };
 
@@ -111,7 +110,7 @@ in pkgs.stdenv.mkDerivation {
       ${lib-docs}/index.md \
       > ./functions/library.md
     substitute ./manual.md.in ./manual.md \
-      --replace-fail '@MANUAL_VERSION@' '${pkgs.lib.version}'
+      --replace '@MANUAL_VERSION@' '${pkgs.lib.version}'
 
     mkdir -p out/media
 
@@ -122,17 +121,16 @@ in pkgs.stdenv.mkDerivation {
       ${pkgs.documentation-highlighter}/mono-blue.css \
       ${pkgs.documentation-highlighter}/loader.js
 
-    cp -t out ./style.css ./anchor.min.js ./anchor-use.js
+    cp -t out ./overrides.css ./style.css
 
     nixos-render-docs manual html \
       --manpage-urls ./manpage-urls.json \
       --revision ${pkgs.lib.trivial.revisionWithDefault (pkgs.rev or "master")} \
       --stylesheet style.css \
+      --stylesheet overrides.css \
       --stylesheet highlightjs/mono-blue.css \
       --script ./highlightjs/highlight.pack.js \
       --script ./highlightjs/loader.js \
-      --script ./anchor.min.js \
-      --script ./anchor-use.js \
       --toc-depth 1 \
       --section-toc-depth 1 \
       manual.md \
@@ -151,26 +149,4 @@ in pkgs.stdenv.mkDerivation {
     echo "doc manual $dest ${common.indexPath}" >> $out/nix-support/hydra-build-products
     echo "doc manual $dest nixpkgs-manual.epub" >> $out/nix-support/hydra-build-products
   '';
-
-  passthru.tests.manpage-urls = with pkgs; testers.invalidateFetcherByDrvHash
-    ({ name ? "manual_check-manpage-urls"
-     , script
-     , urlsFile
-     }: runCommand name {
-      nativeBuildInputs = [
-        cacert
-        (python3.withPackages (p: with p; [
-          aiohttp
-          rich
-          structlog
-        ]))
-      ];
-      outputHash = "sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=";  # Empty output
-    } ''
-      python3 ${script} ${urlsFile}
-      touch $out
-    '') {
-      script = ./tests/manpage-urls.py;
-      urlsFile = ./manpage-urls.json;
-    };
 }

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

@@ -29,7 +29,7 @@ stdenv.mkDerivation {
     mkdir -p "$out"
 
     cat > "$out/index.md" << 'EOF'
-    ```{=include=} sections auto-id-prefix=auto-generated
+    ```{=include=} sections
     EOF
 
     ${lib.concatMapStrings ({ name, baseName ? name, description }: ''

doc/functions/generators.section.md

@@ -6,9 +6,8 @@ All generators follow a similar call interface: `generatorName configFunctions d
 Generators can be fine-tuned to produce exactly the file format required by your application/service. One example is an INI-file format which uses `: ` as separator, the strings `"yes"`/`"no"` as boolean values and requires all string values to be quoted:
 
 ```nix
+with lib;
 let
-  inherit (lib) generators isString;
-
   customToINI = generators.toINI {
     # specifies how to format a key/value pair
     mkKeyValue = generators.mkKeyValueDefault {

doc/functions/nix-gitignore.section.md

@@ -7,30 +7,27 @@
 `pkgs.nix-gitignore` exports a number of functions, but you'll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
 
 ```nix
-{ pkgs ? import <nixpkgs> {} }: {
+{ pkgs ? import <nixpkgs> {} }:
 
- src = nix-gitignore.gitignoreSource [] ./source;
+ nix-gitignore.gitignoreSource [] ./source
      # Simplest version
 
- src = nix-gitignore.gitignoreSource "supplemental-ignores\n" ./source;
+ nix-gitignore.gitignoreSource "supplemental-ignores\n" ./source
      # This one reads the ./source/.gitignore and concats the auxiliary ignores
 
- src = nix-gitignore.gitignoreSourcePure "ignore-this\nignore-that\n" ./source;
+ nix-gitignore.gitignoreSourcePure "ignore-this\nignore-that\n" ./source
      # Use this string as gitignore, don't read ./source/.gitignore.
 
- src = nix-gitignore.gitignoreSourcePure ["ignore-this\nignore-that\n" ~/.gitignore] ./source;
+ nix-gitignore.gitignoreSourcePure ["ignore-this\nignore-that\n", ~/.gitignore] ./source
      # It also accepts a list (of strings and paths) that will be concatenated
      # once the paths are turned to strings via readFile.
-}
 ```
 
 These functions are derived from the `Filter` functions by setting the first filter argument to `(_: _: true)`:
 
 ```nix
-{
-  gitignoreSourcePure = gitignoreFilterSourcePure (_: _: true);
-  gitignoreSource = gitignoreFilterSource (_: _: true);
-}
+gitignoreSourcePure = gitignoreFilterSourcePure (_: _: true);
+gitignoreSource = gitignoreFilterSource (_: _: true);
 ```
 
 Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it's blacklisted by either your filter or the gitignoreFilter.
@@ -38,9 +35,7 @@ Those filter functions accept the same arguments the `builtins.filterSource` fun
 If you want to make your own filter from scratch, you may use
 
 ```nix
-{
-  gitignoreFilter = ign: root: filterPattern (gitignoreToPatterns ign) root;
-}
+gitignoreFilter = ign: root: filterPattern (gitignoreToPatterns ign) root;
 ```
 
 ## gitignore files in subdirectories {#sec-pkgs-nix-gitignore-usage-recursive}
@@ -48,9 +43,7 @@ If you want to make your own filter from scratch, you may use
 If you wish to use a filter that would search for .gitignore files in subdirectories, just like git does by default, use this function:
 
 ```nix
-{
-  # gitignoreFilterRecursiveSource = filter: patterns: root:
-  # OR
-  gitignoreRecursiveSource = gitignoreFilterSourcePure (_: _: true);
-}
+gitignoreFilterRecursiveSource = filter: patterns: root:
+# OR
+gitignoreRecursiveSource = gitignoreFilterSourcePure (_: _: true);
 ```

doc/hooks/breakpoint.section.md

@@ -3,9 +3,7 @@
 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 ];
-}
+nativeBuildInputs = [ breakpointHook ];
 ```
 
 When a build failure happens there will be an instruction printed that shows how to attach with `cntr` to the build sandbox.

doc/hooks/installShellFiles.section.md

@@ -2,26 +2,24 @@
 
 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 `share/man/man<section>/` directory, in [`outputMan`](#outputman).
+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)
-  '';
-}
+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/mpi-check-hook.section.md

@@ -12,14 +12,13 @@ Example:
 
 ```nix
   { mpiCheckPhaseHook, mpi, ... }:
-  {
-    # ...
 
-    nativeCheckInputs = [
-      openssh
-      mpiCheckPhaseHook
-    ];
-  }
+  ...
+
+  nativeCheckInputs = [
+    openssh
+    mpiCheckPhaseHook
+  ];
 ```
 
 

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

@@ -45,7 +45,6 @@ Bash-only variables:
  - `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.
  - `postgresqlStartCommands`: defaults to `pg_ctl start`.
- - `postgresqlExtraSettings`: Additional configuration to add to `postgresql.conf`
 
 ## Hooks {#sec-postgresqlTestHook-hooks}
 

doc/hooks/python.section.md

@@ -1,3 +1,3 @@
 # Python {#setup-hook-python}
 
-Adds the `python.sitePackages` subdirectory (i.e. `lib/pythonX.Y/site-packages`) of each build input to the `PYTHONPATH` environment variable.
+Adds the `lib/${python.libPrefix}/site-packages` subdirectory of each build input to the `PYTHONPATH` environment variable.

doc/hooks/zig.section.md

@@ -9,14 +9,14 @@ In Nixpkgs, `zig.hook` overrides the default build, check and install phases.
 ```nix
 { lib
 , stdenv
-, zig
+, zig_0_11
 }:
 
 stdenv.mkDerivation {
   # . . .
 
   nativeBuildInputs = [
-    zig.hook
+    zig_0_11.hook
   ];
 
   zigBuildFlags = [ "-Dman-pages=true" ];

doc/languages-frameworks/agda.section.md

@@ -114,7 +114,7 @@ This can be overridden by a different version of `ghc` as follows:
 
 ```nix
 agda.withPackages {
-  pkgs = [ /* ... */ ];
+  pkgs = [ ... ];
   ghc = haskell.compiler.ghcHEAD;
 }
 ```
@@ -180,7 +180,6 @@ To add an Agda package to `nixpkgs`, the derivation should be written to `pkgs/d
 
 ```nix
 { mkDerivation, standard-library, fetchFromGitHub }:
-{}
 ```
 
 Note that the derivation function is called with `mkDerivation` set to `agdaPackages.mkDerivation`, therefore you
@@ -194,7 +193,7 @@ mkDerivation {
   version = "1.5.0";
   pname = "iowa-stdlib";
 
-  src = <...>;
+  src = ...
 
   libraryFile = "";
   libraryName = "IAL-1.3";

doc/languages-frameworks/android.section.md

@@ -104,20 +104,18 @@ pull from:
   repo.json to the Nix store based on the given repository XMLs.
 
 ```nix
-{
-  repoXmls = {
-    packages = [ ./xml/repository2-1.xml ];
-    images = [
-      ./xml/android-sys-img2-1.xml
-      ./xml/android-tv-sys-img2-1.xml
-      ./xml/android-wear-sys-img2-1.xml
-      ./xml/android-wear-cn-sys-img2-1.xml
-      ./xml/google_apis-sys-img2-1.xml
-      ./xml/google_apis_playstore-sys-img2-1.xml
-    ];
-    addons = [ ./xml/addon2-1.xml ];
-  };
-}
+repoXmls = {
+  packages = [ ./xml/repository2-1.xml ];
+  images = [
+    ./xml/android-sys-img2-1.xml
+    ./xml/android-tv-sys-img2-1.xml
+    ./xml/android-wear-sys-img2-1.xml
+    ./xml/android-wear-cn-sys-img2-1.xml
+    ./xml/google_apis-sys-img2-1.xml
+    ./xml/google_apis_playstore-sys-img2-1.xml
+  ];
+  addons = [ ./xml/addon2-1.xml ];
+};
 ```
 
 When building the above expression with:

doc/languages-frameworks/beam.section.md

@@ -117,7 +117,6 @@ If there are git dependencies.
 - From the mix_deps.nix file, remove the dependencies that had git versions and pass them as an override to the import function.
 
 ```nix
-{
   mixNixDeps = import ./mix.nix {
     inherit beamPackages lib;
     overrides = (final: prev: {
@@ -139,9 +138,8 @@ If there are git dependencies.
         # you can re-use the same beamDeps argument as generated
         beamDeps = with final; [ prometheus ];
       };
-    });
-  };
-}
+  });
+};
 ```
 
 You will need to run the build process once to fix the hash to correspond to your new git src.
@@ -155,13 +153,11 @@ Practical steps
 - start with the following argument to mixRelease
 
 ```nix
-{
   mixFodDeps = fetchMixDeps {
     pname = "mix-deps-${pname}";
     inherit src version;
     hash = lib.fakeHash;
   };
-}
 ```
 
 The first build will complain about the hash value, you can replace with the suggested value after that.
@@ -220,7 +216,7 @@ in packages.mixRelease {
 Setup will require the following steps:
 
 - Move your secrets to runtime environment variables. For more information refer to the [runtime.exs docs](https://hexdocs.pm/mix/Mix.Tasks.Release.html#module-runtime-configuration). On a fresh Phoenix build that would mean that both `DATABASE_URL` and `SECRET_KEY` need to be moved to `runtime.exs`.
-- `cd assets` and `nix-shell -p node2nix --run "node2nix --development"` will generate a Nix expression containing your frontend dependencies
+- `cd assets` and `nix-shell -p node2nix --run node2nix --development` will generate a Nix expression containing your frontend dependencies
 - commit and push those changes
 - you can now `nix-build .`
 - To run the release, set the `RELEASE_TMP` environment variable to a directory that your program has write access to. It will be used to store the BEAM settings.

doc/languages-frameworks/bower.section.md

@@ -28,7 +28,7 @@ buildEnv { name = "bower-env"; ignoreCollisions = true; paths = [
   (fetchbower "angular" "1.5.3" "~1.5.0" "1749xb0firxdra4rzadm4q9x90v6pzkbd7xmcyjk6qfza09ykk9y")
   (fetchbower "bootstrap" "3.3.6" "~3.3.6" "1vvqlpbfcy0k5pncfjaiskj3y6scwifxygfqnw393sjfxiviwmbv")
   (fetchbower "jquery" "2.2.2" "1.9.1 - 2" "10sp5h98sqwk90y4k6hbdviwqzvzwqf47r3r51pakch5ii2y7js1")
-]; }
+];
 ```
 
 Using the `bower2nix` command line arguments, the output can be redirected to a file. A name like `bower-packages.nix` would be fine.
@@ -42,13 +42,11 @@ The function is implemented in [pkgs/development/bower-modules/generic/default.n
 ### Example buildBowerComponents {#ex-buildBowerComponents}
 
 ```nix
-{
-  bowerComponents = buildBowerComponents {
-    name = "my-web-app";
-    generated = ./bower-packages.nix; # note 1
-    src = myWebApp; # note 2
-  };
-}
+bowerComponents = buildBowerComponents {
+  name = "my-web-app";
+  generated = ./bower-packages.nix; # note 1
+  src = myWebApp; # note 2
+};
 ```
 
 In ["buildBowerComponents" example](#ex-buildBowerComponents) the following arguments are of special significance to the function:

doc/languages-frameworks/chicken.section.md

@@ -13,12 +13,10 @@ done in the typical Nix fashion. For example, to include support for [SRFI
 might write:
 
 ```nix
-{
   buildInputs = [
     chicken
     chickenPackages.chickenEggs.srfi-189
   ];
-}
 ```
 
 Both `chicken` and its eggs have a setup hook which configures the environment
@@ -69,12 +67,12 @@ let
       chickenEggs = super.chickenEggs.overrideScope' (eggself: eggsuper: {
         srfi-180 = eggsuper.srfi-180.overrideAttrs {
           # path to a local copy of srfi-180
-          src = <...>;
+          src = ...
         };
       });
   });
 in
 # Here, `myChickenPackages.chickenEggs.json-rpc`, which depends on `srfi-180` will use
 # the local copy of `srfi-180`.
-<...>
+# ...
 ```

doc/languages-frameworks/coq.section.md

@@ -55,18 +55,17 @@ Here is a simple package example. It is a pure Coq library, thus it depends on C
 ```nix
 { lib, mkCoqDerivation, version ? null
 , coq, mathcomp, mathcomp-finmap, mathcomp-bigenough }:
-
-mkCoqDerivation {
+with lib; mkCoqDerivation {
   /* namePrefix leads to e.g. `name = coq8.11-mathcomp1.11-multinomials-1.5.2` */
   namePrefix = [ "coq" "mathcomp" ];
   pname = "multinomials";
   owner = "math-comp";
   inherit version;
-  defaultVersion = with lib.versions; lib.switch [ coq.version mathcomp.version ] [
-      { cases = [ (range "8.7" "8.12") (isEq "1.11") ];        out = "1.5.2"; }
-      { cases = [ (range "8.7" "8.11") (range "1.8" "1.10") ]; out = "1.5.0"; }
-      { cases = [ (range "8.7" "8.10") (range "1.8" "1.10") ]; out = "1.4"; }
-      { cases = [ (isEq "8.6")         (range "1.6" "1.7") ];  out = "1.1"; }
+  defaultVersion =  with versions; switch [ coq.version mathcomp.version ] [
+      { cases = [ (range "8.7" "8.12")  "1.11.0" ];             out = "1.5.2"; }
+      { cases = [ (range "8.7" "8.11")  (range "1.8" "1.10") ]; out = "1.5.0"; }
+      { cases = [ (range "8.7" "8.10")  (range "1.8" "1.10") ]; out = "1.4"; }
+      { cases = [ "8.6"                 (range "1.6" "1.7") ];  out = "1.1"; }
     ] null;
   release = {
     "1.5.2".sha256 = "15aspf3jfykp1xgsxf8knqkxv8aav2p39c2fyirw7pwsfbsv2c4s";
@@ -85,7 +84,7 @@ mkCoqDerivation {
 
   meta = {
     description = "A Coq/SSReflect Library for Monoidal Rings and Multinomials";
-    license = lib.licenses.cecill-c;
+    license = licenses.cecill-c;
   };
 }
 ```

doc/languages-frameworks/crystal.section.md

@@ -33,26 +33,22 @@ crystal.buildCrystalPackage rec {
   # Insert the path to your shards.nix file here
   shardsFile = ./shards.nix;
 
-  # ...
+  ...
 }
 ```
 
 This won't build anything yet, because we haven't told it what files build. We can specify a mapping from binary names to source files with the `crystalBinaries` attribute. The project's compilation instructions should show this. For Mint, the binary is called "mint", which is compiled from the source file `src/mint.cr`, so we'll specify this as follows:
 
 ```nix
-{
   crystalBinaries.mint.src = "src/mint.cr";
 
   # ...
-}
 ```
 
 Additionally you can override the default `crystal build` options (which are currently `--release --progress --no-debug --verbose`) with
 
 ```nix
-{
   crystalBinaries.mint.options = [ "--release" "--verbose" ];
-}
 ```
 
 Depending on the project, you might need additional steps to get it to compile successfully. In Mint's case, we need to link against openssl, so in the end the Nix file looks as follows:

doc/languages-frameworks/cuda.section.md

@@ -16,28 +16,24 @@ To use one or more CUDA packages in an expression, give the expression a `cudaPa
 , cudaSupport ? config.cudaSupport
 , cudaPackages ? { }
 , ...
-}: {}
+}:
 ```
 
 When using `callPackage`, you can choose to pass in a different variant, e.g.
 when a different version of the toolkit suffices
 ```nix
-{
-  mypkg = callPackage { cudaPackages = cudaPackages_11_5; };
-}
+mypkg = callPackage { cudaPackages = cudaPackages_11_5; }
 ```
 
 If another version of say `cudnn` or `cutensor` is needed, you can override the
 package set to make it the default. This guarantees you get a consistent package
 set.
 ```nix
-{
-  mypkg = let
-    cudaPackages = cudaPackages_11_5.overrideScope (final: prev: {
-      cudnn = prev.cudnn_8_3;
-    });
-  in callPackage { inherit cudaPackages; };
-}
+mypkg = let
+  cudaPackages = cudaPackages_11_5.overrideScope (final: prev: {
+    cudnn = prev.cudnn_8_3;
+  }});
+in callPackage { inherit cudaPackages; };
 ```
 
 The CUDA NVCC compiler requires flags to determine which hardware you
@@ -72,45 +68,16 @@ All new projects should use the CUDA redistributables available in [`cudaPackage
 ### Updating CUDA redistributables {#updating-cuda-redistributables}
 
 1. Go to NVIDIA's index of CUDA redistributables: <https://developer.download.nvidia.com/compute/cuda/redist/>
-2. Make a note of the new version of CUDA available.
-3. Run
+2. Copy the `redistrib_*.json` corresponding to the release to `pkgs/development/compilers/cudatoolkit/redist/manifests`.
+3. Generate the `redistrib_features_*.json` file by running:
 
-   ```bash
-   nix run github:connorbaker/cuda-redist-find-features -- \
-      download-manifests \
-      --log-level DEBUG \
-      --version <newest CUDA version> \
-      https://developer.download.nvidia.com/compute/cuda/redist \
-      ./pkgs/development/cuda-modules/cuda/manifests
-   ```
+    ```bash
+    nix run github:ConnorBaker/cuda-redist-find-features -- <path to manifest>
+    ```
 
-   This will download a copy of the manifest for the new version of CUDA.
-4. Run
+    That command will generate the `redistrib_features_*.json` file in the same directory as the manifest.
 
-   ```bash
-   nix run github:connorbaker/cuda-redist-find-features -- \
-      process-manifests \
-      --log-level DEBUG \
-      --version <newest CUDA version> \
-      https://developer.download.nvidia.com/compute/cuda/redist \
-      ./pkgs/development/cuda-modules/cuda/manifests
-   ```
-
-   This will generate a `redistrib_features_<newest CUDA version>.json` file in the same directory as the manifest.
-5. Update the `cudaVersionMap` attribute set in `pkgs/development/cuda-modules/cuda/extension.nix`.
-
-### Updating cuTensor {#updating-cutensor}
-
-1. Repeat the steps present in [Updating CUDA redistributables](#updating-cuda-redistributables) with the following changes:
-   - Use the index of cuTensor redistributables: <https://developer.download.nvidia.com/compute/cutensor/redist>
-   - Use the newest version of cuTensor available instead of the newest version of CUDA.
-   - Use `pkgs/development/cuda-modules/cutensor/manifests` instead of `pkgs/development/cuda-modules/cuda/manifests`.
-   - Skip the step of updating `cudaVersionMap` in `pkgs/development/cuda-modules/cuda/extension.nix`.
-
-### Updating supported compilers and GPUs {#updating-supported-compilers-and-gpus}
-
-1. Update `nvcc-compatibilities.nix` in `pkgs/development/cuda-modules/` to include the newest release of NVCC, as well as any newly supported host compilers.
-2. Update `gpus.nix` in `pkgs/development/cuda-modules/` to include any new GPUs supported by the new release of CUDA.
+4. Include the path to the new manifest in `pkgs/development/compilers/cudatoolkit/redist/extension.nix`.
 
 ### Updating the CUDA Toolkit runfile installer {#updating-the-cuda-toolkit}
 
@@ -132,7 +99,7 @@ All new projects should use the CUDA redistributables available in [`cudaPackage
    nix store prefetch-file --hash-type sha256 <link>
    ```
 
-4. Update `pkgs/development/cuda-modules/cudatoolkit/releases.nix` to include the release.
+4. Update `pkgs/development/compilers/cudatoolkit/versions.toml` to include the release.
 
 ### Updating the CUDA package set {#updating-the-cuda-package-set}
 
@@ -140,7 +107,7 @@ All new projects should use the CUDA redistributables available in [`cudaPackage
 
    - NOTE: Changing the default CUDA package set should occur in a separate PR, allowing time for additional testing.
 
-2. Successfully build the closure of the new package set, updating `pkgs/development/cuda-modules/cuda/overrides.nix` as needed. Below are some common failures:
+2. Successfully build the closure of the new package set, updating `pkgs/development/compilers/cudatoolkit/redist/overrides.nix` as needed. Below are some common failures:
 
 | Unable to ... | During ... | Reason | Solution | Note |
 | --- | --- | --- | --- | --- |
@@ -148,4 +115,4 @@ All new projects should use the CUDA redistributables available in [`cudaPackage
 | Find libraries | `configurePhase` | Missing dependency on a `dev` output | Add the missing dependency | The `dev` output typically contain CMake configuration files |
 | Find libraries | `buildPhase` or `patchelf` | Missing dependency on a `lib` or `static` output | Add the missing dependency | The `lib` or `static` output typically contain the libraries |
 
-In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary.
+In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`cudaPackages.autoAddOpenGLRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=cudaPackages.autoAddOpenGLRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary.

doc/languages-frameworks/cuelang.section.md

@@ -26,7 +26,7 @@ Cuelang schemas are similar to JSON, here is a quick cheatsheet:
 Nixpkgs provides a `pkgs.writeCueValidator` helper, which will write a validation script based on the provided Cuelang schema.
 
 Here is an example:
-```nix
+```
 pkgs.writeCueValidator
   (pkgs.writeText "schema.cue" ''
     #Def1: {
@@ -42,7 +42,7 @@ pkgs.writeCueValidator
 `document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but different documents based on the data you are validating.
 
 Another example, given the following `validator.nix` :
-```nix
+```
 { pkgs ? import <nixpkgs> {} }:
 let
   genericValidator = version:

doc/languages-frameworks/dart.section.md

@@ -4,33 +4,22 @@
 
 The function `buildDartApplication` builds Dart applications managed with pub.
 
-It fetches its Dart dependencies automatically through `pub2nix`, and (through a series of hooks) builds and installs the executables specified in the pubspec file. The hooks can be used in other derivations, if needed. The phases can also be overridden to do something different from installing binaries.
+It fetches its Dart dependencies automatically through `fetchDartDeps`, and (through a series of hooks) builds and installs the executables specified in the pubspec file. The hooks can be used in other derivations, if needed. The phases can also be overridden to do something different from installing binaries.
 
 If you are packaging a Flutter desktop application, use [`buildFlutterApplication`](#ssec-dart-flutter) instead.
 
-`pubspecLock` is the parsed pubspec.lock file. pub2nix uses this to download required packages.
-This can be converted to JSON from YAML with something like `yq . pubspec.lock`, and then read by Nix.
+`vendorHash`: is the hash of the output of the dependency fetcher derivation. To obtain it, set it to `lib.fakeHash` (or omit it) and run the build ([more details here](#sec-source-hashes)).
 
-Alternatively, `autoPubspecLock` can be used instead, and set to a path to a regular `pubspec.lock` file. This relies on import-from-derivation, and is not permitted in Nixpkgs, but can be useful at other times.
+If the upstream source is missing a `pubspec.lock` file, you'll have to vendor one and specify it using `pubspecLockFile`. If it is needed, one will be generated for you and printed when attempting to build the derivation.
 
-::: {.warning}
-When using `autoPubspecLock` with a local source directory, make sure to use a
-concatenation operator (e.g. `autoPubspecLock = src + "/pubspec.lock";`), and
-not string interpolation.
-
-String interpolation will copy your entire source directory to the Nix store and
-use its store path, meaning that unrelated changes to your source tree will
-cause the generated `pubspec.lock` derivation to rebuild!
-:::
-
-If the package has Git package dependencies, the hashes must be provided in the `gitHashes` set. If a hash is missing, an error message prompting you to add it will be shown.
+The `depsListFile` must always be provided when packaging in Nixpkgs. It will be generated and printed if the derivation is attempted to be built without one. Alternatively, `autoDepsList` may be set to `true` only when outside of Nixpkgs, as it relies on import-from-derivation.
 
 The `dart` commands run can be overridden through `pubGetScript` and `dartCompileCommand`, you can also add flags using `dartCompileFlags` or `dartJitFlags`.
 
 Dart supports multiple [outputs types](https://dart.dev/tools/dart-compile#types-of-output), you can choose between them using `dartOutputType` (defaults to `exe`). If you want to override the binaries path or the source path they come from, you can use `dartEntryPoints`. Outputs that require a runtime will automatically be wrapped with the relevant runtime (`dartaotruntime` for `aot-snapshot`, `dart run` for `jit-snapshot` and `kernel`, `node` for `js`), this can be overridden through `dartRuntimeCommand`.
 
 ```nix
-{ lib, buildDartApplication, fetchFromGitHub }:
+{ buildDartApplication, fetchFromGitHub }:
 
 buildDartApplication rec {
   pname = "dart-sass";
@@ -43,55 +32,12 @@ buildDartApplication rec {
     hash = "sha256-U6enz8yJcc4Wf8m54eYIAnVg/jsGi247Wy8lp1r1wg4=";
   };
 
-  pubspecLock = lib.importJSON ./pubspec.lock.json;
+  pubspecLockFile = ./pubspec.lock;
+  depsListFile = ./deps.json;
+  vendorHash = "sha256-Atm7zfnDambN/BmmUf4BG0yUz/y6xWzf0reDw3Ad41s=";
 }
 ```
 
-### Patching dependencies {#ssec-dart-applications-patching-dependencies}
-
-Some Dart packages require patches or build environment changes. Package derivations can be customised with the `customSourceBuilders` argument.
-
-A collection of such customisations can be found in Nixpkgs, in the `development/compilers/dart/package-source-builders` directory.
-
-This allows fixes for packages to be shared between all applications that use them. It is strongly recommended to add to this collection instead of including fixes in your application derivation itself.
-
-### Running executables from dev_dependencies {#ssec-dart-applications-build-tools}
-
-Many Dart applications require executables from the `dev_dependencies` section in `pubspec.yaml` to be run before building them.
-
-This can be done in `preBuild`, in one of two ways:
-
-1. Packaging the tool with `buildDartApplication`, adding it to Nixpkgs, and running it like any other application
-2. Running the tool from the package cache
-
-Of these methods, the first is recommended when using a tool that does not need
-to be of a specific version.
-
-For the second method, the `packageRun` function from the `dartConfigHook` can be used.
-This is an alternative to `dart run` that does not rely on Pub.
-
-e.g., for `build_runner`:
-
-```bash
-packageRun build_runner build
-```
-
-Do _not_ use `dart run <package_name>`, as this will attempt to download dependencies with Pub.
-
-### Usage with nix-shell {#ssec-dart-applications-nix-shell}
-
-#### Using dependencies from the Nix store {#ssec-dart-applications-nix-shell-deps}
-
-As `buildDartApplication` provides dependencies instead of `pub get`, Dart needs to be explicitly told where to find them.
-
-Run the following commands in the source directory to configure Dart appropriately.
-Do not use `pub` after doing so; it will download the dependencies itself and overwrite these changes.
-
-```bash
-cp --no-preserve=all "$pubspecLockFilePath" pubspec.lock
-mkdir -p .dart_tool && cp --no-preserve=all "$packageConfig" .dart_tool/package_config.json
-```
-
 ## Flutter applications {#ssec-dart-flutter}
 
 The function `buildFlutterApplication` builds Flutter applications.
@@ -103,10 +49,7 @@ See the [Dart documentation](#ssec-dart-applications) for more details on requir
 
 flutter.buildFlutterApplication {
   pname = "firmware-updater";
-  version = "0-unstable-2023-04-30";
-
-  # To build for the Web, use the targetFlutterPlatform argument.
-  # targetFlutterPlatform = "web";
+  version = "unstable-2023-04-30";
 
   src = fetchFromGitHub {
     owner = "canonical";
@@ -116,21 +59,8 @@ flutter.buildFlutterApplication {
     fetchSubmodules = true;
   };
 
-  pubspecLock = lib.importJSON ./pubspec.lock.json;
+  pubspecLockFile = ./pubspec.lock;
+  depsListFile = ./deps.json;
+  vendorHash = "sha256-cdMO+tr6kYiN5xKXa+uTMAcFf2C75F3wVPrn21G4QPQ=";
 }
 ```
-
-### Usage with nix-shell {#ssec-dart-flutter-nix-shell}
-
-Flutter-specific `nix-shell` usage notes are included here. See the [Dart documentation](#ssec-dart-applications-nix-shell) for general `nix-shell` instructions.
-
-#### Entering the shell {#ssec-dart-flutter-nix-shell-enter}
-
-By default, dependencies for only the `targetFlutterPlatform` are available in the
-build environment. This is useful for keeping closures small, but be problematic
-during development. It's common, for example, to build Web apps for Linux during
-development to take advantage of native features such as stateful hot reload.
-
-To enter a shell with all the usual target platforms available, use the `multiShell` attribute.
-
-e.g. `nix-shell '<nixpkgs>' -A fluffychat-web.multiShell`.

doc/languages-frameworks/dhall.section.md

@@ -187,7 +187,6 @@ wish to specify `source = true` for all Dhall packages, then you can amend the
 Dhall overlay like this:
 
 ```nix
-{
   dhallOverrides = self: super: {
     # Enable source for all Dhall packages
     buildDhallPackage =
@@ -195,7 +194,6 @@ Dhall overlay like this:
 
     true = self.callPackage ./true.nix { };
   };
-}
 ```
 
 … and now the Prelude will contain the fully decoded result of interpreting
@@ -431,26 +429,22 @@ $ dhall-to-nixpkgs github https://github.com/dhall-lang/dhall-lang.git \
 the Prelude globally for all packages, like this:
 
 ```nix
-{
   dhallOverrides = self: super: {
     true = self.callPackage ./true.nix { };
 
     Prelude = self.callPackage ./Prelude.nix { };
   };
-}
 ```
 
 … or selectively overriding the Prelude dependency for just the `true` package,
 like this:
 
 ```nix
-{
   dhallOverrides = self: super: {
     true = self.callPackage ./true.nix {
       Prelude = self.callPackage ./Prelude.nix { };
     };
   };
-}
 ```
 
 ## Overrides {#ssec-dhall-overrides}
@@ -460,13 +454,11 @@ You can override any of the arguments to `buildDhallGitHubPackage` or
 For example, suppose we wanted to selectively enable `source = true` just for the Prelude.  We can do that like this:
 
 ```nix
-{
   dhallOverrides = self: super: {
     Prelude = super.Prelude.overridePackage { source = true; };
 
-    # ...
+    …
   };
-}
 ```
 
 [semantic-integrity-checks]: https://docs.dhall-lang.org/tutorials/Language-Tour.html#installing-packages

doc/languages-frameworks/dlang.section.md

@@ -1,69 +0,0 @@
-# D (Dlang) {#dlang}
-
-Nixpkgs provides multiple D compilers such as `ldc`, `dmd` and `gdc`.
-These can be used like any other package during build time.
-
-However, Nixpkgs provides a build helper for compiling packages using the `dub` package manager.
-
-Here's an example:
-```nix
-{
-  lib,
-  buildDubPackage,
-  fetchFromGitHub,
-  ncurses,
-  zlib,
-}:
-
-buildDubPackage rec {
-  pname = "btdu";
-  version = "0.5.1";
-
-  src = fetchFromGitHub {
-    owner = "CyberShadow";
-    repo = "btdu";
-    rev = "v${version}";
-    hash = "sha256-3sSZq+5UJH02IO0Y1yL3BLHDb4lk8k6awb5ZysBQciE=";
-  };
-
-  # generated by dub-to-nix, see below
-  dubLock = ./dub-lock.json;
-
-  buildInputs = [
-    ncurses
-    zlib
-  ];
-
-  installPhase = ''
-    runHook preInstall
-    install -Dm755 btdu -t $out/bin
-    runHook postInstall
-  '';
-}
-```
-
-Note that you need to define `installPhase` because `dub` doesn't know where files should go in `$out`.
-
-Also note that running `dub test` is disabled by default. You can enable it by setting `doCheck = true`.
-
-## Lockfiles {#dub-lockfiles}
-Nixpkgs has its own lockfile format for `dub` dependencies, because `dub`'s official "lockfile" format (`dub.selections.json`) is not hash based.
-
-A lockfile can be generated using the `dub-to-nix` helper package.
-* Firstly, install `dub-to-nix` into your shell session by running `nix-shell -p dub-to-nix`
-* Then navigate to the root of the source of the program you want to package
-* Finally, run `dub-to-nix` and it will print the lockfile to stdout. You could pipe stdout into a text file or just copy the output manually into a file.
-
-## `buildDubPackage` parameters {#builddubpackage-parameters}
-
-The `buildDubPackage` function takes an attrset of parameters that are passed on to `stdenv.mkDerivation`.
-
-The following parameters are specific to `buildDubPackage`:
-
-* `dubLock`: A lockfile generated by `dub-to-nix` from the source of the package. Can be either a path to the file, or an attrset already parsed with `lib.importJSON`.
-  The latter useful if the package uses `dub` dependencies not already in the lockfile. (e.g. if the package calls `dub run some-dub-package` manually)
-* `dubBuildType ? "release"`: The build type to pass to `dub build` as a value for the `--build=` flag.
-* `dubFlags ? []`: The flags to pass to `dub build` and `dub test`.
-* `dubBuildFlags ? []`: The flags to pass to `dub build`.
-* `dubTestFlags ? []`: The flags to pass to `dub test`.
-* `compiler ? ldc`: The D compiler to be used by `dub`.

doc/languages-frameworks/dotnet.section.md

@@ -93,11 +93,7 @@ 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 have `.sln` (entire solution) or `.csproj` (single project) file extensions. This can be a list of multiple projects as well. When omitted, will attempt to find and build the solution (`.sln`). If running into problems, make sure to set it to a file (or a list of files) with the `.csproj` extension - building applications as entire solutions is not fully supported by the .NET CLI.
-* `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`. If the argument is a derivation, it will be used directly and assume it has the same output as `mkNugetDeps`.
-::: {.note}
-For more detail about managing the `deps.nix` file, see [Generating and updating NuGet dependencies](#generating-and-updating-nuget-dependencies)
-:::
-
+* `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`.
 * `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:
@@ -134,7 +130,7 @@ Here is an example `default.nix`, using some of the previously discussed argumen
 { lib, buildDotnetModule, dotnetCorePackages, ffmpeg }:
 
 let
-  referencedProject = import ../../bar { /* ... */ };
+  referencedProject = import ../../bar { ... };
 in buildDotnetModule rec {
   pname = "someDotnetApplication";
   version = "0.1";
@@ -148,7 +144,7 @@ in buildDotnetModule rec {
 
   projectReferences = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure.
 
-  dotnet-sdk = dotnetCorePackages.sdk_6_0;
+  dotnet-sdk = dotnetCorePackages.sdk_6.0;
   dotnet-runtime = dotnetCorePackages.runtime_6_0;
 
   executables = [ "foo" ]; # This wraps "$out/lib/$pname/foo" to `$out/bin/foo`.
@@ -160,8 +156,6 @@ in buildDotnetModule rec {
 }
 ```
 
-Keep in mind that you can tag the [`@NixOS/dotnet`](https://github.com/orgs/nixos/teams/dotnet) team for help and code review.
-
 ## Dotnet global tools {#dotnet-global-tools}
 
 [.NET Global tools](https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools) are a mechanism provided by the dotnet CLI to install .NET binaries from Nuget packages.
@@ -210,51 +204,13 @@ buildDotnetGlobalTool {
 
   nugetSha256 = "sha256-ZG2HFyKYhVNVYd2kRlkbAjZJq88OADe3yjxmLuxXDUo=";
 
-  meta = {
+  meta = with lib; {
     homepage = "https://cmd.petabridge.com/index.html";
     changelog = "https://cmd.petabridge.com/articles/RELEASE_NOTES.html";
-    license = lib.licenses.unfree;
-    platforms = lib.platforms.linux;
+    license = licenses.unfree;
+    platforms = platforms.linux;
   };
 }
 ```
-## Generating and updating NuGet dependencies {#generating-and-updating-nuget-dependencies}
-
-First, restore the packages to the `out` directory, ensure you have cloned
-the upstream repository and you are inside it.
-
-```bash
-$ dotnet restore --packages out
-  Determining projects to restore...
-  Restored /home/lychee/Celeste64/Celeste64.csproj (in 1.21 sec).
-```
-
-Next, use `nuget-to-nix` tool provided in nixpkgs to generate a lockfile to `deps.nix` from
-the packages inside the `out` directory.
-
-```bash
-$ nuget-to-nix out > deps.nix
-```
-Which `nuget-to-nix` will generate an output similar to below
-```nix
-{ fetchNuGet }: [
-  (fetchNuGet { pname = "FosterFramework"; version = "0.1.15-alpha"; sha256 = "0pzsdfbsfx28xfqljcwy100xhbs6wyx0z1d5qxgmv3l60di9xkll"; })
-  (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.linux-x64"; version = "8.0.1"; sha256 = "1gjz379y61ag9whi78qxx09bwkwcznkx2mzypgycibxk61g11da1"; })
-  (fetchNuGet { pname = "Microsoft.NET.ILLink.Tasks"; version = "8.0.1"; sha256 = "1drbgqdcvbpisjn8mqfgba1pwb6yri80qc4mfvyczqwrcsj5k2ja"; })
-  (fetchNuGet { pname = "Microsoft.NETCore.App.Runtime.linux-x64"; version = "8.0.1"; sha256 = "1g5b30f4l8a1zjjr3b8pk9mcqxkxqwa86362f84646xaj4iw3a4d"; })
-  (fetchNuGet { pname = "SharpGLTF.Core"; version = "1.0.0-alpha0031"; sha256 = "0ln78mkhbcxqvwnf944hbgg24vbsva2jpih6q3x82d3h7rl1pkh6"; })
-  (fetchNuGet { pname = "SharpGLTF.Runtime"; version = "1.0.0-alpha0031"; sha256 = "0lvb3asi3v0n718qf9y367km7qpkb9wci38y880nqvifpzllw0jg"; })
-  (fetchNuGet { pname = "Sledge.Formats"; version = "1.2.2"; sha256 = "1y0l66m9rym0p1y4ifjlmg3j9lsmhkvbh38frh40rpvf1axn2dyh"; })
-  (fetchNuGet { pname = "Sledge.Formats.Map"; version = "1.1.5"; sha256 = "1bww60hv9xcyxpvkzz5q3ybafdxxkw6knhv97phvpkw84pd0jil6"; })
-  (fetchNuGet { pname = "System.Numerics.Vectors"; version = "4.5.0"; sha256 = "1kzrj37yzawf1b19jq0253rcs8hsq1l2q8g69d7ipnhzb0h97m59"; })
-]
-```
-
-Finally, you move the `deps.nix` file to the appropriate location to be used by `nugetDeps`, then you're all set!
-
-If you ever need to update the dependencies of a package, you instead do
-
-* `nix-build -A package.fetch-deps` to generate the update script for `package`
-* Run `./result deps.nix` to regenerate the lockfile to `deps.nix`, keep in mind if a location isn't provided, it will write to a temporary path instead
-* Finally, move the file where needed and look at its contents to confirm it has updated the dependencies.
 
+When packaging a new .NET application in nixpkgs, you can tag the [`@NixOS/dotnet`](https://github.com/orgs/nixos/teams/dotnet) team for help and code review.

doc/languages-frameworks/emscripten.section.md

@@ -86,9 +86,9 @@ One advantage is that when `pkgs.zlib` is updated, it will automatically update
 
   postPatch = pkgs.lib.optionalString pkgs.stdenv.isDarwin ''
     substituteInPlace configure \
-      --replace-fail '/usr/bin/libtool' 'ar' \
-      --replace-fail 'AR="libtool"' 'AR="ar"' \
-      --replace-fail 'ARFLAGS="-o"' 'ARFLAGS="-r"'
+      --replace '/usr/bin/libtool' 'ar' \
+      --replace 'AR="libtool"' 'AR="ar"' \
+      --replace 'ARFLAGS="-o"' 'ARFLAGS="-r"'
   '';
 })
 ```

doc/languages-frameworks/gnome.section.md

@@ -8,7 +8,7 @@ Programs in the GNOME universe are written in various languages but they all use
 
 [GSettings](https://developer.gnome.org/gio/stable/GSettings.html) API is often used for storing settings. GSettings schemas are required, to know the type and other metadata of the stored values. GLib looks for `glib-2.0/schemas/gschemas.compiled` files inside the directories of `XDG_DATA_DIRS`.
 
-On Linux, GSettings API is implemented using [dconf](https://gitlab.gnome.org/GNOME/dconf) backend. You will need to add `dconf` [GIO module](#ssec-gnome-gio-modules) to `GIO_EXTRA_MODULES` variable, otherwise the `memory` backend will be used and the saved settings will not be persistent.
+On Linux, GSettings API is implemented using [dconf](https://wiki.gnome.org/Projects/dconf) backend. You will need to add `dconf` [GIO module](#ssec-gnome-gio-modules) to `GIO_EXTRA_MODULES` variable, otherwise the `memory` backend will be used and the saved settings will not be persistent.
 
 Last you will need the dconf database D-Bus service itself. You can enable it using `programs.dconf.enable`.
 
@@ -47,7 +47,6 @@ When an application uses icons, an icon theme should be available in `XDG_DATA_D
 In the rare case you need to use icons from dependencies (e.g. when an app forces an icon theme), you can use the following to pick them up:
 
 ```nix
-{
   buildInputs = [
     pantheon.elementary-icon-theme
   ];
@@ -57,7 +56,6 @@ In the rare case you need to use icons from dependencies (e.g. when an app force
       --prefix XDG_DATA_DIRS : "$XDG_ICON_DIRS"
     )
   '';
-}
 ```
 
 To avoid costly file system access when locating icons, GTK, [as well as Qt](https://woboq.com/blog/qicon-reads-gtk-icon-cache-in-qt57.html), can rely on `icon-theme.cache` files from the themes' top-level directories. These files are generated using `gtk-update-icon-cache`, which is expected to be run whenever an icon is added or removed to an icon theme (typically an application icon into `hicolor` theme) and some programs do indeed run this after icon installation. However, since packages are installed into their own prefix by Nix, this would lead to conflicts. For that reason, `gtk3` provides a [setup hook](#ssec-gnome-hooks-gtk-drop-icon-theme-cache) that will clean the file from installation. Since most applications only ship their own icon that will be loaded on start-up, it should not affect them too much. On the other hand, icon themes are much larger and more widely used so we need to cache them. Because we recommend installing icon themes globally, we will generate the cache files from all packages in a profile using a NixOS module. You can enable the cache generation using `gtk.iconCache.enable` option if your desktop environment does not already do that.
@@ -76,69 +74,61 @@ Previously, a GTK theme needed to be in `XDG_DATA_DIRS`. This is no longer neces
 
 ### GObject introspection typelibs {#ssec-gnome-typelibs}
 
-[GObject introspection](https://gitlab.gnome.org/GNOME/gobject-introspection) allows applications to use C libraries in other languages easily. It does this through `typelib` files searched in `GI_TYPELIB_PATH`.
+[GObject introspection](https://wiki.gnome.org/Projects/GObjectIntrospection) allows applications to use C libraries in other languages easily. It does this through `typelib` files searched in `GI_TYPELIB_PATH`.
 
 ### Various plug-ins {#ssec-gnome-plugins}
 
-If your application uses [GStreamer](https://gstreamer.freedesktop.org/) or [Grilo](https://gitlab.gnome.org/GNOME/grilo), you should set `GST_PLUGIN_SYSTEM_PATH_1_0` and `GRL_PLUGIN_PATH`, respectively.
+If your application uses [GStreamer](https://gstreamer.freedesktop.org/) or [Grilo](https://wiki.gnome.org/Projects/Grilo), you should set `GST_PLUGIN_SYSTEM_PATH_1_0` and `GRL_PLUGIN_PATH`, respectively.
 
-## Onto `wrapGApps*` hooks {#ssec-gnome-hooks}
+## Onto `wrapGAppsHook` {#ssec-gnome-hooks}
 
 Given the requirements above, the package expression would become messy quickly:
 
 ```nix
-{
-  preFixup = ''
-    for f in $(find $out/bin/ $out/libexec/ -type f -executable); do
-      wrapProgram "$f" \
-        --prefix GIO_EXTRA_MODULES : "${getLib dconf}/lib/gio/modules" \
-        --prefix XDG_DATA_DIRS : "$out/share" \
-        --prefix XDG_DATA_DIRS : "$out/share/gsettings-schemas/${name}" \
-        --prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \
-        --prefix XDG_DATA_DIRS : "${hicolor-icon-theme}/share" \
-        --prefix GI_TYPELIB_PATH : "${lib.makeSearchPath "lib/girepository-1.0" [ pango json-glib ]}"
-    done
-  '';
-}
+preFixup = ''
+  for f in $(find $out/bin/ $out/libexec/ -type f -executable); do
+    wrapProgram "$f" \
+      --prefix GIO_EXTRA_MODULES : "${getLib dconf}/lib/gio/modules" \
+      --prefix XDG_DATA_DIRS : "$out/share" \
+      --prefix XDG_DATA_DIRS : "$out/share/gsettings-schemas/${name}" \
+      --prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \
+      --prefix XDG_DATA_DIRS : "${hicolor-icon-theme}/share" \
+      --prefix GI_TYPELIB_PATH : "${lib.makeSearchPath "lib/girepository-1.0" [ pango json-glib ]}"
+  done
+'';
 ```
 
-Fortunately, we have a [family of hooks]{#ssec-gnome-hooks-wrapgappshook} that automate this. They work in conjunction with other setup hooks that populate environment variables, and will then wrap all executables in `bin` and `libexec` directories using said variables.
+Fortunately, there is [`wrapGAppsHook`]{#ssec-gnome-hooks-wrapgappshook}. It works in conjunction with other setup hooks that populate environment variables, and it will then wrap all executables in `bin` and `libexec` directories using said variables.
 
-- [`wrapGAppsHook3`]{#ssec-gnome-hooks-wrapgappshook3} for GTK 3 apps. For convenience, it also adds `dconf.lib` for a GIO module implementing a GSettings backend using `dconf`, `gtk3` for GSettings schemas, and `librsvg` for GdkPixbuf loader to the closure.
-- [`wrapGAppsHook4`]{#ssec-gnome-hooks-wrapgappshook4} for GTK 4 apps. Same as `wrapGAppsHook3` but replaces `gtk3` with `gtk4`.
-- [`wrapGAppsNoGuiHook`]{#ssec-gnome-hooks-wrapgappsnoguihook} for programs without a graphical interface. Same as the above but does not bring `gtk3` and `librsvg` into the closure.
+For convenience, it also adds `dconf.lib` for a GIO module implementing a GSettings backend using `dconf`, `gtk3` for GSettings schemas, and `librsvg` for GdkPixbuf loader to the closure. There is also [`wrapGAppsHook4`]{#ssec-gnome-hooks-wrapgappshook4}, which replaces GTK 3 with GTK 4. And in case you are packaging a program without a graphical interface, you might want to use [`wrapGAppsNoGuiHook`]{#ssec-gnome-hooks-wrapgappsnoguihook}, which runs the same script as `wrapGAppsHook` but does not bring `gtk3` and `librsvg` into the closure.
 
-The hooks do the the following:
+- `wrapGAppsHook` itself will add the package’s `share` directory to `XDG_DATA_DIRS`.
 
-- `wrapGApps*` hook itself will add the package’s `share` directory to `XDG_DATA_DIRS`.
+- []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGAppsHook` will prepend it to `XDG_DATA_DIRS`.
 
-- []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGApps*` hook will prepend it to `XDG_DATA_DIRS`.
-
-- []{#ssec-gnome-hooks-gdk-pixbuf} `gdk-pixbuf` setup hook will populate `GDK_PIXBUF_MODULE_FILE` with the path to biggest `loaders.cache` file from the dependencies containing [GdkPixbuf loaders](#ssec-gnome-gdk-pixbuf-loaders). This works fine when there are only two packages containing loaders (`gdk-pixbuf` and e.g. `librsvg`) – it will choose the second one, reasonably expecting that it will be bigger since it describes extra loader in addition to the default ones. But when there are more than two loader packages, this logic will break. One possible solution would be constructing a custom cache file for each package containing a program like `services/x11/gdk-pixbuf.nix` NixOS module does. `wrapGApps*` hook copies the `GDK_PIXBUF_MODULE_FILE` environment variable into the produced wrapper.
+- []{#ssec-gnome-hooks-gdk-pixbuf} `gdk-pixbuf` setup hook will populate `GDK_PIXBUF_MODULE_FILE` with the path to biggest `loaders.cache` file from the dependencies containing [GdkPixbuf loaders](#ssec-gnome-gdk-pixbuf-loaders). This works fine when there are only two packages containing loaders (`gdk-pixbuf` and e.g. `librsvg`) – it will choose the second one, reasonably expecting that it will be bigger since it describes extra loader in addition to the default ones. But when there are more than two loader packages, this logic will break. One possible solution would be constructing a custom cache file for each package containing a program like `services/x11/gdk-pixbuf.nix` NixOS module does. `wrapGAppsHook` copies the `GDK_PIXBUF_MODULE_FILE` environment variable into the produced wrapper.
 
 - []{#ssec-gnome-hooks-gtk-drop-icon-theme-cache} One of `gtk3`’s setup hooks will remove `icon-theme.cache` files from package’s icon theme directories to avoid conflicts. Icon theme packages should prevent this with `dontDropIconThemeCache = true;`.
 
-- []{#ssec-gnome-hooks-dconf} `dconf.lib` is a dependency of `wrapGApps*` hook, which then also adds it to the `GIO_EXTRA_MODULES` variable.
+- []{#ssec-gnome-hooks-dconf} `dconf.lib` is a dependency of `wrapGAppsHook`, which then also adds it to the `GIO_EXTRA_MODULES` variable.
 
 - []{#ssec-gnome-hooks-hicolor-icon-theme} `hicolor-icon-theme`’s setup hook will add icon themes to `XDG_ICON_DIRS`.
 
-- []{#ssec-gnome-hooks-gobject-introspection} `gobject-introspection` setup hook populates `GI_TYPELIB_PATH` variable with `lib/girepository-1.0` directories of dependencies, which is then added to wrapper by `wrapGApps*` hook. It also adds `share` directories of dependencies to `XDG_DATA_DIRS`, which is intended to promote GIR files but it also [pollutes the closures](https://github.com/NixOS/nixpkgs/issues/32790) of packages using `wrapGApps*` hook.
+- []{#ssec-gnome-hooks-gobject-introspection} `gobject-introspection` setup hook populates `GI_TYPELIB_PATH` variable with `lib/girepository-1.0` directories of dependencies, which is then added to wrapper by `wrapGAppsHook`. It also adds `share` directories of dependencies to `XDG_DATA_DIRS`, which is intended to promote GIR files but it also [pollutes the closures](https://github.com/NixOS/nixpkgs/issues/32790) of packages using `wrapGAppsHook`.
 
-- []{#ssec-gnome-hooks-gst-grl-plugins} Setup hooks of `gst_all_1.gstreamer` and `grilo` will populate the `GST_PLUGIN_SYSTEM_PATH_1_0` and `GRL_PLUGIN_PATH` variables, respectively, which will then be added to the wrapper by `wrapGApps*` hook.
+- []{#ssec-gnome-hooks-gst-grl-plugins} Setup hooks of `gst_all_1.gstreamer` and `grilo` will populate the `GST_PLUGIN_SYSTEM_PATH_1_0` and `GRL_PLUGIN_PATH` variables, respectively, which will then be added to the wrapper by `wrapGAppsHook`.
 
 You can also pass additional arguments to `makeWrapper` using `gappsWrapperArgs` in `preFixup` hook:
 
 ```nix
-{
-  preFixup = ''
-    gappsWrapperArgs+=(
-      # Thumbnailers
-      --prefix XDG_DATA_DIRS : "${gdk-pixbuf}/share"
-      --prefix XDG_DATA_DIRS : "${librsvg}/share"
-      --prefix XDG_DATA_DIRS : "${shared-mime-info}/share"
-    )
-  '';
-}
+preFixup = ''
+  gappsWrapperArgs+=(
+    # Thumbnailers
+    --prefix XDG_DATA_DIRS : "${gdk-pixbuf}/share"
+    --prefix XDG_DATA_DIRS : "${librsvg}/share"
+    --prefix XDG_DATA_DIRS : "${shared-mime-info}/share"
+  )
+'';
 ```
 
 ## Updating GNOME packages {#ssec-gnome-updating}
@@ -149,15 +139,15 @@ Most GNOME package offer [`updateScript`](#var-passthru-updateScript), it is the
 
 ### `GLib-GIO-ERROR **: 06:04:50.903: No GSettings schemas are installed on the system` {#ssec-gnome-common-issues-no-schemas}
 
-There are no schemas available in `XDG_DATA_DIRS`. Temporarily add a random package containing schemas like `gsettings-desktop-schemas` to `buildInputs`. [`glib`](#ssec-gnome-hooks-glib) and [`wrapGApps*`](#ssec-gnome-hooks-wrapgappshook) setup hooks will take care of making the schemas available to application and you will see the actual missing schemas with the [next error](#ssec-gnome-common-issues-missing-schema). Or you can try looking through the source code for the actual schemas used.
+There are no schemas available in `XDG_DATA_DIRS`. Temporarily add a random package containing schemas like `gsettings-desktop-schemas` to `buildInputs`. [`glib`](#ssec-gnome-hooks-glib) and [`wrapGAppsHook`](#ssec-gnome-hooks-wrapgappshook) setup hooks will take care of making the schemas available to application and you will see the actual missing schemas with the [next error](#ssec-gnome-common-issues-missing-schema). Or you can try looking through the source code for the actual schemas used.
 
 ### `GLib-GIO-ERROR **: 06:04:50.903: Settings schema ‘org.gnome.foo’ is not installed` {#ssec-gnome-common-issues-missing-schema}
 
 Package is missing some GSettings schemas. You can find out the package containing the schema with `nix-locate org.gnome.foo.gschema.xml` and let the hooks handle the wrapping as [above](#ssec-gnome-common-issues-no-schemas).
 
-### When using `wrapGApps*` hook with special derivers you can end up with double wrapped binaries. {#ssec-gnome-common-issues-double-wrapped}
+### When using `wrapGAppsHook` with special derivers you can end up with double wrapped binaries. {#ssec-gnome-common-issues-double-wrapped}
 
-This is because derivers like `python.pkgs.buildPythonApplication` or `qt5.mkDerivation` have setup-hooks automatically added that produce wrappers with makeWrapper. The simplest way to workaround that is to disable the `wrapGApps*` hook automatic wrapping with `dontWrapGApps = true;` and pass the arguments it intended to pass to makeWrapper to another.
+This is because derivers like `python.pkgs.buildPythonApplication` or `qt5.mkDerivation` have setup-hooks automatically added that produce wrappers with makeWrapper. The simplest way to workaround that is to disable the `wrapGAppsHook` automatic wrapping with `dontWrapGApps = true;` and pass the arguments it intended to pass to makeWrapper to another.
 
 In the case of a Python application it could look like:
 
@@ -167,9 +157,9 @@ python3.pkgs.buildPythonApplication {
   version = "3.32.2";
 
   nativeBuildInputs = [
-    wrapGAppsHook3
+    wrapGAppsHook
     gobject-introspection
-    # ...
+    ...
   ];
 
   dontWrapGApps = true;
@@ -189,9 +179,9 @@ mkDerivation {
   version = "3.47.0";
 
   nativeBuildInputs = [
-    wrapGAppsHook3
+    wrapGAppsHook
     qmake
-    # ...
+    ...
   ];
 
   dontWrapGApps = true;

doc/languages-frameworks/go.section.md

@@ -1,63 +1,46 @@
 # Go {#sec-language-go}
 
-## Building Go modules with `buildGoModule` {#ssec-language-go}
+## Go modules {#ssec-language-go}
 
-The function `buildGoModule` builds Go programs managed with Go modules. It builds [Go Modules](https://go.dev/wiki/Modules) through a two phase build:
+The function `buildGoModule` builds Go programs managed with Go modules. It builds a [Go Modules](https://github.com/golang/go/wiki/Modules) through a two phase build:
 
-- An intermediate fetcher derivation called `goModules`. This derivation will be used to fetch all the dependencies of the Go module.
+- An intermediate fetcher derivation. This derivation will be used to fetch all of the dependencies of the Go module.
 - A final derivation will use the output of the intermediate derivation to build the binaries and produce the final output.
 
-### Attributes of `buildGoModule` {#buildgomodule-parameters}
-
-The `buildGoModule` function accepts the following parameters in addition to the [attributes accepted by both Go builders](#ssec-go-common-attributes):
-
-- `vendorHash`: is the hash of the output of the intermediate fetcher derivation (the dependencies of the Go modules).
-
-  `vendorHash` can be set to `null`.
-  In that case, rather than fetching the dependencies, the dependencies already vendored in the `vendor` directory of the source repo will be used.
-
-  To avoid updating this field when dependencies change, run `go mod vendor` in your source repo and set `vendorHash = null;`.
-  You can read more about [vendoring in the Go documentation](https://go.dev/ref/mod#vendoring).
-
-  To obtain the actual hash, set `vendorHash = lib.fakeHash;` and run the build ([more details here](#sec-source-hashes)).
-- `proxyVendor`: If `true`, the intermediate fetcher downloads dependencies from the
-  [Go module proxy](https://go.dev/ref/mod#module-proxy) (using `go mod download`) instead of vendoring them. The resulting
-  [module cache](https://go.dev/ref/mod#module-cache) is then passed to the final derivation.
-
-  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-dependent `vendorHash` checksums.
-
-  Defaults to `false`.
-- `modPostBuild`: Shell commands to run after the build of the goModules executes `go mod vendor`, and before calculating fixed output derivation's `vendorHash`.
-  Note that if you change this attribute, you need to update `vendorHash` attribute.
-- `modRoot`: The root directory of the Go module that contains the `go.mod` file.
-  Defaults to `./`, which is the root of `src`.
-
 ### Example for `buildGoModule` {#ex-buildGoModule}
 
-The following is an example expression using `buildGoModule`:
+In the following is an example expression using `buildGoModule`, the following arguments are of special significance to the function:
+
+- `vendorHash`: is the hash of the output of the intermediate fetcher derivation.
+
+  `vendorHash` can also be set to `null`.
+  In that case, rather than fetching the dependencies and vendoring them, the dependencies vendored in the source repo will be used.
+
+  To avoid updating this field when dependencies change, run `go mod vendor` in your source repo and set `vendorHash = null;`
+
+  To obtain the actual hash, set `vendorHash = lib.fakeHash;` and run the build ([more details here](#sec-source-hashes)).
+- `proxyVendor`: Fetches (go mod download) and proxies the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build or if any dependency has case-insensitive conflicts which will produce platform-dependent `vendorHash` checksums.
+- `modPostBuild`: Shell commands to run after the build of the goModules executes `go mod vendor`, and before calculating fixed output derivation's `vendorHash`. Note that if you change this attribute, you need to update `vendorHash` attribute.
 
 ```nix
-{
-  pet = buildGoModule rec {
-    pname = "pet";
-    version = "0.3.4";
+pet = buildGoModule rec {
+  pname = "pet";
+  version = "0.3.4";
 
-    src = fetchFromGitHub {
-      owner = "knqyf263";
-      repo = "pet";
-      rev = "v${version}";
-      hash = "sha256-Gjw1dRrgM8D3G7v6WIM2+50r4HmTXvx0Xxme2fH9TlQ=";
-    };
+  src = fetchFromGitHub {
+    owner = "knqyf263";
+    repo = "pet";
+    rev = "v${version}";
+    hash = "sha256-Gjw1dRrgM8D3G7v6WIM2+50r4HmTXvx0Xxme2fH9TlQ=";
+  };
 
-    vendorHash = "sha256-ciBIR+a1oaYH+H1PcC8cD8ncfJczk1IiJ8iYNM+R6aA=";
+  vendorHash = "sha256-ciBIR+a1oaYH+H1PcC8cD8ncfJczk1IiJ8iYNM+R6aA=";
 
-    meta = {
-      description = "Simple command-line snippet manager, written in Go";
-      homepage = "https://github.com/knqyf263/pet";
-      license = lib.licenses.mit;
-      maintainers = with lib.maintainers; [ kalbasit ];
-    };
+  meta = with lib; {
+    description = "Simple command-line snippet manager, written in Go";
+    homepage = "https://github.com/knqyf263/pet";
+    license = licenses.mit;
+    maintainers = with maintainers; [ kalbasit ];
   };
 }
 ```
@@ -68,28 +51,26 @@ The function `buildGoPackage` builds legacy Go programs, not supporting Go modul
 
 ### Example for `buildGoPackage` {#example-for-buildgopackage}
 
-In the following is an example expression using `buildGoPackage`, the following arguments are of special significance to the function:
+In the following is an example expression using buildGoPackage, the following arguments are of special significance to the function:
 
 - `goPackagePath` specifies the package's canonical Go import path.
 - `goDeps` is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate `deps.nix` file for readability. The dependency data structure is described below.
 
 ```nix
-{
-  deis = buildGoPackage rec {
-    pname = "deis";
-    version = "1.13.0";
+deis = buildGoPackage rec {
+  pname = "deis";
+  version = "1.13.0";
 
-    goPackagePath = "github.com/deis/deis";
+  goPackagePath = "github.com/deis/deis";
 
-    src = fetchFromGitHub {
-      owner = "deis";
-      repo = "deis";
-      rev = "v${version}";
-      hash = "sha256-XCPD4LNWtAd8uz7zyCLRfT8rzxycIUmTACjU03GnaeM=";
-    };
-
-    goDeps = ./deps.nix;
+  src = fetchFromGitHub {
+    owner = "deis";
+    repo = "deis";
+    rev = "v${version}";
+    hash = "sha256-XCPD4LNWtAd8uz7zyCLRfT8rzxycIUmTACjU03GnaeM=";
   };
+
+  goDeps = ./deps.nix;
 }
 ```
 
@@ -122,7 +103,7 @@ The `goDeps` attribute can be imported from a separate `nix` file that defines w
 ]
 ```
 
-To extract dependency information from a Go package in automated way use [go2nix (deprecated)](https://github.com/kamilchm/go2nix). It can produce complete derivation and `goDeps` file for Go programs.
+To extract dependency information from a Go package in automated way use [go2nix](https://github.com/kamilchm/go2nix). It can produce complete derivation and `goDeps` file for Go programs.
 
 You may use Go packages installed into the active Nix profiles by adding the following to your ~/.bashrc:
 
@@ -132,7 +113,7 @@ for p in $NIX_PROFILES; do
 done
 ```
 
-## Attributes used by both builders {#ssec-go-common-attributes}
+## Attributes used by the builders {#ssec-go-common-attributes}
 
 Many attributes [controlling the build phase](#variables-controlling-the-build-phase) are respected by both `buildGoModule` and `buildGoPackage`. Note that `buildGoModule` reads the following attributes also when building the `vendor/` goModules fixed output derivation as well:
 
@@ -142,148 +123,44 @@ Many attributes [controlling the build phase](#variables-controlling-the-build-p
 - [`patchFlags`](#var-stdenv-patchFlags)
 - [`postPatch`](#var-stdenv-postPatch)
 - [`preBuild`](#var-stdenv-preBuild)
-- `env`: useful for passing down variables such as `GOWORK`.
-
-To control test execution of the build derivation, the following attributes are of interest:
-
-- [`checkInputs`](#var-stdenv-checkInputs)
-- [`preCheck`](#var-stdenv-preCheck)
-- [`checkFlags`](#var-stdenv-checkFlags)
 
 In addition to the above attributes, and the many more variables respected also by `stdenv.mkDerivation`, both `buildGoModule` and `buildGoPackage` respect Go-specific attributes that tweak them to behave slightly differently:
 
 ### `ldflags` {#var-go-ldflags}
 
-A string list of flags to pass to the Go linker tool via the `-ldflags` argument of `go build`. Possible values can be retrieved by running `go tool link --help`.
-The most common use case for this argument is to make the resulting executable aware of its own version by injecting the value of string variable using the `-X` flag. For example:
+Arguments to pass to the Go linker tool via the `-ldflags` argument of `go build`. The most common use case for this argument is to make the resulting executable aware of its own version. For example:
 
 ```nix
-{
   ldflags = [
+    "-s" "-w"
     "-X main.Version=${version}"
     "-X main.Commit=${version}"
   ];
-}
 ```
 
 ### `tags` {#var-go-tags}
 
-A string list of [Go build tags (also called build constraints)](https://pkg.go.dev/cmd/go#hdr-Build_constraints) that are passed via the `-tags` argument of `go build`.  These constraints control whether Go files from the source should be included in the build. For example:
+Arguments to pass to the Go via the `-tags` argument of `go build`. For example:
 
 ```nix
-{
   tags = [
     "production"
     "sqlite"
   ];
-}
 ```
 
-Tags can also be set conditionally:
-
 ```nix
-{
   tags = [ "production" ] ++ lib.optionals withSqlite [ "sqlite" ];
-}
 ```
 
 ### `deleteVendor` {#var-go-deleteVendor}
 
-If set to `true`, removes the pre-existing vendor directory. This should only be used if the dependencies included in the vendor folder are broken or incomplete.
+Removes the pre-existing vendor directory. This should only be used if the dependencies included in the vendor folder are broken or incomplete.
 
 ### `subPackages` {#var-go-subPackages}
 
 Specified as a string or list of strings. Limits the builder from building child packages that have not been listed. If `subPackages` is not specified, all child packages will be built.
 
-Many Go projects keep the main package in a `cmd` directory.
-Following example could be used to only build the example-cli and example-server binaries:
-
-```nix
-{
-  subPackages = [
-    "cmd/example-cli"
-    "cmd/example-server"
-  ];
-}
-```
-
 ### `excludedPackages` {#var-go-excludedPackages}
 
-Specified as a string or list of strings. Causes the builder to skip building child packages that match any of the provided values.
-
-### `CGO_ENABLED` {#var-go-CGO_ENABLED}
-
-When set to `0`, the [cgo](https://pkg.go.dev/cmd/cgo) command is disabled. As consequence, the build
-program can't link against C libraries anymore, and the resulting binary is statically linked.
-
-When building with CGO enabled, Go will likely link some packages from the Go standard library against C libraries,
-even when the target code does not explicitly call into C dependencies. With `CGO_ENABLED = 0;`, Go
-will always use the Go native implementation of these internal packages. For reference see
-[net](https://pkg.go.dev/net#hdr-Name_Resolution) and [os/user](https://pkg.go.dev/os/user#pkg-overview) packages.
-Notice that the decision whether these packages should use native Go implementation or not can also be controlled
-on a per package level using build tags (`tags`). In case CGO is disabled, these tags have no additional effect.
-
-When a Go program depends on C libraries, place those dependencies in `buildInputs`:
-
-```nix
-{
-  buildInputs = [
-    libvirt
-    libxml2
-  ];
-}
-```
-
-`CGO_ENABLED` defaults to `1`.
-
-### `enableParallelBuilding` {#var-go-enableParallelBuilding}
-
-Whether builds and tests should run in parallel.
-
-Defaults to `true`.
-
-### `allowGoReference` {#var-go-allowGoReference}
-
-Whether the build result should be allowed to contain references to the Go tool chain. This might be needed for programs that are coupled with the compiler, but shouldn't be set without a good reason.
-
-Defaults to `false`
-
-## Controlling the Go environment {#ssec-go-environment}
-
-The Go build can be further tweaked by setting environment variables. In most cases, this isn't needed. Possible values can be found in the [Go documentation of accepted environment variables](https://pkg.go.dev/cmd/go#hdr-Environment_variables). Notice that some of these flags are set by the builder itself and should not be set explicitly. If in doubt, grep the implementation of the builder.
-
-## Skipping tests {#ssec-skip-go-tests}
-
-`buildGoModule` runs tests by default. Failing tests can be disabled using the `checkFlags` parameter.
-This is done with the [`-skip` or `-run`](https://pkg.go.dev/cmd/go#hdr-Testing_flags) flags of the `go test` command.
-
-For example, only a selection of tests could be run with:
-
-```nix
-{
-  # -run and -skip accept regular expressions
-  checkFlags = [
-    "-run=^Test(Simple|Fast)$"
-  ];
-}
-```
-
-If a larger amount of tests should be skipped, the following pattern can be used:
-
-```nix
-{
-  checkFlags =
-    let
-      # Skip tests that require network access
-      skippedTests = [
-        "TestNetwork"
-        "TestDatabase/with_mysql" # exclude only the subtest
-        "TestIntegration"
-      ];
-    in
-    [ "-skip=^${builtins.concatStringsSep "$|^" skippedTests}$" ];
-}
-```
-
-To disable tests altogether, set `doCheck = false;`.
-`buildGoPackage` does not execute tests by default.
+Specified as a string or list of strings. Causes the builder to skip building child packages that match any of the provided values. If `excludedPackages` is not specified, all child packages will be built.

doc/languages-frameworks/haskell.section.md

@@ -70,42 +70,39 @@ compilers like this:
 ```console
 $ nix-env -f '<nixpkgs>' -qaP -A haskell.compiler
 haskell.compiler.ghc810                  ghc-8.10.7
+haskell.compiler.ghc88                   ghc-8.8.4
 haskell.compiler.ghc90                   ghc-9.0.2
+haskell.compiler.ghc924                  ghc-9.2.4
 haskell.compiler.ghc925                  ghc-9.2.5
 haskell.compiler.ghc926                  ghc-9.2.6
-haskell.compiler.ghc927                  ghc-9.2.7
-haskell.compiler.ghc92                   ghc-9.2.8
-haskell.compiler.ghc945                  ghc-9.4.5
-haskell.compiler.ghc946                  ghc-9.4.6
-haskell.compiler.ghc947                  ghc-9.4.7
-haskell.compiler.ghc94                   ghc-9.4.8
-haskell.compiler.ghc963                  ghc-9.6.3
-haskell.compiler.ghc96                   ghc-9.6.4
-haskell.compiler.ghc98                   ghc-9.8.1
-haskell.compiler.ghcHEAD                 ghc-9.9.20231121
+haskell.compiler.ghc92                   ghc-9.2.7
+haskell.compiler.ghc942                  ghc-9.4.2
+haskell.compiler.ghc943                  ghc-9.4.3
+haskell.compiler.ghc94                   ghc-9.4.4
+haskell.compiler.ghcHEAD                 ghc-9.7.20221224
+haskell.compiler.ghc8102Binary           ghc-binary-8.10.2
+haskell.compiler.ghc8102BinaryMinimal    ghc-binary-8.10.2
+haskell.compiler.ghc8107BinaryMinimal    ghc-binary-8.10.7
 haskell.compiler.ghc8107Binary           ghc-binary-8.10.7
 haskell.compiler.ghc865Binary            ghc-binary-8.6.5
 haskell.compiler.ghc924Binary            ghc-binary-9.2.4
-haskell.compiler.integer-simple.ghc8107  ghc-integer-simple-8.10.7
+haskell.compiler.ghc924BinaryMinimal     ghc-binary-9.2.4
 haskell.compiler.integer-simple.ghc810   ghc-integer-simple-8.10.7
+haskell.compiler.integer-simple.ghc8107  ghc-integer-simple-8.10.7
+haskell.compiler.integer-simple.ghc88    ghc-integer-simple-8.8.4
+haskell.compiler.integer-simple.ghc884   ghc-integer-simple-8.8.4
 haskell.compiler.native-bignum.ghc90     ghc-native-bignum-9.0.2
 haskell.compiler.native-bignum.ghc902    ghc-native-bignum-9.0.2
+haskell.compiler.native-bignum.ghc924    ghc-native-bignum-9.2.4
 haskell.compiler.native-bignum.ghc925    ghc-native-bignum-9.2.5
 haskell.compiler.native-bignum.ghc926    ghc-native-bignum-9.2.6
+haskell.compiler.native-bignum.ghc92     ghc-native-bignum-9.2.7
 haskell.compiler.native-bignum.ghc927    ghc-native-bignum-9.2.7
-haskell.compiler.native-bignum.ghc92     ghc-native-bignum-9.2.8
-haskell.compiler.native-bignum.ghc928    ghc-native-bignum-9.2.8
-haskell.compiler.native-bignum.ghc945    ghc-native-bignum-9.4.5
-haskell.compiler.native-bignum.ghc946    ghc-native-bignum-9.4.6
-haskell.compiler.native-bignum.ghc947    ghc-native-bignum-9.4.7
-haskell.compiler.native-bignum.ghc94     ghc-native-bignum-9.4.8
-haskell.compiler.native-bignum.ghc948    ghc-native-bignum-9.4.8
-haskell.compiler.native-bignum.ghc963    ghc-native-bignum-9.6.3
-haskell.compiler.native-bignum.ghc96     ghc-native-bignum-9.6.4
-haskell.compiler.native-bignum.ghc964    ghc-native-bignum-9.6.4
-haskell.compiler.native-bignum.ghc98     ghc-native-bignum-9.8.1
-haskell.compiler.native-bignum.ghc981    ghc-native-bignum-9.8.1
-haskell.compiler.native-bignum.ghcHEAD   ghc-native-bignum-9.9.20231121
+haskell.compiler.native-bignum.ghc942    ghc-native-bignum-9.4.2
+haskell.compiler.native-bignum.ghc943    ghc-native-bignum-9.4.3
+haskell.compiler.native-bignum.ghc94     ghc-native-bignum-9.4.4
+haskell.compiler.native-bignum.ghc944    ghc-native-bignum-9.4.4
+haskell.compiler.native-bignum.ghcHEAD   ghc-native-bignum-9.7.20221224
 haskell.compiler.ghcjs                   ghcjs-8.10.7
 ```
 
@@ -113,7 +110,7 @@ Each of those compiler versions has a corresponding attribute set built using
 it. However, the non-standard package sets are not tested regularly and, as a
 result, contain fewer working packages. The corresponding package set for GHC
 9.4.5 is `haskell.packages.ghc945`. In fact `haskellPackages` is just an alias
-for `haskell.packages.ghc964`:
+for `haskell.packages.ghc927`:
 
 ```console
 $ nix-env -f '<nixpkgs>' -qaP -A haskell.packages.ghc927
@@ -230,7 +227,7 @@ completely incompatible with packages from `haskellPackages`.
 
 Every haskell package set has its own haskell-aware `mkDerivation` which is used
 to build its packages. Generally you won't have to interact with this builder
-since [cabal2nix](#haskell-cabal2nix) can generate packages
+since [cabal2nix][cabal2nix] can generate packages
 using it for an arbitrary cabal package definition. Still it is useful to know
 the parameters it takes when you need to
 [override](#haskell-overriding-haskell-packages) a generated Nix expression.
@@ -1020,11 +1017,6 @@ failing because of e.g. a syntax error in the Haddock documentation.
 : Sets `doCheck` to `false` for `drv`. Useful if a package has a broken,
 flaky or otherwise problematic test suite breaking the build.
 
-`dontCheckIf condition drv`
-: Sets `doCheck` to `false` for `drv`, but only if `condition` applies.
-Otherwise it's a no-op. Useful to conditionally disable tests for a package
-without interfering with previous overrides or default values.
-
 <!-- Purposefully omitting the non-list variants here. They are a bit
 ugly, and we may want to deprecate them at some point. -->
 
@@ -1123,75 +1115,18 @@ for [this to work][optparse-applicative-completions].
 Note that this feature is automatically disabled when cross-compiling, since it
 requires executing the binaries in question.
 
-## Import-from-Derivation helpers {#haskell-import-from-derivation}
-
-### cabal2nix {#haskell-cabal2nix}
-
-[`cabal2nix`][cabal2nix] can generate Nix package definitions for arbitrary
-Haskell packages using [import from derivation][import-from-derivation].
-`cabal2nix` will generate Nix expressions that look like this:
-
-```nix
-# cabal get mtl-2.2.1 && cd mtl-2.2.1 && cabal2nix .
-{ mkDerivation, base, lib, transformers }:
-mkDerivation {
-  pname = "mtl";
-  version = "2.2.1";
-  src = ./.;
-  libraryHaskellDepends = [ base transformers ];
-  homepage = "http://github.com/ekmett/mtl";
-  description = "Monad classes, using functional dependencies";
-  license = lib.licenses.bsd3;
-}
-```
-
-This expression should be called with `haskellPackages.callPackage`, which will
-supply [`haskellPackages.mkDerivation`](#haskell-mkderivation) and the Haskell
-dependencies as arguments.
-
-`callCabal2nix name src args`
-: Create a package named `name` from the source derivation `src` using
-  `cabal2nix`.
-
-  `args` are extra arguments provided to `haskellPackages.callPackage`.
-
-`callCabal2nixWithOptions name src opts args`
-: Create a package named `name` from the source derivation `src` using
-  `cabal2nix`.
-
-  `opts` are extra options for calling `cabal2nix`. If `opts` is a string, it
-  will be used as extra command line arguments for `cabal2nix`, e.g. `--subpath
-  path/to/dir/containing/cabal-file`. Otherwise, `opts` should be an AttrSet
-  which can contain the following attributes:
-
-  `extraCabal2nixOptions`
-  : Extra command line arguments for `cabal2nix`.
-
-  `srcModifier`
-  : A function which is used to modify the given `src` instead of the default
-    filter.
-
-    The default source filter will remove all files from `src` except for
-    `.cabal` files and `package.yaml` files.
-
-<!--
-
-`callHackage`
-: TODO
-
-`callHackageDirect`
-: TODO
-
-`developPackage`
-: TODO
-
--->
-
 <!--
 
 TODO(@NixOS/haskell): finish these planned sections
 ### Overriding the entire package set
 
+
+## Import-from-Derivation helpers
+
+* `callCabal2nix`
+* `callHackage`, `callHackageDirect`
+* `developPackage`
+
 ## Contributing {#haskell-contributing}
 
 ### Fixing a broken package {#haskell-fixing-a-broken-package}
@@ -1291,12 +1226,10 @@ in
   in
 
   {
-    haskell = prev.haskell // {
-      compiler = prev.haskell.compiler // {
-        ${ghcName} = prev.haskell.compiler.${ghcName}.override {
-          # Unfortunately, the GHC setting is named differently for historical reasons
-          enableProfiledLibs = enableProfiling;
-        };
+    haskell = lib.recursiveUpdate prev.haskell {
+      compiler.${ghcName} = prev.haskell.compiler.${ghcName}.override {
+        # Unfortunately, the GHC setting is named differently for historical reasons
+        enableProfiledLibs = enableProfiling;
       };
     };
   })
@@ -1308,33 +1241,31 @@ in
   in
 
   {
-    haskell = prev.haskell // {
-      packages = prev.haskell.packages // {
-        ${ghcName} = prev.haskell.packages.${ghcName}.override {
-          overrides = hfinal: hprev: {
-            mkDerivation = args: hprev.mkDerivation (args // {
-              # Since we are forcing our ideas upon mkDerivation, this change will
-              # affect every package in the package set.
-              enableLibraryProfiling = enableProfiling;
+    haskell = lib.recursiveUpdate prev.haskell {
+      packages.${ghcName} = prev.haskell.packages.${ghcName}.override {
+        overrides = hfinal: hprev: {
+          mkDerivation = args: hprev.mkDerivation (args // {
+            # Since we are forcing our ideas upon mkDerivation, this change will
+            # affect every package in the package set.
+            enableLibraryProfiling = enableProfiling;
 
-              # To actually use profiling on an executable, executable profiling
-              # needs to be enabled for the executable you want to profile. You
-              # can either do this globally or…
-              enableExecutableProfiling = enableProfiling;
-            });
+            # To actually use profiling on an executable, executable profiling
+            # needs to be enabled for the executable you want to profile. You
+            # can either do this globally or…
+            enableExecutableProfiling = enableProfiling;
+          });
 
-            # …only for the package that contains an executable you want to profile.
-            # That saves on unnecessary rebuilds for packages that you only depend
-            # on for their library, but also contain executables (e.g. pandoc).
-            my-executable = haskellLib.enableExecutableProfiling hprev.my-executable;
+          # …only for the package that contains an executable you want to profile.
+          # That saves on unnecessary rebuilds for packages that you only depend
+          # on for their library, but also contain executables (e.g. pandoc).
+          my-executable = haskellLib.enableExecutableProfiling hprev.my-executable;
 
-            # If you are disabling profiling to save on build time, but want to
-            # retain the ability to substitute from the binary cache. Drop the
-            # override for mkDerivation above and instead have an override like
-            # this for the specific packages you are building locally and want
-            # to make cheaper to build.
-            my-library = haskellLib.disableLibraryProfiling hprev.my-library;
-          };
+          # If you are disabling profiling to save on build time, but want to
+          # retain the ability to substitute from the binary cache. Drop the
+          # override for mkDerivation above and instead have an override like
+          # this for the specific packages you are building locally and want
+          # to make cheaper to build.
+          my-library = haskellLib.disableLibraryProfiling hprev.my-library;
         };
       };
     };
@@ -1366,4 +1297,3 @@ relevant.
 [profiling]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html
 [search.nixos.org]: https://search.nixos.org
 [turtle]: https://hackage.haskell.org/package/turtle
-[import-from-derivation]: https://nixos.org/manual/nix/stable/language/import-from-derivation

doc/languages-frameworks/idris.section.md

@@ -93,11 +93,11 @@ build-idris-package  {
     hash = "sha256-h28F9EEPuvab6zrfeE+0k1XGQJGwINnsJEG8yjWIl7w=";
   };
 
-  meta = {
+  meta = with lib; {
     description = "Idris YAML lib";
     homepage = "https://github.com/Heather/Idris.Yaml";
-    license = lib.licenses.mit;
-    maintainers = [ lib.maintainers.brainrape ];
+    license = licenses.mit;
+    maintainers = [ maintainers.brainrape ];
   };
 }
 ```
@@ -134,9 +134,9 @@ For example you could set
 
 ```nix
 build-idris-package {
-  idrisBuildOptions = [ "--log" "1" "--verbose" ];
+  idrisBuildOptions = [ "--log" "1" "--verbose" ]
 
-  # ...
+  ...
 }
 ```
 

doc/languages-frameworks/idris2.section.md

@@ -1,47 +0,0 @@
-# Idris2 {#sec-idris2}
-
-In addition to exposing the Idris2 compiler itself, Nixpkgs exposes an `idris2Packages.buildIdris` helper to make it a bit more ergonomic to build Idris2 executables or libraries.
-
-The `buildIdris` function takes an attribute set that defines at a minimum the `src` and `ipkgName` of the package to be built and any `idrisLibraries` required to build it. The `src` is the same source you're familiar with and the `ipkgName` must be the name of the `ipkg` file for the project (omitting the `.ipkg` extension). The `idrisLibraries` is a list of other library derivations created with `buildIdris`. You can optionally specify other derivation properties as needed but sensible defaults for `configurePhase`, `buildPhase`, and `installPhase` are provided.
-
-Importantly, `buildIdris` does not create a single derivation but rather an attribute set with two properties: `executable` and `library`. The `executable` property is a derivation and the `library` property is a function that will return a derivation for the library with or without source code included. Source code need not be included unless you are aiming to use IDE or LSP features that are able to jump to definitions within an editor.
-
-A simple example of a fully packaged library would be the [`LSP-lib`](https://github.com/idris-community/LSP-lib) found in the `idris-community` GitHub organization.
-```nix
-{ fetchFromGitHub, idris2Packages }:
-let lspLibPkg = idris2Packages.buildIdris {
-  ipkgName = "lsp-lib";
-  src = fetchFromGitHub {
-   owner = "idris-community";
-   repo = "LSP-lib";
-   rev = "main";
-   hash = "sha256-EvSyMCVyiy9jDZMkXQmtwwMoLaem1GsKVFqSGNNHHmY=";
-  };
-  idrisLibraries = [ ];
-};
-in lspLibPkg.library
-```
-
-The above results in a derivation with the installed library results (with sourcecode).
-
-A slightly more involved example of a fully packaged executable would be the [`idris2-lsp`](https://github.com/idris-community/idris2-lsp) which is an Idris2 language server that uses the `LSP-lib` found above.
-```nix
-{ callPackage, fetchFromGitHub, idris2Packages }:
-
-# Assuming the previous example lives in `lsp-lib.nix`:
-let lspLib = callPackage ./lsp-lib.nix { };
-    lspPkg = idris2Packages.buildIdris {
-      ipkgName = "idris2-lsp";
-      src = fetchFromGitHub {
-         owner = "idris-community";
-         repo = "idris2-lsp";
-         rev = "main";
-         hash = "sha256-vQTzEltkx7uelDtXOHc6QRWZ4cSlhhm5ziOqWA+aujk=";
-      };
-      idrisLibraries = [(idris2Packages.idris2Api { }) (lspLib { })];
-    };
-in lspPkg.executable
-```
-
-The above uses the default value of `withSource = false` for both of the two required Idris libraries that the `idris2-lsp` executable depends on. `idris2Api` in the above derivation comes built in with `idris2Packages`. This library exposes many of the otherwise internal APIs of the Idris2 compiler.
-

doc/languages-frameworks/index.md

@@ -14,7 +14,6 @@ cuda.section.md
 cuelang.section.md
 dart.section.md
 dhall.section.md
-dlang.section.md
 dotnet.section.md
 emscripten.section.md
 gnome.section.md
@@ -22,11 +21,9 @@ go.section.md
 haskell.section.md
 hy.section.md
 idris.section.md
-idris2.section.md
 ios.section.md
 java.section.md
 javascript.section.md
-julia.section.md
 lisp.section.md
 lua.section.md
 maven.section.md

doc/languages-frameworks/java.section.md

@@ -4,31 +4,12 @@ Ant-based Java packages are typically built from source as follows:
 
 ```nix
 stdenv.mkDerivation {
-  pname = "...";
-  version = "...";
+  name = "...";
+  src = fetchurl { ... };
 
-  src = fetchurl { /* ... */ };
+  nativeBuildInputs = [ jdk ant ];
 
-  nativeBuildInputs = [
-    ant
-    jdk
-    stripJavaArchivesHook # removes timestamp metadata from jar files
-  ];
-
-  buildPhase = ''
-    runHook preBuild
-    ant # build the project using ant
-    runHook postBuild
-  '';
-
-  installPhase = ''
-    runHook preInstall
-
-    # copy generated jar file(s) to an appropriate location in $out
-    install -Dm644 build/foo.jar $out/share/java/foo.jar
-
-    runHook postInstall
-  '';
+  buildPhase = "ant";
 }
 ```
 
@@ -36,10 +17,6 @@ Note that `jdk` is an alias for the OpenJDK (self-built where available,
 or pre-built via Zulu). Platforms with OpenJDK not (yet) in Nixpkgs
 (`Aarch32`, `Aarch64`) point to the (unfree) `oraclejdk`.
 
-Also note that not using `stripJavaArchivesHook` will likely cause the
-generated `.jar` files to be non-deterministic, which is not optimal.
-Using it, however, does not always guarantee reproducibility.
-
 JAR files that are intended to be used by other packages should be
 installed in `$out/share/java`. JDKs have a stdenv setup hook that add
 any JARs in the `share/java` directories of the build inputs to the
@@ -48,10 +25,8 @@ installs a JAR named `foo.jar` in its `share/java` directory, and
 another package declares the attribute
 
 ```nix
-{
-  buildInputs = [ libfoo ];
-  nativeBuildInputs = [ jdk ];
-}
+buildInputs = [ libfoo ];
+nativeBuildInputs = [ jdk ];
 ```
 
 then `CLASSPATH` will be set to
@@ -64,15 +39,13 @@ If your Java package provides a program, you need to generate a wrapper
 script to run it using a JRE. You can use `makeWrapper` for this:
 
 ```nix
-{
-  nativeBuildInputs = [ makeWrapper ];
+nativeBuildInputs = [ makeWrapper ];
 
-  installPhase = ''
-    mkdir -p $out/bin
-    makeWrapper ${jre}/bin/java $out/bin/foo \
-      --add-flags "-cp $out/share/java/foo.jar org.foo.Main"
-  '';
-}
+installPhase = ''
+  mkdir -p $out/bin
+  makeWrapper ${jre}/bin/java $out/bin/foo \
+    --add-flags "-cp $out/share/java/foo.jar org.foo.Main"
+'';
 ```
 
 Since the introduction of the Java Platform Module System in Java 9,
@@ -96,18 +69,16 @@ let
   something = (pkgs.something.override { jre = my_jre; });
   other = (pkgs.other.override { jre = my_jre; });
 in
-  <...>
+  ...
 ```
 
 You can also specify what JDK your JRE should be based on, for example
 selecting a 'headless' build to avoid including a link to GTK+:
 
 ```nix
-{
-  my_jre = pkgs.jre_minimal.override {
-    jdk = jdk11_headless;
-  };
-}
+my_jre = pkgs.jre_minimal.override {
+  jdk = jdk11_headless;
+};
 ```
 
 Note all JDKs passthru `home`, so if your application requires
@@ -122,9 +93,7 @@ It is possible to use a different Java compiler than `javac` from the
 OpenJDK. For instance, to use the GNU Java Compiler:
 
 ```nix
-{
-  nativeBuildInputs = [ gcj ant ];
-}
+nativeBuildInputs = [ gcj ant ];
 ```
 
 Here, Ant will automatically use `gij` (the GNU Java Runtime) instead of

doc/languages-frameworks/javascript.section.md

@@ -4,14 +4,11 @@
 
 This contains instructions on how to package javascript applications.
 
-The various tools available will be listed in the [tools-overview](#javascript-tools-overview).
-Some general principles for packaging will follow.
-Finally some tool specific instructions will be given.
+The various tools available will be listed in the [tools-overview](#javascript-tools-overview). Some general principles for packaging will follow. Finally some tool specific instructions will be given.
 
 ## Getting unstuck / finding code examples {#javascript-finding-examples}
 
-If you find you are lacking inspiration for packaging javascript applications, the links below might prove useful.
-Searching online for prior art can be helpful if you are running into solved problems.
+If you find you are lacking inspiration for packing javascript applications, the links below might prove useful. Searching online for prior art can be helpful if you are running into solved problems.
 
 ### Github {#javascript-finding-examples-github}
 
@@ -33,29 +30,23 @@ The following principles are given in order of importance with potential excepti
 
 It is often not documented which node version is used upstream, but if it is, try to use the same version when packaging.
 
-This can be a problem if upstream is using the latest and greatest and you are trying to use an earlier version of node.
-Some cryptic errors regarding V8 may appear.
+This can be a problem if upstream is using the latest and greatest and you are trying to use an earlier version of node. Some cryptic errors regarding V8 may appear.
 
 ### Try to respect the package manager originally used by upstream (and use the upstream lock file) {#javascript-upstream-package-manager}
 
-A lock file (package-lock.json, yarn.lock...) is supposed to make reproducible installations of `node_modules` for each tool.
+A lock file (package-lock.json, yarn.lock...) is supposed to make reproducible installations of node_modules for each tool.
 
-Guidelines of package managers, recommend to commit those lock files to the repos.
-If a particular lock file is present, it is a strong indication of which package manager is used upstream.
+Guidelines of package managers, recommend to commit those lock files to the repos. If a particular lock file is present, it is a strong indication of which package manager is used upstream.
 
-It's better to try to use a Nix tool that understand the lock file.
-Using a different tool might give you hard to understand error because different packages have been installed.
-An example of problems that could arise can be found [here](https://github.com/NixOS/nixpkgs/pull/126629).
-Upstream use npm, but this is an attempt to package it with `yarn2nix` (that uses yarn.lock).
+It's better to try to use a Nix tool that understand the lock file. Using a different tool might give you hard to understand error because different packages have been installed. An example of problems that could arise can be found [here](https://github.com/NixOS/nixpkgs/pull/126629). Upstream use NPM, but this is an attempt to package it with `yarn2nix` (that uses yarn.lock).
 
-Using a different tool forces to commit a lock file to the repository.
-Those files are fairly large, so when packaging for nixpkgs, this approach does not scale well.
+Using a different tool forces to commit a lock file to the repository. Those files are fairly large, so when packaging for nixpkgs, this approach does not scale well.
 
 Exceptions to this rule are:
 
 - When you encounter one of the bugs from a Nix tool. In each of the tool specific instructions, known problems will be detailed. If you have a problem with a particular tool, then it's best to try another tool, even if this means you will have to recreate a lock file and commit it to nixpkgs. In general `yarn2nix` has less known problems and so a simple search in nixpkgs will reveal many yarn.lock files committed.
-- Some lock files contain particular version of a package that has been pulled off npm for some reason. In that case, you can recreate upstream lock (by removing the original and `npm install`, `yarn`, ...) and commit this to nixpkgs.
-- The only tool that supports workspaces (a feature of npm that helps manage sub-directories with different package.json from a single top level package.json) is `yarn2nix`. If upstream has workspaces you should try `yarn2nix`.
+- Some lock files contain particular version of a package that has been pulled off NPM for some reason. In that case, you can recreate upstream lock (by removing the original and `npm install`, `yarn`, ...) and commit this to nixpkgs.
+- The only tool that supports workspaces (a feature of NPM that helps manage sub-directories with different package.json from a single top level package.json) is `yarn2nix`. If upstream has workspaces you should try `yarn2nix`.
 
 ### Try to use upstream package.json {#javascript-upstream-package-json}
 
@@ -76,36 +67,28 @@ Exceptions to this rule are:
   when you need to override a package.json. It's nice to use the one from the upstream source and do some explicit override. Here is an example:
 
   ```nix
-  {
-    patchedPackageJSON = final.runCommand "package.json" { } ''
-      ${jq}/bin/jq '.version = "0.4.0" |
-        .devDependencies."@jsdoc/cli" = "^0.2.5"
-        ${sonar-src}/package.json > $out
-    '';
-  }
+  patchedPackageJSON = final.runCommand "package.json" { } ''
+    ${jq}/bin/jq '.version = "0.4.0" |
+      .devDependencies."@jsdoc/cli" = "^0.2.5"
+      ${sonar-src}/package.json > $out
+  '';
   ```
 
   You will still need to commit the modified version of the lock files, but at least the overrides are explicit for everyone to see.
 
 ### Using node_modules directly {#javascript-using-node_modules}
 
-Each tool has an abstraction to just build the node_modules (dependencies) directory.
-You can always use the `stdenv.mkDerivation` with the node_modules to build the package (symlink the node_modules directory and then use the package build command).
-The node_modules abstraction can be also used to build some web framework frontends.
-For an example of this see how [plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix) is built. `mkYarnModules` to make the derivation containing node_modules.
-Then when building the frontend you can just symlink the node_modules directory.
+Each tool has an abstraction to just build the node_modules (dependencies) directory. You can always use the `stdenv.mkDerivation` with the node_modules to build the package (symlink the node_modules directory and then use the package build command). The node_modules abstraction can be also used to build some web framework frontends. For an example of this see how [plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix) is built. `mkYarnModules` to make the derivation containing node_modules. Then when building the frontend you can just symlink the node_modules directory.
 
 ## Javascript packages inside nixpkgs {#javascript-packages-nixpkgs}
 
-The [pkgs/development/node-packages](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages) folder contains a generated collection of [npm packages](https://npmjs.com/) that can be installed with the Nix package manager.
+The [pkgs/development/node-packages](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages) folder contains a generated collection of [NPM packages](https://npmjs.com/) that can be installed with the Nix package manager.
 
-As a rule of thumb, the package set should only provide _end user_ software packages, such as command-line utilities.
-Libraries should only be added to the package set if there is a non-npm package that requires it.
+As a rule of thumb, the package set should only provide _end user_ software packages, such as command-line utilities. Libraries should only be added to the package set if there is a non-NPM package that requires it.
 
-When it is desired to use npm libraries in a development project, use the `node2nix` generator directly on the `package.json` configuration file of the project.
+When it is desired to use NPM libraries in a development project, use the `node2nix` generator directly on the `package.json` configuration file of the project.
 
-The package set provides support for the official stable Node.js versions.
-The latest stable LTS release in `nodePackages`, as well as the latest stable current release in `nodePackages_latest`.
+The package set provides support for the official stable Node.js versions. The latest stable LTS release in `nodePackages`, as well as the latest stable current release in `nodePackages_latest`.
 
 If your package uses native addons, you need to examine what kind of native build system it uses. Here are some examples:
 
@@ -113,21 +96,18 @@ If your package uses native addons, you need to examine what kind of native buil
 - `node-gyp-builder`
 - `node-pre-gyp`
 
-After you have identified the correct system, you need to override your package expression while adding in build system as a build input.
-For example, `dat` requires `node-gyp-build`, so we override its expression in [pkgs/development/node-packages/overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/overrides.nix):
+After you have identified the correct system, you need to override your package expression while adding in build system as a build input. For example, `dat` requires `node-gyp-build`, so we override its expression in [pkgs/development/node-packages/overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/overrides.nix):
 
 ```nix
-  {
     dat = prev.dat.override (oldAttrs: {
       buildInputs = [ final.node-gyp-build pkgs.libtool pkgs.autoconf pkgs.automake ];
       meta = oldAttrs.meta // { broken = since "12"; };
     });
-  }
 ```
 
 ### Adding and Updating Javascript packages in nixpkgs {#javascript-adding-or-updating-packages}
 
-To add a package from npm to nixpkgs:
+To add a package from NPM to nixpkgs:
 
 1. Modify [pkgs/development/node-packages/node-packages.json](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/node-packages.json) to add, update or remove package entries to have it included in `nodePackages` and `nodePackages_latest`.
 2. Run the script:
@@ -154,7 +134,7 @@ To add a package from npm to nixpkgs:
 
 For more information about the generation process, consult the [README.md](https://github.com/svanderburg/node2nix) file of the `node2nix` tool.
 
-To update npm packages in nixpkgs, run the same `generate.sh` script:
+To update NPM packages in nixpkgs, run the same `generate.sh` script:
 
 ```sh
 ./pkgs/development/node-packages/generate.sh
@@ -179,8 +159,7 @@ git config --global url."https://github.com/".insteadOf git://github.com/
 
 ### 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.
+`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.
 
 Here's an example:
 
@@ -205,18 +184,16 @@ buildNpmPackage rec {
 
   NODE_OPTIONS = "--openssl-legacy-provider";
 
-  meta = {
+  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 = lib.licenses.gpl3Only;
-    maintainers = with lib.maintainers; [ winter ];
+    license = licenses.gpl3Only;
+    maintainers = with maintainers; [ winter ];
   };
 }
 ```
 
-In the default `installPhase` set by `buildNpmPackage`, it uses `npm pack --json --dry-run` to decide what files to install in `$out/lib/node_modules/$name/`, where `$name` is the `name` string defined in the package's `package.json`.
-Additionally, the `bin` and `man` keys in the source's `package.json` are used to decide what binaries and manpages are supposed to be installed.
-If these are not defined, `npm pack` may miss some files, and no binaries will be produced.
+In the default `installPhase` set by `buildNpmPackage`, it uses `npm pack --json --dry-run` to decide what files to install in `$out/lib/node_modules/$name/`, where `$name` is the `name` string defined in the package's `package.json`. Additionally, the `bin` and `man` keys in the source's `package.json` are used to decide what binaries and manpages are supposed to be installed. If these are not defined, `npm pack` may miss some files, and no binaries will be produced.
 
 #### Arguments {#javascript-buildNpmPackage-arguments}
 
@@ -256,37 +233,6 @@ sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
 
 It returns a derivation with all `package-lock.json` dependencies downloaded into `$out/`, usable as an npm cache.
 
-#### importNpmLock {#javascript-buildNpmPackage-importNpmLock}
-
-`importNpmLock` is a Nix function that requires the following optional arguments:
-
-- `npmRoot`: Path to package directory containing the source tree
-- `package`: Parsed contents of `package.json`
-- `packageLock`: Parsed contents of `package-lock.json`
-- `pname`: Package name
-- `version`: Package version
-
-It returns a derivation with a patched `package.json` & `package-lock.json` with all dependencies resolved to Nix store paths.
-
-This function is analogous to using `fetchNpmDeps`, but instead of specifying `hash` it uses metadata from `package.json` & `package-lock.json`.
-
-Note that `npmHooks.npmConfigHook` cannot be used with `importNpmLock`. You will instead need to use `importNpmLock.npmConfigHook`:
-
-```nix
-{ buildNpmPackage, importNpmLock }:
-
-buildNpmPackage {
-  pname = "hello";
-  version = "0.1.0";
-
-  npmDeps = importNpmLock {
-    npmRoot = ./.;
-  };
-
-  npmConfigHook = importNpmLock.npmConfigHook;
-}
-```
-
 ### corepack {#javascript-corepack}
 
 This package puts the corepack wrappers for pnpm and yarn in your PATH, and they will honor the `packageManager` setting in the `package.json`.
@@ -307,8 +253,8 @@ See `node2nix` [docs](https://github.com/svanderburg/node2nix) for more info.
 #### Pitfalls {#javascript-node2nix-pitfalls}
 
 - If upstream package.json does not have a "version" attribute, `node2nix` will crash. You will need to add it like shown in [the package.json section](#javascript-upstream-package-json).
-- `node2nix` has some [bugs](https://github.com/svanderburg/node2nix/issues/238) related to working with lock files from npm distributed with `nodejs_16`.
-- `node2nix` does not like missing packages from npm. If you see something like `Cannot resolve version: vue-loader-v16@undefined` then you might want to try another tool. The package might have been pulled off of npm.
+- `node2nix` has some [bugs](https://github.com/svanderburg/node2nix/issues/238) related to working with lock files from NPM distributed with `nodejs_16`.
+- `node2nix` does not like missing packages from NPM. If you see something like `Cannot resolve version: vue-loader-v16@undefined` then you might want to try another tool. The package might have been pulled off of NPM.
 
 ### yarn2nix {#javascript-yarn2nix}
 
@@ -319,12 +265,10 @@ You will need at least a `yarn.lock` file. If upstream does not have one you nee
 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";
-    hash = "....";
-  };
-}
+offlineCache = fetchYarnDeps {
+  yarnLock = src + "/yarn.lock";
+  hash = "....";
+};
 ```
 
 #### mkYarnPackage {#javascript-yarn2nix-mkYarnPackage}
@@ -334,41 +278,33 @@ If the downloaded files contain the `package.json` and `yarn.lock` files they ca
 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
-  '';
-}
+buildPhase = ''
+  export HOME=$(mktemp -d)
+  yarn --offline build
+'';
 ```
 
-The `distPhase` is packing the package's dependencies in a tarball using `yarn pack`. You can disable it using:
+The dist phase is also trying to build a binary, the only way to override it is with:
 
 ```nix
-{
-  doDist = false;
-}
+distPhase = "true";
 ```
 
 The configure phase can sometimes fail because it makes many assumptions which may not always apply. One common override is:
 
 ```nix
-{
-  configurePhase = ''
-    ln -s $node_modules node_modules
-  '';
-}
+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 = ''
+  cp -r $node_modules node_modules
+  chmod +w node_modules
+'';
 ```
 
 #### mkYarnModules {#javascript-yarn2nix-mkYarnModules}
@@ -408,19 +344,16 @@ mkYarnPackage rec {
 - Having trouble with `node-gyp`? Try adding these lines to the `yarnPreBuild` steps:
 
   ```nix
-  {
-    yarnPreBuild = ''
-      mkdir -p $HOME/.node-gyp/${nodejs.version}
-      echo 9 > $HOME/.node-gyp/${nodejs.version}/installVersion
-      ln -sfv ${nodejs}/include $HOME/.node-gyp/${nodejs.version}
-      export npm_config_nodedir=${nodejs}
-    '';
-  }
+  yarnPreBuild = ''
+    mkdir -p $HOME/.node-gyp/${nodejs.version}
+    echo 9 > $HOME/.node-gyp/${nodejs.version}/installVersion
+    ln -sfv ${nodejs}/include $HOME/.node-gyp/${nodejs.version}
+    export npm_config_nodedir=${nodejs}
+  '';
   ```
 
   - The `echo 9` steps comes from this answer: <https://stackoverflow.com/a/49139496>
   - Exporting the headers in `npm_config_nodedir` comes from this issue: <https://github.com/nodejs/node-gyp/issues/1191#issuecomment-301243919>
-- `offlineCache` (described [above](#javascript-yarn2nix-preparation)) must be specified to avoid [Import From Derivation](#ssec-import-from-derivation) (IFD) when used inside Nixpkgs.
 
 ## Outside Nixpkgs {#javascript-outside-nixpkgs}
 

doc/languages-frameworks/julia.section.md

@@ -1,69 +0,0 @@
-# Julia {#language-julia}
-
-## Introduction {#julia-introduction}
-
-Nixpkgs includes Julia as the `julia` derivation.
-You can get specific versions by looking at the other `julia*` top-level derivations available.
-For example, `julia_19` corresponds to Julia 1.9.
-We also provide the current stable version as `julia-stable`, and an LTS version as `julia-lts`.
-
-Occasionally, a Julia version has been too difficult to build from source in Nixpkgs and has been fetched prebuilt instead.
-These Julia versions are differentiated with the `*-bin` suffix; for example, `julia-stable-bin`.
-
-## julia.withPackages {#julia-withpackage}
-
-The basic Julia derivations only provide the built-in packages that come with the distribution.
-
-You can build Julia environments with additional packages using the `julia.withPackages` command.
-This function accepts a list of strings representing Julia package names.
-For example, you can build a Julia environment with the `Plots` package as follows.
-
-```nix
-julia.withPackages ["Plots"]
-```
-
-Arguments can be passed using `.override`.
-For example:
-
-```nix
-(julia.withPackages.override {
-  precompile = false; # Turn off precompilation
-}) ["Plots"]
-```
-
-Here's a nice way to run a Julia environment with a shell one-liner:
-
-```sh
-nix-shell -p 'julia.withPackages ["Plots"]' --run julia
-```
-
-### Arguments {#julia-withpackage-arguments}
-
-* `precompile`: Whether to run `Pkg.precompile()` on the generated environment.
-
-  This will make package imports faster, but may fail in some cases.
-  For example, there is an upstream issue with `Gtk.jl` that prevents precompilation from working in the Nix build sandbox, because the precompiled code tries to access a display.
-  Packages like this will work fine if you build with `precompile=false`, and then precompile as needed once your environment starts.
-
-  Defaults: `true`
-
-* `extraLibs`: Extra library dependencies that will be placed on the `LD_LIBRARY_PATH` for Julia.
-
-  Should not be needed as we try to obtain library dependencies automatically using Julia's artifacts system.
-
-* `makeWrapperArgs`: Extra arguments to pass to the `makeWrapper` call which we use to wrap the Julia binary.
-* `setDefaultDepot`: Whether to automatically prepend `$HOME/.julia` to the `JULIA_DEPOT_PATH`.
-
-  This is useful because Julia expects a writable depot path as the first entry, which the one we build in Nixpkgs is not.
-  If there's no writable depot, then Julia will show a warning and be unable to save command history logs etc.
-
-  Default: `true`
-
-* `packageOverrides`: Allows you to override packages by name by passing an alternative source.
-
-  For example, you can use a custom version of the `LanguageServer` package by passing `packageOverrides = { "LanguageServer" = fetchFromGitHub {...}; }`.
-
-* `augmentedRegistry`: Allows you to change the registry from which Julia packages are drawn.
-
-  This normally points at a special augmented version of the Julia [General packages registry](https://github.com/JuliaRegistries/General).
-  If you want to use a bleeding-edge version to pick up the latest package updates, you can plug in a later revision than the one in Nixpkgs.

doc/languages-frameworks/lisp.section.md

@@ -45,7 +45,7 @@ $ sbcl
 
 Also one can create a `pkgs.mkShell` environment in `shell.nix`/`flake.nix`:
 
-```nix
+```
 let
   sbcl' = sbcl.withPackages (ps: [ ps.alexandria ]);
 in mkShell {
@@ -55,12 +55,10 @@ in mkShell {
 
 Such a Lisp can be now used e.g. to compile your sources:
 
-```nix
-{
-  buildPhase = ''
-    ${sbcl'}/bin/sbcl --load my-build-file.lisp
-  '';
-}
+```
+buildPhase = ''
+  ${sbcl'}/bin/sbcl --load my-build-file.lisp
+''
 ```
 
 ## Importing packages from Quicklisp {#lisp-importing-packages-from-quicklisp}
@@ -175,7 +173,7 @@ into the package scope with `withOverrides`.
 A package defined outside Nixpkgs using `buildASDFSystem` can be woven into the
 Nixpkgs-provided scope like this:
 
-```nix
+```
 let
   alexandria = sbcl.buildASDFSystem rec {
     pname = "alexandria";
@@ -201,7 +199,7 @@ new package with different parameters.
 
 Example of overriding `alexandria`:
 
-```nix
+```
 sbcl.pkgs.alexandria.overrideLispAttrs (oldAttrs: rec {
   version = "1.4";
   src = fetchFromGitLab {
@@ -227,7 +225,7 @@ vice versa.
 
 To package slashy systems, use `overrideLispAttrs`, like so:
 
-```nix
+```
 ecl.pkgs.alexandria.overrideLispAttrs (oldAttrs: {
   systems = oldAttrs.systems ++ [ "alexandria/tests" ];
   lispLibs = oldAttrs.lispLibs ++ [ ecl.pkgs.rt ];
@@ -292,7 +290,7 @@ derivation.
 
 This example wraps CLISP:
 
-```nix
+```
 wrapLisp {
   pkg = clisp;
   faslExt = "fas";

doc/languages-frameworks/lua.section.md

@@ -1,8 +1,8 @@
-# Lua {#lua}
+# User’s Guide to Lua Infrastructure {#users-guide-to-lua-infrastructure}
 
-## Using Lua {#lua-userguide}
+## Using Lua {#using-lua}
 
-### Overview of Lua {#lua-overview}
+### Overview of Lua {#overview-of-lua}
 
 Several versions of the Lua interpreter are available: luajit, lua 5.1, 5.2, 5.3.
 The attribute `lua` refers to the default interpreter, it is also possible to refer to specific versions, e.g. `lua5_2` refers to Lua 5.2.
@@ -17,9 +17,6 @@ The main package set contains aliases to these package sets, e.g.
 `luaPackages` refers to `lua5_1.pkgs` and `lua52Packages` to
 `lua5_2.pkgs`.
 
-Note that nixpkgs patches the non-luajit interpreters to avoid referring to
-`/usr` and have `;;` (a [placeholder](https://www.lua.org/manual/5.1/manual.html#pdf-package.path) replaced with the default LUA_PATH) work correctly.
-
 ### Installing Lua and packages {#installing-lua-and-packages}
 
 #### Lua environment defined in separate `.nix` file {#lua-environment-defined-in-separate-.nix-file}
@@ -90,7 +87,6 @@ final: prev:
         pname = "luarocks-nix";
         src = /home/my_luarocks/repository;
       });
-    };
   };
 
   luaPackages = lua.pkgs;
@@ -122,7 +118,7 @@ Again, it is possible to launch the interpreter from the shell.
 The Lua interpreter has the attribute `pkgs` which contains all Lua libraries for that specific interpreter.
 
 
-## Developing with lua {#lua-developing}
+## Developing with Lua {#developing-with-lua}
 
 Now that you know how to get a working Lua environment with Nix, it is time
 to go forward and start actually developing with Lua. There are two ways to
@@ -158,9 +154,7 @@ You can develop your package as you usually would, just don't forget to wrap it
 within a `toLuaModule` call, for instance
 
 ```nix
-{
-  mynewlib = toLuaModule ( stdenv.mkDerivation { /* ... */ });
-}
+mynewlib = toLuaModule ( stdenv.mkDerivation { ... });
 ```
 
 There is also the `buildLuaPackage` function that can be used when lua modules
@@ -188,26 +182,24 @@ Each interpreter has the following attributes:
 The `buildLuarocksPackage` function is implemented in `pkgs/development/interpreters/lua-5/build-luarocks-package.nix`
 The following is an example:
 ```nix
-{
-  luaposix = buildLuarocksPackage {
-    pname = "luaposix";
-    version = "34.0.4-1";
+luaposix = buildLuarocksPackage {
+  pname = "luaposix";
+  version = "34.0.4-1";
 
-    src = fetchurl {
-      url    = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
-      hash = "sha256-4mLJG8n4m6y4Fqd0meUDfsOb9RHSR0qa/KD5KCwrNXs=";
-    };
-    disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
-    propagatedBuildInputs = [ bit32 lua std_normalize ];
-
-    meta = {
-      homepage = "https://github.com/luaposix/luaposix/";
-      description = "Lua bindings for POSIX";
-      maintainers = with lib.maintainers; [ vyp lblasc ];
-      license.fullName = "MIT/X11";
-    };
+  src = fetchurl {
+    url    = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
+    hash = "sha256-4mLJG8n4m6y4Fqd0meUDfsOb9RHSR0qa/KD5KCwrNXs=";
   };
-}
+  disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
+  propagatedBuildInputs = [ bit32 lua std_normalize ];
+
+  meta = with lib; {
+    homepage = "https://github.com/luaposix/luaposix/";
+    description = "Lua bindings for POSIX";
+    maintainers = with maintainers; [ vyp lblasc ];
+    license.fullName = "MIT/X11";
+  };
+};
 ```
 
 The `buildLuarocksPackage` delegates most tasks to luarocks:
@@ -223,11 +215,6 @@ install the package
   environment variable and add dependent libraries to script's `LUA_PATH` and
   `LUA_CPATH`.
 
-It accepts as arguments:
-
-* 'luarocksConfig': a nix value that directly maps to the luarocks config used during
-  the installation
-
 By default `meta.platforms` is set to the same value as the interpreter unless overridden otherwise.
 
 #### `buildLuaApplication` function {#buildluaapplication-function}
@@ -242,20 +229,30 @@ The `lua.withPackages` takes a function as an argument that is passed the set of
 Using the `withPackages` function, the previous example for the luafilesystem environment can be written like this:
 
 ```nix
+with import <nixpkgs> {};
+
 lua.withPackages (ps: [ps.luafilesystem])
 ```
 
 `withPackages` passes the correct package set for the specific interpreter version as an argument to the function. In the above example, `ps` equals `luaPackages`.
-But you can also easily switch to using `lua5_1`:
+But you can also easily switch to using `lua5_2`:
 
 ```nix
-lua5_1.withPackages (ps: [ps.lua])
+with import <nixpkgs> {};
+
+lua5_2.withPackages (ps: [ps.lua])
 ```
 
-Now, `ps` is set to `lua5_1.pkgs`, matching the version of the interpreter.
+Now, `ps` is set to `lua52Packages`, matching the version of the interpreter.
 
-### Lua Contributing guidelines {#lua-contributing}
+### Possible Todos {#possible-todos}
+
+* export/use version specific variables such as `LUA_PATH_5_2`/`LUAROCKS_CONFIG_5_2`
+* let luarocks check for dependencies via exporting the different rocktrees in temporary config
+
+### Lua Contributing guidelines {#lua-contributing-guidelines}
 
 Following rules should be respected:
 
+* Make sure libraries build for all Lua interpreters.
 * Commit names of Lua libraries should reflect that they are Lua libraries, so write for example `luaPackages.luafilesystem: 1.11 -> 1.12`.

doc/languages-frameworks/maven.section.md

@@ -34,13 +34,13 @@ maven.buildMavenPackage rec {
       --add-flags "-jar $out/share/jd-cli/jd-cli.jar"
   '';
 
-  meta = {
+  meta = with lib; {
     description = "Simple command line wrapper around JD Core Java Decompiler project";
     homepage = "https://github.com/intoolswetrust/jd-cli";
-    license = lib.licenses.gpl3Plus;
-    maintainers = with lib.maintainers; [ majiir ];
+    license = licenses.gpl3Plus;
+    maintainers = with maintainers; [ majiir ];
   };
-}
+}:
 ```
 
 This package calls `maven.buildMavenPackage` to do its work. The primary difference from `stdenv.mkDerivation` is the `mvnHash` variable, which is a hash of all of the Maven dependencies.

doc/languages-frameworks/nim.section.md

@@ -1,38 +1,74 @@
 # Nim {#nim}
 
-The Nim compiler and a builder function is available.
-Nim programs are built using `buildNimPackage` and a lockfile containing Nim dependencies.
+## Overview {#nim-overview}
+
+The Nim compiler, a builder function, and some packaged libraries are available
+in Nixpkgs. Until now each compiler release has been effectively backwards
+compatible so only the latest version is available.
+
+## Nim program packages in Nixpkgs {#nim-program-packages-in-nixpkgs}
+
+Nim programs can be built using `nimPackages.buildNimPackage`. In the
+case of packages not containing exported library code the attribute
+`nimBinOnly` should be set to `true`.
 
 The following example shows a Nim program that depends only on Nim libraries:
-```nix
-{ lib, buildNimPackage, fetchFromGitHub }:
 
-buildNimPackage { } (finalAttrs: {
+```nix
+{ lib, nimPackages, fetchFromGitHub }:
+
+nimPackages.buildNimPackage (finalAttrs: {
   pname = "ttop";
-  version = "1.2.7";
+  version = "1.0.1";
+  nimBinOnly = true;
 
   src = fetchFromGitHub {
     owner = "inv2004";
     repo = "ttop";
     rev = "v${finalAttrs.version}";
-    hash = "sha256-oPdaUqh6eN1X5kAYVvevOndkB/xnQng9QVLX9bu5P5E=";
+    hash = "sha256-x4Uczksh6p3XX/IMrOFtBxIleVHdAPX9e8n32VAUTC4=";
   };
 
-  lockFile = ./lock.json;
+  buildInputs = with nimPackages; [ asciigraph illwill parsetoml zippy ];
 
-  nimFlags = [
-    "-d:NimblePkgVersion=${finalAttrs.version}"
-  ];
+})
+```
+
+## Nim library packages in Nixpkgs {#nim-library-packages-in-nixpkgs}
+
+
+Nim libraries can also be built using `nimPackages.buildNimPackage`, but
+often the product of a fetcher is sufficient to satisfy a dependency.
+The `fetchgit`, `fetchFromGitHub`, and `fetchNimble` functions yield an
+output that can be discovered during the `configurePhase` of `buildNimPackage`.
+
+Nim library packages are listed in
+[pkgs/top-level/nim-packages.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/nim-packages.nix) and implemented at
+[pkgs/development/nim-packages](https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/nim-packages).
+
+The following example shows a Nim library that propagates a dependency on a
+non-Nim package:
+```nix
+{ lib, buildNimPackage, fetchNimble, SDL2 }:
+
+buildNimPackage (finalAttrs: {
+  pname = "sdl2";
+  version = "2.0.4";
+  src = fetchNimble {
+    inherit (finalAttrs) pname version;
+    hash = "sha256-Vtcj8goI4zZPQs2TbFoBFlcR5UqDtOldaXSH/+/xULk=";
+  };
+  propagatedBuildInputs = [ SDL2 ];
 })
 ```
 
 ## `buildNimPackage` parameters {#buildnimpackage-parameters}
 
-The `buildNimPackage` function takes an attrset of parameters that are passed on to `stdenv.mkDerivation`.
+All parameters from `stdenv.mkDerivation` function are still supported. The
+following are specific to `buildNimPackage`:
 
-The following parameters are specific to `buildNimPackage`:
-
-* `lockFile`: JSON formatted lockfile.
+* `nimBinOnly ? false`: If `true` then build only the programs listed in
+  the Nimble file in the packages sources.
 * `nimbleFile`: Specify the Nimble file location of the package being built
   rather than discover the file at build-time.
 * `nimRelease ? true`: Build the package in *release* mode.
@@ -41,85 +77,6 @@ The following parameters are specific to `buildNimPackage`:
   Use this to specify defines with arguments in the form of `-d:${name}=${value}`.
 * `nimDoc` ? false`: Build and install HTML documentation.
 
-## Lockfiles {#nim-lockfiles}
-Nim lockfiles are created with the `nim_lk` utility.
-Run `nim_lk` with the source directory as an argument and it will print a lockfile to stdout.
-```sh
-$ cd nixpkgs
-$ nix build -f . ttop.src
-$ nix run -f . nim_lk ./result | jq --sort-keys > pkgs/by-name/tt/ttop/lock.json
-```
-
-## Overriding Nim packages {#nim-overrides}
-
-The `buildNimPackage` function generates flags and additional build dependencies from the `lockFile` parameter passed to `buildNimPackage`. Using [`overrideAttrs`](#sec-pkg-overrideAttrs) on the final package will apply after this has already been generated, so this can't be used to override the `lockFile` in a package built with `buildNimPackage`. To be able to override parameters before flags and build dependencies are generated from the `lockFile`, use `overrideNimAttrs` instead with the same syntax as `overrideAttrs`:
-
-```nix
-pkgs.nitter.overrideNimAttrs {
-  # using a different source which has different dependencies from the standard package
-  src = pkgs.fetchFromGithub { /* … */ };
-  # new lock file generated from the source
-  lockFile = ./custom-lock.json;
-}
-```
-
-## Lockfile dependency overrides {#nim-lock-overrides}
-
-The `buildNimPackage` function matches the libraries specified by `lockFile` to attrset of override functions that are then applied to the package derivation.
-The default overrides are maintained as the top-level `nimOverrides` attrset at `pkgs/top-level/nim-overrides.nix`.
-
-For example, to propagate a dependency on SDL2 for lockfiles that select the Nim `sdl2` library, an overlay is added to the set in the `nim-overrides.nix` file:
-```nix
-{ lib
-/* … */
-, SDL2
-/* … */
-}:
-
-{
-  /* … */
-  sdl2 =
-    lockAttrs:
-    finalAttrs:
-    { buildInputs ? [ ], ... }:
-    {
-      buildInputs = buildInputs ++ [ SDL2 ];
-    };
-  /* … */
-}
-```
-
-The annotations in the `nim-overrides.nix` set are functions that take three arguments and return a new attrset to be overlayed on the package being built.
-- lockAttrs: the attrset for this library from within a lockfile. This can be used to implement library version constraints, such as marking libraries as broken or insecure.
-- finalAttrs: the final attrset passed by `buildNimPackage` to `stdenv.mkDerivation`.
-- prevAttrs: the attrset produced by initial arguments to `buildNimPackage` and any preceding lockfile overlays.
-
-### Overriding an Nim library override {#nim-lock-overrides-overrides}
-
-The `nimOverrides` attrset makes it possible to modify overrides in a few different ways.
-
-Override a package internal to its definition:
-```nix
-{ lib, buildNimPackage, nimOverrides, libressl }:
-
-let
-  buildNimPackage' = buildNimPackage.override {
-    nimOverrides = nimOverrides.override { openssl = libressl; };
-  };
-in buildNimPackage' (finalAttrs: {
-  pname = "foo";
-  # …
-})
-
-```
-
-Override a package externally:
-```nix
-{ pkgs }: {
-  foo = pkgs.foo.override {
-    buildNimPackage = pkgs.buildNimPackage.override {
-      nimOverrides = pkgs.nimOverrides.override { openssl = libressl; };
-    };
-  };
-}
-```
+* `buildInputs` ? []: The packages listed here will be searched for `*.nimble`
+  files which are used to populate the Nim library path. Otherwise the standard
+  behavior is in effect.

doc/languages-frameworks/ocaml.section.md

@@ -92,7 +92,6 @@ buildDunePackage rec {
     license = lib.licenses.bsd3;
     maintainers = with lib.maintainers; [ sternenseemann ];
   };
-}
 ```
 
 Here is a second example, this time using a source archive generated with `dune-release`. It is a good idea to use this archive when it is available as it will usually contain substituted variables such as a `%%VERSION%%` field. This library does not depend on any other OCaml library and no tests are run after building it.
@@ -111,11 +110,11 @@ buildDunePackage rec {
     hash = "sha256-d5/3KUBAWRj8tntr4RkJ74KWW7wvn/B/m1nx0npnzyc=";
   };
 
-  meta = {
+  meta = with lib; {
     homepage = "https://github.com/flowtype/ocaml-wtf8";
     description = "WTF-8 is a superset of UTF-8 that allows unpaired surrogates.";
-    license = lib.licenses.mit;
-    maintainers = [ lib.maintainers.eqyiel ];
+    license = licenses.mit;
+    maintainers = [ maintainers.eqyiel ];
   };
 }
 ```

doc/languages-frameworks/perl.section.md

@@ -34,27 +34,23 @@ Nixpkgs provides a function `buildPerlPackage`, a generic package builder functi
 Perl packages from CPAN are defined in [pkgs/top-level/perl-packages.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix) rather than `pkgs/all-packages.nix`. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from `perl-packages.nix`. However, more complicated packages should be put in a separate file, typically in `pkgs/development/perl-modules`. Here is an example of the former:
 
 ```nix
-{
-  ClassC3 = buildPerlPackage rec {
-    pname = "Class-C3";
-    version = "0.21";
-    src = fetchurl {
-      url = "mirror://cpan/authors/id/F/FL/FLORA/${pname}-${version}.tar.gz";
-      hash = "sha256-/5GE5xHT0uYGOQxroqj6LMU7CtKn2s6vMVoSXxL4iK4=";
-    };
+ClassC3 = buildPerlPackage rec {
+  pname = "Class-C3";
+  version = "0.21";
+  src = fetchurl {
+    url = "mirror://cpan/authors/id/F/FL/FLORA/${pname}-${version}.tar.gz";
+    hash = "sha256-/5GE5xHT0uYGOQxroqj6LMU7CtKn2s6vMVoSXxL4iK4=";
   };
-}
+};
 ```
 
 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
 
 ```nix
-{
-  foo = import ../path/to/foo.nix {
-    inherit stdenv fetchurl /* ... */;
-    inherit (perlPackages) ClassC3;
-  };
-}
+foo = import ../path/to/foo.nix {
+  inherit stdenv fetchurl ...;
+  inherit (perlPackages) ClassC3;
+};
 ```
 
 in `all-packages.nix`. You can test building a Perl package as follows:
@@ -95,19 +91,17 @@ buildPerlPackage rec {
 Dependencies on other Perl packages can be specified in the `buildInputs` and `propagatedBuildInputs` attributes. If something is exclusively a build-time dependency, use `buildInputs`; if it’s (also) a runtime dependency, use `propagatedBuildInputs`. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules:
 
 ```nix
-{
-  ClassC3Componentised = buildPerlPackage rec {
-    pname = "Class-C3-Componentised";
-    version = "1.0004";
-    src = fetchurl {
-      url = "mirror://cpan/authors/id/A/AS/ASH/${pname}-${version}.tar.gz";
-      hash = "sha256-ASO9rV/FzJYZ0BH572Fxm2ZrFLMZLFATJng1NuU4FHc=";
-    };
-    propagatedBuildInputs = [
-      ClassC3 ClassInspector TestException MROCompat
-    ];
+ClassC3Componentised = buildPerlPackage rec {
+  pname = "Class-C3-Componentised";
+  version = "1.0004";
+  src = fetchurl {
+    url = "mirror://cpan/authors/id/A/AS/ASH/${pname}-${version}.tar.gz";
+    hash = "sha256-ASO9rV/FzJYZ0BH572Fxm2ZrFLMZLFATJng1NuU4FHc=";
   };
-}
+  propagatedBuildInputs = [
+    ClassC3 ClassInspector TestException MROCompat
+  ];
+};
 ```
 
 On Darwin, if a script has too many `-Idir` flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the `shortenPerlShebang` function from the `postInstall` phase:
@@ -115,22 +109,20 @@ On Darwin, if a script has too many `-Idir` flags in its first line (its “sheb
 ```nix
 { lib, stdenv, buildPerlPackage, fetchurl, shortenPerlShebang }:
 
-{
-  ImageExifTool = buildPerlPackage {
-    pname = "Image-ExifTool";
-    version = "12.50";
+ImageExifTool = buildPerlPackage {
+  pname = "Image-ExifTool";
+  version = "12.50";
 
-    src = fetchurl {
-      url = "https://exiftool.org/${pname}-${version}.tar.gz";
-      hash = "sha256-vOhB/FwQMC8PPvdnjDvxRpU6jAZcC6GMQfc0AH4uwKg=";
-    };
-
-    nativeBuildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
-    postInstall = lib.optionalString stdenv.isDarwin ''
-      shortenPerlShebang $out/bin/exiftool
-    '';
+  src = fetchurl {
+    url = "https://exiftool.org/${pname}-${version}.tar.gz";
+    hash = "sha256-vOhB/FwQMC8PPvdnjDvxRpU6jAZcC6GMQfc0AH4uwKg=";
   };
-}
+
+  nativeBuildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
+  postInstall = lib.optionalString stdenv.isDarwin ''
+    shortenPerlShebang $out/bin/exiftool
+  '';
+};
 ```
 
 This will remove the `-I` flags from the shebang line, rewrite them in the `use lib` form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place.

doc/languages-frameworks/php.section.md

@@ -97,7 +97,7 @@ let
   myPhp = php.withExtensions ({ all, ... }: with all; [ imagick opcache ]);
 in {
   services.phpfpm.pools."foo".phpPackage = myPhp;
-}
+};
 ```
 
 ```nix
@@ -108,7 +108,7 @@ let
   };
 in {
   services.phpfpm.pools."foo".phpPackage = myPhp;
-}
+};
 ```
 
 #### Example usage with `nix-shell` {#ssec-php-user-guide-installing-with-extensions-nix-shell}
@@ -149,7 +149,7 @@ php.override {
     extensions = prev.extensions // {
       mysqlnd = prev.extensions.mysqlnd.overrideAttrs (attrs: {
         patches = attrs.patches or [] ++ [
-          # ...
+          …
         ];
       });
     };

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

@@ -7,28 +7,24 @@ Nixpkgs provides a couple of facilities for working with this tool.
 ## Writing packages providing pkg-config modules {#pkg-config-writing-packages}
 
 Packages should set `meta.pkgConfigModules` with the list of package config modules they provide.
-They should also use `testers.hasPkgConfigModules` to check that the final built package matches that list,
-and optionally check that the pkgconf modules' version metadata matches the derivation's.
+They should also use `testers.testMetaPkgConfig` to check that the final built package matches that list.
 Additionally, the [`validatePkgConfig` setup hook](https://nixos.org/manual/nixpkgs/stable/#validatepkgconfig), will do extra checks on to-be-installed pkg-config modules.
 
-A good example of all these things is miniz:
+A good example of all these things is zlib:
 
-```nix
+```
 { pkg-config, testers, ... }:
 
 stdenv.mkDerivation (finalAttrs: {
-  /* ... */
+  ...
 
   nativeBuildInputs = [ pkg-config validatePkgConfig ];
 
-  passthru.tests.pkg-config = testers.hasPkgConfigModules {
-    package = finalAttrs.finalPackage;
-    versionCheck = true;
-  };
+  passthru.tests.pkg-config = testers.testMetaPkgConfig finalAttrs.finalPackage;
 
   meta = {
-    /* ... */
-    pkgConfigModules = [ "miniz" ];
+    ...
+    pkgConfigModules = [ "zlib" ];
   };
 })
 ```

doc/languages-frameworks/python.section.md

@@ -7,6 +7,7 @@
 | Package    | Aliases         | Interpreter |
 |------------|-----------------|-------------|
 | python27   | python2, python | CPython 2.7 |
+| python38   |                 | CPython 3.8 |
 | python39   |                 | CPython 3.9 |
 | python310  |                 | CPython 3.10 |
 | python311  | python3         | CPython 3.11 |
@@ -59,6 +60,7 @@ sets are
 
 * `pkgs.python27Packages`
 * `pkgs.python3Packages`
+* `pkgs.python38Packages`
 * `pkgs.python39Packages`
 * `pkgs.python310Packages`
 * `pkgs.python311Packages`
@@ -74,9 +76,8 @@ and the aliases
 
 #### `buildPythonPackage` function {#buildpythonpackage-function}
 
-The `buildPythonPackage` function has its name binding in
-`pkgs/development/interpreters/python/python-packages-base.nix` and is
-implemented in `pkgs/development/interpreters/python/mk-python-derivation.nix`
+The `buildPythonPackage` function is implemented in
+`pkgs/development/interpreters/python/mk-python-derivation.nix`
 using setup hooks.
 
 The following is an example:
@@ -115,11 +116,11 @@ buildPythonPackage rec {
     rm testing/test_argcomplete.py
   '';
 
-  build-system = [
+  nativeBuildInputs = [
     setuptools-scm
   ];
 
-  dependencies = [
+  propagatedBuildInputs = [
     attrs
     py
     setuptools
@@ -131,12 +132,12 @@ buildPythonPackage rec {
     hypothesis
   ];
 
-  meta = {
+  meta = with lib; {
     changelog = "https://github.com/pytest-dev/pytest/releases/tag/${version}";
     description = "Framework for writing tests";
     homepage = "https://github.com/pytest-dev/pytest";
-    license = lib.licenses.mit;
-    maintainers = with lib.maintainers; [ domenkozar lovek323 madjar lsix ];
+    license = licenses.mit;
+    maintainers = with maintainers; [ domenkozar lovek323 madjar lsix ];
   };
 }
 ```
@@ -171,10 +172,10 @@ following are specific to `buildPythonPackage`:
   variable in wrapped programs.
 * `pyproject`: Whether the pyproject format should be used. When set to `true`,
   `pypaBuildHook` will be used, and you can add the required build dependencies
-  from `build-system.requires` to `build-system`. Note that the pyproject
+  from `build-system.requires` to `nativeBuildInputs`. Note that the pyproject
   format falls back to using `setuptools`, so you can use `pyproject = true`
   even if the package only has a `setup.py`. When set to `false`, you can
-  use the existing [hooks](#setup-hooks) or provide your own logic to build the
+  use the existing [hooks](#setup-hooks0 or provide your own logic to build the
   package. This can be useful for packages that don't support the pyproject
   format. When unset, the legacy `setuptools` hooks are used for backwards
   compatibility.
@@ -205,22 +206,17 @@ build inputs (see "Specifying dependencies"). The following are of special
 interest for Python packages, either because these are primarily used, or
 because their behaviour is different:
 
-* `nativeBuildInputs ? []`: Build-time only dependencies. Typically executables.
-* `build-system ? []`: Build-time only Python dependencies. Items listed in `build-system.requires`/`setup_requires`.
+* `nativeBuildInputs ? []`: Build-time only dependencies. Typically executables
+  as well as the items listed in `setup_requires`.
 * `buildInputs ? []`: Build and/or run-time dependencies that need to be
   compiled for the host machine. Typically non-Python libraries which are being
   linked.
 * `nativeCheckInputs ? []`: Dependencies needed for running the [`checkPhase`](#ssec-check-phase). These
   are added to [`nativeBuildInputs`](#var-stdenv-nativeBuildInputs) when [`doCheck = true`](#var-stdenv-doCheck). Items listed in
   `tests_require` go here.
-* `dependencies ? []`: Aside from propagating dependencies,
+* `propagatedBuildInputs ? []`: Aside from propagating dependencies,
   `buildPythonPackage` also injects code into and wraps executables with the
   paths included in this list. Items listed in `install_requires` go here.
-* `optional-dependencies ? { }`: Optional feature flagged dependencies.  Items listed in `extras_requires` go here.
-
-Aside from propagating dependencies,
-  `buildPythonPackage` also injects code into and wraps executables with the
-  paths included in this list. Items listed in `extras_requires` go here.
 
 ##### Overriding Python packages {#overriding-python-packages}
 
@@ -254,19 +250,17 @@ The next example shows a non trivial overriding of the `blas` implementation to
 be used through out all of the Python package set:
 
 ```nix
-{
-  python3MyBlas = pkgs.python3.override {
-    packageOverrides = self: super: {
-      # We need toPythonModule for the package set to evaluate this
-      blas = super.toPythonModule(super.pkgs.blas.override {
-        blasProvider = super.pkgs.mkl;
-      });
-      lapack = super.toPythonModule(super.pkgs.lapack.override {
-        lapackProvider = super.pkgs.mkl;
-      });
-    };
+python3MyBlas = pkgs.python3.override {
+  packageOverrides = self: super: {
+    # We need toPythonModule for the package set to evaluate this
+    blas = super.toPythonModule(super.pkgs.blas.override {
+      blasProvider = super.pkgs.mkl;
+    });
+    lapack = super.toPythonModule(super.pkgs.lapack.override {
+      lapackProvider = super.pkgs.mkl;
+    });
   };
-}
+};
 ```
 
 This is particularly useful for numpy and scipy users who want to gain speed with other blas implementations.
@@ -305,17 +299,17 @@ python3Packages.buildPythonApplication rec {
     hash  = "sha256-Pe229rT0aHwA98s+nTHQMEFKZPo/yw6sot8MivFDvAw=";
   };
 
-  build-system = with python3Packages; [
-    setuptools
-    wheel
+  nativeBuildInputs = [
+    python3Packages.setuptools
+    python3Packages.wheel
   ];
 
-  dependencies = with python3Packages; [
-    tornado
-    python-daemon
+  propagatedBuildInputs = [
+    python3Packages.tornado
+    python3Packages.python-daemon
   ];
 
-  meta = {
+  meta = with lib; {
     # ...
   };
 }
@@ -324,9 +318,7 @@ python3Packages.buildPythonApplication rec {
 This is then added to `all-packages.nix` just as any other application would be.
 
 ```nix
-{
-  luigi = callPackage ../applications/networking/cluster/luigi { };
-}
+luigi = callPackage ../applications/networking/cluster/luigi { };
 ```
 
 Since the package is an application, a consumer doesn't need to care about
@@ -346,9 +338,7 @@ the attribute in `python-packages.nix`, and the `toPythonApplication` shall be
 applied to the reference:
 
 ```nix
-{
-  youtube-dl = with python3Packages; toPythonApplication youtube-dl;
-}
+youtube-dl = with python3Packages; toPythonApplication youtube-dl;
 ```
 
 #### `toPythonModule` function {#topythonmodule-function}
@@ -360,12 +350,10 @@ bindings should be made available from `python-packages.nix`. The
 modifications.
 
 ```nix
-{
-  opencv = toPythonModule (pkgs.opencv.override {
-    enablePython = true;
-    pythonPackages = self;
-  });
-}
+opencv = toPythonModule (pkgs.opencv.override {
+  enablePython = true;
+  pythonPackages = self;
+});
 ```
 
 Do pay attention to passing in the right Python version!
@@ -475,14 +463,14 @@ are used in [`buildPythonPackage`](#buildpythonpackage-function).
 - `eggBuildHook` to skip building for eggs.
 - `eggInstallHook` to install eggs.
 - `pipBuildHook` to build a wheel using `pip` and PEP 517. Note a build system
-  (e.g. `setuptools` or `flit`) should still be added as `build-system`.
+  (e.g. `setuptools` or `flit`) should still be added as `nativeBuildInput`.
 - `pypaBuildHook` to build a wheel using
   [`pypa/build`](https://pypa-build.readthedocs.io/en/latest/index.html) and
   PEP 517/518. Note a build system (e.g. `setuptools` or `flit`) should still
-  be added as `build-system`.
+  be added as `nativeBuildInput`.
 - `pipInstallHook` to install wheels.
 - `pytestCheckHook` to run tests with `pytest`. See [example usage](#using-pytestcheckhook).
-- `pythonCatchConflictsHook` to fail if the package depends on two different versions of the same dependency.
+- `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).
@@ -497,6 +485,40 @@ are used in [`buildPythonPackage`](#buildpythonpackage-function).
   with the `pipInstallHook`.
 - `unittestCheckHook` will run tests with `python -m unittest discover`. See [example usage](#using-unittestcheckhook).
 
+### Development mode {#development-mode}
+
+Development or editable mode is supported. To develop Python packages
+[`buildPythonPackage`](#buildpythonpackage-function) has additional logic inside `shellPhase` to run `pip
+install -e . --prefix $TMPDIR/`for the package.
+
+Warning: `shellPhase` is executed only if `setup.py` exists.
+
+Given a `default.nix`:
+
+```nix
+with import <nixpkgs> {};
+
+python3Packages.buildPythonPackage {
+  name = "myproject";
+  buildInputs = with python3Packages; [ pyramid ];
+
+  src = ./.;
+}
+```
+
+Running `nix-shell` with no arguments should give you the environment in which
+the package would be built with `nix-build`.
+
+Shortcut to setup environments with C headers/libraries and Python packages:
+
+```shell
+nix-shell -p python3Packages.pyramid zlib libjpeg git
+```
+
+::: {.note}
+There is a boolean value `lib.inNixShell` set to `true` if nix-shell is invoked.
+:::
+
 ## User Guide {#user-guide}
 
 ### Using Python {#using-python}
@@ -833,7 +855,8 @@ Above, we were mostly just focused on use cases and what to do to get started
 creating working Python environments in nix.
 
 Now that you know the basics to be up and running, it is time to take a step
-back and take a deeper look at how Python packages are packaged on Nix.
+back and take a deeper look at how Python packages are packaged on Nix. Then,
+we will look at how you can use development mode with your code.
 
 #### Python library packages in Nixpkgs {#python-library-packages-in-nixpkgs}
 
@@ -859,7 +882,7 @@ buildPythonPackage rec {
     hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
   };
 
-  build-system = [
+  nativeBuildInputs = [
     setuptools
     wheel
   ];
@@ -873,11 +896,12 @@ buildPythonPackage rec {
     "toolz.dicttoolz"
   ];
 
-  meta = {
+  meta = with lib; {
     changelog = "https://github.com/pytoolz/toolz/releases/tag/${version}";
     homepage = "https://github.com/pytoolz/toolz";
     description = "List processing tools and functional utilities";
-    license = lib.licenses.bsd3;
+    license = licenses.bsd3;
+    maintainers = with maintainers; [ fridh ];
   };
 }
 ```
@@ -918,7 +942,7 @@ with import <nixpkgs> {};
         hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
       };
 
-      build-system = [
+      nativeBuildInputs = [
         python311.pkgs.setuptools
         python311.pkgs.wheel
       ];
@@ -954,15 +978,13 @@ that we introduced with the `let` expression.
 
 #### Handling dependencies {#handling-dependencies}
 
-Our example, `toolz`, does not have any dependencies on other Python packages or system libraries.
-[`buildPythonPackage`](#buildpythonpackage-function) uses the the following arguments in the following circumstances:
-
-- `dependencies` - For Python runtime dependencies.
-- `build-system` - For Python build-time requirements.
-- [`buildInputs`](#var-stdenv-buildInputs) - For non-Python build-time requirements.
-- [`nativeCheckInputs`](#var-stdenv-nativeCheckInputs) - For test dependencies
-
-Dependencies can belong to multiple arguments, for example if something is both a build time requirement & a runtime dependency.
+Our example, `toolz`, does not have any dependencies on other Python packages or
+system libraries. According to the manual, [`buildPythonPackage`](#buildpythonpackage-function) uses the
+arguments [`buildInputs`](#var-stdenv-buildInputs) and [`propagatedBuildInputs`](#var-stdenv-propagatedBuildInputs) to specify dependencies. If
+something is exclusively a build-time dependency, then the dependency should be
+included in [`buildInputs`](#var-stdenv-buildInputs), but if it is (also) a runtime dependency, then it
+should be added to [`propagatedBuildInputs`](#var-stdenv-propagatedBuildInputs). Test dependencies are considered
+build-time dependencies and passed to [`nativeCheckInputs`](#var-stdenv-nativeCheckInputs).
 
 The following example shows which arguments are given to [`buildPythonPackage`](#buildpythonpackage-function) in
 order to build [`datashape`](https://github.com/blaze/datashape).
@@ -992,12 +1014,12 @@ buildPythonPackage rec {
     hash = "sha256-FLLvdm1MllKrgTGC6Gb0k0deZeVYvtCCLji/B7uhong=";
   };
 
-  build-system = [
+  nativeBuildInputs = [
     setuptools
     wheel
   ];
 
-  dependencies = [
+  propagatedBuildInputs = [
     multipledispatch
     numpy
     python-dateutil
@@ -1007,11 +1029,12 @@ buildPythonPackage rec {
     pytest
   ];
 
-  meta = {
+  meta = with lib; {
     changelog = "https://github.com/blaze/datashape/releases/tag/${version}";
     homepage = "https://github.com/ContinuumIO/datashape";
     description = "A data description language";
-    license = lib.licenses.bsd2;
+    license = licenses.bsd2;
+    maintainers = with maintainers; [ fridh ];
   };
 }
 ```
@@ -1019,7 +1042,7 @@ buildPythonPackage rec {
 We can see several runtime dependencies, `numpy`, `multipledispatch`, and
 `python-dateutil`. Furthermore, we have [`nativeCheckInputs`](#var-stdenv-nativeCheckInputs) with `pytest`.
 `pytest` is a test runner and is only used during the [`checkPhase`](#ssec-check-phase) and is
-therefore not added to `dependencies`.
+therefore not added to [`propagatedBuildInputs`](#var-stdenv-propagatedBuildInputs).
 
 In the previous case we had only dependencies on other Python packages to consider.
 Occasionally you have also system libraries to consider. E.g., `lxml` provides
@@ -1046,7 +1069,7 @@ buildPythonPackage rec {
     hash = "sha256-s9NiusRxFydHzaNRMjjxFcvWxfi45jGb9ql6eJJyQJk=";
   };
 
-  build-system = [
+  nativeBuildInputs = [
     setuptools
     wheel
   ];
@@ -1056,12 +1079,12 @@ buildPythonPackage rec {
     libxslt
   ];
 
-  meta = {
+  meta = with lib; {
     changelog = "https://github.com/lxml/lxml/releases/tag/lxml-${version}";
     description = "Pythonic binding for the libxml2 and libxslt libraries";
     homepage = "https://lxml.de";
-    license = lib.licenses.bsd3;
-    maintainers = with lib.maintainers; [ sjourdois ];
+    license = licenses.bsd3;
+    maintainers = with maintainers; [ sjourdois ];
   };
 }
 ```
@@ -1103,7 +1126,7 @@ buildPythonPackage rec {
     hash = "sha256-9ru2r6kwhUCaskiFoaPNuJCfCVoUL01J40byvRt4kHQ=";
   };
 
-  build-system = [
+  nativeBuildInputs = [
     setuptools
     wheel
   ];
@@ -1114,7 +1137,7 @@ buildPythonPackage rec {
     fftwLongDouble
   ];
 
-  dependencies = [
+  propagatedBuildInputs = [
     numpy
     scipy
   ];
@@ -1127,11 +1150,12 @@ buildPythonPackage rec {
   # Tests cannot import pyfftw. pyfftw works fine though.
   doCheck = false;
 
-  meta = {
+  meta = with lib; {
     changelog = "https://github.com/pyFFTW/pyFFTW/releases/tag/v${version}";
     description = "A pythonic wrapper around FFTW, the FFT library, presenting a unified interface for all the supported transforms";
     homepage = "http://hgomersall.github.com/pyFFTW";
-    license = with lib.licenses; [ bsd2 bsd3 ];
+    license = with licenses; [ bsd2 bsd3 ];
+    maintainers = with maintainers; [ fridh ];
   };
 }
 ```
@@ -1167,8 +1191,7 @@ a good indication that the package is not in a valid state.
 Pytest is the most common test runner for python repositories. A trivial
 test run would be:
 
-```nix
-{
+```
   nativeCheckInputs = [ pytest ];
   checkPhase = ''
     runHook preCheck
@@ -1177,7 +1200,6 @@ test run would be:
 
     runHook postCheck
   '';
-}
 ```
 
 However, many repositories' test suites do not translate well to nix's build
@@ -1185,8 +1207,7 @@ sandbox, and will generally need many tests to be disabled.
 
 To filter tests using pytest, one can do the following:
 
-```nix
-{
+```
   nativeCheckInputs = [ pytest ];
   # avoid tests which need additional data or touch network
   checkPhase = ''
@@ -1196,7 +1217,6 @@ To filter tests using pytest, one can do the following:
 
     runHook postCheck
   '';
-}
 ```
 
 `--ignore` will tell pytest to ignore that file or directory from being
@@ -1222,8 +1242,7 @@ when a package may need many items disabled to run the test suite.
 
 Using the example above, the analogous `pytestCheckHook` usage would be:
 
-```nix
-{
+```
   nativeCheckInputs = [
     pytestCheckHook
   ];
@@ -1243,14 +1262,12 @@ Using the example above, the analogous `pytestCheckHook` usage would be:
   disabledTestPaths = [
     "tests/test_failing.py"
   ];
-}
 ```
 
 This is especially useful when tests need to be conditionally disabled,
 for example:
 
-```nix
-{
+```
   disabledTests = [
     # touches network
     "download"
@@ -1262,7 +1279,6 @@ for example:
     # can fail when building with other packages
     "socket"
   ];
-}
 ```
 
 Trying to concatenate the related strings to disable tests in a regular
@@ -1276,24 +1292,20 @@ all packages have test suites that can be run easily, and some have none at all.
 To help ensure the package still works, [`pythonImportsCheck`](#using-pythonimportscheck) can attempt to import
 the listed modules.
 
-```nix
-{
+```
   pythonImportsCheck = [
     "requests"
     "urllib"
   ];
-}
 ```
 
 roughly translates to:
 
-```nix
-{
+```
   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;`](#var-stdenv-doCheck).
@@ -1324,8 +1336,7 @@ pkg3>=1.0,<=2.0
 
 we can do:
 
-```nix
-{
+```
   nativeBuildInputs = [
     pythonRelaxDepsHook
   ];
@@ -1336,7 +1347,6 @@ we can do:
   pythonRemoveDeps = [
     "pkg2"
   ];
-}
 ```
 
 which would result in the following `requirements.txt` file:
@@ -1349,11 +1359,9 @@ pkg3
 Another option is to pass `true`, that will relax/remove all dependencies, for
 example:
 
-```nix
-{
+```
   nativeBuildInputs = [ pythonRelaxDepsHook ];
   pythonRelaxDeps = true;
-}
 ```
 
 which would result in the following `requirements.txt` file:
@@ -1378,8 +1386,7 @@ work with any of the [existing hooks](#setup-hooks).
 
 `unittestCheckHook` is a hook which will substitute the setuptools `test` command for a [`checkPhase`](#ssec-check-phase) which runs `python -m unittest discover`:
 
-```nix
-{
+```
   nativeCheckInputs = [
     unittestCheckHook
   ];
@@ -1387,7 +1394,6 @@ work with any of the [existing hooks](#setup-hooks).
   unittestFlagsArray = [
     "-s" "tests" "-v"
   ];
-}
 ```
 
 #### Using sphinxHook {#using-sphinxhook}
@@ -1397,8 +1403,7 @@ using the popular Sphinx documentation generator.
 It is setup to automatically find common documentation source paths and
 render them using the default `html` style.
 
-```nix
-{
+```
   outputs = [
     "out"
     "doc"
@@ -1407,15 +1412,13 @@ render them using the default `html` style.
   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.
 
-```nix
-{
+```
   outputs = [
     "out"
     "doc"
@@ -1427,22 +1430,58 @@ for the artifacts of the `man` builder into the `man` target.
     "singlehtml"
     "man"
   ];
-}
 ```
 
 Overwrite `sphinxRoot` when the hook is unable to find your
 documentation source root.
 
-```nix
-{
+```
   # 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.
 
+### Develop local package {#develop-local-package}
+
+As a Python developer you're likely aware of [development mode](http://setuptools.readthedocs.io/en/latest/setuptools.html#development-mode)
+(`python setup.py develop`); instead of installing the package this command
+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
+refer to a local source instead using `src = ./path/to/source/tree;`
+
+If we create a `shell.nix` file which calls [`buildPythonPackage`](#buildpythonpackage-function), 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.11
+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`](#var-stdenv-propagatedBuildInputs).
+Indeed, we can just add any package we like to have in our environment to
+[`propagatedBuildInputs`](#var-stdenv-propagatedBuildInputs).
+
+```nix
+with import <nixpkgs> {};
+with python311Packages;
+
+buildPythonPackage rec {
+  name = "mypackage";
+  src = ./path/to/package/source;
+  propagatedBuildInputs = [
+    pytest
+    numpy
+    pkgs.libsndfile
+  ];
+}
+```
+
+It is important to note that due to how development mode is implemented on Nix
+it is not possible to have multiple packages simultaneously in development mode.
+
 ### Organising your packages {#organising-your-packages}
 
 So far we discussed how you can use Python on Nix, and how you can develop with
@@ -1481,16 +1520,17 @@ buildPythonPackage rec {
     hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
   };
 
-  build-system = [
+  nativeBuildInputs = [
     setuptools
     wheel
   ];
 
-  meta = {
+  meta = with lib; {
     changelog = "https://github.com/pytoolz/toolz/releases/tag/${version}";
     homepage = "https://github.com/pytoolz/toolz/";
     description = "List processing tools and functional utilities";
-    license = lib.licenses.bsd3;
+    license = licenses.bsd3;
+    maintainers = with maintainers; [ fridh ];
   };
 }
 ```
@@ -1781,7 +1821,6 @@ folder and not downloaded again.
 If you need to change a package's attribute(s) from `configuration.nix` you could do:
 
 ```nix
-{
   nixpkgs.config.packageOverrides = super: {
     python3 = super.python3.override {
       packageOverrides = python-self: python-super: {
@@ -1796,7 +1835,6 @@ If you need to change a package's attribute(s) from `configuration.nix` you coul
       };
     };
   };
-}
 ```
 
 `python3Packages.twisted` is now globally overridden.
@@ -1809,13 +1847,11 @@ To modify only a Python package set instead of a whole Python derivation, use
 this snippet:
 
 ```nix
-{
   myPythonPackages = python3Packages.override {
     overrides = self: super: {
-      twisted = <...>;
+      twisted = ...;
     };
-  };
-}
+  }
 ```
 
 ### How to override a Python package using overlays? {#how-to-override-a-python-package-using-overlays}
@@ -1851,7 +1887,7 @@ final: prev: {
     (
       python-final: python-prev: {
         foo = python-prev.foo.overridePythonAttrs (oldAttrs: {
-          # ...
+          ...
         });
       }
     )
@@ -1868,8 +1904,8 @@ configure alternatives](#sec-overlays-alternatives-blas-lapack)".
 
 In a `setup.py` or `setup.cfg` it is common to declare dependencies:
 
-* `setup_requires` corresponds to `build-system`
-* `install_requires` corresponds to `dependencies`
+* `setup_requires` corresponds to [`nativeBuildInputs`](#var-stdenv-nativeBuildInputs)
+* `install_requires` corresponds to [`propagatedBuildInputs`](#var-stdenv-propagatedBuildInputs)
 * `tests_require` corresponds to [`nativeCheckInputs`](#var-stdenv-nativeCheckInputs)
 
 ### How to enable interpreter optimizations? {#optimizations}
@@ -1878,7 +1914,7 @@ The Python interpreters are by default not built with optimizations enabled, bec
 the builds are in that case not reproducible. To enable optimizations, override the
 interpreter of interest, e.g using
 
-```nix
+```
 let
   pkgs = import ./. {};
   mypython = pkgs.python3.override {
@@ -1893,28 +1929,24 @@ in mypython
 
 Some packages define optional dependencies for additional features. With
 `setuptools` this is called `extras_require` and `flit` calls it
-`extras-require`, while PEP 621 calls these `optional-dependencies`.
+`extras-require`, while PEP 621 calls these `optional-dependencies`. A
+method for supporting this is by declaring the extras of a package in its
+`passthru`, e.g. in case of the package `dask`
 
 ```nix
-{
-  optional-dependencies = {
-    complete = [ distributed ];
-  };
-}
+passthru.optional-dependencies = {
+  complete = [ distributed ];
+};
 ```
 
 and letting the package requiring the extra add the list to its dependencies
 
 ```nix
-{
-  dependencies = [
-    # ...
-  ] ++ dask.optional-dependencies.complete;
-}
+propagatedBuildInputs = [
+  ...
+] ++ dask.optional-dependencies.complete;
 ```
 
-This method is using `passthru`, meaning that changing `optional-dependencies` of a package won't cause it to rebuild.
-
 Note this method is preferred over adding parameters to builders, as that can
 result in packages depending on different variants and thereby causing
 collisions.
@@ -1977,10 +2009,6 @@ example of such a situation is when `py.test` is used.
 
 * Tests that attempt to access `$HOME` can be fixed by using the following
   work-around before running tests (e.g. `preCheck`): `export HOME=$(mktemp -d)`
-* Compiling with Cython causes tests to fail with a `ModuleNotLoadedError`.
-  This can be fixed with two changes in the derivation: 1) replacing `pytest` with
-  `pytestCheckHook` and 2) adding a `preCheck` containing `cd $out` to run
-  tests within the built output.
 
 ## Contributing {#contributing}
 
@@ -2033,7 +2061,7 @@ and create update commits, and supports the `fetchPypi`, `fetchurl` and
 hosted on GitHub, exporting a `GITHUB_API_TOKEN` is highly recommended.
 
 Updating packages in bulk leads to lots of breakages, which is why a
-stabilization period on the `python-updates` branch is required.
+stabilization period on the `python-unstable` branch is required.
 
 If a package is fragile and often breaks during these bulks updates, it
 may be reasonable to set `passthru.skipBulkUpdate = true` in the

doc/languages-frameworks/qt.section.md

@@ -3,63 +3,61 @@
 Writing Nix expressions for Qt libraries and applications is largely similar as for other C++ software.
 This section assumes some knowledge of the latter.
 
-The major caveat with Qt applications is that Qt uses a plugin system to load additional modules at runtime.
-In Nixpkgs, we wrap Qt applications to inject environment variables telling Qt where to discover the required plugins and QML modules.
-
-This effectively makes the runtime dependencies pure and explicit at build-time, at the cost of introducing
-an extra indirection.
+The major caveat with Qt applications is that Qt uses a plugin system to load additional modules at runtime,
+from a list of well-known locations. In Nixpkgs, we patch QtCore to instead use an environment variable,
+and wrap Qt applications to set it to the right paths. This effectively makes the runtime dependencies
+pure and explicit at build-time, at the cost of introducing an extra indirection.
 
 ## Nix expression for a Qt package (default.nix) {#qt-default-nix}
 
 ```nix
-{ stdenv, qt6 }:
+{ stdenv, lib, qtbase, wrapQtAppsHook }:
 
 stdenv.mkDerivation {
   pname = "myapp";
   version = "1.0";
 
-  buildInputs = [ qt6.qtbase ];
-  nativeBuildInputs = [ qt6.wrapQtAppsHook ];
+  buildInputs = [ qtbase ];
+  nativeBuildInputs = [ wrapQtAppsHook ];
 }
 ```
 
-The same goes for Qt 5 where libraries and tools are under `libsForQt5`.
+It is important to import Qt modules directly, that is: `qtbase`, `qtdeclarative`, etc. *Do not* import Qt package sets such as `qt5` because the Qt versions of dependencies may not be coherent, causing build and runtime failures.
 
-Any Qt package should include `wrapQtAppsHook` in `nativeBuildInputs`, or explicitly set `dontWrapQtApps` to bypass generating the wrappers.
+Additionally all Qt packages must include `wrapQtAppsHook` in `nativeBuildInputs`, or you must explicitly set `dontWrapQtApps`.
 
-::: {.note}
-Qt 6 graphical applications should also include `qtwayland` in `buildInputs` on Linux (but not on platforms e.g. Darwin, where `qtwayland` is not available), to ensure the Wayland platform plugin is available.
+## Locating runtime dependencies {#qt-runtime-dependencies}
 
-This may become default in the future, see [NixOS/nixpkgs#269674](https://github.com/NixOS/nixpkgs/pull/269674).
-:::
+Qt applications must be wrapped to find runtime dependencies.
+Include `wrapQtAppsHook` in `nativeBuildInputs`:
 
-## Packages supporting multiple Qt versions {#qt-versions}
+```nix
+{ stdenv, wrapQtAppsHook }:
 
-If your package is a library that can be built with multiple Qt versions, you may want to take Qt modules as separate arguments (`qtbase`, `qtdeclarative` etc.), and invoke the package from `pkgs/top-level/qt5-packages.nix` or `pkgs/top-level/qt6-packages.nix` using the respective `callPackage` functions.
-
-Applications should generally be built with upstream's preferred Qt version.
-
-## Locating additional runtime dependencies {#qt-runtime-dependencies}
+stdenv.mkDerivation {
+  # ...
+  nativeBuildInputs = [ wrapQtAppsHook ];
+}
+```
 
 Add entries to `qtWrapperArgs` are to modify the wrappers created by
 `wrapQtAppsHook`:
 
 ```nix
-{ stdenv, qt6 }:
+{ stdenv, wrapQtAppsHook }:
 
 stdenv.mkDerivation {
   # ...
-  nativeBuildInputs = [ qt6.wrapQtAppsHook ];
+  nativeBuildInputs = [ wrapQtAppsHook ];
   qtWrapperArgs = [ ''--prefix PATH : /path/to/bin'' ];
 }
 ```
 
 The entries are passed as arguments to [wrapProgram](#fun-wrapProgram).
 
-If you need more control over the wrapping process, set `dontWrapQtApps` to disable automatic wrapper generation,
-and then create wrappers manually in `fixupPhase`, using `wrapQtApp`, which itself is a small wrapper over [wrapProgram](#fun-wrapProgram):
-
-The `makeWrapper` arguments required for Qt are also exposed in the environment as `$qtWrapperArgs`.
+Set `dontWrapQtApps` to stop applications from being wrapped automatically.
+Wrap programs manually with `wrapQtApp`, using the syntax of
+[wrapProgram](#fun-wrapProgram):
 
 ```nix
 { stdenv, lib, wrapQtAppsHook }:

doc/languages-frameworks/ruby.section.md

@@ -2,13 +2,13 @@
 
 ## Using Ruby {#using-ruby}
 
-Several versions of Ruby interpreters are available on Nix, as well as over 250 gems and many applications written in Ruby. The attribute `ruby` refers to the default Ruby interpreter, which is currently MRI 3.1. It's also possible to refer to specific versions, e.g. `ruby_3_y`, `jruby`, or `mruby`.
+Several versions of Ruby interpreters are available on Nix, as well as over 250 gems and many applications written in Ruby. The attribute `ruby` refers to the default Ruby interpreter, which is currently MRI 2.6. It's also possible to refer to specific versions, e.g. `ruby_2_y`, `jruby`, or `mruby`.
 
 In the Nixpkgs tree, Ruby packages can be found throughout, depending on what they do, and are called from the main package set. Ruby gems, however are separate sets, and there's one default set for each interpreter (currently MRI only).
 
 There are two main approaches for using Ruby with gems. One is to use a specifically locked `Gemfile` for an application that has very strict dependencies. The other is to depend on the common gems, which we'll explain further down, and rely on them being updated regularly.
 
-The interpreters have common attributes, namely `gems`, and `withPackages`. So you can refer to `ruby.gems.nokogiri`, or `ruby_3_2.gems.nokogiri` to get the Nokogiri gem already compiled and ready to use.
+The interpreters have common attributes, namely `gems`, and `withPackages`. So you can refer to `ruby.gems.nokogiri`, or `ruby_2_7.gems.nokogiri` to get the Nokogiri gem already compiled and ready to use.
 
 Since not all gems have executables like `nokogiri`, it's usually more convenient to use the `withPackages` function like this: `ruby.withPackages (p: with p; [ nokogiri ])`. This will also make sure that the Ruby in your environment will be able to find the gem and it can be used in your Ruby code (for example via `ruby` or `irb` executables) via `require "nokogiri"` as usual.
 
@@ -33,7 +33,7 @@ Again, it's possible to launch the interpreter from the shell. The Ruby interpre
 #### Load Ruby environment from `.nix` expression {#load-ruby-environment-from-.nix-expression}
 
 As explained [in the `nix-shell` section](https://nixos.org/manual/nix/stable/command-ref/nix-shell) of the Nix manual, `nix-shell` can also load an expression from a `.nix` file.
-Say we want to have Ruby, `nokogori`, and `pry`. Consider a `shell.nix` file with:
+Say we want to have Ruby 2.6, `nokogori`, and `pry`. Consider a `shell.nix` file with:
 
 ```nix
 with import <nixpkgs> {};
@@ -114,7 +114,7 @@ With this file in your directory, you can run `nix-shell` to build and use the g
 
 The `bundlerEnv` is a wrapper over all the gems in your gemset. This means that all the `/lib` and `/bin` directories will be available, and the executables of all gems (even of indirect dependencies) will end up in your `$PATH`. The `wrappedRuby` provides you with all executables that come with Ruby itself, but wrapped so they can easily find the gems in your gemset.
 
-One common issue that you might have is that you have Ruby, but also `bundler` in your gemset. That leads to a conflict for `/bin/bundle` and `/bin/bundler`. You can resolve this by wrapping either your Ruby or your gems in a `lowPrio` call. So in order to give the `bundler` from your gemset priority, it would be used like this:
+One common issue that you might have is that you have Ruby 2.6, but also `bundler` in your gemset. That leads to a conflict for `/bin/bundle` and `/bin/bundler`. You can resolve this by wrapping either your Ruby or your gems in a `lowPrio` call. So in order to give the `bundler` from your gemset priority, it would be used like this:
 
 ```nix
 # ...
@@ -124,13 +124,11 @@ mkShell { buildInputs = [ gems (lowPrio gems.wrappedRuby) ]; }
 Sometimes a Gemfile references other files. Such as `.ruby-version` or vendored gems. When copying the Gemfile to the nix store we need to copy those files alongside. This can be done using `extraConfigPaths`. For example:
 
 ```nix
-{
   gems = bundlerEnv {
     name = "gems-for-some-project";
     gemdir = ./.;
     extraConfigPaths = [ "${./.}/.ruby-version" ];
   };
-}
 ```
 
 ### Gem-specific configurations and workarounds {#gem-specific-configurations-and-workarounds}

doc/languages-frameworks/rust.section.md

@@ -3,12 +3,10 @@
 To install the rust compiler and cargo put
 
 ```nix
-{
-  environment.systemPackages = [
-    rustc
-    cargo
-  ];
-}
+environment.systemPackages = [
+  rustc
+  cargo
+];
 ```
 
 into your `configuration.nix` or bring them into scope with `nix-shell -p rustc cargo`.
@@ -37,51 +35,44 @@ rustPlatform.buildRustPackage rec {
 
   cargoHash = "sha256-jtBw4ahSl88L0iuCXxQgZVm1EcboWRJMNtjxLVTtzts=";
 
-  meta = {
+  meta = with lib; {
     description = "A fast line-oriented regex search tool, similar to ag and ack";
     homepage = "https://github.com/BurntSushi/ripgrep";
-    license = lib.licenses.unlicense;
+    license = licenses.unlicense;
     maintainers = [];
   };
 }
 ```
 
-`buildRustPackage` requires either a `cargoHash` (preferred) or a
-`cargoSha256` attribute, computed over all crate sources of this package.
-`cargoHash` supports [SRI](https://www.w3.org/TR/SRI/) hashes and should be
-preferred over `cargoSha256` which was used for traditional Nix SHA-256 hashes.
-For example:
-
-```nix
-{
-  cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8=";
-}
-```
+`buildRustPackage` requires either the `cargoSha256` or the
+`cargoHash` attribute which is computed over all crate sources of this
+package. `cargoHash256` is used for traditional Nix SHA-256 hashes,
+such as the one in the example above. `cargoHash` should instead be
+used for [SRI](https://www.w3.org/TR/SRI/) hashes. For example:
 
 Exception: If the application has cargo `git` dependencies, the `cargoHash`/`cargoSha256`
 approach will not work, and you will need to copy the `Cargo.lock` file of the application
-to nixpkgs and continue with the next section for specifying the options of the `cargoLock`
+to nixpkgs and continue with the next section for specifying the options of the`cargoLock`
 section.
 
+```nix
+  cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8=";
+```
 
 Both types of hashes are permitted when contributing to nixpkgs. The
 Cargo hash is obtained by inserting a fake checksum into the
 expression and building the package once. The correct checksum can
 then be taken from the failed build. A fake hash can be used for
-`cargoHash` as follows:
+`cargoSha256` as follows:
 
 ```nix
-{
-  cargoHash = lib.fakeHash;
-}
+  cargoSha256 = lib.fakeSha256;
 ```
 
-For `cargoSha256` you can use:
+For `cargoHash` you can use:
 
 ```nix
-{
-  cargoSha256 = lib.fakeSha256;
-}
+  cargoHash = lib.fakeHash;
 ```
 
 Per the instructions in the [Cargo Book](https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html)
@@ -98,7 +89,7 @@ directory into a tar.gz archive.
 The tarball with vendored dependencies contains a directory with the
 package's `name`, which is normally composed of `pname` and
 `version`. This means that the vendored dependencies hash
-(`cargoHash`/`cargoSha256`) is dependent on the package name and
+(`cargoSha256`/`cargoHash`) is dependent on the package name and
 version. The `cargoDepsName` attribute can be used to use another name
 for the directory of vendored dependencies. For example, the hash can
 be made invariant to the version by setting `cargoDepsName` to
@@ -123,7 +114,7 @@ rustPlatform.buildRustPackage rec {
 
 ### Importing a `Cargo.lock` file {#importing-a-cargo.lock-file}
 
-Using a vendored hash (`cargoHash`/`cargoSha256`) is tedious when using
+Using `cargoSha256` or `cargoHash` is tedious when using
 `buildRustPackage` within a project, since it requires that the hash
 is updated after every change to `Cargo.lock`. Therefore,
 `buildRustPackage` also supports vendoring dependencies directly from
@@ -170,11 +161,9 @@ doesn't add a `Cargo.lock` to your `src`, and a `Cargo.lock` is still
 required to build a rust package. A simple fix is to use:
 
 ```nix
-{
-  postPatch = ''
-    ln -s ${./Cargo.lock} Cargo.lock
-  '';
-}
+postPatch = ''
+  ln -s ${./Cargo.lock} Cargo.lock
+'';
 ```
 
 The output hash of each dependency that uses a git source must be
@@ -419,7 +408,7 @@ the `cargoPatches` attribute to update or add it.
 
 ```nix
 rustPlatform.buildRustPackage rec {
-  # ...
+  (...)
   cargoPatches = [
     # a patch file to add/update Cargo.lock in the source code
     ./add-Cargo.lock.patch
@@ -443,12 +432,10 @@ containing `Cargo.toml` and `Cargo.lock`, `fetchCargoTarball`
 can be used as follows:
 
 ```nix
-{
-  cargoDeps = rustPlatform.fetchCargoTarball {
-    inherit src;
-    hash = "sha256-BoHIN/519Top1NUBjpB/oEMqi86Omt3zTQcXFWqrek0=";
-  };
-}
+cargoDeps = rustPlatform.fetchCargoTarball {
+  inherit src;
+  hash = "sha256-BoHIN/519Top1NUBjpB/oEMqi86Omt3zTQcXFWqrek0=";
+};
 ```
 
 The `src` attribute is required, as well as a hash specified through
@@ -470,27 +457,23 @@ function does not require a hash (unless git dependencies are used)
 and fetches every dependency as a separate fixed-output derivation.
 `importCargoLock` can be used as follows:
 
-```nix
-{
-  cargoDeps = rustPlatform.importCargoLock {
-    lockFile = ./Cargo.lock;
-  };
-}
+```
+cargoDeps = rustPlatform.importCargoLock {
+  lockFile = ./Cargo.lock;
+};
 ```
 
 If the `Cargo.lock` file includes git dependencies, then their output
 hashes need to be specified since they are not available through the
 lock file. For example:
 
-```nix
-{
-  cargoDeps = rustPlatform.importCargoLock {
-    lockFile = ./Cargo.lock;
-    outputHashes = {
-      "rand-0.8.3" = "0ya2hia3cn31qa8894s3av2s8j5bjwb6yq92k0jsnlx7jid0jwqa";
-    };
+```
+cargoDeps = rustPlatform.importCargoLock {
+  lockFile = ./Cargo.lock;
+  outputHashes = {
+    "rand-0.8.3" = "0ya2hia3cn31qa8894s3av2s8j5bjwb6yq92k0jsnlx7jid0jwqa";
   };
-}
+};
 ```
 
 If you do not specify an output hash for a git dependency, building
@@ -667,66 +650,6 @@ buildPythonPackage rec {
 }
 ```
 
-#### Rust package built with `meson` {#rust-package-built-with-meson}
-
-Some projects, especially GNOME applications, are built with the Meson Build System instead of calling Cargo directly. Using `rustPlatform.buildRustPackage` may successfully build the main program, but related files will be missing. Instead, you need to set up Cargo dependencies with `fetchCargoTarball` and `cargoSetupHook` and leave the rest to Meson. `rust` and `cargo` are still needed in `nativeBuildInputs` for Meson to use.
-
-```nix
-{ lib
-, stdenv
-, fetchFromGitLab
-, meson
-, ninja
-, pkg-config
-, rustPlatform
-, rustc
-, cargo
-, wrapGAppsHook4
-, blueprint-compiler
-, libadwaita
-, libsecret
-, tracker
-}:
-
-stdenv.mkDerivation rec {
-  pname = "health";
-  version = "0.95.0";
-
-  src = fetchFromGitLab {
-    domain = "gitlab.gnome.org";
-    owner = "World";
-    repo = "health";
-    rev = version;
-    hash = "sha256-PrNPprSS98yN8b8yw2G6hzTSaoE65VbsM3q7FVB4mds=";
-  };
-
-  cargoDeps = rustPlatform.fetchCargoTarball {
-    inherit src;
-    name = "${pname}-${version}";
-    hash = "sha256-8fa3fa+sFi5H+49B5sr2vYPkp9C9s6CcE0zv4xB8gww=";
-  };
-
-  nativeBuildInputs = [
-    meson
-    ninja
-    pkg-config
-    rustPlatform.cargoSetupHook
-    rustc
-    cargo
-    wrapGAppsHook4
-    blueprint-compiler
-  ];
-
-  buildInputs = [
-    libadwaita
-    libsecret
-    tracker
-  ];
-
-  # ...
-}
-```
-
 ## `buildRustCrate`: Compiling Rust crates using Nix instead of Cargo {#compiling-rust-crates-using-nix-instead-of-cargo}
 
 ### Simple operation {#simple-operation}
@@ -777,7 +700,7 @@ with import <nixpkgs> {};
     hello = attrs: lib.optionalAttrs (lib.versionAtLeast attrs.version "1.0")  {
       postPatch = ''
         substituteInPlace lib/zoneinfo.rs \
-          --replace-fail "/usr/share/zoneinfo" "${tzdata}/share/zoneinfo"
+          --replace "/usr/share/zoneinfo" "${tzdata}/share/zoneinfo"
       '';
     };
   };
@@ -808,27 +731,27 @@ general. A number of other parameters can be overridden:
 - The version of `rustc` used to compile the crate:
 
   ```nix
-  (hello {}).override { rust = pkgs.rust; }
+  (hello {}).override { rust = pkgs.rust; };
   ```
 
 - Whether to build in release mode or debug mode (release mode by
   default):
 
   ```nix
-  (hello {}).override { release = false; }
+  (hello {}).override { release = false; };
   ```
 
 - Whether to print the commands sent to `rustc` when building
   (equivalent to `--verbose` in cargo:
 
   ```nix
-  (hello {}).override { verbose = false; }
+  (hello {}).override { verbose = false; };
   ```
 
 - Extra arguments to be passed to `rustc`:
 
   ```nix
-  (hello {}).override { extraRustcOpts = "-Z debuginfo=2"; }
+  (hello {}).override { extraRustcOpts = "-Z debuginfo=2"; };
   ```
 
 - Phases, just like in any other derivation, can be specified using
@@ -844,7 +767,7 @@ general. A number of other parameters can be overridden:
     preConfigure = ''
        echo "pub const PATH=\"${hi.out}\";" >> src/path.rs"
     '';
-  }
+  };
   ```
 
 ### Setting Up `nix-shell` {#setting-up-nix-shell}
@@ -979,8 +902,8 @@ with import <nixpkgs>
 };
 let
   rustPlatform = makeRustPlatform {
-    cargo = rust-bin.selectLatestNightlyWith (toolchain: toolchain.default);
-    rustc = rust-bin.selectLatestNightlyWith (toolchain: toolchain.default);
+    cargo = rust-bin.stable.latest.minimal;
+    rustc = rust-bin.stable.latest.minimal;
   };
 in
 
@@ -999,11 +922,11 @@ rustPlatform.buildRustPackage rec {
 
   doCheck = false;
 
-  meta = {
+  meta = with lib; {
     description = "A fast line-oriented regex search tool, similar to ag and ack";
     homepage = "https://github.com/BurntSushi/ripgrep";
-    license = with lib.licenses; [ mit unlicense ];
-    maintainers = with lib.maintainers; [];
+    license = with licenses; [ mit unlicense ];
+    maintainers = with maintainers; [];
   };
 }
 ```
@@ -1040,7 +963,7 @@ repository:
      lib.updateManyAttrsByPath [{
        path = [ "packages" "stable" ];
        update = old: old.overrideScope(final: prev: {
-         rustc-unwrapped = prev.rustc-unwrapped.overrideAttrs (_: {
+         rustc = prev.rustc.overrideAttrs (_: {
            src = lib.cleanSource /git/scratch/rust;
            # do *not* put passthru.isReleaseTarball=true here
          });
@@ -1080,3 +1003,4 @@ nix-build $NIXPKGS -A package-broken-by-rust-changes
 The `git submodule update --init` and `cargo vendor` commands above
 require network access, so they can't be performed from within the
 `rustc` derivation, unfortunately.
+

doc/languages-frameworks/swift.section.md

@@ -112,17 +112,13 @@ stdenv.mkDerivation rec {
 If you'd like to build a different configuration than `release`:
 
 ```nix
-{
-  swiftpmBuildConfig = "debug";
-}
+swiftpmBuildConfig = "debug";
 ```
 
 It is also possible to provide additional flags to `swift build`:
 
 ```nix
-{
-  swiftpmFlags = [ "--disable-dead-strip" ];
-}
+swiftpmFlags = [ "--disable-dead-strip" ];
 ```
 
 The default `buildPhase` already passes `-j` for parallel building.
@@ -136,9 +132,7 @@ Including `swiftpm` in your `nativeBuildInputs` also provides a default
 `checkPhase`, but it must be enabled with:
 
 ```nix
-{
-  doCheck = true;
-}
+doCheck = true;
 ```
 
 This essentially runs: `swift test -c release`
@@ -153,15 +147,13 @@ them, we need to make them writable.
 A special function `swiftpmMakeMutable` is available to replace the symlink
 with a writable copy:
 
-```nix
-{
-  configurePhase = generated.configure ++ ''
-    # Replace the dependency symlink with a writable copy.
-    swiftpmMakeMutable swift-crypto
-    # Now apply a patch.
-    patch -p1 -d .build/checkouts/swift-crypto -i ${./some-fix.patch}
-  '';
-}
+```
+configurePhase = generated.configure ++ ''
+  # Replace the dependency symlink with a writable copy.
+  swiftpmMakeMutable swift-crypto
+  # Now apply a patch.
+  patch -p1 -d .build/checkouts/swift-crypto -i ${./some-fix.patch}
+'';
 ```
 
 ## Considerations for custom build tools {#ssec-swift-considerations-for-custom-build-tools}

doc/languages-frameworks/texlive.section.md

@@ -181,11 +181,11 @@ let
       runHook postInstall
     '';
 
-    meta = {
+    meta = with lib; {
       description = "A LaTeX2e class for overhead transparencies";
-      license = lib.licenses.unfreeRedistributable;
-      maintainers = with lib.maintainers; [ veprbl ];
-      platforms = lib.platforms.all;
+      license = licenses.unfreeRedistributable;
+      maintainers = with maintainers; [ veprbl ];
+      platforms = platforms.all;
     };
   };
 
@@ -208,23 +208,3 @@ EOF
   cp test.pdf $out
 ''
 ```
-
-## LuaLaTeX font cache {#sec-language-texlive-lualatex-font-cache}
-
-The font cache for LuaLaTeX is written to `$HOME`.
-Therefore, it is necessary to set `$HOME` to a writable path, e.g. [before using LuaLaTeX in nix derivations](https://github.com/NixOS/nixpkgs/issues/180639):
-```nix
-runCommandNoCC "lualatex-hello-world" {
-  buildInputs = [ texliveFull ];
-} ''
-  mkdir $out
-  echo '\documentclass{article} \begin{document} Hello world \end{document}' > main.tex
-  env HOME=$(mktemp -d) lualatex  -interaction=nonstopmode -output-format=pdf -output-directory=$out ./main.tex
-''
-```
-
-Additionally, [the cache of a user can diverge from the nix store](https://github.com/NixOS/nixpkgs/issues/278718).
-To resolve font issues that might follow, the cache can be removed by the user:
-```ShellSession
-luaotfload-tool --cache=erase --flush-lookups --force
-```

doc/languages-frameworks/vim.section.md

@@ -219,11 +219,9 @@ After running the updater, if nvim-treesitter received an update, also run [`nvi
 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
-{
-  deoplete-fish = super.deoplete-fish.overrideAttrs(old: {
-    dependencies = with super; [ deoplete-nvim vim-fish ];
-  });
-}
+deoplete-fish = super.deoplete-fish.overrideAttrs(old: {
+  dependencies = with super; [ deoplete-nvim vim-fish ];
+});
 ```
 
 Sometimes plugins require an override that must be changed when the plugin is updated. This can cause issues when Vim plugins are auto-updated but the associated override isn't updated. For these plugins, the override should be written so that it specifies all information required to install the plugin, and running `./update.py` doesn't change the derivation for the plugin. Manually updating the override is required to update these types of plugins. An example of such a plugin is `LanguageClient-neovim`.
@@ -266,10 +264,8 @@ pwntester/octo.nvim,,
 You can then reference the generated vim plugins via:
 
 ```nix
-{
-  myVimPlugins = pkgs.vimPlugins.extend (
-    (pkgs.callPackage ./generated.nix {})
-  );
-}
+myVimPlugins = pkgs.vimPlugins.extend (
+  (pkgs.callPackage ./generated.nix {})
+);
 ```
 

doc/manpage-urls.json

@@ -1,326 +1,34 @@
 {
-  "gnunet.conf(5)": "https://docs.gnunet.org/latest/users/configuration.html",
+  "gnunet.conf(5)": "https://docs.gnunet.org/users/configuration.html",
   "mpd(1)": "https://mpd.readthedocs.io/en/latest/mpd.1.html",
   "mpd.conf(5)": "https://mpd.readthedocs.io/en/latest/mpd.conf.5.html",
   "nix.conf(5)": "https://nixos.org/manual/nix/stable/command-ref/conf-file.html",
 
   "portals.conf(5)": "https://github.com/flatpak/xdg-desktop-portal/blob/1.18.1/doc/portals.conf.rst.in",
 
-  "bootctl(1)": "https://www.freedesktop.org/software/systemd/man/bootctl.html",
-  "busctl(1)": "https://www.freedesktop.org/software/systemd/man/busctl.html",
-  "coredumpctl(1)": "https://www.freedesktop.org/software/systemd/man/coredumpctl.html",
-  "homectl(1)": "https://www.freedesktop.org/software/systemd/man/homectl.html",
-  "hostnamectl(1)": "https://www.freedesktop.org/software/systemd/man/hostnamectl.html",
-  "init(1)": "https://www.freedesktop.org/software/systemd/man/init.html",
-  "journalctl(1)": "https://www.freedesktop.org/software/systemd/man/journalctl.html",
-  "localectl(1)": "https://www.freedesktop.org/software/systemd/man/localectl.html",
-  "loginctl(1)": "https://www.freedesktop.org/software/systemd/man/loginctl.html",
-  "machinectl(1)": "https://www.freedesktop.org/software/systemd/man/machinectl.html",
-  "mount.ddi(1)": "https://www.freedesktop.org/software/systemd/man/mount.ddi.html",
-  "networkctl(1)": "https://www.freedesktop.org/software/systemd/man/networkctl.html",
-  "oomctl(1)": "https://www.freedesktop.org/software/systemd/man/oomctl.html",
-  "portablectl(1)": "https://www.freedesktop.org/software/systemd/man/portablectl.html",
-  "resolvconf(1)": "https://www.freedesktop.org/software/systemd/man/resolvconf.html",
-  "resolvectl(1)": "https://www.freedesktop.org/software/systemd/man/resolvectl.html",
-  "systemctl(1)": "https://www.freedesktop.org/software/systemd/man/systemctl.html",
-  "systemd-ac-power(1)": "https://www.freedesktop.org/software/systemd/man/systemd-ac-power.html",
-  "systemd-analyze(1)": "https://www.freedesktop.org/software/systemd/man/systemd-analyze.html",
-  "systemd-ask-password(1)": "https://www.freedesktop.org/software/systemd/man/systemd-ask-password.html",
-  "systemd-cat(1)": "https://www.freedesktop.org/software/systemd/man/systemd-cat.html",
-  "systemd-cgls(1)": "https://www.freedesktop.org/software/systemd/man/systemd-cgls.html",
-  "systemd-cgtop(1)": "https://www.freedesktop.org/software/systemd/man/systemd-cgtop.html",
-  "systemd-creds(1)": "https://www.freedesktop.org/software/systemd/man/systemd-creds.html",
-  "systemd-cryptenroll(1)": "https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html",
-  "systemd-delta(1)": "https://www.freedesktop.org/software/systemd/man/systemd-delta.html",
-  "systemd-detect-virt(1)": "https://www.freedesktop.org/software/systemd/man/systemd-detect-virt.html",
-  "systemd-dissect(1)": "https://www.freedesktop.org/software/systemd/man/systemd-dissect.html",
-  "systemd-escape(1)": "https://www.freedesktop.org/software/systemd/man/systemd-escape.html",
-  "systemd-id128(1)": "https://www.freedesktop.org/software/systemd/man/systemd-id128.html",
-  "systemd-inhibit(1)": "https://www.freedesktop.org/software/systemd/man/systemd-inhibit.html",
-  "systemd-machine-id-setup(1)": "https://www.freedesktop.org/software/systemd/man/systemd-machine-id-setup.html",
-  "systemd-measure(1)": "https://www.freedesktop.org/software/systemd/man/systemd-measure.html",
-  "systemd-mount(1)": "https://www.freedesktop.org/software/systemd/man/systemd-mount.html",
-  "systemd-notify(1)": "https://www.freedesktop.org/software/systemd/man/systemd-notify.html",
-  "systemd-nspawn(1)": "https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html",
-  "systemd-path(1)": "https://www.freedesktop.org/software/systemd/man/systemd-path.html",
-  "systemd-run(1)": "https://www.freedesktop.org/software/systemd/man/systemd-run.html",
-  "systemd-socket-activate(1)": "https://www.freedesktop.org/software/systemd/man/systemd-socket-activate.html",
-  "systemd-stdio-bridge(1)": "https://www.freedesktop.org/software/systemd/man/systemd-stdio-bridge.html",
-  "systemd-tty-ask-password-agent(1)": "https://www.freedesktop.org/software/systemd/man/systemd-tty-ask-password-agent.html",
-  "systemd-umount(1)": "https://www.freedesktop.org/software/systemd/man/systemd-umount.html",
-  "systemd(1)": "https://www.freedesktop.org/software/systemd/man/systemd.html",
-  "timedatectl(1)": "https://www.freedesktop.org/software/systemd/man/timedatectl.html",
-  "userdbctl(1)": "https://www.freedesktop.org/software/systemd/man/userdbctl.html",
-  "binfmt.d(5)": "https://www.freedesktop.org/software/systemd/man/binfmt.d.html",
-  "coredump.conf(5)": "https://www.freedesktop.org/software/systemd/man/coredump.conf.html",
-  "coredump.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/coredump.conf.d.html",
-  "crypttab(5)": "https://www.freedesktop.org/software/systemd/man/crypttab.html",
-  "dnssec-trust-anchors.d(5)": "https://www.freedesktop.org/software/systemd/man/dnssec-trust-anchors.d.html",
-  "environment.d(5)": "https://www.freedesktop.org/software/systemd/man/environment.d.html",
-  "extension-release(5)": "https://www.freedesktop.org/software/systemd/man/extension-release.html",
-  "homed.conf(5)": "https://www.freedesktop.org/software/systemd/man/homed.conf.html",
-  "homed.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/homed.conf.d.html",
-  "hostname(5)": "https://www.freedesktop.org/software/systemd/man/hostname.html",
-  "initrd-release(5)": "https://www.freedesktop.org/software/systemd/man/initrd-release.html",
-  "integritytab(5)": "https://www.freedesktop.org/software/systemd/man/integritytab.html",
-  "iocost.conf(5)": "https://www.freedesktop.org/software/systemd/man/iocost.conf.html",
-  "journal-remote.conf(5)": "https://www.freedesktop.org/software/systemd/man/journal-remote.conf.html",
-  "journal-remote.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/journal-remote.conf.d.html",
-  "journal-upload.conf(5)": "https://www.freedesktop.org/software/systemd/man/journal-upload.conf.html",
-  "journal-upload.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/journal-upload.conf.d.html",
   "journald.conf(5)": "https://www.freedesktop.org/software/systemd/man/journald.conf.html",
-  "journald.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/journald.conf.d.html",
-  "journald@.conf(5)": "https://www.freedesktop.org/software/systemd/man/journald@.conf.html",
-  "loader.conf(5)": "https://www.freedesktop.org/software/systemd/man/loader.conf.html",
-  "locale.conf(5)": "https://www.freedesktop.org/software/systemd/man/locale.conf.html",
-  "localtime(5)": "https://www.freedesktop.org/software/systemd/man/localtime.html",
   "logind.conf(5)": "https://www.freedesktop.org/software/systemd/man/logind.conf.html",
-  "logind.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/logind.conf.d.html",
-  "machine-id(5)": "https://www.freedesktop.org/software/systemd/man/machine-id.html",
-  "machine-info(5)": "https://www.freedesktop.org/software/systemd/man/machine-info.html",
-  "modules-load.d(5)": "https://www.freedesktop.org/software/systemd/man/modules-load.d.html",
   "networkd.conf(5)": "https://www.freedesktop.org/software/systemd/man/networkd.conf.html",
-  "networkd.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/networkd.conf.d.html",
-  "oomd.conf(5)": "https://www.freedesktop.org/software/systemd/man/oomd.conf.html",
-  "oomd.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/oomd.conf.d.html",
-  "org.freedesktop.LogControl1(5)": "https://www.freedesktop.org/software/systemd/man/org.freedesktop.LogControl1.html",
-  "org.freedesktop.home1(5)": "https://www.freedesktop.org/software/systemd/man/org.freedesktop.home1.html",
-  "org.freedesktop.hostname1(5)": "https://www.freedesktop.org/software/systemd/man/org.freedesktop.hostname1.html",
-  "org.freedesktop.import1(5)": "https://www.freedesktop.org/software/systemd/man/org.freedesktop.import1.html",
-  "org.freedesktop.locale1(5)": "https://www.freedesktop.org/software/systemd/man/org.freedesktop.locale1.html",
-  "org.freedesktop.login1(5)": "https://www.freedesktop.org/software/systemd/man/org.freedesktop.login1.html",
-  "org.freedesktop.machine1(5)": "https://www.freedesktop.org/software/systemd/man/org.freedesktop.machine1.html",
-  "org.freedesktop.network1(5)": "https://www.freedesktop.org/software/systemd/man/org.freedesktop.network1.html",
-  "org.freedesktop.oom1(5)": "https://www.freedesktop.org/software/systemd/man/org.freedesktop.oom1.html",
-  "org.freedesktop.portable1(5)": "https://www.freedesktop.org/software/systemd/man/org.freedesktop.portable1.html",
-  "org.freedesktop.resolve1(5)": "https://www.freedesktop.org/software/systemd/man/org.freedesktop.resolve1.html",
-  "org.freedesktop.systemd1(5)": "https://www.freedesktop.org/software/systemd/man/org.freedesktop.systemd1.html",
-  "org.freedesktop.timedate1(5)": "https://www.freedesktop.org/software/systemd/man/org.freedesktop.timedate1.html",
-  "os-release(5)": "https://www.freedesktop.org/software/systemd/man/os-release.html",
-  "pstore.conf(5)": "https://www.freedesktop.org/software/systemd/man/pstore.conf.html",
-  "pstore.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/pstore.conf.d.html",
-  "repart.d(5)": "https://www.freedesktop.org/software/systemd/man/repart.d.html",
-  "resolved.conf(5)": "https://www.freedesktop.org/software/systemd/man/resolved.conf.html",
-  "resolved.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/resolved.conf.d.html",
-  "sleep.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/sleep.conf.d.html",
-  "sysctl.d(5)": "https://www.freedesktop.org/software/systemd/man/sysctl.d.html",
-  "system.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/system.conf.d.html",
-  "systemd-sleep.conf(5)": "https://www.freedesktop.org/software/systemd/man/systemd-sleep.conf.html",
-  "systemd-system.conf(5)": "https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html",
-  "systemd-user-runtime-dir(5)": "https://www.freedesktop.org/software/systemd/man/systemd-user-runtime-dir.html",
-  "systemd-user.conf(5)": "https://www.freedesktop.org/software/systemd/man/systemd-user.conf.html",
   "systemd.automount(5)": "https://www.freedesktop.org/software/systemd/man/systemd.automount.html",
-  "systemd.device(5)": "https://www.freedesktop.org/software/systemd/man/systemd.device.html",
-  "systemd.dnssd(5)": "https://www.freedesktop.org/software/systemd/man/systemd.dnssd.html",
   "systemd.exec(5)": "https://www.freedesktop.org/software/systemd/man/systemd.exec.html",
-  "systemd.kill(5)": "https://www.freedesktop.org/software/systemd/man/systemd.kill.html",
   "systemd.link(5)": "https://www.freedesktop.org/software/systemd/man/systemd.link.html",
   "systemd.mount(5)": "https://www.freedesktop.org/software/systemd/man/systemd.mount.html",
-  "systemd.negative(5)": "https://www.freedesktop.org/software/systemd/man/systemd.negative.html",
   "systemd.netdev(5)": "https://www.freedesktop.org/software/systemd/man/systemd.netdev.html",
   "systemd.network(5)": "https://www.freedesktop.org/software/systemd/man/systemd.network.html",
   "systemd.nspawn(5)": "https://www.freedesktop.org/software/systemd/man/systemd.nspawn.html",
   "systemd.path(5)": "https://www.freedesktop.org/software/systemd/man/systemd.path.html",
-  "systemd.positive(5)": "https://www.freedesktop.org/software/systemd/man/systemd.positive.html",
-  "systemd.preset(5)": "https://www.freedesktop.org/software/systemd/man/systemd.preset.html",
   "systemd.resource-control(5)": "https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html",
   "systemd.scope(5)": "https://www.freedesktop.org/software/systemd/man/systemd.scope.html",
   "systemd.service(5)": "https://www.freedesktop.org/software/systemd/man/systemd.service.html",
   "systemd.slice(5)": "https://www.freedesktop.org/software/systemd/man/systemd.slice.html",
   "systemd.socket(5)": "https://www.freedesktop.org/software/systemd/man/systemd.socket.html",
-  "systemd.swap(5)": "https://www.freedesktop.org/software/systemd/man/systemd.swap.html",
-  "systemd.target(5)": "https://www.freedesktop.org/software/systemd/man/systemd.target.html",
   "systemd.timer(5)": "https://www.freedesktop.org/software/systemd/man/systemd.timer.html",
   "systemd.unit(5)": "https://www.freedesktop.org/software/systemd/man/systemd.unit.html",
-  "sysupdate.d(5)": "https://www.freedesktop.org/software/systemd/man/sysupdate.d.html",
-  "sysusers.d(5)": "https://www.freedesktop.org/software/systemd/man/sysusers.d.html",
+  "systemd-system.conf(5)": "https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html",
+  "systemd-user.conf(5)": "https://www.freedesktop.org/software/systemd/man/systemd-user.conf.html",
   "timesyncd.conf(5)": "https://www.freedesktop.org/software/systemd/man/timesyncd.conf.html",
-  "timesyncd.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/timesyncd.conf.d.html",
   "tmpfiles.d(5)": "https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html",
-  "udev.conf(5)": "https://www.freedesktop.org/software/systemd/man/udev.conf.html",
-  "user-runtime-dir@.service(5)": "https://www.freedesktop.org/software/systemd/man/user-runtime-dir@.service.html",
-  "user.conf.d(5)": "https://www.freedesktop.org/software/systemd/man/user.conf.d.html",
-  "user@.service(5)": "https://www.freedesktop.org/software/systemd/man/user@.service.html",
-  "vconsole.conf(5)": "https://www.freedesktop.org/software/systemd/man/vconsole.conf.html",
-  "veritytab(5)": "https://www.freedesktop.org/software/systemd/man/veritytab.html",
-  "bootup(7)": "https://www.freedesktop.org/software/systemd/man/bootup.html",
-  "daemon(7)": "https://www.freedesktop.org/software/systemd/man/daemon.html",
-  "file-hierarchy(7)": "https://www.freedesktop.org/software/systemd/man/file-hierarchy.html",
-  "hwdb(7)": "https://www.freedesktop.org/software/systemd/man/hwdb.html",
-  "kernel-command-line(7)": "https://www.freedesktop.org/software/systemd/man/kernel-command-line.html",
-  "linuxaa64.efi.stub(7)": "https://www.freedesktop.org/software/systemd/man/linuxaa64.efi.stub.html",
-  "linuxia32.efi.stub(7)": "https://www.freedesktop.org/software/systemd/man/linuxia32.efi.stub.html",
-  "linuxx64.efi.stub(7)": "https://www.freedesktop.org/software/systemd/man/linuxx64.efi.stub.html",
-  "sd-boot(7)": "https://www.freedesktop.org/software/systemd/man/sd-boot.html",
-  "sd-stub(7)": "https://www.freedesktop.org/software/systemd/man/sd-stub.html",
-  "smbios-type-11(7)": "https://www.freedesktop.org/software/systemd/man/smbios-type-11.html",
-  "systemd-boot(7)": "https://www.freedesktop.org/software/systemd/man/systemd-boot.html",
-  "systemd-stub(7)": "https://www.freedesktop.org/software/systemd/man/systemd-stub.html",
-  "systemd.directives(7)": "https://www.freedesktop.org/software/systemd/man/systemd.directives.html",
-  "systemd.environment-generator(7)": "https://www.freedesktop.org/software/systemd/man/systemd.environment-generator.html",
-  "systemd.generator(7)": "https://www.freedesktop.org/software/systemd/man/systemd.generator.html",
-  "systemd.image-policy(7)": "https://www.freedesktop.org/software/systemd/man/systemd.image-policy.html",
-  "systemd.index(7)": "https://www.freedesktop.org/software/systemd/man/systemd.index.html",
-  "systemd.journal-fields(7)": "https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html",
-  "systemd.net-naming-scheme(7)": "https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html",
-  "systemd.offline-updates(7)": "https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html",
-  "systemd.special(7)": "https://www.freedesktop.org/software/systemd/man/systemd.special.html",
-  "systemd.syntax(7)": "https://www.freedesktop.org/software/systemd/man/systemd.syntax.html",
-  "systemd.system-credentials(7)": "https://www.freedesktop.org/software/systemd/man/systemd.system-credentials.html",
   "systemd.time(7)": "https://www.freedesktop.org/software/systemd/man/systemd.time.html",
-  "udev(7)": "https://www.freedesktop.org/software/systemd/man/udev.html",
-  "30-systemd-environment-d-generator(8)": "https://www.freedesktop.org/software/systemd/man/30-systemd-environment-d-generator.html",
-  "halt(8)": "https://www.freedesktop.org/software/systemd/man/halt.html",
-  "kernel-install(8)": "https://www.freedesktop.org/software/systemd/man/kernel-install.html",
-  "libnss_myhostname.so.2(8)": "https://www.freedesktop.org/software/systemd/man/libnss_myhostname.so.2.html",
-  "libnss_mymachines.so.2(8)": "https://www.freedesktop.org/software/systemd/man/libnss_mymachines.so.2.html",
-  "libnss_resolve.so.2(8)": "https://www.freedesktop.org/software/systemd/man/libnss_resolve.so.2.html",
-  "libnss_systemd.so.2(8)": "https://www.freedesktop.org/software/systemd/man/libnss_systemd.so.2.html",
-  "nss-myhostname(8)": "https://www.freedesktop.org/software/systemd/man/nss-myhostname.html",
-  "nss-mymachines(8)": "https://www.freedesktop.org/software/systemd/man/nss-mymachines.html",
-  "nss-resolve(8)": "https://www.freedesktop.org/software/systemd/man/nss-resolve.html",
-  "nss-systemd(8)": "https://www.freedesktop.org/software/systemd/man/nss-systemd.html",
-  "pam_systemd(8)": "https://www.freedesktop.org/software/systemd/man/pam_systemd.html",
-  "pam_systemd_home(8)": "https://www.freedesktop.org/software/systemd/man/pam_systemd_home.html",
-  "poweroff(8)": "https://www.freedesktop.org/software/systemd/man/poweroff.html",
-  "reboot(8)": "https://www.freedesktop.org/software/systemd/man/reboot.html",
-  "shutdown(8)": "https://www.freedesktop.org/software/systemd/man/shutdown.html",
-  "systemd-ask-password-console.path(8)": "https://www.freedesktop.org/software/systemd/man/systemd-ask-password-console.path.html",
-  "systemd-ask-password-console.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-ask-password-console.service.html",
-  "systemd-ask-password-wall.path(8)": "https://www.freedesktop.org/software/systemd/man/systemd-ask-password-wall.path.html",
-  "systemd-ask-password-wall.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-ask-password-wall.service.html",
-  "systemd-backlight(8)": "https://www.freedesktop.org/software/systemd/man/systemd-backlight.html",
-  "systemd-backlight@.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-backlight@.service.html",
-  "systemd-battery-check(8)": "https://www.freedesktop.org/software/systemd/man/systemd-battery-check.html",
-  "systemd-binfmt(8)": "https://www.freedesktop.org/software/systemd/man/systemd-binfmt.html",
-  "systemd-bless-boot-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-bless-boot-generator.html",
-  "systemd-bless-boot(8)": "https://www.freedesktop.org/software/systemd/man/systemd-bless-boot.html",
-  "systemd-boot-check-no-failures(8)": "https://www.freedesktop.org/software/systemd/man/systemd-boot-check-no-failures.html",
-  "systemd-boot-random-seed.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-boot-random-seed.service.html",
-  "systemd-confext(8)": "https://www.freedesktop.org/software/systemd/man/systemd-confext.html",
-  "systemd-confext.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-confext.service.html",
-  "systemd-coredump(8)": "https://www.freedesktop.org/software/systemd/man/systemd-coredump.html",
-  "systemd-coredump.socket(8)": "https://www.freedesktop.org/software/systemd/man/systemd-coredump.socket.html",
-  "systemd-coredump@.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-coredump@.service.html",
-  "systemd-cryptsetup-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html",
-  "systemd-cryptsetup(8)": "https://www.freedesktop.org/software/systemd/man/systemd-cryptsetup.html",
-  "systemd-cryptsetup@.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-cryptsetup@.service.html",
-  "systemd-debug-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-debug-generator.html",
-  "systemd-environment-d-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-environment-d-generator.html",
-  "systemd-fsck-root.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-fsck-root.service.html",
-  "systemd-fsck-usr.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-fsck-usr.service.html",
-  "systemd-fsck(8)": "https://www.freedesktop.org/software/systemd/man/systemd-fsck.html",
-  "systemd-fsck@.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-fsck@.service.html",
   "systemd-fstab-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html",
-  "systemd-getty-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-getty-generator.html",
-  "systemd-gpt-auto-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html",
-  "systemd-growfs-root.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-growfs-root.service.html",
-  "systemd-growfs(8)": "https://www.freedesktop.org/software/systemd/man/systemd-growfs.html",
-  "systemd-growfs@.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-growfs@.service.html",
-  "systemd-halt.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-halt.service.html",
-  "systemd-hibernate-resume-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-hibernate-resume-generator.html",
-  "systemd-hibernate-resume(8)": "https://www.freedesktop.org/software/systemd/man/systemd-hibernate-resume.html",
-  "systemd-hibernate.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-hibernate.service.html",
-  "systemd-homed(8)": "https://www.freedesktop.org/software/systemd/man/systemd-homed.html",
-  "systemd-hostnamed(8)": "https://www.freedesktop.org/software/systemd/man/systemd-hostnamed.html",
-  "systemd-hwdb(8)": "https://www.freedesktop.org/software/systemd/man/systemd-hwdb.html",
-  "systemd-hybrid-sleep.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-hybrid-sleep.service.html",
-  "systemd-importd(8)": "https://www.freedesktop.org/software/systemd/man/systemd-importd.html",
-  "systemd-integritysetup-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-integritysetup-generator.html",
-  "systemd-integritysetup(8)": "https://www.freedesktop.org/software/systemd/man/systemd-integritysetup.html",
-  "systemd-integritysetup@.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-integritysetup@.service.html",
-  "systemd-journal-gatewayd(8)": "https://www.freedesktop.org/software/systemd/man/systemd-journal-gatewayd.html",
-  "systemd-journal-gatewayd.socket(8)": "https://www.freedesktop.org/software/systemd/man/systemd-journal-gatewayd.socket.html",
-  "systemd-journal-remote(8)": "https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html",
-  "systemd-journal-remote.socket(8)": "https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.socket.html",
-  "systemd-journal-upload(8)": "https://www.freedesktop.org/software/systemd/man/systemd-journal-upload.html",
-  "systemd-journald-audit.socket(8)": "https://www.freedesktop.org/software/systemd/man/systemd-journald-audit.socket.html",
-  "systemd-journald-dev-log.socket(8)": "https://www.freedesktop.org/software/systemd/man/systemd-journald-dev-log.socket.html",
-  "systemd-journald-varlink@.socket(8)": "https://www.freedesktop.org/software/systemd/man/systemd-journald-varlink@.socket.html",
-  "systemd-journald(8)": "https://www.freedesktop.org/software/systemd/man/systemd-journald.html",
-  "systemd-journald.socket(8)": "https://www.freedesktop.org/software/systemd/man/systemd-journald.socket.html",
-  "systemd-journald@.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-journald@.service.html",
-  "systemd-journald@.socket(8)": "https://www.freedesktop.org/software/systemd/man/systemd-journald@.socket.html",
-  "systemd-kexec.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-kexec.service.html",
-  "systemd-localed(8)": "https://www.freedesktop.org/software/systemd/man/systemd-localed.html",
-  "systemd-logind(8)": "https://www.freedesktop.org/software/systemd/man/systemd-logind.html",
-  "systemd-machine-id-commit.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-machine-id-commit.service.html",
-  "systemd-machined(8)": "https://www.freedesktop.org/software/systemd/man/systemd-machined.html",
-  "systemd-makefs(8)": "https://www.freedesktop.org/software/systemd/man/systemd-makefs.html",
-  "systemd-makefs@.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-makefs@.service.html",
-  "systemd-mkswap@.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-mkswap@.service.html",
-  "systemd-modules-load(8)": "https://www.freedesktop.org/software/systemd/man/systemd-modules-load.html",
-  "systemd-network-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-network-generator.html",
-  "systemd-networkd-wait-online(8)": "https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.html",
-  "systemd-networkd-wait-online@.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online@.service.html",
-  "systemd-networkd(8)": "https://www.freedesktop.org/software/systemd/man/systemd-networkd.html",
-  "systemd-oomd(8)": "https://www.freedesktop.org/software/systemd/man/systemd-oomd.html",
-  "systemd-pcrfs-root.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-pcrfs-root.service.html",
-  "systemd-pcrfs@.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-pcrfs@.service.html",
-  "systemd-pcrmachine.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-pcrmachine.service.html",
-  "systemd-pcrphase-initrd.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-pcrphase-initrd.service.html",
-  "systemd-pcrphase-sysinit.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-pcrphase-sysinit.service.html",
-  "systemd-pcrphase(8)": "https://www.freedesktop.org/software/systemd/man/systemd-pcrphase.html",
-  "systemd-portabled(8)": "https://www.freedesktop.org/software/systemd/man/systemd-portabled.html",
-  "systemd-poweroff.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-poweroff.service.html",
-  "systemd-pstore(8)": "https://www.freedesktop.org/software/systemd/man/systemd-pstore.html",
-  "systemd-random-seed(8)": "https://www.freedesktop.org/software/systemd/man/systemd-random-seed.html",
-  "systemd-reboot.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-reboot.service.html",
-  "systemd-remount-fs(8)": "https://www.freedesktop.org/software/systemd/man/systemd-remount-fs.html",
-  "systemd-repart(8)": "https://www.freedesktop.org/software/systemd/man/systemd-repart.html",
-  "systemd-repart.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html",
-  "systemd-resolved(8)": "https://www.freedesktop.org/software/systemd/man/systemd-resolved.html",
-  "systemd-rfkill(8)": "https://www.freedesktop.org/software/systemd/man/systemd-rfkill.html",
-  "systemd-rfkill.socket(8)": "https://www.freedesktop.org/software/systemd/man/systemd-rfkill.socket.html",
-  "systemd-run-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-run-generator.html",
-  "systemd-shutdown(8)": "https://www.freedesktop.org/software/systemd/man/systemd-shutdown.html",
-  "systemd-sleep(8)": "https://www.freedesktop.org/software/systemd/man/systemd-sleep.html",
-  "systemd-socket-proxyd(8)": "https://www.freedesktop.org/software/systemd/man/systemd-socket-proxyd.html",
-  "systemd-soft-reboot.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-soft-reboot.service.html",
-  "systemd-suspend-then-hibernate.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-suspend-then-hibernate.service.html",
-  "systemd-suspend.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-suspend.service.html",
-  "systemd-sysctl(8)": "https://www.freedesktop.org/software/systemd/man/systemd-sysctl.html",
-  "systemd-sysext(8)": "https://www.freedesktop.org/software/systemd/man/systemd-sysext.html",
-  "systemd-sysext.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-sysext.service.html",
-  "systemd-system-update-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html",
-  "systemd-sysupdate-reboot.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-sysupdate-reboot.service.html",
-  "systemd-sysupdate-reboot.timer(8)": "https://www.freedesktop.org/software/systemd/man/systemd-sysupdate-reboot.timer.html",
-  "systemd-sysupdate(8)": "https://www.freedesktop.org/software/systemd/man/systemd-sysupdate.html",
-  "systemd-sysupdate.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-sysupdate.service.html",
-  "systemd-sysupdate.timer(8)": "https://www.freedesktop.org/software/systemd/man/systemd-sysupdate.timer.html",
-  "systemd-sysusers(8)": "https://www.freedesktop.org/software/systemd/man/systemd-sysusers.html",
-  "systemd-sysusers.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-sysusers.service.html",
-  "systemd-time-wait-sync(8)": "https://www.freedesktop.org/software/systemd/man/systemd-time-wait-sync.html",
-  "systemd-timedated(8)": "https://www.freedesktop.org/software/systemd/man/systemd-timedated.html",
-  "systemd-timesyncd(8)": "https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.html",
-  "systemd-tmpfiles-clean.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles-clean.service.html",
-  "systemd-tmpfiles-clean.timer(8)": "https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles-clean.timer.html",
-  "systemd-tmpfiles-setup-dev-early.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles-setup-dev-early.service.html",
-  "systemd-tmpfiles-setup-dev.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles-setup-dev.service.html",
-  "systemd-tmpfiles-setup.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles-setup.service.html",
-  "systemd-tmpfiles(8)": "https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html",
-  "systemd-udev-settle.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-udev-settle.service.html",
-  "systemd-udevd-control.socket(8)": "https://www.freedesktop.org/software/systemd/man/systemd-udevd-control.socket.html",
-  "systemd-udevd-kernel.socket(8)": "https://www.freedesktop.org/software/systemd/man/systemd-udevd-kernel.socket.html",
-  "systemd-udevd(8)": "https://www.freedesktop.org/software/systemd/man/systemd-udevd.html",
-  "systemd-update-done(8)": "https://www.freedesktop.org/software/systemd/man/systemd-update-done.html",
-  "systemd-update-utmp-runlevel.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-update-utmp-runlevel.service.html",
-  "systemd-update-utmp(8)": "https://www.freedesktop.org/software/systemd/man/systemd-update-utmp.html",
-  "systemd-user-sessions(8)": "https://www.freedesktop.org/software/systemd/man/systemd-user-sessions.html",
-  "systemd-userdbd(8)": "https://www.freedesktop.org/software/systemd/man/systemd-userdbd.html",
-  "systemd-vconsole-setup(8)": "https://www.freedesktop.org/software/systemd/man/systemd-vconsole-setup.html",
-  "systemd-veritysetup-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-veritysetup-generator.html",
-  "systemd-veritysetup(8)": "https://www.freedesktop.org/software/systemd/man/systemd-veritysetup.html",
-  "systemd-veritysetup@.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-veritysetup@.service.html",
-  "systemd-volatile-root(8)": "https://www.freedesktop.org/software/systemd/man/systemd-volatile-root.html",
-  "systemd-xdg-autostart-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-xdg-autostart-generator.html",
-  "udevadm(8)": "https://www.freedesktop.org/software/systemd/man/udevadm.html",
-  "passwd(5)": "https://man.archlinux.org/man/passwd.5",
-  "group(5)": "https://man.archlinux.org/man/group.5",
-  "login.defs(5)": "https://man.archlinux.org/man/login.defs.5",
-  "unshare(1)": "https://man.archlinux.org/man/unshare.1.en",
-  "nix-shell(1)": "https://nixos.org/manual/nix/stable/command-ref/nix-shell.html",
-  "mksquashfs(1)": "https://man.archlinux.org/man/extra/squashfs-tools/mksquashfs.1.en",
-  "curl(1)": "https://curl.se/docs/manpage.html",
-  "netrc(5)": "https://man.cx/netrc"
+  "systemd-networkd-wait-online.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html"
 }

doc/manual.md.in

@@ -1,4 +1,4 @@
-# Nixpkgs Reference Manual {#nixpkgs-manual}
+# Nixpkgs Manual {#nixpkgs-manual}
 ## Version @MANUAL_VERSION@
 
 ```{=include=} chapters