treewide: fix doc typos

Done with `fd \\\.md$ . --type f -x typos --write-changes`

doc/README.md

@@ -293,7 +293,7 @@ Though this is not shown in the rendered documentation on nixos.org.
 
 #### Figures
 
-To define a referencable figure use the following fencing:
+To define a referenceable figure use the following fencing:
 
 ```markdown
 ::: {.figure #nixos-logo}

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

@@ -241,7 +241,7 @@ Write a text file to the Nix store.
 `allowSubstitutes` (Bool, _optional_)
 
 : Whether to allow substituting from a binary cache.
-  Passed through to [`allowSubsitutes`](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-allowSubstitutes) of the underlying call to `builtins.derivation`.
+  Passed through to [`allowSubstitutes`](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-allowSubstitutes) of the underlying call to `builtins.derivation`.
 
   It defaults to `false`, as running the derivation's simple `builder` executable locally is assumed to be faster than network operations.
   Set it to true if the `checkPhase` step is expensive.
@@ -453,7 +453,7 @@ writeTextFile {
 
 ### `writeScriptBin` {#trivial-builder-writeScriptBin}
 
-Write a script within a `bin` subirectory of a directory in the Nix store.
+Write a script within a `bin` subdirectory of a directory in the Nix store.
 This is for consistency with the convention of software packages placing executables under `bin`.
 
 `writeScriptBin` takes the following arguments:

doc/languages-frameworks/javascript.section.md

@@ -233,7 +233,7 @@ If these are not defined, `npm pack` may miss some files, and no binaries will b
 * `npmPruneFlags`: Flags to pass to `npm prune`. Defaults to the value of `npmInstallFlags`.
 * `makeWrapperArgs`: Flags to pass to `makeWrapper`, added to executable calling the generated `.js` with `node` as an interpreter. These scripts are defined in `package.json`.
 * `nodejs`: The `nodejs` package to build against, using the corresponding `npm` shipped with that version of `node`. Defaults to `pkgs.nodejs`.
-* `npmDeps`: The dependencies used to build the npm package. Especially useful to not have to recompute workspace depedencies.
+* `npmDeps`: The dependencies used to build the npm package. Especially useful to not have to recompute workspace dependencies.
 
 #### prefetch-npm-deps {#javascript-buildNpmPackage-prefetch-npm-deps}
 

doc/languages-frameworks/nim.section.md

@@ -88,7 +88,7 @@ For example, to propagate a dependency on SDL2 for lockfiles that select the Nim
 }
 ```
 
-The annotations in the `nim-overrides.nix` set are functions that take two arguments and return a new attrset to be overlayed on the package being built.
+The annotations in the `nim-overrides.nix` set are functions that take two arguments and return a new attrset to be overlaid on the package being built.
 - lockAttrs: the attrset for this library from within a lockfile. This can be used to implement library version constraints, such as marking libraries as broken or insecure.
 - prevAttrs: the attrset produced by initial arguments to `buildNimPackage` and any preceding lockfile overlays.
 

lib/fileset/README.md

@@ -236,7 +236,7 @@ File sets cannot add single files to the store, they can only import files under
 Arguments:
 - (+) There's no point in using this library for a single file, since you can't do anything other than add it to the store or not.
   And it would be unclear how the library should behave if the one file wouldn't be added to the store:
-  `toSource { root = ./file.nix; fileset = <empty>; }` has no reasonable result because returing an empty store path wouldn't match the file type, and there's no way to have an empty file store path, whatever that would mean.
+  `toSource { root = ./file.nix; fileset = <empty>; }` has no reasonable result because returning an empty store path wouldn't match the file type, and there's no way to have an empty file store path, whatever that would mean.
 
 ### `fileFilter` takes a path
 

nixos/doc/manual/configuration/luks-file-systems.section.md

@@ -90,7 +90,7 @@ as [Trezor](https://trezor.io/).
 
 ### systemd Stage 1 {#sec-luks-file-systems-fido2-systemd}
 
-If systemd stage 1 is enabled, it handles unlocking of LUKS-enrypted volumes
+If systemd stage 1 is enabled, it handles unlocking of LUKS-encrypted volumes
 during boot. The following example enables systemd stage1 and adds support for
 unlocking the existing LUKS2 volume `root` using any enrolled FIDO2 compatible
 tokens.

nixos/doc/manual/development/unit-handling.section.md

@@ -75,7 +75,7 @@ units".
 
 "Normal" systemd units, by default, are ordered AFTER `sysinit.target`. In
 other words, these "normal" units expect all services ordered before
-`sysinit.target` to have finished without explicity declaring this dependency
+`sysinit.target` to have finished without explicitly declaring this dependency
 relationship for each dependency. See the [systemd
 bootup](https://www.freedesktop.org/software/systemd/man/latest/bootup.html)
 for more details on the bootup process.

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

@@ -824,7 +824,7 @@ In addition to numerous new and upgraded packages, this release has the followin
   Configurations using this default will print a warning when rebuilt.
 
 - `security.acme` certificates will now correctly check for CA
-  revokation before reaching their minimum age.
+  revocation before reaching their minimum age.
 
 - Removing domains from `security.acme.certs._name_.extraDomainNames`
   will now correctly remove those domains during rebuild/renew.

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

@@ -365,7 +365,7 @@ The pre-existing [services.ankisyncd](#opt-services.ankisyncd.enable) has been m
   This means that configuration now has to be done using [environment variables](https://hexdocs.pm/livebook/readme.html#environment-variables) instead of command line arguments.
   This has the further consequence that the `livebook` service configuration has changed.
 
-- `lua` interpreters default LUA_PATH and LUA_CPATH are not overriden by nixpkgs
+- `lua` interpreters default LUA_PATH and LUA_CPATH are not overridden by nixpkgs
   anymore, we patch LUA_ROOT instead which is more respectful to upstream.
 
 - `luarocks-packages-updater`'s .csv format, used to define lua packages to be updated, has changed: `src` (URL of a git repository) has now become `rockspec` (URL of a rockspec) to remove ambiguity regarding which rockspec to use and simplify implementation.
@@ -730,7 +730,7 @@ Use `services.pipewire.extraConfig` or `services.pipewire.configPackages` for Pi
 - `services.postgresql.extraPlugins`' type has expanded. Previously it was a list of packages, now it can also be a function that returns such a list.
   For example a config line like ``services.postgresql.extraPlugins = with pkgs.postgresql_11.pkgs; [ postgis ];`` is recommended to be changed to ``services.postgresql.extraPlugins = ps: with ps; [ postgis ];``;
 
-- `services.slskd` has been refactored to include more configuation options in
+- `services.slskd` has been refactored to include more configuration options in
   the free-form `services.slskd.settings` option, and some defaults (including listen ports)
   have been changed to match the upstream defaults. Additionally, disk logging is now
   disabled by default, and the log rotation timer has been removed.
@@ -758,7 +758,7 @@ Use `services.pipewire.extraConfig` or `services.pipewire.configPackages` for Pi
 
 - `systemd` units can now specify the `Upholds=` and `UpheldBy=` unit dependencies via the aptly
   named `upholds` and `upheldBy` options. These options get systemd to enforce that the
-  dependencies remain continuosly running for as long as the dependent unit is in a running state.
+  dependencies remain continuously running for as long as the dependent unit is in a running state.
 
 - A stdenv's default set of hardening flags can now be set via its `bintools-wrapper`'s `defaultHardeningFlags` argument. A convenient stdenv adapter, `withDefaultHardeningFlags`, can be used to override an existing stdenv's `defaultHardeningFlags`.
 

pkgs/applications/networking/cluster/k3s/docs/ONBOARDING_MAINTAINER.md

@@ -24,13 +24,13 @@ Only consensus is required to move forward any proposal. Consensus meaning the a
 
 If you cause a regression (we've all been there), you are responsible for fixing it, but in case you can't fix it (it happens), feel free to ask for help. That's fine, just let us know.
 
-To merge code, you need to be a commiter, or use the merge-bot, but currently the merge-bot only works for packages located at `pkgs/by-name/`, which means, K3s still need to be migrated there before you can use merge-bot for merging. As a non-commiter, once you have approved a PR you need to forward the request to a commiter. For deciding which commiter, give preference initially to K3s commiters, but any commiter can commit. A commiter usually has a green approval in PRs.
+To merge code, you need to be a committer, or use the merge-bot, but currently the merge-bot only works for packages located at `pkgs/by-name/`, which means, K3s still need to be migrated there before you can use merge-bot for merging. As a non-committer, once you have approved a PR you need to forward the request to a committer. For deciding which committer, give preference initially to K3s committers, but any committer can commit. A committer usually has a green approval in PRs.
 
-K3s's commiters currently are: superherointj, marcusramberg, Mic92.
+K3s's committers currently are: superherointj, marcusramberg, Mic92.
 
 @euank is often silent but still active and has always handled anything dreadful, internal parts of K3s/Kubernetes or architecture things, he initially packaged K3s for nixpkgs, think of him as a last resort, when we fail to accomplish a fix, he comes to rescue us from ourselves.
 
-@mic92 stepped up when @superherointj stepped down a time ago, as Mic92 has a broad responsibility in nixpkgs (he is responsible for far too many things already, nixpkgs-reviews, sops-nix, release manager, bot-whatever), we avoid giving him chore work for `nixos-unstable`, only pick him as commiter last. As Mic92 runs K3s in a `nixos-stable` setting, he might help in testing stable backports.
+@mic92 stepped up when @superherointj stepped down a time ago, as Mic92 has a broad responsibility in nixpkgs (he is responsible for far too many things already, nixpkgs-reviews, sops-nix, release manager, bot-whatever), we avoid giving him chore work for `nixos-unstable`, only pick him as committer last. As Mic92 runs K3s in a `nixos-stable` setting, he might help in testing stable backports.
 
 On how to handle requests, it's the usual basics, such as, when reviewing PRs, issues, be welcoming, helpful, provide hints whenever possible, try to move things forward, assume good will, ignore [as don't react to] any negativity [since it spirals badly], delay and sort any (severe) disagreement in private. Even on disagrements, be thankful to people for their dedicated time, no matter what happens. In essence, on any unfortunate event, **always put people over code**.
 

pkgs/applications/networking/cluster/k3s/docs/VERSIONING.md

@@ -11,7 +11,7 @@ afoul of the upstream version skew policy.
 
 ## Patch Release Support Lifecycle
 
-K3s is built on top of K8s and typically provides a similar release cadence and support window (simply by cherry-picking over k8s patches). As such, we assume k3s's support lifecycle is identical to upstream K8s. The upstream K8s release and support lifecycle, including maintenance and end-of-life dates for current releases, is documented [on their suppport site](https://kubernetes.io/releases/patch-releases/#support-period). A more tabular view of the current support timeline can also be found on [endoflife.date](https://endoflife.date/kubernetes).
+K3s is built on top of K8s and typically provides a similar release cadence and support window (simply by cherry-picking over k8s patches). As such, we assume k3s's support lifecycle is identical to upstream K8s. The upstream K8s release and support lifecycle, including maintenance and end-of-life dates for current releases, is documented [on their support site](https://kubernetes.io/releases/patch-releases/#support-period). A more tabular view of the current support timeline can also be found on [endoflife.date](https://endoflife.date/kubernetes).
 
 In short, a new Kubernetes version is released roughly every 4 months and each release is supported for a little over 1 year.
 

pkgs/development/cuda-modules/README.md

@@ -23,7 +23,7 @@ scope. These are typically required for the creation of the finalized
 ## Top-level directories
 
 - `cuda`: CUDA redistributables! Provides extension to `cudaPackages` scope.
-- `cudatoolkit`: monolothic CUDA Toolkit run-file installer. Provides extension
+- `cudatoolkit`: monolithic CUDA Toolkit run-file installer. Provides extension
     to `cudaPackages` scope.
 - `cudnn`: NVIDIA cuDNN library.
 - `cutensor`: NVIDIA cuTENSOR library.

pkgs/development/tools/build-managers/gradle/README.md

@@ -23,7 +23,7 @@ Obviously, this is horrible for reproducibility. Additionally, Gradle
 doesn't offer a way to export the list of dependency URLs and hashes (it
 does in a way, but it's far from being complete, and as such is useless
 for nixpkgs). Even if did, it would be annoying to use considering
-fetching non-Gradle dependendencies in Gradle scripts is commonplace.
+fetching non-Gradle dependencies in Gradle scripts is commonplace.
 
 That's why the setup hook uses mitm-cache, a program designed for
 intercepting all HTTP requests, recording all the files that were