IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This allow test-efi-disk.img to be created under meson.
The invocation of qemu is not converted yet, in particular because the
command-line used in Makefile.am is outdated.
Both gcc and clang issue a host of warnings about void pointers used in
arithmetic. The warning must be ignored in that file to avoid multiple
warnings.
Makefile.am used to set this for all libsystemd-journal-internal.a sources,
because there's no finer granularity for warnings. Let's just set it for
this one file.
Specifying the same rule with a slightly different dep list was not useful,
since make cannot distinguish rules with the same input / output. (It possibly
could have two rules with different dependency list, but here all dependencies
that are different between the two rules are always present, so the two rules
are effectively the same.)
This makes dbus-org.freedesktop.network1.service like dbus-org.freedesktop.resolve1.service.
When systemd-networkd.service is disabled, the alias is also removed.
Due to ARM not having an EFI capable objcopy we need to use the binary
output argument. This is correctly set up for AArch64 but is missed
when building for ARM32. This patch adds the ARCH_ARM automake define
which can then be used in the makefile to determine if to use the
correct linker flags.
The addition of the ARM32 flags is a copy and paste from the AArch64 to
create a logical OR for the ARCH_AARCH64 and ARCH_ARM variables. I
couldn't figure out a better way to create the conditional with basic
Make language constructs.
This makes it easier to use the same generator script as for other
gperf scripts. With automake each gperf file had it's own rule, but
with meson I'm trying to use one script, and this inconsistency made
that harder.
We defined both $(VERSION) and $(PACKAGE_VERSION) with the same contents.
$(PACKAGE_VERSION) is slightly more descriptive, so settle on that, and
drop the other define.
busctl is not part of libsystemd, and should not be stored under libsystemd.
In particular this is confusing because busctl is linked with libshared, but
stuff in libsystemd is not supposed to depend on libshared.
Kernel default mode is 0600, but distributions change it to group kvm, mode
either 0660 (e.g. Debian) or 0666 (e.g. Fedora). Both approaches have valid
reasons (a stricter mode limits exposure to bugs in the kvm subsystem, a looser
mode makes libvirt and other virtualization mechanisms work out of the box for
unprivileged users over ssh).
In Fedora the qemu package carries the relevant rule, but it's nicer to have it
in systemd, so that the permissions are not dependent on the qemu package being
installed. Use of packaged qemu binaries is not required to make use of
/dev/kvm, e.g. it's possible to use a self-compiled qemu or some alternative.
https://bugzilla.redhat.com/show_bug.cgi?id=1431876
To accomodate both approaches, add a rule to set the mode in 50-udev-default.rules,
but allow the mode to be overridden with a --with-dev-kvm-mode configure rule.
The default is 0660, as the (slightly) more secure option.
Very few parts of the systemd source require <math.h> or "libm.so".
Linking libbasic with -lm drags the mathematical library in for all
systemd components, and in turn for all users of systemd libraries.
It's just unneeded.
The emergency.service and rescue.service units have become rather
convoluted. We spawn multiple shells and the help text spans multiple lines
which makes the units hard to read.
Move the logic into a single shell script and call that via ExecStart.
The legacy *.pkla files are not required when running against polkit ≥ 106,
and we want to avoid shipping files in /var if possible (but pkla files
can only be in /etc/ or /var).
Only install the *.pkla files if we detect an old polkit version during
configure. Don't install them if polkit isn't installed during build, as
distributions other than Debian-based ones have moved to the new polkit
long ago.
Fixes#5523
Compiling against the dm-ioctl.h header as provided by the Linux kernel
will embed the DM interface version number. Running an older kernel can
result in an error like this on shutdown:
Could not detach DM dm-11: ioctl mismatch, kernel(4.34.4), user(4.35.4)
Work around this by shipping a local copy of dm-ioctl.h. We need at
least the version from 3.13 for DM_DEFERRED_REMOVE [1], so bump the
requirements in README accordingly.
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2c140a246dc0bc085b98eddde978060fcec1080cFixes: #5492
The only functional change is that log_notice("No journal files were found.")
is not printed any more with --quiet. log_error("No journal files were opened
due to insufficient permissions.") is still printed.
I wasn't quite sure where to put this function, but shared/ seems to be the
right place and none of the existing files seem to fit too well.
v2: rename journal_access_check to journal_access_check_and_warn.
As per commit 25e773e "udev: switch to systemd logging functions"
Now log_set_max_level() in udev_new() overwites system wide log level.
Propagate the udev.conf setting to log_set_max_level()
only if udev_new() is called from within udevd or one of its helpers.
Introduce a UDEV_PROPAGATE_LOG macro that we set with -D on
the gcc command line for all udev binaries we build, but not
for any others. The log_set_max_level() call is guarded by an
ifdef check for that macro, so that it only effects the various
udev binaries.
closes: #4525
We have ./configure switches for various parts of non-essential functionality,
let's add one for this new stuff too. Support for environment generators is
not conditional — if you don't want them, just don't install any.
Add support for /etc/environment and document the changes to the user manager
to automatically import environment *.conf files from:
~/.config/environment.d/
/etc/environment.d/
/run/environment.d/
/usr/local/lib/environment.d/
/usr/lib/environment.d/
/etc/environment
Why the strange name: the prefix is necessary to follow our own advice that
environment generators should have numerical prefixes. I also put -d- in the
name because otherwise the name was very easy to mistake with
systemd.environment-generator. This additional letter clarifies that this
on special generator that supports environment.d files.
v2:
- add example files to EXTRA_DIST
v3:
- rework for the new scheme where nothing is written to disk
v4:
- use separate dirs for system and user env generators
Environment file generators are a lot like unit file generators, but not
exactly:
1. environment file generators are run for each manager instance, and their
output is (or at least can be) individualized.
The generators themselves are system-wide, the same for all users.
2. environment file generators are run sequentially, in priority order.
Thus, the lifetime of those files is tied to lifecycle of the manager
instance. Because generators are run sequentially, later generators can use or
modify the output of earlier generators.
Each generator is run with no arguments, and the whole state is stored in the
environment variables. The generator can echo a set of variable assignments to
standard output:
VAR_A=something
VAR_B=something else
This output is parsed, and the next and subsequent generators run with those
updated variables in the environment. After the last generator is done, the
environment that the manager itself exports is updated.
Each generator must return 0, otherwise the output is ignored.
The generators in */user-env-generator are for the user session managers,
including root, and the ones in */system-env-generator are for pid1.
The change:
-/usr/lib/systemd/system/dbus-org.freedesktop.resolve1.service
+/etc/systemd/system/dbus-org.freedesktop.resolve1.service
If resolved is disabled, without this, talking to the resolved bus API will
activate it regardless whether it is enabled or not, let's fix that.
automake helpfully sets a few variables for during build. When our executable
is in a directory underneath $(abs_top_builddir), we know that we're in the
build environment $(abs_top_srcdir) contains the sources, and test data is
under $(abs_top_srcdir)/test. This remains true no matter where the build
directory is relative to the source directory. It also works if the test
executable is invoked as ./test-whatever or .libs/test-whatever, since the
relative path is not used at all.
When running from outside of the build directory, we should be running from the
installed location and we can look for ../testdata relative to the location of
the exe file.
Of course, $SYSTEMD_TEST_DATA always overrides this logic.
