Skip to content

Commit

Permalink
Merge branch 'master' into staging
Browse files Browse the repository at this point in the history 
* master: (293 commits)
  go_1_9: skip flaky TestServerCancelsReadTimeoutWhenIdle
  qsyncthingtray: fix build
  qt56.qtwebengine: fix build
  stdman: d860212 -> 2017.04.02
  jackett: use mono50
  hg-git: disable with python3
  hg-git: 0.8.5 -> 0.8.10
  xfce4-settings: enable parallel building
  gcc-snapshot: mark as broken
  heaptrack: 2017-02-14 -> 2017-10-30
  nixos-container: Modify existing test to cover show-ip command
  nixos-container: Make show-ip work together with ipv4 + netmask
  linux-copperhead: 4.13.12.a -> 4.13.13.a
  matterbridge: 1.1.0 -> 1.4.1
  nixos/nghttpx: add module for the nghttpx proxy server (#31680)
  mattermost: 4.3.0 -> 4.4.0
  breakpad: delete
  simp_le: 0.2.0 -> 0.6.1
  certbot: 0.11.1 -> 0.19.0
  afl: 2.51b -> 2.52b
  ...
  • Loading branch information
@orivej
orivej committed Nov 17, 2017
2 parents 020a666 + 3ac474a commit d99a2fc
Show file tree
Hide file tree
Showing 349 changed files with 9,858 additions and 68,185 deletions.
3 changes: 3 additions & 0 deletions .github/CODEOWNERS
View file
Validating CODEOWNERS rules …
Expand Up @@ -80,3 +80,6 @@

# Eclipse
/pkgs/applications/editors/eclipse @rycee

# https://github.com/NixOS/nixpkgs/issues/31401
/lib/maintainers.nix @ghost
8 changes: 4 additions & 4 deletions .github/CONTRIBUTING.md
View file
Expand Up @@ -12,11 +12,11 @@ under the terms of [COPYING](../COPYING), which is an MIT-like license.

## Submitting changes

* Format the commits in the following way:
* Format the commit messages in the following way:

```
(pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc)
(Motivation for change. Additional information.)
```

Expand All @@ -25,10 +25,10 @@ under the terms of [COPYING](../COPYING), which is an MIT-like license.
* nginx: init at 2.0.1
* firefox: 54.0.1 -> 55.0
* nixos/hydra: add bazBaz option

Dual baz behavior is needed to do foo.
* nixos/nginx: refactor config generation

The old config generation system used impure shell scripts and could break in specific circumstances (see #1234).

* `meta.description` should:
Expand Down
6 changes: 2 additions & 4 deletions .github/ISSUE_TEMPLATE.md
View file
Expand Up @@ -8,7 +8,5 @@

## Technical details

* System: (NixOS: `nixos-version`, Ubuntu/Fedora: `lsb_release -a`, ...)
* Nix version: (run `nix-env --version`)
* Nixpkgs version: (run `nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion`)
* Sandboxing enabled: (run `grep build-use-sandbox /etc/nix/nix.conf`)
Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the
results.
35 changes: 0 additions & 35 deletions .travis.yml
View file

This file was deleted.

60 changes: 35 additions & 25 deletions doc/cross-compilation.xml
View file
Expand Up @@ -11,7 +11,7 @@
For example, a typical use of cross compilation is to compile programs for embedded devices.
These devices often don't have the computing power and memory to compile their own programs.
One might think that cross-compilation is a fairly niche concern, but there are advantages to being rigorous about distinguishing build-time vs run-time environments even when one is developing and deploying on the same machine.
Nixpkgs is increasingly adopting this opinion in that packages should be written with cross-compilation in mind, and nixpkgs should evaluate in a similar way (by minimizing cross-compilation-specific special cases) whether or not one is cross-compiling.
Nixpkgs is increasingly adopting the opinion that packages should be written with cross-compilation in mind, and nixpkgs should evaluate in a similar way (by minimizing cross-compilation-specific special cases) whether or not one is cross-compiling.
</para>

<para>
Expand All @@ -30,11 +30,11 @@
<section>
<title>Platform parameters</title>
<para>
The three GNU Autoconf platforms, <wordasword>build</wordasword>, <wordasword>host</wordasword>, and <wordasword>target</wordasword>, are historically the result of much confusion.
<link xlink:href="https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html" /> clears this up somewhat but there is more to be said.
An important advice to get out the way is, unless you are packaging a compiler or other build tool, just worry about the build and host platforms.
Dealing with just two platforms usually better matches people's preconceptions, and in this case is completely correct.
Nixpkgs follows the <link xlink:href="https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html">common historical convention of GNU autoconf</link> of distinguishing between 3 types of platform: <wordasword>build</wordasword>, <wordasword>host</wordasword>, and <wordasword>target</wordasword>.

In summary, <wordasword>build</wordasword> is the platform on which a package is being built, <wordasword>host</wordasword> is the platform on which it is to run. The third attribute, <wordasword>target</wordasword>, is relevant only for certain specific compilers and build tools.
</para>

<para>
In Nixpkgs, these three platforms are defined as attribute sets under the names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>, and <literal>targetPlatform</literal>.
All three are always defined as attributes in the standard environment, and at the top level. That means one can get at them just like a dependency in a function that is imported with <literal>callPackage</literal>:
Expand All @@ -52,30 +52,32 @@
<varlistentry>
<term><varname>hostPlatform</varname></term>
<listitem><para>
The "host platform" is the platform on which a package is run.
The "host platform" is the platform on which a package will be run.
This is the simplest platform to understand, but also the one with the worst name.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>targetPlatform</varname></term>
<listitem>
<para>
The "target platform" is black sheep.
The other two intrinsically apply to all compiled software—or any build process with a notion of "build-time" followed by "run-time".
The target platform only applies to programming tools, and even then only is a good for for some of them.
Briefly, GCC, Binutils, GHC, and certain other tools are written in such a way such that a single build can only compile code for a single platform.
Thus, when building them, one must think ahead about which platforms they wish to use the tool to produce machine code for, and build binaries for each.
The "target platform" attribute is, unlike the other two attributes, not actually fundamental to the process of building software.
Instead, it is only relevant for compatability with building certain specific compilers and build tools.
It can be safely ignored for all other packages.
</para>
<para>
The build process of certain compilers is written in such a way that the compiler resulting from a single build can itself only produce binaries for a single platform.
The task specifying this single "target platform" is thus pushed to build time of the compiler.
The root cause of this mistake is often that the compiler (which will be run on the host) and the the standard library/runtime (which will be run on the target) are built by a single build process.
</para>
<para>
There is no fundamental need to think about the target ahead of time like this.
LLVM, for example, was designed from the beginning with cross-compilation in mind, and so a normal LLVM binary will support every architecture that LLVM supports.
If the tool supports modular or pluggable backends, one might imagine specifying a <emphasis>set</emphasis> of target platforms / backends one wishes to support, rather than a single one.
There is no fundamental need to think about a single target ahead of time like this.
If the tool supports modular or pluggable backends, both the need to specify the target at build time and the constraint of having only a single target disappear.
An example of such a tool is LLVM.
</para>
<para>
The biggest reason for mess, if there is one, is that many compilers have the bad habit a build process that builds the compiler and standard library/runtime together.
Then the specifying target platform is essential, because it determines the host platform of the standard library/runtime.
Nixpkgs tries to avoid this where possible too, but still, because the concept of a target platform is so ingrained now in Autoconf and other tools, it is best to support it as is.
Tools like LLVM that don't need up-front target platforms can safely ignore it like normal packages, and it will do no harm.
Although the existance of a "target platfom" is arguably a historical mistake, it is a common one: examples of tools that suffer from it are GCC, Binutils, GHC and Autoconf.
Nixpkgs tries to avoid sharing in the mistake where possible.
Still, because the concept of a target platform is so ingrained, it is best to support it as is.
</para>
</listitem>
</varlistentry>
Expand Down Expand Up @@ -155,14 +157,22 @@
<section>
<title>Specifying Dependencies</title>
<para>
As mentioned in the introduction to this chapter, one can think about a build time vs run time distinction whether cross-compiling or not.
In the case of cross-compilation, this corresponds with whether a derivation running on the native or foreign platform is produced.
An interesting thing to think about is how this corresponds with the three Autoconf platforms.
In the run-time case, the depending and depended-on package simply have matching build, host, and target platforms.
But in the build-time case, one can imagine "sliding" the platforms one over.
The depended-on package's host and target platforms (respectively) become the depending package's build and host platforms.
This is the most important guiding principle behind cross-compilation with Nixpkgs, and will be called the <wordasword>sliding window principle</wordasword>.
In this section we explore the relationship between both runtime and buildtime dependencies and the 3 Autoconf platforms.
</para>
<para>
A runtime dependency between 2 packages implies that between them both the host and target platforms match.
This is directly implied by the meaning of "host platform" and "runtime dependency":
The package dependency exists while both packages are runnign on a single host platform.
</para>
<para>
A build time dependency, however, implies a shift in platforms between the depending package and the depended-on package.
The meaning of a build time dependency is that to build the depending package we need to be able to run the depended-on's package.
The depending package's build platform is therefore equal to the depended-on package's host platform.
Analogously, the depending package's host platform is equal to the depended-on package's target platform.
</para>
<para>
In this manner, given the 3 platforms for one package, we can determine the three platforms for all its transitive dependencies.
This is the most important guiding principle behind cross-compilation with Nixpkgs, and will be called the <wordasword>sliding window principle</wordasword>.
</para>
<para>
Some examples will probably make this clearer.
Expand Down
3 changes: 2 additions & 1 deletion doc/stdenv.xml
View file
Expand Up @@ -231,7 +231,8 @@ genericBuild
<listitem><para>
Like <varname>nativeBuildInputs</varname>, but these dependencies are <emphasis>propagated</emphasis>:
that is, the dependencies listed here are added to the <varname>nativeBuildInputs</varname> of any package that uses <emphasis>this</emphasis> package as a dependency.
So if package Y has <literal>propagatedBuildInputs = [X]</literal>, and package Z has <literal>buildInputs = [Y]</literal>, then package X will appear in Z’s build environment automatically.
So if package Y has <literal>propagatedNativeBuildInputs = [X]</literal>, and package Z has <literal>nativeBuildInputs = [Y]</literal>,
then package X will appear in Z’s build environment automatically.
</para></listitem>
</varlistentry>

Expand Down
7 changes: 6 additions & 1 deletion lib/maintainers.nix
View file
Expand Up @@ -62,7 +62,7 @@
asppsa = "Alastair Pharo <asppsa@gmail.com>";
astsmtl = "Alexander Tsamutali <astsmtl@yandex.ru>";
asymmetric = "Lorenzo Manacorda <lorenzo@mailbox.org>";
aszlig = "aszlig <aszlig@redmoonstudios.org>";
aszlig = "aszlig <aszlig@nix.build>";
auntie = "Jonathan Glines <auntieNeo@gmail.com>";
avnik = "Alexander V. Nikolaev <avn@avnik.info>";
aycanirican = "Aycan iRiCAN <iricanaycan@gmail.com>";
Expand Down Expand Up @@ -111,6 +111,7 @@
changlinli = "Changlin Li <mail@changlinli.com>";
chaoflow = "Florian Friesdorf <flo@chaoflow.net>";
chattered = "Phil Scott <me@philscotted.com>";
ChengCat = "Yucheng Zhang <yu@cheng.cat>";
choochootrain = "Hurshal Patel <hurshal@imap.cc>";
chpatrick = "Patrick Chilton <chpatrick@gmail.com>";
chris-martin = "Chris Martin <ch.martin@gmail.com>";
Expand Down Expand Up @@ -144,6 +145,7 @@
DamienCassou = "Damien Cassou <damien@cassou.me>";
danbst = "Danylo Hlynskyi <abcz2.uprola@gmail.com>";
dancek = "Hannu Hartikainen <hannu.hartikainen@gmail.com>";
danharaj = "Dan Haraj <dan@obsidian.systems>";
danielfullmer = "Daniel Fullmer <danielrf12@gmail.com>";
dasuxullebt = "Christoph-Simon Senjak <christoph.senjak@googlemail.com>";
david50407 = "David Kuo <me@davy.tw>";
Expand Down Expand Up @@ -218,6 +220,7 @@
falsifian = "James Cook <james.cook@utoronto.ca>";
fare = "Francois-Rene Rideau <fahree@gmail.com>";
fgaz = "Francesco Gazzetta <francygazz@gmail.com>";
FireyFly = "Jonas Höglund <nix@firefly.nu>";
flokli = "Florian Klink <flokli@flokli.de>";
florianjacob = "Florian Jacob <projects+nixos@florianjacob.de>";
flosse = "Markus Kohlhase <mail@markus-kohlhase.de>";
Expand Down Expand Up @@ -282,6 +285,7 @@
infinisil = "Silvan Mosberger <infinisil@icloud.com>";
ironpinguin = "Michele Catalano <michele@catalano.de>";
ivan-tkatchev = "Ivan Tkatchev <tkatchev@gmail.com>";
ixmatus = "Parnell Springmeyer <parnell@digitalmentat.com>";
j-keck = "Jürgen Keck <jhyphenkeck@gmail.com>";
jagajaga = "Arseniy Seroka <ars.seroka@gmail.com>";
jammerful = "jammerful <jammerful@gmail.com>";
Expand Down Expand Up @@ -325,6 +329,7 @@
kaiha = "Kai Harries <kai.harries@gmail.com>";
kamilchm = "Kamil Chmielewski <kamil.chm@gmail.com>";
kampfschlaefer = "Arnold Krille <arnold@arnoldarts.de>";
karolchmist = "karolchmist <info+nix@chmist.com>";
kentjames = "James Kent <jameschristopherkent@gmail.com";
kevincox = "Kevin Cox <kevincox@kevincox.ca>";
khumba = "Bryan Gardiner <bog@khumba.net>";
Expand Down
82 changes: 0 additions & 82 deletions maintainers/scripts/travis-nox-review-pr.sh
View file

This file was deleted.

22 changes: 20 additions & 2 deletions nixos/doc/manual/release-notes/rl-1803.xml
View file
Expand Up @@ -86,8 +86,26 @@ following incompatible changes:</para>
<itemizedlist>
<listitem>
<para>
ZNC option <option>services.znc.mutable</option> now defaults to <literal>true</literal>.
That means that old configuration is not overwritten by default when update to the znc options are made.
ZNC option <option>services.znc.mutable</option> now defaults to
<literal>true</literal>. That means that old configuration is not
overwritten by default when update to the znc options are made.
</para>
</listitem>
<listitem>
<para>
The option <option>networking.wireless.networks.&lt;name&gt;.auth</option>
has been added for wireless networks with WPA-Enterprise authentication.
There is also a new <option>extraConfig</option> option to directly
configure <literal>wpa_supplicant</literal> and <option>hidden</option>
to connect to hidden networks.
</para>
</listitem>
<listitem>
<para>
The option <option>services.xserver.desktopManager.default</option> is now <literal>none</literal> by default.
An assertion failure is thrown if WM's and DM's default are <literal>none</literal>.
To explicitly run a plain X session without and DM or WM, the newly introduced option <option>services.xserver.plainX</option>
must be set to true.
</para>
</listitem>
</itemizedlist>
Expand Down

0 comments on commit d99a2fc

Please sign in to comment.