diff options
author | Lennart Poettering <lennart@poettering.net> | 2016-07-21 04:15:54 +0200 |
---|---|---|
committer | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2016-07-20 22:15:54 -0400 |
commit | e4a3e122b2e820ba33cc858d3c8b1389f1c8f745 (patch) | |
tree | a1a1580f442fc9471fbcb7c43f1f85a7d37918a1 | |
parent | 176e51b7102d7bba875e58b85b59e2ed7e30bc89 (diff) | |
download | systemd-e4a3e122b2e820ba33cc858d3c8b1389f1c8f745.tar.gz systemd-e4a3e122b2e820ba33cc858d3c8b1389f1c8f745.tar.bz2 systemd-e4a3e122b2e820ba33cc858d3c8b1389f1c8f745.zip |
documentation: add a short document describing how to test your systemd build tree (#3763)
-rw-r--r-- | .github/CONTRIBUTING.md | 1 | ||||
-rw-r--r-- | HACKING | 68 | ||||
-rw-r--r-- | README.md | 2 |
3 files changed, 71 insertions, 0 deletions
diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 4857e94733..8a6db1f629 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -15,6 +15,7 @@ Following these guidelines makes it easier for us to process your issue, and ens * Make sure to post PRs only relative to a very recent git master. * Follow our [Coding Style](https://raw.githubusercontent.com/systemd/systemd/master/CODING_STYLE) when contributing code. This is a requirement for all code we merge. +* Please make sure to test your change before submitting the PR. See [HACKING](https://raw.githubusercontent.com/systemd/systemd/master/HACKING) for details how to do this. * Make sure to run "make check" 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 need to update the code in an existing PR, force-push into the same branch, overriding old commits with new versions. * After you have pushed a new version, try to remove the `reviewed/needs-rework` label. Also add a comment about the new version (no notification is sent just for the commits, so it's easy to miss the update without an explicit comment). diff --git a/HACKING b/HACKING new file mode 100644 index 0000000000..3ee1c7e340 --- /dev/null +++ b/HACKING @@ -0,0 +1,68 @@ +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): + + $ git clone https://github.com/systemd/systemd.git + $ cd systemd + $ vim src/core/main.c # or wherever you'd like to make your changes + $ dnf builddep systemd # install build dependencies + $ ./autogen.sh c # configure the source tree + $ make -j `nproc` # build it locally, see if everything compiles fine + $ 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! @@ -11,6 +11,8 @@ Information about build requirements are provided in the [README file](../master Consult our [NEWS file](../master/NEWS) for information about what's new in the most recent systemd versions. +Please see the [HACKING file](../master/HACKING) for information how to hack on systemd and test your modifications. + Please see our [Contribution Guidelines](../master/.github/CONTRIBUTING.md) for more information about filing GitHub Issues and posting GitHub Pull Requests. When preparing patches for systemd, please follow our [Coding Style Guidelines](../master/CODING_STYLE). |