This layout is closer to what most python modules have nowadays.
It also simplifies testing and static analysis setup.
Keep virt-* wrappers locally, for ease of running these commands
from a git checkout.
Adjust the wrapper binaries we install on via packaging to be
pure python, which makes things like running gdb easier.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was raised here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
Quoting from that:
"""
virt-convert takes an ovf/ova or vmx file and spits
out libvirt XML. It started as a code drop a long time ago that could
translate back and forth between vmx, ovf, and virt-image, a long dead
appliance format. In 2014 I converted it to do vmx -> libvirt and ovf ->
libvirt which was a CLI breaking change, but I never heard a peep of a
complaint. It doesn't seem to do a particularly thorough job at its
intended goal, I've seen 2-3 bug reports in the past 5 years and
generally it doesn't seem to have any users. Let's kill it. If anyone
has the desire to keep it alive it could live as a separate project
that's a wrapper around virt-install but there's no compelling reason to
keep it in virt-manager.git IMO
"""
Nothing has changed since then, so here is the removal.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The canonical location for AppStream XML files has been changed to
/usr/share/metainfo four years ago at least, with /usr/share/appdata
left as legacy location. It is time to switch to the right location.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Import BuildConfig directly from the source file using import hackery.
buildconfig.py is independent of virtinst code so it already does
the right thing. Add some checking to make sure this doesn't regress
in the future.
Drop the now unneeded RPM deps.
Recent changes refactored a code in a whey that running setup.py
requires more python modules and we need to reflect that in our
spec file in order to build RPMs.
We should not need all of these as they are not used but that will
require a lot of code changes. We should eventually fix it.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Instead of using "floppy" as the way to perform unattended installations
for Windoes, let's prefer using "cdrom" instead.
The main reasons behind this change are:
- VMs using q35 may have floppy device disabled in some systems;
- We can drop mstools dependency;
Generating the ISO depends on genisofs, tho. However, it's not a big
deal as genisofs is already a virt-manager dependency.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
virt-manager can optionally use libguestfs for inspecting the guests, so
at least add it as suggestion.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Similar to perform_initrd_injections(), which is used by Linux(es)
unattended installations, perform_floppy_injections() is going to be
used by Windows(es) unattended installations.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
For one, we don't offer to install it anymore because we dropped
packagekit stuff. But even having a single package here isn't
really the whole story because different desktops have their
own askpass providers, like Fedora has openssh-askpass for GNOME,
but ksshaskpass for KDE
So drop it all, make the error more generic, and point people
to setting up SSH keys too
This switch says: if we detect a rhel host, use special version
checks that match rhel backports. This pattern sucks. The way
forward is to have libvirt advertise the bits that are supported,
through domcapabilities. Then virt-manager/virtinst can react
as appropriate.
This came from: https://bugzilla.redhat.com/show_bug.cgi?id=1039803
Seems dconf and gconf before it would use dbus-libs which would
in turn try to use dbus-launch from dbus-x11. They didn't have
a dep on dbus-x11 for *reasons*
Nowadays dconf and virt-manager both use gdbus which is a native
dbus implementation and does not use dbus-launch or have any hard
dependency on x11 AFAICT, so this dep is not required.
The `ipaddress` is available in Python 3.3+ [1] and backport for
Python 2 is available on PyPI [2].
The main differences between ipaddr and ipaddress are:
- ipaddress *Network classes are equivalent to the ipaddr *Network
class counterparts with the strict flag set to True.
- ipaddress *Interface classes are equivalent to the ipaddr *Network
class counterparts with the strict flag set to False.
- The factory functions in ipaddress were renamed to disambiguate them
from classes.
- A few attributes were renamed to disambiguate their purpose as well.
(eg. network -> network_address, numhosts -> num_addresses)
- A number of methods and functions which returned containers in ipaddr
now return iterators. This includes subnets, address_exclude,
summarize_address_range and collapse_address_list.
Another major difference is that in Python 2 the `ipaddress` module
must use unicode. [3]
[1] https://www.python.org/dev/peps/pep-3144/
[2] https://pypi.python.org/pypi/ipaddress
[3] https://github.com/phihag/ipaddress
The vte291 package is actually the latest vte with API version 2.91, while
the vte3 package is effectively a compat package with API version 2.90.
virt-manager works fine with either, so pull the latest bits so there's
no ambiguity.
Most of this is lifted from 'meld'. The bits are
- compile gsettings schemas at setup.py install time
- add options to disable that, and use them in the RPM
- always pass GSETTINGS_SCHEMA_DIR so gsettings loading always works
regardless of the install dir
https://bugzilla.redhat.com/show_bug.cgi?id=1267377
This is so we can drop the dep on system python-urlgrabber, which will
block us from going to python3.
All we need is like 300 lines from python-urlgrabber for the progress
bar. In reality our needs are much lower, we don't need the fancy
progress bar that urlgrabber provides, but it's nice to have. So if
keeping a copy of this code causes issues in the future, we can probably
come up with something simpler (or hopefully there's a more common
python progressbar impl that we can use at that point).
urlgrabber is largely dead upstream and isn't going to be ported to
python3 AFAIK. So we will need to move off of it eventually.
Use requests for http handling which is the most common library nowadays,
and just plain old urllib2 for ftp fetching.
Similarly as in commit 95cda553, just remove the dependency on qemu-kvm
package for RHEL builds. We don't need it, becase libvirt-daemon-kvm
will handle this dependency correctly for us even in case that only
qemu-kvm-rhev is present.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1046651
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
We have shipped several releases of RPMs that use gsettings. People
have already rebuilt their settings by hand. Installing the conversion
script could overwrite their latest bits with old gconf bits (this
happened to me).
Takes a comma separated list of HVs, and only shows those as options in
the 'Open Connection' wizard. This option can be used to hide the bhyve
option as well, so drop --with-bhyve
No one uses it, and it can be handled easy enough with a wrapper script or
similar.
Message-Id: <1b33f161591b86407f78fb307aa4f89f6eee9e4e.1428346382.git.crobinso@redhat.com>
Cole Robinson