On Fri, Jul 14, 2023 at 08:52:15AM -0700, Andrea Bolognani wrote:
> On Fri, Jul 14, 2023 at 04:28:11PM +0100, Daniel P. Berrangé wrote:
> > > > IOW, I think the problem needs to be raised & addressed in context of
> > > > the Fedora and systemd communities, rather than having libvirt diverge
> > >
On Fri, Jul 14, 2023 at 08:44:04AM -0700, Andrea Bolognani wrote:
> On Fri, Jul 14, 2023 at 04:25:48PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Jul 14, 2023 at 08:13:11AM -0700, Andrea Bolognani wrote:
> > > RHEL 8 got libvirt 6.0.0, which comes with socket activation support,
> > > back in
On Fri, Jul 14, 2023 at 04:28:11PM +0100, Daniel P. Berrangé wrote:
> > > IOW, I think the problem needs to be raised & addressed in context of
> > > the Fedora and systemd communities, rather than having libvirt diverge
> > > from normal Feora packaging practice.
> >
> > I absolutely agree with
Add some additional information about running clangd for LSP when clang
is not your normal compiler.
Signed-off-by: Jonathon Jongsma
---
docs/clangd.rst | 17 +
1 file changed, 17 insertions(+)
diff --git a/docs/clangd.rst b/docs/clangd.rst
index 93570ae178..25529948f6 100644
On Fri, Jul 14, 2023 at 04:25:48PM +0100, Daniel P. Berrangé wrote:
> On Fri, Jul 14, 2023 at 08:13:11AM -0700, Andrea Bolognani wrote:
> > RHEL 8 got libvirt 6.0.0, which comes with socket activation support,
> > back in 2020 with RHEL 8.3. Based on our support policy we only
> > consider the
On Fri, Jul 14, 2023 at 08:25:57AM -0700, Andrea Bolognani wrote:
> On Fri, Jul 14, 2023 at 04:02:30PM +0100, Daniel P. Berrangé wrote:
> > I don't have an objection to the conceptual approach.
> >
> > My concern is about where the solution is applied and divergance from
> > Fedora guidelines.
> >
On Fri, Jul 14, 2023 at 04:02:30PM +0100, Daniel P. Berrangé wrote:
> I don't have an objection to the conceptual approach.
>
> My concern is about where the solution is applied and divergance from
> Fedora guidelines.
>
> The long term direction of Fedora / RPM has been to reduce the number
> of
On Fri, Jul 14, 2023 at 08:13:11AM -0700, Andrea Bolognani wrote:
> On Fri, Jul 14, 2023 at 03:45:11PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Jul 14, 2023 at 04:39:39PM +0200, Andrea Bolognani wrote:
> > > This logic was necessary when socket activation was introduced
> > > in libvirt
On Fri, Jul 14, 2023 at 03:45:11PM +0100, Daniel P. Berrangé wrote:
> On Fri, Jul 14, 2023 at 04:39:39PM +0200, Andrea Bolognani wrote:
> > This logic was necessary when socket activation was introduced
> > in libvirt 5.6.0/5.7.0 in order to guarantee smooth upgrades.
> >
> > These days, even the
On Fri, Jul 14, 2023 at 04:39:34PM +0200, Andrea Bolognani wrote:
> Plus some extras I'm throwing in for free :)
>
> To understand why these changes are needed, see the original bug
> report[1] as well as the discussion triggered by Martin's initial
> attempt at addressing it[2].
>
> Getting
On Fri, Jul 14, 2023 at 04:39:39PM +0200, Andrea Bolognani wrote:
> This logic was necessary when socket activation was introduced
> in libvirt 5.6.0/5.7.0 in order to guarantee smooth upgrades.
>
> These days, even the oldest platform that we target ships a
> version of libvirtd that implements
On Mon, Jul 03, 2023 at 08:28:16AM +, Andrea Bolognani wrote:
> On Fri, Jun 30, 2023 at 01:46:05PM -0600, Jim Fehlig wrote:
> > On 6/30/23 10:58, Andrea Bolognani wrote:
> > > In the immediate future, I think we should look into implementing a
> > > similar logic to that of openSUSE in the
Signed-off-by: Andrea Bolognani
---
libvirt.spec.in | 23 ---
1 file changed, 23 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index d929170b2b..17d5f5ff4a 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1457,21 +1457,6 @@ rm -rf
In most cases the replacement is straightforward, with the
biggest difference being that we now schedule restarts during
%pre instead of %post. This also means that we can get rid of
%post for most packages, reducing the number of scriptlets that
need to run during install/upgrade.
Notable
This logic was necessary when socket activation was introduced
in libvirt 5.6.0/5.7.0 in order to guarantee smooth upgrades.
These days, even the oldest platform that we target ships a
version of libvirtd that implements socket activation, so the
additional code is no longer useful and we can
systemd provides a number of standard RPM macros but they don't
quite satisfy our requirements, as evidenced by the fact that we
have already built some custom tooling around them.
Scenarios that the standard macros don't cover and that we're
already addressing with our custom ones:
* for some
To make things more readable, use the same order (%pre, %post,
%posttrans, %preun, %postun) everywhere.
Signed-off-by: Andrea Bolognani
---
libvirt.spec.in | 104
1 file changed, 52 insertions(+), 52 deletions(-)
diff --git a/libvirt.spec.in
Signed-off-by: Andrea Bolognani
---
libvirt.spec.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index c72b420e85..05e322492a 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -22,7 +22,7 @@
%define arches_dmidecode
The current implementation pretty much assumes that targets
where modular daemons are the default will stick with that
configuration, as will targets where they're not, or that
changes to these defaults will be performed by the admin after
the packages have been installed.
This is unnecessarily
According to our platform support policy, now that Fedora 38 is
out we no longer target Fedora 36 and older. This allows us to
simplify a few conditionals.
Signed-off-by: Andrea Bolognani
---
libvirt.spec.in | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
Plus some extras I'm throwing in for free :)
To understand why these changes are needed, see the original bug
report[1] as well as the discussion triggered by Martin's initial
attempt at addressing it[2].
Getting this right is quite tricky, so in order to convince myself
that I'm not just going
Commit be1b7d5b18 introduced parsing /proc/cpuinfo for "address size"
which is not including on S390 and therefore reports an internal error.
Lets remove the parsing on S390.
Signed-off-by: Boris Fiuczynski
Reviewed-by: Marc Hartmayer
Reviewed-by: Collin Walling
---
src/cpu/cpu_x86.c
On a Friday in 2023, Peter Krempa wrote:
We now call 'query-qmp-schema' unconditionally and can extract the
information from there.
Peter Krempa (3):
qemu: capabilities: Probe presence of commands from QMP schema instead
of 'query-commands'
qemu: capabilities: Don't probe 'query-commands'
Now that we don't use it for probing at all we can remove all the
corresponding monitor code.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_monitor.c | 12
src/qemu/qemu_monitor.h | 2 --
src/qemu/qemu_monitor_json.c | 44 ---
Move the probing code to extract the data from the QMP schema rather
than invoking 'query-commands'. This patch doesn't yet remove the actual
invocation of 'query-commands', just moves the actual probing.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_capabilities.c | 17 +
1
We now call 'query-qmp-schema' unconditionally and can extract the
information from there.
Peter Krempa (3):
qemu: capabilities: Probe presence of commands from QMP schema instead
of 'query-commands'
qemu: capabilities: Don't probe 'query-commands'
qemu_monitor: Remove helpers for
On 7/13/23 12:59, Tim Small wrote:
> As a prospective contributor, whilst the documentation is generally very
> helpful, I found a few minor gaps and inconsistencies. I thought I would
> strike
> while the iron was hot, and attempt to make some improvements. The changes are
> mostly minor
On 7/13/23 18:30, Laine Stump wrote:
> When I implemented passt support in libvirt, I saw the --mac-addr
> option on the passt commandline, immediately assumed that this was
> used for setting the guest interface's mac address somewhere within
> passt, and read no further. As a result,
28 matches
Mail list logo
