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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
struct statx in glibc header was introduced in glibc-2.28
(fd70af45528d59a00eb3190ef6706cb299488fcd), but at that time,
sys/stat.h conflicts with linux/stat.h. Since glibc-2.30
(5dad6ffbb2b76215cfcd38c3001778536ada8e8a), sys/stat.h includes
linux/stat.h if exists.
Since now our baseline of glibc is 2.31. Hence, we can drop workarounds
for struct statx by importing linux/stat.h from newer kernel (v6.14-rc4).
In Arch Linux we currently have a half-baked apparmor support,
in particular we cannot link systemd to libapparmor for service
context integration, since that will pull apparmor into base system.
Hence, let's turn this into a dlopen dep.
Ref: https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/issues/22
This fixes the following error:
In file included from ../src/basic/macro.h:13,
from ../src/basic/env-util.h:9,
from ../src/nss-systemd/nss-systemd.c:7:
../src/fundamental/macro-fundamental.h:61:9: error: option ‘-Wzero-as-null-pointer-constant’ is valid for C++/ObjC++ but not for C [-Werror=pragmas]
61 | _Pragma("GCC diagnostic ignored \"-Wzero-as-null-pointer-constant\"")
| ^~~~~~~
../src/nss-systemd/nss-systemd.c:106:1: note: in expansion of macro ‘DISABLE_WARNING_ZERO_AS_NULL_POINTER_CONSTANT’
106 | DISABLE_WARNING_ZERO_AS_NULL_POINTER_CONSTANT;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
This makes the UID range configurable via build time options, but of
course it really shouldn't be changed. The default range I picked is
outside even of IPAs current (ridiculously large) allocation ranges,
hence hopefully minimizes conflicts.
Plus, linux/random.h never defined getrandom(), hence remove
the custom machinery for sys/random.h vs linux/random.h
in favor of single HAVE_GETRANDOM.
We assume its existence in basic/build-path.c, shared/userdb.c,
and coredump/coredump.c already, for which nothing has been reported
so far. So this seems safe to drop.
We carry our own definitions in missing_mman.h, and otherwise
sys/mman.h is employed. Let's drop the unneeded detection/inclusion
of linux/memfd.h hence.
Let's gather generic key/certificate operations in a new tool
systemd-keyutil instead of spreading them across various special purpose
tools.
Fixes#35087
Let's gather generic key/certificate operations in a new tool
systemd-keyutil instead of spreading them across various special
purpose tools.
Fixes#35087
I very much dislike the approach in which we were mixing Linux and UEFI C code
in the same subdirectory. No code was shared between two environments. This
layout was created in e7dd673d1e0acfe5420599588c559fd85a3a9e8f, with the
justification of "being more consistent with the rest of systemd", but I don't
see how it's supposed to be so.
Originally, when the C code was just a single bootctl.c file, this wasn't so
bad. But over time the userspace code grew quite a bit. With the moves done in
previuos commits, the intermediate subdirectory is now empty except for the
efi/ subdir, and this additional subdirectory level doesn't have a good
justification. The components is called "systemd-boot", not "systemd-efi", and
we can remove one level of indentation.
We have other subdirectories with just a single C file. And I expect
that systemd-measure will only grow over time, adding new functionality.
It's nicer to give its own subdirectory to maintain consistent structure.
This commit introduces a build-time option to enable/disable sysupdated
separately from sysupdate. 'auto' translated to enabled by default in
developer builds.
The default definition to add is `-D__loongarch64__`, which is not searched in [bpf_tracing.h](09b9e83102/src/bpf_tracing.h (L68))
This may avoid `error: Must specify a BPF target arch via __TARGET_ARCH_xxx` in loongarch64
Signed-off-by: Zhou Qiankang <wszqkzqk@qq.com>
IPE is a new LSM being introduced in 6.12. Like IMA, it works based on a
policy file that has to be loaded at boot, the earlier the better. So
like IMA, if such a policy is present, load it and activate it.
If there are any .p7b files in /etc/ipe/, load them as policies.
The files have to be inline signed in DER format as per IPE documentation.
For more information on the details of IPE:
https://microsoft.github.io/ipe/
For compiling bpf code, the system include directory needs to be
constructed. On Debian-like systems, this requires passing a multiarch
directory. Since clang's -dump-machine prints something other that the
multiarch triplet, gcc was interrogated earlier, but that also yields a
wrong result for cross compilation and was thus skipped resulting in
clang not finding asm/types.h.
Rather than, -dump-machine we should ask for -print-multiarch (which
rarely differs). Whenever gcc is in use, this is right (even for cross
building). Since clang does not support -print-multiarch and its
-dump-machine never matches Debian's multiarch, we resort to asking gcc
when building natively. For cross builds using clang, we are out of
luck.
