Previously, we looked for scripts in the tools/ directory ad hoc,
wherever they were needed. Let's do those checks in one place.
The main meson.build file is shrunk somewhat, which is always nice.
Instead of including distribution specific files in the subimages,
let's have one common mkosi.pkgenv/ directory that handles all the
matching which is then included in the subimages.
This gives us more control on exactly how we do the matching.
Currently, if the libmount feature is disabled, we don't build
libshared and as a result skip building every other executable as
well. Among other things, this makes our nodeps CI builds kind of
pointless since hardly any code will be compiled.
Let's improve on the situation by making libmount properly optional
in libshared. Then, we only skip building the executables that
actually need libmount.
Symbols exported by libshared can't get pruned by the linker, so
every unused exported symbol is effectively dead code we ship to users
for no good reason. Let's add a script to analyze how many such symbols
we have.
We also add a meson test to run the script on all of our binaries.
Since it detects unused symbols and still has a few false positives,
don't enable the test by default similar to the clang-tidy tests.
The script was 100% vibe coded by Github Copilot with Claude Sonnet 4.5
as the model.
Current results are (without the unused symbols list):
Analysis of libsystemd-shared-259.so
======================================================================
Total exported symbols: 4830
(excluding public API symbols starting with 'sd_')
Used symbols: 4672
Unused symbols: 158
Usage rate: 96.7%
I exclude generated files from license check, and I noticed
that this file was marked with a license header, which doesn't
make much sense, it is not copyrightable.
Currently these messages (broken for length)
2025-08-20T12:04:15.9609277Z
/home/runner/work/systemd/systemd/tools/check-version-history.py:26:
FutureWarning: This search incorrectly ignores the root element, and will be fixed in a future version.
If you rely on the current behaviour, change it to './/funcprototype/funcdef/function'
can be seen in CI output. So let's apply the suggestion.
All those files are standalone programs that can be executed directly.
Some .py files were marked executable, others weren't, probably accidentally.
Mark them all as executable in preparation for subsequent changes.
This extends the functionality introduced in #21648 to allow using
addresses chosen from a delegated prefix as well as the existing
SLAAC/LL/DHCP functionality.
- pass our system include directories to make generators use our libc
wrappers and latest kernel headers,
- include relevant headers in generated gperf file,
- use files() rather than find_program(), as the result of
find_program() cannot be passed to 'input' of custom_target(),
- move generate-bpf-delegate-configs.py to src/core/, as it is only used
by libcore.
We have already exposed device ID in the output of device ID in J
fields. Also sd_device_get_device_id() and sd_device_new_from_device_id()
are already public. Hence, making udevadm accept device IDs may be
useful.
With this change, as we save several data in /run/udev with device ID,
we can call udevadm something like the following:
```
udevadm info $(ls /run/udev/tags/uaccess)
```
Then, we can show all devices that has uaccess tag.
Follow-up for 53628612b7.
With 'or', we ignore the empty string (but not '0'), and we only call
time.time() lazily. So this works the same as the code that is replaced,
but avoids the ugly repetition.
Currently, when we want to add unit tests for code that is compiled into
an executable, we either compile the code at least twice (once for the
executable, and once for each test that uses it) or we create a static
library which is then used by both the executable and all the tests.
Both of these options are not ideal, compiling source files more than
once slows down the build for no reason and creating the intermediate
static libraries takes a lot of boilerplate.
Instead, let's use the extract_objects() method that meson exposes on
build targets. This allows us to extract the objects corresponding to
specific source files and use them in other executables. Because we
define all executables upfront into a dictionary, we integrate this into
the dictionary approach by adding two new fields:
- 'extract' takes a list of files for which objects should be extracted.
The extracted objects are stored in a dict keyed by the executable name
from which they were extracted.
- 'objects' takes the name of an executable from which the extracted
objects should be added to the current executable.
One side effect of this approach is that we can't build test executables
anymore without building the main executable, so we stop building test
executables unless we're also building the main executable. This allows
us to switch to using subdir_done() in all of these subdirectories to skip
parsing them if the corresponding component is disabled.
These changes get me down from 2439 => 2403 ninja targets on a full rebuild
from scratch.
This PR provides a new option for systemd-boot
`secure-boot-enroll-action` which allows to configure the behavior after
SecureBoot keys are enrolled.
Provides the option to either reboot or power off.
The current behavior is not changed, it will by default reboot as it did
before.
It also provides a small message about the action its going to take with
a small delay so the user can read it.
Passing in the func, file and line information complicates the
interface. On top of that, it prevents forward declaring Hashmap in
strv.h, as we need to pass the macros everywhere that we allocate a
hashmap, which means we have to include the hashmap header everywhere
we have a function that allocates a hashmap instead of just having to
forward declare Hashmap.
Let's drop the file, func and line information from the debug information.
Instead, in the future we can add a description field to hashmaps like we
already have in various other structs to describe the purpose of the hashmap
which should be much more useful than having the file, line and function where
the hashmap was allocated.
The walrus operator was introduced in python 3.9 so using it
accidentally bumped the minimum python version to 3.9 from 3.7 and
bluca still cares about keeping this working on 3.8 so let's remove
the usage of the walrus operator.
Follow up for d6a29eee2b
vsc_tag() always reruns even if the vcs-tag option is disabled. Let's
use custom_target() instead so that we can only enable build_always_stale
if the vcs-tag option is enabled.
With the latest mkosi it's possible for MinimumVersion= to be a git
commit so let's start making use of that. This will make mkosi fail
if it's executed within the systemd repository and the checked out
commit is too old.
Putting the mkosi commit sha in mkosi/mkosi.conf also allows retrieving
it without having the full source tree available.
We also make a bunch of improvements to the fetch-mkosi.py script.
Now that mkosi can automatically pick up its main configuration from
a mkosi/ subdirectory if it exists and there is no configuration in the
top level directory, let's make use of it to reduce the amount of clutter
in the top level directory of the repository.
This will also make it easier to install the mkosi configuration files as
part of the testing packages later on.
The tools image is not guaranteed to be the same distribution as the
target distribution and so might have different package environment
variables than the main image yet we currently unconditionally use the
same package environment variables for both of them.
Let's fix this by not passing the package environment variables to the
tools image and subimages anymore, and instead having the main, tools and
build images separately include a config file with the required environment
variables.
Instead of listing dependencies manually for the default tools tree,
let's reuse the prepare scripts from the build image. To make this work,
the sync script has to be configured for the tools tree as well so that
it's invoked both when building the tools tree and for the regular image,
otherwise, when doing the first build in a fresh checkout, the sync script
won't have executed yet as sync scripts for the regular images are executed
after building the default tools tree.
