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