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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The handling of whitespace in pyparsing is a bother. There's some
global state, and per-element state, and it's hard to get a handle on
things. With python3-pyparsing-2.4.7-10.fc36.noarch the grammar would
not match. After handling of tabs was fixed to not accept duplicate tabs,
the grammar passes.
It seems that the entry for usb:v8087p8087*
was generated incorrectly because we treated the interface line
(with two TABs) as a device line (with one TAB).
Follow-up for 00adc340bb.
This fixes the wrong "Received invalid inotify event, ignoring." warnings
caused by the missing curly brackets and the priorities of `&&` and `?:`.
This also replaces the ternary operators with `||`.
Let's raise our supported baseline a bit: CLOCK_BOOTTIME started to work
with timerfd in kernel 3.15 (i.e. back in 2014), let's require support
for it now.
This will raise our baseline only modestly from 3.13 → 3.15.
Defaults to /bin/bash, no changes in the default configuration
The fallback shell for non-root users is as-specified,
and the interactive shell for nspawn sessions is started as
exec(default-user-shell, "-" + basename(default-user-shell), ...)
before falling through to bash and sh
The first three fields of a note are binary, so they are subject to
flipping due to endianess. Instead of a stream of bytes, just use
the native 4-bytes type so that it gets encoded automatically.
Implemented in the tools via: https://github.com/systemd/package-notes/pull/31
Instead of escaping each component separately, we can instead use
quote_command_line. Doing so simplifies the code and fixes an issue
where spaces inside the executable name were not escaped.
Co-Authored-By: David Edmundson <kde@davidedmundson.co.uk>
This fixes a bug introduced by 7be4b23649.
The function `efi_loader_get_device_part_uuid()` handles NULL
gracefully, and it is called with NULL in gpt-auto-generator.
Fixes#22862.
Previously, if a block device is locked by another process, then the
corresponding worker skip to process the corresponding event, and does
not broadcast the uevent to libudev listners. This causes several issues:
- During a period of a device being locked by a process, if a user trigger
an event with `udevadm trigger --settle`, then it never returned.
- When there is a delay between close and unlock in a process, then the
synthesized events triggered by inotify may not be processed. This can
happens easily by wrapping mkfs with flock. This causes severe issues
e.g. new devlinks are not created, or old devlinks are not removed.
This commit makes events are requeued with a tiny delay when the corresponding
block devices are locked by other processes. With this way, the triggered
uevent may be delayed but is always processed by udevd. Hence, the above
issues can be solved. Also, it is not necessary to watch a block device
unconditionally when it is already locked. Hence, the logic is dropped.
Let's be more precise here. Otherwise people might think this describes
the software system or so. We already expose this via hostnamed as
HardwareVendor/HardwareModel hence use the exact same wording.
(Note that the relevant props on the dmi device are just VENDOR/MODEL,
but that's OK given that DMI really is about hardware anyway,
unconditionally, hence no chance of confusion there.)
Follow-up for 4fc7e4f374
Previously, `event_run()` was called repeatedly in one `event_queue_start()`
invocation. Hence, the SELinux label database is reloaded many times needlessly.
Other settings, e.g. udev rules or hwdata, are tried to be reloaded in the
beginning of `event_queue_start()`. Let's also do so for the SELinux database.
Previously, if udevd failed to resolve event dependency, the event is
ignored and libudev listeners did not receive the event. This is
inconsistent with the case when a worker failed to process a event,
in that case, the original uevent sent by the kernel is broadcasted to
listeners.
The ENOENT, ENXIO, and ENODEV error can happen easily when a block
device appears and soon removed. So, it is reasonable to ignore the
error. But other errors should not occur here, and hence let's handle
them as critical.
