nixpkgs docs: normalize

+16 -15
doc/functions.xml
···
<callout arearefs='ex-dockerTools-buildImage-2'>
<para>
<varname>tag</varname> specifies the tag of the resulting image. By
-
default it's <literal>null</literal>, which indicates that the nix output hash will be used as tag.
+
default it's <literal>null</literal>, which indicates that the nix output
+
hash will be used as tag.
</para>
</callout>
<callout arearefs='ex-dockerTools-buildImage-3'>
···
<para>
<varname>imageDigest</varname> specifies the digest of the image to be
downloaded. Skopeo can be used to get the digest of an image, with its
-
<varname>inspect</varname> subcommand. Since a given <varname>imageName</varname>
-
may transparently refer to a manifest list of images which support
-
multiple architectures and/or operating systems, supply the `--override-os`
-
and `--override-arch` arguments to specify exactly which image you
-
want. By default it will match the OS and architecture of the host the
-
command is run on.
+
<varname>inspect</varname> subcommand. Since a given
+
<varname>imageName</varname> may transparently refer to a manifest list
+
of images which support multiple architectures and/or operating systems,
+
supply the `--override-os` and `--override-arch` arguments to specify
+
exactly which image you want. By default it will match the OS and
+
architecture of the host the command is run on.
<programlisting>
$ nix-shell --packages skopeo jq --command "skopeo --override-os linux --override-arch x86_64 inspect docker://docker.io/nixos/nix:1.11 | jq -r '.Digest'"
sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
···
</para>
</callout>
<callout arearefs='ex-dockerTools-pullImage-5'>
-
<para>
-
<varname>os</varname>, if specified, is the operating system of the fetched image.
-
By default it's <literal>linux</literal>.
-
</para>
+
<para>
+
<varname>os</varname>, if specified, is the operating system of the
+
fetched image. By default it's <literal>linux</literal>.
+
</para>
</callout>
<callout arearefs='ex-dockerTools-pullImage-6'>
-
<para>
-
<varname>arch</varname>, if specified, is the cpu architecture of the fetched image.
-
By default it's <literal>x86_64</literal>.
-
</para>
+
<para>
+
<varname>arch</varname>, if specified, is the cpu architecture of the
+
fetched image. By default it's <literal>x86_64</literal>.
+
</para>
</callout>
</calloutlist>
</section>
+11 -13
doc/languages-frameworks/java.xml
···
}
</programlisting>
Note that <varname>jdk</varname> is an alias for the OpenJDK (self-built
-
where available, or pre-built via Zulu).
-
Platforms with OpenJDK not (yet) in Nixpkgs (<literal>Aarch32</literal>,
-
<literal>Aarch64</literal>) point to the (unfree)
-
<literal>oraclejdk</literal>.
-
</para>
+
where available, or pre-built via Zulu). Platforms with OpenJDK not (yet) in
+
Nixpkgs (<literal>Aarch32</literal>, <literal>Aarch64</literal>) point to the
+
(unfree) <literal>oraclejdk</literal>.
+
</para>
<para>
JAR files that are intended to be used by other packages should be installed
-
in <filename>$out/share/java</filename>. JDKs have a stdenv setup hook
-
that add any JARs in the <filename>share/java</filename> directories of the
-
build inputs to the <envar>CLASSPATH</envar> environment variable. For
-
instance, if the package <literal>libfoo</literal> installs a JAR named
+
in <filename>$out/share/java</filename>. JDKs have a stdenv setup hook that
+
add any JARs in the <filename>share/java</filename> directories of the build
+
inputs to the <envar>CLASSPATH</envar> environment variable. For instance, if
+
the package <literal>libfoo</literal> installs a JAR named
<filename>foo.jar</filename> in its <filename>share/java</filename>
directory, and another package declares the attribute
<programlisting>
···
<literal>${jre}/bin/java</literal> instead of
<literal>${jdk}/bin/java</literal>, you prevent your package from depending
on the JDK at runtime.
-
</para>
+
</para>
-
<para>
+
<para>
Note all JDKs passthru <literal>home</literal>, so if your application
requires environment variables like <envar>JAVA_HOME</envar> being set, that
can be done in a generic fashion with the <literal>--set</literal> argument
of <literal>makeWrapper</literal>:
-
<programlisting>
--set JAVA_HOME ${jdk.home}
</programlisting>
-
</para>
+
</para>
<para>
It is possible to use a different Java compiler than <command>javac</command>
+29 -19
doc/package-notes.xml
···
<title>Citrix Receiver</title>
<para>
-
The <link xlink:href="https://www.citrix.com/products/receiver/">Citrix Receiver</link> is a remote
-
desktop viewer which provides access to
-
<link xlink:href="https://www.citrix.com/products/xenapp-xendesktop/">XenDesktop</link> installations.
+
The <link xlink:href="https://www.citrix.com/products/receiver/">Citrix
+
Receiver</link> is a remote desktop viewer which provides access to
+
<link xlink:href="https://www.citrix.com/products/xenapp-xendesktop/">XenDesktop</link>
+
installations.
</para>
<section xml:id="sec-citrix-base">
<title>Basic usage</title>
+
<para>
-
The tarball archive needs to be downloaded manually as the licenses agreements of the vendor
-
need to be accepted first. This is available at the
-
<link xlink:href="https://www.citrix.com/downloads/citrix-receiver/">download page at citrix.com</link>.
-
Then run <literal>nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz</literal>.
-
With the archive available in the store the package can be built and installed with Nix.
+
The tarball archive needs to be downloaded manually as the licenses
+
agreements of the vendor need to be accepted first. This is available at
+
the
+
<link xlink:href="https://www.citrix.com/downloads/citrix-receiver/">download
+
page at citrix.com</link>. Then run <literal>nix-prefetch-url
+
file://$PWD/linuxx64-$version.tar.gz</literal>. With the archive available
+
in the store the package can be built and installed with Nix.
</para>
<para>
-
<emphasis>Note: it's recommended to install <literal>Citrix Receiver</literal> using
-
<literal>nix-env -i</literal> or globally to ensure that the <literal>.desktop</literal> files
-
are installed properly into <literal>$XDG_CONFIG_DIRS</literal>. Otherwise it won't
-
be possible to open <literal>.ica</literal> files
-
automatically from the browser to start a Citrix connection.</emphasis>
+
<emphasis>Note: it's recommended to install <literal>Citrix
+
Receiver</literal> using <literal>nix-env -i</literal> or globally to
+
ensure that the <literal>.desktop</literal> files are installed properly
+
into <literal>$XDG_CONFIG_DIRS</literal>. Otherwise it won't be possible to
+
open <literal>.ica</literal> files automatically from the browser to start
+
a Citrix connection.</emphasis>
</para>
</section>
+
<section xml:id="sec-citrix-custom-certs">
<title>Custom certificates</title>
+
<para>
-
The <literal>Citrix Receiver</literal> in <literal>nixpkgs</literal> trusts several certificates
-
<link xlink:href="https://curl.haxx.se/docs/caextract.html">from the Mozilla database</link> by default.
-
However several companies using Citrix might require their own corporate certificate. On distros with imperative
+
The <literal>Citrix Receiver</literal> in <literal>nixpkgs</literal> trusts
+
several certificates
+
<link xlink:href="https://curl.haxx.se/docs/caextract.html">from the
+
Mozilla database</link> by default. However several companies using Citrix
+
might require their own corporate certificate. On distros with imperative
packaging these certs can be stored easily in
<link xlink:href="https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/"><literal>$ICAROOT</literal></link>,
-
however this directory is a store path in <literal>nixpkgs</literal>. In order to work around this issue the package provides a simple
-
mechanism to add custom certificates without rebuilding the entire package using <literal>symlinkJoin</literal>:
-
+
however this directory is a store path in <literal>nixpkgs</literal>. In
+
order to work around this issue the package provides a simple mechanism to
+
add custom certificates without rebuilding the entire package using
+
<literal>symlinkJoin</literal>:
<programlisting>
<![CDATA[with import <nixpkgs> { config.allowUnfree = true; };
let extraCerts = [ ./custom-cert-1.pem ./custom-cert-2.pem /* ... */ ]; in
+3 -5
doc/platform-notes.xml
···
}
</programlisting>
</listitem>
-
<listitem>
<para>
On darwin libraries are linked using absolute paths, libraries are
···
}
</programlisting>
</listitem>
-
<listitem>
<para>
Even if the libraries are linked using absolute paths and resolved via
their <literal>install_name</literal> correctly, tests can sometimes fail
-
to run binaries. This happens because the <varname>checkPhase</varname>
+
to run binaries. This happens because the <varname>checkPhase</varname>
runs before the libraries are installed.
</para>
<para>
This can usually be solved by running the tests after the
<varname>installPhase</varname> or alternatively by using
<varname>DYLD_LIBRARY_PATH</varname>. More information about this variable
-
can be found in the <citerefentry><refentrytitle>dyld</refentrytitle>
+
can be found in the <citerefentry>
+
<refentrytitle>dyld</refentrytitle>
<manvolnum>1</manvolnum></citerefentry> manpage.
</para>
<programlisting>
···
}
</programlisting>
</listitem>
-
<listitem>
<para>
Some packages assume xcode is available and use <command>xcrun</command>
+21 -18
doc/reviewing-contributions.xml
···
<title>Reviewing contributions</title>
<warning>
<para>
-
The following section is a draft, and the policy for reviewing is still being
-
discussed in issues such as <link
+
The following section is a draft, and the policy for reviewing is still
+
being discussed in issues such as
+
<link
xlink:href="https://github.com/NixOS/nixpkgs/issues/11166">#11166
-
</link> and <link
+
</link> and
+
<link
xlink:href="https://github.com/NixOS/nixpkgs/issues/20836">#20836
</link>.
</para>
</warning>
<para>
-
The nixpkgs project receives a fairly high number of contributions via
-
GitHub pull-requests. Reviewing and approving these is an important task and
-
a way to contribute to the project.
+
The nixpkgs project receives a fairly high number of contributions via GitHub
+
pull-requests. Reviewing and approving these is an important task and a way
+
to contribute to the project.
</para>
<para>
The high change rate of nixpkgs makes any pull request that remains open for
···
to respect every community member and their work.
</para>
<para>
-
GitHub provides reactions as a simple and quick way to provide
-
feedback to pull-requests or any comments. The thumb-down reaction should be
-
used with care and if possible accompanied with some explanation so the
-
submitter has directions to improve their contribution.
+
GitHub provides reactions as a simple and quick way to provide feedback to
+
pull-requests or any comments. The thumb-down reaction should be used with
+
care and if possible accompanied with some explanation so the submitter has
+
directions to improve their contribution.
</para>
<para>
Pull-request reviews should include a list of what has been reviewed in a
···
<itemizedlist>
<listitem>
<para>
-
License can change with version updates, so it should be checked to match
-
the upstream license.
+
License can change with version updates, so it should be checked to
+
match the upstream license.
</para>
</listitem>
<listitem>
···
<listitem>
<para>
Pull-requests are often targeted to the master or staging branch, and
-
building the pull-request locally when it is submitted can trigger
-
many source builds.
+
building the pull-request locally when it is submitted can trigger many
+
source builds.
</para>
<para>
It is possible to rebase the changes on nixos-unstable or
···
-->
<para>
-
In a case a contributor leaves definitively the Nix community, he
-
should create an issue or post on <link
+
In a case a contributor leaves definitively the Nix community, he should
+
create an issue or post on
+
<link
xlink:href="https://discourse.nixos.org">Discourse</link> with
-
references of packages and modules he maintains so the
-
maintainership can be taken over by other contributors.
+
references of packages and modules he maintains so the maintainership can be
+
taken over by other contributors.
</para>
</section>
</chapter>