1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
HACKING ON SYSTEMD
We welcome all contributions to systemd. If you notice a bug or a missing
feature, please feel invited to fix it, and submit your work as a github Pull
Request (PR):
https://github.com/systemd/systemd/pull/new
Please make sure to follow our Coding Style when submitting patches. See
CODING_STYLE for details. Also have a look at our Contribution Guidelines:
https://github.com/systemd/systemd/blob/master/.github/CONTRIBUTING.md
Please always test your work before submitting a PR. For many of the components
of systemd testing is straight-forward as you can simply compile systemd and
run the relevant tool from the build directory.
For some components (most importantly, systemd/PID1 itself) this is not
possible, however. In order to simplify testing for cases like this we provide
a set of "mkosi" build files directly in the source tree. "mkosi" is a tool for
building clean OS images from an upstream distribution in combination with a
fresh build of the project in the local working directory. To make use of this,
please acquire "mkosi" from https://github.com/systemd/mkosi first, unless your
distribution has packaged it already and you can get it from there. After the
tool is installed it is sufficient to type "mkosi" in the systemd project
directory to generate a disk image "image.raw" you can boot either in
systemd-nspawn or in an UEFI-capable VM:
# systemd-nspawn -bi image.raw
or:
# qemu-kvm -m 512 -smp 2 -bios /usr/share/edk2/ovmf/OVMF_CODE.fd -hda image.raw
Every time you rerun the "mkosi" command a fresh image is built, incorporating
all current changes you made to the project tree.
Alternatively, you may install the systemd version from your git check-out
directly on top of your host system's directory tree. This mostly works fine,
but of course you should know what you are doing as you might make your system
unbootable in case of a bug in your changes. Also, you might step into your
package manager's territory with this. Be careful!
And never forget: most distributions provide very simple and convenient ways to
install all development packages necessary to build systemd. For example, on
Fedora the following command line should be sufficient to install all of
systemd's build dependencies:
# dnf builddep systemd
Putting this all together, here's a series of commands for preparing a patch
for systemd (this example is for Fedora):
$ sudo dnf builddep systemd # install build dependencies
$ sudo dnf install mkosi # install tool to quickly build images
$ git clone https://github.com/systemd/systemd.git
$ cd systemd
$ vim src/core/main.c # or wherever you'd like to make your changes
$ ./autogen.sh c # configure the source tree
$ make -j `nproc` # build it locally, see if everything compiles fine
$ make -j `nproc` check # run some simple regression tests
$ sudo mkosi # build a test image
$ sudo systemd-nspawn -bi image.raw # boot up the test image
$ git add -p # interactively put together your patch
$ git commit # commit it
$ ...
And after that, please submit your branch as PR to systemd via github.
Happy hacking!
|
GitWeb
