Backport Rust 1.38 to 19.09 (#70735)

Backport Rust 1.38 to 19.09

.editorconfig

@@ -1,5 +1,5 @@
 # EditorConfig configuration for nixpkgs
-# https://EditorConfig.org
+# http://EditorConfig.org
 
 # Top-most EditorConfig file
 root = true
@@ -11,102 +11,18 @@ insert_final_newline = true
 trim_trailing_whitespace = true
 charset = utf-8
 
-# Ignore diffs/patches
-[*.{diff,patch}]
-end_of_line = unset
-insert_final_newline = unset
-trim_trailing_whitespace = unset
-
 # see https://nixos.org/nixpkgs/manual/#chap-conventions
 
-# Match json/lockfiles/markdown/nix/perl/python/ruby/shell/docbook files, set indent to spaces
-[*.{json,lock,md,nix,pl,pm,py,rb,sh,xml}]
+# Match nix/ruby/docbook files, set indent to spaces with width of two
+[*.{nix,rb,xml}]
 indent_style = space
-
-# Match docbook files, set indent width of one
-[*.xml]
-indent_size = 1
-
-# Match json/lockfiles/markdown/nix/ruby files, set indent width of two
-[*.{json,lock,md,nix,rb}]
 indent_size = 2
 
-# Match perl/python/shell scripts, set indent width of four
-[*.{pl,pm,py,sh}]
+# Match shell/python/perl scripts, set indent to spaces with width of four
+[*.{sh,py,pl}]
+indent_style = space
 indent_size = 4
 
-# Match gemfiles, set indent to spaces with width of two
-[Gemfile]
-indent_size = 2
-indent_style = space
-
-# Disable file types or individual files
-# some of these files may be auto-generated and/or require significant changes
-
-[*.{c,h}]
-insert_final_newline = unset
-trim_trailing_whitespace = unset
-
-[*.{key,ovpn}]
-insert_final_newline = unset
-end_of_line = unset
-
-[*.lock]
-indent_size = unset
-
-[deps.nix]
-insert_final_newline = unset
-
-[eggs.nix]
-trim_trailing_whitespace = unset
-
-[gemset.nix]
-insert_final_newline = unset
-
-[node-{composition,packages}.nix]
-insert_final_newline = unset
-
-[nixos/modules/services/networking/ircd-hybrid/*.{conf,in}]
-trim_trailing_whitespace = unset
-
-[nixos/tests/systemd-networkd-vrf.nix]
-trim_trailing_whitespace = unset
-
-[pkgs/applications/editors/emacs-modes/recipes-archive-melpa.json]
-indent_size = unset
-
-[pkgs/build-support/dotnetenv/Wrapper/**]
-end_of_line = unset
-insert_final_newline = unset
-trim_trailing_whitespace = unset
-
-[pkgs/build-support/upstream-updater/**]
-trim_trailing_whitespace = unset
-
-[pkgs/development/compilers/elm/registry.dat]
-end_of_line = unset
-insert_final_newline = unset
-
-[pkgs/development/lisp-modules/quicklisp-to-nix.nix]
-indent_size = unset
-
-[pkgs/development/haskell-modules/hackage-packages.nix]
-indent_style = unset
-indent_size = unset
-trim_trailing_whitespace = unset
-
-[pkgs/development/mobile/androidenv/generated/{addons,packages}.nix]
-trim_trailing_whitespace = unset
-
-[pkgs/development/node-packages/node-packages.nix]
-insert_final_newline = unset
-
-[pkgs/servers/dict/wordnet_structures.py]
-indent_size = unset
-trim_trailing_whitespace = unset
-
-[pkgs/top-level/emscripten-packages.nix]
-trim_trailing_whitespace = unset
-
-[pkgs/top-level/perl-packages.nix]
-indent_size = unset
+# Match diffs, avoid to trim trailing whitespace
+[*.{diff,patch}]
+trim_trailing_whitespace = false

.github/CODEOWNERS

@@ -10,19 +10,11 @@
 # This file
 /.github/CODEOWNERS @edolstra
 
-# GitHub actions
-/.github/workflows @Mic92 @zowoq
-
-# EditorConfig
-/.editorconfig @Mic92 @zowoq
-
 # Libraries
-/lib                        @edolstra @nbp @infinisil
+/lib                        @edolstra @nbp
 /lib/systems                @nbp @ericson2314 @matthewbauer
 /lib/generators.nix         @edolstra @nbp @Profpatsch
-/lib/cli.nix                @edolstra @nbp @Profpatsch
 /lib/debug.nix              @edolstra @nbp @Profpatsch
-/lib/asserts.nix            @edolstra @nbp @Profpatsch
 
 # Nixpkgs Internals
 /default.nix                          @nbp
@@ -37,13 +29,10 @@
 /pkgs/build-support/bintools-wrapper  @Ericson2314 @orivej
 /pkgs/build-support/setup-hooks       @Ericson2314
 
-# Nixpkgs build-support
-/pkgs/build-support/writers @lassulus @Profpatsch
-
 # NixOS Internals
-/nixos/default.nix          @nbp @infinisil
-/nixos/lib/from-env.nix     @nbp @infinisil
-/nixos/lib/eval-config.nix  @nbp @infinisil
+/nixos/default.nix          @nbp
+/nixos/lib/from-env.nix     @nbp
+/nixos/lib/eval-config.nix  @nbp
 /nixos/doc/manual/configuration/abstractions.xml      @nbp
 /nixos/doc/manual/configuration/config-file.xml       @nbp
 /nixos/doc/manual/configuration/config-syntax.xml     @nbp
@@ -58,29 +47,22 @@
 /nixos/doc/manual/man-nixos-option.xml                @nbp
 /nixos/modules/installer/tools/nixos-option.sh        @nbp
 
-# NixOS integration test driver
-/nixos/lib/test-driver  @tfc
-
-# Updaters
-## update.nix
-/maintainers/scripts/update.nix   @jtojnar
-/maintainers/scripts/update.py    @jtojnar
-## common-updater-scripts
-/pkgs/common-updater/scripts/update-source-version    @jtojnar
+# New NixOS modules
+/nixos/modules/module-list.nix @Infinisil
 
 # Python-related code and docs
 /maintainers/scripts/update-python-libraries	@FRidh
-/pkgs/top-level/python-packages.nix     @FRidh @jonringer
+/pkgs/top-level/python-packages.nix     @FRidh
 /pkgs/development/interpreters/python   @FRidh
-/pkgs/development/python-modules        @FRidh @jonringer
+/pkgs/development/python-modules        @FRidh
 /doc/languages-frameworks/python.section.md     @FRidh
 
 # Haskell
-/pkgs/development/compilers/ghc                       @cdepillabout
-/pkgs/development/haskell-modules		      @cdepillabout
-/pkgs/development/haskell-modules/default.nix	      @cdepillabout
-/pkgs/development/haskell-modules/generic-builder.nix @cdepillabout
-/pkgs/development/haskell-modules/hoogle.nix	      @cdepillabout
+/pkgs/development/compilers/ghc                       @basvandijk
+/pkgs/development/haskell-modules                     @basvandijk
+/pkgs/development/haskell-modules/default.nix         @basvandijk
+/pkgs/development/haskell-modules/generic-builder.nix @basvandijk
+/pkgs/development/haskell-modules/hoogle.nix          @basvandijk
 
 # Perl
 /pkgs/development/interpreters/perl @volth
@@ -92,12 +74,11 @@
 /pkgs/development/r-modules         @peti
 
 # Ruby
-/pkgs/development/interpreters/ruby @alyssais
-/pkgs/development/ruby-modules      @alyssais
+/pkgs/development/interpreters/ruby @alyssais @zimbatm
+/pkgs/development/ruby-modules      @alyssais @zimbatm
 
 # Rust
 /pkgs/development/compilers/rust @Mic92 @LnL7
-/pkgs/build-support/rust @andir
 
 # Darwin-related
 /pkgs/stdenv/darwin         @NixOS/darwin-maintainers
@@ -149,12 +130,6 @@
 /nixos/tests/hardened.nix @joachifm
 /pkgs/os-specific/linux/kernel/hardened-config.nix @joachifm
 
-# Network Time Daemons
-/pkgs/tools/networking/chrony @thoughtpolice
-/pkgs/tools/networking/ntp @thoughtpolice
-/pkgs/tools/networking/openntpd @thoughtpolice
-/nixos/modules/services/networking/ntp @thoughtpolice
-
 # Dhall
 /pkgs/development/dhall-modules      @Gabriel439 @Profpatsch
 /pkgs/development/interpreters/dhall @Gabriel439 @Profpatsch
@@ -175,36 +150,3 @@
 /pkgs/applications/editors/emacs-modes @adisbladis
 /pkgs/applications/editors/emacs       @adisbladis
 /pkgs/top-level/emacs-packages.nix     @adisbladis
-
-# VimPlugins
-/pkgs/misc/vim-plugins         @jonringer @softinio
-
-# VsCode Extensions
-/pkgs/misc/vscode-extensions   @jonringer
-
-# Prometheus exporter modules and tests
-/nixos/modules/services/monitoring/prometheus/exporters.nix  @WilliButz
-/nixos/modules/services/monitoring/prometheus/exporters.xml  @WilliButz
-/nixos/tests/prometheus-exporters.nix                        @WilliButz
-
-# PHP interpreter, packages, extensions, tests and documentation
-/doc/languages-frameworks/php.section.md @NixOS/php
-/nixos/tests/php                         @NixOS/php
-/pkgs/build-support/build-pecl.nix       @NixOS/php
-/pkgs/development/interpreters/php       @NixOS/php
-/pkgs/top-level/php-packages.nix         @NixOS/php
-
-# Podman, CRI-O modules and related
-/nixos/modules/virtualisation/containers.nix @NixOS/podman @zowoq
-/nixos/modules/virtualisation/cri-o.nix      @NixOS/podman @zowoq
-/nixos/modules/virtualisation/podman.nix     @NixOS/podman @zowoq
-/nixos/tests/cri-o.nix                       @NixOS/podman @zowoq
-/nixos/tests/podman.nix                      @NixOS/podman @zowoq
-
-# Blockchains
-/pkgs/applications/blockchains  @mmahut
-
-# Go
-/pkgs/development/compilers/go @kalbasit @Mic92 @zowoq
-/pkgs/development/go-modules   @kalbasit @Mic92 @zowoq
-/pkgs/development/go-packages  @kalbasit @Mic92 @zowoq

.github/CONTRIBUTING.md

@@ -6,8 +6,9 @@ under the terms of [COPYING](../COPYING), which is an MIT-like license.
 ## Opening issues
 
 * Make sure you have a [GitHub account](https://github.com/signup/free)
-* Make sure there is no open issue on the topic
-* [Submit a new issue](https://github.com/NixOS/nixpkgs/issues/new/choose) by choosing the kind of topic and fill out the template
+* [Submit an issue](https://github.com/NixOS/nixpkgs/issues) - assuming one does not already exist.
+  * Clearly describe the issue including steps to reproduce when it is a bug.
+  * Include information what version of nixpkgs and Nix are you using (nixos-version or git revision).
 
 ## Submitting changes
 
@@ -48,16 +49,6 @@ In addition to writing properly formatted commit messages, it's important to inc
 
 For package version upgrades and such a one-line commit message is usually sufficient.
 
-## Backporting changes
-
-Follow these steps to backport a change into a release branch in compliance with the [commit policy](https://nixos.org/nixpkgs/manual/#submitting-changes-stable-release-branches).
-
-1. Take note of the commits in which the change was introduced into `master` branch.
-2. Check out the target _release branch_, e.g. `release-20.09`. Do not use a _channel branch_ like `nixos-20.09` or `nixpkgs-20.09`.
-3. Create a branch for your change, e.g. `git checkout -b backport`.
-4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request.
-5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-20.09`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[20.09]`.
-
 ## Reviewing contributions
 
-See the nixpkgs manual for more details on how to [Review contributions](https://nixos.org/nixpkgs/manual/#chap-reviewing-contributions).
+See the nixpkgs manual for more details on how to [Review contributions](https://nixos.org/nixpkgs/manual/#sec-reviewing-contributions).

.github/ISSUE_TEMPLATE.md

@@ -8,4 +8,4 @@
 
 ## Technical details
 
-Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.
+Please run `nix run nixpkgs.nix-info -c nix-info -m` and paste the result.

.github/ISSUE_TEMPLATE/bug_report.md

@@ -25,14 +25,8 @@ If applicable, add screenshots to help explain your problem.
 **Additional context**
 Add any other context about the problem here.
 
-**Notify maintainers**
-<!--
-Please @ people who are in the `meta.maintainers` list of the offending package or module.
-If in doubt, check `git blame` for whoever last touched something.
--->
-
 **Metadata**
-Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.
+Please run `nix run nixpkgs.nix-info -c nix-info -m` and paste the result.
 
 Maintainer information:
 ```yaml

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,13 +1,4 @@
-<!--
-To help with the large amounts of pull requests, we would appreciate your
-reviews of other pull requests, especially simple package updates. Just leave a
-comment describing what you have tested in the relevant package/service.
-Reviewing helps to reduce the average time-to-merge for everyone.
-Thanks a lot if you do!
-List of open PRs: https://github.com/NixOS/nixpkgs/pulls
-Reviewing guidelines: https://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/download/1/nixpkgs/manual.html#chap-reviewing-contributions
--->
-
+<!-- Nixpkgs has a lot of new incoming Pull Requests, but not enough people to review this constant stream. Even if you aren't a committer, we would appreciate reviews of other PRs, especially simple ones like package updates. Just testing the relevant package/service and leaving a comment saying what you tested, how you tested it and whether it worked would be great. List of open PRs: <https://github.com/NixOS/nixpkgs/pulls>, for more about reviewing contributions: <https://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/download/1/nixpkgs/manual.html#sec-reviewing-contributions>. Reviewing isn't mandatory, but it would help out a lot and reduce the average time-to-merge for all of us. Thanks a lot if you do! -->
 ###### Motivation for this change
 
 
@@ -15,14 +6,18 @@ Reviewing guidelines: https://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/do
 
 <!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->
 
-- [ ] Tested using sandboxing ([nix.useSandbox](https://nixos.org/nixos/manual/options.html#opt-nix.useSandbox) on NixOS, or option `sandbox` in [`nix.conf`](https://nixos.org/nix/manual/#sec-conf-file) on non-NixOS linux)
+- [ ] Tested using sandboxing ([nix.useSandbox](http://nixos.org/nixos/manual/options.html#opt-nix.useSandbox) on NixOS, or option `sandbox` in [`nix.conf`](http://nixos.org/nix/manual/#sec-conf-file) on non-NixOS)
 - Built on platform(s)
    - [ ] NixOS
    - [ ] macOS
    - [ ] other Linux distributions
 - [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
-- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review wip"`
+- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nix-review --run "nix-review wip"`
 - [ ] Tested execution of all binary files (usually in `./result/bin/`)
 - [ ] Determined the impact on package closure size (by running `nix path-info -S` before and after)
 - [ ] Ensured that relevant documentation is up to date
 - [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md).
+
+###### Notify maintainers
+
+cc @

.github/labeler.yml

@@ -1,146 +0,0 @@
-"6.topic: agda":
-  - doc/languages-frameworks/agda.section.md
-  - nixos/tests/agda.nix
-  - pkgs/build-support/agda/**/*
-  - pkgs/development/libraries/agda/**/*
-  - pkgs/top-level/agda-packages.nix
-
-"6.topic: cinnamon":
-  - pkgs/desktops/cinnamon/**/*
-
-"6.topic: emacs":
-  - nixos/modules/services/editors/emacs.nix
-  - nixos/modules/services/editors/emacs.xml
-  - nixos/tests/emacs-daemon.nix
-  - pkgs/applications/editors/emacs-modes/**/*
-  - pkgs/applications/editors/emacs/**/*
-  - pkgs/build-support/emacs/**/*
-  - pkgs/top-level/emacs-packages.nix
-
-"6.topic: erlang":
-  - doc/languages-frameworks/beam.section.md
-  - pkgs/development/beam-modules/**/*
-  - pkgs/development/interpreters/elixir/**/*
-  - pkgs/development/interpreters/erlang/**/*
-  - pkgs/development/tools/build-managers/rebar/**/*
-  - pkgs/development/tools/build-managers/rebar3/**/*
-  - pkgs/development/tools/erlang/**/*
-  - pkgs/top-level/beam-packages.nix
-
-"6.topic: fetch":
-  - pkgs/build-support/fetch*/**/*
-
-"6.topic: GNOME":
-  - doc/languages-frameworks/gnome.section.md
-  - nixos/modules/services/desktops/gnome3/**/*
-  - nixos/modules/services/x11/desktop-managers/gnome3.nix
-  - nixos/tests/gnome3-xorg.nix
-  - nixos/tests/gnome3.nix
-  - pkgs/desktops/gnome-3/**/*
-
-"6.topic: golang":
-  - doc/languages-frameworks/go.section.md
-  - pkgs/development/compilers/go/**/*
-  - pkgs/development/go-modules/**/*
-  - pkgs/development/go-packages/**/*
-
-"6.topic: haskell":
-  - doc/languages-frameworks/haskell.section.md
-  - pkgs/development/compilers/ghc/**/*
-  - pkgs/development/haskell-modules/**/*
-  - pkgs/development/tools/haskell/**/*
-  - pkgs/top-level/haskell-packages.nix
-
-"6.topic: kernel":
-  - pkgs/build-support/kernel/**/*
-
-"6.topic: lua":
-  - pkgs/development/interpreters/lua-5/**/*
-  - pkgs/development/interpreters/luajit/**/*
-  - pkgs/development/lua-modules/**/*
-  - pkgs/top-level/lua-packages.nix
-
-"6.topic: nixos":
-  - nixos/**/*
-
-"6.topic: ocaml":
-  - doc/languages-frameworks/ocaml.section.md
-  - pkgs/development/compilers/ocaml/**/*
-  - pkgs/development/compilers/reason/**/*
-  - pkgs/development/ocaml-modules/**/*
-  - pkgs/development/tools/ocaml/**/*
-  - pkgs/top-level/ocaml-packages.nix
-
-"6.topic: pantheon":
-  - nixos/modules/services/desktops/pantheon/**/*
-  - nixos/modules/services/x11/desktop-managers/pantheon.nix
-  - nixos/modules/services/x11/display-managers/lightdm-greeters/pantheon.nix
-  - nixos/tests/pantheon.nix
-  - pkgs/desktops/pantheon/**/*
-
-"6.topic: policy discussion":
-  - .github/**/*
-
-"6.topic: printing":
-  - nixos/modules/services/printing/cupsd.nix
-  - pkgs/misc/cups/**/*
-
-"6.topic: python":
-  - doc/languages-frameworks/python.section.md
-  - pkgs/development/interpreters/python/**/*
-  - pkgs/development/python-modules/**/*
-  - pkgs/top-level/python-packages.nix
-
-"6.topic: qt/kde":
-  - doc/languages-frameworks/qt.section.md
-  - nixos/modules/services/x11/desktop-managers/plasma5.nix
-  - nixos/tests/plasma5.nix
-  - pkgs/applications/kde/**/*
-  - pkgs/desktops/plasma-5/**/*
-  - pkgs/development/libraries/kde-frameworks/**/*
-  - pkgs/development/libraries/qt-5/**/*
-
-"6.topic: ruby":
-  - doc/languages-frameworks/ruby.section.md
-  - pkgs/development/interpreters/ruby/**/*
-  - pkgs/development/ruby-modules/**/*
-
-"6.topic: rust":
-  - doc/languages-frameworks/rust.section.md
-  - pkgs/build-support/rust/**/*
-  - pkgs/development/compilers/rust/**/*
-
-"6.topic: stdenv":
-  - pkgs/stdenv/**/*
-
-"6.topic: steam":
-  - pkgs/games/steam/**/*
-
-"6.topic: systemd":
-  - pkgs/os-specific/linux/systemd/**/*
-  - nixos/modules/system/boot/systemd*/**/*
-
-"6.topic: TeX":
-  - doc/languages-frameworks/texlive.section.md
-  - pkgs/tools/typesetting/tex/**/*
-
-"6.topic: vim":
-  - doc/languages-frameworks/vim.section.md
-  - pkgs/applications/editors/vim/**/*
-  - pkgs/misc/vim-plugins/**/*
-
-"6.topic: xfce":
-  - nixos/doc/manual/configuration/xfce.xml
-  - nixos/modules/services/x11/desktop-managers/xfce.nix
-  - nixos/tests/xfce.nix
-  - pkgs/desktops/xfce/**/*
-
-"8.has: changelog":
-  - nixos/doc/manual/release-notes/**/*
-
-"8.has: documentation":
-  - doc/**/*
-  - nixos/doc/**/*
-
-"8.has: module (update)":
-  - nixos/modules/**/*

.github/stale.yml

@@ -1,41 +0,0 @@
-# Configuration for probot-stale - https://github.com/probot/stale
-# Number of days of inactivity before an issue becomes stale
-daysUntilStale: 180
-# Number of days of inactivity before a stale issue is closed
-daysUntilClose: false
-# Issues with these labels will never be considered stale
-exemptLabels:
-  - "1.severity: security"
-# Label to use when marking an issue as stale
-staleLabel: "2.status: stale"
-# Comment to post when marking an issue as stale. Set to `false` to disable
-pulls:
-  markComment: |
-    Hello, I'm a bot and I thank you in the name of the community for your contributions.
-
-    Nixpkgs is a busy repository, and unfortunately sometimes PRs get left behind for too long. Nevertheless, we'd like to help committers reach the PRs that are still important. This PR has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.
-
-    If this is still important to you and you'd like to remove the stale label, we ask that you leave a comment. Your comment can be as simple as "still important to me".  But there's a bit more you can do:
-
-    If you received an approval by an unprivileged maintainer and you are just waiting for a merge, you can @ mention someone with merge permissions and ask them to help. You might be able to find someone relevant by using [Git blame](https://git-scm.com/docs/git-blame) on the relevant files, or via [GitHub's web interface](https://docs.github.com/en/github/managing-files-in-a-repository/tracking-changes-in-a-file). You can see if someone's a member of the [nixpkgs-committers](https://github.com/orgs/NixOS/teams/nixpkgs-committers) team, by hovering with the mouse over their username on the web interface, or by searching them directly on [the list](https://github.com/orgs/NixOS/teams/nixpkgs-committers).
-
-    If your PR wasn't reviewed at all, it might help to find someone who's perhaps a user of the package or module you are changing, or alternatively, ask once more for a review by the maintainer of the package/module this is about. If you don't know any, you can use [Git blame](https://git-scm.com/docs/git-blame) on the relevant files, or [GitHub's web interface](https://docs.github.com/en/github/managing-files-in-a-repository/tracking-changes-in-a-file) to find someone who touched the relevant files in the past.
-
-    If your PR has had reviews and nevertheless got stale, make sure you've responded to all of the reviewer's requests / questions. Usually when PR authors show responsibility and dedication, reviewers (privileged or not) show dedication as well. If you've pushed a change, it's possible the reviewer wasn't notified about your push via email, so you can always [officially request them for a review](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/requesting-a-pull-request-review), or just @ mention them and say you've addressed their comments.
-
-    Lastly, you can always ask for help at [our Discourse Forum](https://discourse.nixos.org/), or more specifically, [at this thread](https://discourse.nixos.org/t/prs-in-distress/3604) or at [#nixos' IRC channel](https://webchat.freenode.net/#nixos).
-
-issues:
-  markComment: |
-    Hello, I'm a bot and I thank you in the name of the community for opening this issue.
-
-    To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.
-
-    The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.
-
-    If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use [Git blame](https://git-scm.com/docs/git-blame) or [GitHub's web interface](https://docs.github.com/en/github/managing-files-in-a-repository/tracking-changes-in-a-file) on the relevant files to find them.
-
-    Lastly, you can always ask for help at [our Discourse Forum](https://discourse.nixos.org/) or at [#nixos' IRC channel](https://webchat.freenode.net/#nixos).
-
-# Comment to post when closing a stale issue. Set to `false` to disable
-closeComment: false

.github/workflows/labels.yml

@@ -1,14 +0,0 @@
-name: "Label PR"
-
-on:
-  pull_request_target:
-
-jobs:
-  labels:
-    runs-on: ubuntu-latest
-    if: github.repository_owner == 'NixOS'
-    steps:
-    - uses: actions/labeler@v3
-      with:
-        repo-token: ${{ secrets.GITHUB_TOKEN }}
-        sync-labels: true

.github/workflows/pending-clear.yml

@@ -1,21 +0,0 @@
-name: "clear pending status"
-
-on:
-  check_suite:
-    types: [ completed ]
-
-jobs:
-  action:
-    runs-on: ubuntu-latest
-    steps:
-    - name: clear pending status
-      if: github.repository_owner == 'NixOS' && github.event.check_suite.app.name == 'OfBorg'
-      env:
-        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      run: |
-        curl \
-          -X POST \
-          -H "Accept: application/vnd.github.v3+json" \
-          -H "Authorization: token $GITHUB_TOKEN" \
-          -d '{"state": "success", "target_url": " ", "description": " ", "context": "Wait for ofborg"}' \
-          "https://api.github.com/repos/NixOS/nixpkgs/statuses/${{ github.event.check_suite.head_sha }}"

.github/workflows/pending-set.yml

@@ -1,20 +0,0 @@
-name: "set pending status"
-
-on:
-  pull_request_target:
-
-jobs:
-  action:
-    runs-on: ubuntu-latest
-    steps:
-    - name: set pending status
-      if: github.repository_owner == 'NixOS'
-      env:
-        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      run: |
-        curl \
-          -X POST \
-          -H "Accept: application/vnd.github.v3+json" \
-          -H "Authorization: token $GITHUB_TOKEN" \
-          -d '{"state": "pending", "target_url": " ", "description": "This pending status will be cleared when ofborg starts eval.", "context": "Wait for ofborg"}' \
-          "https://api.github.com/repos/NixOS/nixpkgs/statuses/${{ github.event.pull_request.head.sha }}"

.gitignore

@@ -11,12 +11,7 @@ result-*
 .version-suffix
 
 .DS_Store
-.mypy_cache
-__pycache__
 
 /pkgs/development/libraries/qt-5/*/tmp/
 /pkgs/desktops/kde-5/*/tmp/
 /pkgs/development/mobile/androidenv/xml/*
-
-# generated by pkgs/common-updater/update-script.nix
-update-git-commits.txt

.version

@@ -1 +1 @@
-20.09
+19.09

COPYING

@@ -1,4 +1,4 @@
-Copyright (c) 2003-2020 Eelco Dolstra and the Nixpkgs/NixOS contributors
+Copyright (c) 2003-2019 Eelco Dolstra and the Nixpkgs/NixOS contributors
 
 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files (the

README.md

@@ -16,7 +16,7 @@
 
 * [NixOS Manual](https://nixos.org/nixos/manual) - how to install, configure, and maintain a purely-functional Linux distribution
 * [Nixpkgs Manual](https://nixos.org/nixpkgs/manual/) - contributing to Nixpkgs and using programming-language-specific Nix expressions
-* [Nix Package Manager Manual](https://nixos.org/nix/manual) - how to write Nix expressions (programs), and how to use Nix command line tools
+* [Nix Package Manager Manual](https://nixos.org/nix/manual) - how to write Nix expresssions (programs), and how to use Nix command line tools
 
 # Community
 
@@ -24,17 +24,15 @@
 * [IRC - #nixos on freenode.net](irc://irc.freenode.net/#nixos)
 * [NixOS Weekly](https://weekly.nixos.org/)
 * [Community-maintained wiki](https://nixos.wiki/)
-* [Community-maintained list of ways to get in touch](https://nixos.wiki/wiki/Get_In_Touch#Chat) (Discord, Matrix, Telegram, other IRC channels, etc.)
 
 # Other Project Repositories
 
-The sources of all official Nix-related projects are in the [NixOS
+The sources of all offical Nix-related projects are in the [NixOS
 organization on GitHub](https://github.com/NixOS/). Here are some of
 the main ones:
 
 * [Nix](https://github.com/NixOS/nix) - the purely functional package manager
 * [NixOps](https://github.com/NixOS/nixops) - the tool to remotely deploy NixOS machines
-* [nixos-hardware](https://github.com/NixOS/nixos-hardware) - NixOS profiles to optimize settings for different hardware
 * [Nix RFCs](https://github.com/NixOS/rfcs) - the formal process for making substantial changes to the community
 * [NixOS homepage](https://github.com/NixOS/nixos-homepage) - the [NixOS.org](https://nixos.org) website
 * [hydra](https://github.com/NixOS/hydra) - our continuous integration system
@@ -46,14 +44,16 @@ Nixpkgs and NixOS are built and tested by our continuous integration
 system, [Hydra](https://hydra.nixos.org/).
 
 * [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
-* [Continuous package builds for the NixOS 20.09 release](https://hydra.nixos.org/jobset/nixos/release-20.09)
+* [Continuous package builds for the NixOS 19.09 release](https://hydra.nixos.org/jobset/nixos/release-19.09)
 * [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
-* [Tests for the NixOS 20.09 release](https://hydra.nixos.org/job/nixos/release-20.09/tested#tabs-constituents)
+* [Tests for the NixOS 19.09 release](https://hydra.nixos.org/job/nixos/release-19.09/tested#tabs-constituents)
 
 Artifacts successfully built with Hydra are published to cache at
 https://cache.nixos.org/. When successful build and test criteria are
 met, the Nixpkgs expressions are distributed via [Nix
-channels](https://nixos.org/nix/manual/#sec-channels).
+channels](https://nixos.org/nix/manual/#sec-channels). The channels
+are provided via a read-only mirror of the Nixpkgs repository called
+[nixpkgs-channels](https://github.com/NixOS/nixpkgs-channels).
 
 # Contributing
 

default.nix

@@ -14,7 +14,7 @@ if ! builtins ? nixVersion || builtins.compareVersions requiredVersion builtins.
     - If you installed Nix using the install script (https://nixos.org/nix/install),
       it is safe to upgrade by running it again:
 
-          curl -L https://nixos.org/nix/install | sh
+          curl https://nixos.org/nix/install | sh
 
     For more information, please see the NixOS release notes at
     https://nixos.org/nixos/manual or locally at

doc/Makefile

@@ -1,4 +1,4 @@
-MD_TARGETS=$(addsuffix .xml, $(basename $(shell find . -type f -regex '.*\.md$$')))
+MD_TARGETS=$(addsuffix .xml, $(basename $(wildcard ./*.md ./**/*.md)))
 
 .PHONY: all
 all: validate format out/html/index.html out/epub/manual.epub
@@ -87,7 +87,7 @@ functions/library/generated: doc-support/result
 	ln -rfs ./doc-support/result/function-docs functions/library/generated
 
 %.section.xml: %.section.md
-	pandoc $^ -w docbook \
+	pandoc $^ -w docbook+smart \
 		-f markdown+smart \
 	  | sed -e 's|<ulink url=|<link xlink:href=|' \
 	      -e 's|</ulink>|</link>|' \
@@ -98,7 +98,7 @@ functions/library/generated: doc-support/result
 	| cat  > $@
 
 %.chapter.xml: %.chapter.md
-	pandoc $^ -w docbook \
+	pandoc $^ -w docbook+smart \
 		--top-level-division=chapter \
 		-f markdown+smart \
 	  | sed -e 's|<ulink url=|<link xlink:href=|' \

doc/builders/images.xml

@@ -1,12 +0,0 @@
-<chapter xmlns="http://docbook.org/ns/docbook"
-         xmlns:xi="http://www.w3.org/2001/XInclude"
-         xml:id="chap-images">
- <title>Images</title>
- <para>
-  This chapter describes tools for creating various types of images.
- </para>
- <xi:include href="images/appimagetools.xml" />
- <xi:include href="images/dockertools.xml" />
- <xi:include href="images/ocitools.xml" />
- <xi:include href="images/snaptools.xml" />
-</chapter>

doc/builders/packages/cataclysm-dda.section.md

@@ -1,94 +0,0 @@
-# Cataclysm: Dark Days Ahead
-
-## How to install Cataclysm DDA
-
-To install the latest stable release of Cataclysm DDA to your profile, execute
-`nix-env -f "<nixpkgs>" -iA cataclysm-dda`. For the curses build (build
-without tiles), install `cataclysmDDA.stable.curses`. Note: `cataclysm-dda` is
-an alias to `cataclysmDDA.stable.tiles`.
-
-If you like access to a development build of your favorite git revision,
-override `cataclysm-dda-git` (or `cataclysmDDA.git.curses` if you like curses
-build):
-
-```nix
-cataclysm-dda-git.override {
-  version = "YYYY-MM-DD";
-  rev = "YOUR_FAVORITE_REVISION";
-  sha256 = "CHECKSUM_OF_THE_REVISION";
-}
-```
-
-The sha256 checksum can be obtained by
-
-```sh
-nix-prefetch-url --unpack "https://github.com/CleverRaven/Cataclysm-DDA/archive/${YOUR_FAVORITE_REVISION}.tar.gz"
-```
-
-The default configuration directory is `~/.cataclysm-dda`. If you prefer
-`$XDG_CONFIG_HOME/cataclysm-dda`, override the derivation:
-
-```nix
-cataclysm-dda.override {
-  useXdgDir = true;
-}
-```
-
-## Customizing with mods
-
-To install Cataclysm DDA with mods of your choice, you can use `withMods`
-attribute:
-
-```nix
-cataclysm-dda.withMods (mods: with mods; [
-  tileset.UndeadPeople
-])
-```
-
-All mods, soundpacks, and tilesets available in nixpkgs are found in
-`cataclysmDDA.pkgs`.
-
-Here is an example to modify existing mods and/or add more mods not available
-in nixpkgs:
-
-```nix
-let
-  customMods = self: super: lib.recursiveUpdate super {
-    # Modify existing mod
-    tileset.UndeadPeople = super.tileset.UndeadPeople.overrideAttrs (old: {
-      # If you like to apply a patch to the tileset for example
-      patches = [ ./path/to/your.patch ];
-    });
-
-    # Add another mod
-    mod.Awesome = cataclysmDDA.buildMod {
-      modName = "Awesome";
-      version = "0.x";
-      src = fetchFromGitHub {
-        owner = "Someone";
-        repo = "AwesomeMod";
-        rev = "...";
-        sha256 = "...";
-      };
-      # Path to be installed in the unpacked source (default: ".")
-      modRoot = "contents/under/this/path/will/be/installed";
-    };
-
-    # Add another soundpack
-    soundpack.Fantastic = cataclysmDDA.buildSoundPack {
-      # ditto
-    };
-
-    # Add another tileset
-    tileset.SuperDuper = cataclysmDDA.buildTileSet {
-      # ditto
-    };
-  };
-in
-cataclysm-dda.withMods (mods: with mods.extend customMods; [
-  tileset.UndeadPeople
-  mod.Awesome
-  soundpack.Fantastic
-  tileset.SuperDuper
-])
-```

doc/builders/packages/citrix.xml

@@ -1,46 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-citrix">
- <title>Citrix Workspace</title>
-
- <para>
-  The <link xlink:href="https://www.citrix.com/products/workspace-app/">Citrix Workspace App</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 license agreements of the vendor for <link xlink:href="https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html">Citrix Workspace</link> needs to be accepted first. Then run <command>nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz</command>. With the archive available in the store the package can be built and installed with Nix.
-  </para>
- </section>
-
- <section xml:id="sec-citrix-selfservice">
-  <title>Citrix Selfservice</title>
-  <para>
-   The <link xlink:href="https://support.citrix.com/article/CTX200337">selfservice</link> is an application managing Citrix desktops and applications. Please note that this feature only works with at least <package>citrix_workspace_20_06_0</package> and later versions.
-  </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>
-  </para>
- </section>
-
- <section xml:id="sec-citrix-custom-certs">
-  <title>Custom certificates</title>
-
-  <para>
-   The <literal>Citrix Workspace App</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>:
-<programlisting>
-<![CDATA[with import <nixpkgs> { config.allowUnfree = true; };
-let extraCerts = [ ./custom-cert-1.pem ./custom-cert-2.pem /* ... */ ]; in
-citrix_workspace.override {
-  inherit extraCerts;
-}]]>
-</programlisting>
-  </para>
- </section>
-</section>

doc/builders/packages/dlib.xml

@@ -1,24 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="dlib">
- <title>DLib</title>
-
- <para>
-  <link xlink:href="http://dlib.net/">DLib</link> is a modern, C++-based toolkit which provides several machine learning algorithms.
- </para>
-
- <section xml:id="compiling-without-avx-support">
-  <title>Compiling without AVX support</title>
-
-  <para>
-   Especially older CPUs don't support <link xlink:href="https://en.wikipedia.org/wiki/Advanced_Vector_Extensions">AVX</link> (<abbrev>Advanced Vector Extensions</abbrev>) instructions that are used by DLib to optimize their algorithms.
-  </para>
-
-  <para>
-   On the affected hardware errors like <literal>Illegal instruction</literal> will occur. In those cases AVX support needs to be disabled:
-<programlisting>self: super: {
-  dlib = super.dlib.override { avxSupport = false; };
-}</programlisting>
-  </para>
- </section>
-</section>

doc/builders/packages/eclipse.xml

@@ -1,72 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-eclipse">
- <title>Eclipse</title>
-
- <para>
-  The Nix expressions related to the Eclipse platform and IDE are in <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/eclipse"><filename>pkgs/applications/editors/eclipse</filename></link>.
- </para>
-
- <para>
-  Nixpkgs provides a number of packages that will install Eclipse in its various forms. These range from the bare-bones Eclipse Platform to the more fully featured Eclipse SDK or Scala-IDE packages and multiple version are often available. It is possible to list available Eclipse packages by issuing the command:
-<screen>
-<prompt>$ </prompt>nix-env -f '&lt;nixpkgs&gt;' -qaP -A eclipses --description
-</screen>
-  Once an Eclipse variant is installed it can be run using the <command>eclipse</command> command, as expected. From within Eclipse it is then possible to install plugins in the usual manner by either manually specifying an Eclipse update site or by installing the Marketplace Client plugin and using it to discover and install other plugins. This installation method provides an Eclipse installation that closely resemble a manually installed Eclipse.
- </para>
-
- <para>
-  If you prefer to install plugins in a more declarative manner then Nixpkgs also offer a number of Eclipse plugins that can be installed in an <emphasis>Eclipse environment</emphasis>. This type of environment is created using the function <varname>eclipseWithPlugins</varname> found inside the <varname>nixpkgs.eclipses</varname> attribute set. This function takes as argument <literal>{ eclipse, plugins ? [], jvmArgs ? [] }</literal> where <varname>eclipse</varname> is a one of the Eclipse packages described above, <varname>plugins</varname> is a list of plugin derivations, and <varname>jvmArgs</varname> is a list of arguments given to the JVM running the Eclipse. For example, say you wish to install the latest Eclipse Platform with the popular Eclipse Color Theme plugin and also allow Eclipse to use more RAM. You could then add
-<screen>
-packageOverrides = pkgs: {
-  myEclipse = with pkgs.eclipses; eclipseWithPlugins {
-    eclipse = eclipse-platform;
-    jvmArgs = [ "-Xmx2048m" ];
-    plugins = [ plugins.color-theme ];
-  };
-}
-</screen>
-  to your Nixpkgs configuration (<filename>~/.config/nixpkgs/config.nix</filename>) and install it by running <command>nix-env -f '&lt;nixpkgs&gt;' -iA myEclipse</command> and afterward run Eclipse as usual. It is possible to find out which plugins are available for installation using <varname>eclipseWithPlugins</varname> by running
-<screen>
-<prompt>$ </prompt>nix-env -f '&lt;nixpkgs&gt;' -qaP -A eclipses.plugins --description
-</screen>
- </para>
-
- <para>
-  If there is a need to install plugins that are not available in Nixpkgs then it may be possible to define these plugins outside Nixpkgs using the <varname>buildEclipseUpdateSite</varname> and <varname>buildEclipsePlugin</varname> functions found in the <varname>nixpkgs.eclipses.plugins</varname> attribute set. Use the <varname>buildEclipseUpdateSite</varname> function to install a plugin distributed as an Eclipse update site. This function takes <literal>{ name, src }</literal> as argument where <literal>src</literal> indicates the Eclipse update site archive. All Eclipse features and plugins within the downloaded update site will be installed. When an update site archive is not available then the <varname>buildEclipsePlugin</varname> function can be used to install a plugin that consists of a pair of feature and plugin JARs. This function takes an argument <literal>{ name, srcFeature, srcPlugin }</literal> where <literal>srcFeature</literal> and <literal>srcPlugin</literal> are the feature and plugin JARs, respectively.
- </para>
-
- <para>
-  Expanding the previous example with two plugins using the above functions we have
-<screen>
-packageOverrides = pkgs: {
-  myEclipse = with pkgs.eclipses; eclipseWithPlugins {
-    eclipse = eclipse-platform;
-    jvmArgs = [ "-Xmx2048m" ];
-    plugins = [
-      plugins.color-theme
-      (plugins.buildEclipsePlugin {
-        name = "myplugin1-1.0";
-        srcFeature = fetchurl {
-          url = "http://…/features/myplugin1.jar";
-          sha256 = "123…";
-        };
-        srcPlugin = fetchurl {
-          url = "http://…/plugins/myplugin1.jar";
-          sha256 = "123…";
-        };
-      });
-      (plugins.buildEclipseUpdateSite {
-        name = "myplugin2-1.0";
-        src = fetchurl {
-          stripRoot = false;
-          url = "http://…/myplugin2.zip";
-          sha256 = "123…";
-        };
-      });
-    ];
-  };
-}
-</screen>
- </para>
-</section>

doc/builders/packages/elm.xml

@@ -1,17 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-elm">
- <title>Elm</title>
-
- <para>
-  To start a development environment do <command>nix-shell -p elmPackages.elm elmPackages.elm-format</command>
- </para>
-
- <para>
-  To update Elm compiler, see <filename>nixpkgs/pkgs/development/compilers/elm/README.md</filename>.
- </para>
-
- <para>
-  To package Elm applications, <link xlink:href="https://github.com/hercules-ci/elm2nix#elm2nix">read about elm2nix</link>.
- </para>
-</section>

doc/builders/packages/emacs.xml

@@ -1,131 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-emacs">
- <title>Emacs</title>
-
- <section xml:id="sec-emacs-config">
-  <title>Configuring Emacs</title>
-
-  <para>
-   The Emacs package comes with some extra helpers to make it easier to configure. <varname>emacsWithPackages</varname> allows you to manage packages from ELPA. This means that you will not have to install that packages from within Emacs. For instance, if you wanted to use <literal>company</literal>, <literal>counsel</literal>, <literal>flycheck</literal>, <literal>ivy</literal>, <literal>magit</literal>, <literal>projectile</literal>, and <literal>use-package</literal> you could use this as a <filename>~/.config/nixpkgs/config.nix</filename> override:
-  </para>
-
-<screen>
-{
-  packageOverrides = pkgs: with pkgs; {
-    myEmacs = emacsWithPackages (epkgs: (with epkgs.melpaStablePackages; [
-      company
-      counsel
-      flycheck
-      ivy
-      magit
-      projectile
-      use-package
-    ]));
-  }
-}
-</screen>
-
-  <para>
-   You can install it like any other packages via <command>nix-env -iA myEmacs</command>. However, this will only install those packages. It will not <literal>configure</literal> them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provide a <filename>default.el</filename> file in <filename>/share/emacs/site-start/</filename>. Emacs knows to load this file automatically when it starts.
-  </para>
-
-<screen>
-{
-  packageOverrides = pkgs: with pkgs; rec {
-    myEmacsConfig = writeText "default.el" ''
-;; initialize package
-
-(require 'package)
-(package-initialize 'noactivate)
-(eval-when-compile
-  (require 'use-package))
-
-;; load some packages
-
-(use-package company
-  :bind ("&lt;C-tab&gt;" . company-complete)
-  :diminish company-mode
-  :commands (company-mode global-company-mode)
-  :defer 1
-  :config
-  (global-company-mode))
-
-(use-package counsel
-  :commands (counsel-descbinds)
-  :bind (([remap execute-extended-command] . counsel-M-x)
-         ("C-x C-f" . counsel-find-file)
-         ("C-c g" . counsel-git)
-         ("C-c j" . counsel-git-grep)
-         ("C-c k" . counsel-ag)
-         ("C-x l" . counsel-locate)
-         ("M-y" . counsel-yank-pop)))
-
-(use-package flycheck
-  :defer 2
-  :config (global-flycheck-mode))
-
-(use-package ivy
-  :defer 1
-  :bind (("C-c C-r" . ivy-resume)
-         ("C-x C-b" . ivy-switch-buffer)
-         :map ivy-minibuffer-map
-         ("C-j" . ivy-call))
-  :diminish ivy-mode
-  :commands ivy-mode
-  :config
-  (ivy-mode 1))
-
-(use-package magit
-  :defer
-  :if (executable-find "git")
-  :bind (("C-x g" . magit-status)
-         ("C-x G" . magit-dispatch-popup))
-  :init
-  (setq magit-completing-read-function 'ivy-completing-read))
-
-(use-package projectile
-  :commands projectile-mode
-  :bind-keymap ("C-c p" . projectile-command-map)
-  :defer 5
-  :config
-  (projectile-global-mode))
-    '';
-    myEmacs = emacsWithPackages (epkgs: (with epkgs.melpaStablePackages; [
-      (runCommand "default.el" {} ''
-mkdir -p $out/share/emacs/site-lisp
-cp ${myEmacsConfig} $out/share/emacs/site-lisp/default.el
-'')
-      company
-      counsel
-      flycheck
-      ivy
-      magit
-      projectile
-      use-package
-    ]));
-  };
-}
-</screen>
-
-  <para>
-   This provides a fairly full Emacs start file. It will load in addition to the user's presonal config. You can always disable it by passing <command>-q</command> to the Emacs command.
-  </para>
-
-  <para>
-   Sometimes <varname>emacsWithPackages</varname> is not enough, as this package set has some priorities imposed on packages (with the lowest priority assigned to Melpa Unstable, and the highest for packages manually defined in <filename>pkgs/top-level/emacs-packages.nix</filename>). But you can't control this priorities when some package is installed as a dependency. You can override it on per-package-basis, providing all the required dependencies manually - but it's tedious and there is always a possibility that an unwanted dependency will sneak in through some other package. To completely override such a package you can use <varname>overrideScope'</varname>.
-  </para>
-
-<screen>
-overrides = self: super: rec {
-  haskell-mode = self.melpaPackages.haskell-mode;
-  ...
-};
-((emacsPackagesGen emacs).overrideScope' overrides).emacsWithPackages (p: with p; [
-  # here both these package will use haskell-mode of our own choice
-  ghc-mod
-  dante
-])
-</screen>
- </section>
-</section>

doc/builders/packages/ibus.xml

@@ -1,57 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-ibus-typing-booster">
- <title>ibus-engines.typing-booster</title>
-
- <para>
-  This package is an ibus-based completion method to speed up typing.
- </para>
-
- <section xml:id="sec-ibus-typing-booster-activate">
-  <title>Activating the engine</title>
-
-  <para>
-   IBus needs to be configured accordingly to activate <literal>typing-booster</literal>. The configuration depends on the desktop manager in use. For detailed instructions, please refer to the <link xlink:href="https://mike-fabian.github.io/ibus-typing-booster/documentation.html">upstream docs</link>.
-  </para>
-
-  <para>
-   On NixOS you need to explicitly enable <literal>ibus</literal> with given engines before customizing your desktop to use <literal>typing-booster</literal>. This can be achieved using the <literal>ibus</literal> module:
-<programlisting>{ pkgs, ... }: {
-  i18n.inputMethod = {
-    enabled = "ibus";
-    ibus.engines = with pkgs.ibus-engines; [ typing-booster ];
-  };
-}</programlisting>
-  </para>
- </section>
-
- <section xml:id="sec-ibus-typing-booster-customize-hunspell">
-  <title>Using custom hunspell dictionaries</title>
-
-  <para>
-   The IBus engine is based on <literal>hunspell</literal> to support completion in many languages. By default the dictionaries <literal>de-de</literal>, <literal>en-us</literal>, <literal>fr-moderne</literal> <literal>es-es</literal>, <literal>it-it</literal>, <literal>sv-se</literal> and <literal>sv-fi</literal> are in use. To add another dictionary, the package can be overridden like this:
-<programlisting>ibus-engines.typing-booster.override {
-  langs = [ "de-at" "en-gb" ];
-}</programlisting>
-  </para>
-
-  <para>
-   <emphasis>Note: each language passed to <literal>langs</literal> must be an attribute name in <literal>pkgs.hunspellDicts</literal>.</emphasis>
-  </para>
- </section>
-
- <section xml:id="sec-ibus-typing-booster-emoji-picker">
-  <title>Built-in emoji picker</title>
-
-  <para>
-   The <literal>ibus-engines.typing-booster</literal> package contains a program named <literal>emoji-picker</literal>. To display all emojis correctly, a special font such as <literal>noto-fonts-emoji</literal> is needed:
-  </para>
-
-  <para>
-   On NixOS it can be installed using the following expression:
-<programlisting>{ pkgs, ... }: {
-  fonts.fonts = with pkgs; [ noto-fonts-emoji ];
-}</programlisting>
-  </para>
- </section>
-</section>

doc/builders/packages/index.xml

@@ -1,25 +0,0 @@
-<chapter xmlns="http://docbook.org/ns/docbook"
-         xmlns:xi="http://www.w3.org/2001/XInclude"
-         xml:id="chap-packages">
- <title>Packages</title>
- <para>
-  This chapter contains information about how to use and maintain the Nix expressions for a number of specific packages, such as the Linux kernel or X.org.
- </para>
- <xi:include href="citrix.xml" />
- <xi:include href="dlib.xml" />
- <xi:include href="eclipse.xml" />
- <xi:include href="elm.xml" />
- <xi:include href="emacs.xml" />
- <xi:include href="ibus.xml" />
- <xi:include href="kakoune.xml" />
- <xi:include href="linux.xml" />
- <xi:include href="locales.xml" />
- <xi:include href="nginx.xml" />
- <xi:include href="opengl.xml" />
- <xi:include href="shell-helpers.xml" />
- <xi:include href="steam.xml" />
- <xi:include href="cataclysm-dda.section.xml" />
- <xi:include href="urxvt.xml" />
- <xi:include href="weechat.xml" />
- <xi:include href="xorg.xml" />
-</chapter>

doc/builders/packages/kakoune.xml

@@ -1,14 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-kakoune">
- <title>Kakoune</title>
-
- <para>
-  Kakoune can be built to autoload plugins:
-<programlisting>(kakoune.override {
-  configure = {
-    plugins = with pkgs.kakounePlugins; [ parinfer-rust ];
-  };
-})</programlisting>
- </para>
-</section>

doc/builders/packages/linux.xml

@@ -1,85 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-linux-kernel">
- <title>Linux kernel</title>
-
- <para>
-  The Nix expressions to build the Linux kernel are in <link
-xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel"><filename>pkgs/os-specific/linux/kernel</filename></link>.
- </para>
-
- <para>
-  The function that builds the kernel has an argument <varname>kernelPatches</varname> which should be a list of <literal>{name, patch, extraConfig}</literal> attribute sets, where <varname>name</varname> is the name of the patch (which is included in the kernel’s <varname>meta.description</varname> attribute), <varname>patch</varname> is the patch itself (possibly compressed), and <varname>extraConfig</varname> (optional) is a string specifying extra options to be concatenated to the kernel configuration file (<filename>.config</filename>).
- </para>
-
- <para>
-  The kernel derivation exports an attribute <varname>features</varname> specifying whether optional functionality is or isn’t enabled. This is used in NixOS to implement kernel-specific behaviour. For instance, if the kernel has the <varname>iwlwifi</varname> feature (i.e. has built-in support for Intel wireless chipsets), then NixOS doesn’t have to build the external <varname>iwlwifi</varname> package:
-<programlisting>
-modulesTree = [kernel]
-  ++ pkgs.lib.optional (!kernel.features ? iwlwifi) kernelPackages.iwlwifi
-  ++ ...;
-</programlisting>
- </para>
-
- <para>
-  How to add a new (major) version of the Linux kernel to Nixpkgs:
-  <orderedlist>
-   <listitem>
-    <para>
-     Copy the old Nix expression (e.g. <filename>linux-2.6.21.nix</filename>) to the new one (e.g. <filename>linux-2.6.22.nix</filename>) and update it.
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     Add the new kernel to <filename>all-packages.nix</filename> (e.g., create an attribute <varname>kernel_2_6_22</varname>).
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     Now we’re going to update the kernel configuration. First unpack the kernel. Then for each supported platform (<literal>i686</literal>, <literal>x86_64</literal>, <literal>uml</literal>) do the following:
-     <orderedlist>
-      <listitem>
-       <para>
-        Make an copy from the old config (e.g. <filename>config-2.6.21-i686-smp</filename>) to the new one (e.g. <filename>config-2.6.22-i686-smp</filename>).
-       </para>
-      </listitem>
-      <listitem>
-       <para>
-        Copy the config file for this platform (e.g. <filename>config-2.6.22-i686-smp</filename>) to <filename>.config</filename> in the kernel source tree.
-       </para>
-      </listitem>
-      <listitem>
-       <para>
-        Run <literal>make oldconfig ARCH=<replaceable>{i386,x86_64,um}</replaceable></literal> and answer all questions. (For the uml configuration, also add <literal>SHELL=bash</literal>.) Make sure to keep the configuration consistent between platforms (i.e. don’t enable some feature on <literal>i686</literal> and disable it on <literal>x86_64</literal>).
-       </para>
-      </listitem>
-      <listitem>
-       <para>
-        If needed you can also run <literal>make menuconfig</literal>:
-<screen>
-<prompt>$ </prompt>nix-env -i ncurses
-<prompt>$ </prompt>export NIX_CFLAGS_LINK=-lncurses
-<prompt>$ </prompt>make menuconfig ARCH=<replaceable>arch</replaceable></screen>
-       </para>
-      </listitem>
-      <listitem>
-       <para>
-        Copy <filename>.config</filename> over the new config file (e.g. <filename>config-2.6.22-i686-smp</filename>).
-       </para>
-      </listitem>
-     </orderedlist>
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     Test building the kernel: <literal>nix-build -A kernel_2_6_22</literal>. If it compiles, ship it! For extra credit, try booting NixOS with it.
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     It may be that the new kernel requires updating the external kernel modules and kernel-dependent packages listed in the <varname>linuxPackagesFor</varname> function in <filename>all-packages.nix</filename> (such as the NVIDIA drivers, AUFS, etc.). If the updated packages aren’t backwards compatible with older kernels, you may need to keep the older versions around.
-    </para>
-   </listitem>
-  </orderedlist>
- </para>
-</section>

doc/builders/packages/locales.xml

@@ -1,13 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="locales">
- <title>Locales</title>
-
- <para>
-  To allow simultaneous use of packages linked against different versions of <literal>glibc</literal> with different locale archive formats Nixpkgs patches <literal>glibc</literal> to rely on <literal>LOCALE_ARCHIVE</literal> environment variable.
- </para>
-
- <para>
-  On non-NixOS distributions this variable is obviously not set. This can cause regressions in language support or even crashes in some Nixpkgs-provided programs. The simplest way to mitigate this problem is exporting the <literal>LOCALE_ARCHIVE</literal> variable pointing to <literal>${glibcLocales}/lib/locale/locale-archive</literal>. The drawback (and the reason this is not the default) is the relatively large (a hundred MiB) size of the full set of locales. It is possible to build a custom set of locales by overriding parameters <literal>allLocales</literal> and <literal>locales</literal> of the package.
- </para>
-</section>

doc/builders/packages/nginx.xml

@@ -1,25 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-nginx">
- <title>Nginx</title>
-
- <para>
-  <link xlink:href="https://nginx.org/">Nginx</link> is a reverse proxy and lightweight webserver.
- </para>
-
- <section xml:id="sec-nginx-etag">
-  <title>ETags on static files served from the Nix store</title>
-
-  <para>
-   HTTP has a couple different mechanisms for caching to prevent clients from having to download the same content repeatedly if a resource has not changed since the last time it was requested. When nginx is used as a server for static files, it implements the caching mechanism based on the <link xlink:href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified"><literal>Last-Modified</literal></link> response header automatically; unfortunately, it works by using filesystem timestamps to determine the value of the <literal>Last-Modified</literal> header. This doesn't give the desired behavior when the file is in the Nix store, because all file timestamps are set to 0 (for reasons related to build reproducibility).
-  </para>
-
-  <para>
-   Fortunately, HTTP supports an alternative (and more effective) caching mechanism: the <link xlink:href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag"><literal>ETag</literal></link> response header. The value of the <literal>ETag</literal> header specifies some identifier for the particular content that the server is sending (e.g. a hash). When a client makes a second request for the same resource, it sends that value back in an <literal>If-None-Match</literal> header. If the ETag value is unchanged, then the server does not need to resend the content.
-  </para>
-
-  <para>
-   As of NixOS 19.09, the nginx package in Nixpkgs is patched such that when nginx serves a file out of <filename>/nix/store</filename>, the hash in the store path is used as the <literal>ETag</literal> header in the HTTP response, thus providing proper caching functionality. This happens automatically; you do not need to do modify any configuration to get this behavior.
-  </para>
- </section>
-</section>

doc/builders/packages/opengl.xml

@@ -1,9 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-opengl">
- <title>OpenGL</title>
-
- <para>
-  Packages that use OpenGL have NixOS desktop as their primary target. The current solution for loading the GPU-specific drivers is based on <literal>libglvnd</literal> and looks for the driver implementation in <literal>LD_LIBRARY_PATH</literal>. If you are using a non-NixOS GNU/Linux/X11 desktop with free software video drivers, consider launching OpenGL-dependent programs from Nixpkgs with Nixpkgs versions of <literal>libglvnd</literal> and <literal>mesa_drivers</literal> in <literal>LD_LIBRARY_PATH</literal>. For proprietary video drivers you might have luck with also adding the corresponding video driver package.
- </para>
-</section>

doc/builders/packages/shell-helpers.xml

@@ -1,25 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-shell-helpers">
- <title>Interactive shell helpers</title>
-
- <para>
-  Some packages provide the shell integration to be more useful. But unlike other systems, nix doesn't have a standard share directory location. This is why a bunch <command>PACKAGE-share</command> scripts are shipped that print the location of the corresponding shared folder. Current list of such packages is as following:
-  <itemizedlist>
-   <listitem>
-    <para>
-     <literal>autojump</literal>: <command>autojump-share</command>
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     <literal>fzf</literal>: <command>fzf-share</command>
-    </para>
-   </listitem>
-  </itemizedlist>
-  E.g. <literal>autojump</literal> can then used in the .bashrc like this:
-<screen>
-  source "$(autojump-share)/autojump.bash"
-</screen>
- </para>
-</section>

doc/builders/packages/steam.xml

@@ -1,125 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-steam">
- <title>Steam</title>
-
- <section xml:id="sec-steam-nix">
-  <title>Steam in Nix</title>
-
-  <para>
-   Steam is distributed as a <filename>.deb</filename> file, for now only as an i686 package (the amd64 package only has documentation). When unpacked, it has a script called <filename>steam</filename> that in Ubuntu (their target distro) would go to <filename>/usr/bin </filename>. When run for the first time, this script copies some files to the user's home, which include another script that is the ultimate responsible for launching the steam binary, which is also in $HOME.
-  </para>
-
-  <para>
-   Nix problems and constraints:
-   <itemizedlist>
-    <listitem>
-     <para>
-      We don't have <filename>/bin/bash</filename> and many scripts point there. Similarly for <filename>/usr/bin/python</filename> .
-     </para>
-    </listitem>
-    <listitem>
-     <para>
-      We don't have the dynamic loader in <filename>/lib </filename>.
-     </para>
-    </listitem>
-    <listitem>
-     <para>
-      The <filename>steam.sh</filename> script in $HOME can not be patched, as it is checked and rewritten by steam.
-     </para>
-    </listitem>
-    <listitem>
-     <para>
-      The steam binary cannot be patched, it's also checked.
-     </para>
-    </listitem>
-   </itemizedlist>
-  </para>
-
-  <para>
-   The current approach to deploy Steam in NixOS is composing a FHS-compatible chroot environment, as documented <link xlink:href="http://sandervanderburg.blogspot.nl/2013/09/composing-fhs-compatible-chroot.html">here</link>. This allows us to have binaries in the expected paths without disrupting the system, and to avoid patching them to work in a non FHS environment.
-  </para>
- </section>
-
- <section xml:id="sec-steam-play">
-  <title>How to play</title>
-
-  <para>
-   Use <programlisting>programs.steam.enable = true;</programlisting> if you want to add steam to systemPackages and also enable a few workarrounds aswell as Steam controller support or other Steam supported controllers such as the DualShock 4 or Nintendo Switch Pr.
-  </para>
- </section>
-
- <section xml:id="sec-steam-troub">
-  <title>Troubleshooting</title>
-
-  <para>
-   <variablelist>
-    <varlistentry>
-     <term>
-      Steam fails to start. What do I do?
-     </term>
-     <listitem>
-      <para>
-       Try to run
-<programlisting>strace steam</programlisting>
-       to see what is causing steam to fail.
-      </para>
-     </listitem>
-    </varlistentry>
-    <varlistentry>
-     <term>
-      Using the FOSS Radeon or nouveau (nvidia) drivers
-     </term>
-     <listitem>
-      <itemizedlist>
-       <listitem>
-        <para>
-         The <literal>newStdcpp</literal> parameter was removed since NixOS 17.09 and should not be needed anymore.
-        </para>
-       </listitem>
-       <listitem>
-        <para>
-         Steam ships statically linked with a version of libcrypto that conflics with the one dynamically loaded by radeonsi_dri.so. If you get the error
-<programlisting>steam.sh: line 713: 7842 Segmentation fault (core dumped)</programlisting>
-         have a look at <link xlink:href="https://github.com/NixOS/nixpkgs/pull/20269">this pull request</link>.
-        </para>
-       </listitem>
-      </itemizedlist>
-     </listitem>
-    </varlistentry>
-    <varlistentry>
-     <term>
-      Java
-     </term>
-     <listitem>
-      <orderedlist>
-       <listitem>
-        <para>
-         There is no java in steam chrootenv by default. If you get a message like
-<programlisting>/home/foo/.local/share/Steam/SteamApps/common/towns/towns.sh: line 1: java: command not found</programlisting>
-         You need to add
-<programlisting> steam.override { withJava = true; };</programlisting>
-         to your configuration.
-        </para>
-       </listitem>
-      </orderedlist>
-     </listitem>
-    </varlistentry>
-   </variablelist>
-  </para>
- </section>
-
- <section xml:id="sec-steam-run">
-  <title>steam-run</title>
-
-  <para>
-   The FHS-compatible chroot used for steam can also be used to run other linux games that expect a FHS environment. To do it, add
-<programlisting>pkgs.(steam.override {
-          nativeOnly = true;
-          newStdcpp = true;
-        }).run</programlisting>
-   to your configuration, rebuild, and run the game with
-<programlisting>steam-run ./foo</programlisting>
-  </para>
- </section>
-</section>

doc/builders/packages/unfree.xml

@@ -1,13 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="unfree-software">
- <title>Unfree software</title>
-
- <para>
-  All users of Nixpkgs are free software users, and many users (and developers) of Nixpkgs want to limit and tightly control their exposure to unfree software. At the same time, many users need (or want) to run some specific pieces of proprietary software. Nixpkgs includes some expressions for unfree software packages. By default unfree software cannot be installed and doesn’t show up in searches. To allow installing unfree software in a single Nix invocation one can export <literal>NIXPKGS_ALLOW_UNFREE=1</literal>. For a persistent solution, users can set <literal>allowUnfree</literal> in the Nixpkgs configuration.
- </para>
-
- <para>
-  Fine-grained control is possible by defining <literal>allowUnfreePredicate</literal> function in config; it takes the <literal>mkDerivation</literal> parameter attrset and returns <literal>true</literal> for unfree packages that should be allowed.
- </para>
-</section>

doc/builders/packages/urxvt.xml

@@ -1,115 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-urxvt">
- <title>Urxvt</title>
-
- <para>
-  Urxvt, also known as rxvt-unicode, is a highly customizable terminal emulator.
- </para>
-
- <section xml:id="sec-urxvt-conf">
-
-  <title>Configuring urxvt</title>
-
-  <para>
-   In <literal>nixpkgs</literal>, urxvt is provided by the package
-   <literal>rxvt-unicode</literal>. It can be configured to include your choice
-   of plugins, reducing its closure size from the default configuration which
-   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, ... }: {
-    plugins = with availablePlugins; [ perls resize-font vtwheel ];
-  };
-}
-</programlisting>
-   If the <literal>configure</literal> function returns an attrset without the
-   <literal>plugins</literal> attribute, <literal>availablePlugins</literal>
-   will be used automatically.
-  </para>
-
-  <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>
-  </para>
-
-  <para>
-   To get a list of all the plugins available, open the Nix REPL and run
-<screen>
-<prompt>$ </prompt>nix repl
-:l &lt;nixpkgs&gt;
-map (p: p.name) pkgs.rxvt-unicode.plugins
-</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>
-
-  <para>
-    In addition to <literal>plugins</literal> the options
-    <literal>extraDeps</literal> and <literal>perlDeps</literal> can be used
-    to install extra packages.
-    <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>
-
-    <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>
-  </para>
-
- </section>
-
- <section xml:id="sec-urxvt-pkg">
-
-  <title>Packaging urxvt plugins</title>
-
-  <para>
-   Urxvt plugins resides in
-   <literal>pkgs/applications/misc/rxvt-unicode-plugins</literal>.
-   To add a new plugin create an expression in a subdirectory and add the
-   package to the set in
-   <literal>pkgs/applications/misc/rxvt-unicode-plugins/default.nix</literal>.
-  </para>
-
-  <para>
-   A plugin can be any kind of derivation, the only requirement is that it
-   should always install perl scripts in <literal>$out/lib/urxvt/perl</literal>.
-   Look for existing plugins for examples.
-  </para>
-
-  <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>
-   This will make the urxvt wrapper pick up the dependency and set up the perl
-   path accordingly.
-  </para>
-
- </section>
-
-</section>

doc/builders/packages/weechat.xml

@@ -1,85 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-weechat">
- <title>Weechat</title>
-
- <para>
-  Weechat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration such as
-<programlisting>weechat.override {configure = {availablePlugins, ...}: {
-    plugins = with availablePlugins; [ python perl ];
-  }
-}</programlisting>
-  If the <literal>configure</literal> function returns an attrset without the <literal>plugins</literal> attribute, <literal>availablePlugins</literal> will be used automatically.
- </para>
-
- <para>
-  The plugins currently available are <literal>python</literal>, <literal>perl</literal>, <literal>ruby</literal>, <literal>guile</literal>, <literal>tcl</literal> and <literal>lua</literal>.
- </para>
-
- <para>
-  The python and perl plugins allows the addition of extra libraries. For instance, the <literal>inotify.py</literal> script in weechat-scripts requires D-Bus or libnotify, and the <literal>fish.py</literal> script requires pycrypto. To use these scripts, use the plugin's <literal>withPackages</literal> attribute:
-<programlisting>weechat.override { configure = {availablePlugins, ...}: {
-    plugins = with availablePlugins; [
-            (python.withPackages (ps: with ps; [ pycrypto python-dbus ]))
-        ];
-    };
-}
-</programlisting>
- </para>
-
- <para>
-  In order to also keep all default plugins installed, it is possible to use the following method:
-<programlisting>weechat.override { configure = { availablePlugins, ... }: {
-  plugins = builtins.attrValues (availablePlugins // {
-    python = availablePlugins.python.withPackages (ps: with ps; [ pycrypto python-dbus ]);
-  });
-}; }
-</programlisting>
- </para>
-
- <para>
-  WeeChat allows to set defaults on startup using the <literal>--run-command</literal>. The <literal>configure</literal> method can be used to pass commands to the program:
-<programlisting>weechat.override {
-  configure = { availablePlugins, ... }: {
-    init = ''
-      /set foo bar
-      /server add freenode chat.freenode.org
-    '';
-  };
-}</programlisting>
-  Further values can be added to the list of commands when running <literal>weechat --run-command "your-commands"</literal>.
- </para>
-
- <para>
-  Additionally it's possible to specify scripts to be loaded when starting <literal>weechat</literal>. These will be loaded before the commands from <literal>init</literal>:
-<programlisting>weechat.override {
-  configure = { availablePlugins, ... }: {
-    scripts = with pkgs.weechatScripts; [
-      weechat-xmpp weechat-matrix-bridge wee-slack
-    ];
-    init = ''
-      /set plugins.var.python.jabber.key "val"
-    '':
-  };
-}</programlisting>
- </para>
-
- <para>
-  In <literal>nixpkgs</literal> there's a subpackage which contains derivations for WeeChat scripts. Such derivations expect a <literal>passthru.scripts</literal> attribute which contains a list of all scripts inside the store path. Furthermore all scripts have to live in <literal>$out/share</literal>. An exemplary derivation looks like this:
-<programlisting>{ stdenv, fetchurl }:
-
-stdenv.mkDerivation {
-  name = "exemplary-weechat-script";
-  src = fetchurl {
-    url = "https://scripts.tld/your-scripts.tar.gz";
-    sha256 = "...";
-  };
-  passthru.scripts = [ "foo.py" "bar.lua" ];
-  installPhase = ''
-    mkdir $out/share
-    cp foo.py $out/share
-    cp bar.lua $out/share
-  '';
-}</programlisting>
- </para>
-</section>

doc/builders/packages/xorg.xml

@@ -1,34 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-xorg">
- <title>X.org</title>
-
- <para>
-  The Nix expressions for the X.org packages reside in <filename>pkgs/servers/x11/xorg/default.nix</filename>. This file is automatically generated from lists of tarballs in an X.org release. As such it should not be modified directly; rather, you should modify the lists, the generator script or the file <filename>pkgs/servers/x11/xorg/overrides.nix</filename>, in which you can override or add to the derivations produced by the generator.
- </para>
-
- <para>
-  The generator is invoked as follows:
-<screen>
-<prompt>$ </prompt>cd pkgs/servers/x11/xorg
-<prompt>$ </prompt>cat tarballs-7.5.list extra.list old.list \
-  | perl ./generate-expr-from-tarballs.pl
-</screen>
-  For each of the tarballs in the <filename>.list</filename> files, the script downloads it, unpacks it, and searches its <filename>configure.ac</filename> and <filename>*.pc.in</filename> files for dependencies. This information is used to generate <filename>default.nix</filename>. The generator caches downloaded tarballs between runs. Pay close attention to the <literal>NOT FOUND: <replaceable>name</replaceable></literal> messages at the end of the run, since they may indicate missing dependencies. (Some might be optional dependencies, however.)
- </para>
-
- <para>
-  A file like <filename>tarballs-7.5.list</filename> contains all tarballs in a X.org release. It can be generated like this:
-<screen>
-<prompt>$ </prompt>export i="mirror://xorg/X11R7.4/src/everything/"
-<prompt>$ </prompt>cat $(PRINT_PATH=1 nix-prefetch-url $i | tail -n 1) \
-  | perl -e 'while (&lt;>) { if (/(href|HREF)="([^"]*.bz2)"/) { print "$ENV{'i'}$2\n"; }; }' \
-  | sort > tarballs-7.4.list
-</screen>
-  <filename>extra.list</filename> contains libraries that aren’t part of X.org proper, but are closely related to it, such as <literal>libxcb</literal>. <filename>old.list</filename> contains some packages that were removed from X.org, but are still needed by some people or by other packages (such as <varname>imake</varname>).
- </para>
-
- <para>
-  If the expression for a package requires derivation attributes that the generator cannot figure out automatically (say, <varname>patches</varname> or a <varname>postInstall</varname> hook), you should modify <filename>pkgs/servers/x11/xorg/overrides.nix</filename>.
- </para>
-</section>

doc/builders/special.xml

@@ -1,10 +0,0 @@
-<chapter xmlns="http://docbook.org/ns/docbook"
-         xmlns:xi="http://www.w3.org/2001/XInclude"
-         xml:id="chap-special">
- <title>Special builders</title>
- <para>
-  This chapter describes several special builders.
- </para>
- <xi:include href="special/fhs-environments.xml" />
- <xi:include href="special/mkshell.xml" />
-</chapter>

doc/builders/trivial-builders.xml

@@ -1,90 +0,0 @@
-<chapter xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xmlns:xi="http://www.w3.org/2001/XInclude"
-         xml:id="chap-trivial-builders">
- <title>Trivial builders</title>
- <para>
-  Nixpkgs provides a couple of functions that help with building derivations. The most important one, <function>stdenv.mkDerivation</function>, has already been documented above. The following functions wrap <function>stdenv.mkDerivation</function>, making it easier to use in certain cases.
- </para>
- <variablelist>
-  <varlistentry xml:id="trivial-builder-runCommand">
-   <term>
-    <literal>runCommand</literal>
-   </term>
-   <listitem>
-    <para>
-     This takes three arguments, <literal>name</literal>, <literal>env</literal>, and <literal>buildCommand</literal>. <literal>name</literal> is just the name that Nix will append to the store path in the same way that <literal>stdenv.mkDerivation</literal> uses its <literal>name</literal> attribute. <literal>env</literal> is an attribute set specifying environment variables that will be set for this derivation. These attributes are then passed to the wrapped <literal>stdenv.mkDerivation</literal>. <literal>buildCommand</literal> specifies the commands that will be run to create this derivation. Note that you will need to create <literal>$out</literal> for Nix to register the command as successful.
-    </para>
-    <para>
-     An example of using <literal>runCommand</literal> is provided below.
-    </para>
-<programlisting>
-(import &lt;nixpkgs&gt; {}).runCommand "my-example" {} ''
-  echo My example command is running
-
-  mkdir $out
-
-  echo I can write data to the Nix store > $out/message
-
-  echo I can also run basic commands like:
-
-  echo ls
-  ls
-
-  echo whoami
-  whoami
-
-  echo date
-  date
-''
-</programlisting>
-   </listitem>
-  </varlistentry>
-  <varlistentry xml:id="trivial-builder-runCommandCC">
-   <term>
-    <literal>runCommandCC</literal>
-   </term>
-   <listitem>
-    <para>
-     This works just like <literal>runCommand</literal>. The only difference is that it also provides a C compiler in <literal>buildCommand</literal>’s environment. To minimize your dependencies, you should only use this if you are sure you will need a C compiler as part of running your command.
-    </para>
-   </listitem>
-  </varlistentry>
-  <varlistentry xml:id="trivial-builder-runCommandLocal">
-   <term>
-    <literal>runCommandLocal</literal>
-   </term>
-   <listitem>
-    <para>
-     Variant of <literal>runCommand</literal> that forces the derivation to be built locally, it is not substituted. This is intended for very cheap commands (&lt;1s execution time). It saves on the network roundrip and can speed up a build.
-    </para>
-    <note><para>
-      This sets <link xlink:href="https://nixos.org/nix/manual/#adv-attr-allowSubstitutes"><literal>allowSubstitutes</literal> to <literal>false</literal></link>, so only use <literal>runCommandLocal</literal> if you are certain the user will always have a builder for the <literal>system</literal> of the derivation. This should be true for most trivial use cases (e.g. just copying some files to a different location or adding symlinks), because there the <literal>system</literal> is usually the same as <literal>builtins.currentSystem</literal>.
-    </para></note>
-   </listitem>
-  </varlistentry>
-  <varlistentry xml:id="trivial-builder-writeText">
-   <term>
-    <literal>writeTextFile</literal>, <literal>writeText</literal>, <literal>writeTextDir</literal>, <literal>writeScript</literal>, <literal>writeScriptBin</literal>
-   </term>
-   <listitem>
-    <para>
-     These functions write <literal>text</literal> to the Nix store. This is useful for creating scripts from Nix expressions. <literal>writeTextFile</literal> takes an attribute set and expects two arguments, <literal>name</literal> and <literal>text</literal>. <literal>name</literal> corresponds to the name used in the Nix store path. <literal>text</literal> will be the contents of the file. You can also set <literal>executable</literal> to true to make this file have the executable bit set.
-    </para>
-    <para>
-     Many more commands wrap <literal>writeTextFile</literal> including <literal>writeText</literal>, <literal>writeTextDir</literal>, <literal>writeScript</literal>, and <literal>writeScriptBin</literal>. These are convenience functions over <literal>writeTextFile</literal>.
-    </para>
-   </listitem>
-  </varlistentry>
-  <varlistentry xml:id="trivial-builder-symlinkJoin">
-   <term>
-    <literal>symlinkJoin</literal>
-   </term>
-   <listitem>
-    <para>
-     This can be used to put many derivations into the same directory structure. It works by creating a new derivation and adding symlinks to each of the paths listed. It expects two arguments, <literal>name</literal>, and <literal>paths</literal>. <literal>name</literal> is the name used in the Nix store path for the created derivation. <literal>paths</literal> is a list of paths that will be symlinked. These paths can be to Nix store derivations or any other subdirectory contained within.
-    </para>
-   </listitem>
-  </varlistentry>
- </variablelist>
-</chapter>

doc/coding-conventions.xml

@@ -620,16 +620,6 @@ args.stdenv.mkDerivation (args // {
          </para>
         </listitem>
        </varlistentry>
-       <varlistentry>
-        <term>
-         If it’s an <emphasis>icon theme</emphasis>:
-        </term>
-        <listitem>
-         <para>
-          <filename>data/icons</filename>
-         </para>
-        </listitem>
-       </varlistentry>
        <varlistentry>
         <term>
          If it’s related to <emphasis>SGML/XML processing</emphasis>:
@@ -662,17 +652,6 @@ args.stdenv.mkDerivation (args // {
          </variablelist>
         </listitem>
        </varlistentry>
-       <varlistentry>
-        <term>
-         If it’s a <emphasis>theme</emphasis> for a <emphasis>desktop environment</emphasis>,
-         a <emphasis>window manager</emphasis> or a <emphasis>display manager</emphasis>:
-        </term>
-        <listitem>
-         <para>
-          <filename>data/themes</filename>
-         </para>
-        </listitem>
-       </varlistentry>
       </variablelist>
      </listitem>
     </varlistentry>

doc/configuration.xml

@@ -45,7 +45,7 @@
   However, this does not allow unfree software for individual users. Their configurations are managed separately.
  </para>
  <para>
-  A user's nixpkgs configuration is stored in a user-specific configuration file located at <filename>~/.config/nixpkgs/config.nix</filename>. For example:
+  A user's of nixpkgs configuration is stored in a user-specific configuration file located at <filename>~/.config/nixpkgs/config.nix</filename>. For example:
 <programlisting>
 {
   allowUnfree = true;
@@ -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:
-<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_BROKEN=1</screen>
+<programlisting>$ export NIXPKGS_ALLOW_BROKEN=1</programlisting>
     </para>
    </listitem>
    <listitem>
@@ -85,19 +85,19 @@
   <title>Installing packages on unsupported systems</title>
 
   <para>
-   There are also two ways to try compiling a package which has been marked as unsupported for the given system.
+   There are also two ways to try compiling a package which has been marked as unsuported for the given system.
   </para>
 
   <itemizedlist>
    <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:
-<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1</screen>
+     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_UNSUPPORTED_SYSTEM=1</programlisting>
     </para>
    </listitem>
    <listitem>
     <para>
-     For permanently allowing unsupported packages to be built, you may add <literal>allowUnsupportedSystem = true;</literal> to your user's configuration file, like this:
+     For permanently allowing broken packages to be built, you may add <literal>allowUnsupportedSystem = true;</literal> to your user's configuration file, like this:
 <programlisting>
 {
   allowUnsupportedSystem = true;
@@ -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:
-<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_UNFREE=1</screen>
+<programlisting>$ export NIXPKGS_ALLOW_UNFREE=1</programlisting>
     </para>
    </listitem>
    <listitem>
@@ -141,10 +141,11 @@
      For a more useful example, try the following. This configuration only allows unfree packages named flash player and visual studio code:
 <programlisting>
 {
-  allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [
-    "flashplayer"
-    "vscode"
-  ];
+  allowUnfreePredicate = (pkg: builtins.elem
+    (builtins.parseDrvName pkg.name).name [
+      "flashplayer"
+      "vscode"
+    ]);
 }
 </programlisting>
     </para>
@@ -162,10 +163,10 @@
 </programlisting>
     </para>
     <para>
-     The following example configuration blacklists the <literal>gpl3Only</literal> and <literal>agpl3Only</literal> licenses:
+     The following example configuration blacklists the <literal>gpl3</literal> and <literal>agpl3</literal> licenses:
 <programlisting>
 {
-  blacklistedLicenses = with stdenv.lib.licenses; [ agpl3Only gpl3Only ];
+  blacklistedLicenses = with stdenv.lib.licenses; [ agpl3 gpl3 ];
 }
 </programlisting>
     </para>
@@ -187,7 +188,7 @@
    <listitem>
     <para>
      To temporarily allow all insecure packages, you can use an environment variable for a single invocation of the nix tools:
-<screen><prompt>$ </prompt>export NIXPKGS_ALLOW_INSECURE=1</screen>
+<programlisting>$ export NIXPKGS_ALLOW_INSECURE=1</programlisting>
     </para>
    </listitem>
    <listitem>
@@ -216,7 +217,7 @@
      The following configuration example only allows insecure packages with very short names:
 <programlisting>
 {
-  allowInsecurePredicate = pkg: builtins.stringLength (lib.getName pkg) &lt;= 5;
+  allowInsecurePredicate = (pkg: (builtins.stringLength (builtins.parseDrvName pkg.name).name) &lt;= 5);
 }
 </programlisting>
     </para>
@@ -387,7 +388,7 @@ fi
 </screen>
 
    <para>
-    Now just run <literal>source $HOME/.profile</literal> and you can starting loading man pages from your environment.
+    Now just run <literal>source $HOME/.profile</literal> and you can starting loading man pages from your environent.
    </para>
   </section>
 

doc/contributing/submitting-changes.xml

@@ -1,455 +0,0 @@
-<chapter xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="chap-submitting-changes">
- <title>Submitting changes</title>
- <section xml:id="submitting-changes-making-patches">
-  <title>Making patches</title>
-
-  <itemizedlist>
-   <listitem>
-    <para>
-     Read <link xlink:href="https://nixos.org/nixpkgs/manual/">Manual (How to write packages for Nix)</link>.
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     Fork <link xlink:href="https://github.com/nixos/nixpkgs/">the Nixpkgs repository</link> on GitHub.
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     Create a branch for your future fix.
-     <itemizedlist>
-      <listitem>
-       <para>
-        You can make branch from a commit of your local <command>nixos-version</command>. That will help you to avoid additional local compilations. Because you will receive packages from binary cache. For example
-<screen>
-<prompt>$ </prompt>nixos-version --hash
-0998212
-<prompt>$ </prompt>git checkout 0998212
-<prompt>$ </prompt>git checkout -b 'fix/pkg-name-update'
-</screen>
-       </para>
-      </listitem>
-      <listitem>
-       <para>
-        Please avoid working directly on the <command>master</command> branch.
-       </para>
-      </listitem>
-     </itemizedlist>
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     Make commits of logical units.
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     If you removed pkgs or made some major NixOS changes, write about it in the release notes for the next stable release. For example <command>nixos/doc/manual/release-notes/rl-2003.xml</command>.
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     Check for unnecessary whitespace with <command>git diff --check</command> before committing.
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     Format the commit in a following way:
-    </para>
-<programlisting>
-(pkg-name | nixos/&lt;module>): (from -> to | init at version | refactor | etc)
-Additional information.
-</programlisting>
-    <itemizedlist>
-     <listitem>
-      <para>
-       Examples:
-       <itemizedlist>
-        <listitem>
-         <para>
-          <command>nginx: init at 2.0.1</command>
-         </para>
-        </listitem>
-        <listitem>
-         <para>
-          <command>firefox: 54.0.1 -> 55.0</command>
-         </para>
-        </listitem>
-        <listitem>
-         <para>
-          <command>nixos/hydra: add bazBaz option</command>
-         </para>
-        </listitem>
-        <listitem>
-         <para>
-          <command>nixos/nginx: refactor config generation</command>
-         </para>
-        </listitem>
-       </itemizedlist>
-      </para>
-     </listitem>
-    </itemizedlist>
-   </listitem>
-   <listitem>
-    <para>
-     Test your changes. If you work with
-     <itemizedlist>
-      <listitem>
-       <para>
-        nixpkgs:
-        <itemizedlist>
-         <listitem>
-          <para>
-           update pkg ->
-           <itemizedlist>
-            <listitem>
-             <para>
-              <command>nix-env -i pkg-name -f &lt;path to your local nixpkgs folder&gt;</command>
-             </para>
-            </listitem>
-           </itemizedlist>
-          </para>
-         </listitem>
-         <listitem>
-          <para>
-           add pkg ->
-           <itemizedlist>
-            <listitem>
-             <para>
-              Make sure it's in <command>pkgs/top-level/all-packages.nix</command>
-             </para>
-            </listitem>
-            <listitem>
-             <para>
-              <command>nix-env -i pkg-name -f &lt;path to your local nixpkgs folder&gt;</command>
-             </para>
-            </listitem>
-           </itemizedlist>
-          </para>
-         </listitem>
-         <listitem>
-          <para>
-           <emphasis>If you don't want to install pkg in you profile</emphasis>.
-           <itemizedlist>
-            <listitem>
-             <para>
-              <command>nix-build -A pkg-attribute-name &lt;path to your local nixpkgs folder&gt;/default.nix</command> and check results in the folder <command>result</command>. It will appear in the same directory where you did <command>nix-build</command>.
-             </para>
-            </listitem>
-           </itemizedlist>
-          </para>
-         </listitem>
-         <listitem>
-          <para>
-           If you did <command>nix-env -i pkg-name</command> you can do <command>nix-env -e pkg-name</command> to uninstall it from your system.
-          </para>
-         </listitem>
-        </itemizedlist>
-       </para>
-      </listitem>
-      <listitem>
-       <para>
-        NixOS and its modules:
-        <itemizedlist>
-         <listitem>
-          <para>
-           You can add new module to your NixOS configuration file (usually it's <command>/etc/nixos/configuration.nix</command>). And do <command>sudo nixos-rebuild test -I nixpkgs=&lt;path to your local nixpkgs folder&gt; --fast</command>.
-          </para>
-         </listitem>
-        </itemizedlist>
-       </para>
-      </listitem>
-     </itemizedlist>
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     If you have commits <command>pkg-name: oh, forgot to insert whitespace</command>: squash commits in this case. Use <command>git rebase -i</command>.
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     <link xlink:href="https://git-scm.com/book/en/v2/Git-Branching-Rebasing">Rebase</link> your branch against current <command>master</command>.
-    </para>
-   </listitem>
-  </itemizedlist>
- </section>
- <section xml:id="submitting-changes-submitting-changes">
-  <title>Submitting changes</title>
-
-  <itemizedlist>
-   <listitem>
-    <para>
-     Push your changes to your fork of nixpkgs.
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     Create the pull request
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     Follow <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md#submitting-changes">the contribution guidelines</link>.
-    </para>
-   </listitem>
-  </itemizedlist>
- </section>
- <section xml:id="submitting-changes-submitting-security-fixes">
-  <title>Submitting security fixes</title>
-
-  <para>
-   Security fixes are submitted in the same way as other changes and thus the same guidelines apply.
-  </para>
-
-  <para>
-   If the security fix comes in the form of a patch and a CVE is available, then the name of the patch should be the CVE identifier, so e.g. <literal>CVE-2019-13636.patch</literal> in the case of a patch that is included in the Nixpkgs tree. If a patch is fetched the name needs to be set as well, e.g.:
-  </para>
-
-<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.
-  </para>
-
-  <para>
-   Critical security fixes may by-pass the staging branches and be delivered directly to release branches such as <literal>master</literal> and <literal>release-*</literal>.
-  </para>
- </section>
- <section xml:id="submitting-changes-pull-request-template">
-  <title>Pull Request Template</title>
-
-  <para>
-   The pull request template helps determine what steps have been made for a contribution so far, and will help guide maintainers on the status of a change. The motivation section of the PR should include any extra details the title does not address and link any existing issues related to the pull request.
-  </para>
-
-  <para>
-   When a PR is created, it will be pre-populated with some checkboxes detailed below:
-  </para>
-
-  <section xml:id="submitting-changes-tested-with-sandbox">
-   <title>Tested using sandboxing</title>
-
-   <para>
-    When sandbox builds are enabled, Nix will setup an isolated environment for each build process. It is used to remove further hidden dependencies set by the build environment to improve reproducibility. This includes access to the network during the build outside of <function>fetch*</function> functions and files outside the Nix store. Depending on the operating system access to other resources are blocked as well (ex. inter process communication is isolated on Linux); see <link
-      xlink:href="https://nixos.org/nix/manual/#conf-sandbox">sandbox</link> in Nix manual for details.
-   </para>
-
-   <para>
-    Sandboxing is not enabled by default in Nix due to a small performance hit on each build. In pull requests for <link
-        xlink:href="https://github.com/NixOS/nixpkgs/">nixpkgs</link> people are asked to test builds with sandboxing enabled (see <literal>Tested using sandboxing</literal> in the pull request template) because in<link
-        xlink:href="https://nixos.org/hydra/">https://nixos.org/hydra/</link> sandboxing is also used.
-   </para>
-
-   <para>
-    Depending if you use NixOS or other platforms you can use one of the following methods to enable sandboxing <emphasis role="bold">before</emphasis> building the package:
-    <itemizedlist>
-     <listitem>
-      <para>
-       <emphasis role="bold">Globally enable sandboxing on NixOS</emphasis>: add the following to <filename>configuration.nix</filename>
-<screen>nix.useSandbox = true;</screen>
-      </para>
-     </listitem>
-     <listitem>
-      <para>
-       <emphasis role="bold">Globally enable sandboxing on non-NixOS platforms</emphasis>: add the following to: <filename>/etc/nix/nix.conf</filename>
-<screen>sandbox = true</screen>
-      </para>
-     </listitem>
-    </itemizedlist>
-   </para>
-  </section>
-
-  <section xml:id="submitting-changes-platform-diversity">
-   <title>Built on platform(s)</title>
-
-   <para>
-    Many Nix packages are designed to run on multiple platforms. As such, it's important to let the maintainer know which platforms your changes have been tested on. It's not always practical to test a change on all platforms, and is not required for a pull request to be merged. Only check the systems you tested the build on in this section.
-   </para>
-  </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>
-    Packages with automated tests are much more likely to be merged in a timely fashion because it doesn't require as much manual testing by the maintainer to verify the functionality of the package. If there are existing tests for the package, they should be run to verify your changes do not break the tests. Tests only apply to packages with NixOS modules defined and can only be run on Linux. For more details on writing and running tests, see the <link
-        xlink:href="https://nixos.org/nixos/manual/index.html#sec-nixos-tests">section in the NixOS manual</link>.
-   </para>
-  </section>
-
-  <section xml:id="submitting-changes-tested-compilation">
-   <title>Tested compilation of all pkgs that depend on this change using <command>nixpkgs-review</command></title>
-
-   <para>
-    If you are updating a package's version, you can use nixpkgs-review to make sure all packages that depend on the updated package still compile correctly. The <command>nixpkgs-review</command> utility can look for and build all dependencies either based on uncommited changes with the <literal>wip</literal> option or specifying a github pull request number.
-   </para>
-
-   <para>
-    review changes from pull request number 12345:
-    <screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review pr 12345</screen>
-   </para>
-
-   <para>
-    review uncommitted changes:
-    <screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review wip</screen>
-   </para>
-
-   <para>
-    review changes from last commit:
-    <screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review rev HEAD</screen>
-   </para>
-  </section>
-
-  <section xml:id="submitting-changes-tested-execution">
-   <title>Tested execution of all binary files (usually in <filename>./result/bin/</filename>)</title>
-
-   <para>
-    It's important to test any executables generated by a build when you change or create a package in nixpkgs. This can be done by looking in <filename>./result/bin</filename> and running any files in there, or at a minimum, the main executable for the package. For example, if you make a change to <package>texlive</package>, you probably would only check the binaries associated with the change you made rather than testing all of them.
-   </para>
-  </section>
-
-  <section xml:id="submitting-changes-contribution-standards">
-   <title>Meets Nixpkgs contribution standards</title>
-
-   <para>
-    The last checkbox is fits <link
-        xlink:href="https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md">CONTRIBUTING.md</link>. The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
-   </para>
-  </section>
- </section>
- <section xml:id="submitting-changes-hotfixing-pull-requests">
-  <title>Hotfixing pull requests</title>
-
-  <itemizedlist>
-   <listitem>
-    <para>
-     Make the appropriate changes in you branch.
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     Don't create additional commits, do
-     <itemizedlist>
-      <listitem>
-       <para>
-        <command>git rebase -i</command>
-       </para>
-      </listitem>
-      <listitem>
-       <para>
-        <command>git push --force</command> to your branch.
-       </para>
-      </listitem>
-     </itemizedlist>
-    </para>
-   </listitem>
-  </itemizedlist>
- </section>
- <section xml:id="submitting-changes-commit-policy">
-  <title>Commit policy</title>
-
-  <itemizedlist>
-   <listitem>
-    <para>
-     Commits must be sufficiently tested before being merged, both for the master and staging branches.
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     Hydra builds for master and staging should not be used as testing platform, it's a build farm for changes that have been already tested.
-    </para>
-   </listitem>
-   <listitem>
-    <para>
-     When changing the bootloader installation process, extra care must be taken. Grub installations cannot be rolled back, hence changes may break people's installations forever. For any non-trivial change to the bootloader please file a PR asking for review, especially from @edolstra.
-    </para>
-   </listitem>
-  </itemizedlist>
-
-  <section xml:id="submitting-changes-master-branch">
-   <title>Master branch</title>
-   <para>
-    The <literal>master</literal> branch is the main development branch.
-    It should only see non-breaking commits that do not cause mass rebuilds.
-   </para>
-  </section>
-
-  <section xml:id="submitting-changes-staging-branch">
-   <title>Staging branch</title>
-   <para>
-    The <literal>staging</literal> branch is a development branch where mass-rebuilds go.
-    It should only see non-breaking mass-rebuild commits.
-    That means it is not to be used for testing, and changes must have been well tested already.
-    If the branch is already in a broken state, please refrain from adding extra new breakages.
-   </para>
-  </section>
-
-  <section xml:id="submitting-changes-staging-next-branch">
-   <title>Staging-next branch</title>
-   <para>
-    The <literal>staging-next</literal> branch is for stabilizing mass-rebuilds submitted to the <literal>staging</literal> branch prior to merging them into <literal>master</literal>.
-    Mass-rebuilds should go via the <literal>staging</literal> branch.
-    It should only see non-breaking commits that are fixing issues blocking it from being merged into the <literal>master </literal> branch.
-   </para>
-   <para>
-    If the branch is already in a broken state, please refrain from adding extra new breakages. Stabilize it for a few days and then merge into master.
-   </para>
-  </section>
-
-  <section xml:id="submitting-changes-stable-release-branches">
-   <title>Stable release branches</title>
-
-   <para>
-    For cherry-picking a commit to a stable release branch (<quote>backporting</quote>), use <literal>git cherry-pick -x &lt;original commit&gt;</literal> so that the original commit id is included in the commit.
-   </para>
-
-   <para>
-    Add a reason for the backport by using <literal>git cherry-pick -xe &lt;original commit&gt;</literal> instead when it is not obvious from the original commit message. It is not needed when it’s a minor version update that includes security and bug fixes but don’t add new features or when the commit fixes an otherwise broken package.
-   </para>
-
-   <para>
-    Here is an example of a cherry-picked commit message with good reason description:
-   </para>
-
-<screen>
-zfs: Keep trying root import until it works
-
-Works around #11003.
-
-(cherry picked from commit 98b213a11041af39b39473906b595290e2a4e2f9)
-
-Reason: several people cannot boot with ZFS on NVMe
-</screen>
-
-   <para>
-    Other examples of reasons are:
-   </para>
-
-   <itemizedlist spacing="compact">
-    <listitem>
-     <para>
-      Previously the build would fail due to, e.g., <literal>getaddrinfo</literal> not being defined
-     </para>
-    </listitem>
-    <listitem>
-     <para>
-      The previous download links were all broken
-     </para>
-    </listitem>
-    <listitem>
-     <para>
-      Crash when starting on some X11 systems
-     </para>
-    </listitem>
-   </itemizedlist>
-  </section>
- </section>
-</chapter>

doc/cross-compilation.xml

@@ -244,7 +244,7 @@
      </question>
      <answer>
       <para>
-       Many packages assume that an unprefixed <command>ar</command> is available, but Nix doesn't provide one. It only provides a prefixed one, just as it only does for all the other binutils programs. It may be necessary to patch the package to fix the build system to use a prefixed <command>ar</command>.
+       Many packages assume that an unprefixed <command>ar</command> is available, but Nix doesn't provide one. It only provides a prefixed one, just as it only does for all the other binutils programs. It may be necessary to patch the package to fix the build system to use a prefixed `ar`.
       </para>
      </answer>
     </qandaentry>
@@ -256,7 +256,7 @@
      </question>
      <answer>
       <para>
-<programlisting>doCheck = stdenv.hostPlatform == stdenv.buildPlatfrom;</programlisting>
+<programlisting>doCheck = stdenv.hostPlatform != stdenv.buildPlatfrom;</programlisting>
        Add it to your <function>mkDerivation</function> invocation.
       </para>
      </answer>
@@ -271,14 +271,14 @@
   <para>
    Nixpkgs can be instantiated with <varname>localSystem</varname> alone, in which case there is no cross-compiling and everything is built by and for that system, or also with <varname>crossSystem</varname>, in which case packages run on the latter, but all building happens on the former. Both parameters take the same schema as the 3 (build, host, and target) platforms defined in the previous section. As mentioned above, <literal>lib.systems.examples</literal> has some platforms which are used as arguments for these parameters in practice. You can use them programmatically, or on the command line:
 <programlisting>
-nix-build '&lt;nixpkgs&gt;' --arg crossSystem '(import &lt;nixpkgs/lib&gt;).systems.examples.fooBarBaz' -A whatever</programlisting>
+nix-build &lt;nixpkgs&gt; --arg crossSystem '(import &lt;nixpkgs/lib&gt;).systems.examples.fooBarBaz' -A whatever</programlisting>
   </para>
 
   <note>
    <para>
     Eventually we would like to make these platform examples an unnecessary convenience so that
 <programlisting>
-nix-build '&lt;nixpkgs&gt;' --arg crossSystem '{ config = "&lt;arch&gt;-&lt;os&gt;-&lt;vendor&gt;-&lt;abi&gt;"; }' -A whatever</programlisting>
+nix-build &lt;nixpkgs&gt; --arg crossSystem '{ config = "&lt;arch&gt;-&lt;os&gt;-&lt;vendor&gt;-&lt;abi&gt;"; }' -A whatever</programlisting>
     works in the vast majority of cases. The problem today is dependencies on other sorts of configuration which aren't given proper defaults. We rely on the examples to crudely to set those configuration parameters in some vaguely sane manner on the users behalf. Issue <link xlink:href="https://github.com/NixOS/nixpkgs/issues/34274">#34274</link> tracks this inconvenience along with its root cause in crufty configuration options.
    </para>
   </note>
@@ -348,12 +348,12 @@ nix-build '&lt;nixpkgs&gt;' --arg crossSystem '{ config = "&lt;arch&gt;-&lt;os&g
       </para>
      </listitem>
     </orderedlist>
-    In each stage, <varname>pkgsBuildHost</varname> refers to the previous stage, <varname>pkgsBuildBuild</varname> refers to the one before that, and <varname>pkgsHostTarget</varname> refers to the current one, and <varname>pkgsTargetTarget</varname> refers to the next one. When there is no previous or next stage, they instead refer to the current stage. Note how all the invariants regarding the mapping between dependency and depending packages' build host and target platforms are preserved. <varname>pkgsBuildTarget</varname> and <varname>pkgsHostHost</varname> are more complex in that the stage fitting the requirements isn't always a fixed chain of "prevs" and "nexts" away (modulo the "saturating" self-references at the ends). We just special case each instead. All the primary edges are implemented is in <filename>pkgs/stdenv/booter.nix</filename>, and secondarily aliases in <filename>pkgs/top-level/stage.nix</filename>.
+    In each stage, <varname>pkgsBuildHost</varname> refers the the previous stage, <varname>pkgsBuildBuild</varname> refers to the one before that, and <varname>pkgsHostTarget</varname> refers to the current one, and <varname>pkgsTargetTarget</varname> refers to the next one. When there is no previous or next stage, they instead refer to the current stage. Note how all the invariants regarding the mapping between dependency and depending packages' build host and target platforms are preserved. <varname>pkgsBuildTarget</varname> and <varname>pkgsHostHost</varname> are more complex in that the stage fitting the requirements isn't always a fixed chain of "prevs" and "nexts" away (modulo the "saturating" self-references at the ends). We just special case each instead. All the primary edges are implemented is in <filename>pkgs/stdenv/booter.nix</filename>, and secondarily aliases in <filename>pkgs/top-level/stage.nix</filename>.
    </para>
 
    <note>
     <para>
-     Note the native stages are bootstrapped in legacy ways that predate the current cross implementation. This is why the bootstrapping stages leading up to the final stages are ignored inthe previous paragraph.
+     Note the native stages are bootstrapped in legacy ways that predate the current cross implementation. This is why the the bootstrapping stages leading up to the final stages are ignored inthe previous paragraph.
     </para>
    </note>
 

doc/doc-support/parameters.xml

@@ -8,7 +8,7 @@
  <xsl:param name="html.script" select="'./highlightjs/highlight.pack.js ./highlightjs/loader.js'" />
  <xsl:param name="xref.with.number.and.title" select="1" />
  <xsl:param name="use.id.as.filename" select="1" />
- <xsl:param name="toc.section.depth" select="0" />
+ <xsl:param name="toc.section.depth" select="3" />
  <xsl:param name="admon.style" select="''" />
  <xsl:param name="callout.graphics.extension" select="'.svg'" />
 </xsl:stylesheet>

doc/functions.xml

@@ -7,8 +7,17 @@
   The nixpkgs repository has several utility functions to manipulate Nix expressions.
  </para>
  <xi:include href="functions/library.xml" />
+ <xi:include href="functions/overrides.xml" />
  <xi:include href="functions/generators.xml" />
  <xi:include href="functions/debug.xml" />
+ <xi:include href="functions/fetchers.xml" />
+ <xi:include href="functions/trivial-builders.xml" />
+ <xi:include href="functions/fhs-environments.xml" />
+ <xi:include href="functions/shell.xml" />
+ <xi:include href="functions/dockertools.xml" />
+ <xi:include href="functions/snaptools.xml" />
+ <xi:include href="functions/appimagetools.xml" />
  <xi:include href="functions/prefer-remote-fetch.xml" />
  <xi:include href="functions/nix-gitignore.xml" />
+ <xi:include href="functions/ocitools.xml" />
 </chapter>

doc/functions/appimagetools.xml

@@ -63,7 +63,7 @@ type2.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) (Lepton 3.x)
 appimageTools.wrapType2 { # or wrapType1
   name = "patchwork"; <co xml:id='ex-appimageTools-wrapping-1' />
   src = fetchurl { <co xml:id='ex-appimageTools-wrapping-2' />
-    url = "https://github.com/ssbc/patchwork/releases/download/v3.11.4/Patchwork-3.11.4-linux-x86_64.AppImage";
+    url = https://github.com/ssbc/patchwork/releases/download/v3.11.4/Patchwork-3.11.4-linux-x86_64.AppImage;
     sha256 =  "1blsprpkvm0ws9b96gb36f0rbf8f5jgmw4x6dsb1kswr4ysf591s";
   };
   extraPkgs = pkgs: with pkgs; [ ]; <co xml:id='ex-appimageTools-wrapping-3' />
@@ -80,7 +80,7 @@ appimageTools.wrapType2 { # or wrapType1
      <varname>src</varname> specifies the AppImage file to extract.
     </para>
    </callout>
-   <callout arearefs='ex-appimageTools-wrapping-3'>
+   <callout arearefs='ex-appimageTools-wrapping-2'>
     <para>
      <varname>extraPkgs</varname> allows you to pass a function to include additional packages inside the FHS environment your AppImage is going to run in. There are a few ways to learn which dependencies an application needs:
      <itemizedlist>

doc/functions/dockertools.xml

@@ -8,6 +8,12 @@
   <varname>pkgs.dockerTools</varname> is a set of functions for creating and manipulating Docker images according to the <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#docker-image-specification-v120"> Docker Image Specification v1.2.0 </link>. Docker itself is not used to perform any of the operations done by these functions.
  </para>
 
+ <warning>
+  <para>
+   The <varname>dockerTools</varname> API is unstable and may be subject to backwards-incompatible changes in the future.
+  </para>
+ </warning>
+
  <section xml:id="ssec-pkgs-dockerTools-buildImage">
   <title>buildImage</title>
 
@@ -132,11 +138,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>
-<prompt>$ </prompt>docker images
+<screen><![CDATA[
+$ 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 +158,11 @@ pkgs.dockerTools.buildImage {
 ]]></programlisting>
    <para>
     and now the Docker CLI will display a reasonable date and sort the images as expected:
-<screen>
-<prompt>$ </prompt>docker images
+<screen><![CDATA[
+$ 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>
@@ -166,7 +172,7 @@ hello        latest   de2bf4786de6   About a minute ago   25.2MB
   <title>buildLayeredImage</title>
 
   <para>
-   Create a Docker image with many of the store paths being on their own layer to improve sharing between images. The image is realized into the Nix store as a gzipped tarball. Depending on the intended usage, many users might prefer to use <function>streamLayeredImage</function> instead, which this function uses internally.
+   Create a Docker image with many of the store paths being on their own layer to improve sharing between images.
   </para>
 
   <variablelist>
@@ -327,27 +333,6 @@ pkgs.dockerTools.buildLayeredImage {
   </section>
  </section>
 
- <section xml:id="ssec-pkgs-dockerTools-streamLayeredImage">
-  <title>streamLayeredImage</title>
-
-  <para>
-   Builds a script which, when run, will stream an uncompressed tarball of a Docker image to stdout. The arguments to this function are as for <function>buildLayeredImage</function>. This method of constructing an image does not realize the image into the Nix store, so it saves on IO and disk/cache space, particularly with large images.
-  </para>
-
-  <para>
-    The image produced by running the output script can be piped directly into <command>docker load</command>, to load it into the local docker daemon:
-    <screen><![CDATA[
-$(nix-build) | docker load
-    ]]></screen>
-  </para>
-  <para>
-    Alternatively, the image be piped via <command>gzip</command> into <command>skopeo</command>, e.g. to copy it into a registry:
-    <screen><![CDATA[
-$(nix-build) | gzip --fast | skopeo copy docker-archive:/dev/stdin docker://some_docker_registry/myimage:tag
-    ]]></screen>
-  </para>
- </section>
-
  <section xml:id="ssec-pkgs-dockerTools-fetchFromRegistry">
   <title>pullImage</title>
 

doc/functions/fetchers.xml

@@ -1,14 +1,17 @@
-<chapter xmlns="http://docbook.org/ns/docbook"
+<section xmlns="http://docbook.org/ns/docbook"
          xmlns:xlink="http://www.w3.org/1999/xlink"
          xmlns:xi="http://www.w3.org/2001/XInclude"
-         xml:id="chap-pkgs-fetchers">
- <title>Fetchers</title>
+         xml:id="sec-pkgs-fetchers">
+ <title>Fetcher functions</title>
+
  <para>
   When using Nix, you will frequently need to download source code and other files from the internet. Nixpkgs comes with a few helper functions that allow you to fetch fixed-output derivations in a structured way.
  </para>
+
  <para>
   The two fetcher primitives are <function>fetchurl</function> and <function>fetchzip</function>. Both of these have two required arguments, a URL and a hash. The hash is typically <literal>sha256</literal>, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use <literal>sha256</literal>. This hash will be used by Nix to identify your source. A typical usage of fetchurl is provided below.
  </para>
+
 <programlisting><![CDATA[
 { stdenv, fetchurl }:
 
@@ -20,15 +23,19 @@ stdenv.mkDerivation {
   };
 }
 ]]></programlisting>
+
  <para>
   The main difference between <function>fetchurl</function> and <function>fetchzip</function> is in how they store the contents. <function>fetchurl</function> will store the unaltered contents of the URL within the Nix store. <function>fetchzip</function> on the other hand will decompress the archive for you, making files and directories directly accessible in the future. <function>fetchzip</function> can only be used with archives. Despite the name, <function>fetchzip</function> is not limited to .zip files and can also be used with any tarball.
  </para>
+
  <para>
   <function>fetchpatch</function> works very similarly to <function>fetchurl</function> with the same arguments expected. It expects patch files as a source and and performs normalization on them before computing the checksum. For example it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
  </para>
+
  <para>
   Other fetcher functions allow you to add source code directly from a VCS such as subversion or git. These are mostly straightforward names based on the name of the command used with the VCS system. Because they give you a working repository, they act most like <function>fetchzip</function>.
  </para>
+
  <variablelist>
   <varlistentry>
    <term>
@@ -81,9 +88,11 @@ stdenv.mkDerivation {
    </listitem>
   </varlistentry>
  </variablelist>
+
  <para>
   A number of fetcher functions wrap part of <function>fetchurl</function> and <function>fetchzip</function>. They are mainly convenience functions intended for commonly used destinations of source code in Nixpkgs. These wrapper fetchers are listed below.
  </para>
+
  <variablelist>
   <varlistentry>
    <term>
@@ -105,17 +114,6 @@ stdenv.mkDerivation {
     </para>
    </listitem>
   </varlistentry>
-  <varlistentry>
-   <term>
-    <literal>fetchFromGitiles</literal>
-   </term>
-   <listitem>
-    <para>
-     This is used with Gitiles repositories. The arguments expected
-     are similar to fetchgit.
-    </para>
-   </listitem>
-  </varlistentry>
   <varlistentry>
    <term>
     <literal>fetchFromBitbucket</literal>
@@ -147,4 +145,4 @@ stdenv.mkDerivation {
    </listitem>
   </varlistentry>
  </variablelist>
-</chapter>
+</section>

doc/functions/library/attrsets.xml

@@ -302,7 +302,7 @@ lib.attrsets.attrValues { a = 1; b = 2; c = 3; }
  <section xml:id="function-library-lib.attrsets.catAttrs">
   <title><function>lib.attrsets.catAttrs</function></title>
 
-  <subtitle><literal>catAttrs :: String -> [AttrSet] -> [Any]</literal>
+  <subtitle><literal>catAttrs :: String -> AttrSet -> [Any]</literal>
   </subtitle>
 
   <xi:include href="./locations.xml" xpointer="lib.attrsets.catAttrs" />
@@ -1667,48 +1667,4 @@ recursiveUpdate
 ]]></programlisting>
   </example>
  </section>
-
- <section xml:id="function-library-lib.attrsets.recurseIntoAttrs">
-  <title><function>lib.attrsets.recurseIntoAttrs</function></title>
-
-  <subtitle><literal>recurseIntoAttrs :: AttrSet -> AttrSet</literal>
-  </subtitle>
-
-  <xi:include href="./locations.xml" xpointer="lib.attrsets.recurseIntoAttrs" />
-
-  <para>
-   Make various Nix tools consider the contents of the resulting
-   attribute set when looking for what to build, find, etc.
-  </para>
-
-  <para>
-   This function only affects a single attribute set; it does not apply itself recursively for nested attribute sets.
-  </para>
-
-  <variablelist>
-   <varlistentry>
-    <term>
-     <varname>attrs</varname>
-    </term>
-    <listitem>
-     <para>
-      An attribute set to scan for derivations.
-     </para>
-    </listitem>
-   </varlistentry>
-  </variablelist>
-
-  <example xml:id="function-library-lib.attrsets.recurseIntoAttrs-example">
-   <title>Making Nix look inside an attribute set</title>
-<programlisting><![CDATA[
-{ pkgs ? import <nixpkgs> {} }:
-{
-  myTools = pkgs.lib.recurseIntoAttrs {
-    inherit (pkgs) hello figlet;
-  };
-}
-]]></programlisting>
-  </example>
- </section>
-
 </section>

doc/functions/ocitools.xml

@@ -25,7 +25,7 @@
 buildContainer {
   args = [ (with pkgs; writeScript "run.sh" ''
     #!${bash}/bin/bash
-    exec ${bash}/bin/bash
+    ${coreutils}/bin/exec ${bash}/bin/bash
   '').outPath ]; <co xml:id='ex-ociTools-buildContainer-1' />
 
   mounts = {
@@ -38,7 +38,8 @@ buildContainer {
 
   readonly = false; <co xml:id='ex-ociTools-buildContainer-3' />
 }
-</programlisting>
+
+    </programlisting>
    <calloutlist>
     <callout arearefs='ex-ociTools-buildContainer-1'>
      <para>

doc/functions/overrides.xml

@@ -1,14 +1,17 @@
-<chapter xmlns="http://docbook.org/ns/docbook"
+<section xmlns="http://docbook.org/ns/docbook"
          xmlns:xlink="http://www.w3.org/1999/xlink"
          xmlns:xi="http://www.w3.org/2001/XInclude"
-         xml:id="chap-overrides">
+         xml:id="sec-overrides">
  <title>Overriding</title>
+
  <para>
   Sometimes one wants to override parts of <literal>nixpkgs</literal>, e.g. derivation attributes, the results of derivations.
  </para>
+
  <para>
   These functions are used to make changes to packages, returning only single packages. <link xlink:href="#chap-overlays">Overlays</link>, on the other hand, can be used to combine the overridden packages across the entire package set of Nixpkgs.
  </para>
+
  <section xml:id="sec-pkg-override">
   <title>&lt;pkg&gt;.override</title>
 
@@ -42,6 +45,7 @@ mypkg = pkgs.callPackage ./mypkg.nix {
    In the first example, <varname>pkgs.foo</varname> is the result of a function call with some default arguments, usually a derivation. Using <varname>pkgs.foo.override</varname> will call the same function with the given new arguments.
   </para>
  </section>
+
  <section xml:id="sec-pkg-overrideAttrs">
   <title>&lt;pkg&gt;.overrideAttrs</title>
 
@@ -72,6 +76,7 @@ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
    </para>
   </note>
  </section>
+
  <section xml:id="sec-pkg-overrideDerivation">
   <title>&lt;pkg&gt;.overrideDerivation</title>
 
@@ -119,6 +124,7 @@ mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
    </para>
   </note>
  </section>
+
  <section xml:id="sec-lib-makeOverridable">
   <title>lib.makeOverridable</title>
 
@@ -142,4 +148,4 @@ c = lib.makeOverridable f { a = 1; b = 2; };
    The variable <varname>c</varname> however also has some additional functions, like <link linkend="sec-pkg-override">c.override</link> which can be used to override the default arguments. In this example the value of <varname>(c.override { a = 4; }).result</varname> is 6.
   </para>
  </section>
-</chapter>
+</section>

doc/functions/trivial-builders.xml

@@ -0,0 +1,79 @@
+<section xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xmlns:xi="http://www.w3.org/2001/XInclude"
+         xml:id="sec-trivial-builders">
+ <title>Trivial builders</title>
+
+ <para>
+  Nixpkgs provides a couple of functions that help with building derivations. The most important one, <function>stdenv.mkDerivation</function>, has already been documented above. The following functions wrap <function>stdenv.mkDerivation</function>, making it easier to use in certain cases.
+ </para>
+
+ <variablelist>
+  <varlistentry>
+   <term>
+    <literal>runCommand</literal>
+   </term>
+   <listitem>
+    <para>
+     This takes three arguments, <literal>name</literal>, <literal>env</literal>, and <literal>buildCommand</literal>. <literal>name</literal> is just the name that Nix will append to the store path in the same way that <literal>stdenv.mkDerivation</literal> uses its <literal>name</literal> attribute. <literal>env</literal> is an attribute set specifying environment variables that will be set for this derivation. These attributes are then passed to the wrapped <literal>stdenv.mkDerivation</literal>. <literal>buildCommand</literal> specifies the commands that will be run to create this derivation. Note that you will need to create <literal>$out</literal> for Nix to register the command as successful.
+    </para>
+    <para>
+     An example of using <literal>runCommand</literal> is provided below.
+    </para>
+<programlisting>
+(import &lt;nixpkgs&gt; {}).runCommand "my-example" {} ''
+  echo My example command is running
+
+  mkdir $out
+
+  echo I can write data to the Nix store > $out/message
+
+  echo I can also run basic commands like:
+
+  echo ls
+  ls
+
+  echo whoami
+  whoami
+
+  echo date
+  date
+''
+</programlisting>
+   </listitem>
+  </varlistentry>
+  <varlistentry>
+   <term>
+    <literal>runCommandCC</literal>
+   </term>
+   <listitem>
+    <para>
+     This works just like <literal>runCommand</literal>. The only difference is that it also provides a C compiler in <literal>buildCommand</literal>’s environment. To minimize your dependencies, you should only use this if you are sure you will need a C compiler as part of running your command.
+    </para>
+   </listitem>
+  </varlistentry>
+  <varlistentry>
+   <term>
+    <literal>writeTextFile</literal>, <literal>writeText</literal>, <literal>writeTextDir</literal>, <literal>writeScript</literal>, <literal>writeScriptBin</literal>
+   </term>
+   <listitem>
+    <para>
+     These functions write <literal>text</literal> to the Nix store. This is useful for creating scripts from Nix expressions. <literal>writeTextFile</literal> takes an attribute set and expects two arguments, <literal>name</literal> and <literal>text</literal>. <literal>name</literal> corresponds to the name used in the Nix store path. <literal>text</literal> will be the contents of the file. You can also set <literal>executable</literal> to true to make this file have the executable bit set.
+    </para>
+    <para>
+     Many more commands wrap <literal>writeTextFile</literal> including <literal>writeText</literal>, <literal>writeTextDir</literal>, <literal>writeScript</literal>, and <literal>writeScriptBin</literal>. These are convenience functions over <literal>writeTextFile</literal>.
+    </para>
+   </listitem>
+  </varlistentry>
+  <varlistentry>
+   <term>
+    <literal>symlinkJoin</literal>
+   </term>
+   <listitem>
+    <para>
+     This can be used to put many derivations into the same directory structure. It works by creating a new derivation and adding symlinks to each of the paths listed. It expects two arguments, <literal>name</literal>, and <literal>paths</literal>. <literal>name</literal> is the name used in the Nix store path for the created derivation. <literal>paths</literal> is a list of paths that will be symlinked. These paths can be to Nix store derivations or any other subdirectory contained within.
+    </para>
+   </listitem>
+  </varlistentry>
+ </variablelist>
+</section>

doc/introduction.chapter.md

@@ -0,0 +1,51 @@
+---
+title: Introduction
+author: Frederik Rietdijk
+date: 2015-11-25
+---
+
+# Introduction
+
+The Nix Packages collection (Nixpkgs) is a set of thousands of packages for the
+[Nix package manager](http://nixos.org/nix/), released under a
+[permissive MIT/X11 license](https://github.com/NixOS/nixpkgs/blob/master/COPYING).
+Packages are available for several platforms, and can be used with the Nix
+package manager on most GNU/Linux distributions as well as NixOS.
+
+This manual primarily describes how to write packages for the Nix Packages collection
+(Nixpkgs). Thus it’s mainly for packagers and developers who want to add packages to
+Nixpkgs. If you like to learn more about the Nix package manager and the Nix
+expression language, then you are kindly referred to the [Nix manual](http://nixos.org/nix/manual/).
+
+## Overview of Nixpkgs
+
+Nix expressions describe how to build packages from source and are collected in
+the [nixpkgs repository](https://github.com/NixOS/nixpkgs). Also included in the
+collection are Nix expressions for
+[NixOS modules](http://nixos.org/nixos/manual/index.html#sec-writing-modules).
+With these expressions the Nix package manager can build binary packages.
+
+Packages, including the Nix packages collection, are distributed through
+[channels](http://nixos.org/nix/manual/#sec-channels). The collection is
+distributed for users of Nix on non-NixOS distributions through the channel
+`nixpkgs`. Users of NixOS generally use one of the `nixos-*` channels, e.g.
+`nixos-16.03`, which includes all packages and modules for the stable NixOS
+16.03. Stable NixOS releases are generally only given
+security updates. More up to date packages and modules are available via the
+`nixos-unstable` channel.
+
+Both `nixos-unstable` and `nixpkgs` follow the `master` branch of the Nixpkgs
+repository, although both do lag the `master` branch by generally
+[a couple of days](http://howoldis.herokuapp.com/). Updates to a channel are
+distributed as soon as all tests for that channel pass, e.g.
+[this table](http://hydra.nixos.org/job/nixpkgs/trunk/unstable#tabs-constituents)
+shows the status of tests for the `nixpkgs` channel.
+
+The tests are conducted by a cluster called [Hydra](http://nixos.org/hydra/),
+which also builds binary packages from the Nix expressions in Nixpkgs for
+`x86_64-linux`, `i686-linux` and `x86_64-darwin`.
+The binaries are made available via a [binary cache](https://cache.nixos.org).
+
+The current Nix expressions of the channels are available in the
+[`nixpkgs-channels`](https://github.com/NixOS/nixpkgs-channels) repository,
+which has branches corresponding to the available channels.

doc/languages-frameworks/agda.section.md

@@ -1,106 +0,0 @@
----
-title: Agda
-author: Alex Rice (alexarice)
-date: 2020-01-06
----
-# Agda
-
-## How to use Agda
-
-Agda can be installed from `agda`:
-```
-$ nix-env -iA agda
-```
-
-To use agda with libraries, the `agda.withPackages` function can be used. This function either takes:
-+ A list of packages,
-+ or a function which returns a list of packages when given the `agdaPackages` attribute set,
-+ or an attribute set containing a list of packages and a GHC derivation for compilation (see below).
-
-For example, suppose we wanted a version of agda which has access to the standard library. This can be obtained with the expressions:
-
-```
-agda.withPackages [ agdaPackages.standard-library ]
-```
-
-or
-
-```
-agda.withPackages (p: [ p.standard-library ])
-```
-
-or can be called as in the [Compiling Agda](#compiling-agda) section.
-
-If you want to use a library in your home directory (for instance if it is a development version) then typecheck it manually (using `agda.withPackages` if necessary) and then override the `src` attribute of the package to point to your local repository.
-
-Agda will not by default use these libraries. To tell agda to use the library we have some options:
-- Call `agda` with the library flag:
-```
-$ agda -l standard-library -i . MyFile.agda
-```
-- Write a `my-library.agda-lib` file for the project you are working on which may look like:
-```
-name: my-library
-include: .
-depend: standard-library
-```
-- Create the file `~/.agda/defaults` and add any libraries you want to use by default.
-
-More information can be found in the [official Agda documentation on library management](https://agda.readthedocs.io/en/v2.6.1/tools/package-system.html).
-
-## Compiling Agda
-Agda modules can be compiled with the `--compile` flag. A version of `ghc` with `ieee` is made available to the Agda program via the `--with-compiler` flag.
-This can be overridden by a different version of `ghc` as follows:
-
-```
-agda.withPackages {
-  pkgs = [ ... ];
-  ghc = haskell.compiler.ghcHEAD;
-}
-```
-
-## Writing Agda packages
-To write a nix derivation for an agda library, first check that the library has a `*.agda-lib` file.
-
-A derivation can then be written using `agdaPackages.mkDerivation`. This has similar arguments to `stdenv.mkDerivation` with the following additions:
-+ `everythingFile` can be used to specify the location of the `Everything.agda` file, defaulting to `./Everything.agda`. If this file does not exist then either it should be patched in or the `buildPhase` should be overridden (see below).
-+ `libraryName` should be the name that appears in the `*.agda-lib` file, defaulting to `pname`.
-+ `libraryFile` should be the file name of the `*.agda-lib` file, defaulting to `${libraryName}.agda-lib`.
-
-### Building Agda packages
-The default build phase for `agdaPackages.mkDerivation` simply runs `agda` on the `Everything.agda` file.
-If something else is needed to build the package (e.g. `make`) then the `buildPhase` should be overridden.
-Additionally, a `preBuild` or `configurePhase` can be used if there are steps that need to be done prior to checking the `Everything.agda` file.
-`agda` and the Agda libraries contained in `buildInputs` are made available during the build phase.
-
-### Installing Agda packages
-The default install phase copies agda source files, agda interface files (`*.agdai`) and `*.agda-lib` files to the output directory.
-This can be overridden.
-
-By default, agda sources are files ending on  `.agda`, or literate agda files ending on `.lagda`, `.lagda.tex`, `.lagda.org`, `.lagda.md`, `.lagda.rst`. The list of recognised agda source extensions can be extended by setting the `extraExtensions` config variable.
-
-To add an agda package to `nixpkgs`, the derivation should be written to `pkgs/development/libraries/agda/${library-name}/` and an entry should be added to `pkgs/top-level/agda-packages.nix`. Here it is called in a scope with access to all other agda libraries, so the top line of the `default.nix` can look like:
-```
-{ mkDerivation, standard-library, fetchFromGitHub }:
-```
-and `mkDerivation` should be called instead of `agdaPackages.mkDerivation`. Here is an example skeleton derivation for iowa-stdlib:
-
-```
-mkDerivation {
-  version = "1.5.0";
-  pname = "iowa-stdlib";
-
-  src = ...
-
-  libraryFile = "";
-  libraryName = "IAL-1.3";
-
-  buildPhase = ''
-    patchShebangs find-deps.sh
-    make
-  '';
-}
-```
-This library has a file called `.agda-lib`, and so we give an empty string to `libraryFile` as nothing precedes `.agda-lib` in the filename. This file contains `name: IAL-1.3`, and so we let `libraryName =  "IAL-1.3"`. This library does not use an `Everything.agda` file and instead has a Makefile, so there is no need to set `everythingFile` and we set a custom `buildPhase`.
-
-When writing an agda package it is essential to make sure that no `.agda-lib` file gets added to the store as a single file (for example by using `writeText`). This causes agda to think that the nix store is a agda library and it will attempt to write to it whenever it typechecks something. See [https://github.com/agda/agda/issues/4613](https://github.com/agda/agda/issues/4613).

doc/languages-frameworks/android.section.md

@@ -95,7 +95,7 @@ $ nix-build
 
 The Android SDK gets deployed with all desired plugin versions.
 
-We can also deploy subsets of the Android SDK. For example, to only the
+We can also deploy subsets of the Android SDK. For example, to only the the
 `platform-tools` package, you can evaluate the following expression:
 
 ```nix
@@ -167,7 +167,7 @@ parameters that the SDK composition function (the function shown in the
 previous section) supports.
 
 This build function is particularly useful when it is desired to use
-[Hydra](https://nixos.org/hydra): the Nix-based continuous integration solution
+[Hydra](http://nixos.org/hydra): the Nix-based continuous integration solution
 to build Android apps. An Android APK gets exposed as a build product and can be
 installed on any Android device with a web browser by navigating to the build
 result page.
@@ -186,13 +186,11 @@ with import <nixpkgs> {};
 androidenv.emulateApp {
   name = "emulate-MyAndroidApp";
   platformVersion = "28";
-  abiVersion = "x86"; # armeabi-v7a, mips, x86_64
+  abiVersion = "x86_64"; # armeabi-v7a, mips, x86
   systemImageType = "google_apis_playstore";
 }
 ```
 
-Additional flags may be applied to the Android SDK's emulator through the runtime environment variable `$NIX_ANDROID_EMULATOR_FLAGS`.
-
 It is also possible to specify an APK to deploy inside the emulator
 and the package and activity names to launch it:
 
@@ -237,5 +235,5 @@ package manager uses. To update the expressions run the `generate.sh` script
 that is stored in the `pkgs/development/mobile/androidenv/` sub directory:
 
 ```bash
-./generate.sh
+sh ./generate.sh
 ```

doc/languages-frameworks/beam.xml

@@ -26,7 +26,7 @@
    </listitem>
    <listitem>
     <para>
-     <literal>packages</literal>: a set of package builders (Mix and rebar3), each compiled with a specific Erlang/OTP version, e.g. <literal>beam.packages.erlangR19</literal>.
+     <literal>packages</literal>: a set of package sets, each compiled with a specific Erlang/OTP version, e.g. <literal>beam.packages.erlangR19</literal>.
     </para>
    </listitem>
   </itemizedlist>
@@ -36,11 +36,15 @@
   </para>
 
   <para>
-   To create a package builder built with a custom Erlang version, use the lambda, <literal>beam.packagesWith</literal>, which accepts an Erlang/OTP derivation and produces a package builder similar to <literal>beam.packages.erlang</literal>.
+   To create a package set built with a custom Erlang version, use the lambda, <literal>beam.packagesWith</literal>, which accepts an Erlang/OTP derivation and produces a package set similar to <literal>beam.packages.erlang</literal>.
   </para>
 
   <para>
-   Many Erlang/OTP distributions available in <literal>beam.interpreters</literal> have versions with ODBC and/or Java enabled or without wx (no observer support). For example, there's <literal>beam.interpreters.erlangR22_odbc_javac</literal>, which corresponds to <literal>beam.interpreters.erlangR22</literal> and <literal>beam.interpreters.erlangR22_nox</literal>, which corresponds to <literal>beam.interpreters.erlangR22</literal>.
+   Many Erlang/OTP distributions available in <literal>beam.interpreters</literal> have versions with ODBC and/or Java enabled. For example, there's <literal>beam.interpreters.erlangR19_odbc_javac</literal>, which corresponds to <literal>beam.interpreters.erlangR19</literal>.
+  </para>
+
+  <para xml:id="erlang-call-package">
+   We also provide the lambda, <literal>beam.packages.erlang.callPackage</literal>, which simplifies writing BEAM package definitions by injecting all packages from <literal>beam.packages.erlang</literal> into the top-level context.
   </para>
  </section>
 
@@ -51,7 +55,7 @@
    <title>Rebar3</title>
 
    <para>
-    We provide a version of Rebar3, under <literal>rebar3</literal>. We also provide a helper to fetch Rebar3 dependencies from a lockfile under <literal>fetchRebar3Deps</literal>.
+    We provide a version of Rebar3, which is the normal, unmodified Rebar3, under <literal>rebar3</literal>. We also provide a helper to fetch Rebar3 dependencies from a lockfile under <literal>fetchRebar3Deps</literal>.
    </para>
   </section>
 
@@ -68,14 +72,32 @@
   <title>How to Install BEAM Packages</title>
 
   <para>
-   BEAM builders are not registered at the top level, simply because they are not relevant to the vast majority of Nix users.
-   To install any of those builders into your profile, refer to them by their attribute path <literal>beamPackages.rebar3</literal>:
+   BEAM packages are not registered at the top level, simply because they are not relevant to the vast majority of Nix users. They are installable using the <literal>beam.packages.erlang</literal> attribute set (aliased as <literal>beamPackages</literal>), which points to packages built by the default Erlang/OTP version in Nixpkgs, as defined by <literal>beam.interpreters.erlang</literal>. To list the available packages in <literal>beamPackages</literal>, use the following command:
   </para>
 
 <screen>
-<prompt>$ </prompt>nix-env -f &quot;&lt;nixpkgs&gt;&quot; -iA beamPackages.rebar3
+<prompt>$ </prompt>nix-env -f &quot;&lt;nixpkgs&gt;&quot; -qaP -A beamPackages
+beamPackages.esqlite    esqlite-0.2.1
+beamPackages.goldrush   goldrush-0.1.7
+beamPackages.ibrowse    ibrowse-4.2.2
+beamPackages.jiffy      jiffy-0.14.5
+beamPackages.lager      lager-3.0.2
+beamPackages.meck       meck-0.8.3
+beamPackages.rebar3-pc  pc-1.1.0
 </screen>
-</section>
+
+  <para>
+   To install any of those packages into your profile, refer to them by their attribute path (first column):
+  </para>
+
+<screen>
+<prompt>$ </prompt>nix-env -f &quot;&lt;nixpkgs&gt;&quot; -iA beamPackages.ibrowse
+</screen>
+
+  <para>
+   The attribute path of any BEAM package corresponds to the name of that particular package in <link xlink:href="https://hex.pm">Hex</link> or its OTP Application/Release name.
+  </para>
+ </section>
 
  <section xml:id="packaging-beam-applications">
   <title>Packaging BEAM Applications</title>
@@ -87,7 +109,35 @@
     <title>Rebar3 Packages</title>
 
     <para>
-     The Nix function, <literal>buildRebar3</literal>, defined in <literal>beam.packages.erlang.buildRebar3</literal> and aliased at the top level, can be used to build a derivation that understands how to build a Rebar3 project.
+     The Nix function, <literal>buildRebar3</literal>, defined in <literal>beam.packages.erlang.buildRebar3</literal> and aliased at the top level, can be used to build a derivation that understands how to build a Rebar3 project. For example, we can build <link
+        xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link> as follows:
+    </para>
+
+<programlisting>
+{ stdenv, fetchFromGitHub, buildRebar3, ibrowse, jsx, erlware_commons }:
+
+buildRebar3 rec {
+  name = "hex2nix";
+  version = "0.0.1";
+
+  src = fetchFromGitHub {
+    owner = "ericbmerritt";
+    repo = "hex2nix";
+    rev = "${version}";
+    sha256 = "1w7xjidz1l5yjmhlplfx7kphmnpvqm67w99hd2m7kdixwdxq0zqg";
+  };
+
+  beamDeps = [ ibrowse jsx erlware_commons ];
+}
+</programlisting>
+
+    <para>
+     Such derivations are callable with <literal>beam.packages.erlang.callPackage</literal> (see <xref
+        linkend="erlang-call-package"/>). To call this package using the normal <literal>callPackage</literal>, refer to dependency packages via <literal>beamPackages</literal>, e.g. <literal>beamPackages.ibrowse</literal>.
+    </para>
+
+    <para>
+     Notably, <literal>buildRebar3</literal> includes <literal>beamDeps</literal>, while <literal>stdenv.mkDerivation</literal> does not. BEAM dependencies added there will be correctly handled by the system.
     </para>
 
     <para>
@@ -102,6 +152,30 @@
      Erlang.mk functions similarly to Rebar3, except we use <literal>buildErlangMk</literal> instead of <literal>buildRebar3</literal>.
     </para>
 
+<programlisting>
+{ buildErlangMk, fetchHex, cowlib, ranch }:
+
+buildErlangMk {
+  name = "cowboy";
+  version = "1.0.4";
+
+  src = fetchHex {
+    pkg = "cowboy";
+    version = "1.0.4";
+    sha256 = "6a0edee96885fae3a8dd0ac1f333538a42e807db638a9453064ccfdaa6b9fdac";
+  };
+
+  beamDeps = [ cowlib ranch ];
+
+  meta = {
+    description = ''
+      Small, fast, modular HTTP server written in Erlang
+    '';
+    license = stdenv.lib.licenses.isc;
+    homepage = https://github.com/ninenines/cowboy;
+  };
+}
+</programlisting>
    </section>
 
    <section xml:id="mix-packages">
@@ -111,9 +185,57 @@
      Mix functions similarly to Rebar3, except we use <literal>buildMix</literal> instead of <literal>buildRebar3</literal>.
     </para>
 
+<programlisting>
+{ buildMix, fetchHex, plug, absinthe }:
+
+buildMix {
+  name = "absinthe_plug";
+  version = "1.0.0";
+
+  src = fetchHex {
+    pkg = "absinthe_plug";
+    version = "1.0.0";
+    sha256 = "08459823fe1fd4f0325a8bf0c937a4520583a5a26d73b193040ab30a1dfc0b33";
+  };
+
+  beamDeps = [ plug absinthe ];
+
+  meta = {
+    description = ''
+      A plug for Absinthe, an experimental GraphQL toolkit
+    '';
+    license = stdenv.lib.licenses.bsd3;
+    homepage = https://github.com/CargoSense/absinthe_plug;
+  };
+}
+</programlisting>
+
     <para>
      Alternatively, we can use <literal>buildHex</literal> as a shortcut:
     </para>
+
+<programlisting>
+{ buildHex, buildMix, plug, absinthe }:
+
+buildHex {
+  name = "absinthe_plug";
+  version = "1.0.0";
+
+  sha256 = "08459823fe1fd4f0325a8bf0c937a4520583a5a26d73b193040ab30a1dfc0b33";
+
+  builder = buildMix;
+
+  beamDeps = [ plug absinthe ];
+
+  meta = {
+    description = ''
+      A plug for Absinthe, an experimental GraphQL toolkit
+    '';
+    license = stdenv.lib.licenses.bsd3;
+    homepage = https://github.com/CargoSense/absinthe_plug;
+ };
+}
+</programlisting>
    </section>
   </section>
  </section>
@@ -121,13 +243,66 @@
  <section xml:id="how-to-develop">
   <title>How to Develop</title>
 
+  <section xml:id="accessing-an-environment">
+   <title>Accessing an Environment</title>
+
+   <para>
+    Often, we simply want to access a valid environment that contains a specific package and its dependencies. We can accomplish that with the <literal>env</literal> attribute of a derivation. For example, let's say we want to access an Erlang REPL with <literal>ibrowse</literal> loaded up. We could do the following:
+   </para>
+
+<screen>
+<prompt>$ </prompt><userinput>nix-shell -A beamPackages.ibrowse.env --run "erl"</userinput>
+<computeroutput>Erlang/OTP 18 [erts-7.0] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]
+
+Eshell V7.0  (abort with ^G)</computeroutput>
+<prompt>1> </prompt><userinput>m(ibrowse).</userinput>
+<computeroutput>Module: ibrowse
+MD5: 3b3e0137d0cbb28070146978a3392945
+Compiled: January 10 2016, 23:34
+Object file: /nix/store/g1rlf65rdgjs4abbyj4grp37ry7ywivj-ibrowse-4.2.2/lib/erlang/lib/ibrowse-4.2.2/ebin/ibrowse.beam
+Compiler options:  [{outdir,"/tmp/nix-build-ibrowse-4.2.2.drv-0/hex-source-ibrowse-4.2.2/_build/default/lib/ibrowse/ebin"},
+debug_info,debug_info,nowarn_shadow_vars,
+warn_unused_import,warn_unused_vars,warnings_as_errors,
+{i,"/tmp/nix-build-ibrowse-4.2.2.drv-0/hex-source-ibrowse-4.2.2/_build/default/lib/ibrowse/include"}]
+Exports:
+add_config/1                  send_req_direct/7
+all_trace_off/0               set_dest/3
+code_change/3                 set_max_attempts/3
+get_config_value/1            set_max_pipeline_size/3
+get_config_value/2            set_max_sessions/3
+get_metrics/0                 show_dest_status/0
+get_metrics/2                 show_dest_status/1
+handle_call/3                 show_dest_status/2
+handle_cast/2                 spawn_link_worker_process/1
+handle_info/2                 spawn_link_worker_process/2
+init/1                        spawn_worker_process/1
+module_info/0                 spawn_worker_process/2
+module_info/1                 start/0
+rescan_config/0               start_link/0
+rescan_config/1               stop/0
+send_req/3                    stop_worker_process/1
+send_req/4                    stream_close/1
+send_req/5                    stream_next/1
+send_req/6                    terminate/2
+send_req_direct/4             trace_off/0
+send_req_direct/5             trace_off/2
+send_req_direct/6             trace_on/0
+trace_on/2
+ok</computeroutput>
+<prompt>2></prompt>
+</screen>
+
+   <para>
+    Notice the <literal>-A beamPackages.ibrowse.env</literal>. That is the key to this functionality.
+   </para>
+  </section>
+
   <section xml:id="creating-a-shell">
    <title>Creating a Shell</title>
 
-  <para>
-    Usually, we need to create a <literal>shell.nix</literal> file and do our development inside of the environment specified therein. Just install your version of erlang and other interpreter, and then user your normal build tools.
-    As an example with elixir:
-  </para>
+   <para>
+    Getting access to an environment often isn't enough to do real development. Usually, we need to create a <literal>shell.nix</literal> file and do our development inside of the environment specified therein. This file looks a lot like the packaging described above, except that <literal>src</literal> points to the project root and we call the package directly.
+   </para>
 
 <programlisting>
 { pkgs ? import &quot;&lt;nixpkgs&quot;&gt; {} }:
@@ -136,24 +311,114 @@ with pkgs;
 
 let
 
-  elixir = beam.packages.erlangR22.elixir_1_9;
+  f = { buildRebar3, ibrowse, jsx, erlware_commons }:
+      buildRebar3 {
+        name = "hex2nix";
+        version = "0.1.0";
+        src = ./.;
+        beamDeps = [ ibrowse jsx erlware_commons ];
+      };
+  drv = beamPackages.callPackage f {};
 
 in
-mkShell {
-  buildInputs = [ elixir ];
 
-  ERL_INCLUDE_PATH="${erlang}/lib/erlang/usr/include";
-}
+  drv
 </programlisting>
 
    <section xml:id="building-in-a-shell">
     <title>Building in a Shell (for Mix Projects)</title>
 
+    <para>
+     We can leverage the support of the derivation, irrespective of the build derivation, by calling the commands themselves.
+    </para>
+
+<programlisting>
+# =============================================================================
+# Variables
+# =============================================================================
+
+NIX_TEMPLATES := "$(CURDIR)/nix-templates"
+
+TARGET := "$(PREFIX)"
+
+PROJECT_NAME := thorndyke
+
+NIXPKGS=../nixpkgs
+NIX_PATH=nixpkgs=$(NIXPKGS)
+NIX_SHELL=nix-shell -I "$(NIX_PATH)" --pure
+# =============================================================================
+# Rules
+# =============================================================================
+.PHONY= all test clean repl shell build test analyze configure install \
+        test-nix-install publish plt analyze
+
+all: build
+
+guard-%:
+        @ if [ "${${*}}" == "" ]; then \
+                echo "Environment variable $* not set"; \
+                exit 1; \
+        fi
+
+clean:
+        rm -rf _build
+        rm -rf .cache
+
+repl:
+        $(NIX_SHELL) --run "iex -pa './_build/prod/lib/*/ebin'"
+
+shell:
+        $(NIX_SHELL)
+
+configure:
+        $(NIX_SHELL) --command 'eval "$$configurePhase"'
+
+build: configure
+        $(NIX_SHELL) --command 'eval "$$buildPhase"'
+
+install:
+        $(NIX_SHELL) --command 'eval "$$installPhase"'
+
+test:
+        $(NIX_SHELL) --command 'mix test --no-start --no-deps-check'
+
+plt:
+        $(NIX_SHELL) --run "mix dialyzer.plt --no-deps-check"
+
+analyze: build plt
+        $(NIX_SHELL) --run "mix dialyzer --no-compile"
+
+</programlisting>
+
     <para>
      Using a <literal>shell.nix</literal> as described (see <xref
-      linkend="creating-a-shell"/>) should just work.
+      linkend="creating-a-shell"/>) should just work. Aside from <literal>test</literal>, <literal>plt</literal>, and <literal>analyze</literal>, the Make targets work just fine for all of the build derivations.
     </para>
    </section>
   </section>
  </section>
+
+ <section xml:id="generating-packages-from-hex-with-hex2nix">
+  <title>Generating Packages from Hex with <literal>hex2nix</literal></title>
+
+  <para>
+   Updating the <link xlink:href="https://hex.pm">Hex</link> package set requires <link
+    xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link>. Given the path to the Erlang modules (usually <literal>pkgs/development/erlang-modules</literal>), it will dump a file called <literal>hex-packages.nix</literal>, containing all the packages that use a recognized build system in <link
+    xlink:href="https://hex.pm">Hex</link>. It can't be determined, however, whether every package is buildable.
+  </para>
+
+  <para>
+   To make life easier for our users, try to build every <link
+      xlink:href="https://hex.pm">Hex</link> package and remove those that fail. To do that, simply run the following command in the root of your <literal>nixpkgs</literal> repository:
+  </para>
+
+<screen>
+<prompt>$ </prompt>nix-build -A beamPackages
+</screen>
+
+  <para>
+   That will attempt to build every package in <literal>beamPackages</literal>. Then manually remove those that fail. Hopefully, someone will improve <link
+      xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link> in the future to automate the process.
+  </para>
+ </section>
 </section>

doc/languages-frameworks/crystal.section.md

@@ -66,6 +66,6 @@ crystal.buildCrystalPackage rec {
   shardsFile = ./shards.nix;
   crystalBinaries.mint.src = "src/mint.cr";
 
-  buildInputs = [ openssl ];
+  buildInputs = [ openssl_1_0_2 ];
 }
 ```

doc/languages-frameworks/dotnet.section.md

@@ -1,75 +0,0 @@
-# Dotnet
-
-## Local Development Workflow
-
-For local development, it's recommended to use nix-shell to create a dotnet environment:
-
-```
-# shell.nix
-with import <nixpkgs> {};
-
-mkShell {
-  name = "dotnet-env";
-  buildInputs = [
-    dotnet-sdk_3
-  ];
-}
-```
-
-### Using many sdks in a workflow
-
-It's very likely that more than one sdk will be needed on a given project. Dotnet provides several different frameworks (E.g dotnetcore, aspnetcore, etc.) as well as many versions for a given framework. Normally, dotnet is able to fetch a framework and install it relative to the executable. However, this would mean writing to the nix store in nixpkgs, which is read-only. To support the many-sdk use case, one can compose an environment using `dotnetCorePackages.combinePackages`:
-
-```
-with import <nixpkgs> {};
-
-mkShell {
-  name = "dotnet-env";
-  buildInputs = [
-    (with dotnetCorePackages; combinePackages [
-      sdk_3_1
-      sdk_3_0
-      sdk_2_1
-    ])
-  ];
-}
-```
-
-This will produce a dotnet installation that has the dotnet 3.1, 3.0, and 2.1 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output:
-
-```
-$ dotnet --info
-.NET Core SDK (reflecting any global.json):
- Version:   3.1.101
- Commit:    b377529961
-
-...
-
-.NET Core SDKs installed:
-  2.1.803 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/sdk]
-  3.0.102 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/sdk]
-  3.1.101 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/sdk]
-
-.NET Core runtimes installed:
-  Microsoft.AspNetCore.All 2.1.15 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.All]
-  Microsoft.AspNetCore.App 2.1.15 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
-  Microsoft.AspNetCore.App 3.0.2 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
-  Microsoft.AspNetCore.App 3.1.1 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
-  Microsoft.NETCore.App 2.1.15 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.NETCore.App]
-  Microsoft.NETCore.App 3.0.2 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.NETCore.App]
-  Microsoft.NETCore.App 3.1.1 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.NETCore.App]
-```
-
-## dotnet-sdk vs dotnetCorePackages.sdk
-
-The `dotnetCorePackages.sdk_X_Y` is preferred over the old dotnet-sdk as both major and minor version are very important for a dotnet environment. If a given minor version isn't present (or was changed), then this will likely break your ability to build a project.
-
-## dotnetCorePackages.sdk vs dotnetCorePackages.netcore vs dotnetCorePackages.aspnetcore
-
-The `dotnetCorePackages.sdk` contains both a runtime and the full sdk of a given version. The `netcore` and `aspnetcore` packages are meant to serve as minimal runtimes to deploy alongside already built applications.
-
-## Packaging a Dotnet Application
-
-Ideally, we would like to build against the sdk, then only have the dotnet runtime available in the runtime closure.
-
-TODO: Create closure-friendly way to package dotnet applications

doc/languages-frameworks/emscripten.section.md

@@ -1,4 +1,4 @@
-# Emscripten
+# User's Guide to Emscripten in Nixpkgs
 
 [Emscripten](https://github.com/kripken/emscripten): An LLVM-to-JavaScript Compiler
 
@@ -21,11 +21,11 @@ Modes of use of `emscripten`:
 * **Declarative usage**:
 
     This mode is far more power full since this makes use of `nix` for dependency management of emscripten libraries and targets by using the `mkDerivation` which is implemented by `pkgs.emscriptenStdenv` and `pkgs.buildEmscriptenPackage`. The source for the packages is in `pkgs/top-level/emscripten-packages.nix` and the abstraction behind it in `pkgs/development/em-modules/generic/default.nix`.
-    * build and install all packages:
-        * `nix-env -iA emscriptenPackages`
-
-    * dev-shell for zlib implementation hacking:
-        * `nix-shell -A emscriptenPackages.zlib`
+    * build and install all packages: 
+        * `nix-env -iA emscriptenPackages` 
+          
+    * dev-shell for zlib implementation hacking: 
+        * `nix-shell -A emscriptenPackages.zlib` 
 
 
 ## Imperative usage
@@ -90,7 +90,7 @@ See the `zlib` example:
         libz.so.${old.version} -I . -o example.js
 
         echo "Using node to execute the test"
-        ${pkgs.nodejs}/bin/node ./example.js
+        ${pkgs.nodejs}/bin/node ./example.js 
 
         set +x
         if [ $? -ne 0 ]; then
@@ -112,7 +112,7 @@ See the `zlib` example:
 
 ### Usage 2: pkgs.buildEmscriptenPackage
 
-This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used.
+This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used. 
 
     xmlmirror = pkgs.buildEmscriptenPackage rec {
       name = "xmlmirror";
@@ -163,7 +163,7 @@ This `xmlmirror` example features a emscriptenPackage which is defined completel
       checkPhase = ''
 
       '';
-    };
+    }; 
 
 ### Declarative debugging
 
@@ -182,3 +182,4 @@ Use `nix-shell -I nixpkgs=/some/dir/nixpkgs -A emscriptenPackages.libz` and from
 Using this toolchain makes it easy to leverage `nix` from NixOS, MacOSX or even Windows (WSL+ubuntu+nix). This toolchain is reproducible, behaves like the rest of the packages from nixpkgs and contains a set of well working examples to learn and adapt from.
 
 If in trouble, ask the maintainers.
+

doc/languages-frameworks/gnome.xml

@@ -32,29 +32,8 @@
    <title>Icons</title>
 
    <para>
-    When an application uses icons, an icon theme should be available in <envar>XDG_DATA_DIRS</envar> during runtime. The package for the default, icon-less <link xlink:href="https://www.freedesktop.org/wiki/Software/icon-theme/">hicolor-icon-theme</link> (should be propagated by every icon theme) contains <link linkend="ssec-gnome-hooks-hicolor-icon-theme">a setup hook</link> that will pick up icon themes from <literal>buildInputs</literal> and pass it to our wrapper. Unfortunately, relying on that would mean every user has to download the theme included in the package expression no matter their preference. For that reason, we leave the installation of icon theme on the user. If you use one of the desktop environments, you probably already have an icon theme installed.
+    When an application uses icons, an icon theme should be available in <envar>XDG_DATA_DIRS</envar>. The package for the default, icon-less <link xlink:href="https://www.freedesktop.org/wiki/Software/icon-theme/">hicolor-icon-theme</link> contains <link linkend="ssec-gnome-hooks-hicolor-icon-theme">a setup hook</link> that will pick up icon themes from <literal>buildInputs</literal> and pass it to our wrapper. Unfortunately, relying on that would mean every user has to download the theme included in the package expression no matter their preference. For that reason, we leave the installation of icon theme on the user. If you use one of the desktop environments, you probably already have an icon theme installed.
    </para>
-
-   <para>
-    To avoid costly file system access when locating icons, GTK, <link xlink:href="https://woboq.com/blog/qicon-reads-gtk-icon-cache-in-qt57.html">as well as Qt</link>, can rely on <filename>icon-theme.cache</filename> files from the themes’ top-level directories. These files are generated using <command>gtk-update-icon-cache</command>, which is expected to be run whenever an icon is added or removed to an icon theme (typically an application icon into <literal>hicolor</literal> theme) and some programs do indeed run this after icon installation. However, since packages are installed into their own prefix by Nix, this would lead to conflicts. For that reason, <package>gtk3</package> provides a <link xlink:href="#ssec-gnome-hooks-gtk-drop-icon-theme-cache">setup hook</link> that will clean the file from installation. Since most applications only ship their own icon that will be loaded on start-up, it should not affect them too much. On the other hand, icon themes are much larger and more widely used so we need to cache them. Because we recommend installing icon themes globally, we will generate the cache files from all packages in a profile using a NixOS module. You can enable the cache generation using <option>gtk.iconCache.enable</option> option if your desktop environment does not already do that.
-   </para>
-  </section>
-
-  <section xml:id="ssec-icon-theme-packaging">
-    <title>Packaging icon themes</title>
-
-    <para>
-      Icon themes may inherit from other icon themes. The inheritance is specified using the <literal>Inherits</literal> key in the <filename>index.theme</filename> file distributed with the icon theme. According to the <link xlink:href="https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html">icon theme specification</link>, icons not provided by the theme are looked for in its parent icon themes. Therefore the parent themes should be installed as dependencies for a more complete experience regarding the icon sets used.
-    </para>
-
-    <para>
-      The package <package>hicolor-icon-theme</package> provides a setup hook which makes symbolic links for the parent themes into the directory <filename>share/icons</filename> of the current theme directory in the nix store, making sure they can be found at runtime. For that to work the packages providing parent icon themes should be listed as propagated build dependencies, together with <package>hicolor-icon-theme</package>.
-    </para>
-
-    <para>
-      Also make sure that <filename>icon-theme.cache</filename> is installed for each theme provided by the package, and set <code>dontDropIconThemeCache</code> to <code>true</code> so that the cache file is not removed by the <package>gtk3</package> setup hook.
-    </para>
-
   </section>
 
   <section xml:id="ssec-gnome-themes">
@@ -91,7 +70,7 @@
 preFixup = ''
   for f in $(find $out/bin/ $out/libexec/ -type f -executable); do
     wrapProgram "$f" \
-      --prefix GIO_EXTRA_MODULES : "${getLib dconf}/lib/gio/modules" \
+      --prefix GIO_EXTRA_MODULES : "${getLib gnome3.dconf}/lib/gio/modules" \
       --prefix XDG_DATA_DIRS : "$out/share" \
       --prefix XDG_DATA_DIRS : "$out/share/gsettings-schemas/${name}" \
       --prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \
@@ -112,14 +91,9 @@ preFixup = ''
       <package>glib</package> setup hook will populate <envar>GSETTINGS_SCHEMAS_PATH</envar> and then <package>wrapGAppsHook</package> will prepend it to <envar>XDG_DATA_DIRS</envar>.
      </para>
     </listitem>
-    <listitem xml:id="ssec-gnome-hooks-gtk-drop-icon-theme-cache">
-     <para>
-      One of <package>gtk3</package>’s setup hooks will remove <filename>icon-theme.cache</filename> files from package’s icon theme directories to avoid conflicts. Icon theme packages should prevent this with <code>dontDropIconThemeCache = true;</code>.
-     </para>
-    </listitem>
     <listitem xml:id="ssec-gnome-hooks-dconf">
      <para>
-      <package>dconf.lib</package> is a dependency of <package>wrapGAppsHook</package>, which then also adds it to the <envar>GIO_EXTRA_MODULES</envar> variable.
+      <package>gnome3.dconf.lib</package> is a dependency of <package>wrapGAppsHook</package>, which then also adds it to the <envar>GIO_EXTRA_MODULES</envar> variable.
      </para>
     </listitem>
     <listitem xml:id="ssec-gnome-hooks-hicolor-icon-theme">
@@ -216,9 +190,9 @@ python3.pkgs.buildPythonApplication {
   dontWrapGApps = true;
 
   # Arguments to be passed to `makeWrapper`, only used by buildPython*
-  preFixup = ''
-    makeWrapperArgs+=("''${gappsWrapperArgs[@]}")
-  '';
+  makeWrapperArgs = [
+    "\${gappsWrapperArgs[@]}"
+  ];
 }
 </programlisting>
       And for a QT app like:
@@ -236,9 +210,9 @@ mkDerivation {
   dontWrapGApps = true;
 
   # Arguments to be passed to `makeWrapper`, only used by qt5’s mkDerivation
-  preFixup = ''
-    qtWrapperArgs+=("''${gappsWrapperArgs[@]}")
-  '';
+  qtWrapperArgs [
+    "\${gappsWrapperArgs[@]}"
+  ];
 }
 </programlisting>
      </para>
@@ -250,7 +224,7 @@ mkDerivation {
     </term>
     <listitem>
      <para>
-      You can rely on applications depending on the library setting the necessary environment variables but that is often easy to miss. Instead we recommend to patch the paths in the source code whenever possible. Here are some examples:
+      You can rely on applications depending on the library set the necessary environment variables but that it often easy to miss. Instead we recommend to patch the paths in the source code whenever possible. Here are some examples:
       <itemizedlist>
        <listitem xml:id="ssec-gnome-common-issues-unwrappable-package-gnome-shell-ext">
         <para>
@@ -284,16 +258,6 @@ mkDerivation {
      </para>
     </listitem>
    </varlistentry>
-   <varlistentry xml:id="ssec-gnome-common-issues-weird-location">
-    <term>
-     I need to wrap a binary outside <filename>bin</filename> and <filename>libexec</filename> directories.
-    </term>
-    <listitem>
-     <para>
-      You can manually trigger the wrapping with <function>wrapGApp</function> in <literal>preFixup</literal> phase. It takes a path to a program as a first argument; the remaining arguments are passed directly to <function xlink:href="#fun-wrapProgram">wrapProgram</function> function.
-     </para>
-    </listitem>
-   </varlistentry>
   </variablelist>
  </section>
 </section>

doc/languages-frameworks/go.xml

@@ -26,7 +26,7 @@
    <title>buildGoModule</title>
 <programlisting>
 pet = buildGoModule rec {
-  pname = "pet";
+  name = "pet-${version}";
   version = "0.3.4";
 
   src = fetchFromGitHub {
@@ -36,17 +36,13 @@ pet = buildGoModule rec {
     sha256 = "0m2fzpqxk7hrbxsgqplkg7h2p7gv6s1miymv3gvw0cz039skag0s";
   };
 
-  vendorSha256 = "1879j77k96684wi554rkjxydrj8g3hpp0kvxz03sd8dmwr3lh83j"; <co xml:id='ex-buildGoModule-1' />
+  modSha256 = "1879j77k96684wi554rkjxydrj8g3hpp0kvxz03sd8dmwr3lh83j"; <co xml:id='ex-buildGoModule-1' />
 
   subPackages = [ "." ]; <co xml:id='ex-buildGoModule-2' />
 
-  deleteVendor = true; <co xml:id='ex-buildGoModule-3' />
-
-  runVend = true; <co xml:id='ex-buildGoModule-4' />
-
   meta = with lib; {
     description = "Simple command-line snippet manager, written in Go";
-    homepage = "https://github.com/knqyf263/pet";
+    homepage = https://github.com/knqyf263/pet;
     license = licenses.mit;
     maintainers = with maintainers; [ kalbasit ];
     platforms = platforms.linux ++ platforms.darwin;
@@ -60,7 +56,7 @@ pet = buildGoModule rec {
    <calloutlist>
     <callout arearefs='ex-buildGoModule-1'>
      <para>
-      <varname>vendorSha256</varname> is the hash of the output of the intermediate fetcher derivation.
+      <varname>modSha256</varname> is the hash of the output of the intermediate fetcher derivation.
      </para>
     </callout>
     <callout arearefs='ex-buildGoModule-2'>
@@ -68,27 +64,8 @@ pet = buildGoModule rec {
       <varname>subPackages</varname> limits the builder from building child packages that have not been listed. If <varname>subPackages</varname> is not specified, all child packages will be built.
      </para>
     </callout>
-    <callout arearefs='ex-buildGoModule-3'>
-     <para>
-      <varname>deleteVendor</varname> removes the pre-existing vendor directory and fetches the dependencies. This should only be used if the dependencies included in the vendor folder are broken or incomplete.
-     </para>
-    </callout>
-    <callout arearefs='ex-buildGoModule-4'>
-     <para>
-      <varname>runVend</varname> runs the vend command to generate the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build.
-     </para>
-    </callout>
    </calloutlist>
   </para>
-
-  <para>
-    <varname>vendorSha256</varname> can also take <varname>null</varname> as an input.
-
-    When `null` is used as a value, rather than fetching the dependencies
-    and vendoring them, we use the vendoring included within the source repo.
-    If you'd like to not have to update this field on dependency changes,
-    run `go mod vendor` in your source repo and set 'vendorSha256 = null;'
-  </para>
  </section>
 
  <section xml:id="ssec-go-legacy">
@@ -102,7 +79,7 @@ pet = buildGoModule rec {
    <title>buildGoPackage</title>
 <programlisting>
 deis = buildGoPackage rec {
-  pname = "deis";
+  name = "deis-${version}";
   version = "1.13.0";
 
   goPackagePath = "github.com/deis/deis"; <co xml:id='ex-buildGoPackage-1' />
@@ -117,7 +94,7 @@ deis = buildGoPackage rec {
 
   goDeps = ./deps.nix; <co xml:id='ex-buildGoPackage-3' />
 
-  buildFlags = [ "--tags" "release" ]; <co xml:id='ex-buildGoPackage-4' />
+  buildFlags = "--tags release"; <co xml:id='ex-buildGoPackage-4' />
 }
 </programlisting>
   </example>
@@ -205,6 +182,18 @@ deis = buildGoPackage rec {
    To extract dependency information from a Go package in automated way use <link xlink:href="https://github.com/kamilchm/go2nix">go2nix</link>. It can produce complete derivation and <varname>goDeps</varname> file for Go programs.
   </para>
 
+  <para>
+   <varname>buildGoPackage</varname> produces <xref linkend='chap-multiple-output' xrefstyle="select: title" /> where <varname>bin</varname> includes program binaries. You can test build a Go binary as follows:
+<screen>
+<prompt>$ </prompt>nix-build -A deis.bin
+</screen>
+   or build all outputs with:
+<screen>
+<prompt>$ </prompt>nix-build -A deis.all
+</screen>
+   <varname>bin</varname> output will be installed by default with <varname>nix-env -i</varname> or <varname>systemPackages</varname>.
+  </para>
+
   <para>
    You may use Go packages installed into the active Nix profiles by adding the following to your ~/.bashrc:
 <screen>

doc/languages-frameworks/idris.section.md

@@ -1,4 +1,4 @@
-# Idris
+# Idris packages
 
 ## Installing Idris
 
@@ -96,7 +96,7 @@ build-idris-package  {
 
   meta = {
     description = "Idris YAML lib";
-    homepage = "https://github.com/Heather/Idris.Yaml";
+    homepage = https://github.com/Heather/Idris.Yaml;
     license = lib.licenses.mit;
     maintainers = [ lib.maintainers.brainrape ];
   };

doc/languages-frameworks/index.xml

@@ -1,28 +1,24 @@
 <chapter xmlns="http://docbook.org/ns/docbook"
          xmlns:xi="http://www.w3.org/2001/XInclude"
          xml:id="chap-language-support">
- <title>Languages and frameworks</title>
+ <title>Support for specific programming languages and frameworks</title>
  <para>
   The <link linkend="chap-stdenv">standard build environment</link> makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accomodated by overriding the appropriate phases of <literal>stdenv</literal>. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
  </para>
- <xi:include href="agda.section.xml" />
  <xi:include href="android.section.xml" />
  <xi:include href="beam.xml" />
  <xi:include href="bower.xml" />
  <xi:include href="coq.xml" />
- <xi:include href="crystal.section.xml" />
- <xi:include href="emscripten.section.xml" />
  <xi:include href="gnome.xml" />
  <xi:include href="go.xml" />
  <xi:include href="haskell.section.xml" />
  <xi:include href="idris.section.xml" />
  <xi:include href="ios.section.xml" />
  <xi:include href="java.xml" />
- <xi:include href="lua.section.xml" />
+ <xi:include href="lua.xml" />
  <xi:include href="node.section.xml" />
  <xi:include href="ocaml.xml" />
  <xi:include href="perl.xml" />
- <xi:include href="php.section.xml" />
  <xi:include href="python.section.xml" />
  <xi:include href="qt.xml" />
  <xi:include href="r.section.xml" />
@@ -31,4 +27,6 @@
  <xi:include href="texlive.xml" />
  <xi:include href="titanium.section.xml" />
  <xi:include href="vim.section.xml" />
+ <xi:include href="emscripten.section.xml" />
+ <xi:include href="crystal.section.xml" />
 </chapter>

doc/languages-frameworks/ios.section.md

@@ -1,7 +1,7 @@
 ---
 title: iOS
 author: Sander van der Burg
-date: 2019-11-10
+date: 2018-11-18
 ---
 # iOS
 
@@ -18,7 +18,7 @@ The primary objective of this project is to use the Nix expression language to
 specify how iOS apps can be built from source code, and to automatically spawn
 iOS simulator instances for testing.
 
-This component also makes it possible to use [Hydra](https://nixos.org/hydra),
+This component also makes it possible to use [Hydra](http://nixos.org/hydra),
 the Nix-based continuous integration server to regularly build iOS apps and to
 do wireless ad-hoc installations of enterprise IPAs on iOS devices through
 Hydra.
@@ -217,13 +217,3 @@ xcode.simulateApp {
 
 By providing the result of an `xcode.buildApp {}` function and configuring the
 app bundle id, the app gets deployed automatically and started.
-
-Troubleshooting
----------------
-In some rare cases, it may happen that after a failure, changes are not picked
-up. Most likely, this is caused by a derived data cache that Xcode maintains.
-To wipe it you can run:
-
-```bash
-$ rm -rf ~/Library/Developer/Xcode/DerivedData
-```

doc/languages-frameworks/lua.section.md

@@ -1,252 +0,0 @@
----
-title: Lua
-author: Matthieu Coudron
-date: 2019-02-05
----
-
-# User's Guide to Lua Infrastructure
-
-## Using Lua
-
-### Overview of Lua
-
-Several versions of the Lua interpreter are available: luajit, lua 5.1, 5.2, 5.3.
-The attribute `lua` refers to the default interpreter, it is also possible to refer to specific versions, e.g. `lua5_2` refers to Lua 5.2.
-
-Lua libraries are in separate sets, with one set per interpreter version.
-
-The interpreters have several common attributes. One of these attributes is
-`pkgs`, which is a package set of Lua libraries for this specific
-interpreter. E.g., the `busted` package corresponding to the default interpreter
-is `lua.pkgs.busted`, and the lua 5.2 version is `lua5_2.pkgs.busted`.
-The main package set contains aliases to these package sets, e.g.
-`luaPackages` refers to `lua5_1.pkgs` and `lua52Packages` to
-`lua5_2.pkgs`.
-
-### Installing Lua and packages
-
-#### Lua environment defined in separate `.nix` file
-
-Create a file, e.g. `build.nix`, with the following expression
-```nix
-with import <nixpkgs> {};
-
-lua5_2.withPackages (ps: with ps; [ busted luafilesystem ])
-```
-and install it in your profile with
-```shell
-nix-env -if build.nix
-```
-Now you can use the Lua interpreter, as well as the extra packages (`busted`,
-`luafilesystem`) that you added to the environment.
-
-#### Lua environment defined in `~/.config/nixpkgs/config.nix`
-
-If you prefer to, you could also add the environment as a package override to the Nixpkgs set, e.g.
-using `config.nix`,
-```nix
-{ # ...
-
-  packageOverrides = pkgs: with pkgs; {
-    myLuaEnv = lua5_2.withPackages (ps: with ps; [ busted luafilesystem ]);
-  };
-}
-```
-and install it in your profile with
-```shell
-nix-env -iA nixpkgs.myLuaEnv
-```
-The environment is is installed by referring to the attribute, and considering
-the `nixpkgs` channel was used.
-
-#### Lua environment defined in `/etc/nixos/configuration.nix`
-
-For the sake of completeness, here's another example how to install the environment system-wide.
-
-```nix
-{ # ...
-
-  environment.systemPackages = with pkgs; [
-    (lua.withPackages(ps: with ps; [ busted luafilesystem ]))
-  ];
-}
-```
-
-### How to override a Lua package using overlays?
-
-Use the following overlay template:
-
-```nix
-final: prev:
-{
-
-  lua = prev.lua.override {
-    packageOverrides = luaself: luaprev: {
-
-      luarocks-nix = luaprev.luarocks-nix.overrideAttrs(oa: {
-        pname = "luarocks-nix";
-        src = /home/my_luarocks/repository;
-      });
-  };
-
-  luaPackages = lua.pkgs;
-}
-```
-
-### Temporary Lua environment with `nix-shell`
-
-
-There are two methods for loading a shell with Lua packages. The first and recommended method
-is to create an environment with `lua.buildEnv` or `lua.withPackages` and load that. E.g.
-```sh
-$ nix-shell -p 'lua.withPackages(ps: with ps; [ busted luafilesystem ])'
-```
-opens a shell from which you can launch the interpreter
-```sh
-[nix-shell:~] lua
-```
-The other method, which is not recommended, does not create an environment and requires you to list the packages directly,
-
-```sh
-$ nix-shell -p lua.pkgs.busted lua.pkgs.luafilesystem
-```
-Again, it is possible to launch the interpreter from the shell.
-The Lua interpreter has the attribute `pkgs` which contains all Lua libraries for that specific interpreter.
-
-
-## Developing with Lua
-
-Now that you know how to get a working Lua environment with Nix, it is time
-to go forward and start actually developing with Lua. There are two ways to
-package lua software, either it is on luarocks and most of it can be taken care
-of by the luarocks2nix converter or the packaging has to be done manually.
-Let's present the luarocks way first and the manual one in a second time.
-
-### Packaging a library on luarocks
-
-[Luarocks.org](www.luarocks.org) is the main repository of lua packages.
-The site proposes two types of packages, the rockspec and the src.rock
-(equivalent of a [rockspec](https://github.com/luarocks/luarocks/wiki/Rockspec-format) but with the source).
-These packages can have different build types such as `cmake`, `builtin` etc .
-
-Luarocks-based packages are generated in pkgs/development/lua-modules/generated-packages.nix from
-the whitelist maintainers/scripts/luarocks-packages.csv and updated by running maintainers/scripts/update-luarocks-packages.
-
-[luarocks2nix](https://github.com/nix-community/luarocks) is a tool capable of generating nix derivations from both rockspec and src.rock (and favors the src.rock).
-The automation only goes so far though and some packages need to be customized.
-These customizations go in `pkgs/development/lua-modules/overrides.nix`.
-For instance if the rockspec defines `external_dependencies`, these need to be manually added in in its rockspec file then it won't work.
-
-You can try converting luarocks packages to nix packages with the command `nix-shell -p luarocks-nix` and then `luarocks nix PKG_NAME`.
-Nix rely on luarocks to install lua packages, basically it runs:
-`luarocks make --deps-mode=none --tree $out`
-
-#### Packaging a library manually
-
-You can develop your package as you usually would, just don't forget to wrap it
-within a `toLuaModule` call, for instance
-```nix
-mynewlib = toLuaModule ( stdenv.mkDerivation { ... });
-```
-
-There is also the `buildLuaPackage` function that can be used when lua modules
-are not packaged for luarocks. You can see a few examples at `pkgs/top-level/lua-packages.nix`.
-
-## Lua Reference
-
-### Lua interpreters
-
-Versions 5.1, 5.2 and 5.3 of the lua interpreter are available as
-respectively `lua5_1`, `lua5_2` and `lua5_3`. Luajit is available too.
-The Nix expressions for the interpreters can be found in `pkgs/development/interpreters/lua-5`.
-
-
-#### Attributes on lua interpreters packages
-
-Each interpreter has the following attributes:
-
-- `interpreter`. Alias for `${pkgs.lua}/bin/lua`.
-- `buildEnv`. Function to build lua interpreter environments with extra packages bundled together. See section *lua.buildEnv function* for usage and documentation.
-- `withPackages`. Simpler interface to `buildEnv`.
-- `pkgs`. Set of Lua packages for that specific interpreter. The package set can be modified by overriding the interpreter and passing `packageOverrides`.
-
-
-#### `buildLuarocksPackage` function
-
-The `buildLuarocksPackage` function is implemented in `pkgs/development/interpreters/lua-5/build-lua-package.nix`
-The following is an example:
-```nix
-luaposix = buildLuarocksPackage {
-  pname = "luaposix";
-  version = "34.0.4-1";
-
-  src = fetchurl {
-    url    = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
-    sha256 = "0yrm5cn2iyd0zjd4liyj27srphvy0gjrjx572swar6zqr4dwjqp2";
-  };
-  disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
-  propagatedBuildInputs = [ bit32 lua std_normalize ];
-
-  meta = with stdenv.lib; {
-    homepage = "https://github.com/luaposix/luaposix/";
-    description = "Lua bindings for POSIX";
-    maintainers = with maintainers; [ vyp lblasc ];
-    license.fullName = "MIT/X11";
-  };
-};
-```
-
-The `buildLuarocksPackage` delegates most tasks to luarocks:
-
-* it adds `luarocks` as an unpacker for `src.rock` files (zip files really).
-* configurePhase` writes a temporary luarocks configuration file which location
-is exported via the environment variable `LUAROCKS_CONFIG`.
-* the `buildPhase` does nothing.
-* `installPhase` calls `luarocks make --deps-mode=none --tree $out` to build and
-install the package
-* In the `postFixup` phase, the `wrapLuaPrograms` bash function is called to
-  wrap all programs in the `$out/bin/*` directory to include `$PATH`
-  environment variable and add dependent libraries to script's `LUA_PATH` and
-  `LUA_CPATH`.
-
-By default `meta.platforms` is set to the same value as the interpreter unless overridden otherwise.
-
-#### `buildLuaApplication` function
-
-The `buildLuaApplication` function is practically the same as `buildLuaPackage`.
-The difference is that `buildLuaPackage` by default prefixes the names of the packages with the version of the interpreter.
-Because with an application we're not interested in multiple version the prefix is dropped.
-
-#### lua.withPackages function
-
-The `lua.withPackages` takes a function as an argument that is passed the set of lua packages and returns the list of packages to be included in the environment.
-Using the `withPackages` function, the previous example for the luafilesystem environment can be written like this:
-```nix
-with import <nixpkgs> {};
-
-lua.withPackages (ps: [ps.luafilesystem])
-```
-
-`withPackages` passes the correct package set for the specific interpreter version as an argument to the function. In the above example, `ps` equals `luaPackages`.
-But you can also easily switch to using `lua5_2`:
-```nix
-with import <nixpkgs> {};
-
-lua5_2.withPackages (ps: [ps.lua])
-```
-
-Now, `ps` is set to `lua52Packages`, matching the version of the interpreter.
-
-
-### Possible Todos
-
-* export/use version specific variables such as `LUA_PATH_5_2`/`LUAROCKS_CONFIG_5_2`
-* let luarocks check for dependencies via exporting the different rocktrees in temporary config
-
-### Lua Contributing guidelines
-
-Following rules should be respected:
-
-* Make sure libraries build for all Lua interpreters.
-* Commit names of Lua libraries should reflect that they are Lua libraries, so write for example `luaPackages.luafilesystem: 1.11 -> 1.12`.
-

doc/languages-frameworks/lua.xml

@@ -0,0 +1,36 @@
+<section xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xml:id="sec-language-lua">
+ <title>Lua</title>
+
+ <para>
+  Lua packages are built by the <varname>buildLuaPackage</varname> function. This function is implemented in <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/lua-modules/generic/default.nix"> <filename>pkgs/development/lua-modules/generic/default.nix</filename></link> and works similarly to <varname>buildPerlPackage</varname>. (See <xref linkend="sec-language-perl"/> for details.)
+ </para>
+
+ <para>
+  Lua packages are defined in <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/lua-packages.nix"><filename>pkgs/top-level/lua-packages.nix</filename></link>. Most of them are simple. For example:
+<programlisting>
+fileSystem = buildLuaPackage {
+  name = "filesystem-1.6.2";
+  src = fetchurl {
+    url = "https://github.com/keplerproject/luafilesystem/archive/v1_6_2.tar.gz";
+    sha256 = "1n8qdwa20ypbrny99vhkmx8q04zd2jjycdb5196xdhgvqzk10abz";
+  };
+  meta = {
+    homepage = "https://github.com/keplerproject/luafilesystem";
+    hydraPlatforms = stdenv.lib.platforms.linux;
+    maintainers = with maintainers; [ flosse ];
+  };
+};
+</programlisting>
+ </para>
+
+ <para>
+  Though, more complicated package should be placed in a seperate file in <link
+  xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/lua-modules"><filename>pkgs/development/lua-modules</filename></link>.
+ </para>
+
+ <para>
+  Lua packages accept additional parameter <varname>disabled</varname>, which defines the condition of disabling package from luaPackages. For example, if package has <varname>disabled</varname> assigned to <literal>lua.luaversion != "5.1"</literal>, it will not be included in any luaPackages except lua51Packages, making it only be built for lua 5.1.
+ </para>
+</section>

doc/languages-frameworks/node.section.md

@@ -1,5 +1,5 @@
-Node.js
-=======
+Node.js packages
+================
 The `pkgs/development/node-packages` folder contains a generated collection of
 [NPM packages](https://npmjs.com/) that can be installed with the Nix package
 manager.
@@ -12,9 +12,10 @@ When it is desired to use NPM libraries in a development project, use the
 `node2nix` generator directly on the `package.json` configuration file of the
 project.
 
-The package set provides support for the official stable Node.js versions.
-The latest stable LTS release in `nodePackages`, as well as the latest stable
-Current release in `nodePackages_latest`.
+The package set also provides support for multiple Node.js versions. The policy
+is that a new package should be added to the collection for the latest stable LTS
+release (which is currently 10.x), unless there is an explicit reason to support
+a different release.
 
 If your package uses native addons, you need to examine what kind of native
 build system it uses. Here are some examples:
@@ -25,25 +26,24 @@ build system it uses. Here are some examples:
 
 After you have identified the correct system, you need to override your package
 expression while adding in build system as a build input. For example, `dat`
-requires `node-gyp-build`, so [we override](https://github.com/NixOS/nixpkgs/blob/32f5e5da4a1b3f0595527f5195ac3a91451e9b56/pkgs/development/node-packages/default.nix#L37-L40) its expression in [`default.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/default.nix):
+requires `node-gyp-build`, so we override its expression in `default-v10.nix`:
 
 ```nix
-    dat = super.dat.override {
-      buildInputs = [ self.node-gyp-build pkgs.libtool pkgs.autoconf pkgs.automake ];
-      meta.broken = since "12";
-    };
+dat = nodePackages.dat.override (oldAttrs: {
+  buildInputs = oldAttrs.buildInputs ++ [ nodePackages.node-gyp-build ];
+});
 ```
 
 To add a package from NPM to nixpkgs:
 
- 1. Modify `pkgs/development/node-packages/node-packages.json` to add, update
-    or remove package entries to have it included in `nodePackages` and
-    `nodePackages_latest`.
+ 1. Modify `pkgs/development/node-packages/node-packages-v10.json` to add, update
+    or remove package entries. (Or `pkgs/development/node-packages/node-packages-v8.json`
+    for packages depending on Node.js 8.x)
  2. Run the script: `(cd pkgs/development/node-packages && ./generate.sh)`.
  3. Build your new package to test your changes:
     `cd /path/to/nixpkgs && nix-build -A nodePackages.<new-or-updated-package>`.
-    To build against the latest stable Current Node.js version (e.g. 14.x):
-    `nix-build -A nodePackages_latest.<new-or-updated-package>`
+    To build against a specific Node.js version (e.g. 10.x):
+    `nix-build -A nodePackages_10_x.<new-or-updated-package>`
  4. Add and commit all modified and generated files.
 
 For more information about the generation process, consult the

doc/languages-frameworks/ocaml.xml

@@ -36,7 +36,7 @@ buildDunePackage rec {
   doCheck = true;
 
   meta = {
-    homepage = "https://github.com/inhabitedtype/angstrom";
+    homepage = https://github.com/inhabitedtype/angstrom;
     description = "OCaml parser combinators built for speed and memory efficiency";
     license = stdenv.lib.licenses.bsd3;
     maintainers = with stdenv.lib.maintainers; [ sternenseemann ];
@@ -63,7 +63,7 @@ buildDunePackage rec {
   };
 
   meta = with stdenv.lib; {
-    homepage = "https://github.com/flowtype/ocaml-wtf8";
+    homepage = https://github.com/flowtype/ocaml-wtf8;
     description = "WTF-8 is a superset of UTF-8 that allows unpaired surrogates.";
     license = licenses.mit;
     maintainers = [ maintainers.eqyiel ];

doc/languages-frameworks/perl.xml

@@ -3,47 +3,14 @@
          xml:id="sec-language-perl">
  <title>Perl</title>
 
- <section xml:id="ssec-perl-running">
-  <title>Running perl programs on the shell</title>
+ <para>
+  Nixpkgs provides a function <varname>buildPerlPackage</varname>, a generic package builder function for any Perl package that has a standard <varname>Makefile.PL</varname>. It’s implemented in <link
+xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/perl-modules/generic"><filename>pkgs/development/perl-modules/generic</filename></link>.
+ </para>
 
-  <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>
-  to take the Perl installation from the <literal>PATH</literal> environment variable, or invoke Perl directly with:
-<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>
-  </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>
-  </para>
- </section>
-
- <section xml:id="ssec-perl-packaging">
-  <title>Packaging Perl programs</title>
-
-  <para>
-   Nixpkgs provides a function <varname>buildPerlPackage</varname>, a generic package builder function for any Perl package that has a standard <varname>Makefile.PL</varname>. It’s implemented in <link
- xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/perl-modules/generic"><filename>pkgs/development/perl-modules/generic</filename></link>.
-  </para>
-
-  <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:
+ <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";
@@ -53,47 +20,47 @@ ClassC3 = buildPerlPackage rec {
   };
 };
 </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
+  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>
-   in <filename>all-packages.nix</filename>. You can test building a Perl package as follows:
+  in <filename>all-packages.nix</filename>. You can test building a Perl package as follows:
 <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:
+  <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>
-   (Of course you can also install using the attribute name: <literal>nix-env -i -A perlPackages.ClassC3</literal>.)
-  </para>
+  (Of course you can also install using the attribute name: <literal>nix-env -i -A perlPackages.ClassC3</literal>.)
+ </para>
 
-  <para>
-   So what does <varname>buildPerlPackage</varname> do? It does the following:
-   <orderedlist>
-    <listitem>
-     <para>
-      In the configure phase, it calls <literal>perl Makefile.PL</literal> to generate a Makefile. You can set the variable <varname>makeMakerFlags</varname> to pass flags to <filename>Makefile.PL</filename>
-     </para>
-    </listitem>
-    <listitem>
-     <para>
-      It adds the contents of the <envar>PERL5LIB</envar> environment variable to <literal>#! .../bin/perl</literal> line of Perl scripts as <literal>-I<replaceable>dir</replaceable></literal> flags. This ensures that a script can find its dependencies. (This can cause this shebang line to become too long for Darwin to handle; see the note below.)
-     </para>
-    </listitem>
-    <listitem>
-     <para>
-      In the fixup phase, it writes the propagated build inputs (<varname>propagatedBuildInputs</varname>) to the file <filename>$out/nix-support/propagated-user-env-packages</filename>. <command>nix-env</command> recursively installs all packages listed in this file when you install a package that has it. This ensures that a Perl package can find its dependencies.
-     </para>
-    </listitem>
-   </orderedlist>
-  </para>
+ <para>
+  So what does <varname>buildPerlPackage</varname> do? It does the following:
+  <orderedlist>
+   <listitem>
+    <para>
+     In the configure phase, it calls <literal>perl Makefile.PL</literal> to generate a Makefile. You can set the variable <varname>makeMakerFlags</varname> to pass flags to <filename>Makefile.PL</filename>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     It adds the contents of the <envar>PERL5LIB</envar> environment variable to <literal>#! .../bin/perl</literal> line of Perl scripts as <literal>-I<replaceable>dir</replaceable></literal> flags. This ensures that a script can find its dependencies. (This can cause this shebang line to become too long for Darwin to handle; see the note below.)
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     In the fixup phase, it writes the propagated build inputs (<varname>propagatedBuildInputs</varname>) to the file <filename>$out/nix-support/propagated-user-env-packages</filename>. <command>nix-env</command> recursively installs all packages listed in this file when you install a package that has it. This ensures that a Perl package can find its dependencies.
+    </para>
+   </listitem>
+  </orderedlist>
+ </para>
 
-  <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>:
+ <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 }:
 
@@ -111,10 +78,10 @@ buildPerlPackage rec {
   '';
 }
 </programlisting>
-  </para>
+ </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:
+ <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";
@@ -127,10 +94,10 @@ ClassC3Componentised = buildPerlPackage rec {
   ];
 };
 </programlisting>
-  </para>
+ </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:
+ <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 }:
 
@@ -149,22 +116,22 @@ ImageExifTool = buildPerlPackage {
   '';
 };
 </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.
+  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>
+
+ <section xml:id="ssec-generation-from-CPAN">
+  <title>Generation from CPAN</title>
+
+  <para>
+   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>
 
-  <section xml:id="ssec-generation-from-CPAN">
-   <title>Generation from CPAN</title>
-
-   <para>
-    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>
 
-   <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:
+  <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 {
@@ -180,16 +147,15 @@ ImageExifTool = buildPerlPackage {
     };
   };
 </screen>
-    The output can be pasted into <filename>pkgs/top-level/perl-packages.nix</filename> or wherever else you need it.
-   </para>
-  </section>
+   The output can be pasted into <filename>pkgs/top-level/perl-packages.nix</filename> or wherever else you need it.
+  </para>
+ </section>
 
-  <section xml:id="ssec-perl-cross-compilation">
-   <title>Cross-compiling modules</title>
+ <section xml:id="ssec-perl-cross-compilation">
+  <title>Cross-compiling modules</title>
 
-   <para>
-    Nixpkgs has experimental support for cross-compiling Perl modules. In many cases, it will just work out of the box, even for modules with native extensions. Sometimes, however, the Makefile.PL for a module may (indirectly) import a native module. In that case, you will need to make a stub for that module that will satisfy the Makefile.PL and install it into <filename>lib/perl5/site_perl/cross_perl/${perl.version}</filename>. See the <varname>postInstall</varname> for <varname>DBI</varname> for an example.
-   </para>
-  </section>
+  <para>
+   Nixpkgs has experimental support for cross-compiling Perl modules. In many cases, it will just work out of the box, even for modules with native extensions. Sometimes, however, the Makefile.PL for a module may (indirectly) import a native module. In that case, you will need to make a stub for that module that will satisfy the Makefile.PL and install it into <filename>lib/perl5/site_perl/cross_perl/${perl.version}</filename>. See the <varname>postInstall</varname> for <varname>DBI</varname> for an example.
+  </para>
  </section>
 </section>

doc/languages-frameworks/php.section.md

@@ -1,137 +0,0 @@
-# PHP {#sec-php}
-
-## User Guide {#ssec-php-user-guide}
-
-### Overview {#ssec-php-user-guide-overview}
-
-Several versions of PHP are available on Nix, each of which having a
-wide variety of extensions and libraries available.
-
-The different versions of PHP that nixpkgs provides are located under
-attributes named based on major and minor version number; e.g.,
-`php74` is PHP 7.4.
-
-Only versions of PHP that are supported by upstream for the entirety
-of a given NixOS release will be included in that release of
-NixOS. See [PHP Supported
-Versions](https://www.php.net/supported-versions.php).
-
-The attribute `php` refers to the version of PHP considered most
-stable and thoroughly tested in nixpkgs for any given release of
-NixOS - not necessarily the latest major release from upstream.
-
-All available PHP attributes are wrappers around their respective
-binary PHP package and provide commonly used extensions this way. The
-real PHP 7.4 package, i.e. the unwrapped one, is available as
-`php74.unwrapped`; see the next section for more details.
-
-Interactive tools built on PHP are put in `php.packages`; composer is
-for example available at `php.packages.composer`.
-
-Most extensions that come with PHP, as well as some popular
-third-party ones, are available in `php.extensions`; for example, the
-opcache extension shipped with PHP is available at
-`php.extensions.opcache` and the third-party ImageMagick extension at
-`php.extensions.imagick`.
-
-### Installing PHP with extensions {#ssec-php-user-guide-installing-with-extensions}
-
-A PHP package with specific extensions enabled can be built using
-`php.withExtensions`. This is a function which accepts an anonymous
-function as its only argument; the function should accept two named
-parameters: `enabled` - a list of currently enabled extensions and
-`all` - the set of all extensions, and return a list of wanted
-extensions. For example, a PHP package with all default extensions and
-ImageMagick enabled:
-
-```nix
-php.withExtensions ({ enabled, all }:
-  enabled ++ [ all.imagick ])
-```
-
-To exclude some, but not all, of the default extensions, you can
-filter the `enabled` list like this:
-
-```nix
-php.withExtensions ({ enabled, all }:
-  (lib.filter (e: e != php.extensions.opcache) enabled)
-  ++ [ all.imagick ])
-```
-
-To build your list of extensions from the ground up, you can simply
-ignore `enabled`:
-
-```nix
-php.withExtensions ({ all, ... }: with all; [ imagick opcache ])
-```
-
-`php.withExtensions` provides extensions by wrapping a minimal php
-base package, providing a `php.ini` file listing all extensions to be
-loaded. You can access this package through the `php.unwrapped`
-attribute; useful if you, for example, need access to the `dev`
-output. The generated `php.ini` file can be accessed through the
-`php.phpIni` attribute.
-
-If you want a PHP build with extra configuration in the `php.ini`
-file, you can use `php.buildEnv`. This function takes two named and
-optional parameters: `extensions` and `extraConfig`. `extensions`
-takes an extension specification equivalent to that of
-`php.withExtensions`, `extraConfig` a string of additional `php.ini`
-configuration parameters. For example, a PHP package with the opcache
-and ImageMagick extensions enabled, and `memory_limit` set to `256M`:
-
-```nix
-php.buildEnv {
-  extensions = { all, ... }: with all; [ imagick opcache ];
-  extraConfig = "memory_limit=256M";
-}
-```
-
-#### Example setup for `phpfpm` {#ssec-php-user-guide-installing-with-extensions-phpfpm}
-
-You can use the previous examples in a `phpfpm` pool called `foo` as
-follows:
-
-```nix
-let
-  myPhp = php.withExtensions ({ all, ... }: with all; [ imagick opcache ]);
-in {
-  services.phpfpm.pools."foo".phpPackage = myPhp;
-};
-```
-
-```nix
-let
-  myPhp = php.buildEnv {
-    extensions = { all, ... }: with all; [ imagick opcache ];
-    extraConfig = "memory_limit=256M";
-  };
-in {
-  services.phpfpm.pools."foo".phpPackage = myPhp;
-};
-```
-
-#### Example usage with `nix-shell` {#ssec-php-user-guide-installing-with-extensions-nix-shell}
-
-This brings up a temporary environment that contains a PHP interpreter
-with the extensions `imagick` and `opcache` enabled:
-
-```sh
-nix-shell -p 'php.withExtensions ({ all, ... }: with all; [ imagick opcache ])'
-```
-
-### Installing PHP packages with extensions {#ssec-php-user-guide-installing-packages-with-extensions}
-
-All interactive tools use the PHP package you get them from, so all
-packages at `php.packages.*` use the `php` package with its default
-extensions. Sometimes this default set of extensions isn't enough and
-you may want to extend it. A common case of this is the `composer`
-package: a project may depend on certain extensions and `composer`
-won't work with that project unless those extensions are loaded.
-
-Example of building `composer` with additional extensions:
-```nix
-(php.withExtensions ({ all, enabled }:
-  enabled ++ (with all; [ imagick redis ]))
-).packages.composer
-```

doc/languages-frameworks/qt.xml

@@ -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>

doc/languages-frameworks/r.section.md

@@ -1,5 +1,5 @@
-R
-=
+R packages
+==========
 
 ## Installation
 

doc/languages-frameworks/ruby.xml

@@ -12,14 +12,14 @@
  </para>
 
 <screen>
-<prompt>$ </prompt>cd pkgs/servers/monitoring
-<prompt>$ </prompt>mkdir sensu
-<prompt>$ </prompt>cd sensu
-<prompt>$ </prompt>cat > Gemfile
+<![CDATA[$ cd pkgs/servers/monitoring
+$ mkdir sensu
+$ cd sensu
+$ cat > Gemfile
 source 'https://rubygems.org'
 gem 'sensu'
-<prompt>$ </prompt>$(nix-build '&lt;nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic
-<prompt>$ </prompt>cat > default.nix
+$ $(nix-build '<nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic
+$ cat > default.nix
 { lib, bundlerEnv, ruby }:
 
 bundlerEnv rec {
@@ -32,12 +32,12 @@ bundlerEnv rec {
 
   meta = with lib; {
     description = "A monitoring framework that aims to be simple, malleable, and scalable";
-    homepage    = "http://sensuapp.org/";
+    homepage    = http://sensuapp.org/;
     license     = with licenses; mit;
     maintainers = with maintainers; [ theuni ];
     platforms   = platforms.unix;
   };
-}
+}]]>
 </screen>
 
  <para>
@@ -49,16 +49,17 @@ bundlerEnv rec {
  </para>
 
 <screen>
-<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'
+<![CDATA[$ cd pkgs/servers/monitoring/sensu
+$ nix-shell -p bundler --run 'bundle lock --update'
+$ 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>
 
-<programlisting>
+<screen>
 <![CDATA[{ lib, bundlerApp }:
 
 bundlerApp {
@@ -68,13 +69,13 @@ bundlerApp {
 
   meta = with lib; {
     description = "Tool and libraries for maintaining Ruby gems.";
-    homepage    = "https://github.com/nyarly/corundum";
+    homepage    = https://github.com/nyarly/corundum;
     license     = licenses.mit;
     maintainers = [ maintainers.nyarly ];
     platforms   = platforms.unix;
   };
 }]]>
-</programlisting>
+</screen>
 
  <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.

doc/languages-frameworks/rust.section.md

@@ -4,7 +4,7 @@ author: Matthias Beyer
 date: 2017-03-05
 ---
 
-# Rust
+# User's Guide to the Rust Infrastructure
 
 To install the rust compiler and cargo put
 
@@ -16,6 +16,12 @@ cargo
 into the `environment.systemPackages` or bring them into
 scope with `nix-shell -p rustc cargo`.
 
+> If you are using NixOS and you want to use rust without a nix expression you
+> probably want to add the following in your `configuration.nix` to build
+> crates with C dependencies.
+>
+>     environment.systemPackages = [binutils gcc gnumake openssl pkgconfig]
+
 For daily builds (beta and nightly) use either rustup from
 nixpkgs or use the [Rust nightlies
 overlay](#using-the-rust-nightlies-overlay).
@@ -26,23 +32,24 @@ Rust applications are packaged by using the `buildRustPackage` helper from `rust
 
 ```
 rustPlatform.buildRustPackage rec {
-  pname = "ripgrep";
-  version = "11.0.2";
+  name = "ripgrep-${version}";
+  version = "0.4.0";
 
   src = fetchFromGitHub {
     owner = "BurntSushi";
-    repo = pname;
-    rev = version;
-    sha256 = "1iga3320mgi7m853la55xip514a3chqsdi1a1rwv25lr9b1p7vd3";
+    repo = "ripgrep";
+    rev = "${version}";
+    sha256 = "0y5d1n6hkw85jb3rblcxqas2fp82h3nghssa4xqrhqnz25l799pj";
   };
 
-  cargoSha256 = "17ldqr3asrdcsh4l29m3b5r37r5d0b3npq1lrgjmxb6vlx6a36qh";
+  cargoSha256 = "0q68qyl2h6i0qsz82z840myxlnjay8p1w5z7hfyr8fqp7wgwa9cx";
 
   meta = with stdenv.lib; {
     description = "A fast line-oriented regex search tool, similar to ag and ack";
-    homepage = "https://github.com/BurntSushi/ripgrep";
+    homepage = https://github.com/BurntSushi/ripgrep;
     license = licenses.unlicense;
     maintainers = [ maintainers.tailhook ];
+    platforms = platforms.all;
   };
 }
 ```
@@ -52,111 +59,10 @@ all crate sources of this package. Currently it is obtained by inserting a
 fake checksum into the expression and building the package once. The correct
 checksum can be then take from the failed build.
 
-Per the instructions in the [Cargo Book](https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html)
-best practices guide, Rust applications should always commit the `Cargo.lock`
-file in git to ensure a reproducible build. However, a few packages do not, and
-Nix depends on this file, so if it missing you can use `cargoPatches` to apply
-it in the `patchPhase`. Consider sending a PR upstream with a note to the
-maintainer describing why it's important to include in the application.
-
-The fetcher will verify that the `Cargo.lock` file is in sync with the `src`
-attribute, and fail the build if not. It will also will compress the vendor
-directory into a tar.gz archive.
-
-### Building a crate for a different target
-
-To build your crate with a different cargo `--target` simply specify the `target` attribute:
-
-```nix
-pkgs.rustPlatform.buildRustPackage {
-  (...)
-  target = "x86_64-fortanix-unknown-sgx";
-}
-```
-
-### Running package tests
-
-When using `buildRustPackage`, the `checkPhase` is enabled by default and runs
-`cargo test` on the package to build. To make sure that we don't compile the
-sources twice and to actually test the artifacts that will be used at runtime,
-the tests will be ran in the `release` mode by default.
-
-However, in some cases the test-suite of a package doesn't work properly in the
-`release` mode. For these situations, the mode for `checkPhase` can be changed like
-so:
-
-```nix
-rustPlatform.buildRustPackage {
-  /* ... */
-  checkType = "debug";
-}
-```
-
-Please note that the code will be compiled twice here: once in `release` mode
-for the `buildPhase`, and again in `debug` mode for the `checkPhase`.
-
-#### Tests relying on the structure of the `target/` directory
-
-Some tests may rely on the structure of the `target/` directory. Those tests
-are likely to fail because we use `cargo --target` during the build. This means that
-the artifacts
-[are stored in `target/<architecture>/release/`](https://doc.rust-lang.org/cargo/guide/build-cache.html),
-rather than in `target/release/`.
-
-This can only be worked around by patching the affected tests accordingly.
-
-#### Disabling package-tests
-
-In some instances, it may be necessary to disable testing altogether (with `doCheck = false;`):
-
-* If no tests exist -- the `checkPhase` should be explicitly disabled to skip
-  unnecessary build steps to speed up the build.
-* If tests are highly impure (e.g. due to network usage).
-
-There will obviously be some corner-cases not listed above where it's sensible to disable tests.
-The above are just guidelines, and exceptions may be granted on a case-by-case basis.
-
-However, please check if it's possible to disable a problematic subset of the
-test suite and leave a comment explaining your reasoning.
-
-### Building a package in `debug` mode
-
-By default, `buildRustPackage` will use `release` mode for builds. If a package
-should be built in `debug` mode, it can be configured like so:
-
-```nix
-rustPlatform.buildRustPackage {
-  /* ... */
-  buildType = "debug";
-}
-```
-
-In this scenario, the `checkPhase` will be ran in `debug` mode as well.
-
-### Custom `build`/`install`-procedures
-
-Some packages may use custom scripts for building/installing, e.g. with a `Makefile`.
-In these cases, it's recommended to override the `buildPhase`/`installPhase`/`checkPhase`.
-
-Otherwise, some steps may fail because of the modified directory structure of `target/`.
-
-### Building a crate with an absent or out-of-date Cargo.lock file
-
-`buildRustPackage` needs a `Cargo.lock` file to get all dependencies in the
-source code in a reproducible way. If it is missing or out-of-date one can use
-the `cargoPatches` attribute to update or add it.
-
-```
-{ lib, rustPlatform, fetchFromGitHub }:
-
-rustPlatform.buildRustPackage rec {
-  (...)
-  cargoPatches = [
-    # a patch file to add/update Cargo.lock in the source code
-    ./add-Cargo.lock.patch
-  ];
-}
-```
+When the `Cargo.lock`, provided by upstream, is not in sync with the
+`Cargo.toml`, it is possible to use `cargoPatches` to update it. All patches
+added in `cargoPatches` will also be prepended to the patches in `patches` at
+build-time.
 
 ## Compiling Rust crates using Nix instead of Cargo
 
@@ -282,7 +188,7 @@ argument and returns a set that contains all attribute that should be
 overwritten.
 
 For more complicated cases, such as when parts of the crate's
-derivation depend on the crate's version, the `attrs` argument of
+derivation depend on the the crate's version, the `attrs` argument of
 the override above can be read, as in the following example, which
 patches the derivation:
 

doc/languages-frameworks/texlive.xml

@@ -44,11 +44,11 @@ texlive.combine {
    <listitem>
     <para>
      You can list packages e.g. by <command>nix repl</command>.
-<programlisting>
-<prompt>$ </prompt>nix repl
-<prompt>nix-repl> </prompt>:l &lt;nixpkgs>
-<prompt>nix-repl> </prompt>texlive.collection-<keycap function="tab" />
-</programlisting>
+<programlisting><![CDATA[
+$ nix repl
+nix-repl> :l <nixpkgs>
+nix-repl> texlive.collection-<TAB>
+]]></programlisting>
     </para>
    </listitem>
    <listitem>
@@ -59,94 +59,30 @@ texlive.combine {
   </itemizedlist>
  </section>
 
- <section xml:id="sec-language-texlive-custom-packages">
-  <title>Custom packages</title>
-  <para>
-    You may find that you need to use an external TeX package. A derivation for such package has to provide contents of the "texmf" directory in its output and provide the <varname>tlType</varname> attribute. Here is a (very verbose) example:
-<programlisting><![CDATA[
-with import <nixpkgs> {};
+ <section xml:id="sec-language-texlive-known-problems">
+  <title>Known problems</title>
 
-let
-  foiltex_run = stdenvNoCC.mkDerivation {
-    pname = "latex-foiltex";
-    version = "2.1.4b";
-    passthru.tlType = "run";
-
-    srcs = [
-      (fetchurl {
-        url = "http://mirrors.ctan.org/macros/latex/contrib/foiltex/foiltex.dtx";
-        sha256 = "07frz0krpz7kkcwlayrwrj2a2pixmv0icbngyw92srp9fp23cqpz";
-      })
-      (fetchurl {
-        url = "http://mirrors.ctan.org/macros/latex/contrib/foiltex/foiltex.ins";
-        sha256 = "09wkyidxk3n3zvqxfs61wlypmbhi1pxmjdi1kns9n2ky8ykbff99";
-      })
-    ];
-
-    unpackPhase = ''
-      runHook preUnpack
-
-      for _src in $srcs; do
-        cp "$_src" $(stripHash "$_src")
-      done
-
-      runHook postUnpack
-    '';
-
-    nativeBuildInputs = [ texlive.combined.scheme-small ];
-
-    dontConfigure = true;
-
-    buildPhase = ''
-      runHook preBuild
-
-      # Generate the style files
-      latex foiltex.ins
-
-      runHook postBuild
-    '';
-
-    installPhase = ''
-      runHook preInstall
-
-      path="$out/tex/latex/foiltex"
-      mkdir -p "$path"
-      cp *.{cls,def,clo} "$path/"
-
-      runHook postInstall
-    '';
-
-    meta = with lib; {
-      description = "A LaTeX2e class for overhead transparencies";
-      license = licenses.unfreeRedistributable;
-      maintainers = with maintainers; [ veprbl ];
-      platforms = platforms.all;
-    };
-  };
-  foiltex = { pkgs = [ foiltex_run ]; };
-
-  latex_with_foiltex = texlive.combine {
-    inherit (texlive) scheme-small;
-    inherit foiltex;
-  };
-in
-  runCommand "test.pdf" {
-    nativeBuildInputs = [ latex_with_foiltex ];
-  } ''
-cat >test.tex <<EOF
-\documentclass{foils}
-
-\title{Presentation title}
-\date{}
-
-\begin{document}
-\maketitle
-\end{document}
-EOF
-  pdflatex test.tex
-  cp test.pdf $out
-''
-]]></programlisting>
-  </para>
+  <itemizedlist>
+   <listitem>
+    <para>
+     Some tools are still missing, e.g. luajittex;
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     some apps aren't packaged/tested yet (asymptote, biber, etc.);
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     feature/bug: when a package is rejected by <varname>pkgFilter</varname>, its dependencies are still propagated;
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     in case of any bugs or feature requests, file a github issue or better a pull request and /cc @vcunat.
+    </para>
+   </listitem>
+  </itemizedlist>
  </section>
 </section>

doc/languages-frameworks/vim.section.md

@@ -3,7 +3,7 @@ title: User's Guide for Vim in Nixpkgs
 author: Marc Weber
 date: 2016-06-25
 ---
-# Vim
+# User's Guide to Vim Plugins/Addons/Bundles/Scripts in Nixpkgs
 
 Both Neovim and Vim can be configured to include your favorite plugins
 and additional libraries.
@@ -261,9 +261,12 @@ deoplete-fish = super.deoplete-fish.overrideAttrs(old: {
 
 Sometimes plugins require an override that must be changed when the plugin is updated. This can cause issues when Vim plugins are auto-updated but the associated override isn't updated. For these plugins, the override should be written so that it specifies all information required to install the plugin, and running `./update.py` doesn't change the derivation for the plugin. Manually updating the override is required to update these types of plugins. An example of such a plugin is `LanguageClient-neovim`.
 
-To add a new plugin, run `./update.py --add "[owner]/[name]"`. **NOTE**: This script automatically commits to your git repository. Be sure to check out a fresh branch before running.
+To add a new plugin:
 
-Finally, there are some plugins that are also packaged in nodePackages because they have Javascript-related build steps, such as running webpack. Those plugins are not listed in `vim-plugin-names` or managed by `update.py` at all, and are included separately in `overrides.nix`. Currently, all these plugins are related to the `coc.nvim` ecosystem of Language Server Protocol integration with vim/neovim.
+  1. run `./update.py` and create a commit named "vimPlugins: Update",
+  2. add the new plugin to [vim-plugin-names](/pkgs/misc/vim-plugins/vim-plugin-names) and add overrides if required to [overrides.nix](/pkgs/misc/vim-plugins/overrides.nix),
+  3. run `./update.py` again and create a commit named "vimPlugins.[name]: init at [version]" (where `name` and `version` can be found in [generated.nix](/pkgs/misc/vim-plugins/generated.nix)), and
+  4. create a pull request.
 
 ## Important repositories
 

doc/manual.xml

@@ -1,41 +1,25 @@
 <book xmlns="http://docbook.org/ns/docbook"
       xmlns:xi="http://www.w3.org/2001/XInclude">
  <info>
-  <title>Nixpkgs Manual</title>
+  <title>Nixpkgs Users and Contributors Guide</title>
   <subtitle>Version <xi:include href=".version" parse="text" />
   </subtitle>
  </info>
- <xi:include href="preface.chapter.xml" />
- <part>
-  <title>Using Nixpkgs</title>
-  <xi:include href="using/configuration.xml" />
-  <xi:include href="using/overlays.xml" />
-  <xi:include href="using/overrides.xml" />
-  <xi:include href="functions.xml" />
- </part>
- <part>
-  <title>Standard environment</title>
-  <xi:include href="stdenv/stdenv.xml" />
-  <xi:include href="stdenv/meta.xml" />
-  <xi:include href="stdenv/multiple-output.xml" />
-  <xi:include href="stdenv/cross-compilation.xml" />
-  <xi:include href="stdenv/platform-notes.xml" />
- </part>
- <part>
-  <title>Builders</title>
-  <xi:include href="builders/fetchers.xml" />
-  <xi:include href="builders/trivial-builders.xml" />
-  <xi:include href="builders/special.xml" />
-  <xi:include href="builders/images.xml" />
-  <xi:include href="languages-frameworks/index.xml" />
-  <xi:include href="builders/packages/index.xml" />
- </part>
- <part>
-  <title>Contributing to Nixpkgs</title>
-  <xi:include href="contributing/quick-start.xml" />
-  <xi:include href="contributing/coding-conventions.xml" />
-  <xi:include href="contributing/submitting-changes.xml" />
-  <xi:include href="contributing/reviewing-contributions.xml" />
-  <xi:include href="contributing/contributing-to-documentation.xml" />
- </part>
+ <xi:include href="introduction.chapter.xml" />
+ <xi:include href="quick-start.xml" />
+ <xi:include href="package-specific-user-notes.xml" />
+ <xi:include href="stdenv.xml" />
+ <xi:include href="multiple-output.xml" />
+ <xi:include href="cross-compilation.xml" />
+ <xi:include href="configuration.xml" />
+ <xi:include href="functions.xml" />
+ <xi:include href="meta.xml" />
+ <xi:include href="languages-frameworks/index.xml" />
+ <xi:include href="platform-notes.xml" />
+ <xi:include href="package-notes.xml" />
+ <xi:include href="overlays.xml" />
+ <xi:include href="coding-conventions.xml" />
+ <xi:include href="submitting-changes.xml" />
+ <xi:include href="reviewing-contributions.xml" />
+ <xi:include href="contributing.xml" />
 </book>

doc/meta.xml

@@ -11,7 +11,7 @@ meta = with stdenv.lib; {
     GNU Hello is a program that prints "Hello, world!" when you run it.
     It is fully customizable.
   '';
-  homepage = "https://www.gnu.org/software/hello/manual/";
+  homepage = https://www.gnu.org/software/hello/manual/;
   license = licenses.gpl3Plus;
   maintainers = [ maintainers.eelco ];
   platforms = platforms.all;
@@ -155,17 +155,17 @@ hello-2.3  A program that produces a familiar, friendly greeting
       <itemizedlist>
        <listitem>
         <para>
-         Single license referenced by attribute (preferred) <literal>stdenv.lib.licenses.gpl3Only</literal>.
+         Single license referenced by attribute (preferred) <literal>stdenv.lib.licenses.gpl3</literal>.
         </para>
        </listitem>
        <listitem>
         <para>
-         Single license referenced by its attribute shortName (frowned upon) <literal>"gpl3Only"</literal>.
+         Single license referenced by its attribute shortName (frowned upon) <literal>"gpl3"</literal>.
         </para>
        </listitem>
        <listitem>
         <para>
-         Single license referenced by its attribute spdxId (frowned upon) <literal>"GPL-3.0-only"</literal>.
+         Single license referenced by its attribute spdxId (frowned upon) <literal>"GPL-3.0"</literal>.
         </para>
        </listitem>
        <listitem>

doc/multiple-output.xml

@@ -0,0 +1,232 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE chapter [
+  <!ENTITY ndash "&#x2013;"> <!-- @vcunat likes to use this one ;-) -->
+]>
+<chapter xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xml:id="chap-multiple-output">
+ <title>Multiple-output packages</title>
+ <section xml:id="sec-multiple-outputs-introduction">
+  <title>Introduction</title>
+
+  <para>
+   The Nix language allows a derivation to produce multiple outputs, which is similar to what is utilized by other Linux distribution packaging systems. The outputs reside in separate Nix store paths, so they can be mostly handled independently of each other, including passing to build inputs, garbage collection or binary substitution. The exception is that building from source always produces all the outputs.
+  </para>
+
+  <para>
+   The main motivation is to save disk space by reducing runtime closure sizes; consequently also sizes of substituted binaries get reduced. Splitting can be used to have more granular runtime dependencies, for example the typical reduction is to split away development-only files, as those are typically not needed during runtime. As a result, closure sizes of many packages can get reduced to a half or even much less.
+  </para>
+
+  <note>
+   <para>
+    The reduction effects could be instead achieved by building the parts in completely separate derivations. That would often additionally reduce build-time closures, but it tends to be much harder to write such derivations, as build systems typically assume all parts are being built at once. This compromise approach of single source package producing multiple binary packages is also utilized often by rpm and deb.
+   </para>
+  </note>
+ </section>
+ <section xml:id="sec-multiple-outputs-installing">
+  <title>Installing a split package</title>
+
+  <para>
+   When installing a package via <varname>systemPackages</varname> or <command>nix-env</command> you have several options:
+  </para>
+
+  <itemizedlist>
+   <listitem>
+    <para>
+     You can install particular outputs explicitly, as each is available in the Nix language as an attribute of the package. The <varname>outputs</varname> attribute contains a list of output names.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     You can let it use the default outputs. These are handled by <varname>meta.outputsToInstall</varname> attribute that contains a list of output names.
+    </para>
+    <para>
+     TODO: more about tweaking the attribute, etc.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     NixOS provides configuration option <varname>environment.extraOutputsToInstall</varname> that allows adding extra outputs of <varname>environment.systemPackages</varname> atop the default ones. It's mainly meant for documentation and debug symbols, and it's also modified by specific options.
+    </para>
+    <note>
+     <para>
+      At this moment there is no similar configurability for packages installed by <command>nix-env</command>. You can still use approach from <xref linkend="sec-modify-via-packageOverrides" /> to override <varname>meta.outputsToInstall</varname> attributes, but that's a rather inconvenient way.
+     </para>
+    </note>
+   </listitem>
+  </itemizedlist>
+ </section>
+ <section xml:id="sec-multiple-outputs-using-split-packages">
+  <title>Using a split package</title>
+
+  <para>
+   In the Nix language the individual outputs can be reached explicitly as attributes, e.g. <varname>coreutils.info</varname>, but the typical case is just using packages as build inputs.
+  </para>
+
+  <para>
+   When a multiple-output derivation gets into a build input of another derivation, the <varname>dev</varname> output is added if it exists, otherwise the first output is added. In addition to that, <varname>propagatedBuildOutputs</varname> of that package which by default contain <varname>$outputBin</varname> and <varname>$outputLib</varname> are also added. (See <xref linkend="multiple-output-file-type-groups" />.)
+  </para>
+
+  <para>
+   In some cases it may be desirable to combine different outputs under a single store path. A function <literal>symlinkJoin</literal> can be used to do this. (Note that it may negate some closure size benefits of using a multiple-output package.)
+  </para>
+ </section>
+ <section xml:id="sec-multiple-outputs-">
+  <title>Writing a split derivation</title>
+
+  <para>
+   Here you find how to write a derivation that produces multiple outputs.
+  </para>
+
+  <para>
+   In nixpkgs there is a framework supporting multiple-output derivations. It tries to cover most cases by default behavior. You can find the source separated in &lt;<filename>nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh</filename>&gt;; it's relatively well-readable. The whole machinery is triggered by defining the <varname>outputs</varname> attribute to contain the list of desired output names (strings).
+  </para>
+
+<programlisting>outputs = [ "bin" "dev" "out" "doc" ];</programlisting>
+
+  <para>
+   Often such a single line is enough. For each output an equally named environment variable is passed to the builder and contains the path in nix store for that output. Typically you also want to have the main <varname>out</varname> output, as it catches any files that didn't get elsewhere.
+  </para>
+
+  <note>
+   <para>
+    There is a special handling of the <varname>debug</varname> output, described at <xref linkend="stdenv-separateDebugInfo" />.
+   </para>
+  </note>
+
+  <section xml:id="multiple-output-file-binaries-first-convention">
+   <title><quote>Binaries first</quote></title>
+
+   <para>
+    A commonly adopted convention in <literal>nixpkgs</literal> is that executables provided by the package are contained within its first output. This convention allows the dependent packages to reference the executables provided by packages in a uniform manner. For instance, provided with the knowledge that the <literal>perl</literal> package contains a <literal>perl</literal> executable it can be referenced as <literal>${pkgs.perl}/bin/perl</literal> within a Nix derivation that needs to execute a Perl script.
+   </para>
+
+   <para>
+    The <literal>glibc</literal> package is a deliberate single exception to the <quote>binaries first</quote> convention. The <literal>glibc</literal> has <literal>libs</literal> as its first output allowing the libraries provided by <literal>glibc</literal> to be referenced directly (e.g. <literal>${stdenv.glibc}/lib/ld-linux-x86-64.so.2</literal>). The executables provided by <literal>glibc</literal> can be accessed via its <literal>bin</literal> attribute (e.g. <literal>${stdenv.glibc.bin}/bin/ldd</literal>).
+   </para>
+
+   <para>
+    The reason for why <literal>glibc</literal> deviates from the convention is because referencing a library provided by <literal>glibc</literal> is a very common operation among Nix packages. For instance, third-party executables packaged by Nix are typically patched and relinked with the relevant version of <literal>glibc</literal> libraries from Nix packages (please see the documentation on <link xlink:href="https://nixos.org/patchelf.html">patchelf</link> for more details).
+   </para>
+  </section>
+
+  <section xml:id="multiple-output-file-type-groups">
+   <title>File type groups</title>
+
+   <para>
+    The support code currently recognizes some particular kinds of outputs and either instructs the build system of the package to put files into their desired outputs or it moves the files during the fixup phase. Each group of file types has an <varname>outputFoo</varname> variable specifying the output name where they should go. If that variable isn't defined by the derivation writer, it is guessed &ndash; a default output name is defined, falling back to other possibilities if the output isn't defined.
+   </para>
+
+   <variablelist>
+    <varlistentry>
+     <term>
+      <varname> $outputDev</varname>
+     </term>
+     <listitem>
+      <para>
+       is for development-only files. These include C(++) headers, pkg-config, cmake and aclocal files. They go to <varname>dev</varname> or <varname>out</varname> by default.
+      </para>
+     </listitem>
+    </varlistentry>
+    <varlistentry>
+     <term>
+      <varname> $outputBin</varname>
+     </term>
+     <listitem>
+      <para>
+       is meant for user-facing binaries, typically residing in bin/. They go to <varname>bin</varname> or <varname>out</varname> by default.
+      </para>
+     </listitem>
+    </varlistentry>
+    <varlistentry>
+     <term>
+      <varname> $outputLib</varname>
+     </term>
+     <listitem>
+      <para>
+       is meant for libraries, typically residing in <filename>lib/</filename> and <filename>libexec/</filename>. They go to <varname>lib</varname> or <varname>out</varname> by default.
+      </para>
+     </listitem>
+    </varlistentry>
+    <varlistentry>
+     <term>
+      <varname> $outputDoc</varname>
+     </term>
+     <listitem>
+      <para>
+       is for user documentation, typically residing in <filename>share/doc/</filename>. It goes to <varname>doc</varname> or <varname>out</varname> by default.
+      </para>
+     </listitem>
+    </varlistentry>
+    <varlistentry>
+     <term>
+      <varname> $outputDevdoc</varname>
+     </term>
+     <listitem>
+      <para>
+       is for <emphasis>developer</emphasis> documentation. Currently we count gtk-doc and devhelp books in there. It goes to <varname>devdoc</varname> or is removed (!) by default. This is because e.g. gtk-doc tends to be rather large and completely unused by nixpkgs users.
+      </para>
+     </listitem>
+    </varlistentry>
+    <varlistentry>
+     <term>
+      <varname> $outputMan</varname>
+     </term>
+     <listitem>
+      <para>
+       is for man pages (except for section 3). They go to <varname>man</varname> or <varname>$outputBin</varname> by default.
+      </para>
+     </listitem>
+    </varlistentry>
+    <varlistentry>
+     <term>
+      <varname> $outputDevman</varname>
+     </term>
+     <listitem>
+      <para>
+       is for section 3 man pages. They go to <varname>devman</varname> or <varname>$outputMan</varname> by default.
+      </para>
+     </listitem>
+    </varlistentry>
+    <varlistentry>
+     <term>
+      <varname> $outputInfo</varname>
+     </term>
+     <listitem>
+      <para>
+       is for info pages. They go to <varname>info</varname> or <varname>$outputBin</varname> by default.
+      </para>
+     </listitem>
+    </varlistentry>
+   </variablelist>
+  </section>
+
+  <section xml:id="sec-multiple-outputs-caveats">
+   <title>Common caveats</title>
+
+   <itemizedlist>
+    <listitem>
+     <para>
+      Some configure scripts don't like some of the parameters passed by default by the framework, e.g. <literal>--docdir=/foo/bar</literal>. You can disable this by setting <literal>setOutputFlags = false;</literal>.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      The outputs of a single derivation can retain references to each other, but note that circular references are not allowed. (And each strongly-connected component would act as a single output anyway.)
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Most of split packages contain their core functionality in libraries. These libraries tend to refer to various kind of data that typically gets into <varname>out</varname>, e.g. locale strings, so there is often no advantage in separating the libraries into <varname>lib</varname>, as keeping them in <varname>out</varname> is easier.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Some packages have hidden assumptions on install paths, which complicates splitting.
+     </para>
+    </listitem>
+   </itemizedlist>
+  </section>
+ </section>
+<!--Writing a split derivation-->
+</chapter>

doc/old/cross.txt

@@ -60,7 +60,7 @@ stdenv.mkDerivation {
   name = "binutils-2.16.1-arm";
   builder = ./builder.sh;
   src = fetchurl {
-    url = "http://ftp.nluug.nl/gnu/binutils/binutils-2.16.1.tar.bz2";
+    url = http://ftp.nluug.nl/gnu/binutils/binutils-2.16.1.tar.bz2;
     sha256 = "1ian3kwh2vg6hr3ymrv48s04gijs539vzrq62xr76bxbhbwnz2np";
   };
   inherit noSysDirs;
@@ -84,7 +84,7 @@ stdenv.mkDerivation {
   name = "linux-headers-2.6.13.1-arm";
   builder = ./builder.sh;
   src = fetchurl {
-    url = "http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.1.tar.bz2";
+    url = http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.1.tar.bz2;
     sha256 = "12qxmc827fjhaz53kjy7vyrzsaqcg78amiqsb3qm20z26w705lma";
   };
 }
@@ -220,7 +220,7 @@ fi
 
 preConfigure=preConfigure
 preConfigure() {
-
+    
     # Determine the frontends to build.
     langs="c"
     if test -n "$langCC"; then
@@ -262,7 +262,7 @@ postInstall() {
 
 #if test -z "$profiledCompiler"; then
     #makeFlags="bootstrap"
-#else
+#else    
     #makeFlags="profiledbootstrap"
 #fi
 

doc/overlays.xml

@@ -0,0 +1,140 @@
+<chapter xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xml:id="chap-overlays">
+ <title>Overlays</title>
+ <para>
+  This chapter describes how to extend and change Nixpkgs using overlays. Overlays are used to add layers in the fixed-point used by Nixpkgs to compose the set of all packages.
+ </para>
+ <para>
+  Nixpkgs can be configured with a list of overlays, which are applied in order. This means that the order of the overlays can be significant if multiple layers override the same package.
+ </para>
+<!--============================================================-->
+ <section xml:id="sec-overlays-install">
+  <title>Installing overlays</title>
+
+  <para>
+   The list of overlays can be set either explicitly in a Nix expression, or through <literal>&lt;nixpkgs-overlays></literal> or user configuration files.
+  </para>
+
+  <section xml:id="sec-overlays-argument">
+   <title>Set overlays in NixOS or Nix expressions</title>
+
+   <para>
+    On a NixOS system the value of the <literal>nixpkgs.overlays</literal> option, if present, is passed to the system Nixpkgs directly as an argument. Note that this does not affect the overlays for non-NixOS operations (e.g. <literal>nix-env</literal>), which are <link xlink:href="#sec-overlays-lookup">looked</link> up independently.
+   </para>
+
+   <para>
+    The list of overlays can be passed explicitly when importing nixpkgs, for example <literal>import &lt;nixpkgs> { overlays = [ overlay1 overlay2 ]; }</literal>.
+   </para>
+
+   <para>
+    Further overlays can be added by calling the <literal>pkgs.extend</literal> or <literal>pkgs.appendOverlays</literal>, although it is often preferable to avoid these functions, because they recompute the Nixpkgs fixpoint, which is somewhat expensive to do.
+   </para>
+  </section>
+
+  <section xml:id="sec-overlays-lookup">
+   <title>Install overlays via configuration lookup</title>
+
+   <para>
+    The list of overlays is determined as follows.
+   </para>
+
+   <para>
+    <orderedlist>
+     <listitem>
+      <para>
+       First, if an <link xlink:href="#sec-overlays-argument"><varname>overlays</varname> argument</link> to the Nixpkgs function itself is given, then that is used and no path lookup will be performed.
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       Otherwise, if the Nix path entry <literal>&lt;nixpkgs-overlays></literal> exists, we look for overlays at that path, as described below.
+      </para>
+      <para>
+       See the section on <literal>NIX_PATH</literal> in the Nix manual for more details on how to set a value for <literal>&lt;nixpkgs-overlays>.</literal>
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       If one of <filename>~/.config/nixpkgs/overlays.nix</filename> and <filename>~/.config/nixpkgs/overlays/</filename> exists, then we look for overlays at that path, as described below. It is an error if both exist.
+      </para>
+     </listitem>
+    </orderedlist>
+   </para>
+
+   <para>
+    If we are looking for overlays at a path, then there are two cases:
+    <itemizedlist>
+     <listitem>
+      <para>
+       If the path is a file, then the file is imported as a Nix expression and used as the list of overlays.
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       If the path is a directory, then we take the content of the directory, order it lexicographically, and attempt to interpret each as an overlay by:
+       <itemizedlist>
+        <listitem>
+         <para>
+          Importing the file, if it is a <literal>.nix</literal> file.
+         </para>
+        </listitem>
+        <listitem>
+         <para>
+          Importing a top-level <filename>default.nix</filename> file, if it is a directory.
+         </para>
+        </listitem>
+       </itemizedlist>
+      </para>
+     </listitem>
+    </itemizedlist>
+   </para>
+
+   <para>
+    Because overlays that are set in NixOS configuration do not affect non-NixOS operations such as <literal>nix-env</literal>, the <filename>overlays.nix</filename> option provides a convenient way to use the same overlays for a NixOS system configuration and user configuration: the same file can be used as <filename>overlays.nix</filename> and imported as the value of <literal>nixpkgs.overlays</literal>.
+   </para>
+
+<!-- TODO: Example of sharing overlays between NixOS configuration
+     and configuration lookup. Also reference the example
+     from the sec-overlays-argument paragraph about NixOS.
+ -->
+  </section>
+ </section>
+<!--============================================================-->
+ <section xml:id="sec-overlays-definition">
+  <title>Defining overlays</title>
+
+  <para>
+   Overlays are Nix functions which accept two arguments, conventionally called <varname>self</varname> and <varname>super</varname>, and return a set of packages. For example, the following is a valid overlay.
+  </para>
+
+<programlisting>
+self: super:
+
+{
+  boost = super.boost.override {
+    python = self.python3;
+  };
+  rr = super.callPackage ./pkgs/rr {
+    stdenv = self.stdenv_32bit;
+  };
+}
+</programlisting>
+
+  <para>
+   The first argument (<varname>self</varname>) corresponds to the final package set. You should use this set for the dependencies of all packages specified in your overlay. For example, all the dependencies of <varname>rr</varname> in the example above come from <varname>self</varname>, as well as the overridden dependencies used in the <varname>boost</varname> override.
+  </para>
+
+  <para>
+   The second argument (<varname>super</varname>) corresponds to the result of the evaluation of the previous stages of Nixpkgs. It does not contain any of the packages added by the current overlay, nor any of the following overlays. This set should be used either to refer to packages you wish to override, or to access functions defined in Nixpkgs. For example, the original recipe of <varname>boost</varname> in the above example, comes from <varname>super</varname>, as well as the <varname>callPackage</varname> function.
+  </para>
+
+  <para>
+   The value returned by this function should be a set similar to <filename>pkgs/top-level/all-packages.nix</filename>, containing overridden and/or new packages.
+  </para>
+
+  <para>
+   Overlays are similar to other methods for customizing Nixpkgs, in particular the <literal>packageOverrides</literal> attribute described in <xref linkend="sec-modify-via-packageOverrides"/>. Indeed, <literal>packageOverrides</literal> acts as an overlay with only the <varname>super</varname> argument. It is therefore appropriate for basic use, but overlays are more powerful and easier to distribute.
+  </para>
+ </section>
+</chapter>

doc/overrides.css

@@ -1,22 +1,9 @@
 .docbook .xref img[src^=images\/callouts\/],
 .screen img,
-.programlisting img,
-.literallayout img,
-.synopsis img {
+.programlisting img {
     width: 1em;
 }
 
 .calloutlist img {
     width: 1.5em;
 }
-
-.prompt,
-.screen img,
-.programlisting img,
-.literallayout img,
-.synopsis img {
-    -moz-user-select: none;
-    -webkit-user-select: none;
-    -ms-user-select: none;
-    user-select: none;
-}

doc/package-notes.xml

@@ -0,0 +1,422 @@
+<chapter xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xml:id="chap-package-notes">
+ <title>Package Notes</title>
+ <para>
+  This chapter contains information about how to use and maintain the Nix expressions for a number of specific packages, such as the Linux kernel or X.org.
+ </para>
+<!--============================================================-->
+ <section xml:id="sec-linux-kernel">
+  <title>Linux kernel</title>
+
+  <para>
+   The Nix expressions to build the Linux kernel are in <link
+xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel"><filename>pkgs/os-specific/linux/kernel</filename></link>.
+  </para>
+
+  <para>
+   The function that builds the kernel has an argument <varname>kernelPatches</varname> which should be a list of <literal>{name, patch, extraConfig}</literal> attribute sets, where <varname>name</varname> is the name of the patch (which is included in the kernel’s <varname>meta.description</varname> attribute), <varname>patch</varname> is the patch itself (possibly compressed), and <varname>extraConfig</varname> (optional) is a string specifying extra options to be concatenated to the kernel configuration file (<filename>.config</filename>).
+  </para>
+
+  <para>
+   The kernel derivation exports an attribute <varname>features</varname> specifying whether optional functionality is or isn’t enabled. This is used in NixOS to implement kernel-specific behaviour. For instance, if the kernel has the <varname>iwlwifi</varname> feature (i.e. has built-in support for Intel wireless chipsets), then NixOS doesn’t have to build the external <varname>iwlwifi</varname> package:
+<programlisting>
+modulesTree = [kernel]
+  ++ pkgs.lib.optional (!kernel.features ? iwlwifi) kernelPackages.iwlwifi
+  ++ ...;
+</programlisting>
+  </para>
+
+  <para>
+   How to add a new (major) version of the Linux kernel to Nixpkgs:
+   <orderedlist>
+    <listitem>
+     <para>
+      Copy the old Nix expression (e.g. <filename>linux-2.6.21.nix</filename>) to the new one (e.g. <filename>linux-2.6.22.nix</filename>) and update it.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Add the new kernel to <filename>all-packages.nix</filename> (e.g., create an attribute <varname>kernel_2_6_22</varname>).
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Now we’re going to update the kernel configuration. First unpack the kernel. Then for each supported platform (<literal>i686</literal>, <literal>x86_64</literal>, <literal>uml</literal>) do the following:
+      <orderedlist>
+       <listitem>
+        <para>
+         Make an copy from the old config (e.g. <filename>config-2.6.21-i686-smp</filename>) to the new one (e.g. <filename>config-2.6.22-i686-smp</filename>).
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         Copy the config file for this platform (e.g. <filename>config-2.6.22-i686-smp</filename>) to <filename>.config</filename> in the kernel source tree.
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         Run <literal>make oldconfig ARCH=<replaceable>{i386,x86_64,um}</replaceable></literal> and answer all questions. (For the uml configuration, also add <literal>SHELL=bash</literal>.) Make sure to keep the configuration consistent between platforms (i.e. don’t enable some feature on <literal>i686</literal> and disable it on <literal>x86_64</literal>).
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         If needed you can also run <literal>make menuconfig</literal>:
+<screen>
+<prompt>$ </prompt>nix-env -i ncurses
+<prompt>$ </prompt>export NIX_CFLAGS_LINK=-lncurses
+<prompt>$ </prompt>make menuconfig ARCH=<replaceable>arch</replaceable></screen>
+        </para>
+       </listitem>
+       <listitem>
+        <para>
+         Copy <filename>.config</filename> over the new config file (e.g. <filename>config-2.6.22-i686-smp</filename>).
+        </para>
+       </listitem>
+      </orderedlist>
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      Test building the kernel: <literal>nix-build -A kernel_2_6_22</literal>. If it compiles, ship it! For extra credit, try booting NixOS with it.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      It may be that the new kernel requires updating the external kernel modules and kernel-dependent packages listed in the <varname>linuxPackagesFor</varname> function in <filename>all-packages.nix</filename> (such as the NVIDIA drivers, AUFS, etc.). If the updated packages aren’t backwards compatible with older kernels, you may need to keep the older versions around.
+     </para>
+    </listitem>
+   </orderedlist>
+  </para>
+ </section>
+<!--============================================================-->
+ <section xml:id="sec-xorg">
+  <title>X.org</title>
+
+  <para>
+   The Nix expressions for the X.org packages reside in <filename>pkgs/servers/x11/xorg/default.nix</filename>. This file is automatically generated from lists of tarballs in an X.org release. As such it should not be modified directly; rather, you should modify the lists, the generator script or the file <filename>pkgs/servers/x11/xorg/overrides.nix</filename>, in which you can override or add to the derivations produced by the generator.
+  </para>
+
+  <para>
+   The generator is invoked as follows:
+<screen>
+<prompt>$ </prompt>cd pkgs/servers/x11/xorg
+<prompt>$ </prompt>cat tarballs-7.5.list extra.list old.list \
+  | perl ./generate-expr-from-tarballs.pl
+</screen>
+   For each of the tarballs in the <filename>.list</filename> files, the script downloads it, unpacks it, and searches its <filename>configure.ac</filename> and <filename>*.pc.in</filename> files for dependencies. This information is used to generate <filename>default.nix</filename>. The generator caches downloaded tarballs between runs. Pay close attention to the <literal>NOT FOUND: <replaceable>name</replaceable></literal> messages at the end of the run, since they may indicate missing dependencies. (Some might be optional dependencies, however.)
+  </para>
+
+  <para>
+   A file like <filename>tarballs-7.5.list</filename> contains all tarballs in a X.org release. It can be generated like this:
+<screen>
+<prompt>$ </prompt>export i="mirror://xorg/X11R7.4/src/everything/"
+<prompt>$ </prompt>cat $(PRINT_PATH=1 nix-prefetch-url $i | tail -n 1) \
+  | perl -e 'while (&lt;>) { if (/(href|HREF)="([^"]*.bz2)"/) { print "$ENV{'i'}$2\n"; }; }' \
+  | sort > tarballs-7.4.list
+</screen>
+   <filename>extra.list</filename> contains libraries that aren’t part of X.org proper, but are closely related to it, such as <literal>libxcb</literal>. <filename>old.list</filename> contains some packages that were removed from X.org, but are still needed by some people or by other packages (such as <varname>imake</varname>).
+  </para>
+
+  <para>
+   If the expression for a package requires derivation attributes that the generator cannot figure out automatically (say, <varname>patches</varname> or a <varname>postInstall</varname> hook), you should modify <filename>pkgs/servers/x11/xorg/overrides.nix</filename>.
+  </para>
+ </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>
+-->
+<!--============================================================-->
+ <section xml:id="sec-eclipse">
+  <title>Eclipse</title>
+
+  <para>
+   The Nix expressions related to the Eclipse platform and IDE are in <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/eclipse"><filename>pkgs/applications/editors/eclipse</filename></link>.
+  </para>
+
+  <para>
+   Nixpkgs provides a number of packages that will install Eclipse in its various forms. These range from the bare-bones Eclipse Platform to the more fully featured Eclipse SDK or Scala-IDE packages and multiple version are often available. It is possible to list available Eclipse packages by issuing the command:
+<screen>
+<prompt>$ </prompt>nix-env -f '&lt;nixpkgs&gt;' -qaP -A eclipses --description
+</screen>
+   Once an Eclipse variant is installed it can be run using the <command>eclipse</command> command, as expected. From within Eclipse it is then possible to install plugins in the usual manner by either manually specifying an Eclipse update site or by installing the Marketplace Client plugin and using it to discover and install other plugins. This installation method provides an Eclipse installation that closely resemble a manually installed Eclipse.
+  </para>
+
+  <para>
+   If you prefer to install plugins in a more declarative manner then Nixpkgs also offer a number of Eclipse plugins that can be installed in an <emphasis>Eclipse environment</emphasis>. This type of environment is created using the function <varname>eclipseWithPlugins</varname> found inside the <varname>nixpkgs.eclipses</varname> attribute set. This function takes as argument <literal>{ eclipse, plugins ? [], jvmArgs ? [] }</literal> where <varname>eclipse</varname> is a one of the Eclipse packages described above, <varname>plugins</varname> is a list of plugin derivations, and <varname>jvmArgs</varname> is a list of arguments given to the JVM running the Eclipse. For example, say you wish to install the latest Eclipse Platform with the popular Eclipse Color Theme plugin and also allow Eclipse to use more RAM. You could then add
+<screen>
+packageOverrides = pkgs: {
+  myEclipse = with pkgs.eclipses; eclipseWithPlugins {
+    eclipse = eclipse-platform;
+    jvmArgs = [ "-Xmx2048m" ];
+    plugins = [ plugins.color-theme ];
+  };
+}
+</screen>
+   to your Nixpkgs configuration (<filename>~/.config/nixpkgs/config.nix</filename>) and install it by running <command>nix-env -f '&lt;nixpkgs&gt;' -iA myEclipse</command> and afterward run Eclipse as usual. It is possible to find out which plugins are available for installation using <varname>eclipseWithPlugins</varname> by running
+<screen>
+<prompt>$ </prompt>nix-env -f '&lt;nixpkgs&gt;' -qaP -A eclipses.plugins --description
+</screen>
+  </para>
+
+  <para>
+   If there is a need to install plugins that are not available in Nixpkgs then it may be possible to define these plugins outside Nixpkgs using the <varname>buildEclipseUpdateSite</varname> and <varname>buildEclipsePlugin</varname> functions found in the <varname>nixpkgs.eclipses.plugins</varname> attribute set. Use the <varname>buildEclipseUpdateSite</varname> function to install a plugin distributed as an Eclipse update site. This function takes <literal>{ name, src }</literal> as argument where <literal>src</literal> indicates the Eclipse update site archive. All Eclipse features and plugins within the downloaded update site will be installed. When an update site archive is not available then the <varname>buildEclipsePlugin</varname> function can be used to install a plugin that consists of a pair of feature and plugin JARs. This function takes an argument <literal>{ name, srcFeature, srcPlugin }</literal> where <literal>srcFeature</literal> and <literal>srcPlugin</literal> are the feature and plugin JARs, respectively.
+  </para>
+
+  <para>
+   Expanding the previous example with two plugins using the above functions we have
+<screen>
+packageOverrides = pkgs: {
+  myEclipse = with pkgs.eclipses; eclipseWithPlugins {
+    eclipse = eclipse-platform;
+    jvmArgs = [ "-Xmx2048m" ];
+    plugins = [
+      plugins.color-theme
+      (plugins.buildEclipsePlugin {
+        name = "myplugin1-1.0";
+        srcFeature = fetchurl {
+          url = "http://…/features/myplugin1.jar";
+          sha256 = "123…";
+        };
+        srcPlugin = fetchurl {
+          url = "http://…/plugins/myplugin1.jar";
+          sha256 = "123…";
+        };
+      });
+      (plugins.buildEclipseUpdateSite {
+        name = "myplugin2-1.0";
+        src = fetchurl {
+          stripRoot = false;
+          url = "http://…/myplugin2.zip";
+          sha256 = "123…";
+        };
+      });
+    ];
+  };
+}
+</screen>
+  </para>
+ </section>
+ <section xml:id="sec-elm">
+  <title>Elm</title>
+
+  <para>
+   To start a development environment do <command>nix-shell -p elmPackages.elm elmPackages.elm-format</command>
+  </para>
+
+  <para>
+   To update Elm compiler, see <filename>nixpkgs/pkgs/development/compilers/elm/README.md</filename>.
+  </para>
+
+  <para>
+   To package Elm applications, <link xlink:href="https://github.com/hercules-ci/elm2nix#elm2nix">read about elm2nix</link>.
+  </para>
+ </section>
+ <section xml:id="sec-kakoune">
+  <title>Kakoune</title>
+
+  <para>
+   Kakoune can be built to autoload plugins:
+<programlisting>(kakoune.override {
+  configure = {
+    plugins = with pkgs.kakounePlugins; [ parinfer-rust ];
+  };
+})</programlisting>
+  </para>
+ </section>
+ <section xml:id="sec-shell-helpers">
+  <title>Interactive shell helpers</title>
+
+  <para>
+   Some packages provide the shell integration to be more useful. But unlike other systems, nix doesn't have a standard share directory location. This is why a bunch <command>PACKAGE-share</command> scripts are shipped that print the location of the corresponding shared folder. Current list of such packages is as following:
+   <itemizedlist>
+    <listitem>
+     <para>
+      <literal>autojump</literal>: <command>autojump-share</command>
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      <literal>fzf</literal>: <command>fzf-share</command>
+     </para>
+    </listitem>
+   </itemizedlist>
+   E.g. <literal>autojump</literal> can then used in the .bashrc like this:
+<screen>
+  source "$(autojump-share)/autojump.bash"
+</screen>
+  </para>
+ </section>
+ <section xml:id="sec-weechat">
+  <title>Weechat</title>
+
+  <para>
+   Weechat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration such as
+<programlisting>weechat.override {configure = {availablePlugins, ...}: {
+    plugins = with availablePlugins; [ python perl ];
+  }
+}</programlisting>
+   If the <literal>configure</literal> function returns an attrset without the <literal>plugins</literal> attribute, <literal>availablePlugins</literal> will be used automatically.
+  </para>
+
+  <para>
+   The plugins currently available are <literal>python</literal>, <literal>perl</literal>, <literal>ruby</literal>, <literal>guile</literal>, <literal>tcl</literal> and <literal>lua</literal>.
+  </para>
+
+  <para>
+   The python and perl plugins allows the addition of extra libraries. For instance, the <literal>inotify.py</literal> script in weechat-scripts requires D-Bus or libnotify, and the <literal>fish.py</literal> script requires pycrypto. To use these scripts, use the plugin's <literal>withPackages</literal> attribute:
+<programlisting>weechat.override { configure = {availablePlugins, ...}: {
+    plugins = with availablePlugins; [
+            (python.withPackages (ps: with ps; [ pycrypto python-dbus ]))
+        ];
+    };
+}
+</programlisting>
+  </para>
+
+  <para>
+   In order to also keep all default plugins installed, it is possible to use the following method:
+<programlisting>weechat.override { configure = { availablePlugins, ... }: {
+  plugins = builtins.attrValues (availablePlugins // {
+    python = availablePlugins.python.withPackages (ps: with ps; [ pycrypto python-dbus ]);
+  });
+}; }
+</programlisting>
+  </para>
+
+  <para>
+   WeeChat allows to set defaults on startup using the <literal>--run-command</literal>. The <literal>configure</literal> method can be used to pass commands to the program:
+<programlisting>weechat.override {
+  configure = { availablePlugins, ... }: {
+    init = ''
+      /set foo bar
+      /server add freenode chat.freenode.org
+    '';
+  };
+}</programlisting>
+   Further values can be added to the list of commands when running <literal>weechat --run-command "your-commands"</literal>.
+  </para>
+
+  <para>
+   Additionally it's possible to specify scripts to be loaded when starting <literal>weechat</literal>. These will be loaded before the commands from <literal>init</literal>:
+<programlisting>weechat.override {
+  configure = { availablePlugins, ... }: {
+    scripts = with pkgs.weechatScripts; [
+      weechat-xmpp weechat-matrix-bridge wee-slack
+    ];
+    init = ''
+      /set plugins.var.python.jabber.key "val"
+    '':
+  };
+}</programlisting>
+  </para>
+
+  <para>
+   In <literal>nixpkgs</literal> there's a subpackage which contains derivations for WeeChat scripts. Such derivations expect a <literal>passthru.scripts</literal> attribute which contains a list of all scripts inside the store path. Furthermore all scripts have to live in <literal>$out/share</literal>. An exemplary derivation looks like this:
+<programlisting>{ stdenv, fetchurl }:
+
+stdenv.mkDerivation {
+  name = "exemplary-weechat-script";
+  src = fetchurl {
+    url = "https://scripts.tld/your-scripts.tar.gz";
+    sha256 = "...";
+  };
+  passthru.scripts = [ "foo.py" "bar.lua" ];
+  installPhase = ''
+    mkdir $out/share
+    cp foo.py $out/share
+    cp bar.lua $out/share
+  '';
+}</programlisting>
+  </para>
+ </section>
+ <section xml:id="sec-ibus-typing-booster">
+  <title>ibus-engines.typing-booster</title>
+
+  <para>
+   This package is an ibus-based completion method to speed up typing.
+  </para>
+
+  <section xml:id="sec-ibus-typing-booster-activate">
+   <title>Activating the engine</title>
+
+   <para>
+    IBus needs to be configured accordingly to activate <literal>typing-booster</literal>. The configuration depends on the desktop manager in use. For detailed instructions, please refer to the <link xlink:href="https://mike-fabian.github.io/ibus-typing-booster/documentation.html">upstream docs</link>.
+   </para>
+
+   <para>
+    On NixOS you need to explicitly enable <literal>ibus</literal> with given engines before customizing your desktop to use <literal>typing-booster</literal>. This can be achieved using the <literal>ibus</literal> module:
+<programlisting>{ pkgs, ... }: {
+  i18n.inputMethod = {
+    enabled = "ibus";
+    ibus.engines = with pkgs.ibus-engines; [ typing-booster ];
+  };
+}</programlisting>
+   </para>
+  </section>
+
+  <section xml:id="sec-ibus-typing-booster-customize-hunspell">
+   <title>Using custom hunspell dictionaries</title>
+
+   <para>
+    The IBus engine is based on <literal>hunspell</literal> to support completion in many languages. By default the dictionaries <literal>de-de</literal>, <literal>en-us</literal>, <literal>fr-moderne</literal> <literal>es-es</literal>, <literal>it-it</literal>, <literal>sv-se</literal> and <literal>sv-fi</literal> are in use. To add another dictionary, the package can be overridden like this:
+<programlisting>ibus-engines.typing-booster.override {
+  langs = [ "de-at" "en-gb" ];
+}</programlisting>
+   </para>
+
+   <para>
+    <emphasis>Note: each language passed to <literal>langs</literal> must be an attribute name in <literal>pkgs.hunspellDicts</literal>.</emphasis>
+   </para>
+  </section>
+
+  <section xml:id="sec-ibus-typing-booster-emoji-picker">
+   <title>Built-in emoji picker</title>
+
+   <para>
+    The <literal>ibus-engines.typing-booster</literal> package contains a program named <literal>emoji-picker</literal>. To display all emojis correctly, a special font such as <literal>noto-fonts-emoji</literal> is needed:
+   </para>
+
+   <para>
+    On NixOS it can be installed using the following expression:
+<programlisting>{ pkgs, ... }: {
+  fonts.fonts = with pkgs; [ noto-fonts-emoji ];
+}</programlisting>
+   </para>
+  </section>
+ </section>
+ <section xml:id="sec-nginx">
+  <title>Nginx</title>
+
+  <para>
+   <link xlink:href="https://nginx.org/">Nginx</link> is a reverse proxy and lightweight webserver.
+  </para>
+
+  <section xml:id="sec-nginx-etag">
+   <title>ETags on static files served from the Nix store</title>
+
+   <para>
+    HTTP has a couple different mechanisms for caching to prevent clients from having to download the same content repeatedly if a resource has not changed since the last time it was requested. When nginx is used as a server for static files, it implements the caching mechanism based on the <link xlink:href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified"><literal>Last-Modified</literal></link> response header automatically; unfortunately, it works by using filesystem timestamps to determine the value of the <literal>Last-Modified</literal> header. This doesn't give the desired behavior when the file is in the Nix store, because all file timestamps are set to 0 (for reasons related to build reproducibility).
+   </para>
+
+   <para>
+    Fortunately, HTTP supports an alternative (and more effective) caching mechanism: the <link xlink:href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag"><literal>ETag</literal></link> response header. The value of the <literal>ETag</literal> header specifies some identifier for the particular content that the server is sending (e.g. a hash). When a client makes a second request for the same resource, it sends that value back in an <literal>If-None-Match</literal> header. If the ETag value is unchanged, then the server does not need to resend the content.
+   </para>
+
+   <para>
+    As of NixOS 19.09, the nginx package in Nixpkgs is patched such that when nginx serves a file out of <filename>/nix/store</filename>, the hash in the store path is used as the <literal>ETag</literal> header in the HTTP response, thus providing proper caching functionality. This happens automatically; you do not need to do modify any configuration to get this behavior.
+   </para>
+  </section>
+ </section>
+</chapter>

doc/package-specific-user-notes.xml

@@ -0,0 +1,357 @@
+<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="package-specific-user-notes">
+ <title>Package-specific usage notes</title>
+ <para>
+  These chapters includes some notes that apply to specific packages and should answer some of the frequently asked questions related to Nixpkgs use. Some useful information related to package use can be found in <link linkend="chap-package-notes">package-specific development notes</link>.
+ </para>
+ <section xml:id="opengl">
+  <title>OpenGL</title>
+
+  <para>
+   Packages that use OpenGL have NixOS desktop as their primary target. The current solution for loading the GPU-specific drivers is based on <literal>libglvnd</literal> and looks for the driver implementation in <literal>LD_LIBRARY_PATH</literal>. If you are using a non-NixOS GNU/Linux/X11 desktop with free software video drivers, consider launching OpenGL-dependent programs from Nixpkgs with Nixpkgs versions of <literal>libglvnd</literal> and <literal>mesa_drivers</literal> in <literal>LD_LIBRARY_PATH</literal>. For proprietary video drivers you might have luck with also adding the corresponding video driver package.
+  </para>
+ </section>
+ <section xml:id="locales">
+  <title>Locales</title>
+
+  <para>
+   To allow simultaneous use of packages linked against different versions of <literal>glibc</literal> with different locale archive formats Nixpkgs patches <literal>glibc</literal> to rely on <literal>LOCALE_ARCHIVE</literal> environment variable.
+  </para>
+
+  <para>
+   On non-NixOS distributions this variable is obviously not set. This can cause regressions in language support or even crashes in some Nixpkgs-provided programs. The simplest way to mitigate this problem is exporting the <literal>LOCALE_ARCHIVE</literal> variable pointing to <literal>${glibcLocales}/lib/locale/locale-archive</literal>. The drawback (and the reason this is not the default) is the relatively large (a hundred MiB) size of the full set of locales. It is possible to build a custom set of locales by overriding parameters <literal>allLocales</literal> and <literal>locales</literal> of the package.
+  </para>
+ </section>
+ <section xml:id="sec-emacs">
+  <title>Emacs</title>
+
+  <section xml:id="sec-emacs-config">
+   <title>Configuring Emacs</title>
+
+   <para>
+    The Emacs package comes with some extra helpers to make it easier to configure. <varname>emacsWithPackages</varname> allows you to manage packages from ELPA. This means that you will not have to install that packages from within Emacs. For instance, if you wanted to use <literal>company</literal>, <literal>counsel</literal>, <literal>flycheck</literal>, <literal>ivy</literal>, <literal>magit</literal>, <literal>projectile</literal>, and <literal>use-package</literal> you could use this as a <filename>~/.config/nixpkgs/config.nix</filename> override:
+   </para>
+
+<screen>
+{
+  packageOverrides = pkgs: with pkgs; {
+    myEmacs = emacsWithPackages (epkgs: (with epkgs.melpaStablePackages; [
+      company
+      counsel
+      flycheck
+      ivy
+      magit
+      projectile
+      use-package
+    ]));
+  }
+}
+</screen>
+
+   <para>
+    You can install it like any other packages via <command>nix-env -iA myEmacs</command>. However, this will only install those packages. It will not <literal>configure</literal> them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provide a <filename>default.el</filename> file in <filename>/share/emacs/site-start/</filename>. Emacs knows to load this file automatically when it starts.
+   </para>
+
+<screen>
+{
+  packageOverrides = pkgs: with pkgs; rec {
+    myEmacsConfig = writeText "default.el" ''
+;; initialize package
+
+(require 'package)
+(package-initialize 'noactivate)
+(eval-when-compile
+  (require 'use-package))
+
+;; load some packages
+
+(use-package company
+  :bind ("&lt;C-tab&gt;" . company-complete)
+  :diminish company-mode
+  :commands (company-mode global-company-mode)
+  :defer 1
+  :config
+  (global-company-mode))
+
+(use-package counsel
+  :commands (counsel-descbinds)
+  :bind (([remap execute-extended-command] . counsel-M-x)
+         ("C-x C-f" . counsel-find-file)
+         ("C-c g" . counsel-git)
+         ("C-c j" . counsel-git-grep)
+         ("C-c k" . counsel-ag)
+         ("C-x l" . counsel-locate)
+         ("M-y" . counsel-yank-pop)))
+
+(use-package flycheck
+  :defer 2
+  :config (global-flycheck-mode))
+
+(use-package ivy
+  :defer 1
+  :bind (("C-c C-r" . ivy-resume)
+         ("C-x C-b" . ivy-switch-buffer)
+         :map ivy-minibuffer-map
+         ("C-j" . ivy-call))
+  :diminish ivy-mode
+  :commands ivy-mode
+  :config
+  (ivy-mode 1))
+
+(use-package magit
+  :defer
+  :if (executable-find "git")
+  :bind (("C-x g" . magit-status)
+         ("C-x G" . magit-dispatch-popup))
+  :init
+  (setq magit-completing-read-function 'ivy-completing-read))
+
+(use-package projectile
+  :commands projectile-mode
+  :bind-keymap ("C-c p" . projectile-command-map)
+  :defer 5
+  :config
+  (projectile-global-mode))
+    '';
+    myEmacs = emacsWithPackages (epkgs: (with epkgs.melpaStablePackages; [
+      (runCommand "default.el" {} ''
+mkdir -p $out/share/emacs/site-lisp
+cp ${myEmacsConfig} $out/share/emacs/site-lisp/default.el
+'')
+      company
+      counsel
+      flycheck
+      ivy
+      magit
+      projectile
+      use-package
+    ]));
+  };
+}
+</screen>
+
+   <para>
+    This provides a fairly full Emacs start file. It will load in addition to the user's presonal config. You can always disable it by passing <command>-q</command> to the Emacs command.
+   </para>
+
+   <para>
+    Sometimes <varname>emacsWithPackages</varname> is not enough, as this package set has some priorities imposed on packages (with the lowest priority assigned to Melpa Unstable, and the highest for packages manually defined in <filename>pkgs/top-level/emacs-packages.nix</filename>). But you can't control this priorities when some package is installed as a dependency. You can override it on per-package-basis, providing all the required dependencies manually - but it's tedious and there is always a possibility that an unwanted dependency will sneak in through some other package. To completely override such a package you can use <varname>overrideScope'</varname>.
+   </para>
+
+<screen>
+overrides = self: super: rec {
+  haskell-mode = self.melpaPackages.haskell-mode;
+  ...
+};
+((emacsPackagesGen emacs).overrideScope' overrides).emacsWithPackages (p: with p; [
+  # here both these package will use haskell-mode of our own choice
+  ghc-mod
+  dante
+])
+</screen>
+  </section>
+ </section>
+ <section xml:id="dlib">
+  <title>DLib</title>
+
+  <para>
+   <link xlink:href="http://dlib.net/">DLib</link> is a modern, C++-based toolkit which provides several machine learning algorithms.
+  </para>
+
+  <section xml:id="compiling-without-avx-support">
+   <title>Compiling without AVX support</title>
+
+   <para>
+    Especially older CPUs don't support <link xlink:href="https://en.wikipedia.org/wiki/Advanced_Vector_Extensions">AVX</link> (<abbrev>Advanced Vector Extensions</abbrev>) instructions that are used by DLib to optimize their algorithms.
+   </para>
+
+   <para>
+    On the affected hardware errors like <literal>Illegal instruction</literal> will occur. In those cases AVX support needs to be disabled:
+<programlisting>self: super: {
+  dlib = super.dlib.override { avxSupport = false; };
+}</programlisting>
+   </para>
+  </section>
+ </section>
+ <section xml:id="unfree-software">
+  <title>Unfree software</title>
+
+  <para>
+   All users of Nixpkgs are free software users, and many users (and developers) of Nixpkgs want to limit and tightly control their exposure to unfree software. At the same time, many users need (or want) to run some specific pieces of proprietary software. Nixpkgs includes some expressions for unfree software packages. By default unfree software cannot be installed and doesn’t show up in searches. To allow installing unfree software in a single Nix invocation one can export <literal>NIXPKGS_ALLOW_UNFREE=1</literal>. For a persistent solution, users can set <literal>allowUnfree</literal> in the Nixpkgs configuration.
+  </para>
+
+  <para>
+   Fine-grained control is possible by defining <literal>allowUnfreePredicate</literal> function in config; it takes the <literal>mkDerivation</literal> parameter attrset and returns <literal>true</literal> for unfree packages that should be allowed.
+  </para>
+ </section>
+ <section xml:id="sec-steam">
+  <title>Steam</title>
+
+  <section xml:id="sec-steam-nix">
+   <title>Steam in Nix</title>
+
+   <para>
+    Steam is distributed as a <filename>.deb</filename> file, for now only as an i686 package (the amd64 package only has documentation). When unpacked, it has a script called <filename>steam</filename> that in Ubuntu (their target distro) would go to <filename>/usr/bin </filename>. When run for the first time, this script copies some files to the user's home, which include another script that is the ultimate responsible for launching the steam binary, which is also in $HOME.
+   </para>
+
+   <para>
+    Nix problems and constraints:
+    <itemizedlist>
+     <listitem>
+      <para>
+       We don't have <filename>/bin/bash</filename> and many scripts point there. Similarly for <filename>/usr/bin/python</filename> .
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       We don't have the dynamic loader in <filename>/lib </filename>.
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       The <filename>steam.sh</filename> script in $HOME can not be patched, as it is checked and rewritten by steam.
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       The steam binary cannot be patched, it's also checked.
+      </para>
+     </listitem>
+    </itemizedlist>
+   </para>
+
+   <para>
+    The current approach to deploy Steam in NixOS is composing a FHS-compatible chroot environment, as documented <link xlink:href="http://sandervanderburg.blogspot.nl/2013/09/composing-fhs-compatible-chroot.html">here</link>. This allows us to have binaries in the expected paths without disrupting the system, and to avoid patching them to work in a non FHS environment.
+   </para>
+  </section>
+
+  <section xml:id="sec-steam-play">
+   <title>How to play</title>
+
+   <para>
+    For 64-bit systems it's important to have
+<programlisting>hardware.opengl.driSupport32Bit = true;</programlisting>
+    in your <filename>/etc/nixos/configuration.nix</filename>. You'll also need
+<programlisting>hardware.pulseaudio.support32Bit = true;</programlisting>
+    if you are using PulseAudio - this will enable 32bit ALSA apps integration. To use the Steam controller or other Steam supported controllers such as the DualShock 4 or Nintendo Switch Pro, you need to add
+<programlisting>hardware.steam-hardware.enable = true;</programlisting>
+    to your configuration.
+   </para>
+  </section>
+
+  <section xml:id="sec-steam-troub">
+   <title>Troubleshooting</title>
+
+   <para>
+    <variablelist>
+     <varlistentry>
+      <term>
+       Steam fails to start. What do I do?
+      </term>
+      <listitem>
+       <para>
+        Try to run
+<programlisting>strace steam</programlisting>
+        to see what is causing steam to fail.
+       </para>
+      </listitem>
+     </varlistentry>
+     <varlistentry>
+      <term>
+       Using the FOSS Radeon or nouveau (nvidia) drivers
+      </term>
+      <listitem>
+       <itemizedlist>
+        <listitem>
+         <para>
+          The <literal>newStdcpp</literal> parameter was removed since NixOS 17.09 and should not be needed anymore.
+         </para>
+        </listitem>
+        <listitem>
+         <para>
+          Steam ships statically linked with a version of libcrypto that conflics with the one dynamically loaded by radeonsi_dri.so. If you get the error
+<programlisting>steam.sh: line 713: 7842 Segmentation fault (core dumped)</programlisting>
+          have a look at <link xlink:href="https://github.com/NixOS/nixpkgs/pull/20269">this pull request</link>.
+         </para>
+        </listitem>
+       </itemizedlist>
+      </listitem>
+     </varlistentry>
+     <varlistentry>
+      <term>
+       Java
+      </term>
+      <listitem>
+       <orderedlist>
+        <listitem>
+         <para>
+          There is no java in steam chrootenv by default. If you get a message like
+<programlisting>/home/foo/.local/share/Steam/SteamApps/common/towns/towns.sh: line 1: java: command not found</programlisting>
+          You need to add
+<programlisting> steam.override { withJava = true; };</programlisting>
+          to your configuration.
+         </para>
+        </listitem>
+       </orderedlist>
+      </listitem>
+     </varlistentry>
+    </variablelist>
+   </para>
+  </section>
+
+  <section xml:id="sec-steam-run">
+   <title>steam-run</title>
+
+   <para>
+    The FHS-compatible chroot used for steam can also be used to run other linux games that expect a FHS environment. To do it, add
+<programlisting>pkgs.(steam.override {
+          nativeOnly = true;
+          newStdcpp = true;
+        }).run</programlisting>
+    to your configuration, rebuild, and run the game with
+<programlisting>steam-run ./foo</programlisting>
+   </para>
+  </section>
+ </section>
+ <section xml:id="sec-citrix">
+  <title>Citrix Receiver &amp; Citrix Workspace App</title>
+
+  <para>
+   <note>
+    <para>
+     Please note that the <literal>citrix_receiver</literal> package has been deprecated since its development was <link xlink:href="https://docs.citrix.com/en-us/citrix-workspace-app.html">discontinued by upstream</link> and has been replaced by <link xlink:href="https://www.citrix.com/products/workspace-app/">the citrix workspace app</link>.
+    </para>
+   </note>
+   <link xlink:href="https://www.citrix.com/products/receiver/">Citrix Receiver</link> and <link xlink:href="https://www.citrix.com/products/workspace-app/">Citrix Workspace App</link> are a remote desktop viewers which provide 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 license agreements of the vendor for <link xlink:href="https://www.citrix.com/downloads/citrix-receiver/">Citrix Receiver</link> or <link xlink:href="https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html">Citrix Workspace</link> need to be accepted first. Then run <command>nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz</command>. With the archive available in the store the package can be built and installed with Nix.
+   </para>
+
+   <warning>
+    <title>Caution with <command>nix-shell</command> installs</title>
+    <para>
+     It's recommended to install <literal>Citrix Receiver</literal> and/or <literal>Citrix Workspace</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.
+    </para>
+   </warning>
+  </section>
+
+  <section xml:id="sec-citrix-custom-certs">
+   <title>Custom certificates</title>
+
+   <para>
+    The <literal>Citrix Workspace App</literal> in <literal>nixpkgs</literal> trust 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>:
+<programlisting>
+<![CDATA[with import <nixpkgs> { config.allowUnfree = true; };
+let extraCerts = [ ./custom-cert-1.pem ./custom-cert-2.pem /* ... */ ]; in
+citrix_workspace.override {
+  inherit extraCerts;
+}]]>
+</programlisting>
+   </para>
+  </section>
+ </section>
+</chapter>

doc/platform-notes.xml

@@ -1,6 +1,6 @@
 <chapter xmlns="http://docbook.org/ns/docbook"
          xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="chap-platform-notes">
+         xml:id="chap-platform-nodes">
  <title>Platform Notes</title>
  <section xml:id="sec-darwin">
   <title>Darwin (macOS)</title>

doc/preface.chapter.md

@@ -1,52 +0,0 @@
----
-title: Preface
-author: Frederik Rietdijk
-date: 2015-11-25
----
-
-# Preface
-
-The Nix Packages collection (Nixpkgs) is a set of thousands of packages for the
-[Nix package manager](https://nixos.org/nix/), released under a
-[permissive MIT/X11 license](https://github.com/NixOS/nixpkgs/blob/master/COPYING).
-Packages are available for several platforms, and can be used with the Nix
-package manager on most GNU/Linux distributions as well as [NixOS](https://nixos.org/nixos).
-
-This manual primarily describes how to write packages for the Nix Packages collection
-(Nixpkgs). Thus it’s mainly for packagers and developers who want to add packages to
-Nixpkgs. If you like to learn more about the Nix package manager and the Nix
-expression language, then you are kindly referred to the [Nix manual](https://nixos.org/nix/manual/).
-The NixOS distribution is documented in the [NixOS manual](https://nixos.org/nixos/manual/).
-
-## Overview of Nixpkgs
-
-Nix expressions describe how to build packages from source and are collected in
-the [nixpkgs repository](https://github.com/NixOS/nixpkgs). Also included in the
-collection are Nix expressions for
-[NixOS modules](https://nixos.org/nixos/manual/index.html#sec-writing-modules).
-With these expressions the Nix package manager can build binary packages.
-
-Packages, including the Nix packages collection, are distributed through
-[channels](https://nixos.org/nix/manual/#sec-channels). The collection is
-distributed for users of Nix on non-NixOS distributions through the channel
-`nixpkgs`. Users of NixOS generally use one of the `nixos-*` channels, e.g.
-`nixos-19.09`, which includes all packages and modules for the stable NixOS
-19.09. Stable NixOS releases are generally only given
-security updates. More up to date packages and modules are available via the
-`nixos-unstable` channel.
-
-Both `nixos-unstable` and `nixpkgs` follow the `master` branch of the Nixpkgs
-repository, although both do lag the `master` branch by generally
-[a couple of days](https://status.nixos.org/). Updates to a channel are
-distributed as soon as all tests for that channel pass, e.g.
-[this table](https://hydra.nixos.org/job/nixpkgs/trunk/unstable#tabs-constituents)
-shows the status of tests for the `nixpkgs` channel.
-
-The tests are conducted by a cluster called [Hydra](https://nixos.org/hydra/),
-which also builds binary packages from the Nix expressions in Nixpkgs for
-`x86_64-linux`, `i686-linux` and `x86_64-darwin`.
-The binaries are made available via a [binary cache](https://cache.nixos.org).
-
-The current Nix expressions of the channels are available in the
-[`nixpkgs`](https://github.com/NixOS/nixpkgs) repository in branches
-that correspond to the channel names (e.g. `nixos-19.09-small`).

doc/quick-start.xml

@@ -69,7 +69,8 @@
       <listitem>
        <para>
         JDiskReport, a Java utility: <link
-          xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/misc/jdiskreport/default.nix"><filename>pkgs/tools/misc/jdiskreport/default.nix</filename></link>. Nixpkgs doesn’t have a decent <varname>stdenv</varname> for Java yet so this is pretty ad-hoc.
+          xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/misc/jdiskreport/default.nix"><filename>pkgs/tools/misc/jdiskreport/default.nix</filename></link> (and the <link
+          xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/misc/jdiskreport/builder.sh">builder</link>). Nixpkgs doesn’t have a decent <varname>stdenv</varname> for Java yet so this is pretty ad-hoc.
        </para>
       </listitem>
       <listitem>
@@ -111,7 +112,7 @@
     </para>
     <para>
      The exact syntax and semantics of the Nix expression language, including the built-in function, are described in the Nix manual in the <link
-    xlink:href="https://hydra.nixos.org/job/nix/trunk/tarball/latest/download-by-type/doc/manual/#chap-writing-nix-expressions">chapter on writing Nix expressions</link>.
+    xlink:href="http://hydra.nixos.org/job/nix/trunk/tarball/latest/download-by-type/doc/manual/#chap-writing-nix-expressions">chapter on writing Nix expressions</link>.
     </para>
    </listitem>
    <listitem>

doc/release-notes.xml

@@ -190,7 +190,7 @@ preConfigure = "configureFlagsArray=(\"CFLAGS=-O0 -g\")";</programlisting>
       The function <function>fetchurl</function> now has support for two different kinds of mirroring of files. First, it has support for <emphasis>content-addressable mirrors</emphasis>. For example, given the <function>fetchurl</function> call
 <programlisting>
 fetchurl {
-  url = "http://releases.mozilla.org/<replaceable>...</replaceable>/firefox-2.0.0.6-source.tar.bz2";
+  url = http://releases.mozilla.org/<replaceable>...</replaceable>/firefox-2.0.0.6-source.tar.bz2;
   sha1 = "eb72f55e4a8bf08e8c6ef227c0ade3d068ba1082";
 }</programlisting>
       <function>fetchurl</function> will first try to download this file from <link
@@ -286,7 +286,7 @@ export NIX_MIRRORS_sourceforge=http://osdn.dl.sourceforge.net/sourceforge/</prog
   <note>
    <para>
     This release of Nixpkgs requires <link
-xlink:href='https://nixos.org/releases/nix/nix-0.10/'>Nix 0.10</link> or higher.
+xlink:href='http://nixos.org/releases/nix/nix-0.10/'>Nix 0.10</link> or higher.
    </para>
   </note>
 
@@ -436,7 +436,7 @@ stdenv.mkDerivation {
    <listitem>
     <para>
      Distribution files have been moved to <link
-  xlink:href="https://nixos.org/" />.
+  xlink:href="http://nixos.org/" />.
     </para>
    </listitem>
    <listitem>

doc/reviewing-contributions.xml

@@ -2,7 +2,7 @@
         xmlns:xlink="http://www.w3.org/1999/xlink"
         xmlns:xi="http://www.w3.org/2001/XInclude"
         version="5.0"
-        xml:id="chap-reviewing-contributions">
+        xml:id="sec-reviewing-contributions">
  <title>Reviewing contributions</title>
  <warning>
   <para>
@@ -115,12 +115,19 @@
       <para>
        It is possible to rebase the changes on nixos-unstable or nixpkgs-unstable for easier review by running the following commands from a nixpkgs clone.
 <screen>
-<prompt>$ </prompt>git fetch origin nixos-unstable <co xml:id='reviewing-rebase-2' />
+<prompt>$ </prompt>git remote add channels https://github.com/NixOS/nixpkgs-channels.git <co
+  xml:id='reviewing-rebase-1' />
+<prompt>$ </prompt>git fetch channels nixos-unstable <co xml:id='reviewing-rebase-2' />
 <prompt>$ </prompt>git fetch origin pull/PRNUMBER/head <co xml:id='reviewing-rebase-3' />
 <prompt>$ </prompt>git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD <co
   xml:id='reviewing-rebase-4' />
 </screen>
        <calloutlist>
+        <callout arearefs='reviewing-rebase-1'>
+         <para>
+          This should be done only once to be able to fetch channel branches from the nixpkgs-channels repository.
+         </para>
+        </callout>
         <callout arearefs='reviewing-rebase-2'>
          <para>
           Fetching the nixos-unstable branch.
@@ -141,10 +148,10 @@
      </listitem>
      <listitem>
       <para>
-       The <link xlink:href="https://github.com/Mic92/nixpkgs-review">nixpkgs-review</link> tool can be used to review a pull request content in a single command. <varname>PRNUMBER</varname> should be replaced by the number at the end of the pull request title. You can also provide the full github pull request url.
+       The <link xlink:href="https://github.com/Mic92/nix-review">nix-review</link> tool can be used to review a pull request content in a single command. <varname>PRNUMBER</varname> should be replaced by the number at the end of the pull request title. You can also provide the full github pull request url.
       </para>
 <screen>
-<prompt>$ </prompt>nix-shell -p nixpkgs-review --run "nixpkgs-review pr PRNUMBER"
+<prompt>$ </prompt>nix-shell -p nix-review --run "nix-review pr PRNUMBER"
 </screen>
      </listitem>
     </itemizedlist>

doc/stdenv.xml

@@ -14,7 +14,7 @@
 stdenv.mkDerivation {
   name = "libfoo-1.2.3";
   src = fetchurl {
-    url = "http://example.org/libfoo-1.2.3.tar.bz2";
+    url = http://example.org/libfoo-1.2.3.tar.bz2;
     sha256 = "0x2g1jqygyr5wiwg4ma1nd7w4ydpy82z9gkcv8vh2v8dn3y58v5m";
   };
 }</programlisting>
@@ -145,7 +145,7 @@ genericBuild
     </listitem>
     <listitem>
      <para>
-      GNU Make.
+      GNU Make. It has been patched to provide <quote>nested</quote> output that can be fed into the <command>nix-log2xml</command> command and <command>log2html</command> stylesheet to create a structured, readable output of the build steps performed by Make.
      </para>
     </listitem>
     <listitem>
@@ -254,7 +254,7 @@ let f(h, h + 1, i) = i + h
 
   <variablelist>
    <title>Variables specifying dependencies</title>
-   <varlistentry xml:id="var-stdenv-depsBuildBuild">
+   <varlistentry>
     <term>
      <varname>depsBuildBuild</varname>
     </term>
@@ -267,7 +267,7 @@ let f(h, h + 1, i) = i + h
      </para>
     </listitem>
    </varlistentry>
-   <varlistentry xml:id="var-stdenv-nativeBuildInputs">
+   <varlistentry>
     <term>
      <varname>nativeBuildInputs</varname>
     </term>
@@ -280,7 +280,7 @@ let f(h, h + 1, i) = i + h
      </para>
     </listitem>
    </varlistentry>
-   <varlistentry xml:id="var-stdenv-depsBuildTarget">
+   <varlistentry>
     <term>
      <varname>depsBuildTarget</varname>
     </term>
@@ -296,7 +296,7 @@ let f(h, h + 1, i) = i + h
      </para>
     </listitem>
    </varlistentry>
-   <varlistentry xml:id="var-stdenv-depsHostHost">
+   <varlistentry>
     <term>
      <varname>depsHostHost</varname>
     </term>
@@ -306,7 +306,7 @@ let f(h, h + 1, i) = i + h
      </para>
     </listitem>
    </varlistentry>
-   <varlistentry xml:id="var-stdenv-buildInputs">
+   <varlistentry>
     <term>
      <varname>buildInputs</varname>
     </term>
@@ -319,7 +319,7 @@ let f(h, h + 1, i) = i + h
      </para>
     </listitem>
    </varlistentry>
-   <varlistentry xml:id="var-stdenv-depsTargetTarget">
+   <varlistentry>
     <term>
      <varname>depsTargetTarget</varname>
     </term>
@@ -329,7 +329,7 @@ let f(h, h + 1, i) = i + h
      </para>
     </listitem>
    </varlistentry>
-   <varlistentry xml:id="var-stdenv-depsBuildBuildPropagated">
+   <varlistentry>
     <term>
      <varname>depsBuildBuildPropagated</varname>
     </term>
@@ -339,7 +339,7 @@ let f(h, h + 1, i) = i + h
      </para>
     </listitem>
    </varlistentry>
-   <varlistentry xml:id="var-stdenv-propagatedNativeBuildInputs">
+   <varlistentry>
     <term>
      <varname>propagatedNativeBuildInputs</varname>
     </term>
@@ -349,7 +349,7 @@ let f(h, h + 1, i) = i + h
      </para>
     </listitem>
    </varlistentry>
-   <varlistentry xml:id="var-stdenv-depsBuildTargetPropagated">
+   <varlistentry>
     <term>
      <varname>depsBuildTargetPropagated</varname>
     </term>
@@ -359,7 +359,7 @@ let f(h, h + 1, i) = i + h
      </para>
     </listitem>
    </varlistentry>
-   <varlistentry xml:id="var-stdenv-depsHostHostPropagated">
+   <varlistentry>
     <term>
      <varname>depsHostHostPropagated</varname>
     </term>
@@ -369,7 +369,7 @@ let f(h, h + 1, i) = i + h
      </para>
     </listitem>
    </varlistentry>
-   <varlistentry xml:id="var-stdenv-propagatedBuildInputs">
+   <varlistentry>
     <term>
      <varname>propagatedBuildInputs</varname>
     </term>
@@ -379,7 +379,7 @@ let f(h, h + 1, i) = i + h
      </para>
     </listitem>
    </varlistentry>
-   <varlistentry xml:id="var-stdenv-depsTargetTargetPropagated">
+   <varlistentry>
     <term>
      <varname>depsTargetTargetPropagated</varname>
     </term>
@@ -396,7 +396,7 @@ let f(h, h + 1, i) = i + h
 
   <variablelist>
    <title>Variables affecting <literal>stdenv</literal> initialisation</title>
-   <varlistentry xml:id="var-stdenv-NIX_DEBUG">
+   <varlistentry>
     <term>
      <varname>NIX_DEBUG</varname>
     </term>
@@ -410,7 +410,7 @@ let f(h, h + 1, i) = i + h
 
   <variablelist>
    <title>Attributes affecting build properties</title>
-   <varlistentry xml:id="var-stdenv-enableParallelBuilding">
+   <varlistentry>
     <term>
      <varname>enableParallelBuilding</varname>
     </term>
@@ -427,7 +427,7 @@ let f(h, h + 1, i) = i + h
 
   <variablelist>
    <title>Special variables</title>
-   <varlistentry xml:id="var-stdenv-passthru">
+   <varlistentry>
     <term>
      <varname>passthru</varname>
     </term>
@@ -504,7 +504,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
     There are a number of variables that control what phases are executed and in what order:
     <variablelist>
      <title>Variables affecting phase control</title>
-     <varlistentry xml:id="var-stdenv-phases">
+     <varlistentry>
       <term>
        <varname>phases</varname>
       </term>
@@ -517,7 +517,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
        </para>
       </listitem>
      </varlistentry>
-     <varlistentry xml:id="var-stdenv-prePhases">
+     <varlistentry>
       <term>
        <varname>prePhases</varname>
       </term>
@@ -527,7 +527,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
        </para>
       </listitem>
      </varlistentry>
-     <varlistentry xml:id="var-stdenv-preConfigurePhases">
+     <varlistentry>
       <term>
        <varname>preConfigurePhases</varname>
       </term>
@@ -537,7 +537,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
        </para>
       </listitem>
      </varlistentry>
-     <varlistentry xml:id="var-stdenv-preBuildPhases">
+     <varlistentry>
       <term>
        <varname>preBuildPhases</varname>
       </term>
@@ -547,7 +547,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
        </para>
       </listitem>
      </varlistentry>
-     <varlistentry xml:id="var-stdenv-preInstallPhases">
+     <varlistentry>
       <term>
        <varname>preInstallPhases</varname>
       </term>
@@ -557,7 +557,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
        </para>
       </listitem>
      </varlistentry>
-     <varlistentry xml:id="var-stdenv-preFixupPhases">
+     <varlistentry>
       <term>
        <varname>preFixupPhases</varname>
       </term>
@@ -567,7 +567,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
        </para>
       </listitem>
      </varlistentry>
-     <varlistentry xml:id="var-stdenv-preDistPhases">
+     <varlistentry>
       <term>
        <varname>preDistPhases</varname>
       </term>
@@ -577,7 +577,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
        </para>
       </listitem>
      </varlistentry>
-     <varlistentry xml:id="var-stdenv-postPhases">
+     <varlistentry>
       <term>
        <varname>postPhases</varname>
       </term>
@@ -635,7 +635,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
 
    <variablelist>
     <title>Variables controlling the unpack phase</title>
-    <varlistentry xml:id="var-stdenv-src">
+    <varlistentry>
      <term>
       <varname>srcs</varname> / <varname>src</varname>
      </term>
@@ -645,7 +645,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-sourceRoot">
+    <varlistentry>
      <term>
       <varname>sourceRoot</varname>
      </term>
@@ -655,7 +655,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-setSourceRoot">
+    <varlistentry>
      <term>
       <varname>setSourceRoot</varname>
      </term>
@@ -665,7 +665,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-preUnpack">
+    <varlistentry>
      <term>
       <varname>preUnpack</varname>
      </term>
@@ -675,7 +675,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-postUnpack">
+    <varlistentry>
      <term>
       <varname>postUnpack</varname>
      </term>
@@ -685,7 +685,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontUnpack">
+    <varlistentry>
      <term>
       <varname>dontUnpack</varname>
      </term>
@@ -695,7 +695,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontMakeSourcesWritable">
+    <varlistentry>
      <term>
       <varname>dontMakeSourcesWritable</varname>
      </term>
@@ -705,7 +705,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-unpackCmd">
+    <varlistentry>
      <term>
       <varname>unpackCmd</varname>
      </term>
@@ -727,17 +727,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
 
    <variablelist>
     <title>Variables controlling the patch phase</title>
-    <varlistentry xml:id="var-stdenv-dontPatch">
-     <term>
-      <varname>dontPatch</varname>
-     </term>
-     <listitem>
-      <para>
-       Set to true to skip the patch phase.
-      </para>
-     </listitem>
-    </varlistentry>
-    <varlistentry xml:id="var-stdenv-patches">
+    <varlistentry>
      <term>
       <varname>patches</varname>
      </term>
@@ -747,7 +737,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-patchFlags">
+    <varlistentry>
      <term>
       <varname>patchFlags</varname>
      </term>
@@ -757,7 +747,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-prePatch">
+    <varlistentry>
      <term>
       <varname>prePatch</varname>
      </term>
@@ -767,7 +757,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-postPatch">
+    <varlistentry>
      <term>
       <varname>postPatch</varname>
      </term>
@@ -789,7 +779,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
 
    <variablelist>
     <title>Variables controlling the configure phase</title>
-    <varlistentry xml:id="var-stdenv-configureScript">
+    <varlistentry>
      <term>
       <varname>configureScript</varname>
      </term>
@@ -799,7 +789,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-configureFlags">
+    <varlistentry>
      <term>
       <varname>configureFlags</varname>
      </term>
@@ -809,7 +799,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontConfigure">
+    <varlistentry>
      <term>
       <varname>dontConfigure</varname>
      </term>
@@ -819,7 +809,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-configureFlagsArray">
+    <varlistentry>
      <term>
       <varname>configureFlagsArray</varname>
      </term>
@@ -829,7 +819,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontAddPrefix">
+    <varlistentry>
      <term>
       <varname>dontAddPrefix</varname>
      </term>
@@ -839,7 +829,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-prefix">
+    <varlistentry>
      <term>
       <varname>prefix</varname>
      </term>
@@ -849,7 +839,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-prefixKey">
+    <varlistentry>
      <term>
       <varname>prefixKey</varname>
      </term>
@@ -859,7 +849,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontAddDisableDepTrack">
+    <varlistentry>
      <term>
       <varname>dontAddDisableDepTrack</varname>
      </term>
@@ -869,7 +859,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontFixLibtool">
+    <varlistentry>
      <term>
       <varname>dontFixLibtool</varname>
      </term>
@@ -885,7 +875,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontDisableStatic">
+    <varlistentry>
      <term>
       <varname>dontDisableStatic</varname>
      </term>
@@ -898,7 +888,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-configurePlatforms">
+    <varlistentry>
      <term>
       <varname>configurePlatforms</varname>
      </term>
@@ -913,7 +903,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-preConfigure">
+    <varlistentry>
      <term>
       <varname>preConfigure</varname>
      </term>
@@ -923,7 +913,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-postConfigure">
+    <varlistentry>
      <term>
       <varname>postConfigure</varname>
      </term>
@@ -945,7 +935,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
 
    <variablelist>
     <title>Variables controlling the build phase</title>
-    <varlistentry xml:id="var-stdenv-dontBuild">
+    <varlistentry>
      <term>
       <varname>dontBuild</varname>
      </term>
@@ -955,7 +945,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-makefile">
+    <varlistentry>
      <term>
       <varname>makefile</varname>
      </term>
@@ -965,7 +955,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ]
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-makeFlags">
+    <varlistentry>
      <term>
       <varname>makeFlags</varname>
      </term>
@@ -983,7 +973,7 @@ makeFlags = [ "PREFIX=$(out)" ];
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-makeFlagsArray">
+    <varlistentry>
      <term>
       <varname>makeFlagsArray</varname>
      </term>
@@ -999,7 +989,7 @@ preBuild = ''
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-buildFlags">
+    <varlistentry>
      <term>
       <varname>buildFlags</varname> / <varname>buildFlagsArray</varname>
      </term>
@@ -1009,7 +999,7 @@ preBuild = ''
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-preBuild">
+    <varlistentry>
      <term>
       <varname>preBuild</varname>
      </term>
@@ -1019,7 +1009,7 @@ preBuild = ''
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-postBuild">
+    <varlistentry>
      <term>
       <varname>postBuild</varname>
      </term>
@@ -1049,7 +1039,7 @@ preBuild = ''
 
    <variablelist>
     <title>Variables controlling the check phase</title>
-    <varlistentry xml:id="var-stdenv-doCheck">
+    <varlistentry>
      <term>
       <varname>doCheck</varname>
      </term>
@@ -1067,11 +1057,11 @@ preBuild = ''
      </term>
      <listitem>
       <para>
-       See the <link xlink:href="#var-stdenv-makeFlags">build phase</link> for details.
+       See the build phase for details.
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-checkTarget">
+    <varlistentry>
      <term>
       <varname>checkTarget</varname>
      </term>
@@ -1081,7 +1071,7 @@ preBuild = ''
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-checkFlags">
+    <varlistentry>
      <term>
       <varname>checkFlags</varname> / <varname>checkFlagsArray</varname>
      </term>
@@ -1091,7 +1081,7 @@ preBuild = ''
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-checkInputs">
+    <varlistentry>
      <term>
       <varname>checkInputs</varname>
      </term>
@@ -1101,7 +1091,7 @@ preBuild = ''
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-preCheck">
+    <varlistentry>
      <term>
       <varname>preCheck</varname>
      </term>
@@ -1111,7 +1101,7 @@ preBuild = ''
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-postCheck">
+    <varlistentry>
      <term>
       <varname>postCheck</varname>
      </term>
@@ -1133,27 +1123,17 @@ preBuild = ''
 
    <variablelist>
     <title>Variables controlling the install phase</title>
-     <varlistentry xml:id="var-stdenv-dontInstall">
-     <term>
-       <varname>dontInstall</varname>
-     </term>
-     <listitem>
-      <para>
-       Set to true to skip the install phase.
-      </para>
-     </listitem>
-    </varlistentry>
     <varlistentry>
      <term>
       <varname>makeFlags</varname> / <varname>makeFlagsArray</varname> / <varname>makefile</varname>
      </term>
      <listitem>
       <para>
-       See the <link xlink:href="#var-stdenv-makeFlags">build phase</link> for details.
+       See the build phase for details.
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-installTargets">
+    <varlistentry>
      <term>
       <varname>installTargets</varname>
      </term>
@@ -1165,7 +1145,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-installFlags">
+    <varlistentry>
      <term>
       <varname>installFlags</varname> / <varname>installFlagsArray</varname>
      </term>
@@ -1175,7 +1155,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-preInstall">
+    <varlistentry>
      <term>
       <varname>preInstall</varname>
      </term>
@@ -1185,7 +1165,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-postInstall">
+    <varlistentry>
      <term>
       <varname>postInstall</varname>
      </term>
@@ -1229,7 +1209,7 @@ installTargets = "install-bin install-doc";</programlisting>
 
    <variablelist>
     <title>Variables controlling the fixup phase</title>
-    <varlistentry xml:id="var-stdenv-dontFixup">
+    <varlistentry>
      <term>
       <varname>dontFixup</varname>
      </term>
@@ -1239,7 +1219,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontStrip">
+    <varlistentry>
      <term>
       <varname>dontStrip</varname>
      </term>
@@ -1249,7 +1229,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontStripHost">
+    <varlistentry>
      <term>
       <varname>dontStripHost</varname>
      </term>
@@ -1259,7 +1239,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontStripTarget">
+    <varlistentry>
      <term>
       <varname>dontStripTarget</varname>
      </term>
@@ -1269,7 +1249,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontMoveSbin">
+    <varlistentry>
      <term>
       <varname>dontMoveSbin</varname>
      </term>
@@ -1279,7 +1259,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-stripAllList">
+    <varlistentry>
      <term>
       <varname>stripAllList</varname>
      </term>
@@ -1289,7 +1269,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-stripAllFlags">
+    <varlistentry>
      <term>
       <varname>stripAllFlags</varname>
      </term>
@@ -1299,17 +1279,17 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-stripDebugList">
+    <varlistentry>
      <term>
       <varname>stripDebugList</varname>
      </term>
      <listitem>
       <para>
-       List of directories to search for libraries and executables from which only debugging-related symbols should be stripped. It defaults to <literal>lib lib32 lib64 libexec bin sbin</literal>.
+       List of directories to search for libraries and executables from which only debugging-related symbols should be stripped. It defaults to <literal>lib bin sbin</literal>.
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-stripDebugFlags">
+    <varlistentry>
      <term>
       <varname>stripDebugFlags</varname>
      </term>
@@ -1319,7 +1299,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontPatchELF">
+    <varlistentry>
      <term>
       <varname>dontPatchELF</varname>
      </term>
@@ -1329,7 +1309,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontPatchShebangs">
+    <varlistentry>
      <term>
       <varname>dontPatchShebangs</varname>
      </term>
@@ -1339,7 +1319,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontPruneLibtoolFiles">
+    <varlistentry>
      <term>
       <varname>dontPruneLibtoolFiles</varname>
      </term>
@@ -1349,7 +1329,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-forceShare">
+    <varlistentry>
      <term>
       <varname>forceShare</varname>
      </term>
@@ -1359,7 +1339,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-setupHook">
+    <varlistentry>
      <term>
       <varname>setupHook</varname>
      </term>
@@ -1370,7 +1350,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-preFixup">
+    <varlistentry>
      <term>
       <varname>preFixup</varname>
      </term>
@@ -1380,7 +1360,7 @@ installTargets = "install-bin install-doc";</programlisting>
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-postFixup">
+    <varlistentry>
      <term>
       <varname>postFixup</varname>
      </term>
@@ -1419,7 +1399,7 @@ set debug-file-directory ~/.nix-profile/lib/debug
 
    <variablelist>
     <title>Variables controlling the installCheck phase</title>
-    <varlistentry xml:id="var-stdenv-doInstallCheck">
+    <varlistentry>
      <term>
       <varname>doInstallCheck</varname>
      </term>
@@ -1431,7 +1411,7 @@ set debug-file-directory ~/.nix-profile/lib/debug
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-installCheckTarget">
+    <varlistentry>
      <term>
       <varname>installCheckTarget</varname>
      </term>
@@ -1441,7 +1421,7 @@ set debug-file-directory ~/.nix-profile/lib/debug
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-installCheckFlags">
+    <varlistentry>
      <term>
       <varname>installCheckFlags</varname> / <varname>installCheckFlagsArray</varname>
      </term>
@@ -1451,7 +1431,7 @@ set debug-file-directory ~/.nix-profile/lib/debug
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-installCheckInputs">
+    <varlistentry>
      <term>
       <varname>installCheckInputs</varname>
      </term>
@@ -1461,7 +1441,7 @@ set debug-file-directory ~/.nix-profile/lib/debug
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-preInstallCheck">
+    <varlistentry>
      <term>
       <varname>preInstallCheck</varname>
      </term>
@@ -1471,7 +1451,7 @@ set debug-file-directory ~/.nix-profile/lib/debug
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-postInstallCheck">
+    <varlistentry>
      <term>
       <varname>postInstallCheck</varname>
      </term>
@@ -1493,7 +1473,7 @@ set debug-file-directory ~/.nix-profile/lib/debug
 
    <variablelist>
     <title>Variables controlling the distribution phase</title>
-    <varlistentry xml:id="var-stdenv-distTarget">
+    <varlistentry>
      <term>
       <varname>distTarget</varname>
      </term>
@@ -1503,7 +1483,7 @@ set debug-file-directory ~/.nix-profile/lib/debug
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-distFlags">
+    <varlistentry>
      <term>
       <varname>distFlags</varname> / <varname>distFlagsArray</varname>
      </term>
@@ -1513,7 +1493,7 @@ set debug-file-directory ~/.nix-profile/lib/debug
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-tarballs">
+    <varlistentry>
      <term>
       <varname>tarballs</varname>
      </term>
@@ -1523,7 +1503,7 @@ set debug-file-directory ~/.nix-profile/lib/debug
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-dontCopyDist">
+    <varlistentry>
      <term>
       <varname>dontCopyDist</varname>
      </term>
@@ -1533,7 +1513,7 @@ set debug-file-directory ~/.nix-profile/lib/debug
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-preDist">
+    <varlistentry>
      <term>
       <varname>preDist</varname>
      </term>
@@ -1543,7 +1523,7 @@ set debug-file-directory ~/.nix-profile/lib/debug
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="var-stdenv-postDist">
+    <varlistentry>
      <term>
       <varname>postDist</varname>
      </term>
@@ -1712,7 +1692,7 @@ someVar=$(stripHash $name)
     </term>
     <listitem>
      <para>
-      Convenience function for <literal>makeWrapper</literal> that automatically creates a sane wrapper file. It takes all the same arguments as <literal>makeWrapper</literal>, except for <literal>--argv0</literal>.
+      Convenience function for <literal>makeWrapper</literal> that automatically creates a sane wrapper file It takes all the same arguments as <literal>makeWrapper</literal>, except for <literal>--argv0</literal>.
      </para>
      <para>
       It cannot be applied multiple times, since it will overwrite the wrapper file.
@@ -1737,7 +1717,7 @@ someVar=$(stripHash $name)
   </para>
 
   <para>
-   The most typical use of the setup hook is actually to add other hooks which are then run (i.e. after all the setup hooks) on each dependency. For example, the C compiler wrapper's setup hook feeds itself flags for each dependency that contains relevant libraries and headers. This is done by defining a bash function, and appending its name to one of <envar>envBuildBuildHooks</envar>, <envar>envBuildHostHooks</envar>, <envar>envBuildTargetHooks</envar>, <envar>envHostHostHooks</envar>, <envar>envHostTargetHooks</envar>, or <envar>envTargetTargetHooks</envar>. These 6 bash variables correspond to the 6 sorts of dependencies by platform (there's 12 total but we ignore the propagated/non-propagated axis).
+   The most typical use of the setup hook is actually to add other hooks which are then run (i.e. after all the setup hooks) on each dependency. For example, the C compiler wrapper's setup hook feeds itself flags for each dependency that contains relevant libraries and headers. This is done by defining a bash function, and appending its name to one of <envar>envBuildBuildHooks</envar>`, <envar>envBuildHostHooks</envar>`, <envar>envBuildTargetHooks</envar>`, <envar>envHostHostHooks</envar>`, <envar>envHostTargetHooks</envar>`, or <envar>envTargetTargetHooks</envar>`. These 6 bash variables correspond to the 6 sorts of dependencies by platform (there's 12 total but we ignore the propagated/non-propagated axis).
   </para>
 
   <para>
@@ -1853,7 +1833,7 @@ addEnvHooks "$hostOffset" myBashFunction
        The Bintools Wrapper wraps the binary utilities for a bunch of miscellaneous purposes. These are GNU Binutils when targetting Linux, and a mix of cctools and GNU binutils for Darwin. [The "Bintools" name is supposed to be a compromise between "Binutils" and "cctools" not denoting any specific implementation.] Specifically, the underlying bintools package, and a C standard library (glibc or Darwin's libSystem, just for the dynamic loader) are all fed in, and dependency finding, hardening (see below), and purity checks for each are handled by the Bintools Wrapper. Packages typically depend on CC Wrapper, which in turn (at run time) depends on the Bintools Wrapper.
       </para>
       <para>
-       The Bintools Wrapper was only just recently split off from CC Wrapper, so the division of labor is still being worked out. For example, it shouldn't care about the C standard library, but just take a derivation with the dynamic loader (which happens to be the glibc on linux). Dependency finding however is a task both wrappers will continue to need to share, and probably the most important to understand. It is currently accomplished by collecting directories of host-platform dependencies (i.e. <varname>buildInputs</varname> and <varname>nativeBuildInputs</varname>) in environment variables. The Bintools Wrapper's setup hook causes any <filename>lib</filename> and <filename>lib64</filename> subdirectories to be added to <envar>NIX_LDFLAGS</envar>. Since the CC Wrapper and the Bintools Wrapper use the same strategy, most of the Bintools Wrapper code is sparsely commented and refers to the CC Wrapper. But the CC Wrapper's code, by contrast, has quite lengthy comments. The Bintools Wrapper merely cites those, rather than repeating them, to avoid falling out of sync.
+       The Bintools Wrapper was only just recently split off from CC Wrapper, so the division of labor is still being worked out. For example, it shouldn't care about about the C standard library, but just take a derivation with the dynamic loader (which happens to be the glibc on linux). Dependency finding however is a task both wrappers will continue to need to share, and probably the most important to understand. It is currently accomplished by collecting directories of host-platform dependencies (i.e. <varname>buildInputs</varname> and <varname>nativeBuildInputs</varname>) in environment variables. The Bintools Wrapper's setup hook causes any <filename>lib</filename> and <filename>lib64</filename> subdirectories to be added to <envar>NIX_LDFLAGS</envar>. Since the CC Wrapper and the Bintools Wrapper use the same strategy, most of the Bintools Wrapper code is sparsely commented and refers to the CC Wrapper. But the CC Wrapper's code, by contrast, has quite lengthy comments. The Bintools Wrapper merely cites those, rather than repeating them, to avoid falling out of sync.
       </para>
       <para>
        A final task of the setup hook is defining a number of standard environment variables to tell build systems which executables fulfill which purpose. They are defined to just be the base name of the tools, under the assumption that the Bintools Wrapper's binaries will be on the path. Firstly, this helps poorly-written packages, e.g. ones that look for just <command>gcc</command> when <envar>CC</envar> isn't defined yet <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.
@@ -1889,7 +1869,7 @@ addEnvHooks "$hostOffset" myBashFunction
   </para>
 
   <para>
-   Here are some more packages that provide a setup hook. Since the list of hooks is extensible, this is not an exhaustive list. The mechanism is only to be used as a last resort, so it might cover most uses.
+   Here are some more packages that provide a setup hook. Since the list of hooks is extensible, this is not an exhaustive list the mechanism is only to be used as a last resort, it might cover most uses.
    <variablelist>
     <varlistentry>
      <term>
@@ -2001,7 +1981,7 @@ addEnvHooks "$hostOffset" myBashFunction
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry xml:id="setup-hook-autopatchelfhook">
+    <varlistentry>
      <term>
       autoPatchelfHook
      </term>
@@ -2010,16 +1990,15 @@ addEnvHooks "$hostOffset" myBashFunction
        This is a special setup hook which helps in packaging proprietary software in that it automatically tries to find missing shared library dependencies of ELF files based on the given <varname>buildInputs</varname> and <varname>nativeBuildInputs</varname>.
       </para>
       <para>
-       You can also specify a <varname>runtimeDependencies</varname> variable which lists dependencies to be unconditionally added to <glossterm>rpath</glossterm> of all executables.
+       You can also specify a <envar>runtimeDependencies</envar> environment variable which lists dependencies that are unconditionally added to all executables.
+      </para>
+      <para>
        This is useful for programs that use <citerefentry>
        <refentrytitle>dlopen</refentrytitle>
        <manvolnum>3</manvolnum> </citerefentry> to load libraries at runtime.
       </para>
       <para>
-       In certain situations you may want to run the main command (<command>autoPatchelf</command>) of the setup hook on a file or a set of directories instead of unconditionally patching all outputs. This can be done by setting the <varname>dontAutoPatchelf</varname> environment variable to a non-empty value.
-      </para>
-      <para>
-       By default <command>autoPatchelf</command> will fail as soon as any ELF file requires a dependency which cannot be resolved via the given build inputs. In some situations you might prefer to just leave missing dependencies unpatched and continue to patch the rest. This can be achieved by setting the <envar>autoPatchelfIgnoreMissingDeps</envar> environment variable to a non-empty value.
+       In certain situations you may want to run the main command (<command>autoPatchelf</command>) of the setup hook on a file or a set of directories instead of unconditionally patching all outputs. This can be done by setting the <envar>dontAutoPatchelf</envar> environment variable to a non-empty value.
       </para>
       <para>
        The <command>autoPatchelf</command> command also recognizes a <parameter class="command">--no-recurse</parameter> command line flag, which prevents it from recursing into subdirectories.
@@ -2084,16 +2063,6 @@ postInstall = ''
       </para>
      </listitem>
     </varlistentry>
-    <varlistentry>
-     <term>
-      validatePkgConfig
-     </term>
-     <listitem>
-      <para>
-       The <literal>validatePkgConfig</literal> hook validates all pkg-config (<filename>.pc</filename>) files in a package. This helps catching some common errors in pkg-config files, such as undefined variables.
-      </para>
-     </listitem>
-    </varlistentry>
     <varlistentry>
      <term>
       cmake

doc/stdenv/multiple-output.xml

@@ -1,262 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE chapter [
-  <!ENTITY ndash "&#x2013;"> <!-- @vcunat likes to use this one ;-) -->
-]>
-<chapter xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="chap-multiple-output">
- <title>Multiple-output packages</title>
- <section xml:id="sec-multiple-outputs-introduction">
-  <title>Introduction</title>
-
-  <para>
-   The Nix language allows a derivation to produce multiple outputs, which is similar to what is utilized by other Linux distribution packaging systems. The outputs reside in separate Nix store paths, so they can be mostly handled independently of each other, including passing to build inputs, garbage collection or binary substitution. The exception is that building from source always produces all the outputs.
-  </para>
-
-  <para>
-   The main motivation is to save disk space by reducing runtime closure sizes; consequently also sizes of substituted binaries get reduced. Splitting can be used to have more granular runtime dependencies, for example the typical reduction is to split away development-only files, as those are typically not needed during runtime. As a result, closure sizes of many packages can get reduced to a half or even much less.
-  </para>
-
-  <note>
-   <para>
-    The reduction effects could be instead achieved by building the parts in completely separate derivations. That would often additionally reduce build-time closures, but it tends to be much harder to write such derivations, as build systems typically assume all parts are being built at once. This compromise approach of single source package producing multiple binary packages is also utilized often by rpm and deb.
-   </para>
-  </note>
-
-  <para>
-   A number of attributes can be used to work with a derivation with multiple outputs. The attribute <varname>outputs</varname> is a list of strings, which are the names of the outputs. For each of these names, an identically named attribute is created, corresponding to that output. The attribute <varname>meta.outputsToInstall</varname> is used to determine the default set of outputs to install when using the derivation name unqualified.
-  </para>
-
- </section>
- <section xml:id="sec-multiple-outputs-installing">
-  <title>Installing a split package</title>
-
-  <para>
-   When installing a package with multiple outputs, the package's <varname>meta.outputsToInstall</varname> attribute determines which outputs are actually installed. <varname>meta.outputsToInstall</varname> is a list whose <link xlink:href="https://github.com/NixOS/nixpkgs/blob/f1680774340d5443a1409c3421ced84ac1163ba9/pkgs/stdenv/generic/make-derivation.nix#L310-L320">default installs binaries and the associated man pages</link>. The following sections describe ways to install different outputs.
-  </para>
-
-  <section xml:id="sec-multiple-outputs-installing-nixos">
-   <title>Selecting outputs to install via NixOS</title>
-
-   <para>
-    NixOS provides two ways to select the outputs to install for packages listed in <varname>environment.systemPackages</varname>:
-   </para>
-
-   <itemizedlist>
-    <listitem>
-     <para>
-      The configuration option <varname>environment.extraOutputsToInstall</varname> is appended to each package's <varname>meta.outputsToInstall</varname> attribute to determine the outputs to install. It can for example be used to install <literal>info</literal> documentation or debug symbols for all packages.
-     </para>
-    </listitem>
-    <listitem>
-     <para>
-      The outputs can be listed as packages in <varname>environment.systemPackages</varname>. For example, the <literal>"out"</literal> and <literal>"info"</literal> outputs for the <varname>coreutils</varname> package can be installed by including <varname>coreutils</varname> and <varname>coreutils.info</varname> in <varname>environment.systemPackages</varname>.
-     </para>
-    </listitem>
-   </itemizedlist>
-  </section>
-
-  <section xml:id="sec-multiple-outputs-installing-nix-env">
-   <title>Selecting outputs to install via <command>nix-env</command></title>
-
-   <para>
-    <command>nix-env</command> lacks an easy way to select the outputs to install. When installing a package, <command>nix-env</command> always installs the outputs listed in <varname>meta.outputsToInstall</varname>, even when the user explicitly selects an output.
-   </para>
-
-   <warning>
-    <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>
-<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>
-   </warning>
-
-   <para>
-    The only recourse to select an output with <command>nix-env</command> is to override the package's <varname>meta.outputsToInstall</varname>, using the functions described in <xref linkend="chap-overrides" />. For example, the following overlay adds the <literal>"info"</literal> output for the <varname>coreutils</varname> package:
-   </para>
-
-<programlisting>self: super:
-{
-  coreutils = super.coreutils.overrideAttrs (oldAttrs: {
-    meta = oldAttrs.meta // { outputsToInstall = oldAttrs.meta.outputsToInstall or [ "out" ] ++ [ "info" ]; };
-  });
-}
-</programlisting>
-  </section>
- </section>
- <section xml:id="sec-multiple-outputs-using-split-packages">
-  <title>Using a split package</title>
-
-  <para>
-   In the Nix language the individual outputs can be reached explicitly as attributes, e.g. <varname>coreutils.info</varname>, but the typical case is just using packages as build inputs.
-  </para>
-
-  <para>
-   When a multiple-output derivation gets into a build input of another derivation, the <varname>dev</varname> output is added if it exists, otherwise the first output is added. In addition to that, <varname>propagatedBuildOutputs</varname> of that package which by default contain <varname>$outputBin</varname> and <varname>$outputLib</varname> are also added. (See <xref linkend="multiple-output-file-type-groups" />.)
-  </para>
-
-  <para>
-   In some cases it may be desirable to combine different outputs under a single store path. A function <literal>symlinkJoin</literal> can be used to do this. (Note that it may negate some closure size benefits of using a multiple-output package.)
-  </para>
- </section>
- <section xml:id="sec-multiple-outputs-">
-  <title>Writing a split derivation</title>
-
-  <para>
-   Here you find how to write a derivation that produces multiple outputs.
-  </para>
-
-  <para>
-   In nixpkgs there is a framework supporting multiple-output derivations. It tries to cover most cases by default behavior. You can find the source separated in &lt;<filename>nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh</filename>&gt;; it's relatively well-readable. The whole machinery is triggered by defining the <varname>outputs</varname> attribute to contain the list of desired output names (strings).
-  </para>
-
-<programlisting>outputs = [ "bin" "dev" "out" "doc" ];</programlisting>
-
-  <para>
-   Often such a single line is enough. For each output an equally named environment variable is passed to the builder and contains the path in nix store for that output. Typically you also want to have the main <varname>out</varname> output, as it catches any files that didn't get elsewhere.
-  </para>
-
-  <note>
-   <para>
-    There is a special handling of the <varname>debug</varname> output, described at <xref linkend="stdenv-separateDebugInfo" />.
-   </para>
-  </note>
-
-  <section xml:id="multiple-output-file-binaries-first-convention">
-   <title><quote>Binaries first</quote></title>
-
-   <para>
-    A commonly adopted convention in <literal>nixpkgs</literal> is that executables provided by the package are contained within its first output. This convention allows the dependent packages to reference the executables provided by packages in a uniform manner. For instance, provided with the knowledge that the <literal>perl</literal> package contains a <literal>perl</literal> executable it can be referenced as <literal>${pkgs.perl}/bin/perl</literal> within a Nix derivation that needs to execute a Perl script.
-   </para>
-
-   <para>
-    The <literal>glibc</literal> package is a deliberate single exception to the <quote>binaries first</quote> convention. The <literal>glibc</literal> has <literal>libs</literal> as its first output allowing the libraries provided by <literal>glibc</literal> to be referenced directly (e.g. <literal>${stdenv.glibc}/lib/ld-linux-x86-64.so.2</literal>). The executables provided by <literal>glibc</literal> can be accessed via its <literal>bin</literal> attribute (e.g. <literal>${stdenv.glibc.bin}/bin/ldd</literal>).
-   </para>
-
-   <para>
-    The reason for why <literal>glibc</literal> deviates from the convention is because referencing a library provided by <literal>glibc</literal> is a very common operation among Nix packages. For instance, third-party executables packaged by Nix are typically patched and relinked with the relevant version of <literal>glibc</literal> libraries from Nix packages (please see the documentation on <link xlink:href="https://github.com/NixOS/patchelf/blob/master/README">patchelf</link> for more details).
-   </para>
-  </section>
-
-  <section xml:id="multiple-output-file-type-groups">
-   <title>File type groups</title>
-
-   <para>
-    The support code currently recognizes some particular kinds of outputs and either instructs the build system of the package to put files into their desired outputs or it moves the files during the fixup phase. Each group of file types has an <varname>outputFoo</varname> variable specifying the output name where they should go. If that variable isn't defined by the derivation writer, it is guessed &ndash; a default output name is defined, falling back to other possibilities if the output isn't defined.
-   </para>
-
-   <variablelist>
-    <varlistentry>
-     <term>
-      <varname> $outputDev</varname>
-     </term>
-     <listitem>
-      <para>
-       is for development-only files. These include C(++) headers, pkg-config, cmake and aclocal files. They go to <varname>dev</varname> or <varname>out</varname> by default.
-      </para>
-     </listitem>
-    </varlistentry>
-    <varlistentry>
-     <term>
-      <varname> $outputBin</varname>
-     </term>
-     <listitem>
-      <para>
-       is meant for user-facing binaries, typically residing in bin/. They go to <varname>bin</varname> or <varname>out</varname> by default.
-      </para>
-     </listitem>
-    </varlistentry>
-    <varlistentry>
-     <term>
-      <varname> $outputLib</varname>
-     </term>
-     <listitem>
-      <para>
-       is meant for libraries, typically residing in <filename>lib/</filename> and <filename>libexec/</filename>. They go to <varname>lib</varname> or <varname>out</varname> by default.
-      </para>
-     </listitem>
-    </varlistentry>
-    <varlistentry>
-     <term>
-      <varname> $outputDoc</varname>
-     </term>
-     <listitem>
-      <para>
-       is for user documentation, typically residing in <filename>share/doc/</filename>. It goes to <varname>doc</varname> or <varname>out</varname> by default.
-      </para>
-     </listitem>
-    </varlistentry>
-    <varlistentry>
-     <term>
-      <varname> $outputDevdoc</varname>
-     </term>
-     <listitem>
-      <para>
-       is for <emphasis>developer</emphasis> documentation. Currently we count gtk-doc and devhelp books in there. It goes to <varname>devdoc</varname> or is removed (!) by default. This is because e.g. gtk-doc tends to be rather large and completely unused by nixpkgs users.
-      </para>
-     </listitem>
-    </varlistentry>
-    <varlistentry>
-     <term>
-      <varname> $outputMan</varname>
-     </term>
-     <listitem>
-      <para>
-       is for man pages (except for section 3). They go to <varname>man</varname> or <varname>$outputBin</varname> by default.
-      </para>
-     </listitem>
-    </varlistentry>
-    <varlistentry>
-     <term>
-      <varname> $outputDevman</varname>
-     </term>
-     <listitem>
-      <para>
-       is for section 3 man pages. They go to <varname>devman</varname> or <varname>$outputMan</varname> by default.
-      </para>
-     </listitem>
-    </varlistentry>
-    <varlistentry>
-     <term>
-      <varname> $outputInfo</varname>
-     </term>
-     <listitem>
-      <para>
-       is for info pages. They go to <varname>info</varname> or <varname>$outputBin</varname> by default.
-      </para>
-     </listitem>
-    </varlistentry>
-   </variablelist>
-  </section>
-
-  <section xml:id="sec-multiple-outputs-caveats">
-   <title>Common caveats</title>
-
-   <itemizedlist>
-    <listitem>
-     <para>
-      Some configure scripts don't like some of the parameters passed by default by the framework, e.g. <literal>--docdir=/foo/bar</literal>. You can disable this by setting <literal>setOutputFlags = false;</literal>.
-     </para>
-    </listitem>
-    <listitem>
-     <para>
-      The outputs of a single derivation can retain references to each other, but note that circular references are not allowed. (And each strongly-connected component would act as a single output anyway.)
-     </para>
-    </listitem>
-    <listitem>
-     <para>
-      Most of split packages contain their core functionality in libraries. These libraries tend to refer to various kind of data that typically gets into <varname>out</varname>, e.g. locale strings, so there is often no advantage in separating the libraries into <varname>lib</varname>, as keeping them in <varname>out</varname> is easier.
-     </para>
-    </listitem>
-    <listitem>
-     <para>
-      Some packages have hidden assumptions on install paths, which complicates splitting.
-     </para>
-    </listitem>
-   </itemizedlist>
-  </section>
- </section>
-<!--Writing a split derivation-->
-</chapter>

doc/submitting-changes.xml

@@ -0,0 +1,429 @@
+<chapter xmlns="http://docbook.org/ns/docbook"
+         xmlns:xlink="http://www.w3.org/1999/xlink"
+         xml:id="chap-submitting-changes">
+ <title>Submitting changes</title>
+ <section xml:id="submitting-changes-making-patches">
+  <title>Making patches</title>
+
+  <itemizedlist>
+   <listitem>
+    <para>
+     Read <link xlink:href="https://nixos.org/nixpkgs/manual/">Manual (How to write packages for Nix)</link>.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Fork the repository on GitHub.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Create a branch for your future fix.
+     <itemizedlist>
+      <listitem>
+       <para>
+        You can make branch from a commit of your local <command>nixos-version</command>. That will help you to avoid additional local compilations. Because you will receive packages from binary cache.
+        <itemizedlist>
+         <listitem>
+          <para>
+           For example: <command>nixos-version</command> returns <command>15.05.git.0998212 (Dingo)</command>. So you can do:
+          </para>
+         </listitem>
+        </itemizedlist>
+<screen>
+<prompt>$ </prompt>git checkout 0998212
+<prompt>$ </prompt>git checkout -b 'fix/pkg-name-update'
+</screen>
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        Please avoid working directly on the <command>master</command> branch.
+       </para>
+      </listitem>
+     </itemizedlist>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Make commits of logical units.
+     <itemizedlist>
+      <listitem>
+       <para>
+        If you removed pkgs, made some major NixOS changes etc., write about them in <command>nixos/doc/manual/release-notes/rl-unstable.xml</command>.
+       </para>
+      </listitem>
+     </itemizedlist>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Check for unnecessary whitespace with <command>git diff --check</command> before committing.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Format the commit in a following way:
+    </para>
+<programlisting>
+(pkg-name | nixos/&lt;module>): (from -> to | init at version | refactor | etc)
+Additional information.
+</programlisting>
+    <itemizedlist>
+     <listitem>
+      <para>
+       Examples:
+       <itemizedlist>
+        <listitem>
+         <para>
+          <command>nginx: init at 2.0.1</command>
+         </para>
+        </listitem>
+        <listitem>
+         <para>
+          <command>firefox: 54.0.1 -> 55.0</command>
+         </para>
+        </listitem>
+        <listitem>
+         <para>
+          <command>nixos/hydra: add bazBaz option</command>
+         </para>
+        </listitem>
+        <listitem>
+         <para>
+          <command>nixos/nginx: refactor config generation</command>
+         </para>
+        </listitem>
+       </itemizedlist>
+      </para>
+     </listitem>
+    </itemizedlist>
+   </listitem>
+   <listitem>
+    <para>
+     Test your changes. If you work with
+     <itemizedlist>
+      <listitem>
+       <para>
+        nixpkgs:
+        <itemizedlist>
+         <listitem>
+          <para>
+           update pkg ->
+           <itemizedlist>
+            <listitem>
+             <para>
+              <command>nix-env -i pkg-name -f &lt;path to your local nixpkgs folder&gt;</command>
+             </para>
+            </listitem>
+           </itemizedlist>
+          </para>
+         </listitem>
+         <listitem>
+          <para>
+           add pkg ->
+           <itemizedlist>
+            <listitem>
+             <para>
+              Make sure it's in <command>pkgs/top-level/all-packages.nix</command>
+             </para>
+            </listitem>
+            <listitem>
+             <para>
+              <command>nix-env -i pkg-name -f &lt;path to your local nixpkgs folder&gt;</command>
+             </para>
+            </listitem>
+           </itemizedlist>
+          </para>
+         </listitem>
+         <listitem>
+          <para>
+           <emphasis>If you don't want to install pkg in you profile</emphasis>.
+           <itemizedlist>
+            <listitem>
+             <para>
+              <command>nix-build -A pkg-attribute-name &lt;path to your local nixpkgs folder&gt;/default.nix</command> and check results in the folder <command>result</command>. It will appear in the same directory where you did <command>nix-build</command>.
+             </para>
+            </listitem>
+           </itemizedlist>
+          </para>
+         </listitem>
+         <listitem>
+          <para>
+           If you did <command>nix-env -i pkg-name</command> you can do <command>nix-env -e pkg-name</command> to uninstall it from your system.
+          </para>
+         </listitem>
+        </itemizedlist>
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        NixOS and its modules:
+        <itemizedlist>
+         <listitem>
+          <para>
+           You can add new module to your NixOS configuration file (usually it's <command>/etc/nixos/configuration.nix</command>). And do <command>sudo nixos-rebuild test -I nixpkgs=&lt;path to your local nixpkgs folder&gt; --fast</command>.
+          </para>
+         </listitem>
+        </itemizedlist>
+       </para>
+      </listitem>
+     </itemizedlist>
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     If you have commits <command>pkg-name: oh, forgot to insert whitespace</command>: squash commits in this case. Use <command>git rebase -i</command>.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Rebase you branch against current <command>master</command>.
+    </para>
+   </listitem>
+  </itemizedlist>
+ </section>
+ <section xml:id="submitting-changes-submitting-changes">
+  <title>Submitting changes</title>
+
+  <itemizedlist>
+   <listitem>
+    <para>
+     Push your changes to your fork of nixpkgs.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Create pull request:
+     <itemizedlist>
+      <listitem>
+       <para>
+        Write the title in format <command>(pkg-name | nixos/&lt;module>): improvement</command>.
+        <itemizedlist>
+         <listitem>
+          <para>
+           If you update the pkg, write versions <command>from -> to</command>.
+          </para>
+         </listitem>
+        </itemizedlist>
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        Write in comment if you have tested your patch. Do not rely much on <command>TravisCI</command>.
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        If you make an improvement, write about your motivation.
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        Notify maintainers of the package. For example add to the message: <command>cc @jagajaga @domenkozar</command>.
+       </para>
+      </listitem>
+     </itemizedlist>
+    </para>
+   </listitem>
+  </itemizedlist>
+ </section>
+ <section xml:id="submitting-changes-pull-request-template">
+  <title>Pull Request Template</title>
+
+  <para>
+   The pull request template helps determine what steps have been made for a contribution so far, and will help guide maintainers on the status of a change. The motivation section of the PR should include any extra details the title does not address and link any existing issues related to the pull request.
+  </para>
+
+  <para>
+   When a PR is created, it will be pre-populated with some checkboxes detailed below:
+  </para>
+
+  <section xml:id="submitting-changes-tested-with-sandbox">
+   <title>Tested using sandboxing</title>
+
+   <para>
+    When sandbox builds are enabled, Nix will setup an isolated environment for each build process. It is used to remove further hidden dependencies set by the build environment to improve reproducibility. This includes access to the network during the build outside of <function>fetch*</function> functions and files outside the Nix store. Depending on the operating system access to other resources are blocked as well (ex. inter process communication is isolated on Linux); see <link
+      xlink:href="https://nixos.org/nix/manual/#description-45">build-use-sandbox</link> in Nix manual for details.
+   </para>
+
+   <para>
+    Sandboxing is not enabled by default in Nix due to a small performance hit on each build. In pull requests for <link
+        xlink:href="https://github.com/NixOS/nixpkgs/">nixpkgs</link> people are asked to test builds with sandboxing enabled (see <literal>Tested using sandboxing</literal> in the pull request template) because in<link
+        xlink:href="https://nixos.org/hydra/">https://nixos.org/hydra/</link> sandboxing is also used.
+   </para>
+
+   <para>
+    Depending if you use NixOS or other platforms you can use one of the following methods to enable sandboxing <emphasis role="bold">before</emphasis> building the package:
+    <itemizedlist>
+     <listitem>
+      <para>
+       <emphasis role="bold">Globally enable sandboxing on NixOS</emphasis>: add the following to <filename>configuration.nix</filename>
+<screen>nix.useSandbox = true;</screen>
+      </para>
+     </listitem>
+     <listitem>
+      <para>
+       <emphasis role="bold">Globally enable sandboxing on non-NixOS platforms</emphasis>: add the following to: <filename>/etc/nix/nix.conf</filename>
+<screen>build-use-sandbox = true</screen>
+      </para>
+     </listitem>
+    </itemizedlist>
+   </para>
+  </section>
+
+  <section xml:id="submitting-changes-platform-diversity">
+   <title>Built on platform(s)</title>
+
+   <para>
+    Many Nix packages are designed to run on multiple platforms. As such, it's important to let the maintainer know which platforms your changes have been tested on. It's not always practical to test a change on all platforms, and is not required for a pull request to be merged. Only check the systems you tested the build on in this section.
+   </para>
+  </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>
+    Packages with automated tests are much more likely to be merged in a timely fashion because it doesn't require as much manual testing by the maintainer to verify the functionality of the package. If there are existing tests for the package, they should be run to verify your changes do not break the tests. Tests only apply to packages with NixOS modules defined and can only be run on Linux. For more details on writing and running tests, see the <link
+        xlink:href="https://nixos.org/nixos/manual/index.html#sec-nixos-tests">section in the NixOS manual</link>.
+   </para>
+  </section>
+
+  <section xml:id="submitting-changes-tested-compilation">
+   <title>Tested compilation of all pkgs that depend on this change using <command>nix-review</command></title>
+
+   <para>
+    If you are updating a package's version, you can use nix-review to make sure all packages that depend on the updated package still compile correctly. The <command>nix-review</command> utility can look for and build all dependencies either based on uncommited changes with the <literal>wip</literal> option or specifying a github pull request number.
+   </para>
+
+   <para>
+    review changes from pull request number 12345:
+<screen>nix-shell -p nix-review --run "nix-review pr 12345"</screen>
+   </para>
+
+   <para>
+    review uncommitted changes:
+<screen>nix-shell -p nix-review --run "nix-review wip"</screen>
+   </para>
+  </section>
+
+  <section xml:id="submitting-changes-tested-execution">
+   <title>Tested execution of all binary files (usually in <filename>./result/bin/</filename>)</title>
+
+   <para>
+    It's important to test any executables generated by a build when you change or create a package in nixpkgs. This can be done by looking in <filename>./result/bin</filename> and running any files in there, or at a minimum, the main executable for the package. For example, if you make a change to <package>texlive</package>, you probably would only check the binaries associated with the change you made rather than testing all of them.
+   </para>
+  </section>
+
+  <section xml:id="submitting-changes-contribution-standards">
+   <title>Meets Nixpkgs contribution standards</title>
+
+   <para>
+    The last checkbox is fits <link
+        xlink:href="https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md">CONTRIBUTING.md</link>. The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
+   </para>
+  </section>
+ </section>
+ <section xml:id="submitting-changes-hotfixing-pull-requests">
+  <title>Hotfixing pull requests</title>
+
+  <itemizedlist>
+   <listitem>
+    <para>
+     Make the appropriate changes in you branch.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Don't create additional commits, do
+     <itemizedlist>
+      <listitem>
+       <para>
+        <command>git rebase -i</command>
+       </para>
+      </listitem>
+      <listitem>
+       <para>
+        <command>git push --force</command> to your branch.
+       </para>
+      </listitem>
+     </itemizedlist>
+    </para>
+   </listitem>
+  </itemizedlist>
+ </section>
+ <section xml:id="submitting-changes-commit-policy">
+  <title>Commit policy</title>
+
+  <itemizedlist>
+   <listitem>
+    <para>
+     Commits must be sufficiently tested before being merged, both for the master and staging branches.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     Hydra builds for master and staging should not be used as testing platform, it's a build farm for changes that have been already tested.
+    </para>
+   </listitem>
+   <listitem>
+    <para>
+     When changing the bootloader installation process, extra care must be taken. Grub installations cannot be rolled back, hence changes may break people's installations forever. For any non-trivial change to the bootloader please file a PR asking for review, especially from @edolstra.
+    </para>
+   </listitem>
+  </itemizedlist>
+
+  <section xml:id="submitting-changes-master-branch">
+   <title>Master branch</title>
+
+   <itemizedlist>
+    <listitem>
+     <para>
+      It should only see non-breaking commits that do not cause mass rebuilds.
+     </para>
+    </listitem>
+   </itemizedlist>
+  </section>
+
+  <section xml:id="submitting-changes-staging-branch">
+   <title>Staging branch</title>
+
+   <itemizedlist>
+    <listitem>
+     <para>
+      It's only for non-breaking mass-rebuild commits. That means it's not to be used for testing, and changes must have been well tested already. <link xlink:href="https://web.archive.org/web/20160528180406/http://comments.gmane.org/gmane.linux.distributions.nixos/13447">Read policy here</link>.
+     </para>
+    </listitem>
+    <listitem>
+     <para>
+      If the branch is already in a broken state, please refrain from adding extra new breakages. Stabilize it for a few days, merge into master, then resume development on staging. <link xlink:href="http://hydra.nixos.org/jobset/nixpkgs/staging#tabs-evaluations">Keep an eye on the staging evaluations here</link>. If any fixes for staging happen to be already in master, then master can be merged into staging.
+     </para>
+    </listitem>
+   </itemizedlist>
+  </section>
+
+  <section xml:id="submitting-changes-stable-release-branches">
+   <title>Stable release branches</title>
+
+   <itemizedlist>
+    <listitem>
+     <para>
+      If you're cherry-picking a commit to a stable release branch, always use <command>git cherry-pick -xe</command> and ensure the message contains a clear description about why this needs to be included in the stable branch.
+     </para>
+     <para>
+      An example of a cherry-picked commit would look like this:
+     </para>
+<screen>
+nixos: Refactor the world.
+
+The original commit message describing the reason why the world was torn apart.
+
+(cherry picked from commit abcdef)
+Reason: I just had a gut feeling that this would also be wanted by people from
+the stone age.
+</screen>
+    </listitem>
+   </itemizedlist>
+  </section>
+ </section>
+</chapter>