From: Thomas Huth <thuth@redhat.com>

Found with the codespell utility.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 docs/formatcaps.rst    | 2 +-
 docs/formatdomain.rst  | 4 ++--
 docs/glib-adoption.rst | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst
index da6b215780..7e525487e7 100644
--- a/docs/formatcaps.rst
+++ b/docs/formatcaps.rst
@@ -39,7 +39,7 @@ The ``<host/>`` element consists of the following child elements:
    The host CPU architecture and features.
 
    Note that, while this element contains a ``topology`` sub-element,
-   the information contained therein is farily high-level and likely
+   the information contained therein is fairly high-level and likely
    not very useful when it comes to optimizing guest vCPU placement.
    Look into the ``topology`` *element*, described below, for more
    detailed information.
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index c1876ad467..4bc6a318f5 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -3468,7 +3468,7 @@ paravirtualized driver is specified via the ``disk`` element.
       automatically distributed among the configured iothreads.
 
       Optionally the ``iothread`` element can have multiple ``queue``
-      subelements with mandatory ``id`` atribute specifying that the iothread
+      subelements with mandatory ``id`` attribute specifying that the iothread
       should be used to handle given virt queue. If queue mapping is present
       the ``queues`` attribute of  ``driver`` must be configured and all
       configured virt queues must be included in the mapping. The
@@ -8423,7 +8423,7 @@ Example: usage of external TPM emulator :since:`Since 9.0.0`
 
    This element does not work with the ``passthrough`` backend.
 
-   When specified, it is the user's responsability to prevent files from being
+   When specified, it is the user's responsibility to prevent files from being
    used by multiple VMs or emulators (swtpm will also use advisory locking). If
    not specified, the storage configuration is left to libvirt discretion.
 
diff --git a/docs/glib-adoption.rst b/docs/glib-adoption.rst
index f969ac80a1..c2cec80eea 100644
--- a/docs/glib-adoption.rst
+++ b/docs/glib-adoption.rst
@@ -32,7 +32,7 @@ Array operations
 
    https://developer.gnome.org/glib/stable/glib-Arrays.html
 
-   Instead of using plain C arrays, it is preferrable to use one of
+   Instead of using plain C arrays, it is preferable to use one of
    the GLib types, ``GArray``, ``GPtrArray`` or ``GByteArray``.
    These all use a struct to track the array memory and size
    together and efficiently resize.
-- 
2.48.1

On Mon, Mar 17, 2025 at 11:41:20AM +0100, Thomas Huth via Devel wrote:
>From: Thomas Huth <thuth@redhat.com>
>
>Found with the codespell utility.
>

If you did that typo in the subject on purpose, then hat's off to you.
Anyway, before pushing it, s/types/typos/ please

Reviewed-by: Martin Kletzander <mkletzan@redhat.com>


>Signed-off-by: Thomas Huth <thuth@redhat.com>
>---
> docs/formatcaps.rst    | 2 +-
> docs/formatdomain.rst  | 4 ++--
> docs/glib-adoption.rst | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst
>index da6b215780..7e525487e7 100644
>--- a/docs/formatcaps.rst
>+++ b/docs/formatcaps.rst
>@@ -39,7 +39,7 @@ The ``<host/>`` element consists of the following child elements:
>    The host CPU architecture and features.
>
>    Note that, while this element contains a ``topology`` sub-element,
>-   the information contained therein is farily high-level and likely
>+   the information contained therein is fairly high-level and likely
>    not very useful when it comes to optimizing guest vCPU placement.
>    Look into the ``topology`` *element*, described below, for more
>    detailed information.
>diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
>index c1876ad467..4bc6a318f5 100644
>--- a/docs/formatdomain.rst
>+++ b/docs/formatdomain.rst
>@@ -3468,7 +3468,7 @@ paravirtualized driver is specified via the ``disk`` element.
>       automatically distributed among the configured iothreads.
>
>       Optionally the ``iothread`` element can have multiple ``queue``
>-      subelements with mandatory ``id`` atribute specifying that the iothread
>+      subelements with mandatory ``id`` attribute specifying that the iothread
>       should be used to handle given virt queue. If queue mapping is present
>       the ``queues`` attribute of  ``driver`` must be configured and all
>       configured virt queues must be included in the mapping. The
>@@ -8423,7 +8423,7 @@ Example: usage of external TPM emulator :since:`Since 9.0.0`
>
>    This element does not work with the ``passthrough`` backend.
>
>-   When specified, it is the user's responsability to prevent files from being
>+   When specified, it is the user's responsibility to prevent files from being
>    used by multiple VMs or emulators (swtpm will also use advisory locking). If
>    not specified, the storage configuration is left to libvirt discretion.
>
>diff --git a/docs/glib-adoption.rst b/docs/glib-adoption.rst
>index f969ac80a1..c2cec80eea 100644
>--- a/docs/glib-adoption.rst
>+++ b/docs/glib-adoption.rst
>@@ -32,7 +32,7 @@ Array operations
>
>    https://developer.gnome.org/glib/stable/glib-Arrays.html
>
>-   Instead of using plain C arrays, it is preferrable to use one of
>+   Instead of using plain C arrays, it is preferable to use one of
>    the GLib types, ``GArray``, ``GPtrArray`` or ``GByteArray``.
>    These all use a struct to track the array memory and size
>    together and efficiently resize.
>-- 
>2.48.1
>

On 17/03/2025 12.29, Martin Kletzander wrote:
> On Mon, Mar 17, 2025 at 11:41:20AM +0100, Thomas Huth via Devel wrote:
>> From: Thomas Huth <thuth@redhat.com>
>>
>> Found with the codespell utility.
>>
> 
> If you did that typo in the subject on purpose, then hat's off to you.
> Anyway, before pushing it, s/types/typos/ please

LOL, that was not on purpose, thanks for catching it!

  Thomas

On 3/17/25 12:29, Martin Kletzander via Devel wrote:
> On Mon, Mar 17, 2025 at 11:41:20AM +0100, Thomas Huth via Devel wrote:
>> From: Thomas Huth <thuth@redhat.com>
>>
>> Found with the codespell utility.
>>
> 
> If you did that typo in the subject on purpose, then hat's off to you.
> Anyway, before pushing it, s/types/typos/ please
> 

I don't think Thomas has commit access to our repo, so I've merged this.

> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>

Michal