IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The change to use 'python -m build' in
commit 333c8bef2b
Author: Erik Skultety <eskultet@redhat.com>
Date: Tue Jun 20 12:19:40 2023 +0200
ci: Drop direct 'setup.py' usage
resulted in the CI jobs all downloading latest setuptools and
deps from pypi and running builds with them in a venv. IOW we
ceased testing against the setuptools/wheel packages provided
by the distro, which is the whole point of the CI.
Passing the '-n -x' flags to 'python -m build' tells it to stop
using a venv and not to check dependancies, thus letting it
use what we pre-installed in the container.
This doesn't work on CentOS Stream 8, however, so we revert to
using the old setup.py approach. This is a short term issue,
since Stream 8 is EOL at the end of May, so we'll be deleting
all the Stream 8 jobs across libvirt CI very soon.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The 'python -m build' command creates a source dist and a binary
wheel. To be able run this command without creating a new venv
and downloading from pypi, we need to pre-install the 'wheel'
package.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently, there's just one native_git_build_job -
x86_64-centos-stream-8-git and this is a problem because that's
the job that api_coverage_job then uses. But CentOS Stream 8 has
too old lxml which then makes tests/test_api_coverage.py skip its
run. By switching to CentOS Stream 9 the test can run happily
again.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
While virDomainRestoreParams() has 'virDomain' prefix (and thus
is put into Domain class), it is really in the same family as
virDomainRestore() or virDomainRestoreFlags() -> it acts upon
virConnect object and thus belongs into Connect class.
Then, virDomainFDAssociate is exposed as Domain.FDAssociate() but
because of the way we would generate the method's name
(fDAssociate) the test thinks it's not implemented.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
virStreamRecvFlags allocates a temporary buffer to store the received
stream data in. This buffer was not freed on returns other than the
normal return with data.
Signed-off-by: Vincent Vanlaer <libvirt-e6954efa@volkihar.be>
Distros recently started to object to using 'pip' to install system-wide
packages to prevent breakage. We were hacking-around that by using
'pip install --break-system-packages', but it's straightforward to
simply create a venv with '--system-site-packages' and install it there.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Update:
Debian-10 -> Debian-12
Fedora-37 -> Fedora-38
Fedora-38 -> Fedora-39
Also the artifacts from the Fedora 39 job are needed for the integration
test suite in the main libvirt project.
For Debian 12 we need to start using
'pip install --break-system-packages' as a hack to work around
installation of the built package for testing.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
We have Python 3.6 as a minimum version. If we set Py_LIMITED_API
to 0x03060000, we'll get the stable python API associated with
versions >= 3.6. This lets users compile once and have the libvirt
binary module be loadable by any Python version >= 3.6, as described
in:
https://docs.python.org/3/c-api/stable.html
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Although marginally faster, PySequence_ITEM is not part
of the stable API and also omits some safety checks. It
is better for us to be using PySequence_GetItem instead.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We use various C library functions like printf, strcmp, free
but don't have the corresponding #includes, getting them
indirectly via Python.h. This is a bad idea as Python.h is
not guaranteed to provided these, and indeed will omit them
when Py_LIMITED_API is greater then 0x030a0000.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use a set to collect the authors from the git output with no duplicates,
then sort the resulting set, and apply the wanted indentation.
This method is more Pythonic, using a set to avoid duplicates; applying
the indentation after the sorting makes the sorting slightly faster.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Adopt subprocess.check_output() as more modern and higher-level way to
invoke processes, checking that they succeed, and getting their output.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Storing the git commands as single string, to split it by space later
on, works only in case there are no spaces in the arguments, which is
exactly what is in those commands.
Instead, specify them directly as lists, with the options & arguments
split in the right way. This fixes the generation of the AUTHORS and
ChangeLog files.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Setting CFLAGS before invoking rpm-build causes replacement of the
CFLAGS that RPM wants to set for python. This causes the loss of
certain flags needed to turn on debug output and optimization.
Previously this wasn't a problem as something in setuptools appears
to have been adding -g anyway, but with the update to python 3.12
this now fully breaks. We should never have been setting CFLAGS
during the RPM build so we drop it unconditionally for all distros.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Each respective project that lcitool knows about and currently
maintains its list of package dependencies knows best what packages
they actually depend on. If a new dependency is currently needed,
first a change in lcitool is necessary before GitLab jobs and
containers can be updated. Provided a mapping already exists in
lcitool (which can quickly be added as an override via mappings.yml
temporarily) we speed up the whole CI update process by
one step.
Note that starting this commit lcitool must be invoked as
'$ lcitool -d/--data-dir ci/lcitool ...'
to pick up the project dependency list correctly.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
With all the bits in place we can now replace the direct 'setup.py'
invocation examples with alternatives.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
With all the bits in place we can now drop the 'setup.py' invocations
with preferred alternatives.
This patch does a few things:
- we don't run plain install because that always spins up a new build
process regardless of whether there are build artifacts literally from
the previous command, so instead we install the built wheel directly
- when building, we build both the .whl binary and an sdist because
we'll need the sdist for rpmbuild later in the CI job
- we don't capture the 'build' path as a job artifact anymore, because
that now only contains egg metadata, all the build artifacts are
created by Python's build module under 'dist' so we capture that one
instead
- we always limit pytest to the 'tests' directory which was something
'setup.py test' used to do as a precaution measure, but setup.py no
longer has the logic (which is fine)
Signed-off-by: Erik Skultety <eskultet@redhat.com>
With all the bits in place we can now drop the 'setup.py' invocations
with preferred alternatives. The way to do this in a SPEC file is to
use either of the following macros: %tox or %pytest - both of which
automatically set paths for the test suite correctly which is
something we used to do ourselves in our implementation of the
setup.py's test command originally.
That is wrong and with the migration to PEP-517 compliant builds it
also won't work anymore properly, because there'd be no libs to import
by mangling PYTHONPATH, we'd only get an sdist or a wheel, or in case
of rpmbuild a preset buildroot environment.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Direct setup.py invocations are being discouraged in favour of
using Python's 'build' module. Therefore, we can't really make use of this command
anymore since only wheels and tarballs are built with the 'build' module
compared to the previous state of the art of dumping the freshly built
modules and libraries directly inside the build directory.
We'll have to encourage usage of tox which will install the package
inside a virtualenvironment for the tests. Future patch will update the
Makefile targets to make this easier for the end users.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Given the missing setuptools keywords issue and hence having moved all
the declarative stuff to setup.cfg this one is only a very basic one
just to comply PEP-517 and foolproof this project for the future
PyPa/pip changes.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This one should be used for the "full" test experience including any
additional environments, test suites and linters we may introduce
further down the road.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
- drop direct setup.py invocations
- clean the artifacts directly with 'rm'
- use tox instead of invoking pytest otherwise we don't have a
mechanism to test against the freshly built libvirt modules other
than unpacking the built wheel and mangling the PYTHONPATH again
- use direct rpmbuild invocation to build RPM (the rpm target in its
current form didn't really work anyway)
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This makes it possible to programatically query the version in any
stage of the build process, including Makefile etc.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
So, why using setup.cfg if pyproject.toml is the new best thing
recommended everywhere? Well, quite a few of the fields we use with
setuptools are setuptools-specific and haven't been introduced as
keywords to pyproject.toml yet. There is a chance that these fields
could be added via a dedicated 'tool.setuptools' TOML section, but none
of it is officially documented and so it would be BETA at best anyway.
Let's not try our luck and use a declarative config file tailored
specifically to setuptools - setup.cfg. It's also unlikely we'd switch
from setuptools to something else in the near future given the nature
of building this project (i.e. building with C modules) and if so, it
would likely not be a PyPa recommended PEP-517 compliant build
system anyway, e.g. meson, so we're totally fine doing this.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
When migrated to the PEP-517 compliant builds, some errors occurred due
to missing or non-existent files mentioned in the MANIFEST. Notable
changes:
- README and MANIFEST files are automatically added to sdist per
MANIFEST documentation
- we want all tests/examples to be included, so use the 'graft' keyword
instead of enumerating individual files
- we want all *.[ch] files as those are needed for the build, so use
'include *.[ch]' instead of enumerating individual files
- we want all *.xml files, so use 'include *.xml'
- we want all *.py files - in case this is no longer the case in the
future, we'll need to tweak that 'include'
- we don't want any __pycache__ nor *.pyc build artifacts, so exclude
them globally
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Some of the operations, namely file operations and spawning processes
can utilize the power of context managers. Use them more, use them
together.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
subprocess is the high-level Pythonic interface providing more
flexibility over the low-level os.popen stuff. It is recommended to
always use subprocess over the direct 'os' interface.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Commit 60044515 renamed sanitytest to test_coverage_api but forgot to
update the tox.ini file.
Fixes: 60044515a2
Signed-off-by: Erik Skultety <eskultet@redhat.com>
