* advertise-services:
archlinux: no longer need to mangle shebang for python scripts
Make shebang explicit /usr/bin/python2 where it's still there
Tell dom0 that VM is running Linux
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
* origin/pr/139:
Remove qubes-core-agent Debian dependency on xserver Mark xserver, xinit and x11-xserver-utils as Recommends
FixesQubesOS/qubes-issues#4202
In rare cases when vif-route-qubes is called simultaneously with some
other iptables-restore instance, it fails because of missing --wait (and
recent iptables-restore defaults to aborting instead of waiting
for lock). That other call may be from qubes-firewall or user script.
Related to QubesOS/qubes-issues#3665
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
Previously, bind-dirs.sh had a bunch of `true comment goes here` style debug messages (no-ops). Presumably this was done because these messages are intended as debug messages and would only be displayed when calling bind-dirs.sh with xtrace enabled. However, this includes some fatal errors, which are necessary to debug why bind-dirs.sh is ostensibly not working. For example, I tried to mount /var/lib/docker, didn't realize it did not exist (as an empty directory) in my base template, and there was no journalctl output at all. After this change, journalctl will contain the (very helpful) error message.
If xvda is not partitioned, checking size of device mounted as root dev
doesn't detect xvda resize - it will have the new size, while the fs on
it not. Change to checking actual filesystem size.
Also, improve log message to include the size.
FixesQubesOS/qubes-issues#4274
The qubes-core-agent-passwordless-root package ships sudo configuration,
adding to sudo group isn't needed.
Basically revert all changes made by qubes-core-agent-passwordless-root
installation.
FixesQubesOS/qubes-issues#4015
'which' is an external tool, 'type' is a shell builtin. Using the latter
shaves off a bit of latency.
Also use the already open stderr file descriptor for redirection.
- 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.
