mirror of
https://github.com/privatevoid-net/nix-super.git
synced 2024-11-10 08:16:15 +02:00
Merge pull request #8866 from fricklerhandwerk/glossary-list
glossary: dedent list and do not use forced line breaks
This commit is contained in:
Eelco Dolstra
GitHub
commit
9990edf926
1 changed files with 200 additions and 167 deletions
|
|
@ -1,236 +1,269 @@
|
||||||
# Glossary
|
# Glossary
|
||||||
|
|
||||||
- [derivation]{#gloss-derivation}\
|
- [derivation]{#gloss-derivation}
|
||||||
A description of a build task. The result of a derivation is a
|
|
||||||
store object. Derivations are typically specified in Nix expressions
|
|
||||||
using the [`derivation` primitive](./language/derivations.md). These are
|
|
||||||
translated into low-level *store derivations* (implicitly by
|
|
||||||
`nix-env` and `nix-build`, or explicitly by `nix-instantiate`).
|
|
||||||
|
|
||||||
[derivation]: #gloss-derivation
|
A description of a build task. The result of a derivation is a
|
||||||
|
store object. Derivations are typically specified in Nix expressions
|
||||||
|
using the [`derivation` primitive](./language/derivations.md). These are
|
||||||
|
translated into low-level *store derivations* (implicitly by
|
||||||
|
`nix-env` and `nix-build`, or explicitly by `nix-instantiate`).
|
||||||
|
|
||||||
- [store derivation]{#gloss-store-derivation}\
|
[derivation]: #gloss-derivation
|
||||||
A [derivation] represented as a `.drv` file in the [store].
|
|
||||||
It has a [store path], like any [store object].
|
|
||||||
|
|
||||||
Example: `/nix/store/g946hcz4c8mdvq2g8vxx42z51qb71rvp-git-2.38.1.drv`
|
- [store derivation]{#gloss-store-derivation}
|
||||||
|
|
||||||
See [`nix derivation show`](./command-ref/new-cli/nix3-derivation-show.md) (experimental) for displaying the contents of store derivations.
|
A [derivation] represented as a `.drv` file in the [store].
|
||||||
|
It has a [store path], like any [store object].
|
||||||
|
|
||||||
[store derivation]: #gloss-store-derivation
|
Example: `/nix/store/g946hcz4c8mdvq2g8vxx42z51qb71rvp-git-2.38.1.drv`
|
||||||
|
|
||||||
- [instantiate]{#gloss-instantiate}, instantiation\
|
See [`nix derivation show`](./command-ref/new-cli/nix3-derivation-show.md) (experimental) for displaying the contents of store derivations.
|
||||||
Translate a [derivation] into a [store derivation].
|
|
||||||
|
|
||||||
See [`nix-instantiate`](./command-ref/nix-instantiate.md).
|
[store derivation]: #gloss-store-derivation
|
||||||
|
|
||||||
[instantiate]: #gloss-instantiate
|
- [instantiate]{#gloss-instantiate}, instantiation
|
||||||
|
|
||||||
- [realise]{#gloss-realise}, realisation\
|
Translate a [derivation] into a [store derivation].
|
||||||
Ensure a [store path] is [valid][validity].
|
|
||||||
|
|
||||||
This means either running the `builder` executable as specified in the corresponding [derivation] or fetching a pre-built [store object] from a [substituter].
|
See [`nix-instantiate`](./command-ref/nix-instantiate.md).
|
||||||
|
|
||||||
See [`nix-build`](./command-ref/nix-build.md) and [`nix-store --realise`](@docroot@/command-ref/nix-store/realise.md).
|
[instantiate]: #gloss-instantiate
|
||||||
|
|
||||||
See [`nix build`](./command-ref/new-cli/nix3-build.md) (experimental).
|
- [realise]{#gloss-realise}, realisation
|
||||||
|
|
||||||
[realise]: #gloss-realise
|
Ensure a [store path] is [valid][validity].
|
||||||
|
|
||||||
- [content-addressed derivation]{#gloss-content-addressed-derivation}\
|
This means either running the `builder` executable as specified in the corresponding [derivation] or fetching a pre-built [store object] from a [substituter].
|
||||||
A derivation which has the
|
|
||||||
[`__contentAddressed`](./language/advanced-attributes.md#adv-attr-__contentAddressed)
|
|
||||||
attribute set to `true`.
|
|
||||||
|
|
||||||
- [fixed-output derivation]{#gloss-fixed-output-derivation}\
|
See [`nix-build`](./command-ref/nix-build.md) and [`nix-store --realise`](@docroot@/command-ref/nix-store/realise.md).
|
||||||
A derivation which includes the
|
|
||||||
[`outputHash`](./language/advanced-attributes.md#adv-attr-outputHash) attribute.
|
|
||||||
|
|
||||||
- [store]{#gloss-store}\
|
See [`nix build`](./command-ref/new-cli/nix3-build.md) (experimental).
|
||||||
The location in the file system where store objects live. Typically
|
|
||||||
`/nix/store`.
|
|
||||||
|
|
||||||
From the perspective of the location where Nix is
|
[realise]: #gloss-realise
|
||||||
invoked, the Nix store can be referred to
|
|
||||||
as a "_local_" or a "_remote_" one:
|
|
||||||
|
|
||||||
+ A [local store]{#gloss-local-store} exists on the filesystem of
|
- [content-addressed derivation]{#gloss-content-addressed-derivation}
|
||||||
the machine where Nix is invoked. You can use other
|
|
||||||
local stores by passing the `--store` flag to the
|
|
||||||
`nix` command. Local stores can be used for building derivations.
|
|
||||||
|
|
||||||
+ A *remote store* exists anywhere other than the
|
A derivation which has the
|
||||||
local filesystem. One example is the `/nix/store`
|
[`__contentAddressed`](./language/advanced-attributes.md#adv-attr-__contentAddressed)
|
||||||
directory on another machine, accessed via `ssh` or
|
attribute set to `true`.
|
||||||
served by the `nix-serve` Perl script.
|
|
||||||
|
|
||||||
[store]: #gloss-store
|
- [fixed-output derivation]{#gloss-fixed-output-derivation}
|
||||||
[local store]: #gloss-local-store
|
|
||||||
|
|
||||||
- [chroot store]{#gloss-chroot-store}\
|
A derivation which includes the
|
||||||
A [local store] whose canonical path is anything other than `/nix/store`.
|
[`outputHash`](./language/advanced-attributes.md#adv-attr-outputHash) attribute.
|
||||||
|
|
||||||
- [binary cache]{#gloss-binary-cache}\
|
- [store]{#gloss-store}
|
||||||
A *binary cache* is a Nix store which uses a different format: its
|
|
||||||
metadata and signatures are kept in `.narinfo` files rather than in a
|
|
||||||
[Nix database]. This different format simplifies serving store objects
|
|
||||||
over the network, but cannot host builds. Examples of binary caches
|
|
||||||
include S3 buckets and the [NixOS binary cache](https://cache.nixos.org).
|
|
||||||
|
|
||||||
- [store path]{#gloss-store-path}\
|
The location in the file system where store objects live. Typically
|
||||||
The location of a [store object] in the file system, i.e., an
|
`/nix/store`.
|
||||||
immediate child of the Nix store directory.
|
|
||||||
|
|
||||||
Example: `/nix/store/a040m110amc4h71lds2jmr8qrkj2jhxd-git-2.38.1`
|
From the perspective of the location where Nix is
|
||||||
|
invoked, the Nix store can be referred to
|
||||||
|
as a "_local_" or a "_remote_" one:
|
||||||
|
|
||||||
[store path]: #gloss-store-path
|
+ A [local store]{#gloss-local-store} exists on the filesystem of
|
||||||
|
the machine where Nix is invoked. You can use other
|
||||||
|
local stores by passing the `--store` flag to the
|
||||||
|
`nix` command. Local stores can be used for building derivations.
|
||||||
|
|
||||||
- [file system object]{#gloss-store-object}\
|
+ A *remote store* exists anywhere other than the
|
||||||
The Nix data model for representing simplified file system data.
|
local filesystem. One example is the `/nix/store`
|
||||||
|
directory on another machine, accessed via `ssh` or
|
||||||
|
served by the `nix-serve` Perl script.
|
||||||
|
|
||||||
See [File System Object](@docroot@/architecture/file-system-object.md) for details.
|
[store]: #gloss-store
|
||||||
|
[local store]: #gloss-local-store
|
||||||
|
|
||||||
[file system object]: #gloss-file-system-object
|
- [chroot store]{#gloss-chroot-store}
|
||||||
|
|
||||||
- [store object]{#gloss-store-object}\
|
A [local store] whose canonical path is anything other than `/nix/store`.
|
||||||
|
|
||||||
A store object consists of a [file system object], [reference]s to other store objects, and other metadata.
|
- [binary cache]{#gloss-binary-cache}
|
||||||
It can be referred to by a [store path].
|
|
||||||
|
|
||||||
[store object]: #gloss-store-object
|
A *binary cache* is a Nix store which uses a different format: its
|
||||||
|
metadata and signatures are kept in `.narinfo` files rather than in a
|
||||||
|
[Nix database]. This different format simplifies serving store objects
|
||||||
|
over the network, but cannot host builds. Examples of binary caches
|
||||||
|
include S3 buckets and the [NixOS binary cache](https://cache.nixos.org).
|
||||||
|
|
||||||
- [input-addressed store object]{#gloss-input-addressed-store-object}\
|
- [store path]{#gloss-store-path}
|
||||||
A store object produced by building a
|
|
||||||
non-[content-addressed](#gloss-content-addressed-derivation),
|
|
||||||
non-[fixed-output](#gloss-fixed-output-derivation)
|
|
||||||
derivation.
|
|
||||||
|
|
||||||
- [output-addressed store object]{#gloss-output-addressed-store-object}\
|
The location of a [store object] in the file system, i.e., an
|
||||||
A [store object] whose [store path] is determined by its contents.
|
immediate child of the Nix store directory.
|
||||||
This includes derivations, the outputs of [content-addressed derivations](#gloss-content-addressed-derivation), and the outputs of [fixed-output derivations](#gloss-fixed-output-derivation).
|
|
||||||
|
|
||||||
- [substitute]{#gloss-substitute}\
|
Example: `/nix/store/a040m110amc4h71lds2jmr8qrkj2jhxd-git-2.38.1`
|
||||||
A substitute is a command invocation stored in the [Nix database] that
|
|
||||||
describes how to build a store object, bypassing the normal build
|
|
||||||
mechanism (i.e., derivations). Typically, the substitute builds the
|
|
||||||
store object by downloading a pre-built version of the store object
|
|
||||||
from some server.
|
|
||||||
|
|
||||||
- [substituter]{#gloss-substituter}\
|
[store path]: #gloss-store-path
|
||||||
An additional [store]{#gloss-store} from which Nix can obtain store objects instead of building them.
|
|
||||||
Often the substituter is a [binary cache](#gloss-binary-cache), but any store can serve as substituter.
|
|
||||||
|
|
||||||
See the [`substituters` configuration option](./command-ref/conf-file.md#conf-substituters) for details.
|
- [file system object]{#gloss-store-object}
|
||||||
|
|
||||||
[substituter]: #gloss-substituter
|
The Nix data model for representing simplified file system data.
|
||||||
|
|
||||||
- [purity]{#gloss-purity}\
|
See [File System Object](@docroot@/architecture/file-system-object.md) for details.
|
||||||
The assumption that equal Nix derivations when run always produce
|
|
||||||
the same output. This cannot be guaranteed in general (e.g., a
|
|
||||||
builder can rely on external inputs such as the network or the
|
|
||||||
system time) but the Nix model assumes it.
|
|
||||||
|
|
||||||
- [Nix database]{#gloss-nix-database}\
|
[file system object]: #gloss-file-system-object
|
||||||
An SQlite database to track [reference]s between [store object]s.
|
|
||||||
This is an implementation detail of the [local store].
|
|
||||||
|
|
||||||
Default location: `/nix/var/nix/db`.
|
- [store object]{#gloss-store-object}
|
||||||
|
|
||||||
[Nix database]: #gloss-nix-database
|
|
||||||
|
|
||||||
- [Nix expression]{#gloss-nix-expression}\
|
A store object consists of a [file system object], [reference]s to other store objects, and other metadata.
|
||||||
A high-level description of software packages and compositions
|
It can be referred to by a [store path].
|
||||||
thereof. Deploying software using Nix entails writing Nix
|
|
||||||
expressions for your packages. Nix expressions are translated to
|
|
||||||
derivations that are stored in the Nix store. These derivations can
|
|
||||||
then be built.
|
|
||||||
|
|
||||||
- [reference]{#gloss-reference}\
|
[store object]: #gloss-store-object
|
||||||
A [store object] `O` is said to have a *reference* to a store object `P` if a [store path] to `P` appears in the contents of `O`.
|
|
||||||
|
|
||||||
Store objects can refer to both other store objects and themselves.
|
- [input-addressed store object]{#gloss-input-addressed-store-object}
|
||||||
References from a store object to itself are called *self-references*.
|
|
||||||
References other than a self-reference must not form a cycle.
|
|
||||||
|
|
||||||
[reference]: #gloss-reference
|
A store object produced by building a
|
||||||
|
non-[content-addressed](#gloss-content-addressed-derivation),
|
||||||
|
non-[fixed-output](#gloss-fixed-output-derivation)
|
||||||
|
derivation.
|
||||||
|
|
||||||
- [reachable]{#gloss-reachable}\
|
- [output-addressed store object]{#gloss-output-addressed-store-object}
|
||||||
A store path `Q` is reachable from another store path `P` if `Q`
|
|
||||||
is in the *closure* of the *references* relation.
|
|
||||||
|
|
||||||
- [closure]{#gloss-closure}\
|
A [store object] whose [store path] is determined by its contents.
|
||||||
The closure of a store path is the set of store paths that are
|
This includes derivations, the outputs of [content-addressed derivations](#gloss-content-addressed-derivation), and the outputs of [fixed-output derivations](#gloss-fixed-output-derivation).
|
||||||
directly or indirectly “reachable” from that store path; that is,
|
|
||||||
it’s the closure of the path under the *references* relation. For
|
|
||||||
a package, the closure of its derivation is equivalent to the
|
|
||||||
build-time dependencies, while the closure of its output path is
|
|
||||||
equivalent to its runtime dependencies. For correct deployment it
|
|
||||||
is necessary to deploy whole closures, since otherwise at runtime
|
|
||||||
files could be missing. The command `nix-store --query --requisites ` prints out
|
|
||||||
closures of store paths.
|
|
||||||
|
|
||||||
As an example, if the [store object] at path `P` contains a [reference]
|
- [substitute]{#gloss-substitute}
|
||||||
to a store object at path `Q`, then `Q` is in the closure of `P`. Further, if `Q`
|
|
||||||
references `R` then `R` is also in the closure of `P`.
|
|
||||||
|
|
||||||
[closure]: #gloss-closure
|
A substitute is a command invocation stored in the [Nix database] that
|
||||||
|
describes how to build a store object, bypassing the normal build
|
||||||
|
mechanism (i.e., derivations). Typically, the substitute builds the
|
||||||
|
store object by downloading a pre-built version of the store object
|
||||||
|
from some server.
|
||||||
|
|
||||||
- [output path]{#gloss-output-path}\
|
- [substituter]{#gloss-substituter}
|
||||||
A [store path] produced by a [derivation].
|
|
||||||
|
|
||||||
[output path]: #gloss-output-path
|
An additional [store]{#gloss-store} from which Nix can obtain store objects instead of building them.
|
||||||
|
Often the substituter is a [binary cache](#gloss-binary-cache), but any store can serve as substituter.
|
||||||
|
|
||||||
- [deriver]{#gloss-deriver}\
|
See the [`substituters` configuration option](./command-ref/conf-file.md#conf-substituters) for details.
|
||||||
The [store derivation] that produced an [output path].
|
|
||||||
|
|
||||||
- [validity]{#gloss-validity}\
|
[substituter]: #gloss-substituter
|
||||||
A store path is valid if all [store object]s in its [closure] can be read from the [store].
|
|
||||||
|
|
||||||
For a [local store], this means:
|
- [purity]{#gloss-purity}
|
||||||
- The store path leads to an existing [store object] in that [store].
|
|
||||||
- The store path is listed in the [Nix database] as being valid.
|
|
||||||
- All paths in the store path's [closure] are valid.
|
|
||||||
|
|
||||||
[validity]: #gloss-validity
|
The assumption that equal Nix derivations when run always produce
|
||||||
|
the same output. This cannot be guaranteed in general (e.g., a
|
||||||
|
builder can rely on external inputs such as the network or the
|
||||||
|
system time) but the Nix model assumes it.
|
||||||
|
|
||||||
- [user environment]{#gloss-user-env}\
|
- [Nix database]{#gloss-nix-database}
|
||||||
An automatically generated store object that consists of a set of
|
|
||||||
symlinks to “active” applications, i.e., other store paths. These
|
|
||||||
are generated automatically by
|
|
||||||
[`nix-env`](./command-ref/nix-env.md). See *profiles*.
|
|
||||||
|
|
||||||
- [profile]{#gloss-profile}\
|
An SQlite database to track [reference]s between [store object]s.
|
||||||
A symlink to the current *user environment* of a user, e.g.,
|
This is an implementation detail of the [local store].
|
||||||
`/nix/var/nix/profiles/default`.
|
|
||||||
|
|
||||||
- [installable]{#gloss-installable}\
|
Default location: `/nix/var/nix/db`.
|
||||||
Something that can be realised in the Nix store.
|
|
||||||
|
|
||||||
See [installables](./command-ref/new-cli/nix.md#installables) for [`nix` commands](./command-ref/new-cli/nix.md) (experimental) for details.
|
[Nix database]: #gloss-nix-database
|
||||||
|
|
||||||
- [NAR]{#gloss-nar}\
|
- [Nix expression]{#gloss-nix-expression}
|
||||||
A *N*ix *AR*chive. This is a serialisation of a path in the Nix
|
|
||||||
store. It can contain regular files, directories and symbolic
|
|
||||||
links. NARs are generated and unpacked using `nix-store --dump`
|
|
||||||
and `nix-store --restore`.
|
|
||||||
|
|
||||||
- [`∅`]{#gloss-emtpy-set}\
|
A high-level description of software packages and compositions
|
||||||
The empty set symbol. In the context of profile history, this denotes a package is not present in a particular version of the profile.
|
thereof. Deploying software using Nix entails writing Nix
|
||||||
|
expressions for your packages. Nix expressions are translated to
|
||||||
|
derivations that are stored in the Nix store. These derivations can
|
||||||
|
then be built.
|
||||||
|
|
||||||
- [`ε`]{#gloss-epsilon}\
|
- [reference]{#gloss-reference}
|
||||||
The epsilon symbol. In the context of a package, this means the version is empty. More precisely, the derivation does not have a version attribute.
|
|
||||||
|
|
||||||
- [string interpolation]{#gloss-string-interpolation}\
|
A [store object] `O` is said to have a *reference* to a store object `P` if a [store path] to `P` appears in the contents of `O`.
|
||||||
Expanding expressions enclosed in `${ }` within a [string], [path], or [attribute name].
|
|
||||||
|
|
||||||
See [String interpolation](./language/string-interpolation.md) for details.
|
Store objects can refer to both other store objects and themselves.
|
||||||
|
References from a store object to itself are called *self-references*.
|
||||||
|
References other than a self-reference must not form a cycle.
|
||||||
|
|
||||||
[string]: ./language/values.md#type-string
|
[reference]: #gloss-reference
|
||||||
[path]: ./language/values.md#type-path
|
|
||||||
[attribute name]: ./language/values.md#attribute-set
|
|
||||||
|
|
||||||
- [experimental feature]{#gloss-experimental-feature}\
|
- [reachable]{#gloss-reachable}
|
||||||
Not yet stabilized functionality guarded by named experimental feature flags.
|
|
||||||
These flags are enabled or disabled with the [`experimental-features`](./command-ref/conf-file.html#conf-experimental-features) setting.
|
|
||||||
|
|
||||||
See the contribution guide on the [purpose and lifecycle of experimental feaures](@docroot@/contributing/experimental-features.md).
|
A store path `Q` is reachable from another store path `P` if `Q`
|
||||||
|
is in the *closure* of the *references* relation.
|
||||||
|
|
||||||
|
- [closure]{#gloss-closure}
|
||||||
|
|
||||||
|
The closure of a store path is the set of store paths that are
|
||||||
|
directly or indirectly “reachable” from that store path; that is,
|
||||||
|
it’s the closure of the path under the *references* relation. For
|
||||||
|
a package, the closure of its derivation is equivalent to the
|
||||||
|
build-time dependencies, while the closure of its output path is
|
||||||
|
equivalent to its runtime dependencies. For correct deployment it
|
||||||
|
is necessary to deploy whole closures, since otherwise at runtime
|
||||||
|
files could be missing. The command `nix-store --query --requisites ` prints out
|
||||||
|
closures of store paths.
|
||||||
|
|
||||||
|
As an example, if the [store object] at path `P` contains a [reference]
|
||||||
|
to a store object at path `Q`, then `Q` is in the closure of `P`. Further, if `Q`
|
||||||
|
references `R` then `R` is also in the closure of `P`.
|
||||||
|
|
||||||
|
[closure]: #gloss-closure
|
||||||
|
|
||||||
|
- [output path]{#gloss-output-path}
|
||||||
|
|
||||||
|
A [store path] produced by a [derivation].
|
||||||
|
|
||||||
|
[output path]: #gloss-output-path
|
||||||
|
|
||||||
|
- [deriver]{#gloss-deriver}
|
||||||
|
|
||||||
|
The [store derivation] that produced an [output path].
|
||||||
|
|
||||||
|
- [validity]{#gloss-validity}
|
||||||
|
|
||||||
|
A store path is valid if all [store object]s in its [closure] can be read from the [store].
|
||||||
|
|
||||||
|
For a [local store], this means:
|
||||||
|
- The store path leads to an existing [store object] in that [store].
|
||||||
|
- The store path is listed in the [Nix database] as being valid.
|
||||||
|
- All paths in the store path's [closure] are valid.
|
||||||
|
|
||||||
|
[validity]: #gloss-validity
|
||||||
|
|
||||||
|
- [user environment]{#gloss-user-env}
|
||||||
|
|
||||||
|
An automatically generated store object that consists of a set of
|
||||||
|
symlinks to “active” applications, i.e., other store paths. These
|
||||||
|
are generated automatically by
|
||||||
|
[`nix-env`](./command-ref/nix-env.md). See *profiles*.
|
||||||
|
|
||||||
|
- [profile]{#gloss-profile}
|
||||||
|
|
||||||
|
A symlink to the current *user environment* of a user, e.g.,
|
||||||
|
`/nix/var/nix/profiles/default`.
|
||||||
|
|
||||||
|
- [installable]{#gloss-installable}
|
||||||
|
|
||||||
|
Something that can be realised in the Nix store.
|
||||||
|
|
||||||
|
See [installables](./command-ref/new-cli/nix.md#installables) for [`nix` commands](./command-ref/new-cli/nix.md) (experimental) for details.
|
||||||
|
|
||||||
|
- [NAR]{#gloss-nar}
|
||||||
|
|
||||||
|
A *N*ix *AR*chive. This is a serialisation of a path in the Nix
|
||||||
|
store. It can contain regular files, directories and symbolic
|
||||||
|
links. NARs are generated and unpacked using `nix-store --dump`
|
||||||
|
and `nix-store --restore`.
|
||||||
|
|
||||||
|
- [`∅`]{#gloss-emtpy-set}
|
||||||
|
|
||||||
|
The empty set symbol. In the context of profile history, this denotes a package is not present in a particular version of the profile.
|
||||||
|
|
||||||
|
- [`ε`]{#gloss-epsilon}
|
||||||
|
|
||||||
|
The epsilon symbol. In the context of a package, this means the version is empty. More precisely, the derivation does not have a version attribute.
|
||||||
|
|
||||||
|
- [string interpolation]{#gloss-string-interpolation}
|
||||||
|
|
||||||
|
Expanding expressions enclosed in `${ }` within a [string], [path], or [attribute name].
|
||||||
|
|
||||||
|
See [String interpolation](./language/string-interpolation.md) for details.
|
||||||
|
|
||||||
|
[string]: ./language/values.md#type-string
|
||||||
|
[path]: ./language/values.md#type-path
|
||||||
|
[attribute name]: ./language/values.md#attribute-set
|
||||||
|
|
||||||
|
- [experimental feature]{#gloss-experimental-feature}
|
||||||
|
|
||||||
|
Not yet stabilized functionality guarded by named experimental feature flags.
|
||||||
|
These flags are enabled or disabled with the [`experimental-features`](./command-ref/conf-file.html#conf-experimental-features) setting.
|
||||||
|
|
||||||
|
See the contribution guide on the [purpose and lifecycle of experimental feaures](@docroot@/contributing/experimental-features.md).
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue