Spelling cleanup

.cspell-allowed-words.txt

@@ -37,6 +37,7 @@ builddeps
 caddyfile
 caja
 calamares
+callgraph
 cangjie
 cbindgen
 centrino
@@ -53,6 +54,7 @@ cmdline
 compat
 configfile
 confopts
+corepack
 cpesearch
 cran
 cryptsetup
@@ -65,6 +67,7 @@ dbus
 destdir
 devel
 devlog
+diggity
 dircolors
 directoy
 dirmodel
@@ -165,6 +168,7 @@ ksycoca
 ksysguard
 kwalletd
 kxmlgui
+labwc
 ldflags
 lennart
 libc
@@ -197,9 +201,11 @@ libwebp
 libwebpdecoder
 libwebpdemux
 libwebpmux
+libz
 lifebook
 livingsilver
 localrepo
+lpng
 luks
 lutris
 lvchange
@@ -237,6 +243,7 @@ nuitka
 nvme
 ocen
 ocenaudio
+ofast
 oflag
 openrazer
 organised
@@ -277,6 +284,7 @@ qosmio
 qsynth
 qtile
 quickstart
+radeon
 ralink
 rbind
 rdesktop
@@ -302,6 +310,7 @@ rslave
 rstudio
 rubymine
 rundeps
+runhaskell
 runpath
 runrecovery
 rustup
@@ -352,6 +361,7 @@ tmpfiles
 touchpad
 touchpads
 trackpad
+transifex
 uefi
 ufriilt
 unetbootin
@@ -386,6 +396,7 @@ winbind
 winbindoptions
 wireshark
 wmissing
+wordlist
 workdir
 wsdd
 wxwidgets

devlog/2024-02-09-Intro-to-optimizing-packages-on-solus.md

@@ -14,7 +14,7 @@ hide_table_of_contents: false
 We'll explore how to build packages with advanced compiler techniques in order to squeeze more performance out of the box for packages in Solus. We'll be using the story of how `libwebp` was optimized for and how it led to an unexpected side quest.
 
 <!-- truncate -->
-
+<!-- cspell:disable-next-line -->
 # Cual es la causa
 
 Linux distributions have a lot of control over how a source-based package gets compiled and shipped to users as part of a binary repository. Aggressive and advanced compiler optimization techniques, as well as other methods can be used to provide greater out of the box performance for end users. This can greatly benefit users running on older hardware to provide a snappier end-user experience; reducing time waiting on a heavy workload to finish; or even improved battery life; amongst other improvements.
@@ -122,6 +122,7 @@ Awesome, these binaries do exactly what we need to benchmark `libwebp`, but, we
 
 One extra step we have to do is ensure these binaries are actually linking against their own library, as upstream developers can have a habit of making sure their binaries don't link against their own libraries and end up being self-contained. Run `ldd` to verify.
 
+<!-- spellchecker:disable -->
 ```
 $ ldd /usr/bin/dwebp
 	linux-vdso.so.1 (0x00007ffed8733000)
@@ -134,6 +135,7 @@ $ ldd /usr/bin/dwebp
 	libz.so.1 => /usr/lib/libz.so.1.3.0 (0x00007f7473200000)
 	/usr/lib64/ld-linux-x86-64.so.2 (0x00007f7473bea000)
 ```
+<!-- spellchecker:enable -->
 
 Awesome in this case both `dwebp` and `cwebp` link against `libwebp.so` so we can be confident that any performance improvements will be applicable to all packages in the repository linking against `libwebp`.
 
@@ -221,6 +223,7 @@ Benchmark 1: cwebp ~/PNG_Test.png -o /dev/null
 
 Well... That's interesting. We actually regress in performance for decode performance whilst gaining another small bump in encoding performance. Worse still, we get a bunch of `profile count data file not found [-Wmissing-profile]` warning messages during the optimized build indicating to us our profiling workload isn't comprehensive enough and doesn't cover enough code paths. The lack of a handy `make check` that could be used as a profiling workload is really hurting us here. For now, let's put a pin in exploring PGO, it isn't a dead end but more work needs to be done curating a more comprehensive workload to chuck at it in this particular case, whilst other, easier, optimization techniques are still available to us.
 
+<!-- cspell:disable-next-line -->
 ## 256 Vector Units go brrrrrr...
 
 The next obvious step is to explore `glibc` hardware capabilities. For those unaware both `clang` and `gnu` compilers provide `x86_64-v2`, `x86_64-v3` and `x86_64-v4` micro-architecture build options on top of the baseline of `x86_64`. These enable the use of targeting additional CPU instruction sets during compilation for better performance. For example, `-sse4.2` for `x86_64-v2`, `-avx2` for `x86_64-v3`, and `-avx512` for `x86_64-v4`.
@@ -252,6 +255,7 @@ We now see these additional files in the `pspec_x86_64.xml` file
 
 Let's rerun `lld` on `dwebp` after installing the new package and...
 
+<!-- spellchecker:disable -->
 ```
 $ ldd /usr/bin/dwebp
 	linux-vdso.so.1 (0x00007ffeab5b1000)
@@ -264,6 +268,7 @@ $ ldd /usr/bin/dwebp
 	libz.so.1 => /usr/lib/glibc-hwcaps/x86-64-v3/libz.so.1.3 (0x00007f9a34dbb000)
 	/usr/lib64/ld-linux-x86-64.so.2 (0x00007f9a3520b000)
 ```
+<!-- spellchecker:enable -->
 
 We can crucially see that `dwebp` is now loading the `x86-64-v3` built `libwebp.so` lib from `/usr/lib/glibc-hwcaps/x86-64-v3/libwebp.so.7.1.8`, success! Let's what our performance looks like.
 
@@ -390,10 +395,12 @@ However, there is some light in this tunnel as various forks of zlib having been
 
 Let's just go for it, replacing Solus' `zlib` package with zlib-ng built in compatible mode. It's a bit scary due to how integral zlib is in a typical Linux install, but, how hard could it be?
 
+<!-- cspell:disable-next-line -->
 ## I Zee a Purty lil' Package
 
 Well that was simple. Here's what our zlib-ng `package.yml` recipe looks like.
 
+<!-- spellchecker:disable -->
 <!-- prettier-ignore -->
 ```yaml
 name       : zlib
@@ -422,6 +429,7 @@ install    : |
 check      : |
     %ninja_check
 ```
+<!-- spellchecker:enable -->
 
 After building it, all the files seem to be in the right place and the test suite is passing. Let's just install it overwriting our canonical `zlib` package and hope our system doesn't die... I think the word is YOLO.
 

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

@@ -96,6 +96,7 @@ sudo eopkg ar Solus https://cdn.getsol.us/repo/unstable/eopkg-index.xml.xz
 
 This should yield output similar to:
 
+<!-- spellchecker:disable -->
 ```
 $ sudo eopkg ar Local /var/lib/solbuild/local/eopkg-index.xml.xz
 Repo Local added to system.
@@ -109,6 +110,7 @@ eopkg-index.xml.xz.sha1sum     (40.0  B)100%    765.61 KB/s [00:00:00] [complete
 eopkg-index.xml.xz             (2.1 MB)100%    914.38 KB/s [00:00:01] [complete]
 Package database updated.
 ```
+<!-- spellchecker:enable -->
 
 3. Check that the dependency resolution order is correct so that packages from the local `solbuild` repository are preferred over the upstream Solus repository.
 
@@ -128,6 +130,7 @@ To reset the system to use only packages from the official Solus repository, dis
 
 The output should look similar to:
 
+<!-- spellchecker:disable -->
 ```
 $ sudo eopkg disable-repo Local
 $ sudo eopkg lr
@@ -136,9 +139,11 @@ Local [inactive]
 Solus [active]
    https://cdn.getsol.us/repo/unstable/eopkg-index.xml.xz
 ```
+<!-- spellchecker:enable -->
 
 The "Local" `eopkg` repository can be re-enabled with `sudo eopkg enable-repo Local`.
 
+<!-- spellchecker:disable -->
 ```
 $ sudo eopkg enable-repo Local
 $ sudo eopkg lr
@@ -147,6 +152,7 @@ Local [active]
 Solus [active]
    https://cdn.getsol.us/repo/unstable/eopkg-index.xml.xz
 ```
+<!-- spellchecker:enable -->
 
 ## Closing thoughts
 

docs/packaging/packaging-changes.md

@@ -56,7 +56,7 @@ This page is meant to serve as a changelog of sorts for the Solus packaging envi
 - All packaging actions are now handled by `go-task` rather than `make`.
   - Building a package can be done using `go-task` rather than `make`.
   - Commands are the same: `make local`, for example, is replaced by `go-task local`.
-  - You can see all available commands by either browsing to `Taskfile.yml` in the [`packages` repo](https://github.com/getsolus/packages/blob/main/Taskfile.yml) OR running `go-task -l` somewhere in your updated clone of the packages git monorepo.
+  - You can see all available commands by either browsing to `Taskfile.yml` in the [`packages` repository](https://github.com/getsolus/packages/blob/main/Taskfile.yml) OR running `go-task -l` somewhere in your updated clone of the packages git monorepo.
 - Packagers should install `go-task` on their machines if they have not already.
 - The `Makefile` included with every package is no longer required. Please delete it from a package when updating, and do not include it when making the initial commit of a new package.
 

docs/packaging/prepare-for-packaging.md

@@ -95,9 +95,11 @@ Create your own fork of [getsolus/packages](https://github.com/getsolus/packages
 
 Create a local clone of the package repository you just forked. Here we are using the name `solus-packages` and cloning it into our home directoy. The rest of the documentation will presume this structure. You can choose a different name and path but will have to make sure to replace it in every command that refers to the `solus-packages` directory.
 
+<!-- spellchecker:disable -->
 ```bash
 gh repo clone packages ~/solus-packages
 ```
+<!-- spellchecker:enable -->
 
 ## Initialize git hooks
 

docs/packaging/translation-instructions.md

@@ -17,10 +17,12 @@ Please join our [Matrix rooms](/docs/user/contributing/getting-involved.md#matri
 
 - Strings which include curly braces `{ }` should be translated leaving the curly braces, _and anything inside the braces_, untouched.
 - Examples:
+<!-- spellchecker:disable -->
   - `{DE} Successfully installed, please reboot to continue.` translates to:
   - `{DE} Instalado exitosamente, reinicie para continuar.`
   - `Successfully Installed {}` translates to:
   - `Instalado exitosamente {}`
+<!-- spellchecker:enable -->
 - Do not translate the following strings; leave them untouched:
   - `Packagekit`
   - `XDG_SESSION_DESKTOP`

docs/packaging/update-dev-environment.md

@@ -15,7 +15,7 @@ Always make sure your development environment and system are up to date before b
 
 ## Update Your Fork of the getsolus/packages Repository
 
-If you already have a fork of [getsolus/packages](https://github.com/getsolus/packages) in GitHub, log into GitHub. Make sure you're looking at the `main` branch. Check to see that your fork is up to date with the main repo it was forked from. If your fork indicates it is behind, use the "Sync fork" button to bring it up to date.
+If you already have a fork of [getsolus/packages](https://github.com/getsolus/packages) in GitHub, log into GitHub. Make sure you're looking at the `main` branch. Check to see that your fork is up to date with the main repository it was forked from. If your fork indicates it is behind, use the "Sync fork" button to bring it up to date.
 
 ## Update Your Local Clone of Your Fork
 

docs/packaging/updating-an-existing-package.md

@@ -139,7 +139,7 @@ _Important_: Do not include issue numbers in changelogs. This will incorrectly l
 - #123 fixed a thing
 ```
 
-If you want to intentionally link to another issue in this repository, the right way is to use our repo name. Ex:
+If you want to intentionally link to another issue in this repository, the right way is to use our repository name:
 
 ```
 Fixes getsolus/packages#issuenumber