Git: v2.47.1 -> v2.48.0

doc/interoperability/openxr.md

@@ -0,0 +1,5 @@
+# OpenXR in NixOS
+
+OpenXR is a standard for eXtended Reality (XR) applications and drivers (providers).
+
+OpenXR runtime providers must ensure that the library path of the runtime's shared library can be loaded by Nix applications. If your OpenXR runtime provider runs in an FHSEnv, this means you may have to use `auto-patchelf` to link dependencies to the Nix store.

doc/languages-frameworks/haskell.section.md

@@ -57,7 +57,7 @@ Available compilers are collected under `haskell.compiler`.
 Each of those compiler versions has a corresponding attribute set `packages` built with
 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` (at the time of writing) is just an alias
+9.4.8 is `haskell.packages.ghc948`. In fact `haskellPackages` (at the time of writing) is just an alias
 for `haskell.packages.ghc966`:
 
 Every package set also re-exposes the GHC used to build its packages as `haskell.packages.*.ghc`.
@@ -764,7 +764,7 @@ that depend on that library, you may want to use:
 
 ```nix
 haskellPackages.haskell-ci.overrideScope (self: super: {
-  Cabal = self.Cabal_3_14_0_0;
+  Cabal = self.Cabal_3_14_1_0;
 })
 ```
 

doc/languages-frameworks/python.section.md

@@ -183,7 +183,15 @@ following are specific to `buildPythonPackage`:
   [`makeWrapper`](#fun-makeWrapper) set `PATH` and `PYTHONPATH` environment variables before calling
   the binary. Additional arguments here can allow a developer to set environment
   variables which will be available when the binary is run. For example,
-  `makeWrapperArgs = ["--set FOO BAR" "--set BAZ QUX"]`.
+  `makeWrapperArgs = ["--set" "FOO" "BAR" "--set" "BAZ" "QUX"]`.
+
+  ::: {.note}
+  When `__structuredAttrs = false`, the attribute `makeWrapperArgs` is passed as a space-separated string to the build script. Developers should use `prependToVar` or `appendToVar` to add arguments to it in build phases, or use `__structuredAttrs = true` to ensure that `makeWrapperArgs` is passed as a Bash array.
+
+  For compatibility purposes,
+  when `makeWrapperArgs` shell variable is specified as a space-separated string (instead of a Bash array) in the build script, the string content is Bash-expanded before concatenated into the `wrapProgram` command. Still, developers should not rely on such behaviours, but use `__structuredAttrs = true` to specify flags containing spaces (e.g. `makeWrapperArgs = [ "--set" "GREETING" "Hello, world!" ]`), or use -pre and -post phases to specify flags with Bash-expansions (e.g. `preFixup = ''makeWrapperArgs+=(--prefix PATH : "$SOME_PATH")`'').
+  :::
+
 * `namePrefix`: Prepends text to `${name}` parameter. In case of libraries, this
   defaults to `"python3.8-"` for Python 3.8, etc., and in case of applications to `""`.
 * `pypaBuildFlags ? []`: A list of strings. Arguments to be passed to `python -m build --wheel`.
@@ -1273,7 +1281,7 @@ Using the example above, the analogous `pytestCheckHook` usage would be:
   ];
 
   # requires additional data
-  pytestFlagsArray = [
+  pytestFlags = [
     "tests/"
     "--ignore=tests/integration"
   ];
@@ -1433,7 +1441,7 @@ automatically add `pythonRelaxDepsHook` if either `pythonRelaxDeps` or
     unittestCheckHook
   ];
 
-  unittestFlagsArray = [
+  unittestFlags = [
     "-s" "tests" "-v"
   ];
 }
@@ -2002,7 +2010,7 @@ Occasionally packages don't make use of a common test framework, which may then
 
 * Non-working tests can often be deselected. Most Python modules
   do follow the standard test protocol where the pytest runner can be used.
-  `pytest` supports the `-k` and `--ignore` parameters to ignore test
+  `pytest` supports the `-k` and `--ignore-glob` parameters to ignore test
   methods or classes as well as whole files. For `pytestCheckHook` these are
   conveniently exposed as `disabledTests` and `disabledTestPaths` respectively.
 
@@ -2019,11 +2027,17 @@ Occasionally packages don't make use of a common test framework, which may then
     ];
 
     disabledTestPaths = [
-      "this/file.py"
+      "path/to/performance.py"
+      "path/to/connect-*.py"
     ];
   }
   ```
 
+  ::: {.note}
+  If the test path to disable contains characters like `*`, `?`, `[`, and `]`,
+  quote them with square brackets (`[*]`, `[?]`, `[[]`, and `[]]`) to match literally.
+  :::
+
 * 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`.

doc/stdenv/cross-compilation.chapter.md

@@ -135,7 +135,7 @@ Many packages assume that an unprefixed binutils (`cc`/`ar`/`ld` etc.) is availa
 ```
 
 #### How do I avoid compiling a GCC cross-compiler from source? {#cross-qa-avoid-compiling-gcc-cross-compiler}
-On less powerful machines, it can be inconvenient to cross-compile a package only to find out that GCC has to be compiled from source, which could take up to several hours. Nixpkgs maintains a limited [cross-related jobset on Hydra](https://hydra.nixos.org/jobset/nixpkgs/cross-trunk), which tests cross-compilation to various platforms from build platforms "x86\_64-darwin", "x86\_64-linux", and "aarch64-linux".  See `pkgs/top-level/release-cross.nix` for the full list of target platforms and packages.  For instance, the following invocation fetches the pre-built cross-compiled GCC for `armv6l-unknown-linux-gnueabihf` and builds GNU Hello from source.
+On less powerful machines, it can be inconvenient to cross-compile a package only to find out that GCC has to be compiled from source, which could take up to several hours. Nixpkgs maintains a limited [cross-related jobset on Hydra](https://hydra.nixos.org/jobset/nixpkgs/cross-trunk), which tests cross-compilation to various platforms from build platforms "x86\_64-linux", "aarch64-linux", and "aarch64-darwin".  See `pkgs/top-level/release-cross.nix` for the full list of target platforms and packages.  For instance, the following invocation fetches the pre-built cross-compiled GCC for `armv6l-unknown-linux-gnueabihf` and builds GNU Hello from source.
 
 ```ShellSession
 $ nix-build '<nixpkgs>' -A pkgsCross.raspberryPi.hello

doc/stdenv/stdenv.chapter.md

@@ -75,17 +75,9 @@ stdenv.mkDerivation {
 }
 ```
 
-where the builder can do anything it wants, but typically starts with
+where `stdenv` sets up the environment automatically (e.g. by resetting `PATH` and populating it from build inputs). If you want, you can use `stdenv`’s generic builder:
 
 ```bash
-source $stdenv/setup
-```
-
-to let `stdenv` set up the environment (e.g. by resetting `PATH` and populating it from build inputs). If you want, you can still use `stdenv`’s generic builder:
-
-```bash
-source $stdenv/setup
-
 buildPhase() {
   echo "... this is my custom build phase ..."
   gcc foo.c -o foo
@@ -1276,7 +1268,7 @@ addEnvHooks "$hostOffset" myBashFunction
 
 The *existence* of setups hooks has long been documented and packages inside Nixpkgs are free to use this mechanism. Other packages, however, should not rely on these mechanisms not changing between Nixpkgs versions. Because of the existing issues with this system, there’s little benefit from mandating it be stable for any period of time.
 
-First, let’s cover some setup hooks that are part of Nixpkgs default `stdenv`. This means that they are run for every package built using `stdenv.mkDerivation` or when using a custom builder that has `source $stdenv/setup`. Some of these are platform specific, so they may run on Linux but not Darwin or vice-versa.
+First, let’s cover some setup hooks that are part of Nixpkgs default `stdenv`. This means that they are run for every package built using `stdenv.mkDerivation`, even with custom builders. Some of these are platform specific, so they may run on Linux but not Darwin or vice-versa.
 
 ### `move-docs.sh` {#move-docs.sh}
 
@@ -1411,6 +1403,7 @@ these in the [Hooks Reference](#chap-hooks).
 ### Compiler and Linker wrapper hooks {#compiler-linker-wrapper-hooks}
 
 If the file `${cc}/nix-support/cc-wrapper-hook` exists, it will be run at the end of the [compiler wrapper](#cc-wrapper).
+If the file `${binutils}/nix-support/ld-wrapper-hook` exists, it will be run at the end of the linker wrapper, before the linker runs.
 If the file `${binutils}/nix-support/post-link-hook` exists, it will be run at the end of the linker wrapper.
 These hooks allow a user to inject code into the wrappers.
 As an example, these hooks can be used to extract `extraBefore`, `params` and `extraAfter` which store all the command line arguments passed to the compiler and linker respectively.

maintainers/maintainer-list.nix

@@ -17153,6 +17153,14 @@
     githubId = 108072;
     name = "Slawomir Gonet";
   };
+  outfoxxed = {
+    name = "outfoxxed";
+    email = "[email protected]";
+    matrix = "@outfoxxed:outfoxxed.me";
+    github = "outfoxxed";
+    githubId = 83010835;
+    keys = [ { fingerprint = "0181 FF89 4F34 7FCC EB06  5710 4C88 A185 FB89 301E"; } ];
+  };
   ovlach = {
     email = "[email protected]";
     name = "Ondrej Vlach";

maintainers/scripts/haskell/update-cabal2nix-unstable.sh

@@ -1,5 +1,5 @@
 #! /usr/bin/env nix-shell
-#! nix-shell -i bash -p coreutils curl jq gnused haskellPackages.cabal2nix-unstable -I nixpkgs=.
+#! nix-shell -i bash -p coreutils curl jq gnused haskellPackages.cabal2nix-unstable nixfmt-rfc-style -I nixpkgs=.
 
 # Updates cabal2nix-unstable to the latest master of the nixos/cabal2nix repository.
 # See regenerate-hackage-packages.sh for details on the purpose of this script.
@@ -13,5 +13,7 @@ commit="$(jq -r .commit.sha <<< "$head_info")"
 # extract commit timestamp and convert to date
 date="$(date "--date=$(jq -r .commit.commit.committer.date <<< "$head_info")" +%F)"
 # generate nix expression from cabal file, replacing the version with the commit date
-echo '# This file defines cabal2nix-unstable, used by maintainers/scripts/haskell/regenerate-hackage-packages.sh.' > pkgs/development/haskell-modules/cabal2nix-unstable.nix
-cabal2nix --subpath cabal2nix "https://github.com/NixOS/cabal2nix/archive/$commit.tar.gz" | sed -e 's/version = ".*"/version = "'"unstable-$date"'"/' >> pkgs/development/haskell-modules/cabal2nix-unstable.nix
+output=pkgs/development/haskell-modules/cabal2nix-unstable.nix
+echo '# This file defines cabal2nix-unstable, used by maintainers/scripts/haskell/regenerate-hackage-packages.sh.' > "$output"
+cabal2nix --subpath cabal2nix "https://github.com/NixOS/cabal2nix/archive/$commit.tar.gz" | sed -e 's/version = ".*"/version = "'"unstable-$date"'"/' >> "$output"
+nixfmt "$output"

maintainers/scripts/haskell/update-stackage.sh

@@ -8,7 +8,7 @@ set -eu -o pipefail
 # (should be capitalized like the display name)
 SOLVER=LTS
 # Stackage solver verson, if any. Use latest if empty
-VERSION=
+VERSION=22
 TMP_TEMPLATE=update-stackage.XXXXXXX
 readonly SOLVER
 readonly VERSION

nixos/doc/manual/release-notes/rl-2505.section.md

@@ -22,6 +22,8 @@
 
 - The default Elixir version has been updated to 1.18.
 
+- `buildPythonPackage`, `buildPythonApplication` and the Python building setup hooks now support both `__structuredAttrs = true` and `__structuredAttrs = false`.
+
 - `services.dex` now restarts upon changes to the `.environmentFile` or entries in `.settings.staticClients[].secretFile` when the entry is a `path` type.
 
 - `nixos-rebuild-ng`, a full rewrite of `nixos-rebuild` in Python, is available for testing. You can enable it by setting [system.rebuild.enableNg](options.html#opt-system.rebuild.enableNg) in your configuration (this will replace the old `nixos-rebuild`), or by adding `nixos-rebuild-ng` to your `environment.systemPackages` (in this case, it will live side-by-side with `nixos-rebuild` as `nixos-rebuild-ng`). It is expected that the next major version of NixOS (25.11) will enable `system.rebuild.enableNg` by default.
@@ -120,6 +122,16 @@
   instead of the python tester launcher. You can still refer to the python
   launcher via `python3Packages.toPythonApplication python3Packages.playwright`
 
+- The representation of the flags attributes as shell/environment variables for most Python building setup hooks are now the same as `stdenv.mkDerivation` and other build helpers -- they are space-separated environment variables when `__structuredAttrs = false` and Bash arrays when `__structuredAttrs = true`, and are concatenated to the command without Bash-evaluation. The following behaviour changes are introduced during the conversion:
+
+  - The following flags are no longer Bash-expanded before concatenated to the command:
+    - `disabledTests` and `disabledTestPaths` for `pytestCheckHook`. (`disabledTestPaths` used to be expanded twice before concatenation.)
+    - `setupPyBuildFlags` and `setupPyGlobalFlags` for `setuptoolsBuildHook`.
+
+  - `pytestFlags` and `unittestFlags` replace `pytestFlagsArray` and `unittestFlagsArray` and become the new and conforming interface.
+
+  - `pytestFlagsArray` and `unittestFlagsArray` are kept for compatibility purposes. They continue to be Bash-expanded before concatenated. This compatibility layer will be removed in future releases.
+
 - `strawberry` has been updated to 1.2, which drops support for the VLC backend and Qt 5. The `strawberry-qt5` package
   and `withGstreamer`/`withVlc` override options have been removed due to this.