Since, at least the old framework, checks for the presence of the file
at the end and marks the whole test as skipped if it exists.
Resolves: systemd/systemd-centos-ci#728
tcp reset / icmp port-unreachable are markedly different conditions than
packet loss. It doesn't make much sense to retry in this case. It's
actually not clear if there is any benefit at all retrying tcp
connections, which were presumably already retried as necessary by the
tcp stack.
To make it work without sd-event.
Prompted by recent chat:
> Hey all!
> reading man libudev, it says to use sd-device instead now. I've read that
> APIs header file and it seems it no longer has an equivalent to libudev's
> udev_monitor_get_fd, which AFAICT means I have to use sd-event to watch
> for events I'm interested in. I know I can "embed" sd-event in other event
> loops I might already have, but that seems overkill when I'm only interested
> in this one type of event and don't need sd-event for anything else.
Previously, the main process of systemd-udevd manages worker process
with their sd_device_monitor object to save the destination address.
Let's save only destination address, and drop worker's sd_device_monitor
object.
Previously, device_monitor_enable_receiving() does
- update filter,
- bind socket.
But, binding socket can be done in when the socket is opened.
Let's remove device_monitor_enable_receiving() and bind the socket in
device_monitor_new_full().
Arch and Tumbleweed do not do EOLs but are still stable, so clarify the paragraph.
Also break the entry in paragraphs, to make it more readable when rendered.
The point was made on https://lists.debian.org/debian-ctte/2024/08/msg00005.html
that 'pre-release sounds' like an RC candidate, ie, something that will change
very slightly in the released version. But this is not necessarily the case
for example at the beginnig of a Fedora Rawhide or Debian Testing release cycle,
so change it to a more generic 'development'
Follow-up for 7102dc52e6
This is for experimental builds of the OS made to test some specific WIP
feature.
For example, let's say the distro in question is Asahi Linux and Apple
just released the M3 SoC. The Asahi developers will start porting to the
M3, and will quickly generate builds of Asahi Linux that can technically
boot but aren't ready for any kind of daily use. These images are marked
as experimental, and can be shared among the developers. If a user
somehow stumbles upon one of these images and tries to install it,
they'll be warned that they're about to install an experimental Apple M3
port of Asahi Linux. Eventually, once the Asahi developers think that
their M3 port is ready for a wider audience, they can merge it into the
mainline Asahi repos, where it will be distributed through the usual
nightly CI builds (where RELEASE_TYPE=pre-release; M3 support is no
longer experimental).
This will allow GUIs to customize their behavior a little based on the
type of release.
For example, an OS installer may display a warning/disclaimer if
RELEASE_TYPE=prerelease. The software updates app might be a bit more
insistent about upgrading to the next major release if
RELEASE_TYPE=stable than if RELEASE_TYPE=lts
Fixes the following error:
===
In file included from ../src/basic/macro.h:13,
from ../src/basic/dirent-util.h:8,
from ../src/journal/journalctl-misc.c:3:
../src/journal/journalctl-misc.c: In function 'show_log_ids':
../src/journal/journalctl-misc.c:107:22: error: comparison is always true due to limited range of data type [-Werror=type-limits]
107 | assert(n_ids < INT64_MAX);
| ^
../src/fundamental/macro-fundamental.h:70:44: note: in definition of macro '_unlikely_'
70 | #define _unlikely_(x) (__builtin_expect(!!(x), 0))
| ^
../src/basic/macro.h:165:22: note: in expansion of macro 'assert_message_se'
165 | #define assert(expr) assert_message_se(expr, #expr)
| ^~~~~~~~~~~~~~~~~
../src/journal/journalctl-misc.c:107:9: note: in expansion of macro 'assert'
107 | assert(n_ids < INT64_MAX);
| ^~~~~~
cc1: all warnings being treated as errors
===
Follow-up for 0a8c1f6212.
The --list-invocations command is similar to --list-boots, but shows
invocation IDs of specified unit. This should be useful when showing
a specific invocation of a unit.
The --invocation option is similar to --boot, but takes a invocation ID
or an offset. The -I option is equivalent to --invocation=0.
The struct itself is generic, and can be used for other ID.
Let's rename it to more generic one.
No functional change, just refactoring and preparation for later
commits.
