Spelling pass, add a sort script for the wordlist

- Check spelling in docs/ and devlog/, add allowed words as needed and correct mispellings, change to American english
- Add a small bash script that will tidy up the wordlist

.cspell-allowed-words.txt

@@ -32,6 +32,7 @@ buddiesofbudgie
 builddeps
 caddyfile
 caja
+calamares
 cangjie
 cbindgen
 centrino
@@ -84,6 +85,7 @@ fdisk
 ferryctl
 ferryd
 filesharing
+firstpost
 flarum
 flatpak
 flicky
@@ -104,12 +106,14 @@ gpasswd
 gperf
 gssapi
 haruna
+headerbar
 homeserver
 hostnames
 hplip
 hyphenator
 ibetical
 ibus
+ikey
 inet
 inkjet
 inspiron
@@ -125,6 +129,7 @@ ksgrd
 ksshaskpass
 ksysguard
 ldflags
+libc
 libcurl
 libdir
 libfoobar
@@ -149,6 +154,7 @@ libudev
 libuiohook
 libwebp
 lifebook
+livingsilver
 luks
 lutris
 lvchange
@@ -182,6 +188,7 @@ nomodeset
 nopatch
 noprefixroute
 nproc
+nuitka
 nvme
 ocen
 ocenaudio
@@ -206,6 +213,7 @@ plexmediaserver
 pomo
 pomodoneapp
 portege
+posix
 powerline
 presario
 probook
@@ -259,6 +267,7 @@ smbdoptions
 smbpasswd
 solbuild
 solusesp
+somecommand
 somekey
 someotherpackage
 somepackage

.cspell-sort-wordlist.sh

@@ -0,0 +1,19 @@
+#!/usr/bin/env bash
+set -e
+
+# Checks that .cspell-allowed-words.txt exists, then:
+# 1. Converts all text to lowercase
+# 2. Sorts the file
+# 3. Removes duplicate entries
+
+TARGET='.cspell-allowed-words.txt'
+
+if [ ! -f $TARGET ]; then
+    echo "File $TARGET not found!"
+    exit 1
+
+fi
+
+awk -i inplace '{print tolower($0)}' $TARGET
+sort -o $TARGET $TARGET
+awk -i inplace '!seen[$0]++' $TARGET

devlog/2024-01-13-welcome-devlog.md

@@ -13,13 +13,13 @@ hide_table_of_contents: false
 
 Welcome to the Solus Development Log.
 
-The Solus Development Log will be used by Solus Staff and outside contributors to hightlight wins and changes in Solus. Keep an eye on this space.
+The Solus Development Log will be used by Solus Staff and outside contributors to highlight wins and changes in Solus. Keep an eye on this space.
 
 <!-- truncate -->
 
-The Solus DevLog has been setup to facilitate improved communication with the outside world; wins, signficant changes, as well as challenges, within Solus. Solus Staff and contributors are encouraged to use this space.
+The Solus DevLog has been setup to facilitate improved communication with the outside world; wins, significant changes, as well as challenges, within Solus. Solus Staff and contributors are encouraged to use this space.
 
-The DevLog has been setup as a seperate entity to the [Solus Blog](https://getsol.us/blog/) to encourage more short form development content that doesn't require the same level of polish as an official blog post.
+The DevLog has been setup as a separate entity to the [Solus Blog](https://getsol.us/blog/) to encourage more short form development content that doesn't require the same level of polish as an official blog post.
 
 It is hoped that this will be used to help communicate what's going on in Solus such that our short-term and medium-term progress, goals, and ambitions are less of a black box to the outside world.
 

devlog/2024-01-19-eopkg-is-dead.md

@@ -18,6 +18,8 @@ Close watchers of our [packages repository](https://github.com/getsolus/packages
 
 It's a long story.
 
+<!-- truncate -->
+
 Our package manager `eopkg` is written in Python2. Python2 was originally planned to hit end-of-life all the way back in 2015! So Solus contributors past and present have wrestled with three thorny issues:
 
 - Do we really want to just port `eopkg` to python3? Surely we could build something newer and shinier.

docs/packaging/advanced-config/local-repository.md

@@ -5,7 +5,7 @@ summary: Packaging Using a Local Repository
 
 # Packaging Using a Local Repository
 
-This guide walks you through the steps necessary to tell solbuild how to utilise locally built `.eopkg's` that are not yet in the Solus repository.
+This guide walks you through the steps necessary to tell solbuild how to utilize locally built `.eopkg's` that are not yet in the Solus repository.
 
 :::note
 It is not necessary to use a local repository to test most package submissions. The easier and recommended way is to install the eopkg files provided when a package is built. This is intended for use with stack upgrades, rebuilds, or new packages that need new dependencies that are not yet in the repo.
@@ -29,7 +29,7 @@ Improvements have been made to make it simple for contributors to test fixes out
 
 Note that you will need both the regular package and the `-devel` package if you want to build another package against them using `pkgconfig()` in the `package.yml file`.
 
-With the `.eopkg` files now present in the local repo, we can make use of them in solbuild by running `go-task build-local` rather than just `go-task`. This will index the local repository and prioritise their use over what is available in the Solus unstable repository.
+With the `.eopkg` files now present in the local repo, we can make use of them in solbuild by running `go-task build-local` rather than just `go-task`. This will index the local repository and prioritize their use over what is available in the Solus unstable repository.
 
 ## Best practices when working with a solbuild local repository
 

docs/packaging/procedures/release-processes.md

@@ -9,15 +9,15 @@ This post is intended as both information to users, and guidelines for developer
 
 ## Repository staging
 
-All package builds for Solus, updates or otherwise, will always enter the `unstable` repository first. Consequently, all Solus developers and contributors should ensure `solbuild` is configured to use the unstable target. As and when the weekly stabilisation efforts have completed, the `unstable` repository will be pulled into `shannon`, the stable target.
+All package builds for Solus, updates or otherwise, will always enter the `unstable` repository first. Consequently, all Solus developers and contributors should ensure `solbuild` is configured to use the unstable target. As and when the weekly stabilization efforts have completed, the `unstable` repository will be pulled into `shannon`, the stable target.
 
 This effectively means that `shannon` is a rolling snapshot of `unstable`. Note that the weekly sync will not make each repository match identically - the **tip** of every package in `unstable` will be merged into `shannon`. This ensures that the `shannon` update path is cost-efficient in terms of package availability, and that the delta packages provided on `shannon` match the true update path for those users. Lastly, this also ensures that there are no unintended packages arriving in shannon from older builds.
 
 Solus installations always default to the `shannon` repository, making shannon the published distribution, and `unstable` the development distribution.
 
 ## Weekly Sync - Every Friday
 
-At minimum there shall be one sync per week - this will always be on a Friday. As a result, users are never more than a few days away from unstable. This allows packagers to make deeper changes to Solus and still have time to stabilise the repository before releasing changes on the Friday.
+At minimum there shall be one sync per week - this will always be on a Friday. As a result, users are never more than a few days away from unstable. This allows packagers to make deeper changes to Solus and still have time to stabilize the repository before releasing changes on the Friday.
 
 Given the high volume of changes within Solus in any sync window, the Friday sync should be viewed more as a release than a simple sync. All developers and contributors should try their best to ensure that their changes do not introduce regressions, and that existing update paths are **always respected**.