mirror of
https://github.com/NixOS/nixpkgs.git
synced 2024-11-26 00:43:20 +00:00
treewide: Fix typos
This commit is contained in:
parent
d37aa6f414
commit
470614b671
@ -3,7 +3,7 @@
|
||||
|
||||
This hook can be used to setup a check phase that
|
||||
requires running a MPI application. It detects the
|
||||
used present MPI implementaion type and exports
|
||||
used present MPI implementation type and exports
|
||||
the neceesary environment variables to use
|
||||
`mpirun` and `mpiexec` in a Nix sandbox.
|
||||
|
||||
|
@ -161,7 +161,7 @@ in buildDotnetModule rec {
|
||||
They can be installed either as a global tool for the entire system, or as a local tool specific to project.
|
||||
|
||||
The local installation is the easiest and works on NixOS in the same way as on other Linux distributions.
|
||||
[See dotnet documention](https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools#install-a-local-tool) to learn more.
|
||||
[See dotnet documentation](https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools#install-a-local-tool) to learn more.
|
||||
|
||||
[The global installation method](https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools#install-a-global-tool)
|
||||
should also work most of the time. You have to remember to update the `PATH`
|
||||
|
@ -221,7 +221,7 @@ Sadly we currently don’t have tooling for this. For this you might be
|
||||
interested in the alternative [haskell.nix] framework, which, be warned, is
|
||||
completely incompatible with packages from `haskellPackages`.
|
||||
|
||||
<!-- TODO(@maralorn) Link to package set generation docs in the contributers guide below. -->
|
||||
<!-- TODO(@maralorn) Link to package set generation docs in the contributors guide below. -->
|
||||
|
||||
## `haskellPackages.mkDerivation` {#haskell-mkderivation}
|
||||
|
||||
@ -1192,7 +1192,7 @@ with GHC), it is recommended to use overlays for Nixpkgs to change them.
|
||||
Since the interrelated parts, i.e. the package set and GHC, are connected
|
||||
via the Nixpkgs fixpoint, we need to modify them both in a way that preserves
|
||||
their connection (or else we'd have to wire it up again manually). This is
|
||||
achieved by changing GHC and the package set in seperate overlays to prevent
|
||||
achieved by changing GHC and the package set in separate overlays to prevent
|
||||
the package set from pulling in GHC from `prev`.
|
||||
|
||||
The result is two overlays like the ones shown below. Adjustable parts are
|
||||
|
@ -200,7 +200,7 @@ Internally, the helper operates in three stages:
|
||||
composer repository on the filesystem containing dependencies specified in
|
||||
`composer.json`. This process uses the function
|
||||
`php.mkComposerRepository` which in turn uses the
|
||||
`php.composerHooks.composerRepositoryHook` hook. Internaly this function uses
|
||||
`php.composerHooks.composerRepositoryHook` hook. Internally this function uses
|
||||
a custom
|
||||
[Composer plugin](https://github.com/nix-community/composer-local-repo-plugin) to
|
||||
generate the repository.
|
||||
|
@ -353,7 +353,7 @@ When upgrading from a previous release, please be aware of the following incompa
|
||||
|
||||
Another benefit of the refactoring is that we can now issue reloads via either `pkill -HUP unbound` and `systemctl reload unbound` to reload the running configuration without taking the daemon offline. A prerequisite of this was that unbound configuration is available on a well known path on the file system. We are using the path `/etc/unbound/unbound.conf` as that is the default in the CLI tooling which in turn enables us to use `unbound-control` without passing a custom configuration location.
|
||||
|
||||
The module has also been reworked to be [RFC 0042](https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md) compliant. As such, `sevices.unbound.extraConfig` has been removed and replaced by [services.unbound.settings](options.html#opt-services.unbound.settings). `services.unbound.interfaces` has been renamed to `services.unbound.settings.server.interface`.
|
||||
The module has also been reworked to be [RFC 0042](https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md) compliant. As such, `services.unbound.extraConfig` has been removed and replaced by [services.unbound.settings](options.html#opt-services.unbound.settings). `services.unbound.interfaces` has been renamed to `services.unbound.settings.server.interface`.
|
||||
|
||||
`services.unbound.forwardAddresses` and `services.unbound.allowedAccess` have also been changed to use the new settings interface. You can follow the instructions when executing `nixos-rebuild` to upgrade your configuration to use the new interface.
|
||||
|
||||
|
@ -87,7 +87,7 @@ In addition to numerous new and updated packages, this release has the following
|
||||
|
||||
- [gmediarender](https://github.com/hzeller/gmrender-resurrect), a simple, headless UPnP/DLNA renderer. Available as [services.gmediarender](options.html#opt-services.gmediarender.enable).
|
||||
|
||||
- [go2rtc](https://github.com/AlexxIT/go2rtc), a camera streaming appliation with support for RTSP, WebRTC, HomeKit, FFMPEG, RTMP and other protocols. Available as [services.go2rtc](options.html#opt-services.go2rtc.enable).
|
||||
- [go2rtc](https://github.com/AlexxIT/go2rtc), a camera streaming application with support for RTSP, WebRTC, HomeKit, FFMPEG, RTMP and other protocols. Available as [services.go2rtc](options.html#opt-services.go2rtc.enable).
|
||||
|
||||
- [goeland](https://github.com/slurdge/goeland), an alternative to rss2email written in Golang with many filters. Available as [services.goeland](#opt-services.goeland.enable).
|
||||
|
||||
@ -203,7 +203,7 @@ In addition to numerous new and updated packages, this release has the following
|
||||
|
||||
- `graylog` has been updated to version 5, which can not be updated directly from the previously packaged version 3.3. If you had installed the previously packaged version 3.3, please follow the [upgrade path](https://go2docs.graylog.org/5-0/upgrading_graylog/upgrade_path.htm) from 3.3 to 4.0 to 4.3 to 5.0.
|
||||
|
||||
- `buildFHSUserEnv` is now called `buildFHSEnv` and uses FlatPak's Bubblewrap sandboxing tool rather than Nixpkgs' own chrootenv. The old chrootenv-based implemenation is still available via `buildFHSEnvChroot` but is considered deprecated and will be removed when the remaining uses inside Nixpkgs have been migrated. If your FHSEnv-wrapped application misbehaves when using the new bubblewrap implementation, please create an issue in Nixpkgs.
|
||||
- `buildFHSUserEnv` is now called `buildFHSEnv` and uses FlatPak's Bubblewrap sandboxing tool rather than Nixpkgs' own chrootenv. The old chrootenv-based implementation is still available via `buildFHSEnvChroot` but is considered deprecated and will be removed when the remaining uses inside Nixpkgs have been migrated. If your FHSEnv-wrapped application misbehaves when using the new bubblewrap implementation, please create an issue in Nixpkgs.
|
||||
|
||||
- `nushell` has been updated to at least version 0.77.0, which includes potential breaking changes in aliases. The old aliases are now available as `old-alias` but it is recommended you migrate to the new format. See [Reworked aliases](https://www.nushell.sh/blog/2023-03-14-nushell_0_77.html#reworked-aliases-breaking-changes-kubouch).
|
||||
|
||||
@ -555,7 +555,7 @@ In addition to numerous new and updated packages, this release has the following
|
||||
|
||||
- `buildDunePackage` now defaults to `strictDeps = true` which means that any library should go into `buildInputs` or `checkInputs`. Any executable that is run on the building machine should go into `nativeBuildInputs` or `nativeCheckInputs` respectively. Example of executables are `ocaml`, `findlib` and `menhir`. PPXs are libraries which are built by dune and should therefore not go into `nativeBuildInputs`.
|
||||
|
||||
- `buildFHSUserEnv` is now called `buildFHSEnv` and uses FlatPak's Bubblewrap sandboxing tool rather than Nixpkgs' own chrootenv. The old chrootenv-based implemenation is still available via `buildFHSEnvChroot` but is considered deprecated and will be removed when the remaining uses inside Nixpkgs have been migrated. If your FHSEnv-wrapped application misbehaves when using the new bubblewrap implementation, please create an issue in Nixpkgs.
|
||||
- `buildFHSUserEnv` is now called `buildFHSEnv` and uses FlatPak's Bubblewrap sandboxing tool rather than Nixpkgs' own chrootenv. The old chrootenv-based implementation is still available via `buildFHSEnvChroot` but is considered deprecated and will be removed when the remaining uses inside Nixpkgs have been migrated. If your FHSEnv-wrapped application misbehaves when using the new bubblewrap implementation, please create an issue in Nixpkgs.
|
||||
|
||||
- Top-level `buildPlatform`, `hostPlatform`, `targetPlatform` have been deprecated, use `stdenv.X` instead.
|
||||
|
||||
|
@ -293,11 +293,11 @@ The module update takes care of the new config syntax and the data itself (user
|
||||
|
||||
- `services.nginx` gained a `defaultListen` option at server-level with support for PROXY protocol listeners, also `proxyProtocol` is now exposed in `services.nginx.virtualHosts.<name>.listen` option. It is now possible to run PROXY listeners and non-PROXY listeners at a server-level, see [#213510](https://github.com/NixOS/nixpkgs/pull/213510/) for more details.
|
||||
|
||||
- `services.restic.backups` now adds wrapper scripts to your system path, which set the same environment variables as the service, so restic operations can easly be run from the command line. This behavior can be disabled by setting `createWrapper` to `false`, per backup configuration.
|
||||
- `services.restic.backups` now adds wrapper scripts to your system path, which set the same environment variables as the service, so restic operations can easily be run from the command line. This behavior can be disabled by setting `createWrapper` to `false`, per backup configuration.
|
||||
|
||||
- `services.prometheus.exporters` has a new exporter to monitor electrical power consumption based on PowercapRAPL sensor called [Scaphandre](https://github.com/hubblo-org/scaphandre), see [#239803](https://github.com/NixOS/nixpkgs/pull/239803) for more details.
|
||||
|
||||
- The MariaDB C client library was upgraded from 3.2.x to 3.3.x. It is recomended to review the [upstream release notes](https://mariadb.com/kb/en/mariadb-connector-c-33-release-notes/).
|
||||
- The MariaDB C client library was upgraded from 3.2.x to 3.3.x. It is recommended to review the [upstream release notes](https://mariadb.com/kb/en/mariadb-connector-c-33-release-notes/).
|
||||
|
||||
- The module `services.calibre-server` has new options to configure the `host`, `port`, `auth.enable`, `auth.mode` and `auth.userDb` path, see [#216497](https://github.com/NixOS/nixpkgs/pull/216497/) for more details.
|
||||
|
||||
@ -381,7 +381,7 @@ The module update takes care of the new config syntax and the data itself (user
|
||||
|
||||
- The `qemu-vm.nix` module by default now identifies block devices via
|
||||
persistent names available in `/dev/disk/by-*`. Because the rootDevice is
|
||||
identfied by its filesystem label, it needs to be formatted before the VM is
|
||||
identified by its filesystem label, it needs to be formatted before the VM is
|
||||
started. The functionality of automatically formatting the rootDevice in the
|
||||
initrd is removed from the QEMU module. However, for tests that depend on
|
||||
this functionality, a test utility for the scripted initrd is added
|
||||
|
@ -29,7 +29,7 @@ We welcome new contributors of new packages to Nixpkgs, arguably the greatest so
|
||||
Before adding a new package, please consider the following questions:
|
||||
|
||||
* Is the package ready for general use? We don't want to include projects that are too immature or are going to be abandoned immediately. In case of doubt, check with upstream.
|
||||
* Does the project have a clear license statement? Remember that softwares are unfree by default (all rights reserved), and merely providing access to the source code does not imply its redistribution. In case of doubt, ask upstream.
|
||||
* Does the project have a clear license statement? Remember that software is unfree by default (all rights reserved), and merely providing access to the source code does not imply its redistribution. In case of doubt, ask upstream.
|
||||
* How realistic is it that it will be used by other people? It's good that nixpkgs caters to various niches, but if it's a niche of 5 people it's probably too small.
|
||||
* Are you willing to maintain the package? You should care enough about the package to be willing to keep it up and running for at least one complete Nixpkgs' release life-cycle.
|
||||
|
||||
|
@ -25,7 +25,7 @@ NixOS releases should avoid having deprecated software, or making major version
|
||||
|
||||
As such, we would like to have only the newest K3s version in each NixOS
|
||||
release at the time the release branch is branched off, which will ensure the
|
||||
K3s version in that release will receieve updates for the longest duration
|
||||
K3s version in that release will receive updates for the longest duration
|
||||
possible.
|
||||
|
||||
However, this conflicts with another desire: we would like people to be able to upgrade between NixOS stable releases without needing to make a large enough k3s version jump that they violate the Kubernetes version skew policy.
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
Sage is a pretty complex package that depends on many other complex packages and patches some of those. As a result, the sage nix package is also quite complex.
|
||||
|
||||
Don't feel discouraged to fix, simplify or improve things though. The individual files have comments explaining their purpose. The most importent ones are `default.nix` linking everything together, `sage-src.nix` adding patches and `sagelib.nix` building the actual sage package.
|
||||
Don't feel discouraged to fix, simplify or improve things though. The individual files have comments explaining their purpose. The most important ones are `default.nix` linking everything together, `sage-src.nix` adding patches and `sagelib.nix` building the actual sage package.
|
||||
|
||||
## The sage build is broken
|
||||
|
||||
|
@ -137,7 +137,7 @@ following will happen:
|
||||
This is a list of Haskell packages that are known to be broken.
|
||||
|
||||
- [`hackage-packages.nix`](hackage-packages.nix) will be regenerated. This
|
||||
will mark all Haskell pacakges in `configuration-hackage2nix/broken.yaml`
|
||||
will mark all Haskell packages in `configuration-hackage2nix/broken.yaml`
|
||||
as `broken`.
|
||||
|
||||
- The
|
||||
|
@ -76,7 +76,7 @@ Some libraries have multiple systems under one project, for example,
|
||||
to the Nix store. This prevents ASDF from referring to uncompiled
|
||||
systems on run time.
|
||||
|
||||
Also useful when the `pname` is differrent than the system name, such
|
||||
Also useful when the `pname` is different than the system name, such
|
||||
as when using [reverse domain naming]. (see `jzon` ->
|
||||
`com.inuoe.jzon`)
|
||||
|
||||
|
@ -31,7 +31,7 @@ package.
|
||||
|
||||
## Using libraries not available in repositories
|
||||
|
||||
There are useful and working libraries out there, that are nontheless
|
||||
There are useful and working libraries out there, that are nonetheless
|
||||
unavailable to users of package managers such as Quicklisp or
|
||||
Ultralisp. Two real-world examples are [jzon] and [cl-tar].
|
||||
|
||||
|
@ -203,7 +203,7 @@ more copies of their specification/behavior than I like, and continuing to
|
||||
add more at this early date will only ensure that I spend more time updating
|
||||
docs and less time filling in feature gaps.
|
||||
|
||||
Full documentation may be greatly accellerated if someone can help me sort out
|
||||
Full documentation may be greatly accelerated if someone can help me sort out
|
||||
single-sourcing. See: https://github.com/abathur/resholve/issues/19
|
||||
-->
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user