system/systemd
system/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd synced 2024-07-21 10:17:21 +00:00
Code Issues Actions 7 Packages Projects Releases Wiki Activity

docs: update branch names

Browse source 
Also use --atomic when pushing multiple items with git;
adjust some external URLs.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2021-12-23 21:25:31 +01:00
parent 3c7af1af7d
commit df1f621bda
6 changed files with 19 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
docs/CODE_QUALITY.md
View file

@ -51,8 +51,8 @@ available functionality:
9. There are multiple CI systems in use that run on every github PR submission.
10. [Coverity](https://scan.coverity.com/) is analyzing systemd master in
regular intervals. The reports are available
10. [Coverity](https://scan.coverity.com/) is analyzing systemd `main` branch
in regular intervals. The reports are available
[online](https://scan.coverity.com/projects/systemd).
11. [oss-fuzz](https://oss-fuzz.com/) is continuously fuzzing the
@ -65,7 +65,7 @@ available functionality:
13. When building systemd from a git checkout the build scripts will
automatically enable a git commit hook that ensures whitespace cleanliness.
14. [LGTM](https://lgtm.com/) analyzes every commit pushed to master. The list
14. [LGTM](https://lgtm.com/) analyzes every commit pushed to `main`. The list
of active alerts can be found
[here](https://lgtm.com/projects/g/systemd/systemd/alerts/?mode=list).
@ -75,7 +75,7 @@ available functionality:
for more information.
16. Fossies provides [source code misspelling reports](https://fossies.org/features.html#codespell).
The systemd report can be found [here](https://fossies.org/linux/test/systemd-master.tar.gz/codespell.html).
The systemd report can be found [here](https://fossies.org/linux/misc/systemd/codespell.html).
Access to Coverity and oss-fuzz reports is limited. Please reach out to the
maintainers if you need access.

22
docs/CONTAINER_INTERFACE.md
View file

@ -37,18 +37,18 @@ manager, please consider supporting the following interfaces.
in this context.)
3. Pre-mount `/dev/` as (container private) `tmpfs` for the container and bind
mount some suitable TTY to `/dev/console`. If this is a pty, make sure to not
close the controlling pty master during systemd's lifetime. PID1 will close
mount some suitable TTY to `/dev/console`. If this is a pty, make sure to
not close the controlling pty during systemd's lifetime. PID1 will close
ttys, to avoid being killed by SAK. It only opens ttys for the time it
actually needs to print something. Also, make sure to create device
nodes for `/dev/null`, `/dev/zero`, `/dev/full`, `/dev/random`,
`/dev/urandom`, `/dev/tty`, `/dev/ptmx` in `/dev/`. It is not necessary to
create `/dev/fd` or `/dev/stdout`, as systemd will do that on its own. Make
sure to set up a `BPF_PROG_TYPE_CGROUP_DEVICE` BPF program — on cgroupv2 —
or the `devices` cgroup controller — on cgroupv1 — so that no other devices
but these may be created in the container. Note that many systemd services
use `PrivateDevices=`, which means that systemd will set up a private
`/dev/` for them for which it needs to be able to create these device nodes.
actually needs to print something. Also, make sure to create device nodes
for `/dev/null`, `/dev/zero`, `/dev/full`, `/dev/random`, `/dev/urandom`,
`/dev/tty`, `/dev/ptmx` in `/dev/`. It is not necessary to create `/dev/fd`
or `/dev/stdout`, as systemd will do that on its own. Make sure to set up a
`BPF_PROG_TYPE_CGROUP_DEVICE` BPF program — on cgroupv2 — or the `devices`
cgroup controller — on cgroupv1 — so that no other devices but these may be
created in the container. Note that many systemd services use
`PrivateDevices=`, which means that systemd will set up a private `/dev/`
for them for which it needs to be able to create these device nodes.
Dropping `CAP_MKNOD` for containers is hence generally not advisable, but
see below.

2
docs/CONTRIBUTING.md
View file

@ -31,7 +31,7 @@ See [reporting of security vulnerabilities](SECURITY.md).
## Posting Pull Requests
* Make sure to post PRs only relative to a very recent git master.
* Make sure to post PRs only relative to a very recent git tip.
* Follow our [Coding Style](CODING_STYLE.md) when contributing code. This is a requirement for all code we merge.
* Please make sure to test your change before submitting the PR. See the [Hacking guide](HACKING.md) for details on how to do this.
* Make sure to run the test suite locally, before posting your PR. We use a CI system, meaning we don't even look at your PR, if the build and tests don't pass.

2
docs/JOURNAL_NATIVE_PROTOCOL.md
View file

@ -185,7 +185,7 @@ took place for the current program.
If you are looking for alternative implementations of this protocol (besides
systemd's own in `sd_journal_print()`), consider
[GLib's](https://gitlab.gnome.org/GNOME/glib/-/blob/master/glib/gmessages.c) or
[GLib's](https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gmessages.c) or
[`dbus-broker`'s](https://github.com/bus1/dbus-broker/blob/main/src/util/log.c).
And that's already all there is to it.

2
docs/RELEASE.md
View file

@ -21,4 +21,4 @@ SPDX-License-Identifier: LGPL-2.1-or-later
12. "Draft" a new release on github (https://github.com/systemd/systemd/releases/new), mark "This is a pre-release" if appropriate.
13. Check that announcement to systemd-devel, with a copy&paste from NEWS, was sent. This should happen automatically.
14. Update IRC topic (`/msg chanserv TOPIC #systemd Version NNN released`)
15. [FINAL] Push commits to stable, create an empty -stable branch: `git push systemd-stable origin/master:master origin/master:refs/heads/${version}-stable`, and change the default branch to latest release (https://github.com/systemd/systemd-stable/settings/branches).
15. [FINAL] Push commits to stable, create an empty -stable branch: `git push systemd-stable --atomic origin/main:main origin/main:refs/heads/${version}-stable`, and change the default branch to latest release (https://github.com/systemd/systemd-stable/settings/branches).

2
docs/UIDS-GIDS.md
View file

@ -81,7 +81,7 @@ available during earliest boot, including in the initial RAM disk).
above). However, it does define some special group/GID assignments, which are
primarily used for `systemd-udevd`'s device management. The precise list of the
currently defined groups is found in this `sysusers.d` snippet:
[basic.conf](https://raw.githubusercontent.com/systemd/systemd/master/sysusers.d/basic.conf.in)
[basic.conf](https://raw.githubusercontent.com/systemd/systemd/main/sysusers.d/basic.conf.in)
It's strongly recommended that downstream distributions include these groups in
their default group databases.