Add a pair of services:
1. qubes.RegisterBackupLocation - called by dom0, registers what backup
location (including both file and command options) can be accessed.
Registered location gets an ID returned to the caller. The location (and
its ID) is valid as long as the service call remains open.
2. qubes.RestoreById - called by restoring DispVM to retrieve the backup
content. The service expects location ID as an argument, and then list
of files/directories (separated with spaces) on the first line of stdin.
This is very similar to qubes.Restore service, with exception for the
archive location control.
QubesOS/qubes-issues#5310
This specifically fixes qvm-console-dispvm tool, which uses
qubes.ShowInTerminal to show the actual console. This service uses
xterm, so it needs X session running already.
FixesQubesOS/qubes-issues#5805
While stderr isn't connected to the local_program argument (qrun-in-vm)
of qrexec-client-vm, it *is* connected (by qrexec-client-vm itself) to
the command the user passed to *to qvm-run-vm*.
A small script will add the QubesIncoming shortcut to Nautilus file pane
on the first use of qvm-copy to a given VM. The shortcut will not be recreated if
deleted.
fixesQubesOS/qubes-issues#2229
The script depends on XDG_DATA_DIRS environment variable
being set up correctly, which is not the case when it is
running under sudo. As a result, a post-install trigger
for apt could remove application entries from other sources
(Snap, Flatpak).
FixesQubesOS/qubes-issues#5477.
The workaround is no longer necessary, and it breaks when
the app name itself contains .desktop (such as org.telegram.desktop).
FixesQubesOS/qubes-issues#5408.
* origin/pr/188:
Use built-in rules in qubes-rpc makefile
Ignore build result: tar2qfile
Remove no longer needed xorg-preload-apps.conf
Move qubes-rpc installation from the root Makefile to qubes-rpc Makefile
That allows a build system to customize compiler and linker and pass
extra flags to these.
Remove `-g` as default flag and enable it only when `DEBUG` variable is
set.
qubes-rpc has its own Makefile that's responsible for building some
executables. The root Makefile was installing qubes-rpc files. To make
qubes-rpc a bit more indepdent from core-agent root Makefile and to ease
potential maintainer work on packaging qubes-rpc separately, the
installation has been moved to qubes-rpc Makefile. Moreover that should
make the Makefiles easier to read and maintain.
* fc31:
rpm: switch deps to python3-setuptools on CentOS too
debian: switch to python3
Use spaces in xdg-icon script
Convert other scripts to python3
Convert qubesagent module to python3
Minor codestyle fix in qubesadmin/firewall.py
Require python setuptools
Update python2 dependencies to python3 and clean deprecated requirements
Instead of two scripts calling one another, now it's
only one script, with added variable names inside for clarity.
Also hopefully finally fixes the help messages for good.
fixesQubesOS/qubes-issues#4058
When calling su with a specific script, specify /bin/sh shell to be sure
to use posix compliant shell. User shell may not be a one (like fish).
FixesQubesOS/qubes-issues#5135
Both Archlinux and Fedora 29 have guidelines to point explicitly at
/usr/bin/python2 where it expect python2.
Also, do not use env.
FixesQubesOS/qubes-issues#4027
It may be useful to create AppVM-specific menu entries in AppVM itself.
It may be an application installed there (in /usr/local, or using snap
QubesOS/qubes-issues#2766), but it may be also some user custom
shortcut.
To support this, dom0 will accept menu entries also from
TemplateBasedVMs. But to avoid duplicates, qubes.GetAppmenus service
should send only menu entries actually stored in that VM, not inherited
from its template. To distingush them, first check what type of
persistence this VM has (from qubesdb-read /qubes-vm-persistence). If
it's rw-only, send only entries stored on /rw.
To make it more robust, use $XDG_DATA_DIRS and $XDG_DATA_HOME to
discover directories, instead of looking only for
/usr/{,local/}share/applications. This makes snap and flatpak handled
for free.
FixesQubesOS/qubes-issues#4152
- Symlink the other three tools to qvm-copy-to-vm.gnome, use the same
code where possible, and select differing behavior based on invoked
name (like the CLI tools). This brings qvm-move-to-vm.kde up to date
for R4.0 (bugfix on 89183e9).
- Get rid of a window focus race between zenity/kdialog and the
qubes.Filecopy dom0 permission dialog: Only launch the GUI after the
first line has been read from qfile-agent.
- Avoid visual glitches (e.g. for a non-existing file) by special-casing
a no-op progress function for $SIZE == 0.
- Pass -- separator between 'rm -rf' and the files to be removed, in
case someone or something ever invokes the tool on relative file names
starting with a dash.
- Pass -b (implies --apparent-size) and -s to du, to simplify percentage
calculation and to avoid unnecessary output.
The qvm-{copy,move}-to-vm.{gnome,kde} cancel buttons didn't actually
cancel, because qfile-agent ignored EPIPE and - via qfile_pack_init() -
SIGPIPE. So it never noticed when the local PROGRESS_TYPE=gui reader had
shut down.
for qvm-move
Added more descriptive usage text to the
qvm-copy/qvm-move/qvm-copy-to-vm/qvm-move-to-vm family of tools.
Also fixed bug that removed the file being moved for qvm-move-to-vm,
but not for qvm-move.
fixesQubesOS/qubes-issues#3529fixesQubesOS/qubes-issues#4020
