Sounds good - thank you...
Patch is
Signed-off-by: Mark Mielke
On Mon, Jun 13, 2022 at 5:08 AM Ján Tomko wrote:
> On a Sunday in 2022, Mark Mielke wrote:
> >This is a partial revert of 87a43a907f0ad4897a28ad7c216bc70f37270b93.
>
> I'll drop the trailing period
This is a partial revert of 87a43a907f0ad4897a28ad7c216bc70f37270b93.
The change to use g_clear_pointer() in more places was accidentally
applied to cases involving vir_g_source_unref().
In some cases, the ordering of g_source_destroy() and
vir_g_source_unref() was reversed, which resulted in
ough to support many real-world use cases, or if it is only useful for
the most trivial and eventually limiting use cases.
--
Mark Mielke
nning programs with various undefined
behaviour. Now it is done "correctly" for so long, that people may have
forgotten the old days. :-)
--
Mark Mielke
On Thu, Aug 20, 2020 at 11:48 AM Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:
> On Thu, Aug 20, 2020 at 5:15 PM Mark Mielke wrote:
> > On Thu, Aug 20, 2020 at 8:55 AM Christian Ehrhardt <
> christian.ehrha...@canonical.com> wrote:
> >> This was m
he directory that contains the modules.
I'm wondering if a "last_packaging_change" provides any value over and
above the timestamp of the directory itself? Wouldn't the directory be best
- as it would work automatically for both distro packaging as well as
custom installs?
--
Mark Mielke
On Wed, Aug 5, 2020 at 4:31 AM Mark Mielke wrote:
> On Wed, Aug 5, 2020 at 4:19 AM Andrea Bolognani
> wrote:
>
>> That said, if upgrading QEMU results in losing features, even though
>> you can recover them through additional steps I would argue that's a
>> bug i
On Wed, Aug 5, 2020 at 4:19 AM Andrea Bolognani wrote:
> On Wed, 2020-08-05 at 02:09 -0400, Mark Mielke wrote:
> > In testing qemu-5.1rc2 on my Fedora 32 home system, I found that
> > the Fedora rawhide package has broken out both the QXL display
> > device and th
especially given that
libvirt domcapabilities cache may even persist across reboots? This means I
need to be very careful about the procedure to upgrade, and also I need to
make sure to never install or remove any of the device packages without
checking the procedure. Ouch. :-(
Thoughts?
--
Mark Mielke
On Sat, Jul 11, 2020 at 6:04 AM Mark Mielke wrote:
> On Fri, Jul 10, 2020 at 7:48 AM Mark Mielke wrote:
>
>> On Fri, Jul 10, 2020 at 7:14 AM Jiri Denemark
>> wrote:
>>
>>> The implementation seems to be doing exactly what the commit message
>>>
On Fri, Jul 10, 2020 at 7:48 AM Mark Mielke wrote:
> On Fri, Jul 10, 2020 at 7:14 AM Jiri Denemark wrote:
>
>> > +if (qemuCaps &&
>>
> > +def->cpu->mode == VIR_CPU_MODE_HOST_PASSTHROUGH &&
>> > +!def->
On Fri, Jul 10, 2020 at 7:14 AM Jiri Denemark wrote:
> On Sun, Jul 05, 2020 at 12:45:55 -0400, Mark Mielke wrote:
> > With 6.4.0, live migration was working fine with Qemu 5.0. After trying
> out
> > 6.5.0, migration broke with the following error:
> >
> > libvir
team disagrees with my analysis, then I will have to decide
whether to enable some sort of conversion mechanism to safely migrate
machines from libvirt-6.4.0 and before, to libvirt-6.5.0 without losing the
migration capability.
On Sun, Jul 5, 2020 at 12:45 PM Mark Mielke wrote:
> Hi
ate rather than guessing.
Please start by reverting this patch, so that other people do not get
broken in the same way, and I don't need to carry my revert patch.
Personally, I think this is important enough to build a 6.5.1. However,
since I have a local revert patch in place, I am not waiting for this.
Thanks!
--
Mark Mielke
14 matches
Mail list logo
