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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When the spec was initially written, we didn't add good documentation of how to
display the notes, also because there was no good way to display the data
except manually extracting the section to a file and running 'jq' on that. But
the tools have improved, so let's show the users how easy it is to use this
data.
https://fedoraproject.org/wiki/Changes/RenameNobodyUser, 2018:
> Use "nobody:nobody" as the names for the kernel overflow UID:GID pair, and
> retire the old "nfsnobody" name and the old "nobody:nobody" pair with 99:99
> numbers.
When running unprivileged, checking /proc/1/root doesn't work because
it requires privileges. Instead, let's add an environment variable so
the process that chroot's can tell (systemd) subprocesses whether
they're running in a chroot or not.
- Add the required options to make the package managers non interactive
- Use apt-get instead of apt
- Remove --reinstall from apt-get command so we only install newer packages
- Add --needed to pacman command so we only install newer packages
Currently inhibitors are bypassed unless an explicit request is made to
check for them, or even in that case when the requestor is root or the
same uid as the holder of the lock.
But in many cases this makes it impractical to rely on inhibitor locks.
For example, in Debian there are several convoluted and archaic
workarounds that divert systemctl/reboot to some hacky custom scripts
to try and enforce blocking accidental reboots, when it's not expected
that the requestor will remember to specify the command line option
to enable checking for active inhibitor locks.
Also in many cases one wants to ensure that locks taken by a user are
respected by actions initiated by that same user.
Change logind so that inhibitors checks are not skipped in these
cases, and systemctl so that locks are checked in order to show a
friendly error message rather than "permission denied".
Add new block-weak and delay-weak modes that keep the previous
behaviour unchanged.
Let's document in detail how to build the integration test image and run
the integration tests without building systemd. To streamline the process,
we stop automatically using binaries from build/ when invoking mkosi directly
and don't automatically use a tools tree anymore if systemd on the host is too
old. Instead, we document these options in HACKING.md and change the mkosi meson
target to automatically use the current build directory as an extra binary search
path for mkosi.
Makes it possible to specify URLs to a changelog and an appstream
catalog XML in the sysupdate.d/*.conf files. This will be passed along
to the clients of systemd-sysupdated, which can then present this data.
In https://github.com/systemd/mkosi/pull/2847, the '@' specifier is
removed, CLI arguments take priority over configuration files again
and the "main" image is defined at the top level instead of in
mkosi.images/. Additionally, not every setting from the top level
configuration is inherited by the images in mkosi.images/ anymore,
only settings which make sense to be inherited are inherited.
This commit gets rid of all the usages of '@', moves the "main" image
configuration from mkosi.images/system to the top level and gets rid
of various hacks we had in place to deal with quirks of the old
configuration parsing logic.
We also remove usages of Images= and --append as these options are
removed by the mentioned PR.
Otherwise fixfiles will try to relabel it which could potentially
lead to disaster. We also change the recommendation in HACKING.md
to set the default so that TEST-06-SELINUX can override it.
Let's mention the new way to install the latest changes without
rebuilding the image. Let's also remove the duplicate info about
distribution packages that is already mentioned in its own section.
In some recent PRs (e.g. #32628) I started to systematically name return
parameters that shall only be initialized on failure (because they carry
additional error meta information, such as the line/column number of
parse failures or so). Let's make this official in the coding style.
Unfortunately, git submodules break in all sorts of ways:
- Various github workflows (dependabot, github pages) try to do a shallow
clone of git submodules which does not work at all when the git repository
is hosted on pagure (https://pagure.io/pagure/issue/5453,
https://github.com/dependabot/dependabot-core/issues/9391).
- If the git forge hosting the git repository uses SHA256, then it breaks our
usage of it as a submodule as SHA256 repositories cannot be used as submodules
in SHA1 repositories (src.opensuse.org moved to SHA256 which broke our usage of
opensuse's systemd spec as a submodule).
- git submodules completely break usage of git worktrees.
- ...
Let's avoid all these issues by just doing our own home grown implementation of
git submodules. We lose the automatic dependabot updates this way but since dependabot
fails to run more often that not with submodules we don't really lose anything.
Get them to point to the rendered version, instead of
letting Github thinks they are absolute links in the
repository. The rendered version is much more user-friendly.
Like much English text, the systemd documentation uses "may not" in the
sense of both "will possibly not" and "is forbidden to". In many cases
this is OK because the context makes it clear, but in others I felt it
was possible to read the "is forbidden to" sense by mistake: in
particular, I tripped over "the target file may not exist" in
systemd.unit(5) before realizing the correct interpretation.
Use "might not" or "may choose not to" in these cases to make it clear
which sense we mean.
Tool to parse it and to use it for Debian packaging available at
https://github.com/systemd/package-notes
Add 3 levels of priority like Debian does, but using terminology
from RPM as it seems more apt.
We will very likely never use 'required', as we use this functionality
for optional features, but it is worth having it in the spec nonetheless
as we want it to be generalized.
This commit fixes two instances of a miscount. As the number is not important in either case, and seemingly subject to changes, it was removed entirely.
Another sentence was reworded to improve readability.
Some people are just sad, sad lost souls who don't like even the tiniest
ray of color in their life. Let's add an env var knob for allowing them
to turn the background tinting off, to drive the last bit of color from
their life so that they can stay in their grey grey life.
