Bug#1108679: unblock: libvirt/11.3.0-3

2025-07-05 Thread Andrea Bolognani
On Sat, Jul 05, 2025 at 03:17:51PM +, Ivo De Decker wrote:
> On Thu, Jul 03, 2025 at 09:07:05PM +0200, Andrea Bolognani wrote:
> > On Thu, Jul 03, 2025 at 12:40:14PM +, Ivo De Decker wrote:
> > > This version doesn't seem to be uploaded to unstable. In case this unblock
> > > requests was meant as a pre-approval request:
> > 
> > Yes, that was the idea. I was under the impression that pre-approvals
> > were preferred, but if that's not the case I can start with the
> > upload next time. Or maybe I should have just mentioned this :)
> 
> Well, people usually mention that it's a pre-approval request.

Yeah, it's completely obvious in retrospect. My bad for not
mentioning it. I'll make sure not to make the same mistake in the
future.

> If the change is a small targeted fix that can easily be reverted if
> necessary, then there isn't much risk in a direct upload. If the change is
> bigger, not in line with the freeze policy, or if a revert would be
> inconvenient, it might be better to ask for pre-approval.

Makes sense. Personally I'd rather not upload anything to unstable if
there's a (foreseeable) chance that it will have to be reverted, so
the pre-approval approach still suits me better.

> > > Please go ahead with the upload and remove the moreinfo tag from this 
> > > unblock
> > > request once the new upload has been in unstable for a few days, and you 
> > > think
> > > it's ready to migrate.
> > 
> > Upload done. I'll remove the tag in a few days.
> 
> Unblocked.

Thank you!

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature


Bug#1108679: unblock: libvirt/11.3.0-3

2025-07-03 Thread Andrea Bolognani
On Thu, Jul 03, 2025 at 12:40:14PM +, Ivo De Decker wrote:
> On Wed, Jul 02, 2025 at 10:43:26PM +0200, Andrea Bolognani wrote:
> > Subject: unblock: libvirt/11.3.0-3
> 
> > Please unblock package libvirt
> 
> This version doesn't seem to be uploaded to unstable. In case this unblock
> requests was meant as a pre-approval request:

Yes, that was the idea. I was under the impression that pre-approvals
were preferred, but if that's not the case I can start with the
upload next time. Or maybe I should have just mentioned this :)

> Please go ahead with the upload and remove the moreinfo tag from this unblock
> request once the new upload has been in unstable for a few days, and you think
> it's ready to migrate.

Upload done. I'll remove the tag in a few days.

Thanks!

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature


Bug#1108679: unblock: libvirt/11.3.0-3

2025-07-03 Thread Ivo De Decker
Control: tags -1 confirmed moreinfo

Hi,

On Wed, Jul 02, 2025 at 10:43:26PM +0200, Andrea Bolognani wrote:
> Subject: unblock: libvirt/11.3.0-3

> Please unblock package libvirt

This version doesn't seem to be uploaded to unstable. In case this unblock
requests was meant as a pre-approval request:

Please go ahead with the upload and remove the moreinfo tag from this unblock
request once the new upload has been in unstable for a few days, and you think
it's ready to migrate.

Thanks,

Ivo



Bug#1108679: unblock: libvirt/11.3.0-3

2025-07-02 Thread Andrea Bolognani
Package: release.debian.org
Severity: normal
User: [email protected]
Usertags: unblock
X-Debbugs-Cc: [email protected]
Control: affects -1 + src:libvirt

Please unblock package libvirt

[ Reason ]

Backport fix for https://bugzilla.redhat.com/2369243

The issue has not been filed against Debian, but it affects the
version of libvirt in trixie nonetheless.

[ Tests ]

I have manually tested the fix and confirmed that it addresses the
issue.

[ Risks ]

Very little risk of causing regressions. The fix is small and
targeted, and it comes directly from upstream with no changes.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock libvirt/11.3.0-3

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.
diff -Nru libvirt-11.3.0/debian/changelog libvirt-11.3.0/debian/changelog
--- libvirt-11.3.0/debian/changelog 2025-06-01 16:39:44.0 +0200
+++ libvirt-11.3.0/debian/changelog 2025-07-02 22:15:28.0 +0200
@@ -1,3 +1,10 @@
+libvirt (11.3.0-3) unstable; urgency=medium
+
+  * [d10b70f] patches: Add backports
+- backport/qemu-Be-more-forgiving-when-acquiring-QUERY-job-[...]
+
+ -- Andrea Bolognani   Wed, 02 Jul 2025 22:15:28 +0200
+
 libvirt (11.3.0-2) unstable; urgency=medium
 
   * [eb4a97a] patches: Add backports
diff -Nru 
libvirt-11.3.0/debian/patches/backport/qemu-Be-more-forgiving-when-acquiring-QUERY-job-when-form.patch
 
libvirt-11.3.0/debian/patches/backport/qemu-Be-more-forgiving-when-acquiring-QUERY-job-when-form.patch
--- 
libvirt-11.3.0/debian/patches/backport/qemu-Be-more-forgiving-when-acquiring-QUERY-job-when-form.patch
  1970-01-01 01:00:00.0 +0100
+++ 
libvirt-11.3.0/debian/patches/backport/qemu-Be-more-forgiving-when-acquiring-QUERY-job-when-form.patch
  2025-07-02 22:15:28.0 +0200
@@ -0,0 +1,70 @@
+From: Michal Privoznik 
+Date: Mon, 16 Jun 2025 10:28:37 +0200
+Subject: qemu: Be more forgiving when acquiring QUERY job when formatting
+ domain XML
+
+In my previous commit of v11.0.0-rc1~115 I've made QEMU driver
+implementation for virDomainGetXMLDesc() (qemuDomainGetXMLDesc())
+acquire QERY job. See its commit message for more info. But this
+unfortunately broke apps witch fetch domain XML for incoming
+migration (like virt-manager). The reason is that for incoming
+migration the VIR_ASYNC_JOB_MIGRATION_IN async job is set, but
+the mask of allowed synchronous jobs is empty (because QEMU can't
+talk on monitor really). This makes virDomainObjBeginJob() fail
+which in turn makes qemuDomainGetXMLDesc() fail too.
+
+It makes sense for qemuDomainGetXMLDesc() to acquire the job
+(e.g. so that it's coherent with another thread that might be in
+the middle of a MODIFY job). But failure to dump XML may be
+treated as broken daemon (e.g. virt-manager does so).
+
+Therefore, still try to acquire the QUERY job (if job mask
+permits it) but, do not treat failure as an error.
+
+Fixes: 6cc93bf28842526be2fd596a607ebca796b7fb2e
+Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2369243
+Signed-off-by: Michal Privoznik 
+Reviewed-by: Pavel Hrdina 
+(cherry picked from commit 441c23a7e626c13e6df1946303a0bc0a84180d1c)
+
+Forwarded: not-needed
+Origin: 
https://gitlab.com/libvirt/libvirt/-/commits/441c23a7e626c13e6df1946303a0bc0a84180d1c
+---
+ src/qemu/qemu_driver.c | 10 +++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
+index a34d6f1..9f04374 100644
+--- a/src/qemu/qemu_driver.c
 b/src/qemu/qemu_driver.c
+@@ -6188,6 +6188,7 @@ static char
+ {
+ virQEMUDriver *driver = dom->conn->privateData;
+ virDomainObj *vm;
++bool hasJob = false;
+ char *ret = NULL;
+ 
+ virCheckFlags(VIR_DOMAIN_XML_COMMON_FLAGS | VIR_DOMAIN_XML_UPDATE_CPU,
+@@ -6199,8 +6200,10 @@ static char
+ if (virDomainGetXMLDescEnsureACL(dom->conn, vm->def, flags) < 0)
+ goto cleanup;
+ 
+-if (virDomainObjBeginJob(vm, VIR_JOB_QUERY) < 0)
+-goto cleanup;
++if (virDomainNestedJobAllowed(vm->job, VIR_JOB_QUERY) &&
++virDomainObjBeginJob(vm, VIR_JOB_QUERY) >= 0) {
++hasJob = true;
++}
+ 
+ qemuDomainUpdateCurrentMemorySize(vm);
+ 
+@@ -6216,7 +6219,8 @@ static char
+ 
+ ret = qemuDomainFormatXML(driver, vm, flags);
+ 
+-virDomainObjEndJob(vm);
++if (hasJob)
++virDomainObjEndJob(vm);
+ 
+  cleanup:
+ virDomainObjEndAPI(&vm);
diff -Nru libvirt-11.3.0/debian/patches/series 
libvirt-11.3.0/debian/patches/series
--- libvirt-11.3.0/debian/patches/series2025-06-01 16:39:44.0 
+0200
+++ libvirt-11.3.0/debian/patches/series2025-07-02 22:15:28.0 
+0200
@@ -1,4 +1,5 @@
 backport/qemuProcessStartWithMemoryState-Don-t-setup-qemu-for-inco.patch
+backport/qemu-Be-more-forgiving-when-acquiring-QUERY-job-when-form.patch
 debian/Debianize-libvirt-gu