alioth/nixpkgs
3
0
Fork 0
forked from mirrors/nixpkgs
Code Releases Activity

doc: Improve code listings

Browse source 
By adding prompts and removing unnecessary indentation.
This commit is contained in:
Jan Tojnar 2020-09-23 00:38:04 +02:00
parent 47297487c5
commit e1af37634b
No known key found for this signature in database
GPG key ID: 7FAB2A15F7A607A4
13 changed files with 173 additions and 161 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
doc/builders/images/dockertools.xml
View file

@ -132,11 +132,11 @@ buildImage {
<para>
By default <function>buildImage</function> will use a static date of one second past the UNIX Epoch. This allows <function>buildImage</function> to produce binary reproducible images. When listing images with <command>docker images</command>, the newly created images will be listed like this:
</para>
<screen><![CDATA[
$ docker images
<screen>
<prompt>$ </prompt>docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
hello latest 08c791c7846e 48 years ago 25.2MB
]]></screen>
</screen>
<para>
You can break binary reproducibility but have a sorted, meaningful <literal>CREATED</literal> column by setting <literal>created</literal> to <literal>now</literal>.
</para>
@ -152,11 +152,11 @@ pkgs.dockerTools.buildImage {
]]></programlisting>
<para>
and now the Docker CLI will display a reasonable date and sort the images as expected:
<screen><![CDATA[
$ docker images
<screen>
<prompt>$ </prompt>docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
hello latest de2bf4786de6 About a minute ago 25.2MB
]]></screen>
</screen>
however, the produced images will not be binary reproducible.
</para>
</example>

3
doc/builders/images/ocitools.xml
View file

@ -38,8 +38,7 @@ buildContainer {
readonly = false; <co xml:id='ex-ociTools-buildContainer-3' />
}
</programlisting>
</programlisting>
<calloutlist>
<callout arearefs='ex-ociTools-buildContainer-1'>
<para>

8
doc/builders/packages/citrix.xml
View file

@ -22,10 +22,10 @@
</para>
<para>
In order to set this up, you first have to <link xlink:href="https://its.uiowa.edu/support/article/102186">download the <literal>.cr</literal> file from the Netscaler Gateway</link>. After that you can configure the <command>selfservice</command> like this:
<screen>
<prompt>$ </prompt>storebrowse -C ~/Downloads/receiverconfig.cr
<prompt>$ </prompt>selfservice
</screen>
<screen>
<prompt>$ </prompt>storebrowse -C ~/Downloads/receiverconfig.cr
<prompt>$ </prompt>selfservice
</screen>
</para>
</section>

50
doc/builders/packages/urxvt.xml
View file

@ -18,10 +18,13 @@
includes all available plugins. To make use of this functionality, use an
overlay or directly install an expression that overrides its configuration,
such as
<programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {
<programlisting>
rxvt-unicode.override {
configure = { availablePlugins, ... }: {
plugins = with availablePlugins; [ perls resize-font vtwheel ];
}
}</programlisting>
};
}
</programlisting>
If the <literal>configure</literal> function returns an attrset without the
<literal>plugins</literal> attribute, <literal>availablePlugins</literal>
will be used automatically.
@ -30,18 +33,22 @@
<para>
In order to add plugins but also keep all default plugins installed, it is
possible to use the following method:
<programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {
plugins = (builtins.attrValues availablePlugins) ++ [ custom-plugin ];
};
}</programlisting>
<programlisting>
rxvt-unicode.override {
configure = { availablePlugins, ... }: {
plugins = (builtins.attrValues availablePlugins) ++ [ custom-plugin ];
};
}
</programlisting>
</para>
<para>
To get a list of all the plugins available, open the Nix REPL and run
<programlisting>$ nix repl
<screen>
<prompt>$ </prompt>nix repl
:l &lt;nixpkgs&gt;
map (p: p.name) pkgs.rxvt-unicode.plugins
</programlisting>
</screen>
Alternatively, if your shell is bash or zsh and have completion enabled,
simply type <literal>nixpkgs.rxvt-unicode.plugins.&lt;tab&gt;</literal>.
</para>
@ -53,18 +60,24 @@ map (p: p.name) pkgs.rxvt-unicode.plugins
<literal>extraDeps</literal> can be used, for example, to provide
<literal>xsel</literal> (a clipboard manager) to the clipboard plugin,
without installing it globally:
<programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {
pluginsDeps = [ xsel ];
}
}</programlisting>
<programlisting>
rxvt-unicode.override {
configure = { availablePlugins, ... }: {
pluginsDeps = [ xsel ];
};
}
</programlisting>
<literal>perlDeps</literal> is a handy way to provide Perl packages to
your custom plugins (in <literal>$HOME/.urxvt/ext</literal>). For example,
if you need <literal>AnyEvent</literal> you can do:
<programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {
perlDeps = with perlPackages; [ AnyEvent ];
}
}</programlisting>
<programlisting>
rxvt-unicode.override {
configure = { availablePlugins, ... }: {
perlDeps = with perlPackages; [ AnyEvent ];
};
}
</programlisting>
</para>
</section>
@ -90,7 +103,8 @@ map (p: p.name) pkgs.rxvt-unicode.plugins
<para>
If the plugin is itself a perl package that needs to be imported from
other plugins or scripts, add the following passthrough:
<programlisting>passthru.perlPackages = [ "self" ];
<programlisting>
passthru.perlPackages = [ "self" ];
</programlisting>
This will make the urxvt wrapper pick up the dependency and set up the perl
path accordingly.

12
doc/contributing/submitting-changes.xml
View file

@ -209,12 +209,12 @@ Additional information.
</para>
<programlisting>
(fetchpatch {
name = "CVE-2019-11068.patch";
url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
})
</programlisting>
(fetchpatch {
name = "CVE-2019-11068.patch";
url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
})
</programlisting>
<para>
If a security fix applies to both master and a stable release then, similar to regular changes, they are preferably delivered via master first and cherry-picked to the release branch.

6
doc/languages-frameworks/beam.xml
View file

@ -72,9 +72,9 @@
To install any of those builders into your profile, refer to them by their attribute path <literal>beamPackages.rebar3</literal>:
</para>
<screen>
<prompt>$ </prompt>nix-env -f &quot;&lt;nixpkgs&gt;&quot; -iA beamPackages.rebar3
</screen>
<screen>
<prompt>$ </prompt>nix-env -f &quot;&lt;nixpkgs&gt;&quot; -iA beamPackages.rebar3
</screen>
</section>
<section xml:id="packaging-beam-applications">

186
doc/languages-frameworks/perl.xml
View file

@ -8,28 +8,28 @@
<para>
When executing a Perl script, it is possible you get an error such as <literal>./myscript.pl: bad interpreter: /usr/bin/perl: no such file or directory</literal>. This happens when the script expects Perl to be installed at <filename>/usr/bin/perl</filename>, which is not the case when using Perl from nixpkgs. You can fix the script by changing the first line to:
<programlisting>
#!/usr/bin/env perl
</programlisting>
<programlisting>
#!/usr/bin/env perl
</programlisting>
to take the Perl installation from the <literal>PATH</literal> environment variable, or invoke Perl directly with:
<screen>
<prompt>$ </prompt>perl ./myscript.pl
</screen>
<screen>
<prompt>$ </prompt>perl ./myscript.pl
</screen>
</para>
<para>
When the script is using a Perl library that is not installed globally, you might get an error such as <literal>Can't locate DB_File.pm in @INC (you may need to install the DB_File module)</literal>. In that case, you can use <command>nix-shell</command> to start an ad-hoc shell with that library installed, for instance:
<screen>
<prompt>$ </prompt>nix-shell -p perl perlPackages.DBFile --run ./myscript.pl
</screen>
<screen>
<prompt>$ </prompt>nix-shell -p perl perlPackages.DBFile --run ./myscript.pl
</screen>
</para>
<para>
If you are always using the script in places where <command>nix-shell</command> is available, you can embed the <command>nix-shell</command> invocation in the shebang like this:
<programlisting>
#!/usr/bin/env nix-shell
#! nix-shell -i perl -p perl perlPackages.DBFile
</programlisting>
<programlisting>
#!/usr/bin/env nix-shell
#! nix-shell -i perl -p perl perlPackages.DBFile
</programlisting>
</para>
</section>
@ -44,30 +44,30 @@
<para>
Perl packages from CPAN are defined in <link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix"><filename>pkgs/top-level/perl-packages.nix</filename></link>, rather than <filename>pkgs/all-packages.nix</filename>. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from <filename>perl-packages.nix</filename>. However, more complicated packages should be put in a separate file, typically in <filename>pkgs/development/perl-modules</filename>. Here is an example of the former:
<programlisting>
ClassC3 = buildPerlPackage rec {
name = "Class-C3-0.21";
src = fetchurl {
url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz";
sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
};
};
</programlisting>
<programlisting>
ClassC3 = buildPerlPackage rec {
name = "Class-C3-0.21";
src = fetchurl {
url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz";
sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
};
};
</programlisting>
Note the use of <literal>mirror://cpan/</literal>, and the <literal>${name}</literal> in the URL definition to ensure that the name attribute is consistent with the source that we’re actually downloading. Perl packages are made available in <filename>all-packages.nix</filename> through the variable <varname>perlPackages</varname>. For instance, if you have a package that needs <varname>ClassC3</varname>, you would typically write
<programlisting>
foo = import ../path/to/foo.nix {
inherit stdenv fetchurl ...;
inherit (perlPackages) ClassC3;
};
</programlisting>
<programlisting>
foo = import ../path/to/foo.nix {
inherit stdenv fetchurl ...;
inherit (perlPackages) ClassC3;
};
</programlisting>
in <filename>all-packages.nix</filename>. You can test building a Perl package as follows:
<screen>
<prompt>$ </prompt>nix-build -A perlPackages.ClassC3
</screen>
<screen>
<prompt>$ </prompt>nix-build -A perlPackages.ClassC3
</screen>
<varname>buildPerlPackage</varname> adds <literal>perl-</literal> to the start of the name attribute, so the package above is actually called <literal>perl-Class-C3-0.21</literal>. So to install it, you can say:
<screen>
<prompt>$ </prompt>nix-env -i perl-Class-C3
</screen>
<screen>
<prompt>$ </prompt>nix-env -i perl-Class-C3
</screen>
(Of course you can also install using the attribute name: <literal>nix-env -i -A perlPackages.ClassC3</literal>.)
</para>
@ -94,61 +94,61 @@
<para>
<varname>buildPerlPackage</varname> is built on top of <varname>stdenv</varname>, so everything can be customised in the usual way. For instance, the <literal>BerkeleyDB</literal> module has a <varname>preConfigure</varname> hook to generate a configuration file used by <filename>Makefile.PL</filename>:
<programlisting>
{ buildPerlPackage, fetchurl, db }:
<programlisting>
{ buildPerlPackage, fetchurl, db }:
buildPerlPackage rec {
name = "BerkeleyDB-0.36";
buildPerlPackage rec {
name = "BerkeleyDB-0.36";
src = fetchurl {
url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz";
sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
};
src = fetchurl {
url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz";
sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
};
preConfigure = ''
echo "LIB = ${db.out}/lib" > config.in
echo "INCLUDE = ${db.dev}/include" >> config.in
'';
}
</programlisting>
preConfigure = ''
echo "LIB = ${db.out}/lib" > config.in
echo "INCLUDE = ${db.dev}/include" >> config.in
'';
}
</programlisting>
</para>
<para>
Dependencies on other Perl packages can be specified in the <varname>buildInputs</varname> and <varname>propagatedBuildInputs</varname> attributes. If something is exclusively a build-time dependency, use <varname>buildInputs</varname>; if it’s (also) a runtime dependency, use <varname>propagatedBuildInputs</varname>. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules:
<programlisting>
ClassC3Componentised = buildPerlPackage rec {
name = "Class-C3-Componentised-1.0004";
src = fetchurl {
url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz";
sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
};
propagatedBuildInputs = [
ClassC3 ClassInspector TestException MROCompat
];
};
</programlisting>
<programlisting>
ClassC3Componentised = buildPerlPackage rec {
name = "Class-C3-Componentised-1.0004";
src = fetchurl {
url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz";
sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
};
propagatedBuildInputs = [
ClassC3 ClassInspector TestException MROCompat
];
};
</programlisting>
</para>
<para>
On Darwin, if a script has too many <literal>-I<replaceable>dir</replaceable></literal> flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the <literal>shortenPerlShebang</literal> function from the <literal>postInstall</literal> phase:
<programlisting>
{ stdenv, buildPerlPackage, fetchurl, shortenPerlShebang }:
<programlisting>
{ stdenv, buildPerlPackage, fetchurl, shortenPerlShebang }:
ImageExifTool = buildPerlPackage {
pname = "Image-ExifTool";
version = "11.50";
ImageExifTool = buildPerlPackage {
pname = "Image-ExifTool";
version = "11.50";
src = fetchurl {
url = "https://www.sno.phy.queensu.ca/~phil/exiftool/Image-ExifTool-11.50.tar.gz";
sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3";
};
src = fetchurl {
url = "https://www.sno.phy.queensu.ca/~phil/exiftool/Image-ExifTool-11.50.tar.gz";
sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3";
};
buildInputs = stdenv.lib.optional stdenv.isDarwin shortenPerlShebang;
postInstall = stdenv.lib.optional stdenv.isDarwin ''
shortenPerlShebang $out/bin/exiftool
'';
};
</programlisting>
buildInputs = stdenv.lib.optional stdenv.isDarwin shortenPerlShebang;
postInstall = stdenv.lib.optional stdenv.isDarwin ''
shortenPerlShebang $out/bin/exiftool
'';
};
</programlisting>
This will remove the <literal>-I</literal> flags from the shebang line, rewrite them in the <literal>use lib</literal> form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place.
</para>
@ -159,27 +159,27 @@
Nix expressions for Perl packages can be generated (almost) automatically from CPAN. This is done by the program <command>nix-generate-from-cpan</command>, which can be installed as follows:
</para>
<screen>
<prompt>$ </prompt>nix-env -i nix-generate-from-cpan
</screen>
<screen>
<prompt>$ </prompt>nix-env -i nix-generate-from-cpan
</screen>
<para>
This program takes a Perl module name, looks it up on CPAN, fetches and unpacks the corresponding package, and prints a Nix expression on standard output. For example:
<screen>
<prompt>$ </prompt>nix-generate-from-cpan XML::Simple
XMLSimple = buildPerlPackage rec {
name = "XML-Simple-2.22";
src = fetchurl {
url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz";
sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
};
propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
meta = {
description = "An API for simple XML files";
license = with stdenv.lib.licenses; [ artistic1 gpl1Plus ];
};
};
</screen>
<screen>
<prompt>$ </prompt>nix-generate-from-cpan XML::Simple
XMLSimple = buildPerlPackage rec {
name = "XML-Simple-2.22";
src = fetchurl {
url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz";
sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
};
propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
meta = {
description = "An API for simple XML files";
license = with stdenv.lib.licenses; [ artistic1 gpl1Plus ];
};
};
</screen>
The output can be pasted into <filename>pkgs/top-level/perl-packages.nix</filename> or wherever else you need it.
</para>
</section>

2
doc/languages-frameworks/qt.xml
View file

@ -18,7 +18,7 @@ mkDerivation { <co xml:id='qt-default-nix-co-2' />
buildInputs = [ qtbase ]; <co xml:id='qt-default-nix-co-3' />
}
</programlisting>
</programlisting>
</example>
<calloutlist>

25
doc/languages-frameworks/ruby.xml
View file

@ -12,14 +12,14 @@
</para>
<screen>
<![CDATA[$ cd pkgs/servers/monitoring
$ mkdir sensu
$ cd sensu
$ cat > Gemfile
<prompt>$ </prompt>cd pkgs/servers/monitoring
<prompt>$ </prompt>mkdir sensu
<prompt>$ </prompt>cd sensu
<prompt>$ </prompt>cat > Gemfile
source 'https://rubygems.org'
gem 'sensu'
$ $(nix-build '<nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic
$ cat > default.nix
<prompt>$ </prompt>$(nix-build '&lt;nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic
<prompt>$ </prompt>cat > default.nix
{ lib, bundlerEnv, ruby }:
bundlerEnv rec {
@ -37,7 +37,7 @@ bundlerEnv rec {
maintainers = with maintainers; [ theuni ];
platforms = platforms.unix;
};
}]]>
}
</screen>
<para>
@ -49,17 +49,16 @@ bundlerEnv rec {
</para>
<screen>
<![CDATA[$ cd pkgs/servers/monitoring/sensu
$ nix-shell -p bundler --run 'bundle lock --update'
$ nix-shell -p bundix --run 'bundix'
]]>
<prompt>$ </prompt>cd pkgs/servers/monitoring/sensu
<prompt>$ </prompt>nix-shell -p bundler --run 'bundle lock --update'
<prompt>$ </prompt>nix-shell -p bundix --run 'bundix'
</screen>
<para>
For tools written in Ruby - i.e. where the desire is to install a package and then execute e.g. <command>rake</command> at the command line, there is an alternative builder called <literal>bundlerApp</literal>. Set up the <filename>gemset.nix</filename> the same way, and then, for example:
</para>
<screen>
<programlisting>
<![CDATA[{ lib, bundlerApp }:
bundlerApp {
@ -75,7 +74,7 @@ bundlerApp {
platforms = platforms.unix;
};
}]]>
</screen>
</programlisting>
<para>
The chief advantage of <literal>bundlerApp</literal> over <literal>bundlerEnv</literal> is the executables introduced in the environment are precisely those selected in the <literal>exes</literal> list, as opposed to <literal>bundlerEnv</literal> which adds all the executables made available by gems in the gemset, which can mean e.g. <command>rspec</command> or <command>rake</command> in unpredictable versions available from various packages.

10
doc/languages-frameworks/texlive.xml
View file

@ -44,11 +44,11 @@ texlive.combine {
<listitem>
<para>
You can list packages e.g. by <command>nix repl</command>.
<programlisting><![CDATA[
$ nix repl
nix-repl> :l <nixpkgs>
nix-repl> texlive.collection-<TAB>
]]></programlisting>
<programlisting>
<prompt>$ </prompt>nix repl
<prompt>nix-repl> </prompt>:l &lt;nixpkgs>
<prompt>nix-repl> </prompt>texlive.collection-<keycap function="tab" />
</programlisting>
</para>
</listitem>
<listitem>

2
doc/stdenv/multiple-output.xml
View file

@ -67,7 +67,7 @@
<para>
<command>nix-env</command> silenty disregards the outputs selected by the user, and instead installs the outputs from <varname>meta.outputsToInstall</varname>. For example,
</para>
<programlisting>$ nix-env -iA nixpkgs.coreutils.info</programlisting>
<screen><prompt>$ </prompt>nix-env -iA nixpkgs.coreutils.info</screen>
<para>
installs the <literal>"out"</literal> output (<varname>coreutils.meta.outputsToInstall</varname> is <literal>[ "out" ]</literal>) instead of the requested <literal>"info"</literal>.
</para>

8
doc/using/configuration.xml
View file

@ -66,7 +66,7 @@
<listitem>
<para>
For allowing the build of a broken package once, you can use an environment variable for a single invocation of the nix tools:
<programlisting>$ export NIXPKGS_ALLOW_BROKEN=1</programlisting>
<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_BROKEN=1</screen>
</para>
</listitem>
<listitem>
@ -92,7 +92,7 @@
<listitem>
<para>
For allowing the build of an unsupported package once, you can use an environment variable for a single invocation of the nix tools:
<programlisting>$ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1</programlisting>
<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1</screen>
</para>
</listitem>
<listitem>
@ -122,7 +122,7 @@
<listitem>
<para>
To temporarily allow all unfree packages, you can use an environment variable for a single invocation of the nix tools:
<programlisting>$ export NIXPKGS_ALLOW_UNFREE=1</programlisting>
<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_UNFREE=1</screen>
</para>
</listitem>
<listitem>
@ -187,7 +187,7 @@
<listitem>
<para>
To temporarily allow all insecure packages, you can use an environment variable for a single invocation of the nix tools:
<programlisting>$ export NIXPKGS_ALLOW_INSECURE=1</programlisting>
<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_INSECURE=1</screen>
</para>
</listitem>
<listitem>

10
doc/using/overlays.xml
View file

@ -240,7 +240,7 @@ self: super:
lapackProvider = self.mkl;
}
}
</programlisting>
</programlisting>
<para>
This overlay uses Intel’s MKL library for both BLAS and LAPACK
interfaces. Note that the same can be accomplished at runtime
@ -248,9 +248,9 @@ self: super:
<literal>libblas.so.3</literal> and
<literal>liblapack.so.3</literal>. For instance:
</para>
<programlisting>
$ LD_LIBRARY_PATH=$(nix-build -A mkl)/lib:$LD_LIBRARY_PATH nix-shell -p octave --run octave
</programlisting>
<screen>
<prompt>$ </prompt>LD_LIBRARY_PATH=$(nix-build -A mkl)/lib:$LD_LIBRARY_PATH nix-shell -p octave --run octave
</screen>
<para>
Intel MKL requires an <literal>openmp</literal> implementation
when running with multiple processors. By default,
@ -288,7 +288,7 @@ assert (!blas.isILP64) &amp;&amp; (!lapack.isILP64);
stdenv.mkDerivation {
...
}
</programlisting>
</programlisting>
</section>
</section>
</chapter>