Fix typos

README.md

@@ -101,7 +101,7 @@ graph TD
     NoShepherds[Closed - Lack of Interest]:::closed
     NoShepherds --> |Renewed Interest| Discuss
 
-    FCP[Final Coment Phase]
+    FCP[Final Comment Phase]
     FCP --> |FCP Canceled| Discuss
     FCP --> |Accept| Merged
     FCP --> |Reject| Rejected

rfcs/0001-rfc-process.md

@@ -23,7 +23,7 @@ because they introduce new concepts, big changes or are controversial enough
 that not everybody will agree on the direction to take.
 
 Therefore, the purpose of this RFC is to introduce a process that allows to
-bring the discussion upfront and avoid unnecesary implementations. It forces
+bring the discussion upfront and avoid unnecessary implementations. It forces
 developers to formulate their ideas without getting bogged down into
 implementation details. This RFC is used to bootstrap the process and further
 RFCs can be used to refine the process.
@@ -64,7 +64,7 @@ Pull requests that contain any of the afore mentioned 'substantial' changes may
 ## Description of the process
 
 In short, to get a major feature added to the Nix ecosystem, one should first
-go through the RFC process in order to improve the likelyhood of inclusion.
+go through the RFC process in order to improve the likelihood of inclusion.
 Here are roughly the steps that one would take:
 
 * Fork the RFC repo https://github.com/NixOS/rfcs
@@ -79,12 +79,12 @@ that will help them bring the RFC to completion. The goal is to improve the
 chances that the RFC is both desired and likely to be implemented.
 
 Once the author is happy with the state of the RFC, they should seek for
-wider community review by stating the readyness of the work. Advertisement on
+wider community review by stating the readiness of the work. Advertisement on
 the mailing-list and IRC is an acceptable way of doing that.
 
 After a number of rounds of review the discussion should settle and a general
 consensus should emerge. This bit is left intentionally vague and should be
-refined in the future. We don't have a technical commitee so controversial
+refined in the future. We don't have a technical committee so controversial
 changes will be rejected by default.
 
 If a RFC is accepted then authors may implement it and submit the feature as a

rfcs/0023-musl-libc.md

@@ -66,7 +66,7 @@ most popular libc implementation on Linux, and is used
 by a number of important projects you may be familiar with
 large userbases, including:
 * Alpine Linux - [#70 on Distrowatch](https://distrowatch.com/table.php?distribution=alpine) but very popular amongst docker users for producing slim container images.
-* [OpenWRT/LEDE](https://openwrt.org/) - #1 open-source Linux router firmware project; foundation of most other projects targetting routers.
+* [OpenWRT/LEDE](https://openwrt.org/) - #1 open-source Linux router firmware project; foundation of most other projects targeting routers.
 More projects and details of how they use musl can be found here:
 
 https://wiki.musl-libc.org/projects-using-musl.html
@@ -86,7 +86,7 @@ The main arguments for inclusion are:
 * Software sometimes must be patched to compile or run with musl; in @dtzWill's experience,
   these changes are largely fixes improving compliance and correctness resulting in
   higher-quality programs.  Recent versions of glibc have started taking stronger stances
-  on enforcing compliance (look at patch fallout folllowing any glibc upgrade in last year or so)
+  on enforcing compliance (look at patch fallout following any glibc upgrade in last year or so)
   resulting in overlapping work from both sides.
   (NOTE: use of glibc extensions or reliance on non-standard behavior is still common and unlikely to go away soon)
 
@@ -107,7 +107,7 @@ do folks believe the costs are too high?
 * [projects using musl](https://wiki.musl-libc.org/projects-using-musl.html)
 * [Slides from a talk discussing various libcs, 2014](http://events17.linuxfoundation.org/sites/events/files/slides/libc-talk.pdf)
 
-## Related Isssues
+## Related Issues
 
 * [big musl PR](https://github.com/NixOS/nixpkgs/pull/34645)
 * [issues matching "musl", newest first](https://github.com/NixOS/nixpkgs/search?o=desc&q=musl&s=created&type=Issues&utf8=%E2%9C%93)
@@ -212,7 +212,7 @@ Unfortunately this is unrealistic due to capacity constraints and other reasons.
 
 ### Responsibility
 
-"musl team" is reponsible, initially consisting of
+"musl team" is responsible, initially consisting of
 
 * @dtzWill
 * @shlevy

rfcs/0026-staging-workflow.md

@@ -9,7 +9,7 @@ related-issues:
 # Summary
 [summary]: #summary
 
-Define a new workflow for the `staging` branch that can better accomodate the
+Define a new workflow for the `staging` branch that can better accommodate the
 current and future influx of changes in order to deliver mass-rebuilds faster to
 master. As part of this new workflow an additional branch, `staging-next`, shall
 be introduced.
@@ -20,14 +20,14 @@ be introduced.
 
 The current workflow cannot handle the high amount of mass-rebuilds that are
 continuously delivered, resulting in long delays for these deliveries to reach
-`master`. When a certain delivery causes failures, attemps are typically made to
+`master`. When a certain delivery causes failures, attempts are typically made to
 fix these failures and stabilize `staging` so that the specific delivery can still
 reach `master`.
 
 Often it happens that during this period of stabilization other mass-rebuilds
 are submitted, and it is not uncommon that these also introduce failures, thus
 again increasing the time it takes for a delivery to reach `master`. This is
-especially worrysome in case of security fixes that need to be delivered as soon
+especially worrisome in case of security fixes that need to be delivered as soon
 as possible.
 
 # Detailed design

rfcs/0036-rfc-process-team-amendment.md

@@ -60,15 +60,15 @@ This team should be people who are very familiar with the main components
 touched by the RFC. The author cannot be part of the Shepherd Team. In addition,
 at most half of the Shepherd Team can be part of the RFC Steering Committee.
 
-The resposibility of the team is to guide the discussion as long as it is
+The responsibility of the team is to guide the discussion as long as it is
 constructive, new points are brought up and the RFC is iterated on and from time
 to time summarise the current state of discussion. If this is the case no longer,
 then the Shepherd Team shall step in with a motion for FCP.
 
 ##### Shepherd Leader
 The person in charge of the RFC process for a specific RFC, and responsible for
 ensuring the process is followed in a timely fashion. The Shepherd Leader has no
-special resposibility with regard to moving an undecided Shepherd Team to a
+special responsibility with regard to moving an undecided Shepherd Team to a
 certain decision.
 
 ##### Final Comment Period (FCP)

rfcs/0039-unprivileged-maintainer-teams.md

@@ -178,7 +178,7 @@ for requested reviews](https://github.com/pulls/review-requested).
    automation with credentials on an automated basis.
 
 # Future Potential RFCs
-The following topics are explictly _not_ part of this RFC.
+The following topics are explicitly _not_ part of this RFC.
 
  - Allowing maintainers to merge pull requests against their packages
    without having commit access.

rfcs/0042-config-option.md

@@ -192,7 +192,7 @@ The second part of this RFC aims to encourage people to write better NixOS modul
 
 This RFC has to be thought of as a basis for *new* modules first and foremost. By using this approach we can provide a good basis for new modules, with great flexibility for future changes.
 
-For existing modules, it is often not possible to use this `settings` style without breaking backwards compatibility. How this is handled is left up to the module authors. A workaround that could be employed is to define options `useLegacyConfig` or `declarative` which determin  the modules behavior in regards to old options.
+For existing modules, it is often not possible to use this `settings` style without breaking backwards compatibility. How this is handled is left up to the module authors. A workaround that could be employed is to define options `useLegacyConfig` or `declarative` which determine the modules behavior in regards to old options.
 
 # Drawbacks
 [drawbacks]: #drawbacks

rfcs/0044-disband-nix-core.md

@@ -20,7 +20,7 @@ evolution of the Nix ecosystem and community. It was originally slated
 as a year-long experiment.
 
 It is now a little over a year since officially merging. In that time,
-the core team has not made signifcant progress on its initial goals.
+the core team has not made significant progress on its initial goals.
 We now have the RFC steering/shepherding process which serves similar
 goals (but for the whole ecosystem, not just Nix proper) and is
 operating well. The remaining functions of the core team *not* covered
@@ -46,7 +46,7 @@ announce on all relevant forums.
 
 * Keep the core team around in its current form and responsibilities.
   Would require a fresh attempt to follow through on the relevant
-  committments to be practical.
+  commitments to be practical.
 * Reform the core team based on what we've learned, including possibly
   narrowing the scope.
 

rfcs/0062-content-addressed-paths.md

@@ -1,5 +1,5 @@
 ---
-feature: Simple content-adressed store paths
+feature: Simple content-addressed store paths
 start-date: 2019-08-14
 author: Théophane Hufschmitt
 co-authors: (find a buddy later to help our with the RFC)
@@ -15,7 +15,7 @@ related-issues: (will contain links to implementation PRs)
 Add some experimental support for content-addressed store paths to Nix.
 
 We plan here to give the possibility to mark certain store paths as
-content-adressed (ca), while keeping the other input-adressed as they are
+content-addressed (ca), while keeping the other input-addressed as they are
 now (modulo some mandatory drv rewriting before the build, see below).
 
 By making this opt-in, we can impose arbitrary limitations to the paths that
@@ -37,17 +37,17 @@ the `ca-derivation` experimental flag.
 
 [motivation]: #motivation
 
-Having a content-adressed store with Nix (aka the "Intensional store") is a
+Having a content-addressed store with Nix (aka the "Intensional store") is a
 long-time dream of the community − a design for that was already taking a whole
 chapter in [Eelco's PHD thesis][nixphd].
 
 This was never done because it represents quite a big change in Nix's model,
 with some non-trivial implications (regarding the trust model in
 particular).
 Even without going all the way down to a fully intensional model, we can
-make specific paths content-adressed, which can give some important benefits of
+make specific paths content-addressed, which can give some important benefits of
 the intensional store at a much lower price. In particular, setting some
-critical derivations as content-adressed can lead to some substantial build
+critical derivations as content-addressed can lead to some substantial build
 cutoffs.
 
 # Detailed design
@@ -87,7 +87,7 @@ these derivations).
 
 To fully support this content-addressed model, we need to extend the current
 build process, as well as the caching and remote building systems so that they
-are able to take into account the specificies of these new derivations.
+are able to take into account the specifics of these new derivations.
 
 Fully supporting content-addressed derivations requires some deep changes to the Nix model.
 For the sake of readability, we’ll first present a simplistic model that support them in a very basic way, and then extend this model in several different ways to improve the support.
@@ -119,7 +119,7 @@ the output paths of a derivation before building it.
 This means that the Nix evaluator doesn’t know the output paths of the
 dependencies it manipulates (it _could_ know them if they are already built, but
 that would be a blatant purity hole), so these derivations can’t neither embed
-their own output path, nor explicitely refer to their dependencies by their
+their own output path, nor explicitly refer to their dependencies by their
 output path.
 
 ### Output mappings
@@ -214,7 +214,7 @@ A store path `/nix/store/abc-foo` is said to be **self-referential** if the
 content of the path mentions the path `/nix/store/abc-foo` itself (and this
 mention of the store path is called a **self-reference**).
 
-A lot of store paths happen to be self-referential (for example a path that contains both an dynamic library and an executable using that library will likely have the `rpath` of the exectuable mention the absolute path to the library).
+A lot of store paths happen to be self-referential (for example a path that contains both an dynamic library and an executable using that library will likely have the `rpath` of the executable mention the absolute path to the library).
 
 It happens that these are problematic with content-addressed derivations, because
 
@@ -224,9 +224,9 @@ It happens that these are problematic with content-addressed derivations, becaus
 However, under the assumption that self-references only appear textually in the output (_i.e_ running strings on a file that contains self-references will print all the self-references out), we can:
 
 - Build the derivation on a temporary directory (`/nix/store/someArbitraryHash-foo`, the path provided by the function `assignScratchOutputPaths` above)
-- Replace all the occurences of `someArbitraryHash` by a fixed magic value
+- Replace all the occurrences of `someArbitraryHash` by a fixed magic value
 - Compute the hash of the resulting path to determine the final path
-- Replace the occurences of the magic value by the final path hash
+- Replace the occurrences of the magic value by the final path hash
 - Move the result to the final path.
 
 This is obviously a hack, however it seems to work very well in practice, due to the fact that:
@@ -311,7 +311,7 @@ work on store paths, but rather at the realisation level:
 
   If the store knows about the given derivation output, it will return the associated realisation, otherwise it will return `None`.
 
-- The substitution loop in Nix fist calls this method to ask the remote for the
+- The substitution loop in Nix first calls this method to ask the remote for the
   realisation of the current derivation output.
   If this first call succeeds, then it fetches the corresponding output path
   like before. Then, it registers the realisation in the database:
@@ -330,7 +330,7 @@ This folder contains a set of files of the form `{drvOutput}.doi`, each of them
 
 #### The “two-glibc” issue
 
-As stated in [Eelco’s thesis][nixphd], remote caching of content-addressed derivations can be problematic in conjonction with non-determinism:
+As stated in [Eelco’s thesis][nixphd], remote caching of content-addressed derivations can be problematic in conjunction with non-determinism:
 
 A typical scenario where this can happen is:
 
@@ -431,8 +431,8 @@ We also update `registerRealisation` for the local store to check these signatur
 same end-goal. The big difference between these two is in the scope they cover:
 RFC 0017 is about fundamentally changing the base model of Nix, while this
 proposal suggests to make only the minimal amount of changes to the current
-model to allow the content-adressed model to live in parallel (which would open
-the way to a fully content-adressed store as RFC0017, but in a much more
+model to allow the content-addressed model to live in parallel (which would open
+the way to a fully content-addressed store as RFC0017, but in a much more
 incremental way).
 
 Eventually this RFC should be subsumed by RFC0017.
@@ -485,7 +485,7 @@ annoying since:
 - More annoyingly, these references become dangling and can cause runtime
   failures
 
-We however have a way to dectect these: If we have leaking self-references then
+We however have a way to detect these: If we have leaking self-references then
 the output will change if we artificially change its output path. This could be
 integrated in the `--check` option of `nix-store`.
 

rfcs/0085-nixos-release-stablization.md → rfcs/0085-nixos-release-stabilization.md

@@ -1,5 +1,5 @@
 ---
-feature: nixos-release-stablization
+feature: nixos-release-stabilization
 start-date: 2021-01-17
 author: Jonathan Ringer (@jonringer)
 co-authors:
@@ -13,7 +13,7 @@ related-issues: "[NixOS release schedule](https://github.com/NixOS/rfcs/pull/80)
 
 To bring more certainty to the release cycle, add short periods where
 breaking changes are partially restricted. A list of Release Critical
-Packages is defined. Also, move most release stablization work from
+Packages is defined. Also, move most release stabilization work from
 the `release` branch to the `master` branch to reduce backports.
 
 # Motivation

rfcs/0092-plan-dynamism.md

@@ -69,7 +69,7 @@ It's very efficient, because it doesn't obligate the use of the Nix expression l
 
 It's also quite compatible with `--dry-run`.
 Because derivations don't get new dependencies *mid build*, we have no need to mess with individual steps to explore the plan.
-There still becomes multiple sorts of `--dry-run` policies, but all of them just have to do with building or not buidling derivations which *themselves* are unchanged.
+There still becomes multiple sorts of `--dry-run` policies, but all of them just have to do with building or not building derivations which *themselves* are unchanged.
 
 To make that more, clear, if you *do* want one big ("hundreds of thousands of nodes"-big), static graph, you can still have it!
 Build all the derivations that compute derivations, but not nothing else.
@@ -222,7 +222,7 @@ gives us the path to an output of it.
   still can not build derivations and then use them at evaluation
   time, meaning that you can't have an attribute set whose contents
   are determined by some build, and then access that attribute set
-  outside of build that dependens on that derivation.
+  outside of build that depends on that derivation.
 - We unfortunately expose the `text` `outputHashMode` to users.
   Preferably this should be removed entirely, in addition to `flat`,
   and everything should just use `recursive`.

rfcs/0119-testing-conventions.md

@@ -57,7 +57,7 @@ as this will help define what breakages a pull request author should take owners
     - E.g. `nixos-test` `kvm` `big-parallel`
 
 Usage for mkDerivation's `checkPhase`:
-- Quick "cheap" tests, which run units tests and maybe some addtional scenarios.
+- Quick "cheap" tests, which run units tests and maybe some additional scenarios.
 - Since this contributes to the "build time" of a package, there should be some
 emphasis on ensuring this phase isn't bloated.