Same as the old integration test suite, allow skipping tests that
require qemu.
ppc64el's vsock support doesn't appear to work, so we'll skip it,
as it is already done in the legacy framework.
The "AIPTEK Media Tablet Ultimate", detected as "Waltop International Corp. Batteryless Tablet",
is missing the resolution of the x-/y-axes.
Adding a new rule to 60-evdev.hwdb with the same values as another entry
"WALTOP International Corp. Batteryless Tablet" just with another matching string makes the
device usable.
Fixes#33362.
Follow-up for fc67a943d9
After the mentioned comment, we no longer need to record
the owner to restore the previous bus owner state.
Therefore, bus_name_owner is effectively unused. Kill it.
Historically, systemd-tmpfiles was designed to manager temporary
files, but nowadays it has become a generic tool for managing
all kinds of files. To avoid user confusion, let's remove "temporary"
from the tool's description.
As discussed in #33349
The setting of systemd clock is important and deserves an accurate description,
see for example:
https://discussion.fedoraproject.org/t/f38-to-f39-40-dnf-system-upgrade-can-fail-on-raspberry-pi/92403https://bugzilla.redhat.com/show_bug.cgi?id=2242759
The meat of the description was in systemd-timesyncd.service(8), but
actually it's systemd that sets the clock. In particular, systemd-timesyncd
doesn't know anything about /usr/lib/clock-epoch, and since systemd sets
the clock to the epoch when initializing, systemd-timesyncd would only
get to advance the clock to the epoch under special circumstances.
Also, systemd-timesyncd is an optional component, so we can't even rely
on its man page being installed in all circumstances. The description needs
to be moved to systemd(1).
The description is updated to describe the changes that were made in
previous commits.
Requested in https://github.com/systemd/systemd/pull/33214#discussion_r1630251308.
Also, reword error messages a bit. When /usr/lib/clock-epoch was introduced,
"build time" stopped being acurate. Just say "epoch" instead.
The same message ID is used in the manager and timesyncd. The event is
essentially equivalent for the user, and it seems reasonable that to search for
both at the same time.
The catalog entry is dropped. It provided almost no additional information above
the message. When the same message ID is now applied to messages from PID1 and
timesyncd, and the clock can be both advanced and rewound, it becomes very hard
to make the catalog entry provide something useful, because catalog entries don't
allow conditionalization.
We would attempt to take the built-in epoch twice. Since
advance_tstamp() is only called from one place, we don't need to do that.
Also, just pass usec_t instead of a pointer to stat buf.
Don't say we set the clock to "recorded timestamp" if we just set it
to the built-in epoch. Also, consistently say "advance" to make it clear
that we'll not attempt to rewind the clock here.
If we're updating on a system with an invalid clock, and we're installing
a newer system version with a higher update, adjust the clock. This
way the invariant that the clock is always later than
max(compile time, timestamp file, other timestamp file) is maintained.
Also, adjust the wording of messages. When /usr/lib/clock-epoch was
introduced, "build time" stopped being acurate. Just say "epoch" instead.
Previously systemd would not use /var/lib/systemd/timesync/clock. This means
that even if /var/ is mounted when systemd is started and the file is
available, we would potentially make one time jump and than another time jump.
From a user's POV, this doesn't seem useful at all.
Also, we would always let /usr/lib/clock-epoch take priority over the built-in
epoch. But there is no guarantee that this file is actually fresh. In
particular, a user may touch /usr/lib/clock-epoch to work around a broken clock
during installation (as recommended in [1]), and then this file will grow stale
over time.
So just load the three timestamps and use the highest one as the epoch.
[1] https://discussion.fedoraproject.org/t/f38-to-f39-40-dnf-system-upgrade-can-fail-on-raspberry-pi/92403
