On Fri, 2020-05-01 at 11:58 +0100, Daniel P. Berrangé wrote:
> This removes the locally maintained DCO checking script in favour of the
> shared containre image provided by libvirt-ci.git.
*container
Reviewed-by: Andrea Bolognani
--
Andrea Bolognani / Red Hat / Virtualization
On Fri, May 01, 2020 at 05:56:23PM +0200, Pavel Hrdina wrote:
> On Fri, May 01, 2020 at 10:20:03AM +0100, Daniel P. Berrangé wrote:
> > The python build needs to validate two axis
> >
> > - A variety of libvirt versions
> > - A variety of python versions
> >
> > We get coverage for both these a
On Fri, May 01, 2020 at 12:57:54PM -0300, Daniel Henrique Barboza wrote:
>
>
> On 5/1/20 7:40 AM, Daniel P. Berrangé wrote:
> > On Thu, Apr 30, 2020 at 09:00:51PM -0300, Daniel Henrique Barboza wrote:
> > >
> > > My initial plan is to get the logic/APIs design from Libvirt, rename
> > > them in
On 5/1/20 7:40 AM, Daniel P. Berrangé wrote:
On Thu, Apr 30, 2020 at 09:00:51PM -0300, Daniel Henrique Barboza wrote:
My initial plan is to get the logic/APIs design from Libvirt, rename
them in a Gopher fashion, re-code it with Go and call it a day :)
That is really not a way I would like
On Fri, May 01, 2020 at 10:20:03AM +0100, Daniel P. Berrangé wrote:
> The python build needs to validate two axis
>
> - A variety of libvirt versions
> - A variety of python versions
>
> We get coverage for both these axis by running a build against the
> distro provided libvirt packages. All t
On Wed, Apr 22, 2020 at 07:51:09AM +0200, Anders Östling wrote:
> I am fighting to understand the difference between backing up a VM by
> using a regular copy vs using the virsh blockcopy command.
> What I want to do is to suspend the vm, copy the XML and .QCOW2 files
> and then resume the vm again
On Fri, May 01, 2020 at 11:04:13AM +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 28, 2020 at 03:25:47PM +0200, Daniel Veillard wrote:
> > We are getting close to the end of the month, so I tagged RC1 in git
> > and pushed signed source tarball and rpms to the usual place:
> >
> >https://lib
On Fri, 2020-05-01 at 14:09 +0100, Daniel P. Berrangé wrote:
> On Fri, May 01, 2020 at 02:30:16PM +0200, Andrea Bolognani wrote:
> > Not mocking this function results in files being created in the
> > user's home directory when running the test and in the build
> > failing altogether inside a const
On Fri, May 01, 2020 at 02:13:26PM +0100, Daniel P. Berrangé wrote:
> With the introduce of automated CI pipelines, we are now ready to switch
s/introduce/introduction/
> to using merge requests for the project. With this switch we longer wish
> to have patches sent to the mailing list, and thus
With the introduce of automated CI pipelines, we are now ready to switch
to using merge requests for the project. With this switch we longer wish
to have patches sent to the mailing list, and thus the git-publish
config is removed.
Signed-off-by: Daniel P. Berrangé
---
.gitpublish | 4
On Fri, May 01, 2020 at 02:30:16PM +0200, Andrea Bolognani wrote:
> Not mocking this function results in files being created in the
> user's home directory when running the test and in the build
> failing altogether inside a constrained environment such as the
> one used by pbuilder:
What's pbuild
On Fri, 2020-05-01 at 11:04 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 28, 2020 at 03:25:47PM +0200, Daniel Veillard wrote:
> > We are getting close to the end of the month, so I tagged RC1 in git
> > and pushed signed source tarball and rpms to the usual place:
> >
> >https://libvirt.or
Not mocking this function results in files being created in the
user's home directory when running the test and in the build
failing altogether inside a constrained environment such as the
one used by pbuilder:
Could not initialize HostdevManager - operation failed: Failed
to create state dir
On Fri, May 01, 2020 at 11:52:32AM +0100, Daniel P. Berrangé wrote:
> The "go fmt" code style checking tool is something we wish to run on all
> Go code, so it is useful to have a common container that can be used by
> all relevant projects.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> .gitlab-
This removes the locally maintained DCO checking script in favour of the
shared containre image provided by libvirt-ci.git.
Signed-off-by: Daniel P. Berrangé
---
.gitlab-ci.yml | 21 -
scripts/require-dco.py | 99 --
2 files changed, 9 inse
The "go fmt" code style checking tool is something we wish to run on all
Go code, so it is useful to have a common container that can be used by
all relevant projects.
Signed-off-by: Daniel P. Berrangé
---
.gitlab-ci.yml | 5 +
containers/go-fmt/Dockerfile | 9 +
cont
Signed-off-by: Daniel P. Berrangé
---
.gitlab-ci.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 6de69d6..a1ac31a 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -17,7 +17,7 @@ stages:
after_script:
- docker logout
-build
This common container will be used across all our Go based projects
Daniel P. Berrangé (2):
gitlab: rename job for building check-dco container
containers: add a standard container for running go fmt
.gitlab-ci.yml | 7 ++-
containers/go-fmt/Dockerfile | 9 +
cont
On Thu, Apr 30, 2020 at 09:00:51PM -0300, Daniel Henrique Barboza wrote:
>
> My initial plan is to get the logic/APIs design from Libvirt, rename
> them in a Gopher fashion, re-code it with Go and call it a day :)
That is really not a way I would like to go, as that means we immediately
inherit t
On Thu, Apr 30, 2020 at 03:14:09PM -0400, Laine Stump wrote:
> Here are two things that would help enable me to make useful contributions:
>
>
> 1) a basic "source tree for a go library" setup in a libvirt-subproject on
> gitlab (since gitlab is the official location of libvirt projects now),
> i
On Thu, Apr 30, 2020 at 03:20:19PM -0300, Daniel Henrique Barboza wrote:
>
>
> On 3/19/20 4:00 PM, Laine Stump wrote:
> > TL;DR - I'm not as anti-XML as the proposal seems to be, but also not
> > pro-XML. I also (after thinking about it) understand the advantage of
> > putting this in a separat
On Tue, Apr 28, 2020 at 03:25:47PM +0200, Daniel Veillard wrote:
> We are getting close to the end of the month, so I tagged RC1 in git
> and pushed signed source tarball and rpms to the usual place:
>
>https://libvirt.org/sources/
>
> Seems to work fine in my very limited testing, CI seems
On Fri, 2020-05-01 at 10:20 +0100, Daniel P. Berrangé wrote:
> +.build_git_job_template: &build_git_job_definition
> + image: $CI_REGISTRY_IMAGE/ci-$NAME:latest
> + stage: builds
This should be git_build_job_template...
> +.build_dist_job_template: &build_dist_job_definition
> + image: $CI_REG
"allows to" -> "allows one to"
Spotted by Lintian (spelling-error-in-manpage tag).
Signed-off-by: Andrea Bolognani
---
Pushed as trivial.
docs/manpages/virsh.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst
index dc
On Thu, Apr 30, 2020 at 07:19:07PM +0200, Andrea Bolognani wrote:
> On Thu, 2020-04-30 at 15:14 +0100, Daniel P. Berrangé wrote:
> > +++ b/.gitlab-ci.yml
> > @@ -0,0 +1,171 @@
> > +
> > +stages:
> > + - prebuild
> > + - containers
> > + - build
>
> Should this stage be called "builds", just lik
The python build needs to validate two axis
- A variety of libvirt versions
- A variety of python versions
We get coverage for both these axis by running a build against the
distro provided libvirt packages. All that is then missing is a build
against the latest libvirt git master, which only n
This introduces GitLab CI to the python module. Traditional Jenkins has
validated the python build across all distros, using libvirt git. This
tested one axis - a variety of python versions - but failed to test the
other interesting axis - a variety of libvirt versions.
This new CI setup fixes tha
On Ubuntu 18.04 with libvirt 4.0.0 libvirt-python build fails
running test
/usr/bin/python3 sanitytest.py build/lib.linux-x86_64-3.6
/usr/share/libvirt/api/libvirt-api.xml
Cannot get a value of enum VIR_TYPED_PARAM_BOOLEAN (originally
VIR_DOMAIN_BLKIO_PARAM_BOOLEAN)
Cannot get a value of enum VI
Now that we're standardizing on GitLab CI for both official gating CI
and developer CI, there's no compelling reason to continue to support
Travis CI.
Reviewed-by: Andrea Bolognani
Signed-off-by: Daniel P. Berrangé
---
.travis.yml | 55 -
1 fi
^ since 5.6.0
On Thu, Apr 30, 2020 at 04:35:32PM -0400, Laine Stump wrote:
> To make it simpler to answer questions of "Why doesn't this thing work
> for me?"
>
> Signed-off-by: Laine Stump
> ---
> docs/formatnetwork.html.in | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
On Thu, Apr 30, 2020 at 09:28:08PM +0200, Andrea Bolognani wrote:
> See patch 4/4.
>
> Andrea Bolognani (4):
> containers: New top-level directory
> check-dco: Fix script name in top comment
> check-dco: Change remote name
> check-dco: Support namespaces other than libvirt
>
> .gitlab-ci
The waiting time to acquire the lock times out, which leads to a segment fault.
In essence we should make improvements around locks, but as a workaround we
will change the timeout to allow the user to increase it.
This value was defined as 30 seconds, so use it as the default value.
The logs are as
32 matches
Mail list logo