fixed linter warnings

This commit is contained in:
qubedmaiska 2025-09-09 12:05:31 -04:00
parent e93ddb3796
commit 1be6e5f9b9
No known key found for this signature in database
GPG key ID: 204BCE0FD52C0501
36 changed files with 107 additions and 229 deletions

View file

@ -4,7 +4,7 @@ Qubes builder details
.. warning::
**Note:** This information concerns the old Qubes builder (v1). It supports only building Qubes 4.1 or earlier.The build process has been completely rewritten in `qubes-builder v2 <https://github.com/QubesOS/qubes-builderv2/>`__ . This can be used for building Qubes R4.1 and later, and all related components.
Components Makefile.builder file

View file

@ -57,8 +57,8 @@ Timeline
^^^^^^^^
.. list-table::
:widths: 15 15
.. list-table::
:widths: 15 15
:align: center
:header-rows: 1
@ -70,15 +70,14 @@ Timeline
- Update & extend how-to guides
* - December
- Final project evaluation and case study
Project budget
^^^^^^^^^^^^^^
.. list-table::
:widths: 32 32
.. list-table::
:widths: 32 32
:align: center
:header-rows: 1
@ -88,7 +87,6 @@ Project budget
- $12,000
* - TOTAL
- $12,000
Additional information

View file

@ -22,7 +22,7 @@ be downloaded from `doc.qubes-os.org <https://doc.qubes-os.org/en/latest/>`__:
|epub-pdf|
..
TODO screenshots with main branch instead of rst when rst merged in main
TODO screenshots with main branch instead of rst when rst merged in main
TODO add draft pull request screenshot
The documentation is a volunteer community effort. People like you are
@ -74,8 +74,7 @@ button to edit the file (if you are already logged in in).
If you are not logged in you can click on :guilabel:`Sign In`
and youll be prompted to sign in with your GitHub username and password.
You can also create a free account from
here.
You can also create a free account from here.
|github-sign-in|
@ -174,7 +173,7 @@ Tips & Tricks
$ git merge upstream/main
Keep your pull requests limited to a single issue, pull requests should be as atomic as possible.
Keep your pull requests limited to a single issue, pull requests should be as atomic as possible.
.. _edit_doc_index:

View file

@ -123,8 +123,8 @@ The main `qubesos.github.io <https://github.com/QubesOS/qubesos.github.io>`__ co
└── pages # ← Standalone pages (donate, team, about, etc.)
└── *.md/.html # each file becomes a page at /<filename>/
How to edit the website
-----------------------
Cheatsheet
----------
.. list-table::
:header-rows: 1
@ -139,7 +139,7 @@ How to edit the website
- Update the key/value pair, then rebuild.
* - Modify the look of all pages
- ``_layouts/*.html`` and/or ``_sass/*.scss``
- Edit the HTML skeleton or SASS variables, then run ``jekyll serve`` to preview.
- Edit the HTML skeleton or SASS variables, then run preview.
* - Insert a reusable component (e.g., a callout box)
- ``_includes/*.html``
- Create the snippet, then reference it with ``{% include snippet.html %}`` in any page or post.

View file

@ -8,7 +8,7 @@ posts related to Qubes OS.
Secure Software Development
===========================
- `Security challenges for the Qubes build process <https://blog.invisiblethings.org/2016/05/30/build-security.html>`__ by Joanna Rutkowska, May 2016
- `Security challenges for the Qubes build process <https://blog.invisiblethings.org/2016/05/30/build-security.html>`__ by Joanna Rutkowska, May 2016
Towards Trusted Hardware

View file

@ -574,7 +574,7 @@ Core documentation resides in the `Qubes OS Projects official repositories <h
The main difference between **core** (or **official**) and **external** (or **community** or **unofficial**) documentation is whether it documents software that is officially written and maintained by the Qubes OS Project. The purpose of this distinction is to keep the core docs maintainable and high-quality by limiting them to the software output by the Qubes OS Project. In other words, we take responsibility for documenting all of the software we put out into the world, but it doesnt make sense for us to take on the responsibility of documenting or maintaining documentation for anything else. For example, Qubes OS may use a popular Linux distribution for an official :doc:`TemplateVM </user/templates/templates>`. However, it would not make sense for a comparatively small project like ours, with modest funding and a lean workforce, to attempt to document software belonging to a large, richly-funded project with an army of paid and volunteer contributors, especially when they probably already have documentation of their own. This is particularly true when it comes to Linux in general. Although many users who are new to Qubes are also new to Linux, it makes absolutely no sense for our comparatively tiny project to try to document Linux in general when there is already a plethora of documentation out there.
Many contributors do not realize that there is a significant amount of work involved in *maintaining* documentation after it has been written. They may wish to write documentation and submit it to the core docs, but they see only their own writing process and fail to consider that it will have to be kept up-to-date and consistent with the rest of the docs for years afterward. Submissions to the core docs also have to :ref:`undergo a review process <developer/general/how-to-edit-the-rst-documentation:security>`__ to ensure accuracy before being merged, which takes up valuable time from the team. We aim to maintain high quality standards for the core docs (style and mechanics, formatting), which also takes up a lot of time. If the documentation involves anything external to the Qubes OS Project (such as a website, platform, program, protocol, framework, practice, or even a reference to a version number), the documentation is likely to become outdated when that external thing changes. Its also important to periodically review and update this documentation, especially when a new Qubes release comes out. Periodically, there may be technical or policy changes that affect all the core documentation. The more documentation there is relative to maintainers, the harder all of this will be. Since there are many more people who are willing to write documentation than to maintain it, these individually small incremental additions amount to a significant maintenance burden for the project.
Many contributors do not realize that there is a significant amount of work involved in *maintaining* documentation after it has been written. They may wish to write documentation and submit it to the core docs, but they see only their own writing process and fail to consider that it will have to be kept up-to-date and consistent with the rest of the docs for years afterward. Submissions to the core docs also have to :ref:`undergo a review process <developer/general/how-to-edit-the-rst-documentation:security>` to ensure accuracy before being merged, which takes up valuable time from the team. We aim to maintain high quality standards for the core docs (style and mechanics, formatting), which also takes up a lot of time. If the documentation involves anything external to the Qubes OS Project (such as a website, platform, program, protocol, framework, practice, or even a reference to a version number), the documentation is likely to become outdated when that external thing changes. Its also important to periodically review and update this documentation, especially when a new Qubes release comes out. Periodically, there may be technical or policy changes that affect all the core documentation. The more documentation there is relative to maintainers, the harder all of this will be. Since there are many more people who are willing to write documentation than to maintain it, these individually small incremental additions amount to a significant maintenance burden for the project.
On the positive side, we consider the existence of community documentation to be a sign of a healthy ecosystem, and this is quite common in the software world. The community is better positioned to write and maintain documentation that applies, combines, and simplifies the official documentation, e.g., tutorials that explain how to install and use various programs in Qubes, how to create custom VM setups, and introductory tutorials that teach basic Linux concepts and commands in the context of Qubes. In addition, just because the Qubes OS Project has officially written and maintains some flexible framework, such as ``qrexec``, it does not make sense to include every tutorial that says “heres how to do something cool with ``qrexec`` in the core docs. Such tutorials generally also belong in the community documentation.

View file

@ -3,8 +3,8 @@ Qubes R3.0 release schedule
===========================
.. list-table::
:widths: 11 11
.. list-table::
:widths: 11 11
:align: center
:header-rows: 1
@ -16,5 +16,4 @@ Qubes R3.0 release schedule
- 3.0-rc3 release
* - 1 Oct 2015
- 3.0 release

View file

@ -5,8 +5,8 @@ Qubes R3.1 release schedule
This schedule is based on :ref:`Version Scheme <developer/releases/version-scheme:release schedule>`.
.. list-table::
:widths: 38 38
.. list-table::
:widths: 38 38
:align: center
:header-rows: 1
@ -24,5 +24,4 @@ This schedule is based on :ref:`Version Scheme <developer/releases/version-schem
- current-testing freeze before 3.1-rc3
* - :strike:`16 Feb 2016` 23 Feb 2016
- 3.1-rc3 release

View file

@ -5,8 +5,8 @@ Qubes R3.2 release schedule
This schedule is based on :ref:`Version Scheme <developer/releases/version-scheme:release schedule>`.
.. list-table::
:widths: 38 38
.. list-table::
:widths: 38 38
:align: center
:header-rows: 1
@ -28,5 +28,3 @@ This schedule is based on :ref:`Version Scheme <developer/releases/version-schem
- 3.2-rc3 release
* - 29 Sep 2016
- 3.2 release

View file

@ -5,8 +5,8 @@ Qubes R4.0 release schedule
This schedule is based on :ref:`Version Scheme <developer/releases/version-scheme:release schedule>`.
.. list-table::
:widths: 88 88
.. list-table::
:widths: 88 88
:align: center
:header-rows: 1
@ -40,5 +40,4 @@ This schedule is based on :ref:`Version Scheme <developer/releases/version-schem
- decide whether 4.0-rc5 is the final 4.0
* - 28 Mar 2018
- final 4.0 release

View file

@ -5,8 +5,8 @@ Qubes R4.1 release schedule
The table below is based on our :ref:`release schedule policy <developer/releases/version-scheme:release schedule>`.
.. list-table::
:widths: 10 10
.. list-table::
:widths: 10 10
:align: center
:header-rows: 1
@ -34,5 +34,4 @@ The table below is based on our :ref:`release schedule policy <developer/release
- decide whether 4.1.0-rc4 is the final 4.1
* - 2022-02-04
- final 4.1.0 release

View file

@ -7,8 +7,8 @@ Qubes R4.2 release schedule
The table below is based on our :ref:`release schedule policy <developer/releases/version-scheme:release schedule>`.
.. list-table::
:widths: 10 10
.. list-table::
:widths: 10 10
:align: center
:header-rows: 1
@ -22,5 +22,4 @@ The table below is based on our :ref:`release schedule policy <developer/release
- 4.2.0-rc3 release
* - 2023-10-13
- 4.2.0-rc4 release

View file

@ -7,8 +7,8 @@ Qubes R4.3 release schedule
The table below is based on our :ref:`release schedule policy <developer/releases/version-scheme:release schedule>`.
.. list-table::
:widths: 10 10
.. list-table::
:widths: 10 10
:align: center
:header-rows: 1
@ -16,5 +16,4 @@ The table below is based on our :ref:`release schedule policy <developer/release
- Stage
* - TBD
- 4.3.0-rc1 release

View file

@ -39,8 +39,8 @@ Each release candidate period is as follows: For the first two weeks, we accept
The next RC is released five weeks after the former. All packages are published in the ``current`` repository, and the cycle starts over. There should always be at least one release candidate before the final release.
.. list-table::
:widths: 26 26
.. list-table::
:widths: 26 26
:align: center
:header-rows: 1
@ -52,7 +52,6 @@ The next RC is released five weeks after the former. All packages are published
- two weeks
* - ``current-testing`` freeze
- one week
Starting with the second cycle (that is, after ``-rc1``), two weeks into the cycle (after the primary bug-reporting period), we decide whether there should be another RC. If, based on the bugs that have been reported, we decide that the latest RC will be designated as the stable release, then we decide on its release date, which should be no more than one week later.
@ -104,4 +103,4 @@ Check installed version
If you want to know which version you are running, for example to report an issue, you can either check in the Qubes Manager menu under ``About > Qubes OS`` or in the file ``/etc/qubes-release`` in dom0. For the latter you can use a command like ``cat /etc/qubes-release`` in a dom0 terminal.
.. |Release cycle| image:: /attachment/doc/release-cycle.png

View file

@ -75,7 +75,7 @@ it easy to set the policy using current mechanism.
- `-`
- `-`
- ``<class>\n``
-
-
* - ``admin.vm.List``
- ``dom0|<vm>``
- `-`
@ -132,7 +132,7 @@ it easy to set the policy using current mechanism.
- `-`
- ``<label-index>``
-
* - ``admin.label.Remove``
* - ``admin.label.Remove``
- ``dom0``
- label
- `-`
@ -190,10 +190,10 @@ it easy to set the policy using current mechanism.
* - ``admin.vm.property.List``
- vm
- `-`
- `-`
- `-`
- ``<property>\n``
-
* - ``admin.vm.property.Get``
* - ``admin.vm.property.Get``
- vm
- property
- `-`
@ -227,7 +227,7 @@ it easy to set the policy using current mechanism.
* - ``admin.vm.property.Reset``
- vm
- property
- `-`
- `-`
- `-`
-
* - ``admin.vm.property.Set``
@ -266,7 +266,7 @@ it easy to set the policy using current mechanism.
- `-`
- value
-
* - ``admin.vm.feature.CheckWithTemplateAndAdminVM``
* - ``admin.vm.feature.CheckWithTemplateAndAdminVM``
- vm
- feature
- `-`
@ -301,7 +301,7 @@ it easy to set the policy using current mechanism.
- `-`
- `-`
- ``<tag>\n``
-
-
* - ``admin.vm.tag.Get``
- vm
- tag
@ -322,7 +322,7 @@ it easy to set the policy using current mechanism.
-
* - ``admin.vm.firewall.Get``
- vm
- `-`
- `-`
- `-`
- ``<rule>\n``
- rules syntax as in :ref:`firewall interface <developer/debugging/vm-interface:firewall rules in 4.x>` with addition of ``expire=`` and ``comment=`` options; ``comment=`` (if present) must be the last option
@ -364,11 +364,11 @@ it easy to set the policy using current mechanism.
- device
- `-`
- `-`
- ``device`` is in form ``<backend-name>+<device-ident>``
- ``device`` is in form ``<backend-name>+<device-ident>``
* - ``admin.vm.device.<class>.Set.required``
- vm
- device
- ``True|False``
- ``True|False``
- `-`
- ``device`` is in form ``<backend-name>+<device-ident>``
* - ``admin.vm.deviceclass.List``
@ -434,7 +434,7 @@ it easy to set the policy using current mechanism.
- `-`
- `-`
-
* - ``admin.pool.volume.List``
* - ``admin.pool.volume.List``
- ``dom0``
- pool
- `-`
@ -488,12 +488,12 @@ it easy to set the policy using current mechanism.
- vid
- token, to be used in ``admin.pool.volume.CloneTo``
- | obtain a token to copy volume ``vid`` in ``pool``;
| the token is one time use only, it's invalidated by ``admin.pool.volume.CloneTo``, even if the operation fails
| the token is one time use only, it's invalidated by ``admin.pool.volume.CloneTo``, even if the operation fails
* - ``admin.pool.volume.CloneTo``
- ``dom0``
- pool
- ``<vid> <token>``
- `-`
- `-`
- copy volume pointed by a token to volume ``vid`` in ``pool``
* - ``admin.vm.volume.List``
- vm
@ -503,7 +503,7 @@ it easy to set the policy using current mechanism.
- ``<volume>`` is per-VM volume name (``root``, ``private``, etc), ``<vid>`` is pool-unique volume id
* - ``admin.vm.volume.Info``
- vm
- volume
- volume
- `-`
- ``<property>=<value>\n``
-
@ -614,7 +614,7 @@ it easy to set the policy using current mechanism.
- ``dom0``
- config id
- `-`
- backup info
- backup info
- info what would be included in the backup
* - ``admin.backup.Cancel``
- ``dom0``

View file

@ -112,4 +112,5 @@ Notes
Conventional means of viewing the memory available to Qubes will give incorrect values for ``dom0`` since commands such as ``free`` will only show the memory allocated for ``dom0``. Run the ``xl info`` command in ``dom0`` and read the ``total_memory`` field to see the total memory available to Qubes.
.. |checkmark| image:: /attachment/doc/checkmark.png
.. |redx| image:: /attachment/doc/red_x.png
.. |redx| image:: /attachment/doc/red_x.png

View file

@ -68,7 +68,4 @@ And all these components are “glued together” by the Qubes Core Stack.
This diagram illustrates the location of all these components in the overall system architecture. Unlike the other Qubes architecture diagram above, this one takes an app-qube-centric approach.
.. |qubes-schema-v2.png| image:: /attachment/doc/qubes-schema-v2.png
.. |Qubes system components| image:: /attachment/doc/qubes-components.png