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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
There are two unit tests in test_aio.py that are skipped if
Python is too new (3.10 or newer). But the message printed when
they are skipped mentions just 3.10 which is confusing. Change it
to "3.10+".
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Instead of doing some 'extern ...' declaration magic to force
proper PyInit_libvirtmod*() symbol exposure in resulting .so we
can use what Python already offers - PyMODINIT_FUNC macro and
call it a day.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When -Ibuild flag is passed to compiler then build/ can be dropped
from includes. This is safe to do, because the prefix is only on
local includes (#include "") not system ones (#include <>).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The generator.py generates a (per module) table of functions it
generated code for and stores it in ${module}-export.c file. The
file is then #include-d in corresponding override.c in the table
of all methods implemented in the module.
Now, problem is with naming of the file because the ".c" suffix
might suggest the file needs to be compiled. Well, it doesn't.
It's way closer to being a header file, so change the suffix to
".c.inc".
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Soon generator.py is going to be ran from a build directory which
is different than the source directory. Allow specifying these
directories on the cmd line.
And while at it, introduce new "c+py" output mode in which both C
and Python files are generated. While this is a fallback mode if
no output mode is selected, we need this new mode so that
aforementioned directories can be specified.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When generating spec file, @PY_VERSION@ is replaced with the
current version of libvirt-python. Well, it's not as obvious as
it could be: usually it's just @VERSION@. Worse, the PY_ prefix
may mislead readers into thinking it refers to python version.
Just drop the PY_ prefix.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
logging.warn is an alias to logging.warning since Python 3.3 and will be
removed in Python 3.13.
Signed-off-by: Jelle van der Waa <jvanderwaa@redhat.com>
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>
