* origin/pr/145: (119 commits)
qvm-template: fix downloading template for install
tests: add tests for other qvm-template functions
tests: improve TestProcess behavior
tests: add tests for qvm-template reinstall/up/downgrade when nothing needs to be done
tests: fix mock return values of get_dl_list when testing `qvm-template reinstall`
qvm-template: update comments to reflect e424c7d
qvm-template: only ask for confirmation during install if something is being done
tests: add more tests re. install, remove, and get_keys_for_repos
qvm-template: test != 1 instead of == 0 for template-dummy feature
tests: fix tests for verify_rpm involving incorrect template names
tests: add tests for qvm-template remove
tests: some more for qvm-template
qvm-template: mute pylint complains about typing.NamedTuple
tests: qvm-template-postprocess - template.conf handling
qvm-template-postprocess: fix allowed features list
qvm-template-postprocess: extract config handling into separate function
qvm-template-postprocess: treat missing appmenus files as warnings only
qvm-template: default confirm to 'n'
qvm-template: verify template package signature directly at download
qvm-template: improve error reporting
...
qvm-start-daemon now uses `qubes-guid -C` - ensure correct version
installed.
But to not require qubes-gui-daemon installed always, use reverse
conflict dependency.
qubesd socket protocol is changed in qubes-core-dom0 4.1.12 and also in
this release. Ensure matching versions are installed.
Note the python3-qubesadmin package can be installed in VM too and the
socket protocol applies only to dom0 case - use Conflicts instead of
Requires for this reason (to not break installation in the VM).
qvm-start-gui lifecycle should be bound to X server lifecycle. It should
be restarted when user logoff and login again, at least to start
gui-daemons again.
Do that by opening a connection to X server and reacting to breaking
that socket.
FixesQubesOS/qubes-issues#3147
Start it using XDG Autostart feature, but exclude starting in
qubes-session - so even if package is installed in a VM, it wont be
started simultaneusly with GUI agent.
On the other hand, if some other DE session is running there (which will
be the case for GUI domain), gui-daemons will be started accordingly.
QubesOS/qubes-issues#833
