Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-08-08 14:42:31 -04:00
Code Issues Projects Releases Packages Wiki Activity

Correct code-block lexers

Browse source 
Changing `bash` lexer to `console` because it is appropriate most of
the time. Then after a manual review, some lexer have been changed.

I used `text` each time I was unsure, and for prompt outputs.

The page `/developer/building/qubes-iso-building.rst` still need to be
reviewed (look for lines starting with `$ #`).

I'm not sure about the Windows pages, should we use
[doscon](https://pygments.org/docs/lexers/#pygments.lexers.shell.MSDOSSessionLexer)
or `powershell`?

Is there an appropriate lexer for `guid.conf` content?

**Statistics - Before**
    870 bash
      9 python
      9 c
      2 yaml

**Statistics - After**
    684 console
    111 text
     44 bash
     16 yaml
      9 systemd
      9 c
      8 python
      4 ini
      4 doscon
      2 markdown
      2 desktop
      1 xorg.conf
      1 xml+jinja
      1 xml
      1 kconfig
      1 html

This suggests that the default lexer should be `console`.
This commit is contained in:
parulin 2025-07-30 09:43:09 -04:00
parent b53776e1eb
commit ba399ac488
No known key found for this signature in database
GPG key ID: BC3830B42F4BF1F5
98 changed files with 1022 additions and 1029 deletions
Download patch file Download diff file Expand all files Collapse all files

26
developer/debugging/automated-tests.rst
View file

@ -46,11 +46,11 @@ You can use ``python3 -m qubes.tests.run -h`` to get usage information:
[--do-not-clean] [--do-clean] [--loglevel LEVEL]
[--logfile FILE] [--syslog] [--no-syslog] [--kmsg] [--no-kmsg]
[TESTNAME [TESTNAME ...]]
positional arguments:
TESTNAME list of tests to run named like in description
(default: run all tests)
optional arguments:
-h, --help show this help message and exit
--verbose, -v increase console verbosity level
@ -74,7 +74,7 @@ You can use ``python3 -m qubes.tests.run -h`` to get usage information:
allow running in parallel with qubesd; this is
DANGEROUS and WILL RESULT IN INCONSISTENT SYSTEM STATE
--break-to-repl break to REPL after tests
When running only specific tests, write their names like in log, in format:
MODULE+"/"+CLASS+"/"+FUNCTION. MODULE should omit initial "qubes.tests.".
Example: basic/TC_00_Basic/test_000_create
@ -117,7 +117,7 @@ Example test run:
Tests are also compatible with nose2 test runner, so you can use this instead:
.. code:: bash
.. code:: console
sudo systemctl stop qubesd; sudo -E nose2 -v --plugin nose2.plugins.loader.loadtests qubes.tests; sudo systemctl start qubesd
@ -138,7 +138,7 @@ The below example however will assume that you set up a build environment as des
Assuming you cloned the ``qubes-builder`` repository to your home directory inside a fedora VM, you can use the following commands to run the unit tests:
.. code:: bash
.. code:: console
cd ~
sudo dnf install python3-pip lvm2 python35 python3-virtualenv
@ -213,37 +213,37 @@ When testing (Py)QT applications, it’s useful to create a separate QApplicatio
import quamash
import unittest
import gc
class SomeTestCase(unittest.TestCase):
def setUp(self):
[...]
# force "cleanlooks" style, the default one on Xfce (GtkStyle) use
# static variable internally and caches pointers to later destroyed
# objects (result: SEGV)
self.qtapp = QtGui.QApplication(["test", "-style", "cleanlooks"])
# construct event loop even if this particular test doesn't use it,
# otherwise events with qtapp references will be queued there anyway and the
# first test that actually use event loop will try to dereference (already
# destroyed) objects, resulting in SEGV
self.loop = quamash.QEventLoop(self.qtapp)
def tearDown(self):
[...]
# process any pending events before destroying the object
self.qtapp.processEvents()
# queue destroying the QApplication object, do that for any other QT
# related objects here too
self.qtapp.deleteLater()
# process any pending events (other than just queued destroy), just in case
self.qtapp.processEvents()
# execute main loop, which will process all events, _including just queued destroy_
self.loop.run_until_complete(asyncio.sleep(0))
# at this point it QT objects are destroyed, cleanup all remaining references;
# del other QT object here too
self.loop.close()

2
developer/debugging/safe-remote-ttys.rst
View file

@ -68,7 +68,7 @@ A note on serial consoles
If your machine has a serial console, you may with to use that, but note that a similar split-I/O model should be used to ensure Dom0 integrity. If you use the serial console as normal (via e.g. getty on ttyX, and logging in as normal), then the machine at the end of the serial cable could compromise your machine! Ideally, you would take input from your trusted keyboard, and only send the output over the serial cable via e.g. disabling getty and using:
.. code:: bash
.. code:: console
script -f /dev/ttyS0

70
developer/debugging/test-bench.rst
View file

@ -38,15 +38,15 @@ Internet access is intentionally disabled by default in dom0. But to ease the de
.. code:: bash
#!/bin/sh
# adjust this for your NIC (run lspci)
BDF=0000:02:00.0
# adjust this for your network driver
DRIVER=e1000e
prog=$(basename $0)
pciunbind() {
local path
path=/sys/bus/pci/devices/${1}/driver/unbind
@ -56,7 +56,7 @@ Internet access is intentionally disabled by default in dom0. But to ease the de
fi
echo -n ${1} >${path}
}
pcibind() {
local path
path=/sys/bus/pci/drivers/${2}/bind
@ -66,10 +66,10 @@ Internet access is intentionally disabled by default in dom0. But to ease the de
fi
echo ${1} >${path}
}
pciunbind ${BDF}
pcibind ${BDF} ${DRIVER}
sleep 1
dhclient
@ -78,15 +78,15 @@ Internet access is intentionally disabled by default in dom0. But to ease the de
6. You’ll need to run the above script on every startup. To automate this save the following systemd service ``/etc/systemd/system/dom0-network-direct.service``
.. code:: bash
.. code:: systemd
[Unit]
Description=Connect network to dom0
[Service]
Type=oneshot
ExecStart=/home/user/bin/dom0_network.sh
[Install]
WantedBy=multi-user.target
@ -94,11 +94,11 @@ Internet access is intentionally disabled by default in dom0. But to ease the de
7. Then, enable and start the SSH Server and the script on boot:
.. code:: bash
.. code:: console
sudo systemctl enable sshd
sudo systemctl start sshd
sudo systemctl enable dom0-network-direct
sudo systemctl start dom0-network-direct
@ -117,20 +117,20 @@ Because of the above reason, some additional configurations need to be done to y
The following commands should work for you, but do keep in mind that the provisioning scripts are designed for the `openQA environment <https://openqa.qubes-os.org/>`__ and not your specific local testing system. Run the following in ``dom0``:
.. code:: bash
.. code:: console
# For future reference the following commands are an adaptation of
# https://github.com/marmarek/openqa-tests-qubesos/blob/master/tests/update.pm
# Install git
sudo qubes-dom0-update git || sudo dnf --setopt=reposdir=/etc/yum.repos.d install git
# Download the openQA automated testing environment Salt configuration
git clone https://github.com/marmarek/openqa-tests-qubesos/
cd openqa-tests-qubesos/extra-files
sudo cp -a system-tests/ /srv/salt/
sudo qubesctl top.enable system-tests
# Install the same configuration as the one in openQA
QUBES_VERSION=4.1
PILLAR_DIR=/srv/pillar/base/update
@ -138,7 +138,7 @@ The following commands should work for you, but do keep in mind that the provisi
printf 'update:\n qubes_ver: '$QUBES_VERSION'\n' | sudo tee $PILLAR_DIR/init.sls
printf "base:\n '*':\n - update\n" | sudo tee $PILLAR_DIR/init.top
sudo qubesctl top.enable update pillar=True
# Apply states to dom0 and VMs
# NOTE: These commands can take several minutes (if not more) without showing output
sudo qubesctl --show-output state.highstate
@ -155,7 +155,7 @@ SSH
Arrange firewall so you can reach the testbench from your ``qubes-dev`` VM. Generate SSH key in ``qubes-dev``:
.. code:: bash
.. code:: console
ssh-keygen -t ecdsa -b 521
@ -163,7 +163,7 @@ Arrange firewall so you can reach the testbench from your ``qubes-dev`` VM. Gene
Add the following section in ``.ssh/config`` in ``qubes-dev``:
.. code:: bash
.. code:: text
Host testbench
# substitute username in testbench
@ -190,7 +190,7 @@ This step is optional, but very helpful. Put these scripts somewhere in your ``$
.. code:: bash
#!/bin/sh
ssh testbench python -m qubes.tests.run
@ -199,19 +199,19 @@ This step is optional, but very helpful. Put these scripts somewhere in your ``$
.. code:: bash
#!/bin/sh
TMPDIR=/tmp/qtb-rpms
if [ $# -eq 0 ]; then
echo "usage: $(basename $0) <rpmfile> ..."
exit 2
fi
set -e
ssh testbench mkdir -p "${TMPDIR}"
scp "${@}" testbench:"${TMPDIR}" || echo "check if you have 'scp' installed on your testbench"
while [ $# -gt 0 ]; do
ssh testbench sudo rpm -i --replacepkgs --replacefiles "${TMPDIR}/$(basename ${1})"
shift
@ -220,19 +220,19 @@ This step is optional, but very helpful. Put these scripts somewhere in your ``$
``qtb-iterate``:
.. code:: bash
.. code:: console
#!/bin/sh
set -e
# substitute path to your builder installation
pushd ${HOME}/builder >/dev/null
# the following are needed only if you have sources outside builder
#rm -rf qubes-src/core-admin
#qb -c core-admin package fetch
qb -c core-admin -d host-fc41 prep build
# update your dom0 fedora distribution as appropriate
qtb-install qubes-src/core-admin/rpm/x86_64/qubes-core-dom0-*.rpm
@ -247,20 +247,20 @@ I (woju) have those two git hooks. They ensure tests are passing (or are marked
``core-admin/.git/hooks/pre-commit``: (you may retain also the default hook, here omitted for readability)
.. code:: bash
.. code:: console
#!/bin/sh
set -e
python -c "import sys, qubes.tests.run; sys.exit(not qubes.tests.run.main())"
``core-admin/.git/hooks/pre-push``:
.. code:: bash
.. code:: console
#!/bin/sh
exec qtb-iterate

10
developer/debugging/windows-debugging.rst
View file

@ -45,9 +45,9 @@ You will need to create a custom libvirt config for the target VM. See `the docu
.. code:: bash
.. code:: xml+jinja
{% extends 'libvirt/xen.xml' %}
{% block network %}
<interface type='ethernet'>
@ -58,7 +58,7 @@ You will need to create a custom libvirt config for the target VM. See `the docu
<model type='e1000' />
</interface>
{% endblock %}
@ -98,7 +98,7 @@ Host and target preparation
- ``kdnet`` should show that the NIC is supported, note the busparams:
.. code:: bash
.. code:: text
Network debugging is supported on the following NICs:
busparams=0.6.0, Intel(R) PRO/1000 MT Network Connection, KDNET is running on this NIC.
@ -117,7 +117,7 @@ Host and target preparation
- Reboot ``target-vm``, debugging should start:
.. code:: bash
.. code:: text
Waiting to reconnect...
Connected to target 10.137.0.19 on port 50000 on local IP 10.137.0.20.