<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/libvirt-python.git/ci, branch v9.3.0</title>
<subtitle>libvirt.org: git/libvirt-python.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libvirt-python.git/'/>
<entry>
<title>ci: pass --break-system-packages on Debian Sid</title>
<updated>2023-04-19T10:32:03+00:00</updated>
<author>
<name>Daniel P. Berrangé</name>
<email>berrange@redhat.com</email>
</author>
<published>2023-04-19T09:27:08+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libvirt-python.git/commit/?id=62a4c1f395eebb3d693df35514eabd6580bd0bdb'/>
<id>62a4c1f395eebb3d693df35514eabd6580bd0bdb</id>
<content type='text'>
Debian Sid python packages block users from installing packages using
pip unless using a venv. A venv has no benefit when we are running in
a throwaway container which has no need for software upgrades.

Signed-off-by: Daniel P. Berrangé &lt;berrange@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Debian Sid python packages block users from installing packages using
pip unless using a venv. A venv has no benefit when we are running in
a throwaway container which has no need for software upgrades.

Signed-off-by: Daniel P. Berrangé &lt;berrange@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ci: mark bleeding edge distros as non-gating</title>
<updated>2023-04-19T09:25:34+00:00</updated>
<author>
<name>Daniel P. Berrangé</name>
<email>berrange@redhat.com</email>
</author>
<published>2023-04-19T09:25:34+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libvirt-python.git/commit/?id=664c347534c093dd541f60affd30bc1c4572d776'/>
<id>664c347534c093dd541f60affd30bc1c4572d776</id>
<content type='text'>
Fedora Rawhide, Debian Sid and OpenSUSE Tumbleweed are all liable to
have sporadic failures due to being bleeding edge distros. Thus they
should not gate contributor changes that are otherwise correct.

Signed-off-by: Daniel P. Berrangé &lt;berrange@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fedora Rawhide, Debian Sid and OpenSUSE Tumbleweed are all liable to
have sporadic failures due to being bleeding edge distros. Thus they
should not gate contributor changes that are otherwise correct.

Signed-off-by: Daniel P. Berrangé &lt;berrange@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ci: regenerated with lcitool manifest</title>
<updated>2023-04-19T09:23:57+00:00</updated>
<author>
<name>Daniel P. Berrangé</name>
<email>berrange@redhat.com</email>
</author>
<published>2023-04-19T09:23:57+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libvirt-python.git/commit/?id=6e1351b4c0392cad716520808d4eac4bcc69c855'/>
<id>6e1351b4c0392cad716520808d4eac4bcc69c855</id>
<content type='text'>
This replaces OpenSUSE Leap 15.3 with 15.4

Signed-off-by: Daniel P. Berrangé &lt;berrange@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This replaces OpenSUSE Leap 15.3 with 15.4

Signed-off-by: Daniel P. Berrangé &lt;berrange@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ci: manifest: Define RPM artifacts for regular CentOS Stream 8 build</title>
<updated>2023-01-06T14:58:57+00:00</updated>
<author>
<name>Erik Skultety</name>
<email>eskultet@redhat.com</email>
</author>
<published>2023-01-06T10:17:31+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libvirt-python.git/commit/?id=d75be368770315c04db70dda330dd9b57a871840'/>
<id>d75be368770315c04db70dda330dd9b57a871840</id>
<content type='text'>
Commit 7360326 missed the fact that artifacts were only defined for the
libvirt Git type of libvirt-python build (git is cloned, libvirt is
built and then libvirt-python) based on the
'native_git_build_job_prebuilt_env' job template whereas libvirt CI
expects the RPM artifacts to come from a job based on the
'native_build_job' template instead.

Note that this patch is a hotfix to something which requires a proper
cleanup to stay consistent with the way we're handling the same thing
in libvirt-perl.

Signed-off-by: Erik Skultety &lt;eskultet@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 7360326 missed the fact that artifacts were only defined for the
libvirt Git type of libvirt-python build (git is cloned, libvirt is
built and then libvirt-python) based on the
'native_git_build_job_prebuilt_env' job template whereas libvirt CI
expects the RPM artifacts to come from a job based on the
'native_build_job' template instead.

Note that this patch is a hotfix to something which requires a proper
cleanup to stay consistent with the way we're handling the same thing
in libvirt-perl.

Signed-off-by: Erik Skultety &lt;eskultet@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ci: manifest: Define artifacts cache</title>
<updated>2023-01-05T07:33:02+00:00</updated>
<author>
<name>Erik Skultety</name>
<email>eskultet@redhat.com</email>
</author>
<published>2023-01-05T07:30:07+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libvirt-python.git/commit/?id=736032627204377507ffc0607650412cc7971bf1'/>
<id>736032627204377507ffc0607650412cc7971bf1</id>
<content type='text'>
After commit 6e0d4d53 we lost RPM artifacts cache breaking the whole
integration CI. The reason for that is that we manually defined the
artifacts cache in gitlab.yml instead of manifest.yml. Naturally with
the next lcitool update, gitlab.yml got overwritten according to
manifest.yml which didn't define any artifacts cache.

Fixes: 6e0d4d53d51e8aa9d537e404a886eab131e311cc

Signed-off-by: Erik Skultety &lt;eskultet@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After commit 6e0d4d53 we lost RPM artifacts cache breaking the whole
integration CI. The reason for that is that we manually defined the
artifacts cache in gitlab.yml instead of manifest.yml. Naturally with
the next lcitool update, gitlab.yml got overwritten according to
manifest.yml which didn't define any artifacts cache.

Fixes: 6e0d4d53d51e8aa9d537e404a886eab131e311cc

Signed-off-by: Erik Skultety &lt;eskultet@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ci: manifest: Replace 'expiry' with 'expire_in'</title>
<updated>2023-01-05T07:28:12+00:00</updated>
<author>
<name>Erik Skultety</name>
<email>eskultet@redhat.com</email>
</author>
<published>2023-01-05T07:28:12+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libvirt-python.git/commit/?id=68ee98137995afe32a907bd90318035b0b10b8b6'/>
<id>68ee98137995afe32a907bd90318035b0b10b8b6</id>
<content type='text'>
'expiry' isn't a keyword in lcitool anymore, the only reason why
everything has kept working despite lcitool updates is that lcitool
sets 'expire_in' to 2 days by default.

Signed-off-by: Erik Skultety &lt;eskultet@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
'expiry' isn't a keyword in lcitool anymore, the only reason why
everything has kept working despite lcitool updates is that lcitool
sets 'expire_in' to 2 days by default.

Signed-off-by: Erik Skultety &lt;eskultet@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ci: Refresh and add Fedora 37 target</title>
<updated>2023-01-04T14:06:09+00:00</updated>
<author>
<name>Erik Skultety</name>
<email>eskultety@ridgehead.home.lan</email>
</author>
<published>2023-01-04T14:06:09+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libvirt-python.git/commit/?id=6e0d4d53d51e8aa9d537e404a886eab131e311cc'/>
<id>6e0d4d53d51e8aa9d537e404a886eab131e311cc</id>
<content type='text'>
Signed-off-by: Erik Skultety &lt;eskultet@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Erik Skultety &lt;eskultet@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ci: Expose built RPMs as artifacts</title>
<updated>2022-10-13T08:35:32+00:00</updated>
<author>
<name>Peter Krempa</name>
<email>pkrempa@redhat.com</email>
</author>
<published>2022-10-10T08:44:17+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libvirt-python.git/commit/?id=5b5cd3daccaa68bc6131facd79128f4e905ce34b'/>
<id>5b5cd3daccaa68bc6131facd79128f4e905ce34b</id>
<content type='text'>
Expose the artifacts from the centos-stream-8/9 and fedora 35/36 jobs so
that the main libvirt integration testing project can consume them.

The new libvirt sub-rpm containing a python helper to access QMP
directly requires python environment which we didn't yet install in the
integration job.

Signed-off-by: Peter Krempa &lt;pkrempa@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Expose the artifacts from the centos-stream-8/9 and fedora 35/36 jobs so
that the main libvirt integration testing project can consume them.

The new libvirt sub-rpm containing a python helper to access QMP
directly requires python environment which we didn't yet install in the
integration job.

Signed-off-by: Peter Krempa &lt;pkrempa@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ci: refresh with latest lcitool manifest</title>
<updated>2022-09-30T16:24:31+00:00</updated>
<author>
<name>Daniel P. Berrangé</name>
<email>berrange@redhat.com</email>
</author>
<published>2022-09-30T08:50:04+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libvirt-python.git/commit/?id=4733e2a2d13cb9a85127ba17c04cc29278b31e89'/>
<id>4733e2a2d13cb9a85127ba17c04cc29278b31e89</id>
<content type='text'>
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push

   git push &lt;remote&gt; -o ci.variable=RUN_PIPELINE=1

This variable can also be set globally on the repository, though this is
not recommended. Upstream repo pushes to branches will run CI.

The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.

With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.

Signed-off-by: Daniel P. Berrangé &lt;berrange@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push

   git push &lt;remote&gt; -o ci.variable=RUN_PIPELINE=1

This variable can also be set globally on the repository, though this is
not recommended. Upstream repo pushes to branches will run CI.

The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.

With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.

Signed-off-by: Daniel P. Berrangé &lt;berrange@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>gitlab: switch to using 'pip' for package installation</title>
<updated>2022-03-28T14:44:48+00:00</updated>
<author>
<name>Daniel P. Berrangé</name>
<email>berrange@redhat.com</email>
</author>
<published>2022-03-25T12:28:47+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libvirt-python.git/commit/?id=545cc70f2f6eed9d13ac66d6b4009557e73493ed'/>
<id>545cc70f2f6eed9d13ac66d6b4009557e73493ed</id>
<content type='text'>
The distutils/setuptools 'install' command is deprecated in favour of
'pip', and with recent versiosn, using it will create a bad install
that triggers a traceback on all future use of setuptools:

Traceback (most recent call last):
  File "/builds/berrange/libvirt-python/setup.py", line 328, in &lt;module&gt;
    setup(name = 'libvirt-python',
  File "/usr/lib/python3.10/site-packages/setuptools/__init__.py", line 154, in setup
    _install_setup_requires(attrs)
  File "/usr/lib/python3.10/site-packages/setuptools/__init__.py", line 143, in _install_setup_requires
    dist = MinimalDistribution(attrs)
  File "/usr/lib/python3.10/site-packages/setuptools/__init__.py", line 135, in __init__
    super().__init__(filtered)
  File "/usr/lib/python3.10/site-packages/setuptools/dist.py", line 456, in __init__
    for ep in metadata.entry_points(group='distutils.setup_keywords'):
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 1009, in entry_points
    return SelectableGroups.load(eps).select(**params)
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 459, in load
    ordered = sorted(eps, key=by_group)
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 1006, in &lt;genexpr&gt;
    eps = itertools.chain.from_iterable(
  File "/usr/lib64/python3.10/importlib/metadata/_itertools.py", line 16, in unique_everseen
    k = key(element)
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 941, in _normalized_name
    return self._name_from_stem(stem) or super()._normalized_name
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 622, in _normalized_name
    return Prepared.normalize(self.name)
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 871, in normalize
    return re.sub(r"[-_.]+", "-", name).lower().replace('-', '_')
  File "/usr/lib64/python3.10/re.py", line 209, in sub
    return _compile(pattern, flags).sub(repl, string, count)

This is certainly a bug in distutils/setuptools, but given the
'install' command is deprecated, instead of waiting for a fix,
just switch to the recommend 'pip install .' command.

Signed-off-by: Daniel P. Berrangé &lt;berrange@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The distutils/setuptools 'install' command is deprecated in favour of
'pip', and with recent versiosn, using it will create a bad install
that triggers a traceback on all future use of setuptools:

Traceback (most recent call last):
  File "/builds/berrange/libvirt-python/setup.py", line 328, in &lt;module&gt;
    setup(name = 'libvirt-python',
  File "/usr/lib/python3.10/site-packages/setuptools/__init__.py", line 154, in setup
    _install_setup_requires(attrs)
  File "/usr/lib/python3.10/site-packages/setuptools/__init__.py", line 143, in _install_setup_requires
    dist = MinimalDistribution(attrs)
  File "/usr/lib/python3.10/site-packages/setuptools/__init__.py", line 135, in __init__
    super().__init__(filtered)
  File "/usr/lib/python3.10/site-packages/setuptools/dist.py", line 456, in __init__
    for ep in metadata.entry_points(group='distutils.setup_keywords'):
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 1009, in entry_points
    return SelectableGroups.load(eps).select(**params)
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 459, in load
    ordered = sorted(eps, key=by_group)
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 1006, in &lt;genexpr&gt;
    eps = itertools.chain.from_iterable(
  File "/usr/lib64/python3.10/importlib/metadata/_itertools.py", line 16, in unique_everseen
    k = key(element)
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 941, in _normalized_name
    return self._name_from_stem(stem) or super()._normalized_name
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 622, in _normalized_name
    return Prepared.normalize(self.name)
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 871, in normalize
    return re.sub(r"[-_.]+", "-", name).lower().replace('-', '_')
  File "/usr/lib64/python3.10/re.py", line 209, in sub
    return _compile(pattern, flags).sub(repl, string, count)

This is certainly a bug in distutils/setuptools, but given the
'install' command is deprecated, instead of waiting for a fix,
just switch to the recommend 'pip install .' command.

Signed-off-by: Daniel P. Berrangé &lt;berrange@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
