Currently we show channel label by its name.
If we use name com.redhat.spice.0 but set it
as unix socket, the label in details keep unchanged.
This patch will set label according to device type
if we failed matching target_name
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
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
Since qemu has the setuid qemu-bridge-helper, give a way in the UI
to specify a manual bridge name for qemu:///session. Might not work
all the time but at least the users can try
https://bugzilla.redhat.com/show_bug.cgi?id=1212443
Simplest is to have a separate UI area for the arch warning, since
the standard startup warning may still apply too.
Reported-by: João Pirralha <joaopirralha@gmail.com>
pygobject doesn't seem to choke on debug_leak_check anymore, so we
can use it to find object leaks. just doing a few for now since it's
generally not a big deal.
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).
It happens every now and then that a libvirt bug means calling XMLDesc
on an object will always fail. For example:
https://bugzilla.redhat.com/show_bug.cgi?id=1225771
We don't handle this very well and it can bleed into many other parts of
the code in a bad way. So if the initial polling of the object fails,
blacklist it entirely and ignore it for all future polling.
Originally this made sense, as it was the only way to specify a non-default
storage format when creating new storage.
Nowadays the storage browser is a full featured storage manager... and
this field is a bit confusing WRT whether it's used for creating new
storage, or informing libvirt about an existing image's format.
Drop it from the addhardware wizard, and simplify what we show in the
details wizard as well.
This is a little low level and rarely used IMO to have it in the UI.
If people want to edit this we should point them at virt-xml which
seems like the appropriate user friendlyness for this feature.
This made more sense when raw was the disk image default, but nowadays
we use qcow2 which doesn't even support non-sparse, so the UI is always
disabled.
If the user changed their preference to raw, it still doesn't make much
sense to show the option, since they are likely using raw for performance
in which case they are going to want to preallocate anyways.
So just default to sparse=False. If users want to override it, they can
do it via custom created storage.
Chen Hanxiao