Merge branch 'nixos-unstable' of https://github.com/NixOS/nixpkgs

Conflicts:
	nixpkgs/pkgs/applications/window-managers/sway/default.nix
	nixpkgs/pkgs/build-support/go/module.nix
	nixpkgs/pkgs/build-support/rust/build-rust-package/default.nix
	nixpkgs/pkgs/development/libraries/mesa/default.nix
	nixpkgs/pkgs/servers/dict/dictd-db.nix

Link: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/391

17 files changed, 456 insertions, 224 deletions

diff --git a/nixpkgs/doc/languages-frameworks/bower.section.md b/nixpkgs/doc/languages-frameworks/bower.section.md
index f39539059c04..fceb6aaccb6d 100644
--- a/nixpkgs/doc/languages-frameworks/bower.section.md
+++ b/nixpkgs/doc/languages-frameworks/bower.section.md
@@ -41,32 +41,18 @@ The function is implemented in [pkgs/development/bower-modules/generic/default.n
 
 ### Example buildBowerComponents {#ex-buildBowerComponents}
 
-```{=docbook}
-<programlisting language="nix">
+```nix
 bowerComponents = buildBowerComponents {
   name = "my-web-app";
-  generated = ./bower-packages.nix; <co xml:id="ex-buildBowerComponents-1" />
-  src = myWebApp; <co xml:id="ex-buildBowerComponents-2" />
+  generated = ./bower-packages.nix; # note 1
+  src = myWebApp; # note 2
 };
-</programlisting>
 ```
 
 In ["buildBowerComponents" example](#ex-buildBowerComponents) the following arguments are of special significance to the function:
 
-```{=docbook}
-<calloutlist>
-  <callout arearefs="ex-buildBowerComponents-1">
-    <para>
-      <varname>generated</varname> specifies the file which was created by <command>bower2nix</command>.
-    </para>
-    </callout>
-      <callout arearefs="ex-buildBowerComponents-2">
-    <para>
-      <varname>src</varname> is your project's sources. It needs to contain a <filename>bower.json</filename> file.
-    </para>
-  </callout>
-</calloutlist>
-```
+1. `generated` specifies the file which was created by {command}`bower2nix`.
+2. `src` is your project's sources. It needs to contain a {file}`bower.json` file.
 
 `buildBowerComponents` will run Bower to link together the output of `bower2nix`, resulting in a `bower_components` directory which can be used.
 
@@ -91,10 +77,9 @@ gulp.task('build', [], function () {
 
 ### Example Full example — default.nix {#ex-buildBowerComponentsDefaultNix}
 
-```{=docbook}
-<programlisting language="nix">
+```nix
 { myWebApp ? { outPath = ./.; name = "myWebApp"; }
-, pkgs ? import &lt;nixpkgs&gt; {}
+, pkgs ? import <nixpkgs> {}
 }:
 
 pkgs.stdenv.mkDerivation {
@@ -103,49 +88,29 @@ pkgs.stdenv.mkDerivation {
 
   buildInputs = [ pkgs.nodePackages.gulp ];
 
-  bowerComponents = pkgs.buildBowerComponents { <co xml:id="ex-buildBowerComponentsDefault-1" />
+  bowerComponents = pkgs.buildBowerComponents { # note 1
     name = "my-web-app";
     generated = ./bower-packages.nix;
     src = myWebApp;
   };
 
   buildPhase = ''
-    cp --reflink=auto --no-preserve=mode -R $bowerComponents/bower_components . <co xml:id="ex-buildBowerComponentsDefault-2" />
-    export HOME=$PWD <co xml:id="ex-buildBowerComponentsDefault-3" />
-    ${pkgs.nodePackages.gulp}/bin/gulp build <co xml:id="ex-buildBowerComponentsDefault-4" />
+    cp --reflink=auto --no-preserve=mode -R $bowerComponents/bower_components . # note 2
+    export HOME=$PWD # note 3
+    ${pkgs.nodePackages.gulp}/bin/gulp build # note 4
   '';
 
   installPhase = "mv gulpdist $out";
 }
-</programlisting>
 ```
 
 A few notes about [Full example — `default.nix`](#ex-buildBowerComponentsDefaultNix):
 
-```{=docbook}
-<calloutlist>
-  <callout arearefs="ex-buildBowerComponentsDefault-1">
-    <para>
-      The result of <varname>buildBowerComponents</varname> is an input to the frontend build.
-    </para>
-  </callout>
-  <callout arearefs="ex-buildBowerComponentsDefault-2">
-    <para>
-      Whether to symlink or copy the <filename>bower_components</filename> directory depends on the build tool in use. In this case a copy is used to avoid <command>gulp</command> silliness with permissions.
-    </para>
-  </callout>
-  <callout arearefs="ex-buildBowerComponentsDefault-3">
-    <para>
-      <command>gulp</command> requires <varname>HOME</varname> to refer to a writeable directory.
-    </para>
-  </callout>
-  <callout arearefs="ex-buildBowerComponentsDefault-4">
-    <para>
-      The actual build command. Other tools could be used.
-    </para>
-  </callout>
-</calloutlist>
-```
+1. The result of `buildBowerComponents` is an input to the frontend build.
+2. Whether to symlink or copy the {file}`bower_components` directory depends on the build tool in use.
+   In this case a copy is used to avoid {command}`gulp` silliness with permissions.
+3. {command}`gulp` requires `HOME` to refer to a writeable directory.
+4. The actual build command in this example is {command}`gulp`. Other tools could be used instead.
 
 ## Troubleshooting {#ssec-bower2nix-troubleshooting}
 
diff --git a/nixpkgs/doc/languages-frameworks/cuda.section.md b/nixpkgs/doc/languages-frameworks/cuda.section.md
index 6b19e02e74e9..b7f1f19546a7 100644
--- a/nixpkgs/doc/languages-frameworks/cuda.section.md
+++ b/nixpkgs/doc/languages-frameworks/cuda.section.md
@@ -12,8 +12,11 @@ compatible are available as well. For example, there can be a
 
 To use one or more CUDA packages in an expression, give the expression a `cudaPackages` parameter, and in case CUDA is optional
 ```nix
-cudaSupport ? false
-cudaPackages ? {}
+{ config
+, cudaSupport ? config.cudaSupport
+, cudaPackages ? { }
+, ...
+}:
 ```
 
 When using `callPackage`, you can choose to pass in a different variant, e.g.
diff --git a/nixpkgs/doc/languages-frameworks/dotnet.section.md b/nixpkgs/doc/languages-frameworks/dotnet.section.md
index b6a622875a76..246490d67d26 100644
--- a/nixpkgs/doc/languages-frameworks/dotnet.section.md
+++ b/nixpkgs/doc/languages-frameworks/dotnet.section.md
@@ -92,7 +92,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 usually have `.sln` or `.csproj` file extensions. This can be a list of multiple projects as well. Most of the time dotnet can figure this location out by itself, so this should only be set if necessary.
+* `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`. 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.
@@ -108,11 +108,13 @@ To package Dotnet applications, you can use `buildDotnetModule`. This has simila
 * `executables` is used to specify which executables get wrapped to `$out/bin`, relative to `$out/lib/$pname`. If this is unset, all executables generated will get installed. If you do not want to install any, set this to `[]`. This gets done in the `preFixup` phase.
 * `runtimeDeps` is used to wrap libraries into `LD_LIBRARY_PATH`. This is how dotnet usually handles runtime dependencies.
 * `buildType` is used to change the type of build. Possible values are `Release`, `Debug`, etc. By default, this is set to `Release`.
-* `selfContainedBuild` allows to enable the [self-contained](https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained) build flag. By default, it is set to false and generated applications have a dependency on the selected dotnet runtime. If enabled, the dotnet runtime is bundled into the executable and the built app has no dependency on Dotnet.
+* `selfContainedBuild` allows to enable the [self-contained](https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained) build flag. By default, it is set to false and generated applications have a dependency on the selected dotnet runtime. If enabled, the dotnet runtime is bundled into the executable and the built app has no dependency on .NET.
+* `useAppHost` will enable creation of a binary executable that runs the .NET application using the specified root. More info in [Microsoft docs](https://learn.microsoft.com/en-us/dotnet/core/deploying/#publish-framework-dependent). Enabled by default.
+* `useDotnetFromEnv` will change the binary wrapper so that it uses the .NET from the environment. The runtime specified by `dotnet-runtime` is given as a fallback in case no .NET is installed in the user's environment. This is most useful for .NET global tools and LSP servers, which often extend the .NET CLI and their runtime should match the users' .NET runtime.
 * `dotnet-sdk` is useful in cases where you need to change what dotnet SDK is being used. You can also set this to the result of `dotnetSdkPackages.combinePackages`, if the project uses multiple SDKs to build.
 * `dotnet-runtime` is useful in cases where you need to change what dotnet runtime is being used. This can be either a regular dotnet runtime, or an aspnetcore.
 * `dotnet-test-sdk` is useful in cases where unit tests expect a different dotnet SDK. By default, this is set to the `dotnet-sdk` attribute.
-* `testProjectFile` is useful in cases where the regular project file does not contain the unit tests. It gets restored and build, but not installed. You may need to regenerate your nuget lockfile after setting this.
+* `testProjectFile` is useful in cases where the regular project file does not contain the unit tests. It gets restored and build, but not installed. You may need to regenerate your nuget lockfile after setting this. Note that if set, only tests from this project are executed.
 * `disabledTests` is used to disable running specific unit tests. This gets passed as: `dotnet test --filter "FullyQualifiedName!={}"`, to ensure compatibility with all unit test frameworks.
 * `dotnetRestoreFlags` can be used to pass flags to `dotnet restore`.
 * `dotnetBuildFlags` can be used to pass flags to `dotnet build`.
@@ -121,7 +123,7 @@ To package Dotnet applications, you can use `buildDotnetModule`. This has simila
 * `dotnetPackFlags` can be used to pass flags to `dotnet pack`. Used only if `packNupkg` is set to `true`.
 * `dotnetFlags` can be used to pass flags to all of the above phases.
 
-When packaging a new application, you need to fetch its dependencies. You can run `nix-build -A package.fetch-deps` to generate a script that will build a lockfile for you. After running the script you should have the location of the generated lockfile printed to the console, which can be copied to a stable directory. Then set `nugetDeps = ./deps.nix` and you're ready to build the derivation.
+When packaging a new application, you need to fetch its dependencies. Create an empty `deps.nix`, set `nugetDeps = ./deps.nix`, then run `nix-build -A package.fetch-deps` to generate a script that will build the lockfile for you.
 
 Here is an example `default.nix`, using some of the previously discussed arguments:
 ```nix
@@ -151,3 +153,60 @@ in buildDotnetModule rec {
   runtimeDeps = [ ffmpeg ]; # This will wrap ffmpeg's library path into `LD_LIBRARY_PATH`.
 }
 ```
+
+## 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.
+
+They can be installed either as a global tool for the entire system, or as a local tool specific to project.
+
+The local installation is the easiest and works on NixOS in the same way as on other Linux distributions.
+[See dotnet documention](https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools#install-a-local-tool) to learn more.
+
+[The global installation method](https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools#install-a-global-tool)
+should also work most of the time. You have to remember to update the `PATH`
+value to the location the tools are installed to (the CLI will inform you about it during installation) and also set
+the `DOTNET_ROOT` value, so that the tool can find the .NET SDK package.
+You can find the path to the SDK by running `nix eval --raw nixpkgs#dotnet-sdk` (substitute the `dotnet-sdk` package for
+another if a different SDK version is needed).
+
+This method is not recommended on NixOS, since it's not declarative and involves installing binaries not made for NixOS,
+which will not always work.
+
+The third, and preferred way, is packaging the tool into a Nix derivation.
+
+### Packaging Dotnet global tools {#packaging-dotnet-global-tools}
+
+Dotnet global tools are standard .NET binaries, just made available through a special
+NuGet package. Therefore, they can be built and packaged like every .NET application,
+using `buildDotnetModule`.
+
+If however the source is not available or difficult to build, the
+`buildDotnetGlobalTool` helper can be used, which will package the tool
+straight from its NuGet package.
+
+This helper has the same arguments as `buildDotnetModule`, with a few differences:
+
+* `pname` and `version` are required, and will be used to find the NuGet package of the tool
+* `nugetName` can be used to override the NuGet package name that will be downloaded, if it's different from `pname`
+* `nugetSha256` is the hash of the fetched NuGet package. Set this to `lib.fakeHash256` for the first build, and it will error out, giving you the proper hash. Also remember to update it during version updates (it will not error out if you just change the version while having a fetched package in `/nix/store`)
+* `dotnet-runtime` is set to `dotnet-sdk` by default. When changing this, remember that .NET tools fetched from NuGet require an SDK.
+
+Here is an example of packaging `pbm`, an unfree binary without source available:
+```nix
+{ buildDotnetGlobalTool, lib }:
+
+buildDotnetGlobalTool {
+  pname = "pbm";
+  version = "1.3.1";
+
+  nugetSha256 = "sha256-ZG2HFyKYhVNVYd2kRlkbAjZJq88OADe3yjxmLuxXDUo=";
+
+  meta = with lib; {
+    homepage = "https://cmd.petabridge.com/index.html";
+    changelog = "https://cmd.petabridge.com/articles/RELEASE_NOTES.html";
+    license = licenses.unfree;
+    platforms = platforms.linux;
+  };
+}
+```
diff --git a/nixpkgs/doc/languages-frameworks/gnome.section.md b/nixpkgs/doc/languages-frameworks/gnome.section.md
index 897ebd7861fa..5208f1013cbd 100644
--- a/nixpkgs/doc/languages-frameworks/gnome.section.md
+++ b/nixpkgs/doc/languages-frameworks/gnome.section.md
@@ -137,15 +137,15 @@ Most GNOME package offer [`updateScript`](#var-passthru-updateScript), it is the
 
 ## Frequently encountered issues {#ssec-gnome-common-issues}
 
-#### `GLib-GIO-ERROR **: 06:04:50.903: No GSettings schemas are installed on the system` {#ssec-gnome-common-issues-no-schemas}
+### `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 [`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}
+### `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 `wrapGAppsHook` 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 `wrapGAppsHook` automatic wrapping with `dontWrapGApps = true;` and pass the arguments it intended to pass to makeWrapper to another.
 
@@ -193,7 +193,7 @@ mkDerivation {
 }
 ```
 
-#### I am packaging a project that cannot be wrapped, like a library or GNOME Shell extension. {#ssec-gnome-common-issues-unwrappable-package}
+### I am packaging a project that cannot be wrapped, like a library or GNOME Shell extension. {#ssec-gnome-common-issues-unwrappable-package}
 
 You can rely on applications depending on the library setting the necessary environment variables but that is often easy to miss. Instead we recommend to patch the paths in the source code whenever possible. Here are some examples:
 
@@ -209,6 +209,6 @@ You can rely on applications depending on the library setting the necessary envi
 
   []{#ssec-gnome-common-issues-unwrappable-package-gsettings-c} [Hard-coding GSettings schema path in C library](https://github.com/NixOS/nixpkgs/blob/29c120c065d03b000224872251bed93932d42412/pkgs/development/libraries/glib-networking/default.nix#L31-L34) – nothing special other than using [Coccinelle patch](https://github.com/NixOS/nixpkgs/pull/67957#issuecomment-527717467) to generate the patch itself.
 
-#### I need to wrap a binary outside `bin` and `libexec` directories. {#ssec-gnome-common-issues-weird-location}
+### I need to wrap a binary outside `bin` and `libexec` directories. {#ssec-gnome-common-issues-weird-location}
 
 You can manually trigger the wrapping with `wrapGApp` in `preFixup` phase. It takes a path to a program as a first argument; the remaining arguments are passed directly to [`wrapProgram`](#fun-wrapProgram) function.
diff --git a/nixpkgs/doc/languages-frameworks/go.section.md b/nixpkgs/doc/languages-frameworks/go.section.md
index cf1808414234..7fd38a7d21c5 100644
--- a/nixpkgs/doc/languages-frameworks/go.section.md
+++ b/nixpkgs/doc/languages-frameworks/go.section.md
@@ -20,7 +20,7 @@ In the following is an example expression using `buildGoModule`, the following a
 
   To obtain the actual hash, set `vendorHash = lib.fakeSha256;` and run the build ([more details here](#sec-source-hashes)).
 - `proxyVendor`: Fetches (go mod download) and proxies the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build or if any dependency has case-insensitive conflicts which will produce platform-dependent `vendorHash` checksums.
-- `modPostBuild`: Shell commands to run after the build of the go-modules executes `go mod vendor`, and before calculating fixed output derivation's `vendorHash` (or `vendorSha256`). Note that if you change this attribute, you need to update `vendorHash` (or `vendorSha256`) attribute.
+- `modPostBuild`: Shell commands to run after the build of the goModules executes `go mod vendor`, and before calculating fixed output derivation's `vendorHash` (or `vendorSha256`). Note that if you change this attribute, you need to update `vendorHash` (or `vendorSha256`) attribute.
 
 ```nix
 pet = buildGoModule rec {
@@ -115,7 +115,7 @@ done
 
 ## Attributes used by the builders {#ssec-go-common-attributes}
 
-Many attributes [controlling the build phase](#variables-controlling-the-build-phase) are respected by both `buildGoModule` and `buildGoPackage`. Note that `buildGoModule` reads the following attributes also when building the `vendor/` go-modules fixed output derivation as well:
+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:
 
 - [`sourceRoot`](#var-stdenv-sourceRoot)
 - [`prePatch`](#var-stdenv-prePatch)
diff --git a/nixpkgs/doc/languages-frameworks/haskell.section.md b/nixpkgs/doc/languages-frameworks/haskell.section.md
index 87da2e63663a..60972331840a 100644
--- a/nixpkgs/doc/languages-frameworks/haskell.section.md
+++ b/nixpkgs/doc/languages-frameworks/haskell.section.md
@@ -23,7 +23,7 @@ installing and using them.
 
 All of these packages are originally defined in the `haskellPackages` package
 set and are re-exposed with a reduced dependency closure for convenience.
-(see `justStaticExecutables` below)
+(see `justStaticExecutables` or `separateBinOutput` below)
 
 The `haskellPackages` set includes at least one version of every package from
 Hackage as well as some manually injected packages. This amounts to a lot of
@@ -45,16 +45,17 @@ The attribute names in `haskellPackages` always correspond with their name on
 Hackage. Since Hackage allows names that are not valid Nix without escaping,
 you need to take care when handling attribute names like `3dmodels`.
 
-For packages that are part of [Stackage], we use the version prescribed by a
-Stackage solver (usually the current LTS one) as the default version. For all
-other packages we use the latest version from Hackage. See
-[below](#haskell-available-versions) to learn which versions are provided
-exactly.
+For packages that are part of [Stackage] (a curated set of known to be
+compatible packages), we use the version prescribed by a Stackage snapshot
+(usually the current LTS one) as the default version. For all other packages we
+use the latest version from [Hackage](https://hackage.org) (the repository of
+basically all open source Haskell packages). See [below](#haskell-available-
+versions) for a few more details on this.
 
-Roughly half of the 16K packages contained in `haskellPackages` don't actually
-build and are marked as broken semi-automatically. Most of those packages are
-deprecated or unmaintained, but sometimes packages that should build, do not
-build. Very often fixing them is not a lot of work.
+Roughly half of the 16K packages contained in `haskellPackages` don’t actually
+build and are [marked as broken semi-automatically](https://github.com/NixOS/nixpkgs/blob/haskell-updates/pkgs/development/haskell-modules/configuration-hackage2nix/broken.yaml).
+Most of those packages are deprecated or unmaintained, but sometimes packages
+that should build, do not build. Very often fixing them is not a lot of work.
 
 <!--
 TODO(@sternenseemann):
@@ -126,19 +127,23 @@ Every package set also re-exposes the GHC used to build its packages as `haskell
 ### Available package versions {#haskell-available-versions}
 
 We aim for a “blessed” package set which only contains one version of each
-package, like Stackage (and based on it) but with more packages. Normally in
-nixpkgs the number of building Haskell packages is roughly two to three times
-the size of Stackage. For choosing the version to use for a certain package we
-use the following rules:
-
-1. By default, for every package `haskellPackages.foo` is the newest version
-found on Hackage (at the time of the last update of our package set).
-2. If the Stackage snapshot that we use (usually the newest LTS snapshot)
-contains a package, we use the Stackage version as default version for that
-package.
-3. For some packages, which are not on Stackage, we have manual overrides to
-set the default version to a version older than the newest on Hackage. We do
-this to get them or their reverse dependencies to compile in our package set.
+package, like [Stackage], which is a curated set of known to be compatible
+packages. We use the version information from Stackage snapshots and extend it
+with more packages. Normally in Nixpkgs the number of building Haskell packages
+is roughly two to three times the size of Stackage. For choosing the version to
+use for a certain package we use the following rules:
+
+1. By default, for `haskellPackages.foo` is the newest version of the package
+`foo` found on [Hackage](https://hackage.org), which is the central registry
+of all open source Haskell packages. Nixpkgs contains a reference to a pinned
+Hackage snapshot, thus we use the state of Hackage as of the last time we
+updated this pin.
+2. If the [Stackage] snapshot that we use (usually the newest LTS snapshot)
+contains a package, [we use instead the version in the Stackage snapshot as
+default version for that package.](https://github.com/NixOS/nixpkgs/blob/haskell-updates/pkgs/development/haskell-modules/configuration-hackage2nix/stackage.yaml)
+3. For some packages, which are not on Stackage, we have if necessary [manual
+overrides to set the default version to a version older than the newest on
+Hackage.](https://github.com/NixOS/nixpkgs/blob/haskell-updates/pkgs/development/haskell-modules/configuration-hackage2nix/main.yaml)
 4. For all packages, for which the newest Hackage version is not the default
 version, there will also be a `haskellPackages.foo_x_y_z` package with the
 newest version. The `x_y_z` part encodes the version with dots replaced by
@@ -146,9 +151,12 @@ underscores. When the newest version changes by a new release to Hackage the
 old package will disappear under that name and be replaced by a newer one under
 the name with the new version. The package name including the version will
 also disappear when the default version e.g. from Stackage catches up with the
-newest version from Hackage.
-5. For some packages, we also manually add other `haskellPackages.foo_x_y_z`
-versions, if they are required for a certain build.
+newest version from Hackage. E.g. if `haskellPackages.foo` gets updated from
+1.0.0 to 1.1.0 the package `haskellPackages.foo_1_1_0` becomes obsolete and
+gets dropped.
+5. For some packages, we also [manually add other `haskellPackages.foo_x_y_z`
+versions](https://github.com/NixOS/nixpkgs/blob/haskell-updates/pkgs/development/haskell-modules/configuration-hackage2nix/main.yaml),
+if they are required for a certain build.
 
 Relying on `haskellPackages.foo_x_y_z` attributes in derivations outside
 nixpkgs is discouraged because they may change or disappear with every package
@@ -1066,6 +1074,18 @@ benchmark component.
 `dontCoverage drv`
 : Sets the `doCoverage` argument to `false` for `drv`.
 
+`enableExecutableProfiling drv`
+: Sets the `enableExecutableProfiling` argument to `true` for `drv`.
+
+`disableExecutableProfiling drv`
+: Sets the `enableExecutableProfiling` argument to `false` for `drv`.
+
+`enableLibraryProfiling drv`
+: Sets the `enableLibraryProfiling` argument to `true` for `drv`.
+
+`disableLibraryProfiling drv`
+: Sets the `enableLibraryProfiling` argument to `false` for `drv`.
+
 #### Library functions in the Haskell package sets {#haskell-package-set-lib-functions}
 
 Some library functions depend on packages from the Haskell package sets. Thus they are
@@ -1140,6 +1160,124 @@ covered in the old [haskell4nix docs](https://haskell4nix.readthedocs.io/).
 If you feel any important topic is not documented at all, feel free to comment
 on the issue linked above.
 
+### How to enable or disable profiling builds globally? {#haskell-faq-override-profiling}
+
+By default, Nixpkgs builds a profiling version of each Haskell library. The
+exception to this rule are some platforms where it is disabled due to concerns
+over output size. You may want to…
+
+* …enable profiling globally so that you can build a project you are working on
+  with profiling ability giving you insight in the time spent across your code
+  and code you depend on using [GHC's profiling feature][profiling].
+
+* …disable profiling (globally) to reduce the time spent building the profiling
+  versions of libraries which a significant amount of build time is spent on
+  (although they are not as expensive as the “normal” build of a Haskell library).
+
+::: {.note}
+The method described below affects the build of all libraries in the
+respective Haskell package set as well as GHC. If your choices differ from
+Nixpkgs' default for your (host) platform, you will lose the ability to
+substitute from the official binary cache.
+
+If you are concerned about build times and thus want to disable profiling, it
+probably makes sense to use `haskell.lib.compose.disableLibraryProfiling` (see
+[](#haskell-trivial-helpers)) on the packages you are building locally while
+continuing to substitute their dependencies and GHC.
+:::
+
+Since we need to change the profiling settings for the desired Haskell package
+set _and_ GHC (as the core libraries like `base`, `filepath` etc. are bundled
+with GHC), it is recommended to use overlays for Nixpkgs to change them.
+Since the interrelated parts, i.e. the package set and GHC, are connected
+via the Nixpkgs fixpoint, we need to modify them both in a way that preserves
+their connection (or else we'd have to wire it up again manually). This is
+achieved by changing GHC and the package set in seperate overlays to prevent
+the package set from pulling in GHC from `prev`.
+
+The result is two overlays like the ones shown below. Adjustable parts are
+annotated with comments, as are any optional or alternative ways to achieve
+the desired profiling settings without causing too many rebuilds.
+
+<!-- TODO(@sternenseemann): buildHaskellPackages != haskellPackages with this overlay,
+affected by https://github.com/NixOS/nixpkgs/issues/235960 which needs to be fixed
+properly still.
+-->
+
+```nix
+let
+  # Name of the compiler and package set you want to change. If you are using
+  # the default package set `haskellPackages`, you need to look up what version
+  # of GHC it currently uses (note that this is subject to change).
+  ghcName = "ghc92";
+  # Desired new setting
+  enableProfiling = true;
+in
+
+[
+  # The first overlay modifies the GHC derivation so that it does or does not
+  # build profiling versions of the core libraries bundled with it. It is
+  # recommended to only use such an overlay if you are enabling profiling on a
+  # platform that doesn't by default, because compiling GHC from scratch is
+  # quite expensive.
+  (final: prev:
+  let
+    inherit (final) lib;
+  in
+
+  {
+    haskell = lib.recursiveUpdate prev.haskell {
+      compiler.${ghcName} = prev.haskell.compiler.${ghcName}.override {
+        # Unfortunately, the GHC setting is named differently for historical reasons
+        enableProfiledLibs = enableProfiling;
+      };
+    };
+  })
+
+  (final: prev:
+  let
+    inherit (final) lib;
+    haskellLib = final.haskell.lib.compose;
+  in
+
+  {
+    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;
+          });
+
+          # …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;
+        };
+      };
+    };
+  })
+]
+```
+
+<!-- TODO(@sternenseemann): write overriding mkDerivation, overriding GHC, and
+overriding the entire package set sections and link to them from here where
+relevant.
+-->
+
 [Stackage]: https://www.stackage.org
 [cabal-project-files]: https://cabal.readthedocs.io/en/latest/cabal-project.html
 [cabal2nix]: https://github.com/nixos/cabal2nix
diff --git a/nixpkgs/doc/languages-frameworks/index.md b/nixpkgs/doc/languages-frameworks/index.md
new file mode 100644
index 000000000000..cdbf08f1791b
--- /dev/null
+++ b/nixpkgs/doc/languages-frameworks/index.md
@@ -0,0 +1,45 @@
+# Languages and frameworks {#chap-language-support}
+
+The [standard build environment](#chap-stdenv) makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accommodated by overriding the appropriate phases of `stdenv`. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
+
+```{=include=} sections
+agda.section.md
+android.section.md
+beam.section.md
+bower.section.md
+chicken.section.md
+coq.section.md
+crystal.section.md
+cuda.section.md
+cuelang.section.md
+dart.section.md
+dhall.section.md
+dotnet.section.md
+emscripten.section.md
+gnome.section.md
+go.section.md
+haskell.section.md
+hy.section.md
+idris.section.md
+ios.section.md
+java.section.md
+javascript.section.md
+lisp.section.md
+lua.section.md
+maven.section.md
+nim.section.md
+ocaml.section.md
+octave.section.md
+perl.section.md
+php.section.md
+pkg-config.section.md
+python.section.md
+qt.section.md
+r.section.md
+ruby.section.md
+rust.section.md
+swift.section.md
+texlive.section.md
+titanium.section.md
+vim.section.md
+```
diff --git a/nixpkgs/doc/languages-frameworks/index.xml b/nixpkgs/doc/languages-frameworks/index.xml
deleted file mode 100644
index 94c4e303027f..000000000000
--- a/nixpkgs/doc/languages-frameworks/index.xml
+++ /dev/null
@@ -1,47 +0,0 @@
-<chapter xmlns="http://docbook.org/ns/docbook"
-         xmlns:xi="http://www.w3.org/2001/XInclude"
-         xml:id="chap-language-support">
- <title>Languages and frameworks</title>
- <para>
-  The <link linkend="chap-stdenv">standard build environment</link> makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accommodated by overriding the appropriate phases of <literal>stdenv</literal>. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
- </para>
- <xi:include href="agda.section.xml" />
- <xi:include href="android.section.xml" />
- <xi:include href="beam.section.xml" />
- <xi:include href="bower.section.xml" />
- <xi:include href="chicken.section.xml" />
- <xi:include href="coq.section.xml" />
- <xi:include href="crystal.section.xml" />
- <xi:include href="cuda.section.xml" />
- <xi:include href="cuelang.section.xml" />
- <xi:include href="dart.section.xml" />
- <xi:include href="dhall.section.xml" />
- <xi:include href="dotnet.section.xml" />
- <xi:include href="emscripten.section.xml" />
- <xi:include href="gnome.section.xml" />
- <xi:include href="go.section.xml" />
- <xi:include href="haskell.section.xml" />
- <xi:include href="hy.section.xml" />
- <xi:include href="idris.section.xml" />
- <xi:include href="ios.section.xml" />
- <xi:include href="java.section.xml" />
- <xi:include href="javascript.section.xml" />
- <xi:include href="lisp.section.xml" />
- <xi:include href="lua.section.xml" />
- <xi:include href="maven.section.xml" />
- <xi:include href="nim.section.xml" />
- <xi:include href="ocaml.section.xml" />
- <xi:include href="octave.section.xml" />
- <xi:include href="perl.section.xml" />
- <xi:include href="php.section.xml" />
- <xi:include href="pkg-config.section.xml" />
- <xi:include href="python.section.xml" />
- <xi:include href="qt.section.xml" />
- <xi:include href="r.section.xml" />
- <xi:include href="ruby.section.xml" />
- <xi:include href="rust.section.xml" />
- <xi:include href="swift.section.xml" />
- <xi:include href="texlive.section.xml" />
- <xi:include href="titanium.section.xml" />
- <xi:include href="vim.section.xml" />
-</chapter>
diff --git a/nixpkgs/doc/languages-frameworks/javascript.section.md b/nixpkgs/doc/languages-frameworks/javascript.section.md
index a6c5aad15c15..0a2099b0a6b1 100644
--- a/nixpkgs/doc/languages-frameworks/javascript.section.md
+++ b/nixpkgs/doc/languages-frameworks/javascript.section.md
@@ -196,10 +196,14 @@ buildNpmPackage rec {
 * `npmDepsHash`: The output hash of the dependencies for this project. Can be calculated in advance with [`prefetch-npm-deps`](#javascript-buildNpmPackage-prefetch-npm-deps).
 * `makeCacheWritable`: Whether to make the cache writable prior to installing dependencies. Don't set this unless npm tries to write to the cache directory, as it can slow down the build.
 * `npmBuildScript`: The script to run to build the project. Defaults to `"build"`.
+* `npmWorkspace`: The workspace directory within the project to build and install.
+* `dontNpmBuild`: Option to disable running the build script. Set to `true` if the package does not have a build script. Defaults to `false`. Alternatively, setting `buildPhase` explicitly also disables this.
+* `dontNpmInstall`: Option to disable running `npm install`. Defaults to `false`. Alternatively, setting `installPhase` explicitly also disables this.
 * `npmFlags`: Flags to pass to all npm commands.
-* `npmInstallFlags`: Flags to pass to `npm ci` and `npm prune`.
+* `npmInstallFlags`: Flags to pass to `npm ci`.
 * `npmBuildFlags`: Flags to pass to `npm run ${npmBuildScript}`.
 * `npmPackFlags`: Flags to pass to `npm pack`.
+* `npmPruneFlags`: Flags to pass to `npm prune`. Defaults to the value of `npmInstallFlags`.
 
 #### prefetch-npm-deps {#javascript-buildNpmPackage-prefetch-npm-deps}
 
diff --git a/nixpkgs/doc/languages-frameworks/lua.section.md b/nixpkgs/doc/languages-frameworks/lua.section.md
index 2ed02ab9d6c7..c5049326a776 100644
--- a/nixpkgs/doc/languages-frameworks/lua.section.md
+++ b/nixpkgs/doc/languages-frameworks/lua.section.md
@@ -179,7 +179,7 @@ Each interpreter has the following attributes:
 
 #### `buildLuarocksPackage` function {#buildluarockspackage-function}
 
-The `buildLuarocksPackage` function is implemented in `pkgs/development/interpreters/lua-5/build-lua-package.nix`
+The `buildLuarocksPackage` function is implemented in `pkgs/development/interpreters/lua-5/build-luarocks-package.nix`
 The following is an example:
 ```nix
 luaposix = buildLuarocksPackage {
diff --git a/nixpkgs/doc/languages-frameworks/maven.section.md b/nixpkgs/doc/languages-frameworks/maven.section.md
index cc5b4e3ed799..7e287a097c7e 100644
--- a/nixpkgs/doc/languages-frameworks/maven.section.md
+++ b/nixpkgs/doc/languages-frameworks/maven.section.md
@@ -4,6 +4,87 @@ Maven is a well-known build tool for the Java ecosystem however it has some chal
 
 The following provides a list of common patterns with how to package a Maven project (or any JVM language that can export to Maven) as a Nix package.
 
+## Building a package using `maven.buildMavenPackage` {#maven-buildmavenpackage}
+
+Consider the following package:
+
+```nix
+{ lib, fetchFromGitHub, jre, makeWrapper, maven }:
+
+maven.buildMavenPackage rec {
+  pname = "jd-cli";
+  version = "1.2.1";
+
+  src = fetchFromGitHub {
+    owner = "intoolswetrust";
+    repo = pname;
+    rev = "${pname}-${version}";
+    hash = "sha256-rRttA5H0A0c44loBzbKH7Waoted3IsOgxGCD2VM0U/Q=";
+  };
+
+  mvnHash = "sha256-kLpjMj05uC94/5vGMwMlFzLKNFOKeyNvq/vmB6pHTAo=";
+
+  nativeBuildInputs = [ makeWrapper ];
+
+  installPhase = ''
+    mkdir -p $out/bin $out/share/jd-cli
+    install -Dm644 jd-cli/target/jd-cli.jar $out/share/jd-cli
+
+    makeWrapper ${jre}/bin/java $out/bin/jd-cli \
+      --add-flags "-jar $out/share/jd-cli/jd-cli.jar"
+  '';
+
+  meta = with lib; {
+    description = "Simple command line wrapper around JD Core Java Decompiler project";
+    homepage = "https://github.com/intoolswetrust/jd-cli";
+    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.
+
+::: {.tip}
+After setting `maven.buildMavenPackage`, we then do standard Java `.jar` installation by saving the `.jar` to `$out/share/java` and then making a wrapper which allows executing that file; see [](#sec-language-java) for additional generic information about packaging Java applications.
+:::
+
+### Stable Maven plugins {#stable-maven-plugins}
+
+Maven defines default versions for its core plugins, e.g. `maven-compiler-plugin`. If your project does not override these versions, an upgrade of Maven will change the version of the used plugins, and therefore the derivation and hash.
+
+When `maven` is upgraded, `mvnHash` for the derivation must be updated as well: otherwise, the project will simply be built on the derivation of old plugins, and fail because the requested plugins are missing.
+
+This clearly prevents automatic upgrades of Maven: a manual effort must be made throughout nixpkgs by any maintainer wishing to push the upgrades.
+
+To make sure that your package does not add extra manual effort when upgrading Maven, explicitly define versions for all plugins. You can check if this is the case by adding the following plugin to your (parent) POM:
+
+```xml
+<plugin>
+  <groupId>org.apache.maven.plugins</groupId>
+  <artifactId>maven-enforcer-plugin</artifactId>
+  <version>3.3.0</version>
+  <executions>
+    <execution>
+      <id>enforce-plugin-versions</id>
+      <goals>
+        <goal>enforce</goal>
+      </goals>
+      <configuration>
+        <rules>
+          <requirePluginVersions />
+        </rules>
+      </configuration>
+    </execution>
+  </executions>
+</plugin>
+```
+
+## Manually using `mvn2nix` {#maven-mvn2nix}
+::: {.warning}
+This way is no longer recommended; see [](#maven-buildmavenpackage) for the simpler and preferred way.
+:::
+
 For the purposes of this example let's consider a very basic Maven project with the following `pom.xml` with a single dependency on [emoji-java](https://github.com/vdurmont/emoji-java).
 
 ```xml
@@ -41,14 +122,11 @@ public class Main {
 }
 ```
 
-You find this demo project at https://github.com/fzakaria/nixos-maven-example
-
-## Solving for dependencies {#solving-for-dependencies}
+You find this demo project at [https://github.com/fzakaria/nixos-maven-example](https://github.com/fzakaria/nixos-maven-example).
 
-### buildMaven with NixOS/mvn2nix-maven-plugin {#buildmaven-with-nixosmvn2nix-maven-plugin}
-
-> ⚠️ Although `buildMaven` is the "blessed" way within nixpkgs, as of 2020, it hasn't seen much activity in quite a while.
+### Solving for dependencies {#solving-for-dependencies}
 
+#### buildMaven with NixOS/mvn2nix-maven-plugin {#buildmaven-with-nixosmvn2nix-maven-plugin}
 `buildMaven` is an alternative method that tries to follow similar patterns of other programming languages by generating a lock file. It relies on the maven plugin [mvn2nix-maven-plugin](https://github.com/NixOS/mvn2nix-maven-plugin).
 
 First you generate a `project-info.json` file using the maven plugin.
@@ -105,9 +183,10 @@ The benefit over the _double invocation_ as we will see below, is that the _/nix
 │           ├── avalon-framework-4.1.3.jar -> /nix/store/iv5fp3955w3nq28ff9xfz86wvxbiw6n9-avalon-framework-4.1.3.jar
 ```
 
-### Double Invocation {#double-invocation}
-
-> ⚠️ This pattern is the simplest but may cause unnecessary rebuilds due to the output hash changing.
+#### Double Invocation {#double-invocation}
+::: {.note}
+This pattern is the simplest but may cause unnecessary rebuilds due to the output hash changing.
+:::
 
 The double invocation is a _simple_ way to get around the problem that `nix-build` may be sandboxed and have no Internet connectivity.
 
@@ -115,7 +194,9 @@ It treats the entire Maven repository as a single source to be downloaded, relyi
 
 The first step will be to build the Maven project as a fixed-output derivation in order to collect the Maven repository -- below is an [example](https://github.com/fzakaria/nixos-maven-example/blob/main/double-invocation-repository.nix).
 
-> Traditionally the Maven repository is at `~/.m2/repository`. We will override this to be the `$out` directory.
+::: {.note}
+Traditionally the Maven repository is at `~/.m2/repository`. We will override this to be the `$out` directory.
+:::
 
 ```nix
 { lib, stdenv, maven }:
@@ -147,7 +228,9 @@ stdenv.mkDerivation {
 
 The build will fail, and tell you the expected `outputHash` to place. When you've set the hash, the build will return with a `/nix/store` entry whose contents are the full Maven repository.
 
-> Some additional files are deleted that would cause the output hash to change potentially on subsequent runs.
+::: {.warning}
+Some additional files are deleted that would cause the output hash to change potentially on subsequent runs.
+:::
 
 ```bash
 ❯ tree $(nix-build --no-out-link double-invocation-repository.nix) | head
@@ -165,7 +248,7 @@ The build will fail, and tell you the expected `outputHash` to place. When you'v
 
 If your package uses _SNAPSHOT_ dependencies or _version ranges_; there is a strong likelihood that over-time your output hash will change since the resolved dependencies may change. Hence this method is less recommended then using `buildMaven`.
 
-## Building a JAR {#building-a-jar}
+### Building a JAR {#building-a-jar}
 
 Regardless of which strategy is chosen above, the step to build the derivation is the same.
 
@@ -191,7 +274,9 @@ in stdenv.mkDerivation rec {
 }
 ```
 
-> We place the library in `$out/share/java` since JDK package has a _stdenv setup hook_ that adds any JARs in the `share/java` directories of the build inputs to the CLASSPATH environment.
+::: {.tip}
+We place the library in `$out/share/java` since JDK package has a _stdenv setup hook_ that adds any JARs in the `share/java` directories of the build inputs to the CLASSPATH environment.
+:::
 
 ```bash
 ❯ tree $(nix-build --no-out-link build-jar.nix)
@@ -203,7 +288,7 @@ in stdenv.mkDerivation rec {
 2 directories, 1 file
 ```
 
-## Runnable JAR {#runnable-jar}
+### Runnable JAR {#runnable-jar}
 
 The previous example builds a `jar` file but that's not a file one can run.
 
@@ -215,9 +300,9 @@ We will use the same repository we built above (either _double invocation_ or _b
 
 The following two methods are more suited to Nix then building an [UberJar](https://imagej.net/Uber-JAR) which may be the more traditional approach.
 
-### CLASSPATH {#classpath}
+#### CLASSPATH {#classpath}
 
-> This is ideal if you are providing a derivation for _nixpkgs_ and don't want to patch the project's `pom.xml`.
+This method is ideal if you are providing a derivation for _nixpkgs_ and don't want to patch the project's `pom.xml`.
 
 We will read the Maven repository and flatten it to a single list. This list will then be concatenated with the _CLASSPATH_ separator to create the full classpath.
 
@@ -255,9 +340,9 @@ in stdenv.mkDerivation rec {
 }
 ```
 
-### MANIFEST file via Maven Plugin {#manifest-file-via-maven-plugin}
+#### MANIFEST file via Maven Plugin {#manifest-file-via-maven-plugin}
 
-> This is ideal if you are the project owner and want to change your `pom.xml` to set the CLASSPATH within it.
+This method is ideal if you are the project owner and want to change your `pom.xml` to set the CLASSPATH within it.
 
 Augment the `pom.xml` to create a JAR with the following manifest:
 
@@ -333,8 +418,9 @@ in stdenv.mkDerivation rec {
   '';
 }
 ```
-
-> Our script produces a dependency on `jre` rather than `jdk` to restrict the runtime closure necessary to run the application.
+::: {.note}
+Our script produces a dependency on `jre` rather than `jdk` to restrict the runtime closure necessary to run the application.
+:::
 
 This will give you an executable shell-script that launches your JAR with all the dependencies available.
 
diff --git a/nixpkgs/doc/languages-frameworks/nim.section.md b/nixpkgs/doc/languages-frameworks/nim.section.md
index 4f97c7585f33..6b0fb3df0311 100644
--- a/nixpkgs/doc/languages-frameworks/nim.section.md
+++ b/nixpkgs/doc/languages-frameworks/nim.section.md
@@ -15,32 +15,23 @@ case of packages not containing exported library code the attribute
 The following example shows a Nim program that depends only on Nim libraries:
 
 ```nix
-{ lib, nimPackages, fetchurl }:
-
-nimPackages.buildNimPackage rec {
-  pname = "hottext";
-  version = "1.4";
+{ lib, nimPackages, fetchFromGitHub }:
 
+nimPackages.buildNimPackage (finalAttrs: {
+  pname = "ttop";
+  version = "1.0.1";
   nimBinOnly = true;
 
-  src = fetchurl {
-    url = "https://git.sr.ht/~ehmry/hottext/archive/v${version}.tar.gz";
-    hash = "sha256-hIUofi81zowSMbt1lUsxCnVzfJGN3FEiTtN8CEFpwzY=";
+  src = fetchFromGitHub {
+    owner = "inv2004";
+    repo = "ttop";
+    rev = "v${finalAttrs.version}";
+    hash = "sha256-x4Uczksh6p3XX/IMrOFtBxIleVHdAPX9e8n32VAUTC4=";
   };
 
-  buildInputs = with nimPackages; [
-    bumpy
-    chroma
-    flatty
-    nimsimd
-    pixie
-    sdl2
-    typography
-    vmath
-    zippy
-  ];
-}
+  buildInputs = with nimPackages; [ asciigraph illwill parsetoml zippy ];
 
+})
 ```
 
 ## Nim library packages in Nixpkgs {#nim-library-packages-in-nixpkgs}
@@ -60,15 +51,15 @@ non-Nim package:
 ```nix
 { lib, buildNimPackage, fetchNimble, SDL2 }:
 
-buildNimPackage rec {
+buildNimPackage (finalAttrs: {
   pname = "sdl2";
   version = "2.0.4";
   src = fetchNimble {
-    inherit pname version;
-    hash = "sha256-qDtVSnf+7rTq36WAxgsUZ8XoUk4sKwHyt8EJcY5WP+o=";
+    inherit (finalAttrs) pname version;
+    hash = "sha256-Vtcj8goI4zZPQs2TbFoBFlcR5UqDtOldaXSH/+/xULk=";
   };
   propagatedBuildInputs = [ SDL2 ];
-}
+})
 ```
 
 ## `buildNimPackage` parameters {#buildnimpackage-parameters}
diff --git a/nixpkgs/doc/languages-frameworks/php.section.md b/nixpkgs/doc/languages-frameworks/php.section.md
index 8600e49d4570..6c4315f5c487 100644
--- a/nixpkgs/doc/languages-frameworks/php.section.md
+++ b/nixpkgs/doc/languages-frameworks/php.section.md
@@ -22,7 +22,7 @@ NixOS - not necessarily the latest major release from upstream.
 
 All available PHP attributes are wrappers around their respective
 binary PHP package and provide commonly used extensions this way. The
-real PHP 7.4 package, i.e. the unwrapped one, is available as
+real PHP 8.1 package, i.e. the unwrapped one, is available as
 `php81.unwrapped`; see the next section for more details.
 
 Interactive tools built on PHP are put in `php.packages`; composer is
diff --git a/nixpkgs/doc/languages-frameworks/python.section.md b/nixpkgs/doc/languages-frameworks/python.section.md
index 10f5e3938ce4..947ce6028659 100644
--- a/nixpkgs/doc/languages-frameworks/python.section.md
+++ b/nixpkgs/doc/languages-frameworks/python.section.md
@@ -512,9 +512,10 @@ when building the bindings and are therefore added as `buildInputs`.
 
 ```nix
 { lib
-, pkgs
 , buildPythonPackage
 , fetchPypi
+, libxml2
+, libxslt
 }:
 
 buildPythonPackage rec {
@@ -528,8 +529,8 @@ buildPythonPackage rec {
   };
 
   buildInputs = [
-    pkgs.libxml2
-    pkgs.libxslt
+    libxml2
+    libxslt
   ];
 
   meta = with lib; {
@@ -554,11 +555,13 @@ therefore we have to set `LDFLAGS` and `CFLAGS`.
 
 ```nix
 { lib
-, pkgs
 , buildPythonPackage
 , fetchPypi
 
 # dependencies
+, fftw
+, fftwFloat
+, fftwLongDouble
 , numpy
 , scipy
 }:
@@ -574,9 +577,9 @@ buildPythonPackage rec {
   };
 
   buildInputs = [
-    pkgs.fftw
-    pkgs.fftwFloat
-    pkgs.fftwLongDouble
+    fftw
+    fftwFloat
+    fftwLongDouble
   ];
 
   propagatedBuildInputs = [
@@ -585,8 +588,8 @@ buildPythonPackage rec {
   ];
 
   preConfigure = ''
-    export LDFLAGS="-L${pkgs.fftw.dev}/lib -L${pkgs.fftwFloat.out}/lib -L${pkgs.fftwLongDouble.out}/lib"
-    export CFLAGS="-I${pkgs.fftw.dev}/include -I${pkgs.fftwFloat.dev}/include -I${pkgs.fftwLongDouble.dev}/include"
+    export LDFLAGS="-L${fftw.dev}/lib -L${fftwFloat.out}/lib -L${fftwLongDouble.out}/lib"
+    export CFLAGS="-I${fftw.dev}/include -I${fftwFloat.dev}/include -I${fftwLongDouble.dev}/include"
   '';
 
   # Tests cannot import pyfftw. pyfftw works fine though.
@@ -995,7 +998,7 @@ and in this case the `python3` interpreter is automatically used.
 ### Interpreters {#interpreters}
 
 Versions 2.7, 3.8, 3.9, 3.10 and 3.11 of the CPython interpreter are available
-as respectively `python27`, python38`, `python39`, `python310` and `python311`.
+as respectively `python27`, `python38`, `python39`, `python310` and `python311`.
 The aliases `python2` and `python3` correspond to respectively `python27` and
 `python310`. The attribute `python` maps to `python2`. The PyPy interpreters
 compatible with Python 2.7 and 3 are available as `pypy27` and `pypy3`, with
@@ -1511,11 +1514,11 @@ Note: There is a boolean value `lib.inNixShell` set to `true` if nix-shell is in
 
 ### Tools {#tools}
 
-Packages inside nixpkgs are written by hand. However many tools exist in
-community to help save time. No tool is preferred at the moment.
+Packages inside nixpkgs must use the `buildPythonPackage` or `buildPythonApplication` function directly,
+because we can only provide security support for non-vendored dependencies.
 
-- [nixpkgs-pytools](https://github.com/nix-community/nixpkgs-pytools)
-- [poetry2nix](https://github.com/nix-community/poetry2nix)
+We recommend [nix-init](https://github.com/nix-community/nix-init) for creating new python packages within nixpkgs,
+as it already prefetches the source, parses dependencies for common formats and prefills most things in `meta`.
 
 ### Deterministic builds {#deterministic-builds}
 
diff --git a/nixpkgs/doc/languages-frameworks/qt.section.md b/nixpkgs/doc/languages-frameworks/qt.section.md
index e09194e391e1..2300c5f60ede 100644
--- a/nixpkgs/doc/languages-frameworks/qt.section.md
+++ b/nixpkgs/doc/languages-frameworks/qt.section.md
@@ -10,37 +10,22 @@ 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}
 
-```{=docbook}
-<programlisting>
-{ stdenv, lib, qtbase, wrapQtAppsHook }: <co xml:id='qt-default-nix-co-1' />
+```nix
+{ stdenv, lib, qtbase, wrapQtAppsHook }:
 
 stdenv.mkDerivation {
   pname = "myapp";
   version = "1.0";
 
   buildInputs = [ qtbase ];
-  nativeBuildInputs = [ wrapQtAppsHook ]; <co xml:id='qt-default-nix-co-2' />
+  nativeBuildInputs = [ wrapQtAppsHook ];
 }
-</programlisting>
-
- <calloutlist>
-  <callout arearefs='qt-default-nix-co-1'>
-   <para>
-    Import Qt modules directly, that is: <literal>qtbase</literal>, <literal>qtdeclarative</literal>, etc.
-    <emphasis>Do not</emphasis> import Qt package sets such as <literal>qt5</literal>
-    because the Qt versions of dependencies may not be coherent, causing build and runtime failures.
-   </para>
-  </callout>
-  <callout arearefs='qt-default-nix-co-2'>
-    <para>
-      All Qt packages must include <literal>wrapQtAppsHook</literal> in
-      <literal>nativeBuildInputs</literal>, or you must explicitly set
-      <literal>dontWrapQtApps</literal>.
-    </para>
-  </callout>
- </calloutlist>
 ```
 
+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.
+
+Additionally all Qt packages must include `wrapQtAppsHook` in `nativeBuildInputs`, or you must explicitly set `dontWrapQtApps`.
+
 ## Locating runtime dependencies {#qt-runtime-dependencies}
 
 Qt applications must be wrapped to find runtime dependencies.
diff --git a/nixpkgs/doc/languages-frameworks/rust.section.md b/nixpkgs/doc/languages-frameworks/rust.section.md
index 7d46bdbd4d48..08738026447a 100644
--- a/nixpkgs/doc/languages-frameworks/rust.section.md
+++ b/nixpkgs/doc/languages-frameworks/rust.section.md
@@ -39,7 +39,7 @@ rustPlatform.buildRustPackage rec {
     description = "A fast line-oriented regex search tool, similar to ag and ack";
     homepage = "https://github.com/BurntSushi/ripgrep";
     license = licenses.unlicense;
-    maintainers = [ maintainers.tailhook ];
+    maintainers = [];
   };
 }
 ```
@@ -558,7 +558,7 @@ buildPythonPackage rec {
     hash = "sha256-miW//pnOmww2i6SOGbkrAIdc/JMDT4FJLqdMFojZeoY=";
   };
 
-  sourceRoot = "source/bindings/python";
+  sourceRoot = "${src.name}/bindings/python";
 
   nativeBuildInputs = [
     cargo
@@ -926,7 +926,7 @@ rustPlatform.buildRustPackage rec {
     description = "A fast line-oriented regex search tool, similar to ag and ack";
     homepage = "https://github.com/BurntSushi/ripgrep";
     license = with licenses; [ mit unlicense ];
-    maintainers = with maintainers; [ tailhook ];
+    maintainers = with maintainers; [];
   };
 }
 ```
diff --git a/nixpkgs/doc/languages-frameworks/texlive.section.md b/nixpkgs/doc/languages-frameworks/texlive.section.md
index 72ab14126bed..a4c81daa54bb 100644
--- a/nixpkgs/doc/languages-frameworks/texlive.section.md
+++ b/nixpkgs/doc/languages-frameworks/texlive.section.md
@@ -22,7 +22,7 @@ Since release 15.09 there is a new TeX Live packaging that lives entirely under
   texlive.combine {
     # inherit (texlive) whatever-you-want;
     pkgFilter = pkg:
-      pkg.tlType == "run" || pkg.tlType == "bin" || pkg.pname == "cm-super";
+      pkg.tlType == "run" || pkg.tlType == "bin" || pkg.hasManpages || pkg.pname == "cm-super";
     # elem tlType [ "run" "bin" "doc" "source" ]
     # there are also other attributes: version, name
   }