Skip to content

Commit

Permalink
Merge remote-tracking branch 'upstream/master' into gcc-6
Browse files Browse the repository at this point in the history
  • Loading branch information
@globin
globin committed Jun 20, 2017
2 parents c1359ce + b6bacc4 commit 15f6dcb
Show file tree
Hide file tree
Showing 1,047 changed files with 28,398 additions and 16,879 deletions.
4 changes: 1 addition & 3 deletions .travis.yml
View file
Expand Up @@ -26,6 +26,4 @@ env:
- GITHUB_TOKEN=5edaaf1017f691ed34e7f80878f8f5fbd071603f

notifications:
email:
on_success: never
on_failure: change
email: false
2 changes: 1 addition & 1 deletion doc/configuration.xml
View file
Expand Up @@ -227,7 +227,7 @@ packages via <literal>packageOverrides</literal></title>

<para>You can define a function called
<varname>packageOverrides</varname> in your local
<filename>~/.config/nixpkgs/config.nix</filename> to overide nix packages. It
<filename>~/.config/nixpkgs/config.nix</filename> to override nix packages. It
must be a function that takes pkgs as an argument and return modified
set of packages.

Expand Down
2 changes: 1 addition & 1 deletion doc/functions.xml
View file
Expand Up @@ -70,7 +70,7 @@

<para>
In the above example, the <varname>separateDebugInfo</varname> attribute is
overriden to be true, thus building debug info for
overridden to be true, thus building debug info for
<varname>helloWithDebug</varname>, while all other attributes will be
retained from the original <varname>hello</varname> package.
</para>
Expand Down
22 changes: 22 additions & 0 deletions doc/languages-frameworks/python.md
View file
Expand Up @@ -923,6 +923,28 @@ If you need to change a package's attribute(s) from `configuration.nix` you coul

If you are using the `bepasty-server` package somewhere, for example in `systemPackages` or indirectly from `services.bepasty`, then a `nixos-rebuild switch` will rebuild the system but with the `bepasty-server` package using a different `src` attribute. This way one can modify `python` based software/libraries easily. Using `self` and `super` one can also alter dependencies (`buildInputs`) between the old state (`self`) and new state (`super`).

### How to override a Python package using overlays?

To alter a python package using overlays, you would use the following approach:

```nix
self: super:
rec {
python = super.python.override {
packageOverrides = python-self: python-super: {
bepasty-server = python-super.bepasty-server.overrideAttrs ( oldAttrs: {
src = self.pkgs.fetchgit {
url = "https://github.com/bepasty/bepasty-server";
sha256 = "9ziqshmsf0rjvdhhca55sm0x8jz76fsf2q4rwh4m6lpcf8wr0nps";
rev = "e2516e8cf4f2afb5185337073607eb9e84a61d2d";
};
});
};
};
pythonPackages = python.pkgs;
}
```

## Contributing

### Contributing guidelines
Expand Down
68 changes: 46 additions & 22 deletions doc/languages-frameworks/qt.xml
View file
Expand Up @@ -2,31 +2,55 @@
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:id="sec-language-qt">

<title>Qt and KDE</title>

<para>Qt is a comprehensive desktop and mobile application development toolkit for C++. Legacy support is available for Qt 3 and Qt 4, but all current development uses Qt 5. The Qt 5 packages in Nixpkgs are updated frequently to take advantage of new features, but older versions are typically retained to support packages that may not be compatible with the latest version. When packaging applications and libraries for Nixpkgs, it is important to ensure that compatible versions of Qt 5 are used throughout; this consideration motivates the tools described below.</para>

<section xml:id="ssec-qt-libraries"><title>Libraries</title>

<para>Libraries that depend on Qt 5 should be built with each available version to avoid linking a dependent package against incompatible versions of Qt 5. (Although Qt 5 maintains backward ABI compatibility, linking against multiple versions at once is generally not possible; at best it will lead to runtime faults.) Packages that provide libraries should be added to the top-level function <varname>mkLibsForQt5</varname>, which is used to build a set of libraries for every Qt 5 version. The <varname>callPackage</varname> provided in this scope will ensure that only one Qt version will be used throughout the dependency tree. Dependencies should be imported unqualified, i.e. <literal>qtbase</literal> not <literal>qt5.qtbase</literal>, so that <varname>callPackage</varname> can do its work. <emphasis>Do not</emphasis> import a package set such as <literal>qt5</literal> or <literal>libsForQt5</literal> into your package; although it may work fine in the moment, it could well break at the next Qt update.</para>

<para>If a library does not support a particular version of Qt 5, it is best to mark it as broken by setting its <literal>meta.broken</literal> attribute. A package may be marked broken for certain versions by testing the <literal>qtbase.version</literal> attribute, which will always give the current Qt 5 version.</para>
<title>Qt</title>

<para>
Qt is a comprehensive desktop and mobile application development toolkit for C++.
Legacy support is available for Qt 3 and Qt 4, but all current development uses Qt 5.
The Qt 5 packages in Nixpkgs are updated frequently to take advantage of new features,
but older versions are typically retained until their support window ends.
The most important consideration in packaging Qt-based software is ensuring that each package and all its dependencies use the same version of Qt 5;
this consideration motivates most of the tools described below.
</para>

<section xml:id="ssec-qt-libraries"><title>Packaging Libraries for Nixpkgs</title>

<para>
Whenever possible, libraries that use Qt 5 should be built with each available version.
Packages providing libraries should be added to the top-level function <varname>mkLibsForQt5</varname>,
which is used to build a set of libraries for every Qt 5 version.
A special <varname>callPackage</varname> function is used in this scope to ensure that the entire dependency tree uses the same Qt 5 version.
Import dependencies unqualified, i.e., <literal>qtbase</literal> not <literal>qt5.qtbase</literal>.
<emphasis>Do not</emphasis> import a package set such as <literal>qt5</literal> or <literal>libsForQt5</literal>.
</para>

<para>
If a library does not support a particular version of Qt 5, it is best to mark it as broken by setting its <literal>meta.broken</literal> attribute.
A package may be marked broken for certain versions by testing the <literal>qtbase.version</literal> attribute, which will always give the current Qt 5 version.
</para>

</section>

<section xml:id="ssec-qt-applications"><title>Applications</title>

<para>Applications generally do not need to be built with every Qt version because they do not provide any libraries for dependent packages to link against. The primary consideration is merely ensuring that the application itself and its dependencies are linked against only one version of Qt. To call your application expression, use <literal>libsForQt5.callPackage</literal> instead of <literal>callPackage</literal>. Dependencies should be imported unqualified, i.e. <literal>qtbase</literal> not <literal>qt5.qtbase</literal>. <emphasis>Do not</emphasis> import a package set such as <literal>qt5</literal> or <literal>libsForQt5</literal> into your package; although it may work fine in the moment, it could well break at the next Qt update.</para>

<para>It is generally best to build an application package against the <varname>libsForQt5</varname> library set. In case a package does not build with the latest Qt version, it is possible to pick a set pinned to a particular version, e.g. <varname>libsForQt55</varname> for Qt 5.5, if that is the latest version the package supports.</para>

<para>Qt-based applications require that several paths be set at runtime. This is accomplished by wrapping the provided executables in a package with <literal>wrapQtProgram</literal> or <literal>makeQtWrapper</literal> during the <literal>postFixup</literal> phase. To use the wrapper generators, add <literal>makeQtWrapper</literal> to <literal>nativeBuildInputs</literal>. The wrapper generators support the same options as <literal>wrapProgram</literal> and <literal>makeWrapper</literal> respectively. It is usually only necessary to generate wrappers for programs intended to be invoked by the user.</para>

</section>

<section xml:id="ssec-qt-kde"><title>KDE</title>

<para>The KDE Frameworks are a set of libraries for Qt 5 which form the basis of the Plasma desktop environment and the KDE Applications suite. Packaging a Frameworks-based library does not require any steps beyond those described above for general Qt-based libraries. Frameworks-based applications should not use <literal>makeQtWrapper</literal>; instead, use <literal>kdeWrapper</literal> to create the necessary wrappers: <literal>kdeWrapper { unwrapped = <replaceable>expr</replaceable>; targets = <replaceable>exes</replaceable>; }</literal>, where <replaceable>expr</replaceable> is the un-wrapped package expression and <replaceable>exes</replaceable> is a list of strings giving the relative paths to programs in the package which should be wrapped.</para>
<section xml:id="ssec-qt-applications"><title>Packaging Applications for Nixpkgs</title>

<para>
Call your application expression using <literal>libsForQt5.callPackage</literal> instead of <literal>callPackage</literal>.
Import dependencies unqualified, i.e., <literal>qtbase</literal> not <literal>qt5.qtbase</literal>.
<emphasis>Do not</emphasis> import a package set such as <literal>qt5</literal> or <literal>libsForQt5</literal>.
</para>

<para>
Qt 5 maintains strict backward compatibility, so it is generally best to build an application package against the latest version using the <varname>libsForQt5</varname> library set.
In case a package does not build with the latest Qt version, it is possible to pick a set pinned to a particular version, e.g. <varname>libsForQt55</varname> for Qt 5.5, if that is the latest version the package supports.
If a package must be pinned to an older Qt version, be sure to file a bug upstream;
because Qt is strictly backwards-compatible, any incompatibility is by definition a bug in the application.
</para>

<para>
When testing applications in Nixpkgs, it is a common practice to build the package with <literal>nix-build</literal> and run it using the created symbolic link.
This will not work with Qt applications, however, because they have many hard runtime requirements that can only be guaranteed if the package is actually installed.
To test a Qt application, install it with <literal>nix-env</literal> or run it inside <literal>nix-shell</literal>.
</para>

</section>

Expand Down
2 changes: 1 addition & 1 deletion doc/overlays.xml
View file
Expand Up @@ -78,7 +78,7 @@ self: super:
<para>The first argument, usually named <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 overriden dependencies used in the
from <varname>self</varname>, as well as the overridden dependencies used in the
<varname>boost</varname> override.</para>

<para>The second argument, usually named <varname>super</varname>,
Expand Down
136 changes: 136 additions & 0 deletions doc/package-notes.xml
View file
Expand Up @@ -516,4 +516,140 @@ to your configuration, rebuild, and run the game with

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

</section>

</section>

</chapter>
2 changes: 1 addition & 1 deletion doc/reviewing-contributions.xml
View file
Expand Up @@ -18,7 +18,7 @@
<para>The high change rate of nixpkgs make any pull request that is open for
long enough subject to conflicts that will require extra work from the
submitter or the merger. Reviewing pull requests in a timely manner and being
responsive to the comments is the key to avoid these. Github provides sort
responsive to the comments is the key to avoid these. GitHub provides sort
filters that can be used to see the <link
xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc">most
recently</link> and the <link
Expand Down
20 changes: 13 additions & 7 deletions doc/stdenv.xml
View file
Expand Up @@ -318,7 +318,13 @@ containing some shell commands to be executed, or by redefining the
shell function
<varname><replaceable>name</replaceable>Phase</varname>. The former
is convenient to override a phase from the derivation, while the
latter is convenient from a build script.</para>
latter is convenient from a build script.

However, typically one only wants to <emphasis>add</emphasis> some
commands to a phase, e.g. by defining <literal>postInstall</literal>
or <literal>preFixup</literal>, as skipping some of the default actions
may have unexpected consequences.
</para>


<section xml:id="ssec-controlling-phases"><title>Controlling
Expand Down Expand Up @@ -1156,15 +1162,15 @@ makeWrapper $out/bin/foo $wrapperfile --prefix PATH : ${lib.makeBinPath [ hello
<term><option>--replace</option>
<replaceable>s1</replaceable>
<replaceable>s2</replaceable></term>
<listitem><para>Replace every occurence of the string
<listitem><para>Replace every occurrence of the string
<replaceable>s1</replaceable> by
<replaceable>s2</replaceable>.</para></listitem>
</varlistentry>

<varlistentry>
<term><option>--subst-var</option>
<replaceable>varName</replaceable></term>
<listitem><para>Replace every occurence of
<listitem><para>Replace every occurrence of
<literal>@<replaceable>varName</replaceable>@</literal> by
the contents of the environment variable
<replaceable>varName</replaceable>. This is useful for
Expand All @@ -1177,7 +1183,7 @@ makeWrapper $out/bin/foo $wrapperfile --prefix PATH : ${lib.makeBinPath [ hello
<term><option>--subst-var-by</option>
<replaceable>varName</replaceable>
<replaceable>s</replaceable></term>
<listitem><para>Replace every occurence of
<listitem><para>Replace every occurrence of
<literal>@<replaceable>varName</replaceable>@</literal> by
the string <replaceable>s</replaceable>.</para></listitem>
</varlistentry>
Expand Down Expand Up @@ -1225,7 +1231,7 @@ substitute ./foo.in ./foo.out \
<term><function>substituteAll</function>
<replaceable>infile</replaceable>
<replaceable>outfile</replaceable></term>
<listitem><para>Replaces every occurence of
<listitem><para>Replaces every occurrence of
<literal>@<replaceable>varName</replaceable>@</literal>, where
<replaceable>varName</replaceable> is any environment variable, in
<replaceable>infile</replaceable>, writing the result to
Expand Down Expand Up @@ -1528,7 +1534,7 @@ bin/blib.a(bios_console.o): In function `bios_handle_cup':
depends on such a format string, it will need to be worked around.
</para>

<para>Addtionally, some warnings are enabled which might trigger build
<para>Additionally, some warnings are enabled which might trigger build
failures if compiler warnings are treated as errors in the package build.
In this case, set <option>NIX_CFLAGS_COMPILE</option> to
<option>-Wno-error=warning-type</option>.</para>
Expand Down Expand Up @@ -1558,7 +1564,7 @@ fcntl2.h:50:4: error: call to '__open_missing_mode' declared with attribute erro
<term><varname>pic</varname></term>
<listitem>
<para>Adds the <option>-fPIC</option> compiler options. This options adds
support for position independant code in shared libraries and thus making
support for position independent code in shared libraries and thus making
ASLR possible.</para>
<para>Most notably, the Linux kernel, kernel modules and other code
not running in an operating system environment like boot loaders won't
Expand Down
5 changes: 5 additions & 0 deletions lib/licenses.nix
View file
Expand Up @@ -45,6 +45,11 @@ lib.mapAttrs (n: v: v // { shortName = n; }) rec {
fullName = "Apple Public Source License 2.0";
};

arphicpl = {
fullName = "Arphic Public License";
url = https://www.freedesktop.org/wiki/Arphic_Public_License/;
};

artistic1 = spdx {
spdxId = "Artistic-1.0";
fullName = "Artistic License 1.0";
Expand Down

0 comments on commit 15f6dcb

Please sign in to comment.