about summary refs log tree commit diff
diff options
context:
space:
mode:
authorfigsoda <figsoda@pm.me>2022-12-17 18:21:48 -0500
committerfigsoda <figsoda@pm.me>2022-12-17 18:21:48 -0500
commit403e25e3e31319146c3e6ab478485a9c33efa07f (patch)
tree157bca880fa1f7bcdbb4bbbc37acb81807418827
parent42600bc7153e8a5308faf87aead4e27cff93497b (diff)
doc: fix typos
-rw-r--r--doc/contributing/reviewing-contributions.chapter.md2
-rw-r--r--doc/doc-support/lib-function-docs.nix2
-rw-r--r--doc/languages-frameworks/beam.section.md2
-rw-r--r--doc/languages-frameworks/coq.section.md2
-rw-r--r--doc/languages-frameworks/cuda.section.md2
-rw-r--r--doc/languages-frameworks/cuelang.section.md4
-rw-r--r--doc/languages-frameworks/hy.section.md4
-rw-r--r--doc/languages-frameworks/index.xml2
-rw-r--r--doc/languages-frameworks/python.section.md4
-rw-r--r--doc/languages-frameworks/rust.section.md2
-rw-r--r--doc/old/cross.txt2
-rw-r--r--doc/stdenv/multiple-output.chapter.md2
-rw-r--r--doc/stdenv/stdenv.chapter.md4
13 files changed, 17 insertions, 17 deletions
diff --git a/doc/contributing/reviewing-contributions.chapter.md b/doc/contributing/reviewing-contributions.chapter.md
index 0e6a0dd5b5305..6685c5b60a2c2 100644
--- a/doc/contributing/reviewing-contributions.chapter.md
+++ b/doc/contributing/reviewing-contributions.chapter.md
@@ -185,7 +185,7 @@ Sample template for a new module review is provided below.
 ##### Comments
 ```
 
-## Individual maintainer list {#reviewing-contributions-indvidual-maintainer-list}
+## Individual maintainer list {#reviewing-contributions-individual-maintainer-list}
 
 When adding users to `maintainers/maintainer-list.nix`, the following
 checks should be performed:
diff --git a/doc/doc-support/lib-function-docs.nix b/doc/doc-support/lib-function-docs.nix
index 64f5ed56843c0..4e67609e23fb2 100644
--- a/doc/doc-support/lib-function-docs.nix
+++ b/doc/doc-support/lib-function-docs.nix
@@ -1,4 +1,4 @@
-# Generates the documentation for library functons via nixdoc. To add
+# Generates the documentation for library functions via nixdoc. To add
 # another library function file to this list, the include list in the
 # file `doc/functions/library.xml` must also be updated.
 
diff --git a/doc/languages-frameworks/beam.section.md b/doc/languages-frameworks/beam.section.md
index 65204757b4a28..63f49adccb2ce 100644
--- a/doc/languages-frameworks/beam.section.md
+++ b/doc/languages-frameworks/beam.section.md
@@ -93,7 +93,7 @@ Practical steps:
 - run `mix2nix > mix_deps.nix` in the upstream repo.
 - pass `mixNixDeps = with pkgs; import ./mix_deps.nix { inherit lib beamPackages; };` as an argument to mixRelease.
 
-If there are git depencencies.
+If there are git dependencies.
 
 - You'll need to fix the version artificially in mix.exs and regenerate the mix.lock with fixed version (on upstream). This will enable you to run `mix2nix > mix_deps.nix`.
 - From the mix_deps.nix file, remove the dependencies that had git versions and pass them as an override to the import function.
diff --git a/doc/languages-frameworks/coq.section.md b/doc/languages-frameworks/coq.section.md
index a939a67f09fdb..e359acb3a8098 100644
--- a/doc/languages-frameworks/coq.section.md
+++ b/doc/languages-frameworks/coq.section.md
@@ -8,7 +8,7 @@ The Coq derivation is overridable through the `coq.override overrides`, where ov
 * `customOCamlPackages` (optional, defaults to `null`, which lets Coq choose a version automatically), which can be set to any of the ocaml packages attribute of `ocaml-ng` (such as `ocaml-ng.ocamlPackages_4_10` which is the default for Coq 8.11 for example).
 * `coq-version` (optional, defaults to the short version e.g. "8.10"), is a version number of the form "x.y" that indicates which Coq's version build behavior to mimic when using a source which is not a release. E.g. `coq.override { version = "d370a9d1328a4e1cdb9d02ee032f605a9d94ec7a"; coq-version = "8.10"; }`.
 
-The associated package set can be optained using `mkCoqPackages coq`, where `coq` is the derivation to use.
+The associated package set can be obtained using `mkCoqPackages coq`, where `coq` is the derivation to use.
 
 ## Coq packages attribute sets: `coqPackages` {#coq-packages-attribute-sets-coqpackages}
 
diff --git a/doc/languages-frameworks/cuda.section.md b/doc/languages-frameworks/cuda.section.md
index 27bae33bc71c4..6300904c61c87 100644
--- a/doc/languages-frameworks/cuda.section.md
+++ b/doc/languages-frameworks/cuda.section.md
@@ -38,7 +38,7 @@ want to target for in terms of SASS (real hardware) or PTX (JIT kernels).
 
 Nixpkgs tries to target support real architecture defaults based on the
 CUDA toolkit version with PTX support for future hardware.  Experienced
-users may optmize this configuration for a variety of reasons such as
+users may optimize this configuration for a variety of reasons such as
 reducing binary size and compile time, supporting legacy hardware, or
 optimizing for specific hardware.
 
diff --git a/doc/languages-frameworks/cuelang.section.md b/doc/languages-frameworks/cuelang.section.md
index 93c94027ae291..ef408c7bb19be 100644
--- a/doc/languages-frameworks/cuelang.section.md
+++ b/doc/languages-frameworks/cuelang.section.md
@@ -37,9 +37,9 @@ pkgs.writeCueValidator
 ```
 
 - The first parameter is the Cue schema file.
-- The second paramter is an options parameter, currently, only: `document` can be passed.
+- The second parameter is an options parameter, currently, only: `document` can be passed.
 
-`document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but differents documents based on the data you are validating.
+`document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but different documents based on the data you are validating.
 
 Another example, given the following `validator.nix` :
 ```
diff --git a/doc/languages-frameworks/hy.section.md b/doc/languages-frameworks/hy.section.md
index a851ff24dfc29..49309e4819f5e 100644
--- a/doc/languages-frameworks/hy.section.md
+++ b/doc/languages-frameworks/hy.section.md
@@ -4,10 +4,10 @@
 
 ### Installation without packages {#installation-without-packages}
 
-You can install `hy` via nix-env or by adding it to `configuration.nix` by reffering to it as a `hy` attribute. This kind of installation adds `hy` to your environment and it succesfully works with `python3`.
+You can install `hy` via nix-env or by adding it to `configuration.nix` by referring to it as a `hy` attribute. This kind of installation adds `hy` to your environment and it successfully works with `python3`.
 
 ::: {.caution}
-Packages that are installed with your python derivation, are not accesible by `hy` this way.
+Packages that are installed with your python derivation, are not accessible by `hy` this way.
 :::
 
 ### Installation with packages {#installation-with-packages}
diff --git a/doc/languages-frameworks/index.xml b/doc/languages-frameworks/index.xml
index 7df241436ff5b..7d404643d3693 100644
--- a/doc/languages-frameworks/index.xml
+++ b/doc/languages-frameworks/index.xml
@@ -3,7 +3,7 @@
          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 accomodated 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.
+  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" />
diff --git a/doc/languages-frameworks/python.section.md b/doc/languages-frameworks/python.section.md
index c8aec2e1e9cd8..ab5ba42895859 100644
--- a/doc/languages-frameworks/python.section.md
+++ b/doc/languages-frameworks/python.section.md
@@ -605,7 +605,7 @@ been removed, in this case, it's recommended to use `pytestCheckHook`.
 `test` command for a `checkPhase` which runs `pytest`. This is also beneficial
 when a package may need many items disabled to run the test suite.
 
-Using the example above, the analagous `pytestCheckHook` usage would be:
+Using the example above, the analogous `pytestCheckHook` usage would be:
 
 ```
   checkInputs = [ pytestCheckHook ];
@@ -624,7 +624,7 @@ Using the example above, the analagous `pytestCheckHook` usage would be:
   ];
 ```
 
-This is expecially useful when tests need to be conditionally disabled,
+This is especially useful when tests need to be conditionally disabled,
 for example:
 
 ```
diff --git a/doc/languages-frameworks/rust.section.md b/doc/languages-frameworks/rust.section.md
index 3ede908fe089d..a9d8e54cafd89 100644
--- a/doc/languages-frameworks/rust.section.md
+++ b/doc/languages-frameworks/rust.section.md
@@ -319,7 +319,7 @@ The above are just guidelines, and exceptions may be granted on a case-by-case b
 However, please check if it's possible to disable a problematic subset of the
 test suite and leave a comment explaining your reasoning.
 
-This can be achived with `--skip` in `checkFlags`:
+This can be achieved with `--skip` in `checkFlags`:
 
 ```nix
 rustPlatform.buildRustPackage {
diff --git a/doc/old/cross.txt b/doc/old/cross.txt
index 11292edccaf22..0f958e772b782 100644
--- a/doc/old/cross.txt
+++ b/doc/old/cross.txt
@@ -303,7 +303,7 @@ One of the compiler flags that GCC uses for this compiler is called X_CFLAGS.
 This is used by the Nix build process to set the dynamic linker, glibc
 in the case of i686-linux using the default Nix packages collection.
 
-Obiously, since we need to compile libstc++ for arm-linux with uClibc linking
+Obviously, since we need to compile libstc++ for arm-linux with uClibc linking
 will not be done correctly: you can't link object files built for arm-linux
 with a glibc built for i686-linux.
 
diff --git a/doc/stdenv/multiple-output.chapter.md b/doc/stdenv/multiple-output.chapter.md
index 65156816b9919..c19d497ab61e2 100644
--- a/doc/stdenv/multiple-output.chapter.md
+++ b/doc/stdenv/multiple-output.chapter.md
@@ -29,7 +29,7 @@ NixOS provides two ways to select the outputs to install for packages listed in
 `nix-env` lacks an easy way to select the outputs to install. When installing a package, `nix-env` always installs the outputs listed in `meta.outputsToInstall`, even when the user explicitly selects an output.
 
 ::: {.warning}
-`nix-env` silenty disregards the outputs selected by the user, and instead installs the outputs from `meta.outputsToInstall`. For example,
+`nix-env` silently disregards the outputs selected by the user, and instead installs the outputs from `meta.outputsToInstall`. For example,
 
 ```ShellSession
 $ nix-env -iA nixpkgs.coreutils.info
diff --git a/doc/stdenv/stdenv.chapter.md b/doc/stdenv/stdenv.chapter.md
index e3d874ef507e5..c28bb26baa4af 100644
--- a/doc/stdenv/stdenv.chapter.md
+++ b/doc/stdenv/stdenv.chapter.md
@@ -719,11 +719,11 @@ If set, libraries and executables are not stripped. By default, they are.
 
 ##### `dontStripHost` {#var-stdenv-dontStripHost}
 
-Like `dontStrip`, but only affects the `strip` command targetting the package’s host platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
+Like `dontStrip`, but only affects the `strip` command targeting the package’s host platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
 
 ##### `dontStripTarget` {#var-stdenv-dontStripTarget}
 
-Like `dontStrip`, but only affects the `strip` command targetting the packages’ target platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
+Like `dontStrip`, but only affects the `strip` command targeting the packages’ target platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
 
 ##### `dontMoveSbin` {#var-stdenv-dontMoveSbin}