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.
virt-manager uses some icons included in the gnome-icon-theme package.
Make it explicit and add a dependency.
Desktop folks agree that this is the place where to add this
dependency as adding it to gtk is too problematic.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1146612
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
There were multiple problems with the setting and usage of
hide_unsupported_rhel_options. Due to the fact that the option has
several diferent namings throughout the code, this patch is renaming
it to stable_defaults, which basically says what the option does and
makes it possible to use it without need for more than one negation
(where the old code had up to 4 of them in some places), which also
helps understanding it.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
virt-manager is one of those tools that people will often install when
no traditional desktop is present. dbus-x11 is pulled in by desktop
environments, but not by gtk3 for (presumably) legitimate reasons.
But we need it to do anything worthwhile with dbus.
Last commit changing the default was de1695b2, but there was still one
place in man page left and the spec file was left dirty. This is
hopefully the last vnc->spice patch
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Kind of a maintenance pain, and it's just poorly duplicating info
from the git logs. We could autogenerate this but I don't really
have the interest in figuring it out. Patches welcome :)
The only bits were were using was the icon installation and
translation building, which amounted to about 70 lines of code.
Just steal it so we can avoid the dep which will cause trouble
for future RHEL.
Was originally added with hopes for being used in an ovirt related
product, but was more or less a code dump, and the author has been
allocated to other things. He confirmed it's okay to remove.
That, and it's currently broken, and we've had approximately 0 user
feedback since it was committed.
Cole Robinson