[RFC] Add Guix vmupdate backend#211
Conversation
noufalkv
force-pushed
the
guix-vmupdate-backend-review
branch
from
cbd005c to
e3847ff
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #211 +/- ##
==========================================
- Coverage 71.95% 69.79% -2.16%
==========================================
Files 12 27 +15
Lines 1330 2192 +862
==========================================
+ Hits 957 1530 +573
- Misses 373 662 +289 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
noufalkv
force-pushed
the
guix-vmupdate-backend-review
branch
from
e3847ff to
14b31e4
Compare
|
Updated after the latest reviewability rebase. Current single-commit PR head: The commit itself is GPG-signed with key fingerprint Focused local validation for this head, run from a patched PYTHONPATH=<qubes-core-admin-client checkout>:. ./run-tests.sh vmupdate/tests/test_agent_guix.pyResult: The backend remains scoped to the Guix System update path only: Runtime evidence from the template harness: openQA job 129 passed the central-update path through the Qubes proxy, including This is an autonomous-AI RFC contribution and still needs normal human review before any publication decision. |
noufalkv
force-pushed
the
guix-vmupdate-backend-review
branch
5 times, most recently
from
d0e5d64 to
c71ee2b
Compare
Add a Guix source backend for qvm-template update handling. The backend limits vmupdate to the system profile by running guix time-machine on the master branch, describing available system profile updates, and reconfiguring /etc/config.scm through guix system reconfigure. Report package-level metadata in the same table-oriented shape consumed by the dom0 updater and add regression coverage for manifest parsing, logging, fallback handling, and command construction.
noufalkv
force-pushed
the
guix-vmupdate-backend-review
branch
from
c71ee2b to
182199c
Compare
marmarek
left a comment
marmarek
left a comment
There was a problem hiding this comment.
This is some initial review, I have not checked if the actual commands used for the update are correct yet.
| @staticmethod | ||
| def _parse_sanitized_manifest_entry(fields, store_path): | ||
| """ | ||
| Recover fields after ProcessResult stripped tabs from Guix output. |
There was a problem hiding this comment.
Looks like a lot of effort to un-break that output. Tabs are not that dangerous, so maybe easier would be to simply allow them in ProcessResult.sanitize_output function?
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026060812-devel-guix&flavor=templates Test run included the following:
Installing updates failed, skipping the report! |
|
Updates proxy doesn't work: (see openQA link) |
The backend ran "guix time-machine --branch=master -- system reconfigure", which only advances the Guix channel and never reads /etc/guix/channels.scm. The Qubes channel that pins the Qubes component versions therefore stayed frozen at whatever was baked into the installed template, so reconfigure could not update the Qubes components. Run "guix pull" in refresh() so it reads /etc/guix/channels.scm and advances both Guix and the Qubes channel, then drive "guix system reconfigure" with the freshly pulled root guix. Use root's real HOME so the pull persists. Update the tests accordingly and cover the pulled-guix reconfigure path.
ProcessResult.sanitize_output stripped tabs, so the Guix backend replaced them with a placeholder separator and carried a heuristic to re-split columns that got glued together when a field overflowed Guix's padding. Allow the tab character through sanitize_output (it is printable whitespace) and split the manifest on tabs directly, dropping the placeholder dance and the _parse_sanitized_manifest_entry recovery heuristic.
_print_changes passed the raw version lists to print(), so the Installed and Removed sections rendered Python list syntax (e.g. "pkg ['1.0']"), and the Updated section relied on a fragile slice to strip it. Join the version lists through a shared helper so all three sections print clean, human-readable versions regardless of how many outputs a package has.
|
Update via updates proxy still didn't work. See updated openqa link above, or https://openqa.qubes-os.org/tests/182612/file/update2-qubesctl-upgrade.log specifically. |
|
BTW, the test was using templates from https://github.com/noufalkv/qubes-template-guix/releases/tag/test-rpms-6e6f03e-202606020736 |
4 participants
This is an RFC/review-only component patch for centralized updater support in a native GNU Guix System TemplateVM prototype.
It adds a Guix backend to
qubes-vm-updateso dom0 can dispatch a Guix System refresh/reconfigure path through the same agent-side updater entry point. The backend intentionally updates the Guix System only: refresh maps toguix time-machine --branch=master -- describe, upgrade maps toguix time-machine --branch=master -- system reconfigure --no-bootloader /etc/config.scm, and root or userguix pullcheckouts are out of scope. It passes the Qubes update-proxy environment when active, uses vmupdate-scoped temporary time-machine state, captures Guix stderr inupdate-guix.log, and reports/run/current-system/profilemanifest entries as per-output package metadata for the normal dom0 package summary.Validation run in a clean patched checkout with a matching
qubes-core-admin-clientcheckout onPYTHONPATH:Result:
52 passed, 1 warning.Template-side runtime evidence is in the linked template prototype. RPM-mode openQA job 129 passed the central update path through a standard Debian
sys-netupdate target: TemplateVM/AppVM smoke, generated Guix update-proxy configuration, rawqubes.UpdatesProxyprobe,guix time-machine --branch=master,guix system reconfigure --no-bootloader /etc/config.scm, package metadata reporting, and agent exit status 0. Job 133 reran the corrected central log harness and reached Guix through the same proxy path before failing on an upstream Git HTTP 504 during refresh, which is useful negative evidence for external fetch failure handling rather than a Qubes policy/qrexec failure.This PR is still an RFC. It has not been reviewed or accepted by Qubes maintainers, and it still needs the normal maintainer ownership and release decision before any publication use.
This PR was prepared by an autonomous AI coding agent from a user-directed review branch, so it needs normal human review and ownership before any release decision.