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

Conflicts:
	nixpkgs/pkgs/build-support/rust/build-rust-package/default.nix

8 files changed, 227 insertions, 29 deletions

diff --git a/nixpkgs/doc/languages-frameworks/dart.section.md b/nixpkgs/doc/languages-frameworks/dart.section.md
index 9af02ef143b6..fca87fa70e4e 100644
--- a/nixpkgs/doc/languages-frameworks/dart.section.md
+++ b/nixpkgs/doc/languages-frameworks/dart.section.md
@@ -11,6 +11,18 @@ If you are packaging a Flutter desktop application, use [`buildFlutterApplicatio
 `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.
 
+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.
+
+::: {.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 `dart` commands run can be overridden through `pubGetScript` and `dartCompileCommand`, you can also add flags using `dartCompileFlags` or `dartJitFlags`.
@@ -101,8 +113,8 @@ flutter.buildFlutterApplication {
 
   pubspecLock = lib.importJSON ./pubspec.lock.json;
 }
+```
 
 ### Usage with nix-shell {#ssec-dart-flutter-nix-shell}
 
-See the [Dart documentation](#ssec-dart-applications-nix-shell) nix-shell instructions.
-```
+See the [Dart documentation](#ssec-dart-applications-nix-shell) for nix-shell instructions.
diff --git a/nixpkgs/doc/languages-frameworks/go.section.md b/nixpkgs/doc/languages-frameworks/go.section.md
index 7f069c687ff1..7f151c76129f 100644
--- a/nixpkgs/doc/languages-frameworks/go.section.md
+++ b/nixpkgs/doc/languages-frameworks/go.section.md
@@ -1,26 +1,41 @@
 # Go {#sec-language-go}
 
-## Go modules {#ssec-language-go}
+## Building Go modules with `buildGoModule` {#ssec-language-go}
 
-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:
+The function `buildGoModule` builds Go programs managed with Go modules. It builds [Go Modules](https://github.com/golang/go/wiki/Modules) through a two phase build:
 
-- An intermediate fetcher derivation. This derivation will be used to fetch all of the dependencies of the Go module.
+- An intermediate fetcher derivation called `goModules`. This derivation will be used to fetch all 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.
 
-### Example for `buildGoModule` {#ex-buildGoModule}
+### Attributes of `buildGoModule` {#buildgomodule-parameters}
 
-In the following is an example expression using `buildGoModule`, the following arguments are of special significance to the function:
+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.
+- `vendorHash`: is the hash of the output of the intermediate fetcher derivation (the dependencies of the Go modules).
 
-  `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.
+  `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;`
+  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`: 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.
+- `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`:
 
 ```nix
 pet = buildGoModule rec {
@@ -51,7 +66,7 @@ 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.
@@ -103,7 +118,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](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 (deprecated)](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:
 
@@ -113,7 +128,7 @@ for p in $NIX_PROFILES; do
 done
 ```
 
-## Attributes used by the builders {#ssec-go-common-attributes}
+## Attributes used by both 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:
 
@@ -124,11 +139,18 @@ Many attributes [controlling the build phase](#variables-controlling-the-build-p
 - [`postPatch`](#var-stdenv-postPatch)
 - [`preBuild`](#var-stdenv-preBuild)
 
+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}
 
-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:
+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:
 
 ```nix
   ldflags = [
@@ -139,7 +161,7 @@ Arguments to pass to the Go linker tool via the `-ldflags` argument of `go build
 
 ### `tags` {#var-go-tags}
 
-Arguments to pass to the Go via the `-tags` argument of `go build`. For example:
+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:
 
 ```nix
   tags = [
@@ -148,18 +170,101 @@ Arguments to pass to the Go via the `-tags` argument of `go build`. For example:
   ];
 ```
 
+Tags can also be set conditionally:
+
 ```nix
   tags = [ "production" ] ++ lib.optionals withSqlite [ "sqlite" ];
 ```
 
 ### `deleteVendor` {#var-go-deleteVendor}
 
-Removes the pre-existing vendor directory. This should only be used if the dependencies included in the vendor folder are broken or incomplete.
+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.
 
 ### `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. If `excludedPackages` is not specified, all child packages will be built.
+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.
diff --git a/nixpkgs/doc/languages-frameworks/idris2.section.md b/nixpkgs/doc/languages-frameworks/idris2.section.md
new file mode 100644
index 000000000000..47bcbf46aee9
--- /dev/null
+++ b/nixpkgs/doc/languages-frameworks/idris2.section.md
@@ -0,0 +1,47 @@
+# 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 a package set that defines at a minimum the `src` and `projectName` of the package to be built and any `idrisLibraries` required to build it. The `src` is the same source you're familiar with but the `projectName` 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 {
+  projectName = "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 {
+      projectName = "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.
+
diff --git a/nixpkgs/doc/languages-frameworks/index.md b/nixpkgs/doc/languages-frameworks/index.md
index f177de507841..67107fb5b687 100644
--- a/nixpkgs/doc/languages-frameworks/index.md
+++ b/nixpkgs/doc/languages-frameworks/index.md
@@ -21,6 +21,7 @@ go.section.md
 haskell.section.md
 hy.section.md
 idris.section.md
+idris2.section.md
 ios.section.md
 java.section.md
 javascript.section.md
diff --git a/nixpkgs/doc/languages-frameworks/javascript.section.md b/nixpkgs/doc/languages-frameworks/javascript.section.md
index 152974b465a5..5d2a6413e104 100644
--- a/nixpkgs/doc/languages-frameworks/javascript.section.md
+++ b/nixpkgs/doc/languages-frameworks/javascript.section.md
@@ -354,6 +354,7 @@ mkYarnPackage rec {
 
   - The `echo 9` steps comes from this answer: <https://stackoverflow.com/a/49139496>
   - Exporting the headers in `npm_config_nodedir` comes from this issue: <https://github.com/nodejs/node-gyp/issues/1191#issuecomment-301243919>
+- `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}
 
diff --git a/nixpkgs/doc/languages-frameworks/qt.section.md b/nixpkgs/doc/languages-frameworks/qt.section.md
index 2300c5f60ede..5d2850de3dca 100644
--- a/nixpkgs/doc/languages-frameworks/qt.section.md
+++ b/nixpkgs/doc/languages-frameworks/qt.section.md
@@ -26,6 +26,17 @@ It is important to import Qt modules directly, that is: `qtbase`, `qtdeclarative
 
 Additionally all Qt packages must include `wrapQtAppsHook` in `nativeBuildInputs`, or you must explicitly set `dontWrapQtApps`.
 
+`pkgs.callPackage` does not provide injections for `qtbase` or the like.
+Instead you want to either use `pkgs.libsForQt5.callPackage`, or `pkgs.qt6Packages.callPackage`, depending on the Qt version you want to use.
+
+For example (from [here](https://github.com/NixOS/nixpkgs/blob/2f9286912cb215969ece465147badf6d07aa43fe/pkgs/top-level/all-packages.nix#L30106))
+
+```nix
+  zeal-qt5 = libsForQt5.callPackage ../data/documentation/zeal { };
+  zeal-qt6 = qt6Packages.callPackage ../data/documentation/zeal { };
+  zeal = zeal-qt5;
+```
+
 ## 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 9be381c0bfe2..a81ba1e456e8 100644
--- a/nixpkgs/doc/languages-frameworks/rust.section.md
+++ b/nixpkgs/doc/languages-frameworks/rust.section.md
@@ -44,20 +44,21 @@ rustPlatform.buildRustPackage rec {
 }
 ```
 
-`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:
+`buildRustPackage` requires either the `cargoHash` or the `cargoSha256`
+attribute which is computed over all crate sources of this package.
+`cargoSha256` is used for traditional Nix SHA-256 hashes. `cargoHash` should
+instead be used for [SRI](https://www.w3.org/TR/SRI/) hashes and should be
+preferred. For example:
+
+```nix
+  cargoHash = "sha256-l1vL2ZdtDRxSGvP0X/l3nMw8+6WF67KPutJEzUROjg8=";
+```
 
 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
diff --git a/nixpkgs/doc/languages-frameworks/texlive.section.md b/nixpkgs/doc/languages-frameworks/texlive.section.md
index 8b1ed92a450c..01b59f6f34a9 100644
--- a/nixpkgs/doc/languages-frameworks/texlive.section.md
+++ b/nixpkgs/doc/languages-frameworks/texlive.section.md
@@ -208,3 +208,23 @@ 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
+```