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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
CentOS 8 ships python 3.6 so let's try and stay compatible with that
since the only feature we're using that requires python 3.9 is the
streamlined type annotations which are trivial to convert back to
the older stuff to stay compatible with python 3.6.
When running from the build directory systemd-detect-virt might not be installed,
so tell meson to set up the PATH accordingly to point to the build directory.
Fixes https://github.com/systemd/systemd/issues/28316
When building on a x32 system we need to explicitly pass `-m64` to get
the right ABI as the kernel and EFI are still 64bit. For this to
actually work, a suitable multilib compiler, 32bit libc headers and
libgcc need to be installed (similar to ia32 builds on x86_64).
On x32 efi_arch will be set as the kernel architecture is just x86_64,
but there's no userland support to build the EFI ABI. When -Dbootloader=false
is set, skip libefitest too.
Some distributions still use glibc's libcrypt. In that case, libcrypt.pc
does not exist and dependency() will fail.
Also, even if libxcrypt is used, there may not be a symlink
from libcrypt.pc to libxcrypt.pc. So, let's add a secondary name.
Follow-up for d625f717db.
Fixes#28289.
This also drops the fallback for libacl, libcap, libcrypt, and libgcrypt,
as recent Ubuntu (at least, 20.04 LTS and newer) and Debian (at least, buster
and newer) have relevant .pc files.
Fixes#28161.
This changes the generated config.h file thusly:
-#define _GNU_SOURCE
+#define _GNU_SOURCE 1
Canonically, _GNU_SOURCE is just defined, without any value, but g++ defines
_GNU_SOURCE implicitly [1]. This causes a warning about a redefinition during
complilation of C++ programs after '-include config.h'. Our config attempts to
inject this (and a bunch of other arguments) into all compliations. But before
meson 0.54, flags for dependencies were not propagated correctly (*), and the C++
compilation was done without various flags (**). Once that was fixed, we started
getting a warning.
[1] http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.predefined
(*) Actually, the changelog doesn't say anything. But it mentions various work
related to dependency propagation, and apparently this changes as a side
effect.
(**) -fno-strict-aliasing
-fstrict-flex-arrays=1
-fvisibility=hidden
-fno-omit-frame-pointer
-include config.h
This could be solved in various ways, but it'd require either making the
compilation command line longer, which we want to avoid for readability of the
build logs, or splitting the logic to define the args for C++ progs separately,
which would make our meson.build files more complicated. Changing the
definition to '1' also solves the issue (because apparently now we match the
implicit definition), and shouldn't have other effects. I checked compilation
with gcc and clang. Maybe on other systems this could cause problems. We can
revisit if people report issues.
This is mostly a one-to-one translation of kernel-install.sh, except for
the followings:
- BOOT_ROOT is searched with find_{esp,xbootldr}_and_warn().
- entry token is searched with boot_entry_token_ensure().
- inspect command verboses more information, e.g. found plugins,
environment variables explicitly passed to plugins, arguments passed
to plugins.
- paths specified in $KERNEL_INSTALL_PLUGINS must be absolute.
- LC_COLLATE is set to C.UTF-8 (or any specified on build time).
By writing kernel-install C, we can share the code used by bootctl or
so, and can introduce --root and/or --image options later.
In b6033b7060 support was added to create
{/etc|/run}/credstore{|.encrypted} via tmpfiles.d with perms 0000. These
perms are so restrictive that not even root can access them unless it
has CAP_DAC_OVERRIDE capability. This is creates the dirs at boot time
In 24039e1207 support was added to create
/etc/credstore with perm 0700 from meson.build at build time.
This patch makes unifies the two parts:
1. creates both /etc/credstore *and* /etc/credstore.encrypted in both
places (the build system still won't create them in /run/, since
that's pointless since not shipped, and the runtime won't create the
dirs below /usr/lib/, since that's not generically writable anyway).
2. Both at runtime and at build time we'll create the dirs with mode
0700. This is easier for packaging tools to handle since they
generally react pretty negatively on dirs they can't enumerate.
The entries are sorted by speed. Some fields are left empty when there is no
clear value to use. The table is much longer now, but I think it's better to
document the allowed values, even if some are not terribly useful.
Fixes#26256.
Let's make the creds directories a bit more discoverable and make it
easier for users to use them. This also allows us to fix the
mode to 0700 for /etc instead of the usual 0755 which is what probably
would happen if users had to create this directory themselves.
Build option "link-portabled-shared" to build a statically linked
systemd-portabled by using
-Dlink-portabled-shared=false
on systems with full systemd stack except systemd-portabled, such
as CentOS/RHEL 9.
As part of the build, we would populate build/test/sys/ using
sys-script.py, and then udev-test.p[ly] would create a tmpfs instance
on build/test/tmpfs and copy the sys tree to build/test/tmpfs/sys.
Also, we had udev-test.p[ly] which called test-udev. test-udev was
marked as a manual test and installed, but neither udev-test.p[ly] or
sys-script.py were.
test-udev is renamed to udev-rule-runner, which reduces confusion and
frees up the test-udev name. udev-test.py is renamed to test-udev.py.
All three files are now installed.
test-udev.py is modified to internally call sys-script.py to set up the
sys tree. Copying and creating it from scratch should take the same
amount of time. We avoid having a magic directory, everything is now
done underneath a temporary directory.
test-udev.py is now a normal installed test, and run-unit-tests.py will
pick it up. When test-udev.py is invoked from meson, the path to
udev-rule-runner is passed via envvar; when it is invoked via
run-unit-tests.py or directly, it looks for udev-rule-runner in a relative
path.
The goal of this whole change is to let Debian drop the 'udev' test.
It called sys-script.py and udev-test.pl from the source directory and
had to recreate a bunch of the logic. Now test-udev.py will now be called
via 'upstream'.
We install a kernel with layout=uki and uki_generator=ukify, and test
that a UKI gets installed in the expected place. The two plugins cooperate,
so it's easiest to test them together.
We can always build the standalone version whenever we build the normal version
(the dependencies are the same). In most builds standalone binaries would be
disabled. But it is occasionally useful to have them for testing, so move the
conditional to install:, so the binaries can be build by giving the explicit
target name.
The default of 'build_by_default' for executable() is sadly true (since meson
0.38.0), so need to specify build_by_default: too.
Also add systemd-shutdown.standalone to public_programs for additional testing.
When executable() or custom_target() has install: that is conditional as is
false (i.e. not install:true), it won't be built by default. (build_by_default:
defaults to install:). But if that program is added to public_programs, it will
be build by default because it is pulled in by the test, effectively defeating
the disablement.
While at it, make 'ukify' follow the same pattern as 'kernel-install'.
They will be used later together.
/usr/lib/systemd/tests may contain more than the unit tests. For example on
SUSE we also install the integration tests there.
Putting the unit tests in a dedicated directory named 'unit-tests' makes the
layout cleaner.
Note that `run-unit-tests.py` has not been moved so we don't need to adjust
(Fedora) packaging and users also don't need to descend into the subdirectory.
This adds back sd-boot builds by using meson compile targets directly.
We can do this now, because userspace binaries use the special
dependency that allows us to easily separate flags, so that we don't
pass anything to EFI builds that shouldn't be passed.
Additionally, we pass a bunch of flags to hopefully disable/override any
distro provided flags that should not be used for EFI binaries.
Fixes: #12275
This drops all mentions of gnu-efi and its manual build machinery. A
future commit will bring bootloader builds back. A new bootloader meson
option is now used to control whether to build sd-boot and its userspace
tooling.
Although udev rules are already being checked by rule-syntax-check.py
script, also check them using udevadm verify which performs more
thorough checks.
With this change we'll install a symlink /sbin/mount.ddi →
systemd-dissect. If invoked that way we'll do the equivalent of
systemd-dissect --mount.
This makes DDIs mountable directly via the "mount" command, by
specifying the "-t ddi" pseudo file system type. Moreover you can now
mount DDIs directly via /etc/fstab, by specifying "ddi" in the file
system column (3rd column).
IN C23, thread_local is a reserved keyword and we shall therefore
do nothing to redefine it. glibc has it defined for older standard
version with the right conditions.
v2 by Yu Watanabe:
Move the definition to missing_threads.h like the way we define e.g.
missing syscalls or missing definitions, and include it by the users.
Co-authored-by: Yu Watanabe <watanabe.yu+github@gmail.com>
When mkosi is run from git-worktree(1), the .git is not a repository
directory but a textfile pointing to the real git dir
(e.g. /home/user/systemd/.git/worktrees/systemd-worktree). This git dir
is not bind mounted into build environment and it fails with:
> fatal: not a git repository: /home/user/systemd/.git/worktrees/systemd-worktree
> test/meson.build:190:16: ERROR: Command `/usr/bin/env -u GIT_WORK_TREE /usr/bin/git --git-dir=/root/src/.git ls-files ':/test/dmidecode-dumps/*.bin'` failed with status 128.
There is already a fallback to use shell globbing instead of ls-files,
use it with git worktrees as well.
Most of the support for valgrind was under HAVE_VALGRIND_VALGRIND_H, i.e. we
would enable if the valgrind headers were found. The operations then we be
conditionalized on RUNNING_UNDER_VALGRIND.
But in a few places we had code which was conditionalized on VALGRIND, i.e. the
config option. I noticed because I compiled with -Dvalgrind=true on a machine
that didn't have valgrind.h, and the build failed because
RUNNING_UNDER_VALGRIND was not defined. My first idea was to add a check that
the header is present if the option is set, but it seems better to just remove
the option. The code to support valgrind is trivial, and if we're
!RUNNING_UNDER_VALGRIND, it has negligible cost. And the case of running under
valgrind is always some special testing/debugging mode, so we should just do
those extra steps to make valgrind output cleaner. Removing the option makes
things simpler and we don't have to think if something should be covered by the
one or the other configuration bit.
I had a vague recollection that in some places we used -Dvalgrind=true not
for valgrind support, but to enable additional cleanup under other sanitizers.
But that code would fail to build without the valgrind headers anyway, so
I'm not sure if that was still used. If there are uses like that, we can
extend the condition for cleanup_pools().
