diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/contributing/reviewing-contributions.chapter.md | 105 | ||||
| -rw-r--r-- | doc/contributing/submitting-changes.chapter.md | 2 | ||||
| -rw-r--r-- | doc/languages-frameworks/coq.section.md | 2 | ||||
| -rw-r--r-- | doc/languages-frameworks/python.section.md | 67 | ||||
| -rw-r--r-- | doc/languages-frameworks/vim.section.md | 3 | ||||
| -rw-r--r-- | doc/release-notes.xml | 650 | ||||
| -rw-r--r-- | doc/using/configuration.chapter.md | 17 |
7 files changed, 151 insertions, 695 deletions
diff --git a/doc/contributing/reviewing-contributions.chapter.md b/doc/contributing/reviewing-contributions.chapter.md index 3417854730ef..4452695a6f38 100644 --- a/doc/contributing/reviewing-contributions.chapter.md +++ b/doc/contributing/reviewing-contributions.chapter.md @@ -185,6 +185,111 @@ Sample template for a new module review is provided below. ##### Comments ``` +## Individual maintainer list {#reviewing-contributions-indvidual-maintainer-list} + +When adding users to `maintainers/maintainer-list.nix`, the following +checks should be performed: + +- If the user has specified a GPG key, verify that the commit is + signed by their key. + + First, validate that the commit adding the maintainer is signed by + the key the maintainer listed. Check out the pull request and + compare its signing key with the listed key in the commit. + + If the commit is not signed or it is signed by a different user, ask + them to either recommit using that key or to remove their key + information. + + Given a maintainter entry like this: + + ``` nix + { + example = { + email = "user@example.com"; + name = "Example User"; + keys = [{ + fingerprint = "0000 0000 2A70 6423 0AED 3C11 F04F 7A19 AAA6 3AFE"; + }]; + } + }; + ``` + + First receive their key from a keyserver: + + $ gpg --recv-keys 0xF04F7A19AAA63AFE + gpg: key 0xF04F7A19AAA63AFE: public key "Example <user@example.com>" imported + gpg: Total number processed: 1 + gpg: imported: 1 + + Then check the commit is signed by that key: + + $ git log --show-signature + commit b87862a4f7d32319b1de428adb6cdbdd3a960153 + gpg: Signature made Wed Mar 12 13:32:24 2003 +0000 + gpg: using RSA key 000000002A7064230AED3C11F04F7A19AAA63AFE + gpg: Good signature from "Example User <user@example.com> + Author: Example User <user@example.com> + Date: Wed Mar 12 13:32:24 2003 +0000 + + maintainers: adding example + + and validate that there is a `Good signature` and the printed key + matches the user's submitted key. + + Note: GitHub's "Verified" label does not display the user's full key + fingerprint, and should not be used for validating the key matches. + +- If the user has specified a `github` account name, ensure they have + also specified a `githubId` and verify the two match. + + Maintainer entries that include a `github` field must also include + their `githubId`. People can and do change their GitHub name + frequently, and the ID is used as the official and stable identity + of the maintainer. + + Given a maintainer entry like this: + + ``` nix + { + example = { + email = "user@example.com"; + name = "Example User"; + github = "ghost"; + githubId = 10137; + } + }; + ``` + + First, make sure that the listed GitHub handle matches the author of + the commit. + + Then, visit the URL `https://api.github.com/users/ghost` and + validate that the `id` field matches the provided `githubId`. + +## Maintainer teams {#reviewing-contributions-maintainer-teams} + +Feel free to create a new maintainer team in `maintainers/team-list.nix` +when a group is collectively responsible for a collection of packages. +Use taste and personal judgement when deciding if a team is warranted. + +Teams are allowed to define their own rules about membership. + +For example, some teams will represent a business or other group which +wants to carefully track its members. Other teams may be very open about +who can join, and allow anybody to participate. + +When reviewing changes to a team, read the team's scope and the context +around the member list for indications about the team's membership +policy. + +In any case, request reviews from the existing team members. If the team +lists no specific membership policy, feel free to merge changes to the +team after giving the existing members a few days to respond. + +*Important:* If a team says it is a closed group, do not merge additions +to the team without an approval by at least one existing member. + ## Other submissions {#reviewing-contributions-other-submissions} Other type of submissions requires different reviewing steps. diff --git a/doc/contributing/submitting-changes.chapter.md b/doc/contributing/submitting-changes.chapter.md index 6f87e015b9cf..471e45d7dfb3 100644 --- a/doc/contributing/submitting-changes.chapter.md +++ b/doc/contributing/submitting-changes.chapter.md @@ -227,7 +227,7 @@ digraph { } ``` -[This GitHub Action](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/periodic-merge-6h.yml) brings changes from `master` to `staging-next` and from `staging-next` to `staging` every 6 hours. +[This GitHub Action](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/periodic-merge-6h.yml) brings changes from `master` to `staging-next` and from `staging-next` to `staging` every 6 hours; these are the blue arrows in the diagram above. The purple arrows in the diagram above are done manually and much less frequently. You can get an idea of how often these merges occur by looking at the git history. ### Master branch {#submitting-changes-master-branch} diff --git a/doc/languages-frameworks/coq.section.md b/doc/languages-frameworks/coq.section.md index 11777b5eef42..80d8566f804f 100644 --- a/doc/languages-frameworks/coq.section.md +++ b/doc/languages-frameworks/coq.section.md @@ -41,7 +41,7 @@ The recommended way of defining a derivation for a Coq library, is to use the `c * `useDune2` (optional, defaults to `false`) uses Dune2 to build the package if set to true, the presence of this attribute overrides the behavior of the previous one. * `opam-name` (optional, defaults to concatenating with a dash separator the components of `namePrefix` and `pname`), name of the Dune package to build. * `enableParallelBuilding` (optional, defaults to `true`), since it is activated by default, we provide a way to disable it. -* `extraInstallFlags` (optional), allows to extend `installFlags` which initializes the variables `DESTDIR` and `COQMF_COQLIB` so as to install in the proper subdirectory. Indeed Coq libraries should be installed in `$(out)/lib/coq/${coq.coq-version}/user-contrib/`. Such directories are automatically added to the `$COQPATH` environment variable by the hook defined in the Coq derivation. +* `extraInstallFlags` (optional), allows to extend `installFlags` which initializes the variable `COQMF_COQLIB` so as to install in the proper subdirectory. Indeed Coq libraries should be installed in `$(out)/lib/coq/${coq.coq-version}/user-contrib/`. Such directories are automatically added to the `$COQPATH` environment variable by the hook defined in the Coq derivation. * `setCOQBIN` (optional, defaults to `true`), by default, the environment variable `$COQBIN` is set to the current Coq's binary, but one can disable this behavior by setting it to `false`, * `useMelquiondRemake` (optional, default to `null`) is an attribute set, which, if given, overloads the `preConfigurePhases`, `configureFlags`, `buildPhase`, and `installPhase` attributes of the derivation for a specific use in libraries using `remake` as set up by Guillaume Melquiond for `flocq`, `gappalib`, `interval`, and `coquelicot` (see the corresponding derivation for concrete examples of use of this option). For backward compatibility, the attribute `useMelquiondRemake.logpath` must be set to the logical root of the library (otherwise, one can pass `useMelquiondRemake = {}` to activate this without backward compatibility). * `dropAttrs`, `keepAttrs`, `dropDerivationAttrs` are all optional and allow to tune which attribute is added or removed from the final call to `mkDerivation`. diff --git a/doc/languages-frameworks/python.section.md b/doc/languages-frameworks/python.section.md index 3211ae616a1c..09e177c7a482 100644 --- a/doc/languages-frameworks/python.section.md +++ b/doc/languages-frameworks/python.section.md @@ -8,9 +8,9 @@ Several versions of the Python interpreter are available on Nix, as well as a high amount of packages. The attribute `python3` refers to the default -interpreter, which is currently CPython 3.9. The attribute `python` refers to +interpreter, which is currently CPython 3.10. The attribute `python` refers to CPython 2.7 for backwards-compatibility. It is also possible to refer to -specific versions, e.g. `python38` refers to CPython 3.8, and `pypy` refers to +specific versions, e.g. `python39` refers to CPython 3.9, and `pypy` refers to the default PyPy interpreter. Python is used a lot, and in different ways. This affects also how it is @@ -26,10 +26,10 @@ however, 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 Python libraries for this specific interpreter. E.g., the `toolz` package corresponding to the default interpreter -is `python.pkgs.toolz`, and the CPython 3.8 version is `python38.pkgs.toolz`. +is `python.pkgs.toolz`, and the CPython 3.9 version is `python39.pkgs.toolz`. The main package set contains aliases to these package sets, e.g. -`pythonPackages` refers to `python.pkgs` and `python38Packages` to -`python38.pkgs`. +`pythonPackages` refers to `python.pkgs` and `python39Packages` to +`python39.pkgs`. #### Installing Python and packages {#installing-python-and-packages} @@ -54,7 +54,7 @@ with `python.buildEnv` or `python.withPackages` where the interpreter and other executables are wrapped to be able to find each other and all of the modules. In the following examples we will start by creating a simple, ad-hoc environment -with a nix-shell that has `numpy` and `toolz` in Python 3.8; then we will create +with a nix-shell that has `numpy` and `toolz` in Python 3.9; then we will create a re-usable environment in a single-file Python script; then we will create a full Python environment for development with this same environment. @@ -70,10 +70,10 @@ temporary shell session with a Python and a *precise* list of packages (plus their runtime dependencies), with no other Python packages in the Python interpreter's scope. -To create a Python 3.8 session with `numpy` and `toolz` available, run: +To create a Python 3.9 session with `numpy` and `toolz` available, run: ```sh -$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy toolz ])' +$ nix-shell -p 'python39.withPackages(ps: with ps; [ numpy toolz ])' ``` By default `nix-shell` will start a `bash` session with this interpreter in our @@ -81,8 +81,8 @@ By default `nix-shell` will start a `bash` session with this interpreter in our ```Python console [nix-shell:~/src/nixpkgs]$ python3 -Python 3.8.1 (default, Dec 18 2019, 19:06:26) -[GCC 9.2.0] on linux +Python 3.9.12 (main, Mar 23 2022, 21:36:19) +[GCC 11.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import numpy; import toolz ``` @@ -102,13 +102,16 @@ will still get 1 wrapped Python interpreter. We can start the interpreter directly like so: ```sh -$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy toolz requests ])' --run python3 -these derivations will be built: - /nix/store/xbdsrqrsfa1yva5s7pzsra8k08gxlbz1-python3-3.8.1-env.drv -building '/nix/store/xbdsrqrsfa1yva5s7pzsra8k08gxlbz1-python3-3.8.1-env.drv'... -created 277 symlinks in user environment -Python 3.8.1 (default, Dec 18 2019, 19:06:26) -[GCC 9.2.0] on linux +$ nix-shell -p "python39.withPackages (ps: with ps; [ numpy toolz requests ])" --run python3 +this derivation will be built: + /nix/store/mpn7k6bkjl41fm51342rafaqfsl10qs4-python3-3.9.12-env.drv +this path will be fetched (0.09 MiB download, 0.41 MiB unpacked): + /nix/store/5gaiacnzi096b6prc6aa1pwrhncmhc8b-python3.9-toolz-0.11.2 +copying path '/nix/store/5gaiacnzi096b6prc6aa1pwrhncmhc8b-python3.9-toolz-0.11.2' from 'https://cache.nixos.org'... +building '/nix/store/mpn7k6bkjl41fm51342rafaqfsl10qs4-python3-3.9.12-env.drv'... +created 279 symlinks in user environment +Python 3.9.12 (main, Mar 23 2022, 21:36:19) +[GCC 11.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import requests >>> @@ -147,7 +150,7 @@ Executing this script requires a `python3` that has `numpy`. Using what we learn in the previous section, we could startup a shell and just run it like so: ```ShellSession -$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy ])' --run 'python3 foo.py' +$ nix-shell -p 'python39.withPackages(ps: with ps; [ numpy ])' --run 'python3 foo.py' The dot product of [1 2] and [3 4] is: 11 ``` @@ -210,12 +213,12 @@ create a single script with Python dependencies, but in the course of normal development we're usually working in an entire package repository. As explained in the Nix manual, `nix-shell` can also load an expression from a -`.nix` file. Say we want to have Python 3.8, `numpy` and `toolz`, like before, +`.nix` file. Say we want to have Python 3.9, `numpy` and `toolz`, like before, in an environment. We can add a `shell.nix` file describing our dependencies: ```nix with import <nixpkgs> {}; -(python38.withPackages (ps: [ps.numpy ps.toolz])).env +(python39.withPackages (ps: [ps.numpy ps.toolz])).env ``` And then at the command line, just typing `nix-shell` produces the same @@ -229,7 +232,7 @@ What's happening here? imports the `<nixpkgs>` function, `{}` calls it and the `with` statement brings all attributes of `nixpkgs` in the local scope. These attributes form the main package set. -2. Then we create a Python 3.8 environment with the `withPackages` function, as before. +2. Then we create a Python 3.9 environment with the `withPackages` function, as before. 3. The `withPackages` function expects us to provide a function as an argument that takes the set of all Python packages and returns a list of packages to include in the environment. Here, we select the packages `numpy` and `toolz` @@ -240,7 +243,7 @@ To combine this with `mkShell` you can: ```nix with import <nixpkgs> {}; let - pythonEnv = python38.withPackages (ps: [ + pythonEnv = python39.withPackages (ps: [ ps.numpy ps.toolz ]); @@ -378,8 +381,8 @@ information. The output of the function is a derivation. An expression for `toolz` can be found in the Nixpkgs repository. As explained in the introduction of this Python section, a derivation of `toolz` is available -for each interpreter version, e.g. `python38.pkgs.toolz` refers to the `toolz` -derivation corresponding to the CPython 3.8 interpreter. +for each interpreter version, e.g. `python39.pkgs.toolz` refers to the `toolz` +derivation corresponding to the CPython 3.9 interpreter. The above example works when you're directly working on `pkgs/top-level/python-packages.nix` in the Nixpkgs repository. Often though, @@ -392,11 +395,11 @@ and adds it along with a `numpy` package to a Python environment. with import <nixpkgs> {}; ( let - my_toolz = python38.pkgs.buildPythonPackage rec { + my_toolz = python39.pkgs.buildPythonPackage rec { pname = "toolz"; version = "0.10.0"; - src = python38.pkgs.fetchPypi { + src = python39.pkgs.fetchPypi { inherit pname version; sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560"; }; @@ -414,7 +417,7 @@ with import <nixpkgs> {}; ``` Executing `nix-shell` will result in an environment in which you can use -Python 3.8 and the `toolz` package. As you can see we had to explicitly mention +Python 3.9 and the `toolz` package. As you can see we had to explicitly mention for which Python version we want to build a package. So, what did we do here? Well, we took the Nix expression that we used earlier @@ -742,7 +745,7 @@ If we create a `shell.nix` file which calls `buildPythonPackage`, and if `src` is a local source, and if the local source has a `setup.py`, then development mode is activated. -In the following example we create a simple environment that has a Python 3.8 +In the following example we create a simple environment that has a Python 3.9 version of our package in it, as well as its dependencies and other packages we like to have in the environment, all specified with `propagatedBuildInputs`. Indeed, we can just add any package we like to have in our environment to @@ -750,7 +753,7 @@ Indeed, we can just add any package we like to have in our environment to ```nix with import <nixpkgs> {}; -with python38Packages; +with python39Packages; buildPythonPackage rec { name = "mypackage"; @@ -828,9 +831,9 @@ and in this case the `python38` interpreter is automatically used. ### Interpreters {#interpreters} -Versions 2.7, 3.7, 3.8 and 3.9 of the CPython interpreter are available as -respectively `python27`, `python37`, `python38` and `python39`. The -aliases `python2` and `python3` correspond to respectively `python27` and +Versions 2.7, 3.7, 3.8, 3.9 and 3.10 of the CPython interpreter are available +as respectively `python27`, `python37`, `python38`, `python39` and `python310`. +The aliases `python2` and `python3` correspond to respectively `python27` and `python39`. The attribute `python` maps to `python2`. The PyPy interpreters compatible with Python 2.7 and 3 are available as `pypy27` and `pypy3`, with aliases `pypy2` mapping to `pypy27` and `pypy` mapping to `pypy2`. The Nix diff --git a/doc/languages-frameworks/vim.section.md b/doc/languages-frameworks/vim.section.md index 563fdf45a861..6d7efe455b13 100644 --- a/doc/languages-frameworks/vim.section.md +++ b/doc/languages-frameworks/vim.section.md @@ -277,9 +277,6 @@ my-vim = copy paste output2 here ]; - # Pathogen would be - # vimrcConfig.pathogen.knownPlugins = plugins; # plugins - # vimrcConfig.pathogen.pluginNames = ["tlib"]; }; ``` diff --git a/doc/release-notes.xml b/doc/release-notes.xml deleted file mode 100644 index a15f54667290..000000000000 --- a/doc/release-notes.xml +++ /dev/null @@ -1,650 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<article xmlns="http://docbook.org/ns/docbook" - xmlns:xlink="http://www.w3.org/1999/xlink"> - <title>Nixpkgs Release Notes</title> - <section xml:id="release-notes-0.14"> - <title>Release 0.14 (June 4, 2012)</title> - - <para> - In preparation for the switch from Subversion to Git, this release is mainly the prevent the Nixpkgs version number from going backwards. (This would happen because prerelease version numbers produced for the Git repository are lower than those for the Subversion repository.) - </para> - - <para> - Since the last release, there have been thousands of changes and new packages by numerous contributors. For details, see the commit logs. - </para> - </section> - <section xml:id="release-notes-0.13"> - <title>Release 0.13 (February 5, 2010)</title> - - <para> - As always, there are many changes. Some of the most important updates are: - <itemizedlist> - <listitem> - <para> - Glibc 2.9. - </para> - </listitem> - <listitem> - <para> - GCC 4.3.3. - </para> - </listitem> - <listitem> - <para> - Linux 2.6.32. - </para> - </listitem> - <listitem> - <para> - X.org 7.5. - </para> - </listitem> - <listitem> - <para> - KDE 4.3.4. - </para> - </listitem> - </itemizedlist> - </para> - </section> - <section xml:id="release-notes-0.12"> - <title>Release 0.12 (April 24, 2009)</title> - - <para> - There are way too many additions to Nixpkgs since the last release to list here: for example, the number of packages on Linux has increased from 1002 to 2159. However, some specific improvements are worth listing: - <itemizedlist> - <listitem> - <para> - Nixpkgs now has a manual. In particular, it describes the standard build environment in detail. - </para> - </listitem> - <listitem> - <para> - Major new packages: - <itemizedlist> - <listitem> - <para> - KDE 4. - </para> - </listitem> - <listitem> - <para> - TeXLive. - </para> - </listitem> - <listitem> - <para> - VirtualBox. - </para> - </listitem> - </itemizedlist> - … and many others. - </para> - </listitem> - <listitem> - <para> - Important updates: - <itemizedlist> - <listitem> - <para> - Glibc 2.7. - </para> - </listitem> - <listitem> - <para> - GCC 4.2.4. - </para> - </listitem> - <listitem> - <para> - Linux 2.6.25 — 2.6.28. - </para> - </listitem> - <listitem> - <para> - Firefox 3. - </para> - </listitem> - <listitem> - <para> - X.org 7.3. - </para> - </listitem> - </itemizedlist> - </para> - </listitem> - <listitem> - <para> - Support for building derivations in a virtual machine, including RPM and Debian builds in automatically generated VM images. See <filename>pkgs/build-support/vm/default.nix</filename> for details. - </para> - </listitem> - <listitem> - <para> - Improved support for building Haskell packages. - </para> - </listitem> - </itemizedlist> - </para> - - <para> - The following people contributed to this release: Andres Löh, Arie Middelkoop, Armijn Hemel, Eelco Dolstra, Lluís Batlle, Ludovic Courtès, Marc Weber, Mart Kolthof, Martin Bravenboer, Michael Raskin, Nicolas Pierron, Peter Simons, Pjotr Prins, Rob Vermaas, Sander van der Burg, Tobias Hammerschmidt, Valentin David, Wouter den Breejen and Yury G. Kudryashov. In addition, several people contributed patches on the <literal>nix-dev</literal> mailing list. - </para> - </section> - <section xml:id="release-notes-0.11"> - <title>Release 0.11 (September 11, 2007)</title> - - <para> - This release has the following improvements: - <itemizedlist> - <listitem> - <para> - The standard build environment (<literal>stdenv</literal>) is now pure on the <literal>x86_64-linux</literal> and <literal>powerpc-linux</literal> platforms, just as on <literal>i686-linux</literal>. (Purity means that building and using the standard environment has no dependencies outside of the Nix store. For instance, it doesn’t require an external C compiler such as <filename>/usr/bin/gcc</filename>.) Also, the statically linked binaries used in the bootstrap process are now automatically reproducible, making it easy to update the bootstrap tools and to add support for other Linux platforms. See <filename>pkgs/stdenv/linux/make-bootstrap-tools.nix</filename> for details. - </para> - </listitem> - <listitem> - <para> - Hook variables in the generic builder are now executed using the <function>eval</function> shell command. This has a major advantage: you can write hooks directly in Nix expressions. For instance, rather than writing a builder like this: -<programlisting> -source $stdenv/setup - -postInstall=postInstall -postInstall() { - ln -sf gzip $out/bin/gunzip - ln -sf gzip $out/bin/zcat -} - -genericBuild</programlisting> - (the <literal>gzip</literal> builder), you can just add this attribute to the derivation: -<programlisting> -postInstall = "ln -sf gzip $out/bin/gunzip; ln -sf gzip $out/bin/zcat";</programlisting> - and so a separate build script becomes unnecessary. This should allow us to get rid of most builders in Nixpkgs. - </para> - </listitem> - <listitem> - <para> - It is now possible to have the generic builder pass arguments to <command>configure</command> and <command>make</command> that contain whitespace. Previously, for example, you could say in a builder, -<programlisting> -configureFlags="CFLAGS=-O0"</programlisting> - but not -<programlisting> -configureFlags="CFLAGS=-O0 -g"</programlisting> - since the <literal>-g</literal> would be interpreted as a separate argument to <command>configure</command>. Now you can say -<programlisting> -configureFlagsArray=("CFLAGS=-O0 -g")</programlisting> - or similarly -<programlisting> -configureFlagsArray=("CFLAGS=-O0 -g" "LDFLAGS=-L/foo -L/bar")</programlisting> - which does the right thing. Idem for <literal>makeFlags</literal>, <literal>installFlags</literal>, <literal>checkFlags</literal> and <literal>distFlags</literal>. - </para> - <para> - Unfortunately you can't pass arrays to Bash through the environment, so you can't put the array above in a Nix expression, e.g., -<programlisting> -configureFlagsArray = ["CFLAGS=-O0 -g"];</programlisting> - since it would just be flattened to a since string. However, you <emphasis>can</emphasis> use the inline hooks described above: -<programlisting> -preConfigure = "configureFlagsArray=(\"CFLAGS=-O0 -g\")";</programlisting> - </para> - </listitem> - <listitem> - <para> - 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"; - sha1 = "eb72f55e4a8bf08e8c6ef227c0ade3d068ba1082"; -}</programlisting> - <function>fetchurl</function> will first try to download this file from <link - xlink:href="http://tarballs.nixos.org/sha1/eb72f55e4a8bf08e8c6ef227c0ade3d068ba1082"/>. If that file doesn’t exist, it will try the original URL. In general, the “content-addressed” location is <replaceable>mirror</replaceable><literal>/</literal><replaceable>hash-type</replaceable><literal>/</literal><replaceable>hash</replaceable>. There is currently only one content-addressable mirror (<link - xlink:href="http://tarballs.nixos.org"/>), but more can be specified in the <varname>hashedMirrors</varname> attribute in <filename>pkgs/build-support/fetchurl/mirrors.nix</filename>, or by setting the <envar>NIX_HASHED_MIRRORS</envar> environment variable to a whitespace-separated list of URLs. - </para> - <para> - Second, <function>fetchurl</function> has support for widely-mirrored distribution sites such as SourceForge or the Linux kernel archives. Given a URL of the form <literal>mirror://<replaceable>site</replaceable>/<replaceable>path</replaceable></literal>, it will try to download <replaceable>path</replaceable> from a configurable list of mirrors for <replaceable>site</replaceable>. (This idea was borrowed from Gentoo Linux.) Example: -<programlisting> -fetchurl { - url = mirror://gnu/gcc/gcc-4.2.0/gcc-core-4.2.0.tar.bz2; - sha256 = "0ykhzxhr8857dr97z0j9wyybfz1kjr71xk457cfapfw5fjas4ny1"; -}</programlisting> - Currently <replaceable>site</replaceable> can be <literal>sourceforge</literal>, <literal>gnu</literal> and <literal>kernel</literal>. The list of mirrors is defined in <filename>pkgs/build-support/fetchurl/mirrors.nix</filename>. You can override the list of mirrors for a particular site by setting the environment variable <envar>NIX_MIRRORS_<replaceable>site</replaceable></envar>, e.g. -<programlisting> -export NIX_MIRRORS_sourceforge=http://osdn.dl.sourceforge.net/sourceforge/</programlisting> - </para> - </listitem> - <listitem> - <para> - Important updates: - <itemizedlist> - <listitem> - <para> - Glibc 2.5. - </para> - </listitem> - <listitem> - <para> - GCC 4.1.2. - </para> - </listitem> - <listitem> - <para> - Gnome 2.16.3. - </para> - </listitem> - <listitem> - <para> - X11R7.2. - </para> - </listitem> - <listitem> - <para> - Linux 2.6.21.7 and 2.6.22.6. - </para> - </listitem> - <listitem> - <para> - Emacs 22.1. - </para> - </listitem> - </itemizedlist> - </para> - </listitem> - <listitem> - <para> - Major new packages: - <itemizedlist> - <listitem> - <para> - KDE 3.5.6 Base. - </para> - </listitem> - <listitem> - <para> - Wine 0.9.43. - </para> - </listitem> - <listitem> - <para> - OpenOffice 2.2.1. - </para> - </listitem> - <listitem> - <para> - Many Linux system packages to support NixOS. - </para> - </listitem> - </itemizedlist> - </para> - </listitem> - </itemizedlist> - </para> - - <para> - The following people contributed to this release: Andres Löh, Arie Middelkoop, Armijn Hemel, Eelco Dolstra, Marc Weber, Mart Kolthof, Martin Bravenboer, Michael Raskin, Wouter den Breejen and Yury G. Kudryashov. - </para> - </section> - <section xml:id="release-notes-0.10"> - <title>Release 0.10 (October 12, 2006)</title> - - <note> - <para> - This release of Nixpkgs requires <link -xlink:href='https://nixos.org/releases/nix/nix-0.10/'>Nix 0.10</link> or higher. - </para> - </note> - - <para> - This release has the following improvements: - </para> - - <itemizedlist> - <listitem> - <para> - <filename>pkgs/system/all-packages-generic.nix</filename> is gone, we now just have <filename>pkgs/top-level/all-packages.nix</filename> that contains all available packages. This should cause much less confusion with users. <filename>all-packages.nix</filename> is a function that by default returns packages for the current platform, but you can override this by specifying a different <varname>system</varname> argument. - </para> - </listitem> - <listitem> - <para> - Certain packages in Nixpkgs are now user-configurable through a configuration file, i.e., without having to edit the Nix expressions in Nixpkgs. For instance, the Firefox provided in the Nixpkgs channel is built without the RealPlayer plugin (for legal reasons). Previously, you could easily enable RealPlayer support by editing the call to the Firefox function in <filename>all-packages.nix</filename>, but such changes are not respected when Firefox is subsequently updated through the Nixpkgs channel. - </para> - <para> - The Nixpkgs configuration file (found in <filename>~/.nixpkgs/config.nix</filename> or through the <envar>NIXPKGS_CONFIG</envar> environment variable) is an attribute set that contains configuration options that <filename>all-packages.nix</filename> reads and uses for certain packages. For instance, the following configuration file: -<programlisting> -{ - firefox = { - enableRealPlayer = true; - }; -}</programlisting> - persistently enables RealPlayer support in the Firefox build. - </para> - <para> - (Actually, <literal>firefox.enableRealPlayer</literal> is the <emphasis>only</emphasis> configuration option currently available, but more are sure to be added.) - </para> - </listitem> - <listitem> - <para> - Support for new platforms: - <itemizedlist> - <listitem> - <para> - <literal>i686-cygwin</literal>, i.e., Windows (using <link xlink:href="http://www.cygwin.com/">Cygwin</link>). The standard environment on <literal>i686-cygwin</literal> by default builds binaries for the Cygwin environment (i.e., it uses Cygwin tools and produces executables that use the Cygwin library). However, there is also a standard environment that produces binaries that use <link - xlink:href="http://www.mingw.org/">MinGW</link>. You can use it by calling <filename>all-package.nix</filename> with the <varname>stdenvType</varname> argument set to <literal>"i686-mingw"</literal>. - </para> - </listitem> - <listitem> - <para> - <literal>i686-darwin</literal>, i.e., Mac OS X on Intel CPUs. - </para> - </listitem> - <listitem> - <para> - <literal>powerpc-linux</literal>. - </para> - </listitem> - <listitem> - <para> - <literal>x86_64-linux</literal>, i.e., Linux on 64-bit AMD/Intel CPUs. Unlike <literal>i686-linux</literal>, this platform doesn’t have a pure <literal>stdenv</literal> yet. - </para> - </listitem> - </itemizedlist> - </para> - </listitem> - <listitem> - <para> - The default compiler is now GCC 4.1.1. - </para> - </listitem> - <listitem> - <para> - X11 updated to X.org’s X11R7.1. - </para> - </listitem> - <listitem> - <para> - Notable new packages: - <itemizedlist> - <listitem> - <para> - Opera. - </para> - </listitem> - <listitem> - <para> - Microsoft Visual C++ 2005 Express Edition and the Windows SDK. - </para> - </listitem> - </itemizedlist> - In total there are now around 809 packages in Nixpkgs. - </para> - </listitem> - <listitem> - <para> - It is now <emphasis>much</emphasis> easier to override the default C compiler and other tools in <literal>stdenv</literal> for specific packages. <filename>all-packages.nix</filename> provides two utility functions for this purpose: <function>overrideGCC</function> and <function>overrideInStdenv</function>. Both take a <literal>stdenv</literal> and return an augmented <literal>stdenv</literal>; the formed changes the C compiler, and the latter adds additional packages to the front of <literal>stdenv</literal>’s initial <envar>PATH</envar>, allowing tools to be overridden. - |