Age | Commit message (Collapse) | Author |
|
Doc for Platform Normalization
|
|
Worthwhile to do now that #24610 makes it less abysmal.
|
|
|
|
|
|
It was not updated with 9d6a55aefd7.
|
|
fixes #23621
|
|
|
|
* Update python.md
this makes it clear how to alter `attributes` by using `packageOverrides`
* Update python.md
* Update python.md
* Update python.md
* Update python.md
* Update python.md
* Update python.md
|
|
|
|
This reverts commit 6393d433803f84e02cc340645481dcd85231083b.
Commit added too much changes.
|
|
|
|
|
|
* Strip the unnecessary 'pkgs' attribute.
* Remove ghc-7.6.3 as a GHC supporting integer-simple.
|
|
Fix code syntax highlighting by specifying language in every code block
and adding some context to Nix code blocks to make them valid
expressions. Use the same markup style for all code blocks. Reformat
some code blocks.
fixes #23535
|
|
|
|
|
|
- Describe the new `libsForQt5.callPackage` interface
- Emphasize that Qt dependencies must be imported unqualified
- Describe the new `kdeWrapper` wrapper generator
|
|
|
|
|
|
If a package's meta has `knownVulnerabilities`, like so:
stdenv.mkDerivation {
name = "foobar-1.2.3";
...
meta.knownVulnerabilities = [
"CVE-0000-00000: remote code execution"
"CVE-0000-00001: local privilege escalation"
];
}
and a user attempts to install the package, they will be greeted with
a warning indicating that maybe they don't want to install it:
error: Package ‘foobar-1.2.3’ in ‘...default.nix:20’ is marked as insecure, refusing to evaluate.
Known issues:
- CVE-0000-00000: remote code execution
- CVE-0000-00001: local privilege escalation
You can install it anyway by whitelisting this package, using the
following methods:
a) for `nixos-rebuild` you can add ‘foobar-1.2.3’ to
`nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
like so:
{
nixpkgs.config.permittedInsecurePackages = [
"foobar-1.2.3"
];
}
b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
‘foobar-1.2.3’ to `permittedInsecurePackages` in
~/.config/nixpkgs/config.nix, like so:
{
permittedInsecurePackages = [
"foobar-1.2.3"
];
}
Adding either of these configurations will permit this specific
version to be installed. A third option also exists:
NIXPKGS_ALLOW_INSECURE=1 nix-build ...
though I specifically avoided having a global file-based toggle to
disable this check. This way, users don't disable it once in order to
get a single package, and then don't realize future packages are
insecure.
|
|
|
|
|
|
I ran into some issues making HTTPS requests from a container built with buildImage. I've added notes with tips for resolving similar issues.
|
|
|
|
This is instead of both system and platform, which is kind of ugly.
|
|
cross stdenv: let build package's build deps resolve to native packages
|
|
This fixes the "sliding window" principle:
0. Run packages: build = native; host = foreign; target = foreign;
1. Build packages: build = native; host = native; target = foreign;
2. Vanilla packages: build = native; host = native; target = native;
3. Vanilla packages: build = native; host = native; target = native;
n+3. ...
Each stage's build dependencies are resolved against the previous stage,
and the "foreigns" are shifted accordingly. Vanilla packages alone are
built against themsevles, since there are no more "foreign"s to shift away.
Before, build packages' build dependencies were resolved against
themselves:
0. Run packages: build = native; host = foreign; target = foreign;
1. Build packages: build = native; host = native; target = foreign;
2. Build packages: build = native; host = native; target = foreign;
n+2. ...
This is wrong because that principle is violated by the target
platform staying foreign.
This will change the hashes of many build packages and run packages, but
that is OK. This is an unavoidable cost of fixing cross compiling.
The cross compilation docs have been updated to reflect this fix.
|
|
|
|
|
|
If the flag enableIntegerSimple is true GHC will be build with the GPL-free but
slower integer-simple library instead of the faster but GPLed integer-gmp
library.
The attribute `pkgs.haskell.compiler.integer-simple."${ghcVersion}"` provides a
GHC compiler build with `integer-simple`.
Similarly, the attribute `pkgs.haskell.packages.integer-simple."${ghcVersion}"`
provides a package set supporting `integer-simple`.
Closes https://github.com/NixOS/nixpkgs/pull/22121.
Closes https://github.com/NixOS/nixpkgs/issues/5493.
|
|
|
|
The former is still respected as a fallback for config.nix for
backwards compatibility (but not for overlays because they're a new
feature).
|
|
The Nix search path is the established mechanism for specifying the
location of Nix expressions, so let's use it instead of adding another
environment variable.
|
|
|
|
|
|
Prepend "bad/better/best" to each paragraph, to make more visible which approach is best
|
|
Bye bye MD5
|
|
|
|
Do so in the stdenv section where the other two are discussed. This can be
done without brining up cross-compilation by talking about build-time vs
run-time.
|
|
|
|
Fixes #18887.
|
|
bundleEnv: Used gemdir for most applications now
|
|
Azulinho/python-docs_add_virtualenv_and_nixshell_example
python docs: add an example for a virtualenv and pip through nix-shell
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This patch add a new argument to Nixpkgs default expression named "overlays".
By default, the value of the argument is either taken from the environment variable `NIXPKGS_OVERLAYS`,
or from the directory `~/.nixpkgs/overlays/`. If the environment variable does not name a valid directory
then this mechanism would fallback on the home directory. If the home directory does not exists it will
fallback on an empty list of overlays.
The overlays directory should contain the list of extra Nixpkgs stages which would be used to extend the
content of Nixpkgs, with additional set of packages. The overlays, i-e directory, files, symbolic links
are used in alphabetical order.
The simplest overlay which extends Nixpkgs with nothing looks like:
```nix
self: super: {
}
```
More refined overlays can use `super` as the basis for building new packages, and `self` as a way to query
the final result of the fix-point.
An example of overlay which extends Nixpkgs with a small set of packages can be found at:
https://github.com/nbp/nixpkgs-mozilla/blob/nixpkgs-overlay/moz-overlay.nix
To use this file, checkout the repository and add a symbolic link to
the `moz-overlay.nix` file in `~/.nixpkgs/overlays` directory.
|