vmupdate: support dnf5 python API #187
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #187 +/- ##
=======================================
Coverage 73.03% 73.03%
=======================================
Files 10 10
Lines 1157 1157
=======================================
Hits 845 845
Misses 312 312 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2025040403-4.3&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2025031804-4.3&flavor=update
Failed tests45 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/132953#dependencies 12 fixed
Unstable testsPerformance TestsPerformance degradation:11 performance degradations
Remaining performance tests:61 tests
|
vmupdate/agent/entrypoint.py
Outdated
| else: | ||
| from source.dnf.dnf5_api import DNF as PackageManager | ||
| except ImportError: | ||
| log.warning("Failed to load dnf with progress bar. Use dnf cli.") |
There was a problem hiding this comment.
I hit this case initially. Several things:
- I didn't got this message in GUI updater, only in log file, why?
- The "use dnf cli" suggest an action from the user, -> "using"?
- Maybe try fallback to dnf4 before fallback to CLI? Or could that cause issues?
- Should core-agent-linux pull in python3-libdnf5? Or maybe qubes-vm-recommended (in which case, it won't be present in minimal template)? With DNF4 it wasn't an issue, as it was a dependency of DNF itself...
There was a problem hiding this comment.
- Should be better now
- fixed
- you're right
- I think it should
|
When trying it out (after installing python3-libdnf5), the download reporting behave weird. First, I get a wall of "Fetching package: ..." messages almost instantly. Does it try to download all packages in parallel? Then I get "Fetched" messages for individual packages as they get downloaded, together with progress updates. But also, when keeping details open, qubes-update-gui gets quite busy during download phase - about 50% CPU all the time. It's about 20% when details are closed. And much lower regardless of viewing details when installing updates (after download completes). This may be an issue in qubes-update-gui, but probably related to the rate at which download progress is reported. |
It looks like updater-gui consumes a lot of CPU if messages are sent frequently.
This is related to text output. I reduced the amount of printed text, and it looks better. The GUI probably needs to be optimized in this regard. |
| :param downloaded: Number of bytes downloaded. | ||
| """ | ||
| if not self.fetching_notified: | ||
| print(f"Fetching {self.count} packages", flush=True) |
There was a problem hiding this comment.
Maybe include total download size too here?
There was a problem hiding this comment.
Good idea, I did it for all package managers
|
Tests says repository refresh error is reported as no updates instead of failure:
|
This also look to be some issue, the update log has: But it's supposed to find test-pkg update (1.0 -> 1.1). |
expiring cache enforces re-downloading metadata skip_unavailable -> skip_if_unavailable skip_unavailable: skips unavailable packages skip_if_unavailable: skips unavailable repos
| # USA. | ||
|
|
||
| import subprocess | ||
| import os |
remove unused import
|
Now I don't get what is currently being done at all... only "Fetching xxx packages" and then "Updating packages", and finally "Updated". My complain was only about "Fetching ..." message, as it looks like it was printed for all packages at the start, not when it actually started fetching that package - so not very useful. But "Fetched ..." message is meanigful as you see what was done already. And similar for installation - message which package is currently being installed (or just was installed) is an useful info. As for CPU usage, even with this very minimal, it qubes-update-gui still used about 50% CPU during download, so it isn't (just) about messages. More likely frequency of updating the progress bar. Not sure what would be a good solution here, but it's a minor issue, can be solved later. |
4 participants
No description provided.