At the time of writing those lines, i do not see any OpenQA entree either in the PR that was approved above, nor any new issue created under Issues · QubesOS/updates-status · GitHub
Edit: they were there.
Then PR got merged to xmm-xen.
@marmarek/@adw can you detail the flow of a an approved code PR → OpenQA testing output to look at (how are those linked outside of seeing pipelineretry) → signing → issue being created under Issues · QubesOS/updates-status · GitHub → package landing under unstable repositories to be testable ?
It gets automatically build-tested on gitlab-ci. In few cases, this includes also basic unit tests. This gets reported in the PR status.
PR get review; in case of less than trivial changes, PR get a “openqa-pending” label, to be included in the next openQA run (in the “pull requests” group). Those get scheduled manually, usually just after assigning the label. Results get reported back to PR comments. There is a common run for all the PRs with the label, so a failure listed there may be caused by another PR in the group (IOW, failed tests are just a hint, not a blocker).
PR get merged; at this point, github automatically closes associated issues, but otherwise not much more is happening.
I bump a package version (usually after merging a few PRs in given repository). At this point the package gets built and lands in current-testing repo + an issue in updates-status is created. Relevant issues (qubes-issues repo) get also automatic comment about the packages.
Every Wednesday, automatic openQA run is started for package in current-testing repo (the “updates” group on openqa). Results get reported as a comment in relevant update-status issues.
Every Saturday, a weekly ISO image is built (including packages from current-testing repo) and scheduled on openQA in the “Qubes OS” group.
Depending on testing results, package can be moved to “current” repository after at least a week. For some less trivial changes, I prefer to keep it in current-testing repo a bit longer. I usually do review of “updates-status” issues on Monday or Tuesday.
The last point is where this group can help a lot. Even just giving or helps, as an indicator that you actually installed related package and found (or not) it working. Packages with no feedback at all tends to stay longer in current-testing repo.
Those aren’t supposed to be there (vanilla packages from Fedora are enough in VM).
@marmarek :
It is not clear to me the link between current-testing notes for bullseye here under vmm-xen v4.14.5-9 (r4.1) · Issue #3084 · QubesOS/updates-status · GitHub Package for bullseye was built ([build log](https://github.com/QubesOS/build-logs/tree/master/build-debian4/log_2022-10-16_01-33-06)) and uploaded to current-testing repository
And the packages qubes-input-proxy-sender qubes-vm-dependencies qubes-vm-recommended xen-utils-guest that were update candidates with bullseye-testing uncommented, applied on other post for testing.
If it is unclear to me, this is most probably unclear as well for the testing community as well.
@marmarek, can you explain why some other templates have updates but not others then and how to easily understand the link between vmm-xen to v4.14.5-9 and bullseye current-testing available updates, in this case:
And more importantly, why and what is the relation between dom0 package here and what differenciate fedora templates not needing specifics parallel updates and why here only a subset of supported templates have updates available that do not seem clearly related, nor having specific names of packages that would need to be co-tested for regression/functionality?
In case of xen packages for Debian, there is almost nothing qubes specific there, and as such, most most fixes referenced there apply only to the dom0. The only remaining reason we build them (instead of using upstream packages directly, as in case of Fedora) is that Debian packaging insists on having the same version of libraries as the hypervisor. This matters for dom0, but is irrelevant for VM (and indeed Fedora VMs for example use libs from Xen 4.16 and it works just fine). But since the Debian packaging has this versioning requirements, we need to ship the same version (at the moment Debian stable incidentally also ships with Xen 4.14, but it isn’t always the case, and for example Debian testing has Xen 4.16). I hope this will be resolved one day in Debian too…
Long story short: for xen it’s enough to test dom0 packages.