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
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).
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.
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.
## 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.
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.
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).
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.