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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Seen running on fedora 32:
DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats
ret = libvirtmod.virDomainLookupByUUID(self._o, uuid)
This comes from here: https://bugs.python.org/issue36381
See the section about PY_SSIZE_T_CLEAN here:
https://docs.python.org/3/c-api/arg.html#strings-and-buffers
Solution is to use Py_ssize_t instead of int for unpacked '#' values,
combined with defined PY_SSIZE_T_CLEAN before importing Python.h. The
latter turns these deprecation warnings into runtime segfaults though
if we missed an instance.
I verified the virt-manager's test suite works fine after this change
Signed-off-by: Cole Robinson <crobinso@redhat.com>
$ ./setup.py build
running build
/usr/bin/pkg-config --print-errors --atleast-version=0.9.11 libvirt
/usr/bin/python3 generator.py libvirt /usr/share/libvirt/api/libvirt-api.xml
generator.py:1562: SyntaxWarning: "is" with a literal. Did you mean "=="?
if classname is "virStorageVol":
...
Signed-off-by: Cole Robinson <crobinso@redhat.com>
There are four methods which receive/send entire stream
(sendAll(), recvAll(), sparseSendAll() and sparseRecvAll()). All
these have an intermediary buffer which is either filled by
incoming stream and passed to a user provided callback to handle
the data, or the other way round - user fills it with data they
want to send and the buffer is handed over to virStream.
But the buffer is incredibly small which leads to smaller packets
being sent and thus increased overhead. What we can do is to use
the same buffer as their C counterparts do (e.g.
virStreamSendAll()) - they all use VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX
long buffer (which is the maximum size of a stream packet we
send) - this is almost exactly 256KiB (it's 256KiB - 24B for the
header).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Instead of hardcoding the names of the targets for which certain
steps should be skipped, use a separate variable to store that
information.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The docs refers to XML files that don't exist in the python binding
since it was split off from the main libvirt.git repo.
Fixes#3
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We bundle a git generated ChangeLog file in the dist, and never add
any entries to the NEWS file.
Fixes#2
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
With the introduction 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é <berrange@redhat.com>
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 <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 needs to be run on
a single distro, for which CentOS 8 is picked as a stable long life
base.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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 VIR_TYPED_PARAM_DOUBLE (originally VIR_DOMAIN_BLKIO_PARAM_DOUBLE)
Cannot get a value of enum VIR_TYPED_PARAM_INT (originally VIR_DOMAIN_BLKIO_PARAM_INT)
...snip...
The code generated for the binding is still correct and so we can just
whitelist this error scenario.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This job uses the shared "check-dco" image to validate that all
commits on a branch in a developer's repo fork have a suitable
Signed-off-by statement present.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Fix two more cases in examples as
libvirt.open*() does not return None but raises an exception
Fixes: 283e2bc693
Signed-off-by: Philipp Hahn <hahn@univention.de>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Python 3.5 is the oldest Python version available across our supported
build platforms.
Reviewed-by: Philipp Hahn <hahn@univention.de>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Libvirt uses GitHub as an automated read-only mirror. The goals were to
have a disaster recovery backup for libvirt.org, a way to make it easy
for people to clone their own private copy of libvirt Git, and finally
as a way to interact with apps like Travis.
The project description was set to a message telling people that we
don't respond to pull requests. This was quite a negative message to
potential contributors, and also did not give them any guidance about
the right way to submit to libvirt. Many also missed the description and
submitted issues or pull requests regardless.
It is possible to disable the issue tracker in GitHub, but there is no
way to disable merge requests. Disabling the issue tracker would also
leave the problem of users not being given any positive information
about where they should be reporting instead.
There is a fairly new 3rd party application built for GitHub that
provides a bot which auto-responds to both issues and merge requests,
closing and locking them, with a arbitrary comment:
https://github.com/apps/repo-lockdown
This commit adds a suitable configuration file for libvirt, which
tries to give a positive response to user's issue/pullreq and guide
them to the desired contribution path on GitLab.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The generator creates broken code for all these methods.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
python2 will be end of life by the time of the next
libvirt release. All our supported build targets, including
CentOS7, have a python3 build available.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Libvirt commit <95f5ac9ae52455e9da47afc95fa31c9456ac27ae> changed the
VIR_DOMAIN_QEMU_AGENT_COMMAND_* enum values to use different enum values
instead of direct numbers. We need to translate it back.
Traceback (most recent call last):
File "generator.py", line 2143, in <module>
qemuBuildWrappers(sys.argv[1])
File "generator.py", line 2008, in qemuBuildWrappers
items.sort(key=lambda i: (int(i[1]), i[0]))
File "generator.py", line 2008, in <lambda>
items.sort(key=lambda i: (int(i[1]), i[0]))
ValueError: invalid literal for int() with base 10: 'VIR_DOMAIN_AGENT_RESPONSE_TIMEOUT_BLOCK'
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Introduced in libvirt 5.1.0 by commit <c830187a015>.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The virNetworkPort class is passed both the virNetwork parent
python class and the virNetworkPort C object. This needs special
handling in the generator, similar to how virDomainSnapshots are
dealt with.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
libvirt-override.c: In function ‘libvirt_virConnectBaselineHypervisorCPU’:
libvirt-override.c:9946:23: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
libvirt-override.c:9961:19: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
Use ssize_t as was similarly done in 75ec2acb61
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Since commit ee0cfbe65c (spec: Unconditionally build python2 on
Fedora) python2-libvirt is not built on any Fedora version.
Fix the spec to drop python2-libvirt on Fedora 31.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Nir Soffer <nsoffer@redhat.com>
