gador/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

doc: fix typos

Browse Source
This commit is contained in:
Ben Siraphob
2025-09-01 11:31:10 -07:00
parent d665cf061a
commit 1e82a2f358
21 changed files with 38 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
doc/README.md
View File

@@ -380,7 +380,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.
@@ -415,7 +415,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

2
doc/build-helpers.md
View File

@@ -9,7 +9,7 @@ This is not to be confused with the [`builder` argument of the Nix `derivation`
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.

2
doc/build-helpers/fetchers.chapter.md
View File

@@ -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

7
doc/build-helpers/fixed-point-arguments.chapter.md
View File

@@ -1,7 +1,6 @@
# 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.
@@ -9,7 +8,7 @@ Build helpers don't always support fixed-point arguments yet, as support in [`st
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 {

2
doc/build-helpers/special/fhs-environments.section.md
View File

@@ -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:

2
doc/build-helpers/testers.chapter.md
View File

@@ -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.

2
doc/build-helpers/trivial-build-helpers.chapter.md
View File

@@ -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).

2
doc/development.md
View File

@@ -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. -->

2
doc/functions.md
View File

@@ -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

2
doc/functions/debug.section.md
View File

@@ -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.

8
doc/functions/generators.section.md
View File

@@ -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]

4
doc/interoperability/cyclonedx.md
View File

@@ -5,8 +5,8 @@ The standards described here are for including Nix specific information within S
## `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.

4
doc/languages-frameworks/chicken.section.md
View File

@@ -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.

2
doc/languages-frameworks/gnome.section.md
View File

@@ -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`.

2
doc/languages-frameworks/javascript.section.md
View File

@@ -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;

2
doc/languages-frameworks/ocaml.section.md
View File

@@ -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

2
doc/languages-frameworks/python.section.md
View File

@@ -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.

2
doc/module-system/module-system.chapter.md
View File

@@ -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 -->

6
doc/preface.chapter.md
View File

@@ -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`).

10
doc/release-notes/rl-2505.section.md
View File

@@ -230,7 +230,7 @@
- `buildGoModule` now supports a `goSum` attribute (`null` by default) to optionally provide a path to `go.sum` and correctly enabling rebuilds when the file changes.
- The newly added aliases `go_latest` and `buildGoLatestModule` are now available and can be use to prevent packages like `gopls` from breaking whenever the default toolchain minor version is lagging behind.
- The newly added aliases `go_latest` and `buildGoLatestModule` are now available and can be used to prevent packages like `gopls` from breaking whenever the default toolchain minor version is lagging behind.
It can also be used _outside of Nixpkgs_ to get fast access to new Go minor versions without having to wait for a staging cycle that will update the default builder/toolchain.
- A [policy documenting the details of Go toolchain and builder upgrades](https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/go/README.md#go-toolchainbuilder-upgrade-policy) in Nixpkgs, as well as rules related to using non-default builders like `buildGo1xxModule` and `buildGoLatestModule` has been added in-tree.
@@ -257,7 +257,7 @@
and `withGstreamer`/`withVlc` override options have been removed due to this.
- `nexusmods-app` has been upgraded from version 0.6.3. If you were running a version older than 0.7.0, then before upgrading, you **must reset all app state** (mods, games, settings, etc). Otherwise, NexusMods.App will crash due to app state files incompatibility.
- Typically, you can can reset to a clean state by running `NexusMods.App uninstall-app`. See Nexus Mod's [how to uninstall the app](https://nexus-mods.github.io/NexusMods.App/users/Uninstall) documentation for more detail and alternative methods.
- Typically, you can reset to a clean state by running `NexusMods.App uninstall-app`. See Nexus Mod's [how to uninstall the app](https://nexus-mods.github.io/NexusMods.App/users/Uninstall) documentation for more detail and alternative methods.
- This should not be necessary going forward, because loading app state from 0.7.0 or newer is now supported. This is documented in the [0.7.1 changelog](https://github.com/Nexus-Mods/NexusMods.App/releases/tag/v0.7.1).
- `nezha` and its agent `nezha-agent` have been updated to v1, which contains breaking changes. See the [official wiki](https://nezha.wiki/en_US/) for more details.
@@ -369,7 +369,7 @@
- `nodePackages.expo-cli` has been removed, as it was deprecated by upstream. The suggested replacement is the `npx expo` command.
- `open-policy-agent` has has been updated to 1.0.0+.
- `open-policy-agent` has been updated to 1.0.0+.
This major release makes the `rego.v1` syntax the default.
This is a breaking change for those using v0 Rego.
See the [upgrade documentation](https://www.openpolicyagent.org/docs/v1.0.1/v0-upgrade/) for more details.
@@ -514,7 +514,7 @@
Note that all provided plugins must have versions/tags (string after `@`), even if upstream repo does not tag each release. For untagged plugins, you can either create an empty Go project and run `go get <plugin>` and see changes in `go.mod` to get the pseudo-version number, or provide a commit hash in place of version/tag for the first run, and update the plugin string based on the error output.
- The `godot-export-templates` package now has its content at `share/godot/export_templates/$version` instead of the output root. This makes it more convenient for for symlinking into `~/.local`, but scripts expecting the old layout will need to be changed.
- The `godot-export-templates` package now has its content at `share/godot/export_templates/$version` instead of the output root. This makes it more convenient for symlinking into `~/.local`, but scripts expecting the old layout will need to be changed.
- GOverlay has been updated to 1.2, please check the [upstream changelog](https://github.com/benjamimgois/goverlay/releases) for more details.
@@ -549,7 +549,7 @@
- `gerbera` now has wavpack support.
- `signal-desktop` has been migrated to a from source build. No state migration is necessary. In case there's no working source build available (like on Darwin), the the binary build is still available at `signal-desktop-bin`.
- `signal-desktop` has been migrated to a from source build. No state migration is necessary. In case there's no working source build available (like on Darwin), the binary build is still available at `signal-desktop-bin`.
- `ddclient` was updated from 3.11.2 to 4.0.0 [Release notes](https://github.com/ddclient/ddclient/releases/tag/v4.0.0)

4
doc/release-notes/rl-2511.section.md
View File

@@ -34,7 +34,7 @@
- `buildGoModule` now warns if `<pkg>.passthru.overrideModAttrs` is lost during the overriding of its result packages.
- `gentium` package now provides `Gentium-*.ttf` files, and not `GentiumPlus-*.ttf` files like before. The font identifiers `Gentium Plus*` are available in the `gentium-plus` package, and if you want to use the more recently updated package `gentium` [by sil](https://software.sil.org/gentium/), you should update your configuration files to use the `Gentium` font identifier.
- `gentium` package now provides `Gentium-*.ttf` files, and not `GentiumPlus-*.ttf` files like before. The font identifiers `Gentium Plus*` are available in the `gentium-plus` package, and if you want to use the more recently updated package `gentium` [by SIL](https://software.sil.org/gentium/), you should update your configuration files to use the `Gentium` font identifier.
- `space-orbit` package has been removed due to lack of upstream maintenance. Debian upstream stopped tracking it in 2011.
@@ -98,7 +98,7 @@
- `tooling-language-server` has been renamed to `deputy` (both the package and binary), following the rename of the upstream project.
- `fetchtorrent`, when using the "rqbit" backend, erroneously started fetching files into a subdirectory in Nixpkgs 24.11. The original behaviour &ndash; which matches the behaviour using the "transmission" backend &ndash; has now been restored. Users reliant on the erroneous behaviour can temporarily maintain it by adding `flatten = false` to the `fetchtorrent` arguments; Nix will produce an evaluation warning for anyone using `backend = "rqbit"` without `flatten = true`.
- `fetchtorrent`, when using the "rqbit" backend, erroneously started fetching files into a subdirectory in Nixpkgs 24.11. The original behaviour -- which matches the behaviour using the "transmission" backend -- has now been restored. Users reliant on the erroneous behaviour can temporarily maintain it by adding `flatten = false` to the `fetchtorrent` arguments; Nix will produce an evaluation warning for anyone using `backend = "rqbit"` without `flatten = true`.
- `linux` and all other Linux kernel packages have moved all in-tree kernel modules into a new `modules` output.