| 1 | -*- mode: org; coding: utf-8; -*- |
| 2 | |
| 3 | #+TITLE: Hacking GNU Guix and Its Incredible Distro |
| 4 | |
| 5 | Copyright © 2012, 2013 Ludovic Courtès <[email protected]> |
| 6 | Copyright © 2013 Nikita Karetnikov <[email protected]> |
| 7 | |
| 8 | Copying and distribution of this file, with or without modification, |
| 9 | are permitted in any medium without royalty provided the copyright |
| 10 | notice and this notice are preserved. |
| 11 | |
| 12 | |
| 13 | * Building from Git |
| 14 | |
| 15 | First, make sure that Autoconf (>= 2.69), Automake, and pkg-config are |
| 16 | installed. Run ‘./bootstrap’ that, among other things, invokes ‘git submodule |
| 17 | update’, or you might get the following error |
| 18 | |
| 19 | make: *** No rule to make target `nix/libstore/schema.sql', needed by |
| 20 | `nix/libstore/schema.sql.hh' |
| 21 | |
| 22 | Then, as always, run ‘./configure’. If you get an error like this one |
| 23 | |
| 24 | ./configure: line 6755: `PKG_CHECK_MODULES(GUILE, guile-2.0 >= 2.0.5)' |
| 25 | |
| 26 | it probably means that Autoconf couldn’t find ‘pkg.m4’, which is provided by |
| 27 | pkg-config. Make sure that ‘pkg.m4’ is available. For instance, if you |
| 28 | installed Automake in ‘/usr/local’, it wouldn’t look for ‘.m4’ files in |
| 29 | ‘/usr/share’. So you have to invoke the following command in that case |
| 30 | |
| 31 | $ export ACLOCAL_PATH=/usr/share/aclocal |
| 32 | |
| 33 | See “info '(automake) Macro Search Path'” for more information. |
| 34 | |
| 35 | After that you should proceed with ‘make’. You might also get this error |
| 36 | |
| 37 | /bin/bash: dot: command not found |
| 38 | make[2]: *** [doc/images/bootstrap-graph.png] Error 127 |
| 39 | |
| 40 | This one is easy to handle; just install Graphviz. It is not listed as a |
| 41 | requirement because the resulting images should come with a tarball. |
| 42 | |
| 43 | Finally, you have to invoke ‘make check’ to run tests. If anything fails, |
| 44 | take a look at “info '(guix) Installation'” or send a message to |
| 45 | <[email protected]>. |
| 46 | |
| 47 | * Running Guix before it is installed |
| 48 | |
| 49 | Command-line tools can be used even if you have not run "make install". |
| 50 | To do that, prefix each command with ‘./pre-inst-env’, as in: |
| 51 | |
| 52 | ./pre-inst-env guix build --help |
| 53 | |
| 54 | Similarly, for a Guile session using the Guix modules: |
| 55 | |
| 56 | ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))' |
| 57 | |
| 58 | The ‘pre-inst-env’ script sets up all the environment variables |
| 59 | necessary to support this. |
| 60 | |
| 61 | * The Perfect Setup |
| 62 | |
| 63 | The Perfect Setup to hack on Guix is basically the perfect setup used |
| 64 | for Guile hacking (info "(guile) Using Guile in Emacs"). First, you |
| 65 | need more than an editor, you need [[http://www.gnu.org/software/emacs][Emacs]], empowered by the wonderful |
| 66 | [[http://nongnu.org/geiser/][Geiser]]. |
| 67 | |
| 68 | Geiser allows for interactive and incremental development from within |
| 69 | Emacs: code compilation and evaluation from within buffers, access to |
| 70 | on-line documentation (docstrings), context-sensitive completion, M-. to |
| 71 | jump to an object definition, a REPL to try out your code, and more. |
| 72 | |
| 73 | To actually edit the code, Emacs already has a neat Scheme mode. But in |
| 74 | addition to that, you must not miss [[http://www.emacswiki.org/emacs/ParEdit][Paredit]]. It provides facilities to |
| 75 | directly operate on the syntax tree, such as raising an s-expression or |
| 76 | wrapping it, swallowing or rejecting the following s-expression, etc. |
| 77 | |
| 78 | * Adding new packages |
| 79 | |
| 80 | Package recipes in Guix look like this: |
| 81 | |
| 82 | #+BEGIN_SRC scheme |
| 83 | (package |
| 84 | (name "nettle") |
| 85 | (version "2.5") |
| 86 | (source |
| 87 | (origin |
| 88 | (method url-fetch) |
| 89 | (uri (string-append "mirror://gnu/nettle/nettle-" |
| 90 | version ".tar.gz")) |
| 91 | (sha256 |
| 92 | (base32 |
| 93 | "0wicr7amx01l03rm0pzgr1qvw3f9blaw17vjsy1301dh13ll58aa")))) |
| 94 | (build-system gnu-build-system) |
| 95 | (inputs `(("m4" ,m4))) |
| 96 | (propagated-inputs `(("gmp" ,gmp))) |
| 97 | (home-page |
| 98 | "http://www.lysator.liu.se/~nisse/nettle/") |
| 99 | (synopsis "GNU Nettle, a cryptographic library") |
| 100 | (description |
| 101 | "Nettle is a cryptographic library...") |
| 102 | (license gpl2+)) |
| 103 | #+END_SRC |
| 104 | |
| 105 | Such a recipe can be written by hand, and then tested by running |
| 106 | ‘./pre-inst-env guix build nettle’. |
| 107 | |
| 108 | When writing the recipe, the base32-encoded SHA256 hash of the source |
| 109 | code tarball, which can be seen in the example above, can be obtained by |
| 110 | running: |
| 111 | |
| 112 | guix download http://ftp.gnu.org/gnu/nettle/nettle-2.5.tar.gz |
| 113 | |
| 114 | Alternatively, it is possible to semi-automatically import recipes from |
| 115 | the [[http://nixos.org/nixpkgs/][Nixpkgs]] software distribution using this command: |
| 116 | |
| 117 | guix import /path/to/nixpkgs/checkout nettle |
| 118 | |
| 119 | The command automatically fetches and converts to Guix the “Nix |
| 120 | expression” of Nettle. |
| 121 | |
| 122 | * Submitting Patches |
| 123 | |
| 124 | Development is done using the Git distributed version control system. Thus, |
| 125 | access to the repository is not strictly necessary. We welcome contributions |
| 126 | in the form of patches as produced by ‘git format-patch’ sent to |
| 127 | [email protected]. Please write commit logs in the [[http://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs][GNU ChangeLog format]]. |
| 128 | |
| 129 | As you become a regular contributor, you may find it convenient to have write |
| 130 | access to the repository (see below.) |
| 131 | |
| 132 | * Commit Access |
| 133 | |
| 134 | For frequent contributors, having write access to the repository is |
| 135 | convenient. When you deem it necessary, feel free to ask for it on the |
| 136 | mailing list. When you get commit access, please make sure to follow the |
| 137 | policy below (discussions of the policy can take place on [email protected].) |
| 138 | |
| 139 | Non-trivial patches should always be posted to [email protected] (trivial |
| 140 | patches include fixing typos, etc.) |
| 141 | |
| 142 | For patches that just add a new package, and a simple one, it’s OK to commit, |
| 143 | if you’re confident (which means you successfully built it in a chroot setup, |
| 144 | and have done a reasonable copyright and license auditing.) Likewise for |
| 145 | package upgrades. We have a mailing list for commit notifications |
| 146 | ([email protected]), so people can notice. Before pushing your changes, |
| 147 | make sure to run ‘git pull --rebase’. |
| 148 | |
| 149 | For anything else, please post to [email protected] and leave time for a |
| 150 | review, without committing anything. If you didn’t receive any reply |
| 151 | after two weeks, and if you’re confident, it’s OK to commit. |
| 152 | |
| 153 | That last part is subject to being adjusted, allowing individuals to commit |
| 154 | directly on non-controversial changes on parts they’re familiar with. |