It's time to get rid of prefdm. Distributions which still want to use
this should maintain this downstream, but it's probably better to just
provide proper units for the various display managers, like Fedora is
doing this, for example:
https://fedoraproject.org/wiki/Features/DisplayManagerRework
In order to make containers work nicely out of the box it is highly
desirable to have the mount propagation mode for the root fs is set as
"shared" by default so that containers receive system mounts by default.
(See mount --make-shared for more information).
As it is unlikely that the kernel will change the default to "shared"
for this, do this early at boot-up from PID 1. Setups which prefer the
default of "private" should undo this change via invoking "mount
--make-private /" or a similar command after boot.
In the long run /etc/fstab should take the propagation mode as a mount
option like any other, so that this may be used to change the default
mode. However, if fstab is not around or doesn't list / we still should
default to shared as propagation mode, hence this change now.
Adds messages for formally silent errors: new "Failed on cmdline argument %s: %s".
Removes some specific error messages for -ENOMEM in mount-setup.c. A few specific
ones have been left in other binaries.
This is useful e.g. if the keyfile is a raw device, where only parts of it
should be read. It is typically used whenever the keyfile-offset= option is
specified.
Tested-by: Erik Westrup <erik.westrup@gmail.com>
https://launchpad.net/bugs/1011323 reports more AMILO models which need this
quirk; enough to assume that all of them need it, and applying it on working
models does not really hurt.
There is no apparent justification for using util_strscpyl
on the filename since it's a plain hardcoded path.
Older versions used:
util_strscpyl(filename, sizeof(filename), SOME_DIR, "/queue.bin", NULL);
and when changed nobody bothered to simplify it.
Old: systemd[1]: Got direct mount request for ffff88003bb10c00, triggered by 14476 (fuser)
New: systemd[1]: Got direct mount request on /dev/mqueue, triggered by 2177 (ls)
This file is generated, so it should be referred to as
$(top_builddir)/src/gudev/gudevenumtypes.h. It could only appear in
$(top_srcdir) as a result of previous build in $(top_srcdir). Better
to just let automake add the prefix for us, so there's no need to
spell it out.
Remove the prefix from other source files too, $(top_srcdir) is the
default anyway.
$(MKDIR_P) is added where missing, and rules are standardized on one
form of $(MKDIR_P), to make it easier to spot when it is missing.
Single line $(MKDIR)&&command form is broken into two line form.
https://bugs.freedesktop.org/show_bug.cgi?id=49459
For compilation in a separate build directory to work, when a file is
generated, the rule must include an explicit mkdir first, unless the
file is created at the top level. Even when building in a separate
build-dir, automake would normally create all directories as a side
result of creating the dependencies files. Therefore the bug was only
visible with -C (turning off dependency generation).
We want to keep things uniform, and hence treat udevd's man page like
any other in the repo. What matters is how users primarily interface
with a service, and that is not the binary path in /usr/lib/systemd but
the service name.
This reverts commit 6c1f3ba54a.
Instead of making systemd-udevd a so-link to systemd-udevd.service,
ship the real page as systemd-udevd to integrate better with distros
where udevd might be run standalone.
"make dist" can build a different tarball depending on the flags passed
to ./configure and the (optional) dependencies found on the system.
Move all append-to-EXTRA_DIST operations out of automake conditionals to
fix this.
Introduce a polkitpolicy_files so that the policy files built still
correctly depend on the automake conditionals, but the .in files that
get distributed do not.
Kay Sievers