Qubes 4.3 compatibility #1373
Draft
Qubes 4.3 compatibility #1373
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
deeplow
force-pushed
the
1245-qubes-4.3-compat
branch
6 times, most recently
from
5dfd030 to
3ecdfbb
Compare
deeplow
force-pushed
the
1245-qubes-4.3-compat
branch
2 times, most recently
from
cd02e0b to
8eeae1a
Compare
deeplow
force-pushed
the
1245-qubes-4.3-compat
branch
11 times, most recently
from
9d9303f to
e31a66b
Compare
Contributor
Author
|
This is now passing installation with a few hacks. It's only running into issues in the tests, but I haven't taken a look at those yet. |
deeplow
force-pushed
the
1245-qubes-4.3-compat
branch
from
e45451c to
66bceaa
Compare
deeplow
force-pushed
the
1245-qubes-4.3-compat
branch
from
66bceaa to
7fad531
Compare
This was referenced Oct 23, 2025
deeplow
force-pushed
the
1245-qubes-4.3-compat
branch
2 times, most recently
from
ffef033 to
31a1e00
Compare
deeplow
force-pushed
the
1245-qubes-4.3-compat
branch
3 times, most recently
from
59c0d9b to
2a486e2
Compare
Run openqa jobs on Qubes 4.3
Qt5 is not installed by default in dom0 whereas PyQt6 is.
Other than changing the imports from PyQt5 to 6 this commit updates the
code that was not forward-compatible, namely:
- replace "exec_()" with exec() (Qt5 targetted also python2, which
meant that it had "exec" reserved. This is no longer the case, so we
can use the more aptly named "exec()"
- Expand enums like QMessageBox.Ok to have its full name
(QMessageBox.StandardButtons.Ok)
A consolidated view of the upgrade notes can be found at
https://www.pythonguis.com/faq/pyqt5-vs-pyqt6/
Use Qt6 to regenerate the compiled UI. To achieve this I installed
pyqt6-dev-tools and ran it with:
pyuic6 sdw_updater.ui > UpdaterAppUiQt6.py
NOTES:
- version mismatch between version used for compilation (6.4.2) and
the one available in dom0 (6.8.1) should not make a difference since
syntax changes should be constant in the same Qt/PyQt version
- Ruff lint was applied on top of the result.
When running "sdw-admin --apply" "run-prep-upgrade-scripts" in "sd-upgrade-templates.sls" and "sd-remove-unused-templates" as it fails with the message: stdout: Please specify prepare or remove This indicated that the 'args' parameter is not being properly recognized. I looked at the saltstack documentation for the cmd module and nothing indicates an 'args' parameters change. I've checked with changelogs as well comparing the version in Qubes 4.2 with the one in Qubes 4.3. Instead of investigating how to get "cmd.script" this simply uses another way to call the command as a temporary fix. For a more permanent solution we need to fix this in all different places and if we choose to go the 'cmd.run' route, we should place the script in some place other than '/srv/salt/'. (run on: openqa)
Launcher tests are failing. Run OpenQA despite them failing.
Package not yet available for dom0 with fc41 and the keyring package is not strictly necessary to proceed with the installation. (test on: openqa)
Launcher tests were failing likely due missing dependency updates in test-deps make target.
Assert has changed and test_migration_is_required was failing due to
this:
> raise AttributeError(
f"{name!r} is not a valid assertion. Use a spec "
f"for the mock if {name!r} is meant to be an attribute.")
E AttributeError: 'called_once_with' is not a valid assertion.
Use a spec for the mock if 'called_once_with' is meant to be
an attribute.. Did you mean: 'assert_called_once_with'?
Launcher tests showed a warning about warnings that should use 'warning' instead of 'warn()'
The NEEDLES_DIR was a temporary override due to an experience issue in OpenQA and now with GUI tests we're running into issues where it can't find the needle we just created interactively. The assumption here is that even though we do a live-creation of a needle, it's still fetching the git-provided ones. Since we had not yet actively worked on GUI test (which need needles, we had not yet run into problems with our temporary workaround)
Parts of the client application were getting hidden by the low resolution. Refs 1474.
Preloaded qubes do not need to be configured as they automatically get restarted when its template is changed and saved to disk. These preloaded sd-viewer qubes were getting included for configuration due to the inheritance of the 'sd-workstation' tag. Fruthermore, this attempt at configuration was causing issues as preloaded qubes would time-out when ordered to shut down (See #1475). The implementation choice was to include this fix in configure() rather than pre-filtering out preloaded qubes from the list of targets before passing them on to the 'configure()' function. This was due to the fact that the calling function should not need to be aware that preloaded qubes do not (and should not) have configurations applied to them. Fixes #1475 (test on: openqa)
Launcher tests were failing on 'poetry install' due to:
The currently activated Python version 3.11.6 is not supported
by the project (>=3.13).
Trying to find and use a compatible version.
Poetry was unable to find a compatible version. If you have one,
you can explicitly use it via the "env use" command.
(test on: openqa)
The test 'test_vms_exist.py::test_expected' and 'test_grsec_kernel' were failing because preloaded qubes are also tagged with 'sd-workstation' [1]. (test on: openqa) [1]: #1475 (comment)
Upon test failure, from an error message, it's not possible to easily understand what VM failed: > assert not policy_exists(vm, "sd-log", "securedrop.Log") E AssertionError: assert not True E + where True = policy_exists(<qubesadmin.vm.QubesVM object at 0x77effbba0d10>, 'sd-log', 'securedrop.Log') In the future, this will be made more apparent with the use of pytest fixture, but for the time being, this is already an improvement, without modifying much of test code (out of scope for this PR).
deeplow
force-pushed
the
1245-qubes-4.3-compat
branch
from
2a486e2 to
e9007f6
Compare
(test on: openqa)
deeplow
force-pushed
the
1245-qubes-4.3-compat
branch
from
e9007f6 to
e91ee7f
Compare
deeplow
commented
Nov 24, 2025
Comment on lines
17
to
+18
| container: | ||
| image: quay.io/fedora/fedora:37 | ||
| image: quay.io/fedora/fedora:41 |
Contributor
Author
There was a problem hiding this comment.
Do we even need to run "lint" in a container environment? If so, does it make sense to bump this to the dom0's Fedora version and add "matrix strategy"?
deeplow
commented
Nov 24, 2025
Contributor
Author
There was a problem hiding this comment.
I'm not sure how to handle OpenQA here. I've started a discussion in #1266 (comment)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of Changes
Towards #1245. Base Qubes 4.3 compatibility. Opening so we can iterate on OpenQA.
NOTES:
poetry env use python3.13FEDORA_VERSION=41 make devTesting
TBD
Deployment
Any special considerations for deployment? Consider both:
Checklist
If you have made changes to the provisioning logic
make test) pass indom0If you have added or removed files
MANIFEST.inandrpm-build/SPECS/securedrop-workstation-dom0-config.specIf documentation is required