diff --git a/lib/spack/docs/build_systems/intelpackage.rst b/lib/spack/docs/build_systems/intelpackage.rst index 8b2905f19a..52153348a5 100644 --- a/lib/spack/docs/build_systems/intelpackage.rst +++ b/lib/spack/docs/build_systems/intelpackage.rst @@ -90,7 +90,7 @@ and optimizers do require a paid license. In Spack, they are packaged as: TODO: Confirm and possible change(!) the scope of MPI components (runtime vs. devel) in current (and previous?) *cluster/professional/composer* editions, i.e., presence in downloads, possibly subject to license - coverage(!); see `disussion in PR #4300 + coverage(!); see `discussion in PR #4300 `_. [NB: An "mpi" subdirectory is not indicative of the full MPI SDK being present (i.e., ``mpicc``, ..., and header files). The directory may just as well diff --git a/lib/spack/docs/packaging_guide.rst b/lib/spack/docs/packaging_guide.rst index 84046a654e..b1e9a84fe4 100644 --- a/lib/spack/docs/packaging_guide.rst +++ b/lib/spack/docs/packaging_guide.rst @@ -5284,7 +5284,7 @@ installed example. example = which(self.prefix.bin.example) example() -Output showing the identification of each test part after runnig the tests +Output showing the identification of each test part after running the tests is illustrated below. .. code-block:: console @@ -5781,7 +5781,7 @@ with those implemented in the package itself. * - `Cxx `_ - Compiles and runs several ``hello`` programs - * - `Fortan + * - `Fortran `_ - Compiles and runs ``hello`` programs (``F`` and ``f90``) * - `Mpi diff --git a/lib/spack/docs/signing.rst b/lib/spack/docs/signing.rst index dc44eaec1d..7504fef75b 100644 --- a/lib/spack/docs/signing.rst +++ b/lib/spack/docs/signing.rst @@ -142,7 +142,7 @@ Reputational Key ---------------- The Reputational Key is the public facing key used to sign complete groups of -development and release packages. Only one key pair exsits in this class of +development and release packages. Only one key pair exists in this class of keys. In contrast to the Intermediate CI Key the Reputational Key *should* be used to verify package integrity. At the end of develop and release pipeline a final pipeline job pulls down all signed package metadata built by the pipeline, @@ -272,7 +272,7 @@ Internal Implementation The technical implementation of the pipeline signing process includes components defined in Amazon Web Services, the Kubernetes cluster, at affilicated -institutions, and the GitLab/GitLab Runner deployment. We present the techincal +institutions, and the GitLab/GitLab Runner deployment. We present the technical implementation in two interdependent sections. The first addresses how secrets are managed through the lifecycle of a develop or release pipeline. The second section describes how Gitlab Runner and pipelines are configured and managed to @@ -295,7 +295,7 @@ infrastructure. ----------------------- Multiple intermediate CI signing keys exist, one Intermediate CI Key for jobs -run in AWS, and one key for each affiliated institution (e.g. Univerity of +run in AWS, and one key for each affiliated institution (e.g. University of Oregon). Here we describe how the Intermediate CI Key is managed in AWS: The Intermediate CI Key (including the Signing Intermediate CI Private Key is @@ -305,7 +305,7 @@ contains an ASCII-armored export of just the *public* components of the Reputational Key. This secret also contains the *public* components of each of the affiliated institutions' Intermediate CI Key. These are potentially needed to verify dependent packages which may have been found in the public mirror or -built by a protected job running on an affiliated institution's infrastrcuture +built by a protected job running on an affiliated institution's infrastructure in an earlier stage of the pipeline. Procedurally the ``spack-intermediate-ci-signing-key`` secret is used in