On Thu, May 08, 2025 at 06:58:45PM +, Matt Ochs wrote:
> On May 8, 2025, at 4:00 AM, Andrea Bolognani wrote:
> > That was all present in my patch from earlier this year[1], which
> > this one is clearly based on.
> >
> > And "based on" is a very generous term in this case, since what the
> > a
> On May 8, 2025, at 4:33 AM, Andrea Bolognani wrote:
>
> On Thu, May 08, 2025 at 02:06:19AM -0700, Andrea Bolognani wrote:
>> On Thu, May 08, 2025 at 07:59:38AM +0200, Peter Krempa wrote:
>>> This one also should be mentioned, but I don't actually know the reason
>>> for this. So if you can dig
Hi Andrea,
> On May 8, 2025, at 4:00 AM, Andrea Bolognani wrote:
> On Thu, May 08, 2025 at 07:51:29AM +0200, Peter Krempa wrote:
>> On Wed, May 07, 2025 at 16:38:38 -0700, Matthew R. Ochs via Devel wrote:
>
> That was all present in my patch from earlier this year[1], which
> this one is clearly
On 5/7/25 12:55 AM, Markus Armbruster wrote:
[...]
- First, it's already broken because we rely on ifdef that won't be
there in Rust or Go.
I don't think it's broken. QAPI 'if' translates straightforwardly to C
#if, but that doesn't mean it cannot be translated to conditional
compilation / m
On 5/7/25 4:32 AM, Daniel P. Berrangé wrote:
On Wed, May 07, 2025 at 09:55:13AM +0200, Markus Armbruster wrote:
Pierrick Bouvier writes:
[...]
I don't think we should think too much ahead for languages other than C,
for one, two, and even three reasons :)
I agree that thinking ahead too mu
When VERSION is set to a development snapshot (micro >= 50), or a release
candidate (micro >= 90) we have an off-by-1 in determining deprecation
and deletion thresholds for versioned machine types. In such cases we need
to use the next major/minor version in threshold checks.
This adapts the depre
If we change the deprecation logic in include/hw/boards.h, we must make
a corresponding change to docs/conf.py and docs/about/deprecated.rst.
Add comments to these files as a warning to future maintainers to keep
these files in sync.
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Thomas Huth
Sig
We remove versioned machine types on a fixed schedule. This allows us
to auto-generate a paragraph in the removed-features.rst document that
always has accurate version info.
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Thomas Huth
Signed-off-by: Daniel P. Berrangé
---
docs/about/removed-fea
From: Thomas Huth
With the release of QEMU 10.1, the pc-q35-4.1 machine will be older
than 6 years and thus will get disabled automatically by the
MACHINE_VER_DELETION() macro. Remove the related test to avoid
that the q35-test is failing when the machine is not available anymore.
Tested-by: Phi
This reverts commit c9fd2d9a48ee3c195cf83cc611b87b09f02f0013.
When we introduced the specialized machine type deprecation policy, we
allow automatic deprecation to take effect immediately, but blocked the
automatic deletion of machine types for 2 releases. This ensured we
complied with the histori
We deprecate versioned machine types on a fixed schedule. This allows us
to auto-generate a paragraph in the deprecated.rst document that always
has accurate version info.
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Thomas Huth
Signed-off-by: Daniel P. Berrangé
---
docs/about/deprecated.rst
The following changes since commit 57b6f8d07f1478375f85a4593a207e936c63ff59:
Merge tag 'pull-target-arm-20250506' of
https://git.linaro.org/people/pmaydell/qemu-arm into staging (2025-05-07
14:28:20 -0400)
are available in the Git repository at:
https://gitlab.com/berrange/qemu tags/docs-d
Roman Bogorodskiy wrote:
> FWIW, I was able to resolve this and a couple of other minor issues
> relatively simply.
>
> https://gitlab.com/libvirt/libvirt-tck/-/merge_requests/59
Thanks for reviewing this one!
> > > On QEMU side, use of UEFI has always required manual config specification,
>
On Thu, May 08, 2025 at 12:21:20PM +0200, Philippe Mathieu-Daudé wrote:
> On 8/5/25 10:53, Daniel P. Berrangé wrote:
> > On Thu, May 08, 2025 at 09:45:50AM +0200, Thomas Huth wrote:
> > > On 06/05/2025 18.00, Daniel P. Berrangé wrote:
> > > > When VERSION is set to a development snapshot (micro >=
On Thu, May 08, 2025 at 07:51:29AM +0200, Peter Krempa wrote:
> On Wed, May 07, 2025 at 16:38:38 -0700, Matthew R. Ochs via Devel wrote:
> > diff --git
> > a/tests/qemuxmlconfdata/aarch64-nousb-minimal.aarch64-latest.abi-update.args
> >
> > b/tests/qemuxmlconfdata/aarch64-nousb-minimal.aarch64-l
On 6/5/25 18:00, Daniel P. Berrangé wrote:
Daniel P. Berrangé (5):
Revert "include/hw: temporarily disable deletion of versioned machine
types"
include/hw/boards: cope with dev/rc versions in deprecation checks
docs/about/deprecated: auto-generate a note for versioned machine
On 8/5/25 12:23, Daniel P. Berrangé wrote:
On Thu, May 08, 2025 at 12:21:20PM +0200, Philippe Mathieu-Daudé wrote:
On 8/5/25 10:53, Daniel P. Berrangé wrote:
On Thu, May 08, 2025 at 09:45:50AM +0200, Thomas Huth wrote:
On 06/05/2025 18.00, Daniel P. Berrangé wrote:
When VERSION is set to a de
On 8/5/25 10:53, Daniel P. Berrangé wrote:
On Thu, May 08, 2025 at 09:45:50AM +0200, Thomas Huth wrote:
On 06/05/2025 18.00, Daniel P. Berrangé wrote:
When VERSION is set to a development snapshot (micro >= 50), or a release
candidate (micro >= 90) we have an off-by-1 in determining deprecation
From: Daniel P. Berrangé
The zfs-fuse package has been dead upstream for a long time and is
now retired in Fedora rawhide.
Signed-off-by: Daniel P. Berrangé
---
libvirt.spec.in | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 92
The borzoi machine type was dropped in QEMU 9.2.0, so let's
use a different machine type with no ACPI support and no
implicit USB controller instead.
Signed-off-by: Andrea Bolognani
---
tests/qemuxmlconfdata/aarch64-noacpi-acpi.aarch64-latest.err | 2 +-
tests/qemuxmlconfdata/aarch64-noacpi-ac
On Thu, May 08, 2025 at 02:06:19AM -0700, Andrea Bolognani wrote:
> On Thu, May 08, 2025 at 07:59:38AM +0200, Peter Krempa wrote:
> > This one also should be mentioned, but I don't actually know the reason
> > for this. So if you can dig it out please reply with it and I'll ammend
> > the commit me
This combines my [v1] with Mattew's [v2] in a way that preserves
accurate authorship information, correctly splits changes across
patches and adequately documents the changes themselves.
[v1]
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/Z4NQ3CVQYLNGZRBC35CUHOQ2EXJROPYG/
On Thu, May 08, 2025 at 02:00:07AM -0700, Andrea Bolognani wrote:
> On Thu, May 08, 2025 at 07:51:29AM +0200, Peter Krempa wrote:
> [...] seems to indicate that they have just applied a naive
> s/borzoi/collie/ without considering the semantics. With this patch
> applied:
>
> $ grep collie tests/
On Thu, May 08, 2025 at 07:59:38AM +0200, Peter Krempa wrote:
> On Wed, May 07, 2025 at 16:38:46 -0700, Matthew R. Ochs via Devel wrote:
> > Add xml and reply files for QEMU 10.0.0 on aarch64.
>
> I'd prefer if the commit message commented on some of the .args changes.
> See below. (I can ammend th
On Thu, May 08, 2025 at 09:45:50AM +0200, Thomas Huth wrote:
> On 06/05/2025 18.00, Daniel P. Berrangé wrote:
> > When VERSION is set to a development snapshot (micro >= 50), or a release
> > candidate (micro >= 90) we have an off-by-1 in determining deprecation
> > and deletion thresholds for vers
On Wed, May 07, 2025 at 08:44:05PM +, Matt Ochs wrote:
> Hi Daniel,
>
> Thanks for your feedback!
>
> > On May 7, 2025, at 11:51 AM, Daniel P. Berrangé wrote:
> > On Fri, Apr 11, 2025 at 08:40:54AM -0700, Matthew R. Ochs via Devel wrote:
> >> Resending: Series has been re-based over latest u
On 06/05/2025 18.00, Daniel P. Berrangé wrote:
When VERSION is set to a development snapshot (micro >= 50), or a release
candidate (micro >= 90) we have an off-by-1 in determining deprecation
and deletion thresholds for versioned machine types. In such cases we need
to use the next major/minor ve
27 matches
Mail list logo
