NixOS · vcunat · Oct 5, 2025 · Sep 20, 2025 · Sep 20, 2025 · Sep 20, 2025
diff --git a/.git-blame-ignore-revs b/.git-blame-ignore-revs
@@ -264,6 +264,9 @@ a4f7e161b380b35b2f7bc432659a95fd71254ad8
 # haskellPackages.hercules-ci-agent (cabal2nix -> nixfmt-rfc-style)
 9314da7ee8d2aedfb15193b8c489da51efe52bb5
 
+# haskell-updates: nixfmt-rfc-style
+9e296dcf846294e0aa94af7d3235e82eee7fe055
+
 # nix-builder-vm: nixfmt-rfc-style
 a034fb50f79816c6738fb48b48503b09ea3b0132
 

diff --git a/README.md b/README.md
@@ -57,7 +57,7 @@ When successful build and test criteria are met, the Nixpkgs expressions are dis
 # Contributing
 
 Nixpkgs is among the most active projects on GitHub.
-While thousands of open issues and pull requests might seem a lot at first, it helps consider it in the context of the scope of the project.
+While thousands of open issues and pull requests might seem like a lot at first, it helps to consider it in the context of the scope of the project.
 Nixpkgs describes how to build tens of thousands of pieces of software and implements a Linux distribution.
 The [GitHub Insights](https://github.com/NixOS/nixpkgs/pulse) page gives a sense of the project activity.
 

diff --git a/ci/eval/README.md b/ci/eval/README.md
@@ -8,7 +8,7 @@ Furthermore it also allows local evaluation using:
 nix-build ci -A eval.baseline
 ```
 
-The most important two arguments are:
+The two most important arguments are:
 - `--arg evalSystems`: The set of systems for which `nixpkgs` should be evaluated.
   Defaults to the four official platforms (`x86_64-linux`, `aarch64-linux`, `x86_64-darwin` and `aarch64-darwin`).
   Example: `--arg evalSystems '["x86_64-linux" "aarch64-darwin"]'`

diff --git a/doc/README.md b/doc/README.md
@@ -408,7 +408,7 @@ Though this is not shown in the rendered documentation on nixos.org.
 
 #### Footnotes
 
-To add a foonote explanation, use the following syntax:
+To add a footnote explanation, use the following syntax:
 
 ```markdown
 Sometimes it's better to add context [^context] in a footnote.
@@ -443,7 +443,7 @@ This syntax is taken from [CommonMark](https://spec.commonmark.org/0.30/#link-re
 #### Typographic replacements
 
 Typographic replacements are enabled.
-Check the [list of possible replacement patterns check](https://github.com/executablebooks/markdown-it-py/blob/3613e8016ecafe21709471ee0032a90a4157c2d1/markdown_it/rules_core/replacements.py#L1-L15).
+Check the [list of possible replacement patterns](https://github.com/executablebooks/markdown-it-py/blob/3613e8016ecafe21709471ee0032a90a4157c2d1/markdown_it/rules_core/replacements.py#L1-L15).
 
 ## Getting help
 

diff --git a/doc/build-helpers.md b/doc/build-helpers.md
@@ -3,13 +3,13 @@
 A build helper is a function that produces derivations.
 
 :::{.warning}
-This is not to be confused with the [`builder` argument of the Nix `derivation` primitive](https://nixos.org/manual/nix/unstable/language/derivations.html), which refers to the executable that produces the build result, or [remote builder](https://nixos.org/manual/nix/stable/advanced-topics/distributed-builds.html), which refers to a remote  machine that could run such an executable.
+This is not to be confused with the [`builder` argument of the Nix `derivation` primitive](https://nixos.org/manual/nix/unstable/language/derivations.html), which refers to the executable that produces the build result, or [remote builder](https://nixos.org/manual/nix/stable/advanced-topics/distributed-builds.html), which refers to a remote machine that could run such an executable.
 :::
 
 Such a function is usually designed to abstract over a typical workflow for a given programming language or framework.
 This allows declaring a build recipe by setting a limited number of options relevant to the particular use case instead of using the `derivation` function directly.
 
-[`stdenv.mkDerivation`](#part-stdenv) is the most widely used build helper, and serves as a basis for many others.
+[`stdenv.mkDerivation`](#part-stdenv) is the most widely used build helper and serves as a basis for many others.
 In addition, it offers various options to customize parts of the builds.
 
 There is no uniform interface for build helpers.

diff --git a/doc/build-helpers/fetchers.chapter.md b/doc/build-helpers/fetchers.chapter.md
@@ -416,7 +416,7 @@ fetchurl {
 }
 ```
 
-After building the package, the file will be downloaded and place into the Nix store:
+After building the package, the file will be downloaded and placed into the Nix store:
 
 ```shell
 $ nix-build

diff --git a/doc/build-helpers/fixed-point-arguments.chapter.md b/doc/build-helpers/fixed-point-arguments.chapter.md
@@ -1,15 +1,14 @@
 # Fixed-point arguments of build helpers {#chap-build-helpers-finalAttrs}
 
-As mentioned in the beginning of this part, `stdenv.mkDerivation` could alternatively accept a fixed-point function. The input of such function, typically named `finalAttrs`, is expected to be the final state of the attribute set.
-A build helper like this is said to accept **fixed-point arguments**.
+As mentioned in the beginning of this part, `stdenv.mkDerivation` could alternatively accept a fixed-point function. The input of this function, typically named `finalAttrs`, is expected to be the final state of the attribute set.  A build helper like this is said to accept **fixed-point arguments**.
 
 Build helpers don't always support fixed-point arguments yet, as support in [`stdenv.mkDerivation`](#mkderivation-recursive-attributes) was first included in Nixpkgs 22.05.
 
 ## Defining a build helper with `lib.extendMkDerivation` {#sec-build-helper-extendMkDerivation}
 
 Developers can use the Nixpkgs library function [`lib.customisation.extendMkDerivation`](#function-library-lib.customisation.extendMkDerivation) to define a build helper supporting fixed-point arguments from an existing one with such support, with an attribute overlay similar to the one taken by [`<pkg>.overrideAttrs`](#sec-pkg-overrideAttrs).
 
-Beside overriding, `lib.extendMkDerivation` also supports `excludeDrvArgNames` to optionally exclude some arguments in the input fixed-point arguments from passing down the base build helper (specified as `constructDrv`).
+Besides overriding, `lib.extendMkDerivation` also supports `excludeDrvArgNames` to optionally exclude some arguments in the input fixed-point arguments from passing down the base build helper (specified as `constructDrv`).
 
 :::{.example #ex-build-helpers-extendMkDerivation}
 
@@ -41,7 +40,7 @@ stdenv.mkDerivation (
 )
 ```
 
-we could define with `lib.extendMkDerivation` an attribute overlay to make the result build helper also accepts the the attribute set's fixed point passing to the underlying `stdenv.mkDerivation`, named `finalAttrs` here:
+we could define with `lib.extendMkDerivation` an attribute overlay to make the result build helper also accept the attribute set's fixed point passing to the underlying `stdenv.mkDerivation`, named `finalAttrs` here:
 
 ```nix
 lib.extendMkDerivation {

diff --git a/doc/build-helpers/special/fhs-environments.section.md b/doc/build-helpers/special/fhs-environments.section.md
@@ -1,6 +1,6 @@
 # buildFHSEnv {#sec-fhs-environments}
 
-`buildFHSEnv` provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root filesystem with the host's `/nix/store`, so its footprint in terms of disk space is quite small. This allows you to run software which is hard or unfeasible to patch for NixOS; 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries for instance.
+`buildFHSEnv` provides a way to build and run an FHS-compatible, lightweight sandbox. It creates an isolated root filesystem with the host's `/nix/store`, so its footprint in terms of disk space is quite small. This allows you to run software which is hard or unfeasible to patch for NixOS; 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries for instance.
 It uses Linux' namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without requiring elevated privileges. It works similar to containerisation technology such as Docker or FlatPak but provides no security-relevant separation from the host system.
 
 Accepted arguments are:

diff --git a/doc/build-helpers/testers.chapter.md b/doc/build-helpers/testers.chapter.md
@@ -98,7 +98,7 @@ It has two modes:
 
 : The path to the files to check.
 
-`remap` (attribe set, optional) {#tester-lycheeLinkCheck-param-remap}
+`remap` (attribute set, optional) {#tester-lycheeLinkCheck-param-remap}
 
 : An attribute set where the attribute names are regular expressions.
   The values should be strings, derivations, or path values.

diff --git a/doc/build-helpers/trivial-build-helpers.chapter.md b/doc/build-helpers/trivial-build-helpers.chapter.md
@@ -651,7 +651,7 @@ Write a Bash script to a "bin" subdirectory of a directory in the Nix store.
 : The contents of the file.
 
 The file's contents will be put into `/nix/store/<store path>/bin/<name>`.
-The store path will include the the name, and it will be a directory.
+The store path will include the name, and it will be a directory.
 
 This function is a combination of [](#trivial-builder-writeShellScript) and [](#trivial-builder-writeScriptBin).
 

diff --git a/doc/development.md b/doc/development.md
@@ -1,6 +1,6 @@
 # Development of Nixpkgs {#part-development}
 
-This section shows you how Nixpkgs is being developed and how you can interact with the contributors and the latest updates.
+This section shows you how Nixpkgs is developed and how you can interact with the contributors and the latest updates.
 If you are interested in contributing yourself, see [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
 
 <!-- In the future this section should also include: How to test pull requests, how to know if pull requests are available in channels, etc. -->

diff --git a/doc/functions.md b/doc/functions.md
@@ -1,6 +1,6 @@
 # Functions reference {#chap-functions}
 
-The nixpkgs repository has several utility functions to manipulate Nix expressions.
+The Nixpkgs repository has several utility functions to manipulate Nix expressions.
 
 ```{=include=} sections
 functions/library.md

diff --git a/doc/functions/debug.section.md b/doc/functions/debug.section.md
@@ -1,5 +1,5 @@
 # Debugging Nix Expressions {#sec-debug}
 
-Nix is a unityped, dynamic language, this means every value can potentially appear anywhere. Since it is also non-strict, evaluation order and what ultimately is evaluated might surprise you. Therefore it is important to be able to debug nix expressions.
+Nix is a unityped, dynamic language, this means any value can potentially appear anywhere. Since it is also non-strict, evaluation order and what is ultimately evaluated might surprise you. Therefore, it is important to be able to debug Nix expressions.
 
 In the `lib/debug.nix` file you will find a number of functions that help (pretty-)printing values while evaluation is running. You can even specify how deep these values should be printed recursively, and transform them on the fly. Please consult the docstrings in `lib/debug.nix` for usage information.
diff --git a/doc/functions/generators.section.md b/doc/functions/generators.section.md
@@ -1,9 +1,9 @@
 # Generators {#sec-generators}
-Generators are functions that create file formats from nix data structures, e. g. for configuration files. There are generators available for: `INI`, `JSON` and `YAML`
+Generators are functions that create file formats from Nix data structures, e.g. for configuration files. There are generators available for: `INI`, `JSON` and `YAML`.
 
-All generators follow a similar call interface: `generatorName configFunctions data`, where `configFunctions` is an attrset of user-defined functions that format nested parts of the content. They each have common defaults, so often they do not need to be set manually. An example is `mkSectionName ? (name: libStr.escape [ "[" "]" ] name)` from the `INI` generator. It receives the name of a section and sanitizes it. The default `mkSectionName` escapes `[` and `]` with a backslash.
+All generators follow a similar call interface: `generatorName configFunctions data`, where `configFunctions` is an attrset of user-defined functions that format nested parts of the content. They each have common defaults, so often they do not need to be set manually. An example is `mkSectionName` from the `INI` generator, which defaults to `(name: libStr.escape [ "[" "]" ] name)`. It receives the name of a section and sanitizes it. The default `mkSectionName` escapes `[` and `]` with a backslash.
 
-Generators can be fine-tuned to produce exactly the file format required by your application/service. One example is an INI-file format which uses `: ` as separator, the strings `"yes"`/`"no"` as boolean values and requires all string values to be quoted:
+Generators can be fine-tuned to produce exactly the file format required by your application/service. One example is an INI file format that uses `: ` as a separator, the strings `"yes"` and `"no"` as boolean values, and requires all string values to be quoted:
 
 ```nix
 let
@@ -42,7 +42,7 @@ customToINI {
 }
 ```
 
-This will produce the following INI file as nix string:
+This will produce the following INI file as a Nix string:
 
 ```INI
 [main]

diff --git a/doc/interoperability/cyclonedx.md b/doc/interoperability/cyclonedx.md
@@ -3,10 +3,10 @@
 [OWASP](https://owasp.org/) [CycloneDX](https://cyclonedx.org/) is a Software [Bill of Materials](https://en.wikipedia.org/wiki/Bill_of_materials) (SBOM) standard.
 The standards described here are for including Nix specific information within SBOMs in a way that is interoperable with external SBOM tooling.
 
-## `nix` Namespace Property Taxonomy  {#sec-interop.cylonedx-nix}
+## `nix` Namespace Property Taxonomy {#sec-interop.cylonedx-nix}
 
-The following tables describe namespaces for [properties](https://cyclonedx.org/docs/1.6/json/#components_items_properties) that may be attached to components within SBOMs.
-Component properties are lists of name-value-pairs where values must be strings.
+The following tables describe namespaces for [properties](https://cyclonedx.org/docs/1.6/json/#components_items_properties) that can be attached to components within SBOMs.
+Component properties are lists of name-value-pairs where the values must be strings.
 Properties with the same name may appear more than once.
 Names and values are case-sensitive.
 

diff --git a/doc/languages-frameworks/chicken.section.md b/doc/languages-frameworks/chicken.section.md
@@ -6,7 +6,7 @@ compiler. It includes an interactive mode and a custom package format, "eggs".
 
 ## Using Eggs {#sec-chicken-using}
 
-Eggs described in nixpkgs are available inside the
+Eggs described in Nixpkgs are available inside the
 `chickenPackages.chickenEggs` attrset. Including an egg as a build input is
 done in the typical Nix fashion. For example, to include support for [SRFI
 189](https://srfi.schemers.org/srfi-189/srfi-189.html) in a derivation, one
@@ -26,7 +26,7 @@ variables `CHICKEN_INCLUDE_PATH` and `CHICKEN_REPOSITORY_PATH`.
 
 ## Updating Eggs {#sec-chicken-updating-eggs}
 
-nixpkgs only knows about a subset of all published eggs. It uses
+Nixpkgs only knows about a subset of all published eggs. It uses
 [egg2nix](https://github.com/the-kenny/egg2nix) to generate a
 package set from a list of eggs to include.
 

diff --git a/doc/languages-frameworks/gnome.section.md b/doc/languages-frameworks/gnome.section.md
@@ -111,7 +111,7 @@ Fortunately, we have a [family of hooks]{#ssec-gnome-hooks-wrapgappshook} that a
 - [`wrapGAppsHook4`]{#ssec-gnome-hooks-wrapgappshook4} for GTK 4 apps. Same as `wrapGAppsHook3` but replaces `gtk3` with `gtk4`.
 - [`wrapGAppsNoGuiHook`]{#ssec-gnome-hooks-wrapgappsnoguihook} for programs without a graphical interface. Same as the above but does not bring `gtk3` and `librsvg` into the closure.
 
-The hooks do the the following:
+The hooks do the following:
 
 - `wrapGApps*` hook itself will add the package’s `share` directory to `XDG_DATA_DIRS`.
 

diff --git a/doc/languages-frameworks/haskell.section.md b/doc/languages-frameworks/haskell.section.md
@@ -58,7 +58,7 @@ Each of those compiler versions has a corresponding attribute set `packages` bui
 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.8 is `haskell.packages.ghc948`. In fact, `haskellPackages` (at the time of writing) is just an alias
-for `haskell.packages.ghc984`:
+for `haskell.packages.ghc9103`.
 
 Every package set also re-exposes the GHC used to build its packages as `haskell.packages.*.ghc`.
 

diff --git a/doc/languages-frameworks/javascript.section.md b/doc/languages-frameworks/javascript.section.md
@@ -542,7 +542,7 @@ set `prePnpmInstall` to the right commands to run. For example:
 ```nix
 {
   prePnpmInstall = ''
-    pnpm config set dedupe-peer-dependants false
+    pnpm config set dedupe-peer-dependents false
   '';
   pnpmDeps = pnpm.fetchDeps {
     inherit (finalAttrs) prePnpmInstall;

diff --git a/doc/languages-frameworks/ocaml.section.md b/doc/languages-frameworks/ocaml.section.md
@@ -52,7 +52,7 @@ Here is a simple package example.
 
 - It sets the optional `doCheck` attribute such that tests will be run with
   `dune runtest -p angstrom` after the build (`dune build -p angstrom`) is
-  complete, but only if the OCaml version is at at least `"4.05"`.
+  complete, but only if the OCaml version is at least `"4.05"`.
 
 - It uses the package `ocaml-syntax-shims` as a build input, `alcotest` and
   `ppx_let` as check inputs (because they are needed to run the tests), and

diff --git a/doc/languages-frameworks/python.section.md b/doc/languages-frameworks/python.section.md
@@ -1018,7 +1018,7 @@ that we introduced with the `let` expression.
 #### Handling dependencies {#handling-dependencies}
 
 Our example, `toolz`, does not have any dependencies on other Python packages or system libraries.
-[`buildPythonPackage`](#buildpythonpackage-function) uses the the following arguments in the following circumstances:
+[`buildPythonPackage`](#buildpythonpackage-function) uses the following arguments in the following circumstances:
 
 - `dependencies` - For Python runtime dependencies.
 - `build-system` - For Python build-time requirements.

diff --git a/doc/module-system/module-system.chapter.md b/doc/module-system/module-system.chapter.md
@@ -162,7 +162,7 @@ the last category is only available after the `imports` have been resolved.
   It is exposed as a module argument due to how the module system is implemented, which cannot be avoided without breaking compatibility.
 
   It is a good practice not to rely on `_prefix`. A module should not make assumptions about its location in the configuration tree.
-  For example, the root of a NixOS configuration may have a non-empty prefix, for example when it is a specialisation, or when it is part of a larger, multi-host configuration such as a [NixOS test](https://nixos.org/manual/nixos/unstable/#sec-nixos-tests).
+  For example, the root of a NixOS configuration may have a non-empty prefix, for example when it is a specialisation, or when it is part of a larger, multi-host configuration, such as a [NixOS test](https://nixos.org/manual/nixos/unstable/#sec-nixos-tests).
   Instead of depending on `_prefix` use explicit options, whose default definitions can be provided by the module that imports them.
 
 <!-- markdown link aliases -->

diff --git a/doc/preface.chapter.md b/doc/preface.chapter.md
@@ -19,7 +19,7 @@ To discover other kinds of documentation:
 ## Overview of Nixpkgs {#overview-of-nixpkgs}
 
 Nix expressions describe how to build packages from source and are collected in
-the [nixpkgs repository](https://github.com/NixOS/nixpkgs). Also included in the
+the [Nixpkgs repository](https://github.com/NixOS/nixpkgs). Also included in the
 collection are Nix expressions for
 [NixOS modules](https://nixos.org/nixos/manual/index.html#sec-writing-modules).
 With these expressions the Nix package manager can build binary packages.
@@ -34,7 +34,7 @@ security updates. More up-to-date packages and modules are available via the
 `nixos-unstable` channel.
 
 Both `nixos-unstable` and `nixpkgs-unstable` follow the `master` branch of the
-nixpkgs repository, although both do lag the `master` branch by generally
+Nixpkgs repository, although both do lag the `master` branch by generally
 [a couple of days](https://status.nixos.org/). Updates to a channel are
 distributed as soon as all tests for that channel pass, e.g.
 [this table](https://hydra.nixos.org/job/nixpkgs/trunk/unstable#tabs-constituents)
@@ -46,5 +46,5 @@ which also builds binary packages from the Nix expressions in Nixpkgs for
 The binaries are made available via a [binary cache](https://cache.nixos.org).
 
 The current Nix expressions of the channels are available in the
-[nixpkgs repository](https://github.com/NixOS/nixpkgs) in branches
+[Nixpkgs repository](https://github.com/NixOS/nixpkgs) in branches
 that correspond to the channel names (e.g. `nixos-22.11-small`).
diff --git a/doc/redirects.json b/doc/redirects.json
@@ -216,6 +216,12 @@
   "sec-building-packages-with-llvm-using-clang-stdenv": [
     "index.html#sec-building-packages-with-llvm-using-clang-stdenv"
   ],
+  "sec-darwin-libcxx-deployment-targets": [
+    "index.html#sec-darwin-libcxx-deployment-targets"
+  ],
+  "sec-darwin-libcxx-versions": [
+    "index.html#sec-darwin-libcxx-versions"
+  ],
   "sec-functions-library-treefmt": [
     "index.html#sec-functions-library-treefmt"
   ],