Merge pull request #45914 from grahamc/section-ids

Section ids

+6 -6
doc/cross-compilation.xml
···
<section xml:id="sec-cross-packaging">
<title>Packaging in a cross-friendly manner</title>
-
<section>
+
<section xml:id="sec-cross-platform-parameters">
<title>Platform parameters</title>
<para>
···
</variablelist>
</section>
-
<section>
+
<section xml:id="sec-cross-specifying-dependencies">
<title>Specifying Dependencies</title>
<para>
···
</note>
</section>
-
<section>
+
<section xml:id="sec-cross-cookbook">
<title>Cross packaging cookbook</title>
<para>
···
</para>
<qandaset>
-
<qandaentry>
+
<qandaentry xml:id="cross-qa-build-c-program-in-build-environment">
<question>
<para>
What if my package's build system needs to build a C program to be run
···
</para>
</answer>
</qandaentry>
-
<qandaentry>
+
<qandaentry xml:id="cross-qa-fails-to-find-ar">
<question>
<para>
My package fails to find <command>ar</command>.
···
</para>
</answer>
</qandaentry>
-
<qandaentry>
+
<qandaentry xml:id="cross-testsuite-runs-host-code">
<question>
<para>
My package's testsuite needs to run host platform code.
+2 -2
doc/languages-frameworks/texlive.xml
···
under attribute <varname>texlive</varname>.
</para>
-
<section>
+
<section xml:id="sec-language-texlive-users-guide">
<title>User's guide</title>
<itemizedlist>
···
</itemizedlist>
</section>
-
<section>
+
<section xml:id="sec-language-texlive-known-problems">
<title>Known problems</title>
<itemizedlist>
+5 -5
doc/multiple-output.xml
···
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:id="chap-multiple-output">
<title>Multiple-output packages</title>
-
<section>
+
<section xml:id="sec-multiple-outputs-introduction">
<title>Introduction</title>
<para>
···
</para>
</note>
</section>
-
<section>
+
<section xml:id="sec-multiple-outputs-installing">
<title>Installing a split package</title>
<para>
···
</listitem>
</itemizedlist>
</section>
-
<section>
+
<section xml:id="sec-multiple-outputs-using-split-packages">
<title>Using a split package</title>
<para>
···
also added. (See <xref linkend="multiple-output-file-type-groups" />.)
</para>
</section>
-
<section>
+
<section xml:id="sec-multiple-outputs-">
<title>Writing a split derivation</title>
<para>
···
</variablelist>
</section>
-
<section>
+
<section xml:id="sec-multiple-outputs-caveats">
<title>Common caveats</title>
<itemizedlist>
+2 -2
doc/package-notes.xml
···
</section>
<!--============================================================-->
<!--
-
<section>
+
<section xml:id="sec-package-notes-gnome">
<title>Gnome</title>
<para>* Expression is auto-generated</para>
<para>* How to update</para>
···
-->
<!--============================================================-->
<!--
-
<section>
+
<section xml:id="sec-package-notes-gcc">
<title>GCC</title>
<para>…</para>
</section>
+8 -8
doc/release-notes.xml
···
<article xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Nixpkgs Release Notes</title>
-
<section>
+
<section xml:id="release-notes-0.14">
<title>Release 0.14 (June 4, 2012)</title>
<para>
···
packages by numerous contributors. For details, see the commit logs.
</para>
</section>
-
<section>
+
<section xml:id="release-notes-0.13">
<title>Release 0.13 (February 5, 2010)</title>
<para>
···
</itemizedlist>
</para>
</section>
-
<section>
+
<section xml:id="release-notes-0.12">
<title>Release 0.12 (April 24, 2009)</title>
<para>
···
<literal>nix-dev</literal> mailing list.
</para>
</section>
-
<section>
+
<section xml:id="release-notes-0.11">
<title>Release 0.11 (September 11, 2007)</title>
<para>
···
Bravenboer, Michael Raskin, Wouter den Breejen and Yury G. Kudryashov.
</para>
</section>
-
<section>
+
<section xml:id="release-notes-0.10">
<title>Release 0.10 (October 12, 2006)</title>
<note>
···
Bravenboer, Merijn de Jonge, Rob Vermaas and Roy van den Broek.
</para>
</section>
-
<section>
+
<section xml:id="release-notes-0.9">
<title>Release 0.9 (January 31, 2006)</title>
<para>
···
Martin Bravenboer, Rob Vermaas and Roy van den Broek.
</para>
</section>
-
<section>
+
<section xml:id="release-notes-0.8">
<title>Release 0.8 (April 11, 2005)</title>
<para>
···
</itemizedlist>
</para>
</section>
-
<section>
+
<section xml:id="release-notes-0.7">
<title>Release 0.7 (March 14, 2005)</title>
<itemizedlist>
+10 -10
doc/reviewing-contributions.xml
···
meant as examples. Their usage is optional and the reviewer is free to adapt
them to their liking.
</para>
-
<section>
+
<section xml:id="reviewing-contributions-package-updates">
<title>Package updates</title>
<para>
···
</listitem>
</itemizedlist>
-
<example>
+
<example xml:id="reviewing-contributions-sample-package-update">
<title>Sample template for a package update review</title>
<screen>
##### Reviewed points
···
</screen>
</example>
</section>
-
<section>
+
<section xml:id="reviewing-contributions-new-packages">
<title>New packages</title>
<para>
···
</listitem>
</itemizedlist>
-
<example>
+
<example xml:id="reviewing-contributions-sample-new-package">
<title>Sample template for a new package review</title>
<screen>
##### Reviewed points
···
</screen>
</example>
</section>
-
<section>
+
<section xml:id="reviewing-contributions-module-updates">
<title>Module updates</title>
<para>
···
</listitem>
</itemizedlist>
-
<example>
+
<example xml:id="reviewing-contributions-sample-module-update">
<title>Sample template for a module update review</title>
<screen>
##### Reviewed points
···
</screen>
</example>
</section>
-
<section>
+
<section xml:id="reviewing-contributions-new-modules">
<title>New modules</title>
<para>
···
</listitem>
</itemizedlist>
-
<example>
+
<example xml:id="reviewing-contributions-sample-new-module">
<title>Sample template for a new module review</title>
<screen>
##### Reviewed points
···
</screen>
</example>
</section>
-
<section>
+
<section xml:id="reviewing-contributions-other-submissions">
<title>Other submissions</title>
<para>
···
pull requests fitting this category.
</para>
</section>
-
<section>
+
<section xml:id="reviewing-contributions--merging-pull-requests">
<title>Merging pull-requests</title>
<para>
+7 -7
doc/stdenv.xml
···
platforms relative to the new derivation's, and whether they are propagated.
The platform distinctions are motivated by cross compilation; see
<xref linkend="chap-cross"/> for exactly what each platform means.
-
<footnote>
+
<footnote xml:id="footnote-stdenv-ignored-build-platform">
<para>
The build platform is ignored because it is a mere implementation detail
of the package satisfying the dependency: As a general programming
···
out only for dependencies whose host platform matches the new derivation's
build platform–i.e. which run on the platform where the new derivation
will be built.
-
<footnote>
+
<footnote xml:id="footnote-stdenv-native-dependencies-in-path">
<para>
Currently, that means for native builds all dependencies are put on the
<envar>PATH</envar>. But in the future that may not be the case for sake
···
<link xlink:href="https://en.wikipedia.org/wiki/Natural_deduction">Natural
Deduction</link> using the inference rules. This probably seems a bit
obtuse, but so is the bash code that actually implements it!
-
<footnote>
+
<footnote xml:id="footnote-stdenv-find-inputs-location">
<para>
The <function>findInputs</function> function, currently residing in
<filename>pkgs/stdenv/generic/setup.sh</filename>, implements the
···
By default, the configure phase applies some special hackery to all
files called <filename>ltmain.sh</filename> before running the configure
script in order to improve the purity of Libtool-based packages
-
<footnote>
+
<footnote xml:id="footnote-stdenv-sys-lib-search-path">
<para>
It clears the
<varname>sys_lib_<replaceable>*</replaceable>search_path</varname>
···
or a subset to control exactly which platform flags are passed.
Compilers and other tools should use this to also pass the target
platform, for example.
-
<footnote>
+
<footnote xml:id="footnote-stdenv-build-time-guessing-impurity">
<para>
Eventually these will be passed when in native builds too, to improve
determinism: build-time guessing, as is done today, is a risk of
···
Controls whether the installCheck phase is executed. By default it is
skipped, but if <varname>doInstallCheck</varname> is set to true, the
installCheck phase is usually executed. Thus you should set
-
<programlisting>doInstallCheck = true;</programlisting>
+
<programlisting>doInstallCheck = true;</programlisting>
in the derivation to enable install checks. The exception is cross
compilation. Cross compiled builds never run tests, no matter how
<varname>doInstallCheck</varname> is set, as the newly-built program
···
<command>clang</command> is to be used. Secondly, this helps packages
not get confused when cross-compiling, in which case multiple Bintools
Wrappers may simultaneously be in use.
-
<footnote>
+
<footnote xml:id="footnote-stdenv-per-platform-wrapper">
<para>
Each wrapper targets a single platform, so if binaries for multiple
platforms are needed, the underlying binaries must be wrapped multiple
+15 -15
doc/submitting-changes.xml
···
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:id="chap-submitting-changes">
<title>Submitting changes</title>
-
<section>
+
<section xml:id="submitting-changes-making-patches">
<title>Making patches</title>
<itemizedlist>
···
</listitem>
</itemizedlist>
</section>
-
<section>
+
<section xml:id="submitting-changes-submitting-changes">
<title>Submitting changes</title>
<itemizedlist>
···
</listitem>
</itemizedlist>
</section>
-
<section>
+
<section xml:id="submitting-changes-pull-request-template">
<title>Pull Request Template</title>
<para>
···
below:
</para>
-
<section>
+
<section xml:id="submitting-changes-tested-with-sandbox">
<title>Tested using sandboxing</title>
<para>
···
</para>
</section>
-
<section>
+
<section xml:id="submitting-changes-platform-diversity">
<title>Built on platform(s)</title>
<para>
···
</para>
</section>
-
<section>
+
<section xml:id="submitting-changes-nixos-tests">
<title>Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)</title>
<para>
···
</para>
</section>
-
<section>
+
<section xml:id="submitting-changes-tested-compilation">
<title>Tested compilation of all pkgs that depend on this change using <command>nox-review</command></title>
<para>
···
</para>
</section>
-
<section>
+
<section xml:id="submitting-changes-tested-execution">
<title>Tested execution of all binary files (usually in <filename>./result/bin/</filename>)</title>
<para>
···
</para>
</section>
-
<section>
-
<title>Meets nixpkgs contribution standards</title>
+
<section xml:id="submitting-changes-contribution-standards">
+
<title>Meets Nixpkgs contribution standards</title>
<para>
The last checkbox is fits
···
</para>
</section>
</section>
-
<section>
+
<section xml:id="submitting-changes-hotfixing-pull-requests">
<title>Hotfixing pull requests</title>
<itemizedlist>
···
</listitem>
</itemizedlist>
</section>
-
<section>
+
<section xml:id="submitting-changes-commit-policy">
<title>Commit policy</title>
<itemizedlist>
···
</listitem>
</itemizedlist>
-
<section>
+
<section xml:id="submitting-changes-master-branch">
<title>Master branch</title>
<itemizedlist>
···
</itemizedlist>
</section>
-
<section>
+
<section xml:id="submitting-changes-staging-branch">
<title>Staging branch</title>
<itemizedlist>
···
</itemizedlist>
</section>
-
<section>
+
<section xml:id="submitting-changes-stable-release-branches">
<title>Stable release branches</title>
<itemizedlist>