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>
It's the wrong dep on F21+, and it's redundant there anyways. So just
restrict this to RHEL7 where the bug was reported, come RHEL8 time
it likely won't be relevant.
I don't think anything is actually using it these days, and upstream
autobuild development seems dead. If someone is still using it, we
can revert this commit.