Merge branch 'master' into 'master'

Spelling and trailing whitespace fixes

See merge request !36

LICENSE

@@ -49,7 +49,7 @@ exhaustive, and do not form part of our licenses.
      such as asking that all changes be marked or described.
      Although not required by our licenses, you are encouraged to
      respect those requests where reasonable. More_considerations
-     for the public: 
+     for the public:
 	wiki.creativecommons.org/Considerations_for_licensees
 
 =======================================================================

rfcs/0002-march.rst

@@ -50,7 +50,7 @@ These microarchitecture became available in GCC version 11 (unreleased)
 and LLVM version 12 (unreleased), and are supported in glibc-2.33 and
 binutils-2.36.
 
-You can see what architecture is support by your CPU by running:
+You can see what architecture is supported by your CPU by running:
 
 ``/lib/ld-linux-x86-64.so.2 --help``
 ::
@@ -60,7 +60,7 @@ You can see what architecture is support by your CPU by running:
    x86-64-v3 (supported, searched)
    x86-64-v2 (supported, searched)
 
-RHEL9 will use use x86-64-v2 as its baseline.
+RHEL9 will use x86-64-v2 as its baseline.
 
 This RFC is proposing adding an x86_64_v3 port in Arch Linux. Assuming
 SSE4 and AVX2 (and others) while compiling will provide greater
@@ -85,7 +85,7 @@ Some benchmarks performed rebuilding packages with and without the above
 CFLAGS additions against repositories from 2021-03-12:
 
 **firefox-86.0.1-1**: benchmarking on Basemark Web 3.0
-(https://web.basemark.com/) seven times (alternativing installs) gave a
+(https://web.basemark.com/) seven times (alternating installs) gave a
 median score of 514.68 for v1 and 565.42 for v3, representing a 9.9%
 improvement. Note, this was rebuilding only firefox itself, and none of
 its dependencies, thus representing a lower bound.
@@ -97,7 +97,7 @@ keys of different sizes.
 Benchmarks posted on the arch-general mailing list [1] show a median
 performance benefit of *-march=haswell* (roughly x86_64-v3) of around 10%.
 
-[1] https://lists.archlinux.org/pipermail/arch-general/2021-March/048739.html 
+[1] https://lists.archlinux.org/pipermail/arch-general/2021-March/048739.html
 
 Specification
 -------------
@@ -108,7 +108,7 @@ includes the following:
 
  CARCH="x86_64_v3"
  CHOST="x86_64-pc-linux-gnu"
- 
+
  CFLAGS="-march=x86-64-v3 -mtune=generic ...
  CXXFLAGS="$CFLAGS"
 

rfcs/0004-lto-by-default.rst

@@ -21,7 +21,7 @@ Motivation
 ----------
 
 Arch packages are super slow, and they need to be super fast! One way to
-improve optimisation is through LTO. 
+improve optimisation is through LTO.
 
 LTO gives GCC the capability of dumping its internal representation (GIMPLE)
 to disk, so that all the different compilation units that make up a single
@@ -31,7 +31,7 @@ everything that is visible at link time). Clang does similar LTO, but dumps
 its internal representation as LLVM byte-code.
 
 When SUSE implemented LTO, they found the overall size of installed binaries
-decreased by 5%. The benefits are particulary beneficial in large C++
+decreased by 5%. The benefits are particularly beneficial in large C++
 programs.
 
 Some useful reading:
@@ -57,10 +57,10 @@ reason, can add
 Additionally, `makepkg` will have additions to strip the LTO bytecodes from
 any installed .o/.a files. [2]
 
-RedHat found some issues using -flto with old configure scripts [3]. These
+Red Hat found some issues using -flto with old configure scripts [3]. These
 packages can be detected by running configure with and without LTO enabled
 and comparing the generated `config.h` files. We can provide a simple sed
-script as a makepkg-template in devtools to fix these packages, and do a 
+script as a makepkg-template in devtools to fix these packages, and do a
 scan of the repos to automatically detect packages that need the fix added
 to their PKGBUILD.
 
@@ -81,7 +81,7 @@ added to their PKGBUILD.
 There is some increased overhead when linking.
 
 LTO can make debugging more difficult, with inlining of function occurring
-across build units. In addtion, the use of LTO can cause the memory usage of
+across build units. In addition, the use of LTO can cause the memory usage of
 GBD to markedly increase [4]. This can be worked around by debugging in a
 non-LTO build if needed (and assuming that LTO is not the cause of the issue.
 

rfcs/0006-code-of-conduct.rst

@@ -42,7 +42,7 @@ behavior within a community.
 Historically, a Code of Conduct document for Arch Linux has been written,
 extended and maintained by several staff members `in the Arch Wiki
 <https://wiki.archlinux.org/index.php?oldid=648541&date-range-to=2021-01-09&action=history>`_.
-This document, although widely used througout the distribution on e.g. the
+This document, although widely used throughout the distribution on e.g. the
 forums, the mailing lists, the bug tracker, official IRC channels and the wiki
 has not been officially ratified.
 

rfcs/0007-rename-trusted-user-role.rst

@@ -124,7 +124,7 @@ a larger, more meaningful re-design as so ("->" is to be read as "becomes") [6]_
 - AUR handling, especially PRQ -> Trusted Users
 
 Finally, a two-round-system vote was held at this RFC's MR discussion thread
-to chose the final naming scheme proposed here. It consisted initially of all
+to choose the final naming scheme proposed here. It consisted initially of all
 popular labels and then kept only the two most popular options in the final
 round to achieve majority.
 

rfcs/0017-increase-fortification-level.rst

@@ -30,11 +30,11 @@ with level 2 to 47% with level 3. Similarly, sudo went from 1.3% to 49.57%.
 Specification
 -------------
 
-CFLAGS in the distribtion packaging makepkg.conf would change from 
+CFLAGS in the distribution packaging makepkg.conf would change from
 `-D_FORTIFY_SOURCE=2` to `-D_FORTIFY_SOURCE=3`.
 
 Some applications use `malloc_usable_size` (despite the glibc manual stating
-it is for diagnostic purposes only).  This is currently incompatible with 
+it is for diagnostic purposes only).  This is currently incompatible with
 `_FORTIFY_SOURCE=3`, so these packages will need to continue using level 2 by
 modifying `C{,XX}FLAGS` in the PKGBUILD.  A TODO list will be created for all
 such packages on adoption of this proposal.

rfcs/0019-aur-moderator-role.rst

@@ -20,7 +20,7 @@ Specification
 Similar to forum moderators, `AUR Moderators` review requests on the AUR and accept or close them.
 They must not handle their own requests.
 Furthermore, they are allowed to suspend accounts that violate the AUR contribution guidelines.
-With a succesful application, they are onboarded as Arch Linux staff.
+With a successful application, they are onboarded as Arch Linux staff.
 
 At the moment AUR web defines the following user types
 
@@ -29,7 +29,7 @@ At the moment AUR web defines the following user types
 * `Developer`
 * `Package Maintainer & Developer`
 
-After the implemention of this RFC the user types will be changed to
+After the implementation of this RFC the user types will be changed to
 
 * `Normal User`
 * `AUR Moderator`
@@ -48,9 +48,9 @@ They can seek for sponsorship support by contacting staff members directly.
 Once a sponsor is found, the nominee writes an application email signed with either the SSH or GPG key of their AUR account to the aur-general mailing list.
 After the sponsor confirmed their sponsorship, a discussion period of seven days starts.
 Subsequently, the `AUR Moderators` cast their vote.
-For a succesful application, the nominee has to gain a simple majority
+For a successful application, the nominee has to gain a simple majority
 of all votes.
-The responsibility of the the sponsor is to guide the rookie through the duties of an `AUR Moderator` while regularly checking in on their work during their first month.
+The responsibility of the sponsor is to guide the rookie through the duties of an `AUR Moderator` while regularly checking in on their work during their first month.
 In general, the responsibility of all `AUR Moderators` and the applicant is to be up to date on the latest AUR submission guidelines [1] and Arch package guidelines [2].
 Detailed guidelines for the new role of `AUR Moderators` will be worked out by the initial
 group of `AUR Moderators` based on this RFC and related existing documents.
@@ -68,7 +68,7 @@ None
 Alternatives Considered
 -----------------------
 
-Package Maintainers should take care of the AUR more regularly. One possiblity is to name a group of up to five Package Maintainers who will focus on AUR requests for one week. A list with names is published as a markdown file every month.
+Package Maintainers should take care of the AUR more regularly. One possibility is to name a group of up to five Package Maintainers who will focus on AUR requests for one week. A list with names is published as a markdown file every month.
 
 [1] https://wiki.archlinux.org/title/AUR_submission_guidelines
 [2] https://wiki.archlinux.org/title/Arch_package_guidelines

rfcs/0020-sources-for-python-packaging.rst

@@ -17,7 +17,7 @@ Historically, Arch Linux has relied upon `source distribution`_ (sdist) tarballs
 
 However, over the years the use of the platform became more and more burdensome for packagers:
 
-- stable, predictable download links were no longer publicly advertized (instead download links with hashes are advertized over the web UI)
+- stable, predictable download links were no longer publicly advertised (instead download links with hashes are advertised over the web UI)
 - the availability of OpenPGP signatures for sources were deemed to obscurity by not showing them in the download section
 - eventually existing OpenPGP signatures were no longer available since they were deprecated in May 2023 (https://blog.pypi.org/posts/2023-05-23-removing-pgp/)
 

rfcs/0026-fno-omit-frame-pointer.rst

@@ -147,22 +147,22 @@ Unwinding
 How does the profiler get the list of function names? There are two parts of it:
 
 1. Unwinding the stack - getting a list of virtual addresses pointing to the
-executable code 
+executable code
 2. Symbolization - translating virtual addresses into human-readable
 information, like function name, inlined functions at the address, or file name
-and line number. 
+and line number.
 
 Unwinding is what we're interested in for the purpose of this proposal. The
 important things are:
 
-- Data on stack is split into frames, each frame belonging to one function. 
+- Data on stack is split into frames, each frame belonging to one function.
 - Right before each function call, the return address is put on the stack. This
   is the instruction address in the caller to which we will eventually return —
-  and that's what we care about. 
+  and that's what we care about.
 - One register, called the "frame pointer" or "base pointer" register (RBP), is
   traditionally used to point to the beginning of the current frame. Every
   function should back up RBP onto the stack and set it properly at the very
-  beginning. 
+  beginning.
 
 The “frame pointer” part is achieved by adding push %rbp, mov %rsp,%rbp to the
 beginning of every function and by adding pop %rbp before returning. Using this
@@ -226,7 +226,7 @@ Potential performance impact
 
 - From https://hal.inria.fr/hal-02297690/document, a paper on DWARF unwinding,
   we find that Google compiles all its internal critical software with frame
-  pointers to ensure fast and reliable backtraces. 
+  pointers to ensure fast and reliable backtraces.
 - Given that the kernel uses the ORC debuginfo format and this works well,
   we'll keep compiling the kernel without frame pointers since there's no
   benefits for profiling or debugging to be gained by compiling the kernel with
@@ -246,7 +246,7 @@ Benchmarking of the performance impact
 As part of the change proposal for enabling frame pointers on Fedora by default,
 we compared a number of benchmarks on a Fedora 37 system where every package is
 built with frame pointers against the same benchmarks on a regular Fedora 37
-system. The source code for the benchmarks can be found in the 
+system. The source code for the benchmarks can be found in the
 `fpbench repository on GitHub <https://github.com/DaanDeMeyer/fpbench>`_. We used
 copr to build the packages required to run the benchmarks (and their
 dependencies) with frame pointers. Then, using mkosi, we build one Fedora 37
@@ -258,11 +258,11 @@ repository.
 
 Summarizing the results:
 
-- Compiling the kernel with GCC is 2.4% slower with frame pointers 
-- Running Blender to render a frame is 2% slower on our specific testcase 
-- openssl/botan/zstd do not seem to be affected significantly when built with frame pointers 
+- Compiling the kernel with GCC is 2.4% slower with frame pointers
+- Running Blender to render a frame is 2% slower on our specific testcase
+- openssl/botan/zstd do not seem to be affected significantly when built with frame pointers
 - The impact on CPython benchmarks can be anywhere from 1-10% depending on the specific benchmark
-- Redis benchmarks do not seem to be significantly impacted when built with frame pointers 
+- Redis benchmarks do not seem to be significantly impacted when built with frame pointers
 
 Aside from the Python performance benchmarks, the impact of building with frame
 pointers is limited on the benchmarks we performed. Our findings on the impact
@@ -279,7 +279,7 @@ pointer:
   the beginning of the frame without the frame pointer, which means we can walk
   the stack exactly as before. The problem is that we need to unwind the stack
   in kernel space which isn't implemented in the kernel. Given that the kernel
-  implemented it's own format (ORC) instead of using DWARF, it's unlikely that
+  implemented its own format (ORC) instead of using DWARF, it's unlikely that
   we'll see a DWARF unwinder in the kernel any time soon. The perf tool allows
   you to use the DWARF data with --call-graph=dwarf, but this means that it
   copies the full stack on every event and unwinds in user space. This has very

rfcs/0032-arch-linux-ports.rst

@@ -54,7 +54,7 @@ Previous RFCs have aimed at a direct integration for new architectures. This app
 Instead, this RFC outlines a data driven process through which we can estimate how much extra maintenance effort is required, how mature the architecture is, and how much interest there is for it in the community.
 We acknowledge the `Debian Ports project`_ as a role model for this RFC, which has been covering a similar use case for many years.
 
-In the following sections we elaborate on specific technological changes and procedures that are required for 
+In the following sections we elaborate on specific technological changes and procedures that are required for
 - introducing a new port
 - maintaining a port until it is either promoted to an official architecture or dropped
 - providing and using source repositories of packages
@@ -195,7 +195,7 @@ Port repositories are distributed alongside the official Arch Linux repositories
 Installation media
 """"""""""""""""""
 
-Ports should create generic installation media, which works on a broad set of devices. At the time of writing, this can be achieved using `archiso`_'s releng profile as a base. 
+Ports should create generic installation media, which works on a broad set of devices. At the time of writing, this can be achieved using `archiso`_'s releng profile as a base.
 This does not necessitate covering installation scenarios for special purpose hardware (e.g. those only able to boot from an SD card), as for those special purpose bootstrap artifacts need to be created.
 
 Port installation media is distributed alongside the official Arch Linux binary artifacts in a namespaced directory structure: