* qubesos/pr/157:
qubes-updates-proxy: make ShellCheck happy
Use exec to ease systemd handling the tinyproxy process
Handle tinyproxy path changed in upstream
Dom0 may not sent /etc/yum.conf but only /etc/dnf/dnf.conf - handle this
case too. Since dom0 use dnf for a long time, prefer dnf.conf.
Not all versions of dnf supports cachedir option, so handle also the
case when it's set by default to /var/cache/dnf (instead of overriden
with /var/cache/yum with yum.conf). Simply look for packages in whole
/var/cache.
QubesOS/qubes-issues#4225
This part of GIO library isn't suitable for short-lived processes (the
call is done asynchronously and may not reach the application before
qubes-desktop-run process is terminated). To fix this, implement dbus
activation manually, synchronously.
While at it, implement waiting for application to terminate (useful in
DispVM), by waiting for its dbus name to disappear.
dbus-python API isn't particularly nice, but don't switch to completely different
library as a stable update.
FixesQubesOS/qubes-issues#2449
parted tries to load random data for possible partiont table UUID
generation, even though there is no need to generate new UUID. In case
of early VM startup, this is very undesirable as random entropy pool may
not be initialized yet, which will cause parted to block.
Use sfdisk instead, which doesn't try to do that. And also can relocate
backup GPT and resize partition in one go.
FixesQubesOS/qubes-issues#4419
The previous approach used `df` to get usable space and then added a
fixed size to that number in order to account for filesystem
overhead. However, at some point that stopped working for me. It
appears that ext4 filesystem overhead can vary over time or because of
other factors. (Certainly now that I think about it the old code would
only work well for people with the exact same filesystem size as me.)
So the new approach is to just completely ignore what `df` tells us
and instead go directly to the source: the filesystem's internal
notion of exactly how much space it takes up. We use `dumpe2fs` to
retrieve this information and calculate the on-disk size dynamically
from that. Then we add the space that boot data takes up (unchanged),
and we add 5MB padding because when I tested this it didn't quite add
up otherwise. https://unix.stackexchange.com/a/13551/29146 suggests
that this unaccounted-for data may be e.g. additional copies of the
superblock.
Network setup scripts, especially for network backend use 'ip' tool, so
the iproute package should be installed for this to work.
QubesOS/qubes-issues#4411
It is needed by the startup scripts to create fs on fresh private image.
Otherwise /rw (and thus /home) isn't mounted and user applications fail
to start.
FixesQubesOS/qubes-issues#4671
