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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If the tty arg is set to "-", agetty uses the stdin fd as the tty.
Let's pass the tty this way so that we keep an fd open to the tty
at all times. If all fd's to a tty are closed, the kernel might
reset the tty which we want to avoid.
Imports are sorted in the usual fashion: stdlib first.
literal_eval() parses string/numbers/lists/sets/dicts, and nothing else, while
eval will execute any python code. Using literal_eval() is generally more
correct, because it avoids the risk of side effects from the parsed expression.
In this case, we generate the parsed strings ourselves, so it's very unlikely
to have anything unexpected in the expressions. But let's do the correct thing
anyway.
The LoopDevice object supports a shortcut: if the backing fd we are
supposed to create a loopback device of refers to a
block device alrady then we'll use it as is – if we can – instead of
setting up an unnecessary loopback device that would be pretty much
the same as its backing device.
Previously, when doing this we'd just dup() the original backing fd and
use that. But that's problematic in case O_DIRECT was set on the fd,
since we'll keep that flag set on our copy too, which means we can't do
simple, regular IO on it anymore.
Thus, let's reopen the inode in this case with the exact access flags
we'd apply if we'd actually allocate and open a new loopback device.
Fixes: #21176
efi_arch is set to whatever meson returns from host_machine.cpu_family() and
gnu_efi_arch is then set accordingly.
On x86, efi_arch == x86 and gnu_efi_arch == ia32. Surprisingly, compilation
worked (without disabling some instruction sets) and nobody ever complained
about systemd-bootia32.efi not working.
This brings the final list of compiler arguments more in line with
how meson does things. In particular, --buildtype=plain will not
add any optimizations on its own (and would have to be provided
through CFLAGS=).
These flags are used by gnu-efi. Adding --no-undefined even allows
us to drop the no-undefined-symbols.sh test in favor of immediate
compile time errors.
This is not a hosted environment and we should not pretend otherwise
if -ffreestanding is not supported.
With EFI strings being in UCS2, it is not supported to build without
-fshort-wchar as gcc/clang default to a w_char_t size of 4 bytes.
This also makes the charset for wide chars explicit on gcc. This way
we get a nice error message if anyone ever tries to add 💩 to strings.
(Or when -H is used, since -H and -M are incompatible.)
Note that the slightly unusual form with separate boolean variables (hint_vars,
hint_addr) instead of e.g. a const char* variable to hold the message, because this
way we don't trigger the warning about non-literal format.
rearrange_stdio() invalidates specified fds even on failure, which means
we should always invalidate the fds we pass in no matter what. Let's
make this explicit by using TAKE_FD() for that everywhere.
Note that in many places we such invalidation doesnt get us much
behaviour-wise, since we don't use the variables anymore later. But
TAKE_FD() in a way is also documentation, it encodes explicitly that the
fds are invalidated here, so I think it's a good thing to always make
this explicit here.
Alternative to https://github.com/systemd/systemd/pull/20531.
Whenever a service triggered by another unit fails condition checks,
stop the triggering unit to prevent systemd busy looping trying to
start the triggered unit.
I got the logic reversed in 6d93265955.
Let's just remove the conditionalization of the status message: if we're
sending something, we might just as well always attach READY=1, the extra
few bytes don't make much of a difference.
FWIW, it seems that this bug didn't cause problems, probably because we'd send
READY=1 either from user_manager_send_ready() or from a later call to
manager_send_ready().
Most sd_notify() calls are like log_info() — the result is only informative
and if they fail, it's best ignore this. But if a call with READY=1 fails,
the unit may enter a failed state, so we should warn about this. Similarly
for FSTOREREMOVE=1: the manager may be left with a stale fd, at least wasting
resources.
… but only for a single variable.
The guidelines already allowed declaring variables at the point of
initialization. But not making a function call to do that. Let's allow that
now. The existing style of declaring and initializing seperate is still
allowed, and whatever makes most sense should be used.
It is only added in the one place where we actually try to set the
setting to a new value. Before we were testing if we can set to it the
existing value, which was a noop. We could still get a permission error,
but this is the first place where we would propagate EROFS.
From packit/rawhide-arm64 logs:
Assertion 'limit >= INT_MAX || get_process_ppid(limit+1, NULL) == -ESRCH' failed at src/test/test-process-util.c:855, function test_get_process_ppid(). Aborting.
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
The kernel has a few different limits. In particular kernel.threads-max can be
set to some lower value, and kernel.pid_max can be set to a higher value. This
is nice because it reduces PID reuse, even if the number of threads that is
allowed is limited. But the tests assumed that we cannot have a thread with
PID above MIN(kernel.threads-max, kernel.pid_max-1), which is not valid.
So let's rework the whole thing: let's expose the helpers to read
kernel.threads-max and kernel.pid_max, and print what they return in tests.
procfs_tasks_get_limit() was something that is only used in tests, and wasn't
very well defined, so let's drop it.
Fixes#21193.
This test makes assumptions on the availability of some mappings contained in
kbd-model-map and therefore strongly relies on the version shipped by
upstream. IOW the test is likely to fail if it's installed on a system with a
more comprehensive kbd-model-map.
This patch makes the upstream kbd-model-map file available via a symlink in
test/testdata/test-keymap-util dir and makes sure that this specific version is
always used by test-keymap-util regardless of whether the test is installed and
run on a different system or directly run (optionally via meson) from the
project working dir.
Let's document this for now. We should be able to lift these limitations
sooner or later, at which point we can drop this documentation again.
These two limitations are a pitfall that people should be aware of,
before going FIDO2-only.
See: #20230#19208
