Given that ANSI_COLOR= is mostly about branding it probably makes sense
to use RGB rather than paletted colors for them, so that the colors
match the project design as close as possible. Hence, provide a 25bit
RGB example for ANSI_COLOR, and update the overall example to something
newer.
Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1823099
It's pretty, and it highlights that the pw prompt is kinda special and
needs user input.
We suppress the emoji entirel if there's no emoji support (i.e. this
means we suppress the ASCII replacement), since it carries no additional
information, it is just decoration to highlight a line.
We provide a way via the '-' symbol to ignore errors when nonexistent
executable files are passed to Exec* parameters & so on. In such a case,
the flag `EXEC_COMMAND_IGNORE_FAILURE` is set and we go on happily with
our life if that happens. However, `systemd-analyze verify` complained
about missing executables even in such a case. In such a case it is not
an error for this to happen so check if the flag is set before checking
if the file is accessible and executable.
Add some small tests to check this condition.
Closes#15218.
This commit introduces new meson build option "kernel-install" to prevent kernel-install from building if the user
sets the added option as "false".
Signed-off-by: Jakov Smolic <jakov.smolic@sartura.hr>
Signed-off-by: Luka Perkov <luka.perkov@sartura.hr>
An stdio FILE* stream usually refers to something with a file
descriptor, but that's just "usually". It doesn't have to, when taking
fmemopen() and similar into account. Most of our calls to fileno()
assumed the call couldn't fail. In most cases this was correct, but in
some cases where we didn't know whether we work on files or memory we'd
use the returned fd as if it was unconditionally valid while it wasn't,
and passed it to a multitude of kernel syscalls. Let's fix that, and do
something reasonably smart when encountering this case.
(Running test-fileio with this patch applied will remove tons of ioctl()
calls on -1).
The wiki was primarily describing the D-Bus API, but it also had a large
introduction to the daemon functionality. I moved that latter part into
the page that describes the daemon, and the API description into the new
page.
This is mostly a straighforward import. Apart from some required formatting
changes, I removed obvious repetitions, and made tiny grammar and typo fixes
where I noticed them. The goal is not to have a perfect text immediately.
<interfacename>org.foo.bar</interface> is used for interface names,
<function>function()</function> for methods, and <function>signal</function>
(no parentheses) for signal names. In D-Bus, signals are similar to methods,
and docbook doesn't have a nice tag for them.
