3
0
Fork 0
forked from mirrors/nixpkgs

doc: correct typos and spelling (#237098)

This commit is contained in:
Andrew 2023-06-10 17:15:43 -07:00 committed by GitHub
parent 30a6ecff17
commit 1b6f640687
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
8 changed files with 9 additions and 9 deletions

View file

@ -201,7 +201,7 @@ checks should be performed:
them to either recommit using that key or to remove their key
information.
Given a maintainter entry like this:
Given a maintainer entry like this:
``` nix
{

View file

@ -16,7 +16,7 @@ let
if v == true then ''"yes"''
else if v == false then ''"no"''
else if isString v then ''"${v}"''
# and delegats all other values to the default generator
# and delegates all other values to the default generator
else generators.mkValueStringDefault {} v;
} ":";
};

View file

@ -1,6 +1,6 @@
# Bower {#sec-bower}
[Bower](https://bower.io) is a package manager for web site front-end components. Bower packages (comprising of build artefacts and sometimes sources) are stored in `git` repositories, typically on Github. The package registry is run by the Bower team with package metadata coming from the `bower.json` file within each package.
[Bower](https://bower.io) is a package manager for web site front-end components. Bower packages (comprising of build artifacts and sometimes sources) are stored in `git` repositories, typically on Github. The package registry is run by the Bower team with package metadata coming from the `bower.json` file within each package.
The end result of running Bower is a `bower_components` directory which can be included in the web app's build process.

View file

@ -27,7 +27,7 @@ The modules are typically installed to `lib/gio/modules/` directory of a package
In particular, we recommend:
* adding `dconf.lib` for any software on Linux that reads [GSettings](#ssec-gnome-settings) (even transitivily through e.g. GTKs file manager)
* adding `dconf.lib` for any software on Linux that reads [GSettings](#ssec-gnome-settings) (even transitively through e.g. GTKs file manager)
* adding `glib-networking` for any software that accesses network using GIO or libsoup glib-networking contains a module that implements TLS support and loads system-wide proxy settings
To allow software to use various virtual file systems, `gvfs` package can be also added. But that is usually an optional feature so we typically use `gvfs` from the system (e.g. installed globally using NixOS module).

View file

@ -104,7 +104,7 @@ The above function takes a variety of parameters:
and the location where the source code resides
* `sdkVersion` specifies which version of the iOS SDK to use.
It also possile to adjust the `xcodebuild` parameters. This is only needed in
It also possible to adjust the `xcodebuild` parameters. This is only needed in
rare circumstances. In most cases the default values should suffice:
* Specifies which `xcodebuild` target to build. By default it takes the target
@ -130,7 +130,7 @@ In addition, you need to set the following parameters:
store certificates.
* `generateIPA` specifies that we want to produce an IPA file (this is probably
what you want)
* `generateXCArchive` specifies thet we want to produce an xcarchive file.
* `generateXCArchive` specifies that we want to produce an xcarchive file.
When building IPA files on Hydra and when it is desired to allow iOS devices to
install IPAs by browsing to the Hydra build products page, you can enable the

View file

@ -143,7 +143,7 @@ To update NPM packages in nixpkgs, run the same `generate.sh` script:
#### Git protocol error {#javascript-git-error}
Some packages may have Git dependencies from GitHub specified with `git://`.
GitHub has [disabled unecrypted Git connections](https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git), so you may see the following error when running the generate script:
GitHub has [disabled unencrypted Git connections](https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git), so you may see the following error when running the generate script:
```
The unauthenticated git protocol on port 9418 is no longer supported

View file

@ -70,7 +70,7 @@ A list of the maintainers of this Nix expression. Maintainers are defined in [`n
### `mainProgram` {#var-meta-mainProgram}
The name of the main binary for the package. This effects the binary `nix run` executes and falls back to the name of the package. Example: `"rg"`
The name of the main binary for the package. This affects the binary `nix run` executes and falls back to the name of the package. Example: `"rg"`
### `priority` {#var-meta-priority}

View file

@ -286,7 +286,7 @@ This is where “sum-like” comes in from above: We can just sum all of the hos
Because of the bounds checks, the uncommon cases are `h = t` and `h + 2 = t`. In the former case, the motivation for `mapOffset` is that since its host and target platforms are the same, no transitive dependency of it should be able to “discover” an offset greater than its reduced target offsets. `mapOffset` effectively “squashes” all its transitive dependencies offsets so that none will ever be greater than the target offset of the original `h = t` package. In the other case, `h + 1` is skipped over between the host and target offsets. Instead of squashing the offsets, we need to “rip” them apart so no transitive dependencies offset is that one.
Overall, the unifying theme here is that propagation shouldnt be introducing transitive dependencies involving platforms the depending package is unaware of. \[One can imagine the dependending package asking for dependencies with the platforms it knows about; other platforms it doesnt know how to ask for. The platform description in that scenario is a kind of unforagable capability.\] The offset bounds checking and definition of `mapOffset` together ensure that this is the case. Discovering a new offset is discovering a new platform, and since those platforms werent in the derivation “spec” of the needing package, they cannot be relevant. From a capability perspective, we can imagine that the host and target platforms of a package are the capabilities a package requires, and the depending package must provide the capability to the dependency.
Overall, the unifying theme here is that propagation shouldnt be introducing transitive dependencies involving platforms the depending package is unaware of. \[One can imagine the depending package asking for dependencies with the platforms it knows about; other platforms it doesnt know how to ask for. The platform description in that scenario is a kind of unforgeable capability.\] The offset bounds checking and definition of `mapOffset` together ensure that this is the case. Discovering a new offset is discovering a new platform, and since those platforms werent in the derivation “spec” of the needing package, they cannot be relevant. From a capability perspective, we can imagine that the host and target platforms of a package are the capabilities a package requires, and the depending package must provide the capability to the dependency.
#### Variables specifying dependencies {#variables-specifying-dependencies}