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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
ATTOW llvm-11 got into focal-updates, which conflicts with llvm-11
provided by the apt.llvm.org repositories. Let's use the system
llvm package if available in such cases to avoid that.
Previously, the lifetime was 30 minutes. But it is not necessary to set
to such short time compared with prefix or route prefix lifetime.
Note that the propagated DNS servers and domains are all 'static',
that is, configured in a .network file, and not provided dynamically.
So, it should be safe to use longer lifetime.
This is a debugging feature. It's sometimes incredibly useful to be able
to run a second instance of homed that operates on another dir than
/home/.
Specifically, if you build homed from the source tree you can now run an
instance of it pretty reasonably directly from the build tree via:
sudo SYSTEMD_HOME_DEBUG_SUFFIX=foo SYSTEMD_HOMEWORK_PATH=$(pwd)/build/systemd-homework SYSTEMD_HOME_ROOT=/home/foo ./build/systemd-homed
And then talk to it via
sudo SYSTEMD_HOME_DEBUG_SUFFIX=foo homectl …
(you might need to tweak your dbus policy for this to work fully though)
The pin fd keeps the mount busy, ensuring that unmount requests need to
go through us.
Note that this doesn't change too much IRL, since a logged in user
generally has processes keeping the home dir busy anyway. However, in
some corner cases it is safer to protect from accidental unmounts this
way. (e.g. if user manually called "homectl activate" first).
Currently, when Xen PV domains are nested within a hypervisor which is
detected through CPUID (such as VMware), the detected hypervisor might
not be Xen, because we don't check for Xen until after the CPUID check.
This change moves the Xen check before CPUID checks to fix the issue,
and moves Dom0 checking to detect_vm_xen so that we keep ignoring Xen
when we are in Dom0.
Register a LINUX_EFI_INITRD_MEDIA_GUID DevicePath with a LoadFile2Protocol interface and serve the initrd to a supported Linux kernel (Version 5.8+)
Leave the x86 code for older kernels in place until supported kernels become more mainstream
Let's use the underlying Linux API directly, instead of
opendir()/readdir(). This makes it possible for us to do a single memory
allocation for all directory entries in common cases, instead of one for
each entry.
glibc 2.30 (Aug 2019) added a wrapper for getdents64(). For older
versions let's define our own.
(This syscall exists since Linux 2.4, hence should be safe to use for
us)
Using kernel types __u32 is fine for headers shared by the kernel, but
if we define something in userspace and only use it in userspace, in our
own .c files, let's stick to userspace fixed-length types.
We already did that for sd-boot, hence do it for sd-stub the same way.
Also, move the __attribute__ stuff to the beginning of the statement,
rather than the middle. Mostly just because we usually put it first for
implementations for identifiers (for prototypes we put it last).
ANSI C reserves identifiers beginning with an underscore for compiler
internal stuff. We already invade that namespace plenty and probably
should not. But even going for the doubly underscore prefixed namespace
is a bit too much. Let's just rename the offending table as
"static_signal_table[]", since it lists the static defined signals
rather than the "dynamic" RTSIGMIN/RTSIGMAX signals.
So far we assumed every power source was a battery except for the ones
which definitely are not. I think this logic makes little sense, as
"battery" is kinda the exceptional case here, not the other way round.
Hence let's invert the type check, and denylist "Battery" devices rather
than allowlist "Mains" devices.
This should increase compatibility with alternative types of power
sources, in particular USB ones.
This takes into account that additional power types have been added
since we wrote the original code, and in particular should cover the
siutation discussed here OK:
https://sources.debian.org/src/powermgmt-base/1.36/power_supply.txt/#L31https://sources.debian.org/src/powermgmt-base/1.36/on_ac_power/#L25
Also, modernizes the code in various was ways.
Inspired by and fixes: #20964
