diff --git a/doc/builders/fetchers.chapter.md b/doc/builders/fetchers.chapter.md
index 317c9430cd00..c70e3020bbfa 100644
--- a/doc/builders/fetchers.chapter.md
+++ b/doc/builders/fetchers.chapter.md
@@ -18,7 +18,7 @@ stdenv.mkDerivation {
The main difference between `fetchurl` and `fetchzip` is in how they store the contents. `fetchurl` will store the unaltered contents of the URL within the Nix store. `fetchzip` on the other hand will decompress the archive for you, making files and directories directly accessible in the future. `fetchzip` can only be used with archives. Despite the name, `fetchzip` is not limited to .zip files and can also be used with any tarball.
-`fetchpatch` works very similarly to `fetchurl` with the same arguments expected. It expects patch files as a source and and performs normalization on them before computing the checksum. For example it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
+`fetchpatch` works very similarly to `fetchurl` with the same arguments expected. It expects patch files as a source and performs normalization on them before computing the checksum. For example it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
Other fetcher functions allow you to add source code directly from a VCS such as subversion or git. These are mostly straightforward nambes based on the name of the command used with the VCS system. Because they give you a working repository, they act most like `fetchzip`.
diff --git a/doc/builders/images/snaptools.xml b/doc/builders/images/snaptools.xml
index 422fcfa37d88..bbe2e3f5e14c 100644
--- a/doc/builders/images/snaptools.xml
+++ b/doc/builders/images/snaptools.xml
@@ -16,7 +16,7 @@
- The base should not be be specified, as makeSnap will force set it.
+ The base should not be specified, as makeSnap will force set it.
diff --git a/doc/languages-frameworks/android.section.md b/doc/languages-frameworks/android.section.md
index 62e544cd48b6..416073df078e 100644
--- a/doc/languages-frameworks/android.section.md
+++ b/doc/languages-frameworks/android.section.md
@@ -80,7 +80,7 @@ Most of the function arguments have reasonable default settings.
You can specify license names:
-* `extraLicenses` is a list of of license names.
+* `extraLicenses` is a list of license names.
You can get these names from repo.json or `querypackages.sh licenses`. The SDK
license (`android-sdk-license`) is accepted for you if you set accept_license
to true. If you are doing something like working with preview SDKs, you will
diff --git a/doc/languages-frameworks/dotnet.section.md b/doc/languages-frameworks/dotnet.section.md
index 88fd74db8256..c3947042494d 100644
--- a/doc/languages-frameworks/dotnet.section.md
+++ b/doc/languages-frameworks/dotnet.section.md
@@ -64,7 +64,7 @@ $ dotnet --info
The `dotnetCorePackages.sdk_X_Y` is preferred over the old dotnet-sdk as both major and minor version are very important for a dotnet environment. If a given minor version isn't present (or was changed), then this will likely break your ability to build a project.
-## dotnetCorePackages.sdk vs vs dotnetCorePackages.net vs dotnetCorePackages.netcore vs dotnetCorePackages.aspnetcore
+## dotnetCorePackages.sdk vs dotnetCorePackages.net vs dotnetCorePackages.netcore vs dotnetCorePackages.aspnetcore
The `dotnetCorePackages.sdk` contains both a runtime and the full sdk of a given version. The `net`, `netcore` and `aspnetcore` packages are meant to serve as minimal runtimes to deploy alongside already built applications. For runtime versions >= .NET 5 `net` is used while `netcore` is used for older .NET Core runtime version.
diff --git a/doc/languages-frameworks/lua.section.md b/doc/languages-frameworks/lua.section.md
index d81949c75f69..5935cbd7bd52 100644
--- a/doc/languages-frameworks/lua.section.md
+++ b/doc/languages-frameworks/lua.section.md
@@ -50,7 +50,7 @@ and install it in your profile with
```shell
nix-env -iA nixpkgs.myLuaEnv
```
-The environment is is installed by referring to the attribute, and considering
+The environment is installed by referring to the attribute, and considering
the `nixpkgs` channel was used.
#### Lua environment defined in `/etc/nixos/configuration.nix`
@@ -129,7 +129,7 @@ the whitelist maintainers/scripts/luarocks-packages.csv and updated by running m
[luarocks2nix](https://github.com/nix-community/luarocks) is a tool capable of generating nix derivations from both rockspec and src.rock (and favors the src.rock).
The automation only goes so far though and some packages need to be customized.
These customizations go in `pkgs/development/lua-modules/overrides.nix`.
-For instance if the rockspec defines `external_dependencies`, these need to be manually added in in its rockspec file then it won't work.
+For instance if the rockspec defines `external_dependencies`, these need to be manually added in its rockspec file then it won't work.
You can try converting luarocks packages to nix packages with the command `nix-shell -p luarocks-nix` and then `luarocks nix PKG_NAME`.
Nix rely on luarocks to install lua packages, basically it runs:
diff --git a/doc/languages-frameworks/python.section.md b/doc/languages-frameworks/python.section.md
index e569cdaa9357..26458c3906e6 100644
--- a/doc/languages-frameworks/python.section.md
+++ b/doc/languages-frameworks/python.section.md
@@ -334,7 +334,7 @@ Above, we were mostly just focused on use cases and what to do to get started
creating working Python environments in nix.
Now that you know the basics to be up and running, it is time to take a step
-back and take a deeper look at at how Python packages are packaged on Nix. Then,
+back and take a deeper look at how Python packages are packaged on Nix. Then,
we will look at how you can use development mode with your code.
#### Python library packages in Nixpkgs
@@ -918,7 +918,7 @@ because their behaviour is different:
* `nativeBuildInputs ? []`: Build-time only dependencies. Typically executables
as well as the items listed in `setup_requires`.
-* `buildInputs ? []`: Build and/or run-time dependencies that need to be be
+* `buildInputs ? []`: Build and/or run-time dependencies that need to be
compiled for the host machine. Typically non-Python libraries which are being
linked.
* `checkInputs ? []`: Dependencies needed for running the `checkPhase`. These
diff --git a/doc/languages-frameworks/ruby.section.md b/doc/languages-frameworks/ruby.section.md
index aeec154586c7..c519d79d3daf 100644
--- a/doc/languages-frameworks/ruby.section.md
+++ b/doc/languages-frameworks/ruby.section.md
@@ -229,7 +229,7 @@ end
If you want to package a specific version, you can use the standard Gemfile syntax for that, e.g. `gem 'mdl', '0.5.0'`, but if you want the latest stable version anyway, it's easier to update by simply running the `bundle lock` and `bundix` steps again.
-Now you can also also make a `default.nix` that looks like this:
+Now you can also make a `default.nix` that looks like this:
```nix
{ bundlerApp }:
diff --git a/doc/languages-frameworks/rust.section.md b/doc/languages-frameworks/rust.section.md
index 94f94aaffe32..020201d08665 100644
--- a/doc/languages-frameworks/rust.section.md
+++ b/doc/languages-frameworks/rust.section.md
@@ -737,7 +737,7 @@ with import "${src.out}/rust-overlay.nix" pkgs pkgs;
stdenv.mkDerivation {
name = "rust-env";
buildInputs = [
- # Note: to use use stable, just replace `nightly` with `stable`
+ # Note: to use stable, just replace `nightly` with `stable`
latest.rustChannels.nightly.rust
# Add some extra dependencies from `pkgs`
diff --git a/doc/using/overlays.xml b/doc/using/overlays.xml
index 1def8b069555..8f12aad2adad 100644
--- a/doc/using/overlays.xml
+++ b/doc/using/overlays.xml
@@ -230,7 +230,7 @@ self: super:
- For BLAS/LAPACK switching to work correctly, all packages must depend on blas or lapack. This ensures that only one BLAS/LAPACK library is used at one time. There are two versions versions of BLAS/LAPACK currently in the wild, LP64 (integer size = 32 bits) and ILP64 (integer size = 64 bits). Some software needs special flags or patches to work with ILP64. You can check if ILP64 is used in Nixpkgs with blas.isILP64 and lapack.isILP64. Some software does NOT work with ILP64, and derivations need to specify an assertion to prevent this. You can prevent ILP64 from being used with the following:
+ For BLAS/LAPACK switching to work correctly, all packages must depend on blas or lapack. This ensures that only one BLAS/LAPACK library is used at one time. There are two versions of BLAS/LAPACK currently in the wild, LP64 (integer size = 32 bits) and ILP64 (integer size = 64 bits). Some software needs special flags or patches to work with ILP64. You can check if ILP64 is used in Nixpkgs with blas.isILP64 and lapack.isILP64. Some software does NOT work with ILP64, and derivations need to specify an assertion to prevent this. You can prevent ILP64 from being used with the following: