On 8/16/19 5:59 AM, Michal Privoznik wrote:
On 8/14/19 5:14 PM, Daniel Henrique Barboza wrote:
I've run make check with each individual patch, and everything
seems fine in my environment.
For all patches:
Tested-by: Daniel Henrique Barboza
I'll see if I can drop some code reviews later
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
The pci-stub is so old school that no one uses it. All modern
systems have adapted VFIO. Switch our virpcitest too.
Signed-off-by: Michal Privoznik
---
tests/virpcitest.c | 12 ++--
1 file changed, 6
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
The virHostdevPreparePCIDevices() function works in several
steps. In the very first one, it checks if devices we want to
detach from the host are not taken already by some other domain.
However, this piece of
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
The pci-assign device is so old school that no one uses it. All
modern systems have adapted VFIO. Switch our xml2argv test too.
Signed-off-by: Michal Privoznik
---
.../hostdev-pci-address-device.args
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
The pci-stub is so old school that no one uses it. All modern
systems have adapted VFIO. Switch our virhostdevtest too.
Signed-off-by: Michal Privoznik
---
tests/virhostdevtest.c | 4 ++--
1 file changed, 2
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
So far, we are creating devices directly under
/sys/bus/pci/devices/*. There is not much problem with it, but if
we really want to model kernel behaviour we need to create them
under /sys/devices/pci:BB and
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
So far, we don't need to create anything under
/sys/kernel/iommu_groups/N/devices directory (which is symlinked
from /sys/bus/pci/devices/:BB:DD.F/iommu_group directory)
because virhostdevtest still tests the
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
It may happen that there are two domains with the same name in
two separate drivers (e.g. qemu and lxc). That is why for PCI
devices we track both names of driver and domain combination
which has taken the device.
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
Have just one function to generate path to a PCI driver so that
when we change it in near future there's only few of the places
we need to fix.
Signed-off-by: Michal Privoznik
---
tests/virpcimock.c | 34
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
Have just one function to generate path to a PCI device so that
when we change it in near future there's only few of the places
we need to fix.
Signed-off-by: Michal Privoznik
---
tests/virpcimock.c | 42
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
We will need to create more directories and instead of
introducing bunch of new variables to hold their actual
paths, we can have one and reuse it.
Signed-off-by: Michal Privoznik
---
tests/virpcimock.c | 10
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
It saves us couple of lines.
Signed-off-by: Michal Privoznik
---
tests/virpcimock.c | 109 +++--
1 file changed, 36 insertions(+), 73 deletions(-)
diff --git
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
When creating a PCI device, the pciDevice structure contains @id
member which holds device address (.BB:DD.F) and is type of
'char *'. But the structure is initialized from a const char and
in fact we never
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
Newer kernels (v3.16-rc1~29^2~6^4) have 'driver_override' file
which simplifies way of binding a PCI device to desired driver.
Libvirt has support for this for some time too (v2.3.0-rc1~236),
but not our
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
The @fakesysfspcidir is derived from @fakerootdir. We don't need
two global variables that contain nearly the same content,
especially when we construct the actual path anyways.
Signed-off-by: Michal Privoznik
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
This reverts commit b70c093ffa00cd87c8d39d3652b798f033a81faf.
In next commit the virpcimock is going to be extended and thus
binding a PCI device to vfio-pci driver will finally succeed.
Remove this test as it
Reviewed-by: Daniel Henrique Barboza
On 8/14/19 8:57 AM, Michal Privoznik wrote:
The pci_driver_bind() and pci_driver_unbind() functions are
"internal implementation", meaning other parts of the code should
be able to call them and get the job done. Checking for actions
(PCI_ACTION_BIND and
On 8/14/19 8:57 AM, Michal Privoznik wrote:
In upcoming patches we will need only some portions of the PCI
address. To construct that easily, it's better if the PCI address
of a device is stored as four integers rather than one string.
Signed-off-by: Michal Privoznik
---
On 8/14/19 8:57 AM, Michal Privoznik wrote:
In near future, we will be creating devices under different
location and just symlink them under devices/. Just like real
kernel does. But for that we need the directories to exists.
nit: s/exists/exist
Signed-off-by: Michal Privoznik
---
On Fri, Aug 16, 2019 at 05:57:36PM +0300, Ilias Stamatis wrote:
> On Fri, Aug 16, 2019 at 5:39 PM Erik Skultety wrote:
> >
> > ...
> >
> > > +
> > > +if (operation == TEST_DEVICE_DETACH)
> > > +parse_flags |= VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE;
> >
> > ^This should be added by patch
Commit fb64e176f4f forgot to delete the check that short-circuits the
disk alias creation if the alias is already present. The side efect
of this is that the creation qomName which is necessary to be able to
refer to disk frontends when -blockdev is used was skipped when user
aliases are used.
The fact that you are modifying this code implies that you are using it,
and that implies that you are still using legacy KVM device assignment
(i.e. the pcistub driver) instead of VFIO device assignment. (I say this
because the function that calls this function you've patched,
This is a workaround needed as a set of MinGW packages got removed from
Fedora Rawhide. We have to keep this workaround till the packages are
not un-retired/re-added.
Signed-off-by: Fabiano Fidêncio
---
refresh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/refresh
Let's refresh the archived Dockerfiles in order to have the fedora-30
containers performing the MinGW builds (instead of the fedora-rawhide
ones).
Signed-off-by: Fabiano Fidêncio
---
buildenv-libosinfo-centos-7.zip | Bin 458 -> 458 bytes
Due to a recent removal of mingw packages on Rawhide, let's use
Fedora 30 machines to perform MinGW builds till the packages
are un-retired/re-added in Rawhide.
Fabiano Fidêncio (2):
refresh: Use fedora-30 to perform MinGW builds
Refresh archived Dockerfiles
buildenv-libosinfo-centos-7.zip
As a set of MinGW packages ended up removed from Fedora Rawhide, let's
move the MinGW builds to Fedora 30 till the packages are back to
rawhide.
Signed-off-by: Fabiano Fidêncio
---
jenkins/jobs/defaults.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
MinGW packages are available in all Fedora releases, not only in
Rawhide.
Signed-off-by: Fabiano Fidêncio
---
guests/vars/mappings.yml | 108 +++
1 file changed, 54 insertions(+), 54 deletions(-)
diff --git a/guests/vars/mappings.yml
Due to a recent removal of mingw packages on Rawhide, let's use
Fedora 30 machines to perform MinGW builds till the packages
are un-retired/re-added in Rawhide.
Fabiano Fidêncio (3):
mappings: MinGW packages are not Fedora Rawhide specific
guests: Move MinGW builds to fedora-30
jenkins: Set
As a set of MinGW packages ended up removed from Fedora Rawhide, let's
move the MinGW builds to Fedora 30 till the packages are back to
Rawhide.
Signed-off-by: Fabiano Fidêncio
---
guests/host_vars/libvirt-fedora-30/main.yml | 10 ++
guests/host_vars/libvirt-fedora-rawhide/main.yml
On Fri, Aug 16, 2019 at 5:39 PM Erik Skultety wrote:
>
> ...
>
> > +
> > +if (operation == TEST_DEVICE_DETACH)
> > +parse_flags |= VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE;
>
> ^This should be added by patch 3/5
>
> > +
> > +if (xml) {
> > +if (!(dev =
On Wed, Aug 14, 2019 at 07:47:10PM +0300, Ilias Stamatis wrote:
> Signed-off-by: Ilias Stamatis
> ---
> src/test/test_driver.c | 72 ++
> 1 file changed, 72 insertions(+)
>
> diff --git a/src/test/test_driver.c b/src/test/test_driver.c
> index
On Wed, Aug 14, 2019 at 07:47:09PM +0300, Ilias Stamatis wrote:
> Signed-off-by: Ilias Stamatis
> ---
Reviewed-by: Erik Skultety
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
> +
> +virDomainShmemDefFree(virDomainShmemDefRemove(vmdef, idx));
> +break;
> +
^Extra line
Reviewed-by: Erik Skultety
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
...
> +
> +if (operation == TEST_DEVICE_DETACH)
> +parse_flags |= VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE;
^This should be added by patch 3/5
> +
> +if (xml) {
> +if (!(dev = virDomainDeviceDefParse(xml, def,
> +driver->caps,
We require that 'auto-read-only' is dynamic for posix-file backeds this
prevents problems with libvirt's usage of sVirt where we don't grant
qemu permissions to write backing chain until it's needed.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_capabilities.c | 3 +
Initial implementation of 'auto-read-only' didn't reopen the backing
files when needed. For '-blockdev' to work we need to be able to tel
qemu to open a file read-only and change it during blockjobs as we label
backing chains with a sVirt label which does not allow writing. The
dynamic
With the patches I've posted to the list libvirt should be mostly
prepared to use -blockdev instead of -drive to specify disk images.
There's one gothcha though. Internal snapshots don't work due to qemu
considering every monitor-owned node for snapshot as well. With blockdev
everything became
On Wed, Aug 14, 2019 at 07:47:08PM +0300, Ilias Stamatis wrote:
> Signed-off-by: Ilias Stamatis
> ---
> src/test/test_driver.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/test/test_driver.c b/src/test/test_driver.c
> index ff9693ccb7..1152ca5bed 100755
> ---
On Fri, 2019-08-16 at 15:51 +0200, Andrea Bolognani wrote:
> On Fri, 2019-08-16 at 14:32 +0200, Fabiano Fidêncio wrote:
> > On Mon, 2019-08-12 at 16:09 +0200, Andrea Bolognani wrote:
> > > This is connected to
> > >
> > > https://www.redhat.com/archives/libvir-list/2019-August/msg00399.html
> > >
On Wed, Aug 14, 2019 at 07:47:06PM +0300, Ilias Stamatis wrote:
> Signed-off-by: Ilias Stamatis
> ---
> src/test/test_driver.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/test/test_driver.c b/src/test/test_driver.c
> index 5f28e9017f..abf80b97cf 100755
> ---
Use the code for creating or attaching new storage source in the
snapshot code and switch to 'blockdev-snapshot' for creating the
snapshot itself.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 104 ++---
1 file changed, 88 insertions(+), 16
With blockdev we'll be able to support protocols which are not supported
by the storage backends in libvirt. This means that we have to be able
to skip the creation and relative storage path reading if it's not
supported. This will make it impossible to use relative backing for
network protocols
After we always assume support for the 'transaction' command
(c358adc57113b) and follow-up cleanups
qemuDomainSnapshotCreateSingleDiskActive lost it's value. Move the code
into appropriate helpers and remove the function.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 53
Remove libvit's support check for the target of an external snapshot to
the blockdev code or qemu. This will potentially require a more complex
cleanup but removes a level of hardcoded feature checks.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 16
1 file changed,
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 9248f912d0..0bbde4b52d 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -15366,16
Move the internals into qemuDomainSnapshotDiskDataCollectOne to make it
obvious what's happening after moving more code here.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 104 +++--
1 file changed, 59 insertions(+), 45 deletions(-)
diff --git
Refactor the code to avoid having a cleanup label. This will simplify
the change necessary when restricting this check in an upcoming patch.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git
dd->src is always allocated in this function as it contains the new
source for the snapshot which is meant to replace the disk source.
The label handling code executed if that source was not present thus is
dead code. Remove it.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 7
Soon we'll allow more protocols and storage types with snapshots where
we in some cases can't check whether the storage already exists.
Restrict the sanity checks whether the destination images exist or not
for local storage where it's easy. For any other case we will fail
later.
Signed-off-by:
While the VM is running the persistent source of a disk might differ
e.g. as the 'newDef' was redefined. Our snapshot code would blindly
rewrite the source of such disk if it shared the 'target'. Fix this by
checking whether the source is the same in the first place.
Signed-off-by: Peter Krempa
Peter Krempa (10):
qemu: snapshot: Don't modify persistent XML if disk source is
different
qemu: driver: Remove dead code from
qemuDomainSnapshotUpdateDiskSources
qemu: Remove cleanup label in qemuDomainSnapshotPrepareDiskExternal
qemu: snapshot: Restrict file existance check only
On Fri, 2019-08-16 at 11:49 +0200, Andrea Bolognani wrote:
> See the individual commits for details, but the gist of it is that
> after this series it's possible for users to hook into the build
> process and customize it according to their needs; on top of that,
> the whole thing is made more
On Fri, 2019-08-16 at 14:32 +0200, Fabiano Fidêncio wrote:
> On Mon, 2019-08-12 at 16:09 +0200, Andrea Bolognani wrote:
> > This is connected to
> >
> > https://www.redhat.com/archives/libvir-list/2019-August/msg00399.html
> >
> >
16.08.2019 15:33, Markus Armbruster wrote:
> Kevin Wolf writes:
>
>> Am 15.08.2019 um 21:24 hat Markus Armbruster geschrieben:
> [...]
>>> Let's assume all libvirt ever does with deprecation notices is logging
>>> them. Would that solve the problem of reliably alerting libvirt
>>> developers to
On 7/25/19 8:09 PM, Daniel Henrique Barboza wrote:
>
Huh, looks like we have came across same bugs recently. Well, great
minds think alike :D
So I guess the resolution might be this: I'll merge my patches as soon
as I get review and then you can repost your patches (it's going to be
shorter
On 7/25/19 8:09 PM, Daniel Henrique Barboza wrote:
From: Shivaprasad G Bhat
The pci-stub is obsolete for a while now. Upcoming test cases try
to test the VFIO hotplug/unplug cases.
Change the default test driver to vfio-pci instead of pci-stub,
and fail bind for pci-stub instead.
On 7/25/19 8:09 PM, Daniel Henrique Barboza wrote:
From: Shivaprasad G Bhat
The mocked path falls into /sys/bus/kernel/iommu_groups instead of
/sys/kernel/iommu_groups. Needed for adding some new test cases.
Signed-off-by: Shivaprasad G Bhat
Signed-off-by: Daniel Henrique Barboza
---
On 7/25/19 8:09 PM, Daniel Henrique Barboza wrote:
From: Shivaprasad G Bhat
Signed-off-by: Shivaprasad G Bhat
Signed-off-by: Daniel Henrique Barboza
---
src/util/virprocess.h | 2 +-
tests/Makefile.am | 7 +++
tests/qemuhotplugtest.c
On 7/25/19 8:09 PM, Daniel Henrique Barboza wrote:
From: Shivaprasad G Bhat
There are already good number of test cases with hostdevices,
few have multifunction devices but none having more than one
than one multifunction cards.
This patch adds a case where there are two multifunction cards
On 7/25/19 8:09 PM, Daniel Henrique Barboza wrote:
From: Shivaprasad G Bhat
The iommu group, /dev/vfio/ behaviors
of the host are mocked. This patch implements support for
multifunction/multiple devices per iommu groups and emulates
the /dev/vfio/ file correctly.
This code helps adding
On 7/25/19 8:09 PM, Daniel Henrique Barboza wrote:
The current virHostdevPreparePCIDevices code fails to detect an unmanaged
VFIO device that is in the activePCIHostdevs, and active in the same
domain name as dom_name, as a device in use. Considering a call to this
function, when
Kevin Wolf writes:
> Am 15.08.2019 um 21:24 hat Markus Armbruster geschrieben:
[...]
>> Let's assume all libvirt ever does with deprecation notices is logging
>> them. Would that solve the problem of reliably alerting libvirt
>> developers to deprecation issues? Nope. But it could help
>>
On Mon, 2019-08-12 at 16:09 +0200, Andrea Bolognani wrote:
> Since libvirt-dockerfile's commit 7130ffe0a0e9, the containers
> used for CI builds have been renamed from buildenv-* to
> buildenv-libvirt-* in order to make it possible for projects
> other than libvirt to be supported, so we need to
On Mon, 2019-08-12 at 14:28 +0200, Andrea Bolognani wrote:
> See commit 1/3 for more information.
>
> Andrea Bolognani (3):
> refresh: Generate archived Dockerfiles
> Remove plain Dockerfiles
> Add archived Dockerfiles
>
Reviewed-by: Fabiano Fidêncio
--
libvir-list mailing list
On Mon, 2019-08-12 at 15:35 +0200, Andrea Bolognani wrote:
> Once [1] has been merged, we'll be able to conveniently cause
> container images to be rebuilt without having to define custom
> triggers.
>
> [1]
> https://www.redhat.com/archives/libvir-list/2019-August/msg00399.html
>
> Andrea
On 8/16/19 5:59 AM, Michal Privoznik wrote:
On 8/14/19 6:14 PM, Daniel Henrique Barboza wrote:
Michal, I believe the problem you're trying to fix in this patch
is somehow the same I'm trying to fix in this patch here:
https://www.redhat.com/archives/libvir-list/2019-June/msg01270.html
Do
Introduce new semantics to virStorageSourceNewFromBacking and some
of the helpers used by it which propagate the return value from the
callers.
The new return value introduced by this patch allows to notify the
calller that the parsed virStorageSource correctly describes the source
but contains
While it's a bad idea to use userinfo to pass credentials via an URI add
a test that we at least do the correct thing.
Signed-off-by: Peter Krempa
---
tests/viruritest.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/viruritest.c b/tests/viruritest.c
index d419711135..3255e2333a
Automatically free the 'root' temporary variable to get rid fo some
complexity.
Signed-off-by: Peter Krempa
---
src/util/virstoragefile.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
index
Automatically clean the 'uri' variable and get rid of the 'cleanup'
label.
Signed-off-by: Peter Krempa
---
src/util/virstoragefile.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
index
Return the parsed storage source via an pointer in arguments and return
an integer from the function. Describe the semantics with a comment for
the function and adjust callers to the new semantics.
Signed-off-by: Peter Krempa
---
src/util/virstoragefile.c | 43
Using inline authentication for storage volumes will not work properly
as libvirt requires use of the secret driver for the auth data and
thus would not be able to represent the passwords stored in the backing
store string.
Make sure that the backing store parsers return 1 which is a sign for
the
virStorageFileGetMetadata does not report error if we can't interrogate
the file somehow. Clarify this in the description of the @report_broken
flag as it implies we should report an error in that case. The problem
is that we don't know whether there's a problem and unforntnately just
offload it
Automatically clean the temporary buffer and get rid of the cleanup
label.
Signed-off-by: Peter Krempa
---
tests/virstoragetest.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/tests/virstoragetest.c b/tests/virstoragetest.c
index
virStorageFileGetMetadataRecurse would include in the backing chain
files which would not really be usable by libvirt directly e.g. when
such file would be promoted to the top layer by a active block commit as
for example inline authentication data can't be represented in the VM
xml file. The idea
If a backing file string contains authentication data, many things can
break as libvirt is not tracking it since we use the secret driver for
this.
Stop considering such files as viable backing store entries.
Peter Krempa (14):
util: storage: Simplify cleanup path handling in
virStorageSourceParseBackingURI will report special return values in
some cases. Preserve it in virStorageSourceParseBackingJSONUriStr.
Signed-off-by: Peter Krempa
---
src/util/virstoragefile.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/util/virstoragefile.c
Return the storage source definition via a pointer in the arguments and
document the returned values. This will simplify the possibility to
ignore certain backing store types which are not representable by
libvirt.
Signed-off-by: Peter Krempa
---
src/storage/storage_util.c | 2 +-
There is no cleanup code.
Signed-off-by: Peter Krempa
---
src/util/virstoragefile.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
index 520f531088..8af45bfbd2 100644
--- a/src/util/virstoragefile.c
Modiy testBackingParse to allow testing other return values of the
backing store string parser.
Signed-off-by: Peter Krempa
---
tests/virstoragetest.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/tests/virstoragetest.c b/tests/virstoragetest.c
Automatically free the intermediate JSON data to get rid of the cleanup
section.
Signed-off-by: Peter Krempa
---
src/util/virstoragefile.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
index
Now that we have a home directory for the user, storing the
source there rather than in a custom top-level directory is
the obvious choice.
Later on we're also going to add some more files related to
builds, and storing everything in the user's home directory
will keep things nice and tidy.
In order for the prepare script to be really useful, it needs
to be able to perform privileged operations such as installing
additional packages or setting up custom mount points.
In order to achieve that, we now run the container as root,
run the prepare script with full privilege, and only then
Both for ci-build and ci-shell we want to execute basically
the same setup and cleanup logic, the only difference being
that for the former we then run the build script and with the
latter a shell.
Rework the targets so that they both call the generic
ci-run-command rule passing an appropriate
Now that we're using sudo, the initial work directory is no
longer relevant since the user will find themselves in their
home directory when they get control anyway.
Signed-off-by: Andrea Bolognani
---
ci/Makefile | 2 --
1 file changed, 2 deletions(-)
diff --git a/ci/Makefile b/ci/Makefile
We're going to have a few more CI-related files in a second, and
it makes sense to have a separate directory for them rather than
littering the root directory.
$(CI_SCRATCHDIR) can now also be created inside the CI directory,
and as a bonus the make rune necessary to start CI builds without
The $ needs to be escaped when calling shell code from a
Makefile.
Signed-off-by: Andrea Bolognani
---
Makefile.ci | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile.ci b/Makefile.ci
index 977e0445c6..14d595a00f 100644
--- a/Makefile.ci
+++ b/Makefile.ci
@@ -114,8
Instead of hardcoding build instructions into the Makefile,
move them to a separate script that's mounted into the
container.
This gives us a couple of advantages: we no longer have to
deal with the awkward quoting required when embedding shell
code in a Makefile, and we also provide the users
This script is run before $(CI_BUILD_SCRIPT) and can be used
to tweak the environment as necessary before the build starts.
Signed-off-by: Andrea Bolognani
---
Makefile.am | 1 +
ci/Makefile | 8 +++-
ci/prepare.sh | 9 +
3 files changed, 17 insertions(+), 1 deletion(-)
create
We only use the list of submodules once, so no need to
store it in a variable.
Signed-off-by: Andrea Bolognani
---
Makefile.ci | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/Makefile.ci b/Makefile.ci
index 14d595a00f..86e936aef8 100644
--- a/Makefile.ci
+++
See the individual commits for details, but the gist of it is that
after this series it's possible for users to hook into the build
process and customize it according to their needs; on top of that,
the whole thing is made more maintainable in the process.
Andrea Bolognani (10):
ci: Fix
Some applications expect the user's home directory to be
present on the system and require workarounds when that's not
the case. Creating the home directory along with everything
else is easy enough for us, so let's just do that.
Signed-off-by: Andrea Bolognani
---
ci/Makefile | 15
---
src/domain.rs | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/domain.rs b/src/domain.rs
index 11ecb3c..acb9e6e 100644
--- a/src/domain.rs
+++ b/src/domain.rs
@@ -136,7 +136,7 @@ extern "C" {
fn virDomainGetHostname(ptr: sys::virDomainPtr, flags:
On 8/14/19 5:14 PM, Daniel Henrique Barboza wrote:
I've run make check with each individual patch, and everything
seems fine in my environment.
For all patches:
Tested-by: Daniel Henrique Barboza
I'll see if I can drop some code reviews later on.
That'd be great because we are lacking
On 8/14/19 6:14 PM, Daniel Henrique Barboza wrote:
Michal, I believe the problem you're trying to fix in this patch
is somehow the same I'm trying to fix in this patch here:
https://www.redhat.com/archives/libvir-list/2019-June/msg01270.html
Do you mind taking a look? If that's the case, I
On 8/15/19 11:44 AM, hexin900...@163.com wrote:
From: hexin
The parent bridge configuration of the current device
should be read and reset, instead of reading the current
device configuration.
Signed-off-by: He Xin
Signed-off-by: Liu Qi
Signed-off-by: Zhang Yu
---
src/util/virpci.c | 2
On 8/16/19 4:41 AM, Laine Stump wrote:
The first patch fixes the bug. The 2nd patch just updates some code
that I noticed while fixing the bug (because I figured someone would
whine that I was just moving around calls to outdated APIs).
Laine Stump (2):
network: fix crash during cleanup from
On 8/15/19 10:42 PM, Laine Stump wrote:
Commit e69444e17 (first appeared in libvirt-5.5.0) added the new value
"VIR_ACCESS_PERM_NETWORK_SEARCH_PORTS" to the virAccessPerNetwork
enum, and also the string "search_ports" to the VIR_ENUM_IMPL() macro
for that enum. Unfortunately, the enum value was
Am 15.08.2019 um 21:24 hat Markus Armbruster geschrieben:
> Kevin Wolf writes:
>
> > Am 15.08.2019 um 18:07 hat John Snow geschrieben:
> >>
> >>
> >> On 8/15/19 6:49 AM, Kevin Wolf wrote:
> >> > Am 14.08.2019 um 21:27 hat John Snow geschrieben:
> >> >>
> >> >>
> >> >> On 8/14/19 6:07 AM,
On Fri, Aug 16, 2019 at 09:52:02 +0200, Erik Skultety wrote:
> On Fri, Aug 16, 2019 at 09:43:27AM +0200, Peter Krempa wrote:
> > In some cases e.g. with clang on fedora 30 __open2 isn't even declared
> > which results in the following build error:
> >
> >
1 - 100 of 103 matches
Mail list logo
