* Submitting Patches:: Share your work.
* Tracking Bugs and Patches:: Using Debbugs.
* Commit Access:: Pushing to the official repository.
+* Updating the Guix Package:: Updating the Guix package definition.
@end menu
@node Building from Git
Then, run @command{./configure} as usual. Make sure to pass
@code{--localstatedir=@var{directory}} where @var{directory} is the
@code{localstatedir} value used by your current installation (@pxref{The
-Store}, for information about this). We recommend to use the value
-@code{/var}.
+Store}, for information about this), usually @file{/var}. Note that you
+will probably not run @command{make install} at the end (you don't have
+to) but it's still important to pass the right @code{localstatedir}.
Finally, you have to invoke @code{make check} to run tests
(@pxref{Running the Test Suite}). If anything
The first run takes a couple of minutes, but subsequent runs are faster.
+Or, when your configuration for your local Git repository doesn't match
+the default one, you can provide the reference for the @code{keyring}
+branch through the variable @code{GUIX_GIT_KEYRING}. The following
+example assumes that you have a Git remote called @samp{myremote}
+pointing to the official repository:
+
+@example
+make authenticate GUIX_GIT_KEYRING=myremote/keyring
+@end example
+
@quotation Note
You are advised to run @command{make authenticate} after every
@command{git pull} invocation. This ensures you keep receiving valid
``end-user'' hat and your ``motley'' costume.
To that end, all the command-line tools can be used even if you have not
-run @code{make install}. To do that, you first need to have an environment
-with all the dependencies available (@pxref{Building from Git}), and then
-simply prefix each command with
-@command{./pre-inst-env} (the @file{pre-inst-env} script lives in the
-top build tree of Guix; it is generated by @command{./configure}).
-An example@footnote{The @option{-E} flag to
-@command{sudo} guarantees that @code{GUILE_LOAD_PATH} is correctly set
-such that @command{guix-daemon} and the tools it uses can find the Guile
-modules they need.}:
+run @code{make install}. To do that, you first need to have an
+environment with all the dependencies available (@pxref{Building from
+Git}), and then simply prefix each command with @command{./pre-inst-env}
+(the @file{pre-inst-env} script lives in the top build tree of Guix; it
+is generated by running @command{./bootstrap} followed by
+@command{./configure}). As an example, here is how you would build the
+@code{hello} package as defined in your working tree (this assumes
+@command{guix-daemon} is already running on your system; it's OK if it's
+a different version):
@example
-$ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
$ ./pre-inst-env guix build hello
@end example
$1 = 361
@end example
+If you are hacking on the daemon and its supporting code or if
+@command{guix-daemon} is not already running on your system, you can
+launch it straight from the build tree@footnote{The @option{-E} flag to
+@command{sudo} guarantees that @code{GUILE_LOAD_PATH} is correctly set
+such that @command{guix-daemon} and the tools it uses can find the Guile
+modules they need.}:
+
+@example
+$ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
+@end example
+
The @command{pre-inst-env} script sets up all the environment variables
necessary to support this, including @env{PATH} and @env{GUILE_LOAD_PATH}.
(@pxref{Submitting Patches}). Well, if you need help, we will be happy to
help you too. Once the patch is committed in the Guix repository, the
new package automatically gets built on the supported platforms by
-@url{@value{SUBSTITUTE-SERVER}, our continuous integration system}.
+@url{@value{SUBSTITUTE-URL}, our continuous integration system}.
@cindex substituter
Users can obtain the new package definition simply by running
* Version Numbers:: When the name is not enough.
* Synopses and Descriptions:: Helping users find the right package.
* Snippets versus Phases:: Whether to use a snippet, or a build phase.
+* Emacs Packages:: Your Elisp fix.
* Python Modules:: A touch of British comedy.
* Perl Modules:: Little pearls.
* Java Packages:: Coffee break.
appropriately.
Synopses and descriptions are translated by volunteers
-@uref{https://translationproject.org/domain/guix-packages.html, at the
-Translation Project} so that as many users as possible can read them in
+@uref{https://translate.fedoraproject.org/projects/guix/packages, at
+Weblate} so that as many users as possible can read them in
their native language. User interfaces search them and display them in
the language specified by the current locale.
special comments like this (@pxref{xgettext Invocation,,, gettext, GNU
Gettext}):
-@example
+@lisp
;; TRANSLATORS: "X11 resize-and-rotate" should not be translated.
(description "ARandR is designed to provide a simple visual front end
for the X11 resize-and-rotate (RandR) extension. @dots{}")
-@end example
+@end lisp
@node Snippets versus Phases
@subsection Snippets versus Phases
using build phases. Refer to the @code{origin} record documentation for
more information (@pxref{origin Reference}).
+@node Emacs Packages
+@subsection Emacs Packages
+
+@cindex emacs, packaging
+@cindex elisp, packaging
+Emacs packages should preferably use the Emacs build system
+(@pxref{emacs-build-system}), for uniformity and the benefits provided
+by its build phases, such as the auto-generation of the autoloads file
+and the byte compilation of the sources. Because there is no
+standardized way to run a test suite for Emacs packages, tests are
+disabled by default. When a test suite is available, it should be
+enabled by setting the @code{#:tests?} argument to @code{#true}. By
+default, the command to run the test is @command{make check}, but any
+command can be specified via the @code{#:test-command} argument. The
+@code{#:test-command} argument expects a list containing a command and
+its arguments, to be invoked during the @code{check} phase.
+
+The Elisp dependencies of Emacs packages are typically provided as
+@code{propagated-inputs} when required at run time. As for other
+packages, build or test dependencies should be specified as
+@code{native-inputs}.
+
+Emacs packages sometimes depend on resources directories that should be
+installed along the Elisp files. The @code{#:include} argument can be
+used for that purpose, by specifying a list of regexps to match. The
+best practice when using the @code{#:include} argument is to extend
+rather than override its default value (accessible via the
+@code{%default-include} variable). As an example, a yasnippet extension
+package typically include a @file{snippets} directory, which could be
+copied to the installation directory using:
+
+@lisp
+#:include (cons "^snippets/" %default-include))
+@end lisp
+
+When encountering problems, it is wise to check for the presence of the
+@code{Package-Requires} extension header in the package main source
+file, and whether any dependencies and their versions listed therein are
+satisfied.
+
@node Python Modules
@subsection Python Modules
dashes should remain in place.
In the rust ecosystem it is common for multiple incompatible versions of a
-package to be used at any given time, so all packages should have a versioned
-suffix. If a package has passed version 1.0.0 then just the major version
-number is sufficient (e.g.@: @code{rust-clap-2}), otherwise the version suffix
-should contain both the major and minor version (e.g.@: @code{rust-rand-0.6}).
+package to be used at any given time, so all package definitions should have a
+versioned suffix. The versioned suffix is the left-most non-zero digit (and
+any leading zeros, of course). This follows the ``caret'' version scheme
+intended by Cargo. Examples@: @code{rust-clap-2}, @code{rust-rand-0.6}.
Because of the difficulty in reusing rust packages as pre-compiled inputs for
other packages the Cargo build system (@pxref{Build Systems,
Guix code should define appropriate data types (for instance, using
@code{define-record-type*}) rather than abuse lists. In addition, it
should use pattern matching, via Guile’s @code{(ice-9 match)} module,
-especially when matching lists.
+especially when matching lists (@pxref{Pattern Matching,,, guile, GNU
+Guile Reference Manual}).
@node Formatting Code
@subsection Formatting Code
whether to split the package (@pxref{Packages with Multiple Outputs}),
and which optional dependencies should be used. In particular, avoid adding
@code{texlive} as a dependency: because of its extreme size, use
-@code{texlive-tiny} or @code{texlive-union} instead.
+the @code{texlive-tiny} package or @code{texlive-union} procedure instead.
@item
For important changes, check that dependent package (if applicable) are
6 months or so.
@end table
-All these branches are @uref{@value{SUBSTITUTE-SERVER},
+All these branches are @uref{@value{SUBSTITUTE-URL},
tracked by our build farm} and merged into @code{master} once
everything has been successfully built. This allows us to fix issues
before they hit users, and to reduce the window during which pre-built
binaries are not available.
-Generally, branches other than @code{master} are considered
-@emph{frozen} if there has been a recent evaluation, or there is a
-corresponding @code{-next} branch. Please ask on the mailing list or
-IRC if unsure where to place a patch.
+When we decide to start building the @code{staging} or
+@code{core-updates} branches, they will be forked and renamed with the
+suffix @code{-frozen}, at which time only bug fixes may be pushed to the
+frozen branches. The @code{core-updates} and @code{staging} branches
+will remain open to accept patches for the next cycle. Please ask on
+the mailing list or IRC if unsure where to place a patch.
@c TODO: It would be good with badges on the website that tracks these
@c branches. Or maybe even a status page.
@emph{reviewing} and pushing other people's changes. As a committer,
you're welcome to use your expertise and commit rights to help other
contributors, too!
+
+@node Updating the Guix Package
+@section Updating the Guix Package
+
+@cindex update-guix-package, updating the guix package
+It is sometimes desirable to update the @code{guix} package itself (the
+package defined in @code{(gnu packages package-management)}), for
+example to make new daemon features available for use by the
+@code{guix-service-type} service type. In order to simplify this task,
+the following command can be used:
+
+@example
+make update-guix-package
+@end example
+
+The @code{update-guix-package} make target will use the last known
+@emph{commit} corresponding to @code{HEAD} in your Guix checkout,
+compute the hash of the Guix sources corresponding to that commit and
+update the @code{commit}, @code{revision} and hash of the @code{guix}
+package definition.
+
+To validate that the updated @code{guix} package hashes are correct and
+that it can be built successfully, the following command can be run from
+the directory of your Guix checkout:
+
+@example
+./pre-inst-env guix build guix
+@end example
+
+To guard against accidentally updating the @code{guix} package to a
+commit that others can't refer to, a check is made that the commit used
+has already been pushed to the Savannah-hosted Guix git repository.
+
+This check can be disabled, @emph{at your own peril}, by setting the
+@code{GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT} environment variable. When
+this variable is set, the updated package source is also added to the
+store. This is used as part of the release process of Guix.
HCoop / jackhill / guix / guix.git / blobdiff