The TODO says we were supposed to do that in 2019–2020 (if I interpreted the
enigmatic notation correctly). The comment in hwdb said:
> DO NOT USE THIS PROPERTY. This property is kept for backwards
> compatibility. The only known consumer, libinput, stopped reading this
> property in version 1.9.0. No new entries for this property should be
> added.
… and we're currently on libinput-1.23.0.
Most likely there are no users, and even if they are, they'll just get a
slightly misbehaving pointingstick, which shouldn't be too bad.
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.
It is marked and named as a script, so add +x otherwise Lintian complains:
W: systemd-tests: script-not-executable [usr/lib/systemd/tests/testdata/units/generator-utils.sh]
When a static null address is requested, e.g. Address=0.0.0.0/24,
then the corresponding Address object owned by Network object has
null address, and previously it did not match any addresses already
assigne to the interface.
Let's search matching Address object when originally it is requested as
the null address.
Then, the address configured with requested as a null address will be
kept on reconfigure.
Fixes#26113.
Request may refer Address object owned by Link, but its broadcast
address or label may be updated by address_equalify(), hence these
fields cannot be used in the hash and compare functions.
Introduce a manual test tool that creates a journal, corrupts it by
flipping bits at given offsets, and then attempts to write to the journal.
In ideal case we should handle this gracefully without any crash or
memory corruption.
With the fix done in PR28215, the unit restart job is created with type JOB_START.
Because of that, it is not properly merged anymore with the old one: the
merged job has state JOB_RUNNING. It should have state JOB_WAITING.
I think that the old job is not cleaned up because we don't go through the failed state.
With this fix, the merged job is properly created with state JOB_WAITING.
When this option is set to direct, the service restarts without entering a failed
state. Dependent units are not notified of transitory failure.
This is useful for the following use case:
We have a target with Requires=my-service, After=my-service.
my-service.service is a oneshot service and has Restart=on-failure in
its definition.
my-service.service can get stuck for various reasons and time out, in
which case it is restarted. Currently, when it fails the first time, the
target fails, even though my-service is restarted.
The behavior we're looking for is that until my-service is not restarted
anymore, the target stays pending waiting for my-service.service to
start successfully or fail without being restarted anymore.
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Yu Watanabe
Luca Boccassi
Christian Hesse
Lily Foster
Frantisek Sumsal
Weblate
Richard Phibel
Daniel P. Berrangé