On first run of the app we will check to see if libvirt and qemu
are installed, and if not, offer to install them. In theory anyways.
In practice this stuff breaks repeatedly and is a pain to test because
every desktop has their own API provider with subtly different behavior.
My last round of testing about 12 months ago: apper on KDE was completely
busted and apparently unmaintained (although that may have changed lately),
gnome-software is the latest packagekit provider on gnome and completely
changes the semantics of the API compared to old style gnome-packagekit
that break a lot of virt-manager assumptions.
So I'm tired of it and want it all gone. Still use systemd to try and
check if libvirtd is running, and provide error messages at startup
to guide people.
The copyright headers in every file were chjanged in this previous commit
commit b6dcee8eb7
Author: Cole Robinson <crobinso@redhat.com>
Date: Tue Mar 20 15:00:02 2018 -0400
Use consistent and minimal license header for every file
Where before this they said "
"either version 2 of the License, or (at your option) any later version."
Now they just say
"GNU GPLv2"
This fixes it to say "GNU GPLv2 or later" again.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently it throws an exception at startup which is hidden unless you
run with --no-fork
$ python3 ./virt-manager --no-fork
Traceback (most recent call last):
File "/home/berrange/src/virt/virt-manager/virtManager/baseclass.py", line 225, in wrap_func
return func(*wrapargs)
File "/home/berrange/src/virt/virt-manager/virtManager/engine.py", line 206, in conn_open_completed
ConnectError.details)
AttributeError: 'NoneType' object has no attribute 'details'
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Kind of a big mess but it was difficult to untangle piecemeal.
Basically this drops nearly all the centralized window tracking
in engine.py and moves it to each UI class. If manager.py wants
to open a details window it does it directly, and vmmDetails tracks
the window object list itself. This simplifies things and makes
the code easier to follow.
There's still some weirdness with vmmConnect and connection callbacks,
but future patches will break those apart.
Have a separate class for tracking the connection list, and emitting
conn-added and conn-removed signals. It exists as a singleton instance
that UI classes can talk directly to
This creates a weird situation where we pass the engine to those
classes UI functions, but this is a step towards untangling that.
While here, get rid of the conn-added connect magic and add a
simpler way to access the connection list from the engine
Rather than key it on the library being available. Makes it much
easier to test both modes of behavior.
Fix up a few inspection bugs while I'm in the area, and convert
it to be more singleton like.
Call the callbacks directly rather than using signals. engine.py
has become a bit of a catchall for shared functionality and this
is a step towards disentangling it
This can help us find object leaks within the code. virConnectClose
is just a deference and will return 1 if other references are still
floating around.
Fix all E125:
Continuation line with same indent as next logical line
Also remove ignore options of E125
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
The message when failing to connect can be misleading as package names
will differ per Distribution as well as not apply for e.g. self built
binaries.
This changes the message in a way to be more generic not implying literal
package names.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Dealing with packagekit across desktops and in a consistent
manner is a pain. This code path is rarely exercised and difficult
to test, so just fallback to giving a hint error message and
let the user install if they care.
Cole Robinson