This project is a cooperative effort, and we need your help to make it
grow! Please get in touch with us on @email{guix-devel@@gnu.org} and
-@code{#guix} on the Freenode IRC network. We welcome ideas, bug
+@code{#guix} on the Libera Chat IRC network. We welcome ideas, bug
reports, patches, and anything that may be helpful to the project. We
particularly welcome help on packaging (@pxref{Packaging Guidelines}).
wonderful @url{https://nongnu.org/geiser/, Geiser}. To set that up, run:
@example
-guix package -i emacs guile emacs-geiser
+guix package -i emacs guile emacs-geiser emacs-geiser-guile
@end example
Geiser allows for interactive and incremental development from within
field to, say, 7 digits. It avoids an aesthetic annoyance (assuming
aesthetics have a role to play here) as well as problems related to OS
limits such as the maximum shebang length (127 bytes for the Linux
-kernel). It is best to use the full commit identifiers in
-@code{origin}s, though, to avoid ambiguities. A typical package
-definition may look like this:
+kernel). There are helper functions for doing this for packages using
+@code{git-fetch} or @code{hg-fetch} (see below). It is best to use the
+full commit identifiers in @code{origin}s, though, to avoid ambiguities.
+A typical package definition may look like this:
+
@lisp
(define my-package
)))
@end lisp
+@deffn {Scheme Procedure} git-version @var{VERSION} @var{REVISION} @var{COMMIT}
+Return the version string for packages using @code{git-fetch}.
+
+@lisp
+(git-version "0.2.3" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05")
+@result{} "0.2.3-0.93818c9"
+@end lisp
+@end deffn
+
+@deffn {Scheme Procedure} hg-version @var{VERSION} @var{REVISION} @var{CHANGESET}
+Return the version string for packages using @code{hg-fetch}. It works
+in the same way as @code{git-version}.
+@end deffn
+
@node Synopses and Descriptions
@subsection Synopses and Descriptions
We recommend you also try building the package on other supported
platforms. As you may not have access to actual hardware platforms, we
recommend using the @code{qemu-binfmt-service-type} to emulate them. In
-order to enable it, add the following service to the list of services in
-your @code{operating-system} configuration:
+order to enable it, add the @code{virtualization} service module and the
+following service to the list of services in your @code{operating-system}
+configuration:
@lisp
(service qemu-binfmt-service-type
(qemu-binfmt-configuration
- (platforms (lookup-qemu-platforms "arm" "aarch64"))
+ (platforms (lookup-qemu-platforms "arm" "aarch64"))))
@end lisp
Then reconfigure your system.
You can then build packages for different platforms by specifying the
@code{--system} option. For example, to build the "hello" package for
-the armhf, aarch64, or mips64 architectures, you would run the following
+the armhf or aarch64 architectures, you would run the following
commands, respectively:
@example
guix build --system=armhf-linux --rounds=2 hello
the @code{texlive-tiny} package or @code{texlive-union} procedure instead.
@item
-For important changes, check that dependent package (if applicable) are
+For important changes, check that dependent packages (if applicable) are
not affected by the change; @code{guix refresh --list-dependent
@var{package}} will help you do that (@pxref{Invoking guix refresh}).
@code{staging} branch (non-disruptive changes). This branch is intended
to be merged in @code{master} every 6 weeks or so. Topical changes
(e.g., an update of the GNOME stack) can instead go to a specific branch
-(say, @code{gnome-updates}).
+(say, @code{gnome-updates}). This branch is not expected to be
+buildable or usable until late in its development process.
@item more than 1,800 dependent packages
@code{core-updates} branch (may include major and potentially disruptive
changes). This branch is intended to be merged in @code{master} every
-6 months or so.
+6 months or so. This branch is not expected to be buildable or usable
+until late in its development process.
@end table
All these branches are @uref{@value{SUBSTITUTE-URL},
changes anything like line breaks or indentation which could potentially
break the patches.
+Expect some delay when you submit your very first patch to
+@email{guix-patches@@gnu.org}. You have to wait until you get an
+acknowledgement with the assigned tracking number. Future acknowledgements
+should not be delayed.
+
When a bug is resolved, please close the thread by sending an email to
@email{@var{NNN}-done@@debbugs.gnu.org}.
Some of the software packaged in Guix also contain translations. We do not
host a translation platform for them. If you want to translate a package
-provided by Guix, you should contact their developpers or find the information
+provided by Guix, you should contact their developers or find the information
on their website. As an example, you can find the homepage of the
@code{hello} package by typing @code{guix show hello}. On the ``homepage''
line, you will see @url{https://www.gnu.org/software/hello/} as the homepage.
@table @asis
@item guix
Guix is written in the Guile programming language, and some strings contain
-special formating that is interpreted by Guile. These special formating
+special formatting that is interpreted by Guile. These special formatting
should be highlighted by Weblate. They start with @code{~} followed by one
or more characters.
-When printing the string, Guile replaces the special formating symbols with
+When printing the string, Guile replaces the special formatting symbols with
actual values. For instance, the string @samp{ambiguous package specification
`~a'} would be substituted to contain said package specification instead of
-@code{~a}. To properly translate this string, you must keep the formating
+@code{~a}. To properly translate this string, you must keep the formatting
code in your translation, although you can place it where it makes sense in
your language. For instance, the French translation says @samp{spécification
du paquet « ~a » ambiguë} because the adjective needs to be placed in the
end of the sentence.
-If there are multiple formating symbols, make sure to respect the order.
+If there are multiple formatting symbols, make sure to respect the order.
Guile does not know in which order you intended the string to be read, so it
will substitute the symbols in the same order as the English sentence.
As an example, you cannot translate @samp{package '~a' has been superseded by
'~a'} by @samp{'~a' superseeds package '~a'}, because the meaning would be
-reversed. If foo is superseeded by bar, the translation would read
+reversed. If @var{foo} is superseded by @var{bar}, the translation would read
@samp{'foo' superseeds package 'bar'}. To work around this problem, it
-is possible to use more advanced formating to select a given piece of data,
+is possible to use more advanced formatting to select a given piece of data,
instead of following the default English order. @xref{Formatted Output,,,
-guile, GNU Guile Reference Manual}, for more information on formating in Guile.
+guile, GNU Guile Reference Manual}, for more information on formatting in Guile.
@item packages
The characters after ``@@'' form the name of the markup, and the text between
``@{'' and ``@}'' is its content. In general, you should not translate the
content of markup like @code{@@code}, as it contains literal code that do not
-change with language. You can translate the content of formating markup such
+change with language. You can translate the content of formatting markup such
as @code{@@emph}, @code{@@i}, @code{@@itemize}, @code{@@item}. However, do
not translate the name of the markup, or it will not be recognized. Do
not translate the word after @code{@@end}, it is the name of the markup that
keep Texinfo markup as is. There are more possible markup types in the manual
than in the package descriptions. In general, do not translate the content
of @code{@@code}, @code{@@file}, @code{@@var}, @code{@@value}, etc. You
-should translate the content of formating markup such as @code{@@emph},
+should translate the content of formatting markup such as @code{@@emph},
@code{@@i}, etc.
-The manual contains sections that can be refered to by name by @code{@@ref},
+The manual contains sections that can be referred to by name by @code{@@ref},
@code{@@xref} and @code{@@pxref}. We have a mechanism in place so you do
not have to translate their content. If you keep the English title, we will
automatically replace it with your translation of that title. This ensures
enough to give it commit access to our repositories. However, we decided
to use a separate repository for two reasons. First, we would have to give
Weblate commit access and authorize its signing key, but we do not trust it
-in the same way we trust guix developpers, especially since we do not manage
+in the same way we trust guix developers, especially since we do not manage
the instance ourselves. Second, if translators mess something up, it can
break the generation of the website and/or guix pull for all our users,
independently of their language.
synchronize it with our guix and artworks repositories after checking no issue
was introduced in the translation.
-Developpers can download the latest PO files from weblate in the Guix
-repository by runnig the @command{make download-po} target. It will
+Developers can download the latest PO files from weblate in the Guix
+repository by running the @command{make download-po} command. It will
automatically download the latest files from weblate, reformat them to a
canonical form, and check they do not contain issues. The manual needs to be
built again to check for additional issues that might crash Texinfo.
-Before pushing new translation files, developpers should add them to the
+Before pushing new translation files, developers should add them to the
make machinery so the translations are actually available. The process
differs for the various components.