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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
All wiki pages that contain a deprecation banner
pointing to systemd.io or manpages are updated to
point to their replacements directly.
Helpful command for identification of available links:
git grep freedesktop.org/wiki | \
sed "s#.*\(https://www.freedesktop.org/wiki[^ $<'\\\")]*\)\(.*\)#\\1#" | \
sort | uniq
* Avoid traling slash as most links are defined without.
* Always use https:// protocol and www. subdomain
Allows for easier tree-wide linkvalidation
for our migration to systemd.io.
3970 e = object_path_startswith(path, prefix);
(gdb) p path
$1 = 0x55c5a166f768 "/org/freedesktop/portable1/image"
(gdb) p prefix
$2 = 0x55c59ffc2928 "/org/freedesktop/portable1/image"
(gdb) p e
$1 = 0x5581a1675788 ""
This can be a bit confusing in certain cases, so add a comment and a
test to make the behaviour clearer and explicit.
Before 9e82a74cb0, we had a check like the
following:
if [[ -d /efi/loader/entries ]] || [[ -d /efi/$MACHINE_ID ]]; then
ENTRY_DIR_ABS="/efi/$MACHINE_ID/$KERNEL_VERSION"
elif [[ -d /boot/loader/entries ]] || [[ -d /boot/$MACHINE_ID ]]; then
ENTRY_DIR_ABS="/boot/$MACHINE_ID/$KERNEL_VERSION"
elif [[ -d /boot/efi/loader/entries ]] || [[ -d /boot/efi/$MACHINE_ID ]]; then
ENTRY_DIR_ABS="/boot/efi/$MACHINE_ID/$KERNEL_VERSION"
…
In stock Fedora 34-, /efi isn't used, but grub creates /boot/loader/entries and
installs kernels and initrds directly in /boot. Thus the second arm of the
check wins, and we end up with BOOT_ROOT=/boot.
After 9e82a74cb0, we iterate over the inner
directory first and over the second directory later:
[ -d /efi/<machine-id> ]
[ -d /boot/efi/<machine-id> ]
[ -d /boot/<machine-id> ]
[ -d /efi/Default ]
[ -d /boot/efi/Default ]
[ -d /boot/Default ]
[ -d /efi/loader/entries ]
[ -d /boot/efi/loader/entries ]
[ -d /boot/loader/entries ]
This was partially reverted by 447a822f8e which
removed Default from the list, and a5307e173b,
which moved checks for /boot up, so we ended up with:
[ -d /efi/<machine-id> ]
[ -d /boot/<machine-id> ]
[ -d /boot/efi/<machine-id> ]
[ -d /efi/loader/entries ]
[ -d /boot/loader/entries ]
[ -d /boot/efi/loader/entries ]
6637cf9db6 added autodetection of an entry
token, so we end up checking the following suffixes:
<machine-id>, $IMAGE_ID, $ID, Default
But the important unchanged characteristic is that we iterate over the suffix
first. Sadly this breaks Fedora, because we find /boot/efi/<machine-id> before
we could find /boot/loader/entries. It seems that every possible aspect of
behaviour matters for somebody, so we need to keep the original order of
detection.
With the patch:
[ -d /efi/<machine-id> ]
...
[ -d /efi/loader/entries ]
[ -d /boot/<machine-id> ]
...
[ -d /boot/loader/entries ]
[ -d /boot/efi/<machine-id> ]
...
[ -d /boot/efi/loader/entries ]
Note that we need to check for "loader/entries" too, even though it is not
an entry-token candidate, so that we get the same detection priority as
before.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2071034.
I took inspiration from pid1:
bus_unit_find()
→ find_unit()
→ manager_load_unit_from_dbus_path()
→ unit_name_from_dbus_path()
→ !startswith(path, "/org/freedesktop/systemd1/unit/")
→ return -EINVAL
←
←
←
← if (r < 0) return 0
← 0
←
i.e. we return 0 when queried for "/org/freedesktop/systemd1/unit".
Fixes#23445.
If $BOOT_ROOT is specified, but entry-token not, we'd skip the detection
altogether, effectively defaulting to entry-token=machine-id.
The case where $BOOT_ROOT was not specied, but entry-token was configured
was handled correctly.
This patch makes the handling of both symmetrical, i.e. will only set what
wasn't configured.
No changes to behaviour, but let's print everything out as we discover it.
The docs say that BOOT_ROOT can be specified by the environment. I have
it locally in /etc/kernel/install.conf, and then the override doesn't work.
It'd be nice to handle such cases more reliably.
Fixes#23433
matches is plumbed through until it finally gets used in unit_match()
which can deal with NULL matches so the assert() is unnecessary and
can be removed.
The two call sites of extract_image_and_extensions() also don't
assert() on matches either.
* Use brand-green for demo log messages on the startpage
instead of the default `green` color defined by the browser vendor
(after all, the brand green color is intended to reflect the
boot status output)
* Add a matching blue intro color (mixed using HSL from brand-green
by 55deg hue rotation and 4% lightness)
* Use a defined font-size
(to avoid blurry rendering at 13.33333px, due to font-size: smaller)
* Add possibility for the browser to show horizontal scrollbar
(avoid overflow in mobile view)
Respect the user agent property `prefers-color-scheme` by
rendering the documentation in dark mode, if requested.
Reorganise CSS to store the color palette into CSS variables
and reference these from another set of CSS variables that
are dynamically switched based on the prefers-color-scheme
media query.
Light mode variables stay they same as before,
but to ease color mixing, the current RGB values
have been transformed to HSL (using chrome devtools).
The current body background is now --sd-gray-extralight,
the current body color is now --sd-gray-extradark.
Other gray-variations, needed for dark-mode constrasts
are derived from these colors using HSL lightness shifting.
The systemd brand black color is used as dark mode background
and a matching extralight gray font color has been selected.
The link font-weight is reduced to 400 in dark mode,
as the green color on dark ground becomes to overwhelming
with a bold font.
The systemd logo color is dynamically swapped by using
the special fill value `currentColor` for dark/light-mode
depending parts – as per specification on brand.systemd.io
* Update to rougify 3.26.1 styling
* Adapt background overwrite by removing default background color
and only adding explicit overwrites for syntax error
(error stylings appear for example in json-excerpts –
see HACKING.md – and are therefore hidden by our css)
* Provides a nice introduction to the intro paragraph
* Ensures text of subpages start at the same position as the intro text
on the homepage
=> less visual "jumps" while navigating
The theme color is used on android to style the chrome
browser-ui with a color that suits the webpage.
Use the dark brand color instead of a random default blue color
in order to fit to the rest of the color scheme.
h1 font weight is defined to be 100 but no font-face
definition for weight 100 is included.
The browser will use the nearest available font-weight
instead. As that is 400, we do specify it explicitly now.
