diff --git a/doc/guix.texi b/doc/guix.texi
index 89935b476c..bac73890e1 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -11,7 +11,7 @@
 
 @copying
 Copyright @copyright{} 2012, 2013, 2014, 2015, 2016 Ludovic Courtès@*
-Copyright @copyright{} 2013, 2014 Andreas Enge@*
+Copyright @copyright{} 2013, 2014, 2016 Andreas Enge@*
 Copyright @copyright{} 2013 Nikita Karetnikov@*
 Copyright @copyright{} 2015 Mathieu Lirzin@*
 Copyright @copyright{} 2014 Pierre-Antoine Rault@*
@@ -247,7 +247,7 @@ returns an installed package.  As a pure function, its result depends
 solely on its inputs---for instance, it cannot refer to software or
 scripts that were not explicitly passed as inputs.  A build function
 always produces the same result when passed a given set of inputs.  It
-cannot alter the system's environment in
+cannot alter the environment of the running system in
 any way; for instance, it cannot create, modify, or delete files outside
 of its build and installation directories.  This is achieved by running
 build processes in isolated environments (or @dfn{containers}), where only their
@@ -256,13 +256,13 @@ explicit inputs are visible.
 @cindex store
 The result of package build functions is @dfn{cached} in the file
 system, in a special directory called @dfn{the store} (@pxref{The
-Store}).  Each package is installed in a directory of its own, in the
+Store}).  Each package is installed in a directory of its own in the
 store---by default under @file{/gnu/store}.  The directory name contains
 a hash of all the inputs used to build that package; thus, changing an
 input yields a different directory name.
 
-This approach is the foundation of Guix's salient features: support for
-transactional package upgrade and rollback, per-user installation, and
+This approach is the foundation for the salient features of Guix: support
+for transactional package upgrade and rollback, per-user installation, and
 garbage collection of packages (@pxref{Features}).
 
 Guix has a command-line interface, which allows users to build, install,
@@ -327,7 +327,7 @@ $ wget ftp://alpha.gnu.org/gnu/guix/guix-binary-@value{VERSION}.@var{system}.tar
 $ gpg --verify guix-binary-@value{VERSION}.@var{system}.tar.xz.sig
 @end example
 
-If that command fails because you don't have the required public key,
+If that command fails because you do not have the required public key,
 then run this command to import it:
 
 @example
@@ -546,7 +546,7 @@ goes through the daemon.  For instance, command-line tools such as
 daemon (@i{via} remote procedure calls) to instruct it what to do.
 
 The following sections explain how to prepare the build daemon's
-environment.  Also @ref{Substitutes}, for information on how to allow
+environment.  See also @ref{Substitutes}, for information on how to allow
 the daemon to download pre-built binaries.
 
 @menu
@@ -625,7 +625,7 @@ that appear in the chroot's @code{/dev} is fixed, most of these files
 can only be created if the host has them.};
 
 @item
-the @code{/proc} directory; it only shows the container's processes
+the @code{/proc} directory; it only shows the processes of the container
 since a separate PID name space is used;
 
 @item
@@ -645,7 +645,7 @@ a writable @file{/tmp} directory.
 
 You can influence the directory where the daemon stores build trees
 @i{via} the @code{TMPDIR} environment variable.  However, the build tree
-within the chroot is always @file{/tmp/guix-build-@var{name}.drv-0},
+within the chroot is always called @file{/tmp/guix-build-@var{name}.drv-0},
 where @var{name} is the derivation name---e.g., @code{coreutils-8.24}.
 This way, the value of @code{TMPDIR} does not leak inside build
 environments, which avoids discrepancies in cases where build processes
@@ -674,9 +674,9 @@ When desired, the build daemon can @dfn{offload}
 derivation builds to other machines
 running Guix, using the @code{offload} @dfn{build hook}.  When that
 feature is enabled, a list of user-specified build machines is read from
-@file{/etc/guix/machines.scm}; anytime a build is requested, for
+@file{/etc/guix/machines.scm}; every time a build is requested, for
 instance via @code{guix build}, the daemon attempts to offload it to one
-of the machines that satisfies the derivation's constraints, in
+of the machines that satisfy the constraints of the derivation, in
 particular its system type---e.g., @file{x86_64-linux}.  Missing
 prerequisites for the build are copied over SSH to the target machine,
 which then proceeds with the build; upon success the output(s) of the
@@ -715,16 +715,16 @@ Avahi in Guile Scheme Programs}).  The @code{build-machine} data type is
 detailed below.
 
 @deftp {Data Type} build-machine
-This data type represents build machines the daemon may offload builds
-to.  The important fields are:
+This data type represents build machines to which the daemon may offload
+builds.  The important fields are:
 
 @table @code
 
 @item name
-The remote machine's host name.
+The host name of the remote machine.
 
 @item system
-The remote machine's system type---e.g., @code{"x86_64-linux"}.
+The system type of the remote machine---e.g., @code{"x86_64-linux"}.
 
 @item user
 The user account to use when connecting to the remote machine over SSH.
@@ -738,7 +738,7 @@ A number of optional fields may be specified:
 @table @code
 
 @item port
-Port number of the machine's SSH server (default: 22).
+Port number of SSH server on the machine (default: 22).
 
 @item private-key
 The SSH private key file to use when connecting to the machine.
@@ -774,7 +774,7 @@ this is the case by running:
 lsh build-machine guile -c "'(use-modules (guix config))'"
 @end example
 
-There's one last thing to do once @file{machines.scm} is in place.  As
+There is one last thing to do once @file{machines.scm} is in place.  As
 explained above, when offloading, files are transferred back and forth
 between the machine stores.  For this to work, you first need to
 generate a key pair on each machine to allow the daemon to export signed
@@ -1022,8 +1022,8 @@ get everything in place.  Here are some of them.
 @cindex locales, when not on GuixSD
 @vindex LOCPATH
 @vindex GUIX_LOCPATH
-Packages installed @i{via} Guix will not use the host system's locale
-data.  Instead, you must first install one of the locale packages
+Packages installed @i{via} Guix will not use the locale data of the
+host system.  Instead, you must first install one of the locale packages
 available with Guix and then define the @code{GUIX_LOCPATH} environment
 variable:
 
@@ -1034,7 +1034,7 @@ $ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
 
 Note that the @code{glibc-locales} package contains data for all the
 locales supported by the GNU@tie{}libc and weighs in at around
-110@tie{}MiB.  Alternately, the @code{glibc-utf8-locales} is smaller but
+110@tie{}MiB.  Alternatively, the @code{glibc-utf8-locales} is smaller but
 limited to a few UTF-8 locales.
 
 The @code{GUIX_LOCPATH} variable plays a role similar to @code{LOCPATH}
@@ -1043,9 +1043,9 @@ Manual}).  There are two important differences though:
 
 @enumerate
 @item
-@code{GUIX_LOCPATH} is honored only by Guix's libc, and not by the libc
+@code{GUIX_LOCPATH} is honored only by the libc in Guix, and not by the libc
 provided by foreign distros.  Thus, using @code{GUIX_LOCPATH} allows you
-to make sure the foreign distro's programs will not end up loading
+to make sure the programs of the foreign distro will not end up loading
 incompatible locale data.
 
 @item
@@ -1062,10 +1062,10 @@ versions may be incompatible.
 @subsection X11 Fonts
 
 The majority of graphical applications use Fontconfig to locate and
-load fonts and perform X11-client-side rendering.  Guix's
-@code{fontconfig} package looks for fonts in @file{$HOME/.guix-profile}
+load fonts and perform X11-client-side rendering.  The @code{fontconfig}
+package in Guix looks for fonts in @file{$HOME/.guix-profile}
 by default.  Thus, to allow graphical applications installed with Guix
-to display fonts, you will have to install fonts with Guix as well.
+to display fonts, you have to install fonts with Guix as well.
 Essential font packages include @code{gs-fonts}, @code{font-dejavu}, and
 @code{font-gnu-freefont-ttf}.
 
@@ -1094,9 +1094,9 @@ the Emacs package system organizes the file structure (@pxref{Package
 Files,,, emacs, The GNU Emacs Manual}).
 
 By default, Emacs (installed with Guix) ``knows'' where these packages
-are placed, so you don't need to perform any configuration.  If, for
+are placed, so you do not need to perform any configuration.  If, for
 some reason, you want to avoid auto-loading Emacs packages installed
-with Guix, you can do it by running Emacs with @code{--no-site-file}
+with Guix, you can do so by running Emacs with @code{--no-site-file}
 option (@pxref{Init File,,, emacs, The GNU Emacs Manual}).
 
 @c TODO What else?
@@ -1107,7 +1107,7 @@ option (@pxref{Init File,,, emacs, The GNU Emacs Manual}).
 
 The purpose of GNU Guix is to allow users to easily install, upgrade, and
 remove software packages, without having to know about their build
-procedure or dependencies.  Guix also goes beyond this obvious set of
+procedures or dependencies.  Guix also goes beyond this obvious set of
 features.
 
 This chapter describes the main features of Guix, as well as the package
@@ -1149,7 +1149,7 @@ simply continues to point to
 coexist on the same system without any interference.
 
 The @command{guix package} command is the central tool to manage
-packages (@pxref{Invoking guix package}).  It operates on those per-user
+packages (@pxref{Invoking guix package}).  It operates on the per-user
 profiles, and can be used @emph{with normal user privileges}.
 
 The command provides the obvious install, remove, and upgrade
@@ -1166,8 +1166,8 @@ of their profile, which was known to work well.  Similarly, the global
 system configuration is subject to transactional upgrades and roll-back
 (@pxref{Using the Configuration System}).
 
-All those packages in the package store may be @emph{garbage-collected}.
-Guix can determine which packages are still referenced by the user
+All packages in the package store may be @emph{garbage-collected}.
+Guix can determine which packages are still referenced by user
 profiles, and remove those that are provably no longer referenced
 (@pxref{Invoking guix gc}).  Users may also explicitly remove old
 generations of their profile so that the packages they refer to can be
@@ -1197,8 +1197,8 @@ otherwise, it builds the package from source, locally
 Control over the build environment is a feature that is also useful for
 developers.  The @command{guix environment} command allows developers of
 a package to quickly set up the right development environment for their
-package, without having to manually install the package's dependencies
-in their profile (@pxref{Invoking guix environment}).
+package, without having to manually install the dependencies of the
+package into their profile (@pxref{Invoking guix environment}).
 
 @node Invoking guix package
 @section Invoking @command{guix package}
@@ -1289,7 +1289,7 @@ An example is the GNU MPC library: its C header files refer to those of
 the GNU MPFR library, which in turn refer to those of the GMP library.
 Thus, when installing MPC, the MPFR and GMP libraries also get installed
 in the profile; removing MPC also removes MPFR and GMP---unless they had
-also been explicitly installed independently.
+also been explicitly installed by the user.
 
 Besides, packages sometimes rely on the definition of environment
 variables for their search paths (see explanation of
@@ -1327,7 +1327,7 @@ As an example, @var{file} might contain a definition like this
 @end example
 
 Developers may find it useful to include such a @file{package.scm} file
-in the root of their project's source tree that can be used to test
+in the root of their project source tree that can be used to test
 development snapshots and create reproducible development environments
 (@pxref{Invoking guix environment}).
 
@@ -1398,11 +1398,11 @@ before any other actions.
 
 When rolling back from the first generation that actually contains
 installed packages, the profile is made to point to the @dfn{zeroth
-generation}, which contains no files apart from its own meta-data.
+generation}, which contains no files apart from its own metadata.
 
-Installing, removing, or upgrading packages from a generation that has
-been rolled back to overwrites previous future generations.  Thus, the
-history of a profile's generations is always linear.
+After having rolled back, installing, removing, or upgrading packages
+overwrites previous future generations.  Thus, the history of the
+generations in a profile is always linear.
 
 @item --switch-generation=@var{pattern}
 @itemx -S @var{pattern}
@@ -1465,8 +1465,8 @@ variable, even though, taken individually, neither @file{foo} nor
 Use @var{profile} instead of the user's default profile.
 
 @item --verbose
-Produce verbose output.  In particular, emit the environment's build log
-on the standard error port.
+Produce verbose output.  In particular, emit the build log of the
+environment on the standard error port.
 
 @item --bootstrap
 Use the bootstrap Guile to build the profile.  This option is only
@@ -1474,7 +1474,7 @@ useful to distribution developers.
 
 @end table
 
-In addition to these actions @command{guix package} supports the
+In addition to these actions, @command{guix package} supports the
 following options to query the current state of a profile, or the
 availability of packages:
 
@@ -1484,7 +1484,7 @@ availability of packages:
 @itemx -s @var{regexp}
 @cindex searching for packages
 List the available packages whose name, synopsis, or description matches
-@var{regexp}.  Print all the meta-data of matching packages in
+@var{regexp}.  Print all the metadata of matching packages in
 @code{recutils} format (@pxref{Top, GNU recutils databases,, recutils,
 GNU recutils manual}).
 
@@ -1610,7 +1610,7 @@ specified order.  Neither spaces nor trailing commas are allowed.
 
 @item @emph{Ranges}.  @code{--list-generations=2..9} prints the
 specified generations and everything in between.  Note that the start of
-a range must be lesser than its end.
+a range must be smaller than its end.
 
 It is also possible to omit the endpoint.  For example,
 @code{--list-generations=2..}, returns all generations starting from the
@@ -1636,17 +1636,17 @@ deletes generations that are more than one month old.
 If the current generation matches, it is @emph{not} deleted.  Also, the
 zeroth generation is never deleted.
 
-Note that deleting generations prevents roll-back to them.
+Note that deleting generations prevents rolling back to them.
 Consequently, this command must be used with care.
 
 @end table
 
 Finally, since @command{guix package} may actually start build
 processes, it supports all the common build options (@pxref{Common Build
-Options}).  It also support package transformation options, such as
+Options}).  It also supports package transformation options, such as
 @option{--with-source} (@pxref{Package Transformation Options}).
 However, note that package transformations are lost when upgrading; to
-preserve transformation across upgrades, you should define your own
+preserve transformations across upgrades, you should define your own
 package variant in a Guile module and add it to @code{GUIX_PACKAGE_PATH}
 (@pxref{Defining Packages}).
 
@@ -1781,7 +1781,7 @@ like to discuss this project, join us on @email{guix-devel@@gnu.org}.
 @cindex package outputs
 
 Often, packages defined in Guix have a single @dfn{output}---i.e., the
-source package leads exactly one directory in the store.  When running
+source package leads to exactly one directory in the store.  When running
 @command{guix package -i glibc}, one installs the default output of the
 GNU libc package; the default output is called @code{out}, but its name
 can be omitted as shown in this command.  In this particular case, the
@@ -1808,7 +1808,7 @@ guix package -i glib:doc
 @end example
 
 Some packages install programs with different ``dependency footprints''.
-For instance, the WordNet package install both command-line tools and
+For instance, the WordNet package installs both command-line tools and
 graphical user interfaces (GUIs).  The former depend solely on the C
 library, whereas the latter depend on Tcl/Tk and the underlying X
 libraries.  In this case, we leave the command-line tools in the default
@@ -1830,7 +1830,7 @@ guix package}).
 @section Invoking @command{guix gc}
 
 @cindex garbage collector
-Packages that are installed but not used may be @dfn{garbage-collected}.
+Packages that are installed, but not used, may be @dfn{garbage-collected}.
 The @command{guix gc} command allows users to explicitly run the garbage
 collector to reclaim space from the @file{/gnu/store} directory.  It is
 the @emph{only} way to remove files from @file{/gnu/store}---removing
@@ -1914,8 +1914,8 @@ include the store files themselves, their references, and the references
 of these, recursively.  In other words, the returned list is the
 @dfn{transitive closure} of the store files.
 
-@xref{Invoking guix size}, for a tool to profile the size of an
-element's closure.  @xref{Invoking guix graph}, for a tool to visualize
+@xref{Invoking guix size}, for a tool to profile the size of the closure
+of an element.  @xref{Invoking guix graph}, for a tool to visualize
 the graph of references.
 
 @end table
@@ -1931,13 +1931,13 @@ store and to control disk usage.
 Verify the integrity of the store.
 
 By default, make sure that all the store items marked as valid in the
-daemon's database actually exist in @file{/gnu/store}.
+database of the daemon actually exist in @file{/gnu/store}.
 
-When provided, @var{options} must a comma-separated list containing one
+When provided, @var{options} must be a comma-separated list containing one
 or more of @code{contents} and @code{repair}.
 
-When passing @option{--verify=contents}, the daemon will compute the
-content hash of each store item and compare it against its hash in the
+When passing @option{--verify=contents}, the daemon computse the
+content hash of each store item and compares it against its hash in the
 database.  Hash mismatches are reported as data corruptions.  Because it
 traverses @emph{all the files in the store}, this command can take a
 long time, especially on systems with a slow disk drive.
@@ -2004,7 +2004,7 @@ useful to Guix developers.
 The @command{guix archive} command allows users to @dfn{export} files
 from the store into a single archive, and to later @dfn{import} them.
 In particular, it allows store files to be transferred from one machine
-to another machine's store.  For example, to transfer the @code{emacs}
+to the store on another machine.  For example, to transfer the @code{emacs}
 package to a machine connected over SSH, one would run:
 
 @example
@@ -2023,14 +2023,14 @@ guix archive --export -r $(readlink -f ~/.guix-profile) | \
 @noindent
 However, note that, in both examples, all of @code{emacs} and the
 profile as well as all of their dependencies are transferred (due to
-@code{-r}), regardless of what is already available in the target
-machine's store.  The @code{--missing} option can help figure out which
-items are missing from the target's store.
+@code{-r}), regardless of what is already available in the store on the
+target machine.  The @code{--missing} option can help figure out which
+items are missing from the target store.
 
 Archives are stored in the ``Nix archive'' or ``Nar'' format, which is
 comparable in spirit to `tar', but with a few noteworthy differences
 that make it more appropriate for our purposes.  First, rather than
-recording all Unix meta-data for each file, the Nar format only mentions
+recording all Unix metadata for each file, the Nar format only mentions
 the file type (regular, directory, or symbolic link); Unix permissions
 and owner/group are dismissed.  Second, the order in which directory
 entries are stored always follows the order of file names according to
@@ -2073,7 +2073,7 @@ the store.
 
 @item --generate-key[=@var{parameters}]
 @cindex signing, archives
-Generate a new key pair for the daemons.  This is a prerequisite before
+Generate a new key pair for the daemon.  This is a prerequisite before
 archives can be exported with @code{--export}.  Note that this operation
 usually takes time, because it needs to gather enough entropy to
 generate the key pair.
@@ -2083,7 +2083,7 @@ The generated key pair is typically stored under @file{/etc/guix}, in
 key, which must be kept secret.)  When @var{parameters} is omitted,
 an ECDSA key using the Ed25519 curve is generated, or, for Libgcrypt
 versions before 1.6.0, it is a 4096-bit RSA key.
-Alternately, @var{parameters} can specify
+Alternatively, @var{parameters} can specify
 @code{genkey} parameters suitable for Libgcrypt (@pxref{General
 public-key related Functions, @code{gcry_pk_genkey},, gcrypt, The
 Libgcrypt Reference Manual}).
@@ -2127,7 +2127,7 @@ archive contents coming from possibly untrusted substitute servers.
 
 @end table
 
-To export store files as an archive to the standard output, run:
+To export store files as an archive to standard output, run:
 
 @example
 guix archive --export @var{options} @var{specifications}...
@@ -2226,8 +2226,8 @@ package looks like this:
 
 @noindent
 Without being a Scheme expert, the reader may have guessed the meaning
-of the various fields here.  This expression binds variable @code{hello}
-to a @code{<package>} object, which is essentially a record
+of the various fields here.  This expression binds the variable
+@code{hello} to a @code{<package>} object, which is essentially a record
 (@pxref{SRFI-9, Scheme records,, guile, GNU Guile Reference Manual}).
 This package object can be inspected using procedures found in the
 @code{(guix packages)} module; for instance, @code{(package-name hello)}
@@ -2237,7 +2237,7 @@ With luck, you may be able to import part or all of the definition of
 the package you are interested in from another repository, using the
 @code{guix import} command (@pxref{Invoking guix import}).
 
-In the example above, @var{hello} is defined into a module of its own,
+In the example above, @var{hello} is defined in a module of its own,
 @code{(gnu packages hello)}.  Technically, this is not strictly
 necessary, but it is convenient to do so: all the packages defined in
 modules under @code{(gnu packages @dots{})} are automatically known to
@@ -2308,7 +2308,7 @@ more information on how to test package definitions, and
 @ref{Invoking guix lint}, for information on how to check a definition
 for style conformance.
 
-Eventually, updating the package definition to a new upstream version
+Finally, updating the package definition to a new upstream version
 can be partly automated by the @command{guix refresh} command
 (@pxref{Invoking guix refresh}).
 
@@ -2388,7 +2388,7 @@ tuples, where each tuple has a label for the input (a string) as its
 first element, a package, origin, or derivation as its second element,
 and optionally the name of the output thereof that should be used, which
 defaults to @code{"out"} (@pxref{Packages with Multiple Outputs}, for
-more on package outputs).  For example, the list below specifies 3
+more on package outputs).  For example, the list below specifies three
 inputs:
 
 @example
@@ -2404,15 +2404,15 @@ dependencies listed in @code{inputs} are built for the @emph{target}
 architecture; conversely, dependencies listed in @code{native-inputs}
 are built for the architecture of the @emph{build} machine.
 
-@code{native-inputs} is typically where you would list tools needed at
-build time but not at run time, such as Autoconf, Automake, pkg-config,
+@code{native-inputs} is typically used to list tools needed at
+build time, but not at run time, such as Autoconf, Automake, pkg-config,
 Gettext, or Bison.  @command{guix lint} can report likely mistakes in
 this area (@pxref{Invoking guix lint}).
 
 @anchor{package-propagated-inputs}
 Lastly, @code{propagated-inputs} is similar to @code{inputs}, but the
-specified packages will be force-installed alongside the package they
-belong to (@pxref{package-cmd-propagated-inputs, @command{guix
+specified packages will be automatically installed alongside the package
+they belong to (@pxref{package-cmd-propagated-inputs, @command{guix
 package}}, for information on how @command{guix package} deals with
 propagated inputs.)
 
@@ -2420,9 +2420,9 @@ For example this is necessary when a C/C++ library needs headers of
 another library to compile, or when a pkg-config file refers to another
 one @i{via} its @code{Requires} field.
 
-Another example where @code{propagated-inputs} is useful is for
-languages that lack a facility to record the run-time search path akin
-to ELF's @code{RUNPATH}; this includes Guile, Python, Perl, GHC, and
+Another example where @code{propagated-inputs} is useful is for languages
+that lack a facility to record the run-time search path akin to the
+@code{RUNPATH}of ELF files; this includes Guile, Python, Perl, GHC, and
 more.  To ensure that libraries written in those languages can find
 library code they depend on at run time, run-time dependencies must be
 listed in @code{propagated-inputs} rather than @code{inputs}.
@@ -2441,7 +2441,7 @@ A list of @code{search-path-specification} objects describing
 search-path environment variables honored by the package.
 
 @item @code{replacement} (default: @code{#f})
-This must either @code{#f} or a package object that will be used as a
+This must be either @code{#f} or a package object that will be used as a
 @dfn{replacement} for this package.  @xref{Security Updates, grafts},
 for details.
 
@@ -2452,7 +2452,8 @@ A one-line description of the package.
 A more elaborate description of the package.
 
 @item @code{license}
-The license of the package; a value from @code{(guix licenses)}.
+The license of the package; a value from @code{(guix licenses)},
+or a list of such values.
 
 @item @code{home-page}
 The URL to the home-page of the package, as a string.
@@ -2465,7 +2466,7 @@ The list of systems supported by the package, as strings of the form
 The list of maintainers of the package, as @code{maintainer} objects.
 
 @item @code{location} (default: source location of the @code{package} form)
-The source location of the package.  It's useful to override this when
+The source location of the package.  It is useful to override this when
 inheriting from another package, in which case this field is not
 automatically corrected.
 @end table
@@ -2489,13 +2490,13 @@ the @code{method} (see below).  For example, when using the
 values are: a URL represented as a string, or a list thereof.
 
 @item @code{method}
-A procedure that will handle the URI.
+A procedure that handles the URI.
 
 Examples include:
 
 @table @asis
 @item @var{url-fetch} from @code{(guix download)}
-download a file the HTTP, HTTPS, or FTP URL specified in the
+download a file from the HTTP, HTTPS, or FTP URL specified in the
 @code{uri} field;
 
 @item @var{git-fetch} from @code{(guix git-download)}
@@ -2519,7 +2520,7 @@ base-32 string.
 The file name under which the source code should be saved.  When this is
 @code{#f}, a sensible default value will be used in most cases.  In case
 the source is fetched from a URL, the file name from the URL will be
-used.  For version control checkouts, it's recommended to provide the
+used.  For version control checkouts, it is recommended to provide the
 file name explicitly because the default is not very descriptive.
 
 @item @code{patches} (default: @code{'()})
@@ -2559,7 +2560,7 @@ this is @code{#f}, a sensible default is used.
 @cindex build system
 Each package definition specifies a @dfn{build system} and arguments for
 that build system (@pxref{Defining Packages}).  This @code{build-system}
-field represents the build procedure of the package, as well implicit
+field represents the build procedure of the package, as well as implicit
 dependencies of that build procedure.
 
 Build systems are @code{<build-system>} objects.  The interface to
@@ -2583,7 +2584,7 @@ evaluated in the @dfn{build stratum}---i.e., by a Guile process launched
 by the daemon (@pxref{Derivations}).
 
 The main build system is @var{gnu-build-system}, which implements the
-standard build procedure for GNU packages and many other packages.  It
+standard build procedure for GNU and many other packages.  It
 is provided by the @code{(guix build-system gnu)} module.
 
 @defvr {Scheme Variable} gnu-build-system
@@ -2592,7 +2593,7 @@ thereof (@pxref{Configuration, configuration and makefile conventions,,
 standards, GNU Coding Standards}).
 
 @cindex build phases
-In a nutshell, packages using it configured, built, and installed with
+In a nutshell, packages using it are configured, built, and installed with
 the usual @code{./configure && make && make check && make install}
 command sequence.  In practice, a few additional steps are often needed.
 All these steps are split up in separate @dfn{phases},
@@ -2657,8 +2658,8 @@ means that all the phases described above will be used, except the
 In addition, this build system ensures that the ``standard'' environment
 for GNU packages is available.  This includes tools such as GCC, libc,
 Coreutils, Bash, Make, Diffutils, grep, and sed (see the @code{(guix
-build-system gnu)} module for a complete list.)  We call these the
-@dfn{implicit inputs} of a package, because package definitions don't
+build-system gnu)} module for a complete list).  We call these the
+@dfn{implicit inputs} of a package, because package definitions do not
 have to mention them.
 @end defvr
 
@@ -2694,8 +2695,8 @@ This build system adds the following two phases to the ones defined by
 
 @table @code
 @item glib-or-gtk-wrap
-The phase @code{glib-or-gtk-wrap} ensures that programs found under
-@file{bin/} are able to find GLib's ``schemas'' and
+The phase @code{glib-or-gtk-wrap} ensures that programs in
+@file{bin/} are able to find GLib ``schemas'' and
 @uref{https://developer.gnome.org/gtk3/stable/gtk-running.html, GTK+
 modules}.  This is achieved by wrapping the programs in launch scripts
 that appropriately set the @code{XDG_DATA_DIRS} and @code{GTK_PATH}
@@ -2709,9 +2710,9 @@ where wrapping would gratuitously add a dependency of that output on
 GLib and GTK+.
 
 @item glib-or-gtk-compile-schemas
-The phase @code{glib-or-gtk-compile-schemas} makes sure that all GLib's
+The phase @code{glib-or-gtk-compile-schemas} makes sure that all
 @uref{https://developer.gnome.org/gio/stable/glib-compile-schemas.html,
-GSettings schemas} are compiled.  Compilation is performed by the
+GSettings schemas} of GLib are compiled.  Compilation is performed by the
 @command{glib-compile-schemas} program.  It is provided by the package
 @code{glib:bin} which is automatically imported by the build system.
 The @code{glib} package providing @command{glib-compile-schemas} can be
@@ -2728,7 +2729,7 @@ packages, which consists in running @code{python setup.py build} and
 then @code{python setup.py install --prefix=/gnu/store/@dots{}}.
 
 For packages that install stand-alone Python programs under @code{bin/},
-it takes care of wrapping these programs so their @code{PYTHONPATH}
+it takes care of wrapping these programs so that their @code{PYTHONPATH}
 environment variable points to all the Python libraries they depend on.
 
 Which Python package is used can be specified with the @code{#:python}
@@ -2741,7 +2742,7 @@ implements the standard build procedure for Perl packages, which either
 consists in running @code{perl Build.PL --prefix=/gnu/store/@dots{}},
 followed by @code{Build} and @code{Build install}; or in running
 @code{perl Makefile.PL PREFIX=/gnu/store/@dots{}}, followed by
-@code{make} and @code{make install}; depending on which of
+@code{make} and @code{make install}, depending on which of
 @code{Build.PL} or @code{Makefile.PL} is present in the package
 distribution.  Preference is given to the former if both @code{Build.PL}
 and @code{Makefile.PL} exist in the package distribution.  This
@@ -2816,8 +2817,8 @@ parameter which defaults to @code{ghc}.
 
 @defvr {Scheme Variable} emacs-build-system
 This variable is exported by @code{(guix build-system emacs)}.  It
-implements an installation procedure similar to the one of Emacs' own
-packaging system (@pxref{Packages,,, emacs, The GNU Emacs Manual}).
+implements an installation procedure similar to the packaging system
+of Emacs itself (@pxref{Packages,,, emacs, The GNU Emacs Manual}).
 
 It first creates the @code{@var{package}-autoloads.el} file, then it
 byte compiles all Emacs Lisp files.  Differently from the Emacs
@@ -2836,7 +2837,7 @@ and does not have a notion of build phases.
 This variable is exported by @code{(guix build-system trivial)}.
 
 This build system requires a @code{#:builder} argument.  This argument
-must be a Scheme expression that builds the package's output(s)---as
+must be a Scheme expression that builds the package output(s)---as
 with @code{build-expression->derivation} (@pxref{Derivations,
 @code{build-expression->derivation}}).
 @end defvr
@@ -2847,8 +2848,8 @@ with @code{build-expression->derivation} (@pxref{Derivations,
 @cindex store
 @cindex store paths
 
-Conceptually, the @dfn{store} is where derivations that have been
-successfully built are stored---by default, under @file{/gnu/store}.
+Conceptually, the @dfn{store} is the place where derivations that have
+been built successfully are stored---by default, @file{/gnu/store}.
 Sub-directories in the store are referred to as @dfn{store paths}.  The
 store has an associated database that contains information such as the
 store paths referred to by each store path, and the list of @emph{valid}
@@ -2856,8 +2857,8 @@ store paths---paths that result from a successful build.
 
 The store is always accessed by the daemon on behalf of its clients
 (@pxref{Invoking guix-daemon}).  To manipulate the store, clients
-connect to the daemon over a Unix-domain socket, send it requests, and
-read the result---these are remote procedure calls, or RPCs.
+connect to the daemon over a Unix-domain socket, send requests to it,
+and read the result---these are remote procedure calls, or RPCs.
 
 The @code{(guix store)} module provides procedures to connect to the
 daemon, and to perform RPCs.  These are described below.
@@ -2866,7 +2867,7 @@ daemon, and to perform RPCs.  These are described below.
 Connect to the daemon over the Unix-domain socket at @var{file}.  When
 @var{reserve-space?} is true, instruct it to reserve a little bit of
 extra space on the file system so that the garbage collector can still
-operate, should the disk become full.  Return a server object.
+operate should the disk become full.  Return a server object.
 
 @var{file} defaults to @var{%default-socket-path}, which is the normal
 location given the options that were passed to @command{configure}.
@@ -3155,9 +3156,9 @@ So, to exit the monad and get the desired effect, one must use
 @result{} /gnu/store/...-sh-symlink
 @end example
 
-Note that the @code{(guix monad-repl)} module extends Guile's REPL with
+Note that the @code{(guix monad-repl)} module extends the Guile REPL with
 new ``meta-commands'' to make it easier to deal with monadic procedures:
-@code{run-in-store}, and @code{enter-store-monad}.  The former, is used
+@code{run-in-store}, and @code{enter-store-monad}.  The former is used
 to ``run'' a single monadic value through the store:
 
 @example
@@ -3339,7 +3340,8 @@ monadic procedures:
 
 @deffn {Monadic Procedure} package-file @var{package} [@var{file}] @
        [#:system (%current-system)] [#:target #f] @
-       [#:output "out"] Return as a monadic
+       [#:output "out"]
+Return as a monadic
 value in the absolute file name of @var{file} within the @var{output}
 directory of @var{package}.  When @var{file} is omitted, return the name
 of the @var{output} directory of @var{package}.  When @var{target} is
@@ -3361,12 +3363,12 @@ Monadic version of @code{package-derivation} and
 @cindex build code quoting
 So we have ``derivations'', which represent a sequence of build actions
 to be performed to produce an item in the store (@pxref{Derivations}).
-Those build actions are performed when asking the daemon to actually
+These build actions are performed when asking the daemon to actually
 build the derivations; they are run by the daemon in a container
 (@pxref{Invoking guix-daemon}).
 
 @cindex strata of code
-It should come as no surprise that we like to write those build actions
+It should come as no surprise that we like to write these build actions
 in Scheme.  When we do that, we end up with two @dfn{strata} of Scheme
 code@footnote{The term @dfn{stratum} in this context was coined by
 Manuel Serrano et al.@: in the context of their work on Hop.  Oleg
@@ -3380,19 +3382,19 @@ performs build actions, such as making directories, invoking
 
 To describe a derivation and its build actions, one typically needs to
 embed build code inside host code.  It boils down to manipulating build
-code as data, and Scheme's homoiconicity---code has a direct
+code as data, and the homoiconicity of Scheme---code has a direct
 representation as data---comes in handy for that.  But we need more than
-Scheme's normal @code{quasiquote} mechanism to construct build
+the normal @code{quasiquote} mechanism in Scheme to construct build
 expressions.
 
 The @code{(guix gexp)} module implements @dfn{G-expressions}, a form of
 S-expressions adapted to build expressions.  G-expressions, or
-@dfn{gexps}, consist essentially in three syntactic forms: @code{gexp},
+@dfn{gexps}, consist essentially of three syntactic forms: @code{gexp},
 @code{ungexp}, and @code{ungexp-splicing} (or simply: @code{#~},
-@code{#$}, and @code{#$@@}), which are comparable respectively to
-@code{quasiquote}, @code{unquote}, and @code{unquote-splicing}
-(@pxref{Expression Syntax, @code{quasiquote},, guile, GNU Guile
-Reference Manual}).  However, there are major differences:
+@code{#$}, and @code{#$@@}), which are comparable to
+@code{quasiquote}, @code{unquote}, and @code{unquote-splicing},
+respectivel (@pxref{Expression Syntax, @code{quasiquote},, guile,
+GNU Guile Reference Manual}).  However, there are major differences:
 
 @itemize
 @item
@@ -3415,9 +3417,9 @@ This mechanism is not limited to package and derivation
 objects: @dfn{compilers} able to ``lower'' other high-level objects to
 derivations or files in the store can be defined,
 such that these objects can also be inserted
-into gexps.  For example, a useful type of high-level object that can be
+into gexps.  For example, a useful type of high-level objects that can be
 inserted in a gexp is ``file-like objects'', which make it easy to
-add files to the store and refer to them in
+add files to the store and to refer to them in
 derivations and such (see @code{local-file} and @code{plain-file}
 below.)
 
@@ -3444,8 +3446,8 @@ As one would expect, the @code{"/gnu/store/@dots{}-coreutils-8.22"} string is
 substituted to the reference to the @var{coreutils} package in the
 actual build code, and @var{coreutils} is automatically made an input to
 the derivation.  Likewise, @code{#$output} (equivalent to @code{(ungexp
-output)}) is replaced by a string containing the derivation's output
-directory name.
+output)}) is replaced by a string containing the directory name of the
+output of the derivation.
 
 @cindex cross compilation
 In a cross-compilation context, it is useful to distinguish between
@@ -3784,7 +3786,7 @@ The general syntax is:
 guix build @var{options} @var{package-or-derivation}@dots{}
 @end example
 
-As an example, the following command builds the latest version of Emacs
+As an example, the following command builds the latest versions of Emacs
 and of Guile, displays their build logs, and finally displays the
 resulting directories:
 
@@ -3890,7 +3892,7 @@ stashing one of the build results with @code{guix archive --export},
 then rebuilding, and finally comparing the two results.
 
 @item --no-build-hook
-Do not attempt to offload builds @i{via} the daemon's ``build hook''
+Do not attempt to offload builds @i{via} the ``build hook'' of the daemon
 (@pxref{Daemon Offload Setup}).  That is, always build things locally
 instead of offloading builds to remote machines.
 
@@ -3953,7 +3955,7 @@ the parsed command-line options.
 @cindex package variants
 Another set of command-line options supported by @command{guix build}
 and also @command{guix package} are @dfn{package transformation
-options}.  These are options that allow you to define @dfn{package
+options}.  These are options that make it possible to define @dfn{package
 variants}---for instance, packages built from different source code.
 This is a convenient way to create customized packages on the fly
 without having to type in the definitions of package variants
@@ -3966,11 +3968,11 @@ Use @var{source} as the source of the corresponding package.
 @var{source} must be a file name or a URL, as for @command{guix
 download} (@pxref{Invoking guix download}).
 
-The ``corresponding package'' is taken to be one specified on the
-command line whose name matches the base of @var{source}---e.g., if
-@var{source} is @code{/src/guile-2.0.10.tar.gz}, the corresponding
+The ``corresponding package'' is taken to be the one specified on the
+command line the name of which matches the base of @var{source}---e.g.,
+if @var{source} is @code{/src/guile-2.0.10.tar.gz}, the corresponding
 package is @code{guile}.  Likewise, the version string is inferred from
-@var{source}; in the previous example, it's @code{2.0.10}.
+@var{source}; in the previous example, it is @code{2.0.10}.
 
 This option allows users to try out versions of packages other than the
 one provided by the distribution.  The example below downloads
@@ -4001,7 +4003,7 @@ Replace dependency on @var{package} by a dependency on
 @var{replacement} must be a package specification such as @code{guile}
 or @code{guile@@1.8}.
 
-For instance, the following command builds Guix but replaces its
+For instance, the following command builds Guix, but replaces its
 dependency on the current stable version of Guile with a dependency on
 the development version of Guile, @code{guile-next}:
 
@@ -4045,7 +4047,7 @@ For example, @var{expr} may be @code{(@@ (gnu packages guile)
 guile-1.8)}, which unambiguously designates this specific variant of
 version 1.8 of Guile.
 
-Alternately, @var{expr} may be a G-expression, in which case it is used
+Alternatively, @var{expr} may be a G-expression, in which case it is used
 as a build program passed to @code{gexp->derivation}
 (@pxref{G-Expressions}).
 
@@ -4055,14 +4057,15 @@ monadic value, which is then passed through @code{run-with-store}.
 
 @item --source
 @itemx -S
-Build the packages' source derivations, rather than the packages
+Build the source derivations of the packages, rather than the packages
 themselves.
 
 For instance, @code{guix build -S gcc} returns something like
-@file{/gnu/store/@dots{}-gcc-4.7.2.tar.bz2}, which is GCC's source tarball.
+@file{/gnu/store/@dots{}-gcc-4.7.2.tar.bz2}, which is the GCC
+source tarball.
 
 The returned source tarball is the result of applying any patches and
-code snippets specified in the package's @code{origin} (@pxref{Defining
+code snippets specified in the package @code{origin} (@pxref{Defining
 Packages}).
 
 @item --sources
@@ -4079,8 +4082,8 @@ This value causes the @code{--sources} option to behave in the same way
 as the @code{--source} option.
 
 @item all
-Build all packages' source derivations, including any source that might
-be listed as @code{inputs}.  This is the default value.
+Build the source derivations of all packages, including any source that
+might be listed as @code{inputs}.  This is the default value.
 
 @example
 $ guix build --sources tzdata
@@ -4090,8 +4093,8 @@ The following derivations will be built:
 @end example
 
 @item transitive
-Build all packages' source derivations, as well as all source
-derivations for packages' transitive inputs.  This can be used e.g. to
+Build the source derivations of all packages, as well of all transitive
+inputs to the packages.  This can be used e.g. to
 prefetch package source for later offline building.
 
 @example
@@ -4111,7 +4114,7 @@ The following derivations will be built:
 @item --system=@var{system}
 @itemx -s @var{system}
 Attempt to build for @var{system}---e.g., @code{i686-linux}---instead of
-the host's system type.
+the system type of the build host.
 
 An example use of this is on Linux-based systems, which can emulate
 different personalities.  For instance, passing
@@ -4132,9 +4135,9 @@ Rebuild @var{package-or-derivation}, which are already available in the
 store, and raise an error if the build results are not bit-for-bit
 identical.
 
-This mechanism allows you to check whether previously-installed
-substitutes are genuine (@pxref{Substitutes}), or whether a package's
-build result is deterministic.  @xref{Invoking guix challenge}, for more
+This mechanism allows you to check whether previously installed
+substitutes are genuine (@pxref{Substitutes}), or whether the build result
+of a package is deterministic.  @xref{Invoking guix challenge}, for more
 background information and tools.
 
 @item --no-grafts
@@ -4154,7 +4157,7 @@ collector root.
 
 @item --log-file
 Return the build log file names or URLs for the given
-@var{package-or-derivation}s, or raise an error if build logs are
+@var{package-or-derivation}, or raise an error if build logs are
 missing.
 
 This works regardless of how packages or derivations are specified.  For
@@ -4171,8 +4174,8 @@ If a log is unavailable locally, and unless @code{--no-substitutes} is
 passed, the command looks for a corresponding log on one of the
 substitute servers (as specified with @code{--substitute-urls}.)
 
-So for instance, let's say you want to see the build log of GDB on MIPS
-but you're actually on an @code{x86_64} machine:
+So for instance, imagine you want to see the build log of GDB on MIPS,
+but you are actually on an @code{x86_64} machine:
 
 @example
 $ guix build --log-file gdb -s mips64el-linux 
@@ -4200,9 +4203,9 @@ launches the program specified in the @code{VISUAL} or in the
 @code{EDITOR} environment variable to edit the recipe of GCC@tie{}4.8.4
 and that of Vim.
 
-If you are using Emacs, note that the Emacs user interface provides
+If you are using Emacs, note that the Emacs user interface provides the
 @kbd{M-x guix-edit} command and a similar functionality in the ``package
-info'' and ``package list'' buffers created by @kbd{M-x
+info'' and ``package list'' buffers created by the @kbd{M-x
 guix-search-by-name} and similar commands (@pxref{Emacs Commands}).
 
 
@@ -4210,7 +4213,7 @@ guix-search-by-name} and similar commands (@pxref{Emacs Commands}).
 @section Invoking @command{guix download}
 
 When writing a package definition, developers typically need to download
-the package's source tarball, compute its SHA256 hash, and write that
+a source tarball, compute its SHA256 hash, and write that
 hash in the package definition (@pxref{Defining Packages}).  The
 @command{guix download} tool helps with this task: it downloads a file
 from the given URI, adds it to the store, and prints both its file name
@@ -4274,10 +4277,10 @@ in the definitions of packages.
 Compute the hash on @var{file} recursively.
 
 In this case, the hash is computed on an archive containing @var{file},
-including its children if it is a directory.  Some of @var{file}'s
-meta-data is part of the archive; for instance, when @var{file} is a
+including its children if it is a directory.  Some of the metadata of
+@var{file} is part of the archive; for instance, when @var{file} is a
 regular file, the hash is different depending on whether @var{file} is
-executable or not.  Meta-data such as time stamps has no impact on the
+executable or not.  Metadata such as time stamps has no impact on the
 hash (@pxref{Invoking guix archive}).
 @c FIXME: Replace xref above with xref to an ``Archive'' section when
 @c it exists.
@@ -4290,10 +4293,10 @@ hash (@pxref{Invoking guix archive}).
 @cindex importing packages
 @cindex package import
 @cindex package conversion
-The @command{guix import} command is useful for people willing to add a
-package to the distribution but who'd rather do as little work as
-possible to get there---a legitimate demand.  The command knows of a few
-repositories from which it can ``import'' package meta-data.  The result
+The @command{guix import} command is useful for people who would like to
+add a package to the distribution with as little work as
+possible---a legitimate demand.  The command knows of a few
+repositories from which it can ``import'' package metadata.  The result
 is a package definition, or a template thereof, in the format we know
 (@pxref{Defining Packages}).
 
@@ -4304,17 +4307,17 @@ guix import @var{importer} @var{options}@dots{}
 @end example
 
 @var{importer} specifies the source from which to import package
-meta-data, and @var{options} specifies a package identifier and other
+metadata, and @var{options} specifies a package identifier and other
 options specific to @var{importer}.  Currently, the available
 ``importers'' are:
 
 @table @code
 @item gnu
-Import meta-data for the given GNU package.  This provides a template
+Import metadata for the given GNU package.  This provides a template
 for the latest version of that GNU package, including the hash of its
 source tarball, and its canonical synopsis and description.
 
-Additional information such as the package's dependencies and its
+Additional information such as the package dependencies and its
 license needs to be figured out manually.
 
 For example, the following command returns a package definition for
@@ -4329,19 +4332,19 @@ Specific command-line options are:
 @table @code
 @item --key-download=@var{policy}
 As for @code{guix refresh}, specify the policy to handle missing OpenPGP
-keys when verifying the package's signature.  @xref{Invoking guix
+keys when verifying the package signature.  @xref{Invoking guix
 refresh, @code{--key-download}}.
 @end table
 
 @item pypi
 @cindex pypi
-Import meta-data from the @uref{https://pypi.python.org/, Python Package
+Import metadata from the @uref{https://pypi.python.org/, Python Package
 Index}@footnote{This functionality requires Guile-JSON to be installed.
 @xref{Requirements}.}.  Information is taken from the JSON-formatted
 description available at @code{pypi.python.org} and usually includes all
 the relevant information, including package dependencies.
 
-The command below imports meta-data for the @code{itsdangerous} Python
+The command below imports metadata for the @code{itsdangerous} Python
 package:
 
 @example
@@ -4350,18 +4353,18 @@ guix import pypi itsdangerous
 
 @item gem
 @cindex gem
-Import meta-data from @uref{https://rubygems.org/,
+Import metadata from @uref{https://rubygems.org/,
 RubyGems}@footnote{This functionality requires Guile-JSON to be
 installed.  @xref{Requirements}.}.  Information is taken from the
 JSON-formatted description available at @code{rubygems.org} and includes
 most relevant information, including runtime dependencies.  There are
-some caveats, however.  The meta-data doesn't distinguish between
+some caveats, however.  The metadata doesn't distinguish between
 synopses and descriptions, so the same string is used for both fields.
 Additionally, the details of non-Ruby dependencies required to build
 native extensions is unavailable and left as an exercise to the
 packager.
 
-The command below imports meta-data for the @code{rails} Ruby package:
+The command below imports metadata for the @code{rails} Ruby package:
 
 @example
 guix import gem rails
@@ -4369,15 +4372,15 @@ guix import gem rails
 
 @item cpan
 @cindex CPAN
-Import meta-data from @uref{https://www.metacpan.org/, MetaCPAN}.
-Information is taken from the JSON-formatted meta-data provided through
+Import metadata from @uref{https://www.metacpan.org/, MetaCPAN}.
+Information is taken from the JSON-formatted metadata provided through
 @uref{https://api.metacpan.org/, MetaCPAN's API} and includes most
 relevant information, such as module dependencies.  License information
 should be checked closely.  If Perl is available in the store, then the
 @code{corelist} utility will be used to filter core modules out of the
 list of dependencies.
 
-The command command below imports meta-data for the @code{Acme::Boolean}
+The command command below imports metadata for the @code{Acme::Boolean}
 Perl module:
 
 @example
@@ -4387,28 +4390,28 @@ guix import cpan Acme::Boolean
 @item cran
 @cindex CRAN
 @cindex Bioconductor
-Import meta-data from @uref{http://cran.r-project.org/, CRAN}, the
+Import metadata from @uref{http://cran.r-project.org/, CRAN}, the
 central repository for the @uref{http://r-project.org, GNU@tie{}R
 statistical and graphical environment}.
 
-Information is extracted from the package's @code{DESCRIPTION} file.
+Information is extracted from the @code{DESCRIPTION} file of the package.
 
-The command command below imports meta-data for the @code{Cairo}
+The command command below imports metadata for the @code{Cairo}
 R package:
 
 @example
 guix import cran Cairo
 @end example
 
-When @code{--archive=bioconductor} is added, meta-data is imported from
+When @code{--archive=bioconductor} is added, metadata is imported from
 @uref{http://www.bioconductor.org/, Bioconductor}, a repository of R
 packages for for the analysis and comprehension of high-throughput
 genomic data in bioinformatics.
 
-Information is extracted from a package's @code{DESCRIPTION} file
+Information is extracted from the @code{DESCRIPTION} file of a package
 published on the web interface of the Bioconductor SVN repository.
 
-The command command below imports meta-data for the @code{GenomicRanges}
+The command below imports metadata for the @code{GenomicRanges}
 R package:
 
 @example
@@ -4416,7 +4419,7 @@ guix import cran --archive=bioconductor GenomicRanges
 @end example
 
 @item nix
-Import meta-data from a local copy of the source of the
+Import metadata from a local copy of the source of the
 @uref{http://nixos.org/nixpkgs/, Nixpkgs distribution}@footnote{This
 relies on the @command{nix-instantiate} command of
 @uref{http://nixos.org/nix/, Nix}.}.  Package definitions in Nixpkgs are
@@ -4447,7 +4450,7 @@ guix import nix ~/path/to/nixpkgs libreoffice
 
 @item hackage
 @cindex hackage
-Import meta-data from Haskell community's central package archive
+Import metadata from the Haskell community's central package archive
 @uref{https://hackage.haskell.org/, Hackage}.  Information is taken from
 Cabal files and includes all the relevant information, including package
 dependencies.
@@ -4457,10 +4460,10 @@ Specific command-line options are:
 @table @code
 @item --stdin
 @itemx -s
-Read a Cabal file from the standard input.
+Read a Cabal file from standard input.
 @item --no-test-dependencies
 @itemx -t
-Do not include dependencies required by the test suites only.
+Do not include dependencies required only by the test suites.
 @item --cabal-environment=@var{alist}
 @itemx -e @var{alist}
 @var{alist} is a Scheme alist defining the environment in which the
@@ -4470,10 +4473,10 @@ The value associated with a flag has to be either the symbol
 @code{true} or @code{false}.  The value associated with other keys
 has to conform to the Cabal file format definition.  The default value
 associated with the keys @code{os}, @code{arch} and @code{impl} is
-@samp{linux}, @samp{x86_64} and @samp{ghc} respectively.
+@samp{linux}, @samp{x86_64} and @samp{ghc}, respectively.
 @end table
 
-The command below imports meta-data for the latest version of the
+The command below imports metadata for the latest version of the
 @code{HTTP} Haskell package without including test dependencies and
 specifying the value of the flag @samp{network-uri} as @code{false}:
 
@@ -4490,7 +4493,7 @@ guix import hackage mtl-2.1.3.1
 
 @item elpa
 @cindex elpa
-Import meta-data from an Emacs Lisp Package Archive (ELPA) package
+Import metadata from an Emacs Lisp Package Archive (ELPA) package
 repository (@pxref{Packages,,, emacs, The GNU Emacs Manual}).
 
 Specific command-line options are:
@@ -4535,8 +4538,8 @@ gnu/packages/gettext.scm:29:13: gettext would be upgraded from 0.18.1.1 to 0.18.
 gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0
 @end example
 
-It does so by browsing each package's FTP directory and determining the
-highest version number of the source tarballs therein.  The command
+It does so by browsing the FTP directory of each package and determining
+the highest version number of the source tarballs therein.  The command
 knows how to update specific types of packages: GNU packages, ELPA
 packages, etc.---see the documentation for @option{--type} below.  The
 are many packages, though, for which it lacks a method to determine
@@ -4544,14 +4547,14 @@ whether a new upstream release is available.  However, the mechanism is
 extensible, so feel free to get in touch with us to add a new method!
 
 When passed @code{--update}, it modifies distribution source files to
-update the version numbers and source tarball hashes of those packages'
+update the version numbers and source tarball hashes of those package
 recipes (@pxref{Defining Packages}).  This is achieved by downloading
 each package's latest source tarball and its associated OpenPGP
 signature, authenticating the downloaded tarball against its signature
 using @command{gpg}, and finally computing its hash.  When the public
 key used to sign the tarball is missing from the user's keyring, an
 attempt is made to automatically retrieve it from a public key server;
-when it's successful, the key is added to the user's keyring; otherwise,
+when this is successful, the key is added to the user's keyring; otherwise,
 @command{guix refresh} reports an error.
 
 The following options are supported:
@@ -4619,8 +4622,8 @@ the updater for @uref{http://www.bioconductor.org/, Bioconductor} R packages;
 the updater for @uref{https://pypi.python.org, PyPI} packages.
 @end table
 
-For instance, the following commands only checks for updates of Emacs
-packages hosted at @code{elpa.gnu.org} and updates of CRAN packages:
+For instance, the following command only checks for updates of Emacs
+packages hosted at @code{elpa.gnu.org} and for updates of CRAN packages:
 
 @example
 $ guix refresh --type=elpa,cran
@@ -4705,9 +4708,9 @@ Use @var{host} as the OpenPGP key server when importing a public key.
 
 @node Invoking guix lint
 @section Invoking @command{guix lint}
-The @command{guix lint} is meant to help package developers avoid common
-errors and use a consistent style.  It runs a number of checks on a
-given set of packages in order to find common mistakes in their
+The @command{guix lint} command is meant to help package developers avoid
+common errors and use a consistent style.  It runs a number of checks on
+a given set of packages in order to find common mistakes in their
 definitions.  Available @dfn{checkers} include (see
 @code{--list-checkers} for a complete list):
 
@@ -4725,8 +4728,8 @@ Identify inputs that should most likely be native inputs.
 @itemx source-file-name
 Probe @code{home-page} and @code{source} URLs and report those that are
 invalid.  Check that the source file name is meaningful, e.g. is not
-just a version number or ``git-checkout'', and should not have a
-@code{file-name} declared (@pxref{origin Reference}).
+just a version number or ``git-checkout'', without a declared
+@code{file-name} (@pxref{origin Reference}).
 
 @item cve
 Report known vulnerabilities found in the Common Vulnerabilities and
@@ -4749,17 +4752,16 @@ If no package is given on the command line, then all packages are checked.
 The @var{options} may be zero or more of the following:
 
 @table @code
+@item --list-checkers
+@itemx -l
+List and describe all the available checkers that will be run on packages
+and exit.
 
 @item --checkers
 @itemx -c
 Only enable the checkers specified in a comma-separated list using the
 names returned by @code{--list-checkers}.
 
-@item --list-checkers
-@itemx -l
-List and describe all the available checkers that will be run on packages
-and exit.
-
 @end table
 
 @node Invoking guix size
@@ -4769,7 +4771,7 @@ The @command{guix size} command helps package developers profile the
 disk usage of packages.  It is easy to overlook the impact of an
 additional dependency added to a package, or the impact of using a
 single output for a package that could easily be split (@pxref{Packages
-with Multiple Outputs}).  These are the typical issues that
+with Multiple Outputs}).  Such are the typical issues that
 @command{guix size} can highlight.
 
 The command can be passed a package specification such as @code{gcc-4.8}
@@ -4796,12 +4798,12 @@ would be returned by:
 $ guix gc -R /gnu/store/@dots{}-coreutils-8.23
 @end example
 
-Here the output shows 3 columns next to store items.  The first column,
+Here the output shows three columns next to store items.  The first column,
 labeled ``total'', shows the size in mebibytes (MiB) of the closure of
 the store item---that is, its own size plus the size of all its
 dependencies.  The next column, labeled ``self'', shows the size of the
-item itself.  The last column shows the ratio of the item's size to the
-space occupied by all the items listed here.
+item itself.  The last column shows the ratio of the size of the item
+itself to the space occupied by all the items listed here.
 
 In this example, we see that the closure of Coreutils weighs in at
 70@tie{}MiB, half of which is taken by libc.  (That libc represents a
@@ -4815,9 +4817,9 @@ dependencies, and measures its size in the store, similar to @command{du
 Coreutils}).
 
 When the given package is @emph{not} in the store, @command{guix size}
-reports information based on information about the available substitutes
-(@pxref{Substitutes}).  This allows it to profile disk usage of store
-items that are not even on disk, only available remotely.
+reports information based on the available substitutes
+(@pxref{Substitutes}).  This makes it possible it to profile disk usage of
+store items that are not even on disk, only available remotely.
 
 The available options are:
 
@@ -4828,7 +4830,7 @@ Use substitute information from @var{urls}.
 @xref{client-substitute-urls, the same option for @code{guix build}}.
 
 @item --map-file=@var{file}
-Write to @var{file} a graphical map of disk usage as a PNG file.
+Write a graphical map of disk usage in PNG format to @var{file}.
 
 For the example above, the map looks like this:
 
@@ -4852,11 +4854,11 @@ Consider packages for @var{system}---e.g., @code{x86_64-linux}.
 @cindex DAG
 Packages and their dependencies form a @dfn{graph}, specifically a
 directed acyclic graph (DAG).  It can quickly become difficult to have a
-mental model of the package DAG, so the @command{guix graph} command is
-here to provide a visual representation of the DAG.  @command{guix
-graph} emits a DAG representation in the input format of
+mental model of the package DAG, so the @command{guix graph} command
+provides a visual representation of the DAG.  @command{guix graph}
+emits a DAG representation in the input format of
 @uref{http://www.graphviz.org/, Graphviz}, so its output can be passed
-directly to Graphviz's @command{dot} command, for instance.  The general
+directly to the @command{dot} command of Graphviz.  The general
 syntax is:
 
 @example
@@ -4877,15 +4879,15 @@ The output looks like this:
 
 Nice little graph, no?
 
-But there's more than one graph!  The one above is concise: it's the
+But there is more than one graph!  The one above is concise: it is the
 graph of package objects, omitting implicit inputs such as GCC, libc,
-grep, etc.  It's often useful to have such a concise graph, but
-sometimes you want to see more details.  @command{guix graph} supports
-several types of graphs, allowing you to choose the level of details:
+grep, etc.  It is often useful to have such a concise graph, but
+sometimes one may want to see more details.  @command{guix graph} supports
+several types of graphs, allowing you to choose the level of detail:
 
 @table @code
 @item package
-This is the default type, the one we used above.  It shows the DAG of
+This is the default type used in the example above.  It shows the DAG of
 package objects, excluding implicit dependencies.  It is concise, but
 filters out many details.
 
@@ -4905,7 +4907,7 @@ guix graph --type=bag-emerged coreutils | dot -Tpdf > dag.pdf
 At the bottom of the graph, we see all the implicit inputs of
 @var{gnu-build-system} (@pxref{Build Systems, @code{gnu-build-system}}).
 
-Now, note that the dependencies of those implicit inputs---that is, the
+Now, note that the dependencies of these implicit inputs---that is, the
 @dfn{bootstrap dependencies} (@pxref{Bootstrapping})---are not shown
 here, for conciseness.
 
@@ -4920,11 +4922,11 @@ Similar to @code{bag}, but also showing origins and their dependencies.
 This is the most detailed representation: It shows the DAG of
 derivations (@pxref{Derivations}) and plain store items.  Compared to
 the above representation, many additional nodes are visible, including
-builds scripts, patches, Guile modules, etc.
+build scripts, patches, Guile modules, etc.
 
 @end table
 
-All the above types correspond to @emph{build-time dependencies}.  The
+All the types above correspond to @emph{build-time dependencies}.  The
 following graph type represents the @emph{run-time dependencies}:
 
 @table @code
@@ -4967,7 +4969,7 @@ guix graph -e '(@@@@ (gnu packages commencement) gnu-make-final)'
 The purpose of @command{guix environment} is to assist hackers in
 creating reproducible development environments without polluting their
 package profile.  The @command{guix environment} tool takes one or more
-packages, builds all of the necessary inputs, and creates a shell
+packages, builds all of their inputs, and creates a shell
 environment to use them.
 
 The general syntax is:
@@ -4983,12 +4985,12 @@ GNU@tie{}Guile:
 guix environment guile
 @end example
 
-If the specified packages are not built yet, @command{guix environment}
-automatically builds them.  The new shell's environment is an augmented
+If the needed dependencies are not built yet, @command{guix environment}
+automatically builds them.  The environment of the new shell is an augmented
 version of the environment that @command{guix environment} was run in.
 It contains the necessary search paths for building the given package
 added to the existing environment variables.  To create a ``pure''
-environment in which the original environment variables have been unset,
+environment, in which the original environment variables have been unset,
 use the @code{--pure} option@footnote{Users sometimes wrongfully augment
 environment variables such as @code{PATH} in their @file{~/.bashrc}
 file.  As a consequence, when @code{guix environment} launches it, Bash
@@ -5001,7 +5003,7 @@ details on Bash start-up files.}.
 
 @vindex GUIX_ENVIRONMENT
 @command{guix environment} defines the @code{GUIX_ENVIRONMENT}
-variable in the shell it spaws.  This allows users to, say, define a
+variable in the shell it spawns.  This allows users to, say, define a
 specific prompt for development environments in their @file{.bashrc}
 (@pxref{Bash Startup Files,,, bash, The GNU Bash Reference Manual}):
 
@@ -5128,7 +5130,7 @@ runs @command{guile} in an environment where Guile and Guile-SDL are
 available.
 
 Note that this example implicitly asks for the default output of
-@code{guile} and @code{guile-sdl} but it is possible to ask for a
+@code{guile} and @code{guile-sdl}, but it is possible to ask for a
 specific output---e.g., @code{glib:bin} asks for the @code{bin} output
 of @code{glib} (@pxref{Packages with Multiple Outputs}).
 
@@ -5202,7 +5204,7 @@ build} supports (@pxref{Common Build Options}).
 @section Invoking @command{guix publish}
 
 The purpose of @command{guix publish} is to enable users to easily share
-their store with others, which can then use it as a substitute server
+their store with others, who can then use it as a substitute server
 (@pxref{Substitutes}).
 
 When @command{guix publish} runs, it spawns an HTTP server which allows
@@ -5213,7 +5215,7 @@ the @code{hydra.gnu.org} build farm.
 
 For security, each substitute is signed, allowing recipients to check
 their authenticity and integrity (@pxref{Substitutes}).  Because
-@command{guix publish} uses the system's signing key, which is only
+@command{guix publish} uses the signing key of the system, which is only
 readable by the system administrator, it must be started as root; the
 @code{--user} option makes it drop root privileges early on.
 
@@ -5277,12 +5279,12 @@ of the @code{operating-system} declaration (@pxref{guix-publish-service,
 @cindex verifiable builds
 
 Do the binaries provided by this server really correspond to the source
-code it claims to build?  Is this package's build process deterministic?
+code it claims to build?  Is a package build process deterministic?
 These are the questions the @command{guix challenge} command attempts to
 answer.
 
 The former is obviously an important question: Before using a substitute
-server (@pxref{Substitutes}), you'd rather @emph{verify} that it
+server (@pxref{Substitutes}), one had better @emph{verify} that it
 provides the right binaries, and thus @emph{challenge} it.  The latter
 is what enables the former: If package builds are deterministic, then
 independent builds of the package should yield the exact same result,
@@ -5298,7 +5300,7 @@ one store file name should map to exactly one build output.
 mapping by comparing the build outputs of several independent builds of
 any given store item.
 
-The command's output looks like this:
+The command output looks like this:
 
 @smallexample
 $ guix challenge --substitute-urls="http://hydra.gnu.org http://guix.example.org"
@@ -5337,7 +5339,7 @@ results, the inclusion of random numbers, and directory listings sorted
 by inode number.  See @uref{http://reproducible.debian.net/howto/}, for
 more information.
 
-To find out what's wrong with this Git binary, we can do something along
+To find out what is wrong with this Git binary, we can do something along
 these lines (@pxref{Invoking guix archive}):
 
 @example
@@ -5354,11 +5356,11 @@ works great for text files.  When binary files differ, a better option
 is @uref{http://diffoscope.org/, Diffoscope}, a tool that helps
 visualize differences for all kinds of files.
 
-Once you've done that work, you can tell whether the differences are due
+Once you have done that work, you can tell whether the differences are due
 to a non-deterministic build process or to a malicious server.  We try
 hard to remove sources of non-determinism in packages to make it easier
-to verify substitutes, but of course, this is a process, one that
-involves not just Guix but a large part of the free software community.
+to verify substitutes, but of course, this is a process that
+involves not just Guix, but a large part of the free software community.
 In the meantime, @command{guix challenge} is one tool to help address
 the problem.
 
@@ -5371,7 +5373,7 @@ $ guix challenge @var{package}
 @end example
 
 @noindent
-... where @var{package} is a package specification such as
+where @var{package} is a package specification such as
 @code{guile-2.0} or @code{glibc:debug}.
 
 The general syntax is:
@@ -5428,9 +5430,9 @@ guix container exec @var{pid} @var{program} @var{arguments}@dots{}
 @end example
 
 @var{pid} specifies the process ID of the running container.
-@var{program} specifies an executable file name within the container's
-root file system.  @var{arguments} are the additional options that will
-be passed to @var{program}.
+@var{program} specifies an executable file name within the root file
+system of the container.  @var{arguments} are the additional options that
+will be passed to @var{program}.
 
 The following command launches an interactive login shell inside a
 GuixSD container, started by @command{guix system container}, and whose
@@ -5441,7 +5443,7 @@ guix container exec 9001 /run/current-system/profile/bin/bash --login
 @end example
 
 Note that the @var{pid} cannot be the parent process of a container.  It
-must be the container's PID 1 or one of its child processes.
+must be PID 1 of the container or one of its child processes.
 
 @end table
 
@@ -5471,7 +5473,7 @@ running @command{guix package} (@pxref{Invoking guix package}):
 guix package --list-available
 @end example
 
-Our goal has been to provide a practical 100% free software distribution of
+Our goal is to provide a practical 100% free software distribution of
 Linux-based and other variants of GNU, with a focus on the promotion and
 tight integration of GNU components, and an emphasis on programs and
 tools that help users exert that freedom.
@@ -5488,11 +5490,12 @@ Intel 32-bit architecture (IA32), Linux-Libre kernel;
 
 @item armhf-linux
 ARMv7-A architecture with hard float, Thumb-2 and NEON,
-using the EABI hard-float ABI, and Linux-Libre kernel.
+using the EABI hard-float application binary interface (ABI),
+and Linux-Libre kernel.
 
 @item mips64el-linux
 little-endian 64-bit MIPS processors, specifically the Loongson series,
-n32 application binary interface (ABI), and Linux-Libre kernel.
+n32 ABI, and Linux-Libre kernel.
 
 @end table
 
@@ -5500,7 +5503,7 @@ GuixSD itself is currently only available on @code{i686} and @code{x86_64}.
 
 @noindent
 For information on porting to other architectures or kernels,
-@xref{Porting}.
+@pxref{Porting}.
 
 @menu
 * System Installation::         Installing the whole operating system.
@@ -5550,7 +5553,7 @@ not production-ready.  It may contain bugs and lack important
 features.  Thus, if you are looking for a stable production system that
 respects your freedom as a computer user, a good solution at this point
 is to consider @url{http://www.gnu.org/distros/free-distros.html, one of
-more established GNU/Linux distributions}.  We hope you can soon switch
+the more established GNU/Linux distributions}.  We hope you can soon switch
 to the GuixSD without fear, of course.  In the meantime, you can
 also keep using your distribution and try out the package manager on top
 of it (@pxref{Installation}).
@@ -5566,7 +5569,7 @@ get a feel of what that means.)
 
 @item
 The system does not yet provide full GNOME and KDE desktops.  Xfce and
-Enlightenment are available though, if graphical desktop environments
+Enlightenment are available, though, if graphical desktop environments
 are your thing, as well as a number of X11 window managers.
 
 @item
@@ -5581,8 +5584,8 @@ More than 3,000 packages are available, but you may
 occasionally find that a useful package is missing.
 @end itemize
 
-You've been warned.  But more than a disclaimer, this is an invitation
-to report issues (and success stories!), and join us in improving it.
+You have been warned!  But more than a disclaimer, this is an invitation
+to report issues (and success stories!), and to join us in improving it.
 @xref{Contributing}, for more info.
 
 @node USB Stick Installation
@@ -5615,8 +5618,8 @@ xz -d guixsd-usb-install-@value{VERSION}.@var{system}.xz
 @end example
 
 @item
-Insert a USB stick of 1@tie{}GiB or more in your machine, and determine
-its device name.  Assuming that USB stick is known as @file{/dev/sdX},
+Insert a USB stick of 1@tie{}GiB or more into your machine, and determine
+its device name.  Assuming that the USB stick is known as @file{/dev/sdX},
 copy the image with:
 
 @example
@@ -10263,7 +10266,7 @@ Free software packages are usually distributed in the form of
 all the source files.  Adding a package to the distribution means
 essentially two things: adding a @dfn{recipe} that describes how to
 build the package, including a list of other packages required to build
-it, and adding @dfn{package meta-data} along with that recipe, such as a
+it, and adding @dfn{package metadata} along with that recipe, such as a
 description and licensing information.
 
 In Guix all this information is embodied in @dfn{package definitions}.