Building with GCC 12.2 and binutils 2.39 fails on riscv64 Ubuntu Kinetic
with:
FAILED: systemd-oomd
/usr/bin/ld: systemd-oomd.p/src_oom_oomd-util.c.o:
in function `oomd_cgroup_context_acquire':
build/../src/oom/oomd-util.c:415:
undefined reference to `__atomic_exchange_1'
We have to link with -latomic.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
For now, this simply outputs the PCR hash values expected for a kernel
image, if it's measured like sd-stub would do it.
(Later on, we can extend the tool, to optionally sign these
pre-calculated measurements, in order to implement signed PCR policies
for disk encryption.)
Everywhere else that `conf.get('ENABLE_*')` is used as a boolean key for
something (for example in if statements) it always checks if == 1, but
in this one case it neglects to do so. This is important because
conf.get yields the same int that was stored, but if statements require
booleans.
So does executable's "install" kwarg, at least according to the
documentation. In actuality, it accepts all types without sanity
checking, then uses python "if bool(var)", so you can actually do
`install: 'do not'` and that's treated identical to `true`. This is a
type-checking bug which Meson will eventually fix.
muon fails on the same code, today.
0 UID and GID are special, and should not be acceptable for the settings.
Hence, we can handle 0 as unset.
Strictly speaking, time epoch with 0 is valid, but I guess no one use
0 as a valid value.
The journalctl tool may be needed on cross compilation hosts in order
to run --update-catalog against a target rootfs.
To avoid reliability issues caused by shared linking allow journalctl
to be linked statically.
The idea is that we can peek into /sysroot/etc/fstab and figure out if there's
anything interesting there. We could use a separate binary for this, but we'd
need to duplicate most of the logic that in systemd-fstab-generator. Thus I
think it's nicer to make systemd-fstab-generator work as a multi-call binary.
If called as systemd-sysroot-fstab-check, we look for units that we'd mount and
call daemon-reload and initrd-fs.target/restart, similarly to what we did
before, but in the process itself.
DefaultSmackProcessLabel tells systemd what label to assign to its child
process in case SmackProcessLabel is not set in the service file. By
default, when DefaultSmackProcessLabel is not set child processes inherit
label from systemd.
If DefaultSmackProcessLabel is set to "/" (which is an invalid character
for a SMACK label) the DEFAULT_SMACK_PROCESS_LABEL set during compilation
is ignored and systemd act as if the option was unset.
I opted to tweaking kernel-install to allow overriding config
(with $KERNEL_INSTALL_CONF_ROOT, $KERNEL_INSTALL_PLUGINS). An alternative
would be to build a test environment in test/. We can still do that,
but I think it's nice to have a simple test that is very quick and easy
to debug.
Invocation as installkernel is for #23681.
Before we had the following scheme:
mempool_enabled() would check mempool_use_allowed, and
libsystemd-shared would be linked with a .c file that provides mempool_use_allowed=true,
while other things would linked with a different .c file with mempool_use_allowed=false.
In the new scheme, mempool_enabled() itself is a weak symbol. If it's
not found, we assume false. So it only needs to be provided for libsystemd-shared,
where it can return false or true.
test-set-disable-mempool is libshared, so it gets the symbol. But then we
actually disable the mempool via envvar. mempool_enable() is called to check
its return value directly.
I think developers are particularly unlikely to find the descriptions
useful, and would benefit from being able to copy&paste unit names.
Let's make this choice automatically.
Profiling tools tend to work better when binaries and libraries
are compiled with frame pointers as without them there's no easy
and fast way to get the current stacktrace.
https://github.com/systemd/systemd/pull/23192 caused breakage in
Arch Linux's build tooling. Let's give users an opt-out aside from
reverting the patch. It's hardly any maintenance work on our side
and gives users an easy way to revert the locale change if needed.
Of course, by default we still pick C.UTF-8 if the option is not
specified.
On Debian, libdir is commonly something like 'lib/x86_64-linux-gnu'.
The result of get_option('libdir') is normalized to a prefix-relative
path by meson, so we can just append it to rootprefixdir.
Fixes https://github.com/systemd/systemd/issues/23648.
Introduce rootpkglibdir for installing libsystemd-{shared,core}.so.
The benefit over using rootlibexecdir is that this path can be
multiarch aware, i.e. this path can be architecture qualified.
This is something we'd like to make use of in Debian/Ubuntu to make
libsystemd-shared co-installable, e.g. for i386 the path would be
/usr/lib/i386-linux-gnu/systemd/libsystemd-shared-*.so and for amd64
/usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-*.so.
This will allow for example to install and run systemd-boot/i386 on an
amd64 host. It also simplifies/enables cross-building/bootstrapping.
For more infos about Multi-Arch see https://wiki.debian.org/Multiarch.
See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990547
We're already using C.UTF-8 as the default locale for nspawn. Let's
make the same change for the default-locale option instead of deciding
what to use based on the locale used by the host system. Users can
still override the locale using the default-locale option if needed.
If both gnutls and openssl are available, prefer openssl.
We are gradually moving toward supporting openssl only as the
crypto library, and the resolved gnutls backend will be dropped
at some point, so start nudging users toward the openssl one.
Even if we use meson >= 0.55, using path() does not produce any error or
warning if the required version is below 0.55.
Let's convert path() with full_path() when we requires meson >= 0.55.
Setting with number is deprecated:
```
meson.build:1008: DEPRECATION: configuration_data.set10 with number. the `set10` method should only be used with booleans
```
Passing potentially arbitrary data into a shellscript is potentially
very broken if you do not correctly quote it for use. This quoting must
be done as part of the interpretation of the data itself, e.g. python's
shlex.quote; simply formatting it into a string with double quotes is
NOT sufficient.
An alternative is to communicate the data reliably via argv to the shell
process, and allow the shell to internally handle it via `"$1"`, which
is quote-safe and will expand the data from argv as a single tokenized
word.
