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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
History (c068650fcf,
941a12dcba) has proven
that we're not good at keeping socket and service states
in sync. Instead, let's query the high-level unit_active_state()
first, and only hardcode the two special auto-restart
service states.
Additionally, allow returning to listening state on SERVICE_CLEANING.
Let's use the newly added credentials to only enable autologin for
/dev/console (systemd-nspawn) and /dev/hvc0 (qemu) instead of enabling
autologin for every tty.
This allows for "per-instance" credentials for units. The use case
is best explained with an example. Currently all our getty units
have the following stanzas in their unit file:
"""
ImportCredential=agetty.*
ImportCredential=login.*
"""
This means that setting agetty.autologin=root as a system credential
will make every instance of our all our getty units autologin as the
root user. This prevents us from doing autologin on /dev/hvc0 while
still requiring manual login on all other ttys.
To solve the issue, we introduce support for renaming credentials with
ImportCredential=. This will allow us to add the following to e.g.
serial-getty@.service:
"""
ImportCredential=tty.serial.%I.agetty.*:agetty.
ImportCredential=tty.serial.%I.login.*:login.
"""
which for serial-getty@hvc0.service will make the service manager read
all credentials of the form "tty.serial.hvc0.agetty.xxx" and pass them
to the service in the form "agetty.xxx" (same goes for login). We can
apply the same to each of the getty units to allow setting agetty and
login credentials for individual ttys instead of globally.
Credentials are written to a temporary file and renamed to the
destination with renameat() which will replace existing files so
EEXIST should not happen so drop the handling for EEXIST.
All messages logged from exec_spawn() are attributed to the unit
and as such we should set the log level to the unit's max log level
for the duration of the function.
With ambient capabilities being dropped at the start of process managers
(both system and user) as well as systemd-executor it isn't necessary
to drop them here. Moreover, at this point also the inheritable set can
be preserved. This makes it possible to assign a user session manager
inheritable capabilities which combined with file capabilites (ei sets)
of service executables enable running user services with capabilities
but only when started by the manager.
This reverts commit 943800f4e7.
