Only includes a small fix for the login into the Robot Web interface,
which is used to eg. provide access to admin accounts (which in turn is
used by the NixOps Hetzner backend).
Signed-off-by: aszlig <aszlig@nix.build>
(cherry picked from commit 56009d4a8d)
If our old Nix can’t evaluate the Nixpkgs channel, try the fallback
from the new channel /first/. That way we can upgrade Nix to a newer
version and support breaking changes to Nix (like seen in the upgrade
o Nix 2.0).
This change should be backported to older NixOS versions!
(cherry picked from commit 475c8aa018)
grpcio currently does not build on Darwin (10.13.6). Due to the
following issues:
* ar is invoked with incorrect flags (#33765).
* libtool cannot be found, with a libtool dependency, with libtool
the option '-no_warning_for_no_symbols' is not recognized.
* the module build cannot find boringssl that is packaged with
python-grpcio when pkgconfig is not installed (grpc/#10058).
(cherry picked from commit 4beb94d6d6)
Fixes CVE-2018-10933:
libssh versions 0.6 and above have an authentication bypass
vulnerability in the server code. By presenting the server an
SSH2_MSG_USERAUTH_SUCCESS message in place of the
SSH2_MSG_USERAUTH_REQUEST message which the server would expect to
initiate authentication, the attacker could successfully authentciate
without any credentials.
Source:
https://www.libssh.org/2018/10/16/libssh-0-8-4-and-0-7-6-security-and-bugfix-release/
(cherry picked from commit eca462813d)
This release adds support for building with cmake!
So switch to that eagerly instead of fighting with bam.
(if nothing else cmake is the devil we know...)
Also:
* fixup 'DATA_DIR' so programs can find resources
(without need for wrappers)
* install readme+license as previously done ("docs")
* don't install tools since not built or installed by default
* esp since doesn't appear to have non-adhoc method for installation
* other distros don't seem to include
(cherry picked from commit 18258bae34)
Fixes CVE-2018-18541.
Semi-automatic update. These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 1.4.15 with grep in /nix/store/7nifpbj16dlhljb2jwbwxyv4wx1zwa1y-mosquitto-1.4.15
- found 1.4.15 in filename of file in /nix/store/7nifpbj16dlhljb2jwbwxyv4wx1zwa1y-mosquitto-1.4.15
(cherry picked from commit a28a2e3829)
Upstream changelog:
- SECURITY UPDATE: In previous versions of libfuse it was possible to
for unprivileged users to specify the allow_other option even when
this was forbidden in /etc/fuse.conf. The vulnerability is present
only on systems where SELinux is active (including in permissive
mode).
- libfuse no longer segfaults when fuse_interrupted() is called outside
the event loop.
- The fusermount binary has been hardened in several ways to reduce
potential attack surface. Most importantly, mountpoints and mount
options must now match a hard-coded whitelist. It is expected that
this whitelist covers all regular use-cases.
- Fixed rename deadlock on FreeBSD.
(cherry picked from commit ec1082c58f)
Upstream changelog:
- SECURITY UPDATE: In previous versions of libfuse it was possible to
for unprivileged users to specify the allow_other option even when
this was forbidden in /etc/fuse.conf. The vulnerability is present
only on systems where SELinux is active (including in permissive
mode).
- The fusermount binary has been hardened in several ways to reduce
potential attack surface. Most importantly, mountpoints and mount
options must now match a hard-coded whitelist. It is expected that
this whitelist covers all regular use-cases.
- Added a test of seekdir to test_syscalls.
- Fixed readdir bug when non-zero offsets are given to filler and the
filesystem client, after reading a whole directory, re-reads it from a
non-zero offset e. g. by calling seekdir followed by readdir.
(cherry picked from commit 46cd782b43)
Stop using bin/mount.fuse from fuse3 for fuse2 (mount.fuse from fuse3
isn't guaranteed to remain backwards compatible).
(cherry picked from commit c00b5bf6a2)
[18.03] Backport Signal-Desktop
Reason: Signal-Desktop displayed the following message: "This version of
Signal Desktop has expired. Please upgrade to the latest version to
continue messaging." (see #48436).
Skipped 1.15.1 due to upstream issues (see GitHub), 1.15.2 and 1.15.3
should be fine (at least there are fewer issues).
(cherry picked from commit c7e04336a7)
Thought this could be useful for others as well. Unfortunately it will
also override the UI language.
Example usage:
environment.systemPackages = with pkgs; [
(signal-desktop.override {
spellcheckerLanguage = "de_DE";
})
];
(cherry picked from commit 9ef1406a99)
snapshot.debian.org actually keeps track of all of the updates as they
come in rather than doing arbitrary (?) snapshots.
(cherry picked from commit 9cc18fa7f9)
This is a sort port of 4d6f880 (#43811). The mentioned issues are not
being fixed in the release. The CPU release should be used instead.
Since someone might still need the PSU version it will just be marked as
insecure allowing the user to whitelist it, if required.
Highlights in this release include:
This release fixes problems with argument handling, some unintended results of the security fixes to the SAFER file access restrictions (specifically accessing ICC profile files), and some additional security issues over the recent 9.24 release.
CVE-2018-16802
CVE-2018-17183
Note: The ps2epsi utility does not, and cannot call Ghostscript with the -dSAFER command line option. It should never be called with input from untrusted sources.
Security issues have been the primary focus of this release, including solving several (well publicised) real and potential exploits.
PLEASE NOTE: We strongly urge users to upgrade to this latest release to avoid these issues.
As well as Ghostscript itself, jbig2dec has had a significant amount of work improving its robustness in the face of out specification files.
IMPORTANT: We are in the process of forking LittleCMS. LCMS2 is not thread safe, and cannot be made thread safe without breaking the ABI. Our fork will be thread safe, and include performance enhancements (these changes have all be been offered and rejected upstream). We will maintain compatibility between Ghostscript and LCMS2 for a time, but not in perpetuity. Our fork will be available as its own package separately from Ghostscript (and MuPDF).
The usual round of bug fixes, compatibility changes, and incremental improvements.
(cherry picked from commit 5b77b0d2f1)
(cherry picked from commit dbcbf7cce8)
(cherry picked from commit 4f519e5dc8)
Reason: Security update: "The pam_fscrypt module in fscrypt before 0.2.4
may incorrectly restore primary and supplementary group IDs to the
values associated with the root user, which allows attackers to gain
privileges via a successful login through certain applications that use
Linux-PAM (aka pam)."
(cherry picked from commit 18b468ed81)
Reason: Security update: "Depend on new version of gollum-lib that
relies on a patched version of sanitize, which solves a vulnerability
(CVE-2018-3740). See https://github.com/gollum/gollum-lib/pull/296."
This is a port of the current state of thunderbird from the master
branch. We did miss a bunch of security fixes when thunderbird 60 was
released. This is an attempt to take a shortcut by simply copying over
the expression from the master branch.
Security related fixes in this release are:
- CVE-2018-12359: Buffer overflow using computed size of canvas element
A buffer overflow can occur when rendering canvas content while
adjusting the height and width of the <canvas> element dynamically,
causing data to be written outside of the currently computed
boundaries. This results in a potentially exploitable crash.
- CVE-2018-12360: Use-after-free when using focus()
A use-after-free vulnerability can occur when deleting an input
element during a mutation event handler triggered by focusing that
element. This results in a potentially exploitable crash.
- CVE-2018-12361: Integer overflow in SwizzleData
An integer overflow can occur in the SwizzleData code while
calculating buffer sizes. The overflowed value is used for subsequent
graphics computations when their inputs are not sanitized which
results in a potentially exploitable crash.
- CVE-2018-12362: Integer overflow in SSSE3 scaler
An integer overflow can occur during graphics operations done by the
Supplemental Streaming SIMD Extensions 3 (SSSE3) scaler, resulting in
a potentially exploitable crash.
- CVE-2018-5156: Media recorder segmentation fault when track type is changed during capture
A vulnerability can occur when capturing a media stream when the media
source type is changed as the capture is occuring. This can result in
stream data being cast to the wrong type causing a potentially
exploitable crash.
- CVE-2018-12363: Use-after-free when appending DOM nodes
A use-after-free vulnerability can occur when script uses mutation
events to move DOM nodes between documents, resulting in the old
document that held the node being freed but the node still having a
pointer referencing it. This results in a potentially exploitable
crash.
- CVE-2018-12364: CSRF attacks through 307 redirects and NPAPI plugins
NPAPI plugins, such as Adobe Flash, can send non-simple cross-origin
requests, bypassing CORS by making a same-origin POST that does a 307
redirect to the target site. This allows for a malicious site to
engage in cross-site request forgery (CSRF) attacks.
- CVE-2018-12365: Compromised IPC child process can list local filenames
A compromised IPC child process can escape the content sandbox and
list the names of arbitrary files on the file system without user
consent or interaction. This could result in exposure of private local
files.
- CVE-2018-12371: Integer overflow in Skia library during edge builder allocation
An integer overflow vulnerability in the Skia library when allocating
memory for edge builders on some systems with at least 16 GB of RAM.
This results in the use of uninitialized memory, resulting in a
potentially exploitable crash.
- CVE-2018-12366: Invalid data handling during QCMS transformations
An invalid grid size during QCMS (color profile) transformations can
result in the out-of-bounds read interpreted as a float value. This
could leak private data into the output.
- CVE-2018-12367: Timing attack mitigation of PerformanceNavigationTiming
In the previous mitigations for Spectre, the resolution or precision
of various methods was reduced to counteract the ability to measure
precise time intervals. In that work, PerformanceNavigationTiming was
not adjusted but it was found that it could be used as a precision
timer.
- CVE-2018-5187: Memory safety bugs fixed in Firefox 61, Firefox ESR 60.1, and Thunderbird 60
Mozilla developers and community members Christian Holler, Sebastian
Hengst, Nils Ohlmeier, Jon Coppeard, Randell Jesup, Ted Campbell, Gary
Kwong, and Jean-Yves Avenard reported memory safety bugs present in
Firefox 60 and Firefox ESR 60. Some of these bugs showed evidence of
memory corruption and we presume that with enough effort that some of
these could be exploited to run arbitrary code.
- CVE-2018-5188: Memory safety bugs fixed in Firefox 61, Firefox ESR 60.1, Firefox ESR 52.9, and Thunderbird 60
Mozilla developers and community members Alex Gaynor, Christoph Diehl,
Christian Holler, Jason Kratzer, David Major, Jon Coppeard, Nicolas B.
Pierron, Jason Kratzer, Marcia Knous, and Ronald Crane reported memory
safety bugs present in Firefox 60, Firefox ESR 60, and Firefox ESR
52.8. Some of these bugs showed evidence of memory corruption and we
presume that with enough effort that some of these could be exploited
to run arbitrary code.
This update bumps the package to the latest stable version containing a
few security fixes:
- CVE-2018-12386: Type confusion in JavaScript
A vulnerability in register allocation in JavaScript can lead to type
confusion, allowing for an arbitrary read and write. This leads to
remote code execution inside the sandboxed content process when
triggered.
- CVE-2018-12387
A vulnerability where the JavaScript JIT compiler inlines
Array.prototype.push with multiple arguments that results in the stack
pointer being off by 8 bytes after a bailout. This leaks a memory
address to the calling function which can be used as part of an
exploit inside the sandboxed content process.
Source: https://www.mozilla.org/en-US/security/advisories/mfsa2018-24/
(cherry picked from commit 246d2848ff)
This update bumps the package to the latest stable version containing a
few security fixes:
- CVE-2018-12386: Type confusion in JavaScript
A vulnerability in register allocation in JavaScript can lead to type
confusion, allowing for an arbitrary read and write. This leads to
remote code execution inside the sandboxed content process when
triggered.
- CVE-2018-12387
A vulnerability where the JavaScript JIT compiler inlines
Array.prototype.push with multiple arguments that results in the stack
pointer being off by 8 bytes after a bailout. This leaks a memory
address to the calling function which can be used as part of an
exploit inside the sandboxed content process.
Source: https://www.mozilla.org/en-US/security/advisories/mfsa2018-24/
(cherry picked from commit e7785f1148)
This update bumps the package to the latest stable version containing a
few security fixes:
- CVE-2018-12386: Type confusion in JavaScript
A vulnerability in register allocation in JavaScript can lead to type
confusion, allowing for an arbitrary read and write. This leads to
remote code execution inside the sandboxed content process when
triggered.
- CVE-2018-12387
A vulnerability where the JavaScript JIT compiler inlines
Array.prototype.push with multiple arguments that results in the stack
pointer being off by 8 bytes after a bailout. This leaks a memory
address to the calling function which can be used as part of an
exploit inside the sandboxed content process.
Source: https://www.mozilla.org/en-US/security/advisories/mfsa2018-24/
(cherry picked from commit 64d02660cb)
darwin.security_tool is currently broken in Mojave. See issue #45042
for more info. Our security_tool stuff comes from 10.9 so I suspect
that it needs an update.
Here I am putting in a hack to get things working again. This uses the
system provided security binary at /usr/bin/security to avoid the
issue in Haskell’s x509-system package. Unfortunately, this will break
with the sandbox. I am also working on a proper fix, but this requires
updating lots of Apple stuff (and also copumpkin’s new CF). You can
follow the progress on this branch:
https://github.com/matthewbauer/nixpkgs/tree/xcode-security
This commit should be backported to release-18.03 and release-18.09.
/cc @copumpkin @lnl7 @pikajude
PHP tries to discover the mysql default socket path during configure
phase by probing the file system:
cf3b852109/ext/mysqli/config.m4 (L4)
This obviously fails to discover /run/mysqld/mysqld.sock, which is being
used (hardcoded) across all MySQL flavours.
This leads to PHP having no mysql socket path set for the mysql[i]
extensions, and `/tmp/mysql.sock` set for pdo_mysql,
meaning one currently has to manually configure and set it in php.ini.
Luckily, PHP supports setting that path via
`--with-mysql-sock=/run/mysqld/mysqld.sock` during configure phase,
so let's do this as soon as one of the three modules is enabled.
(cherry picked from commit baa04e4204)
A lot of the functionality of the z3 library depends on it being able to
find the z3 executable on $PATH. Hard-coding it here means it will never
be unable to find it and z3 doesn't need to pollute $PATH.
(cherry picked from commit c8598daad4)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/bitcoin/versions.
These checks were done:
- built on NixOS
- /nix/store/5fjv944ikyak1s83624ay8i9h4gbs2c0-bitcoin-0.16.1/bin/bitcoind passed the binary check.
- /nix/store/5fjv944ikyak1s83624ay8i9h4gbs2c0-bitcoin-0.16.1/bin/bitcoin-cli passed the binary check.
- /nix/store/5fjv944ikyak1s83624ay8i9h4gbs2c0-bitcoin-0.16.1/bin/bitcoin-tx passed the binary check.
- /nix/store/5fjv944ikyak1s83624ay8i9h4gbs2c0-bitcoin-0.16.1/bin/test_bitcoin passed the binary check.
- /nix/store/5fjv944ikyak1s83624ay8i9h4gbs2c0-bitcoin-0.16.1/bin/bench_bitcoin passed the binary check.
- Warning: no invocation of /nix/store/5fjv944ikyak1s83624ay8i9h4gbs2c0-bitcoin-0.16.1/bin/bitcoin-qt had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/5fjv944ikyak1s83624ay8i9h4gbs2c0-bitcoin-0.16.1/bin/test_bitcoin-qt had a zero exit code or showed the expected version
- 5 of 7 passed binary check by having a zero exit code.
- 0 of 7 passed binary check by having the new version present in output.
- found 0.16.1 with grep in /nix/store/5fjv944ikyak1s83624ay8i9h4gbs2c0-bitcoin-0.16.1
- directory tree listing: https://gist.github.com/a5e5d745910497ae913d4577342deba5
- du listing: https://gist.github.com/5f62bec50f6ab977a25c8ee0f118cb10
(cherry picked from commit 77f3ac7b76)
This is only a minor bugfix release and updates the fallback CA root
certificates. For NixOS this is usually not required as the probe paths
will match there, but for non-NixOS users it might be helpful.
Signed-off-by: aszlig <aszlig@nix.build>
(cherry picked from commit 48d1c50f7a)
Reason: This might be relevant for NixOps users on Mac OS X and the
update won't break anything that wasn't broken before.
The upstream src URL for the patch appears to no longer exist. Per discussion in
https://github.com/NixOS/nixpkgs/issues/39927, the upstream URL is not stable,
so this commit inlines the patch in the nixpkgs src tree.
(cherry picked from commit 17f50018c0)
As backported in Ubuntu. On unstable the issue is solved by #45916.
I couldn't find their source repo working with current data,
even that salsa.debian.org, so I copied the patch from their tarball.
this fixes a series of potential security issues:
CVE-2018-2940, CVE-2018-2941, CVE-2018-2952, CVE-2018-2964,
CVE-2018-2972 & CVE-2018-2973
(cherry picked from commit f9788aa118)
When creating a new mobile broadband connection
with the plasma network manager connection editor,
it tries to find a file containing provider
information somewhere in /usr/share/... .
The build recipe contains a patch to fix the lookup path
such that it finds the file in the corresponding package,
probably added due to
https://github.com/NixOS/nixpkgs/issues/9389 .
The actual lookup path is injected into
the patch file with substituteAll.
With commit a31d98f312 ,
the variable name used in subsituteAll changed from
mobile_broadband_provider_info to mobile-broadband-provider-info
(underscores in package names turned into dashes).
Apparently, substituteAll can't handle dashes in variable names.
Consequently, the variable name was no longer resolved.
plasma-nm failed to create new mobile broadband connections;
the connection creator silently exited and logged the error
> plasma-nm: Error opening providers file "@mobile-broadband-provider-info@/share/mobile-broadband-provider-info/serviceproviders.xml"
This commit keeps the dashes in package names, but it
restores the underscores in the variable used by substituteAll,
thereby ensuring the variable gets resolved properly.
(cherry picked from commit bdf6f8528e)
This requires some minor hoop-hopping because it's involved in the
Linux bootstrap, but it's nothing too complicated.
Fixes#43289
(cherry picked from commit a5b5536e2a)
mke2fs has this annoying property that it uses getrandom() to get random
numbers (for whatever purposes) which blocks until the kernel's secure
RNG has sufficient entropy, which it usually doesn't in the early boot
(except if your CPU supports RDRAND) where we may need to create the
root disk.
So let's give the VM a virtio RNG to avoid the boot getting stuck at
mke2fs.
(cherry picked from commit dda74d9e50)
Bump to latest stable version of the 10.2.x branch. Besides many bug fixes the
following security related issues have been fixed:
- CVE-2018-3060
- CVE-2018-3064
- CVE-2018-3063
- CVE-2018-3058
- CVE-2018-3066
(probably more from before 10.2.16)
Release notes: https://mariadb.com/kb/en/library/mariadb-10217-release-notes/
(cherry picked from commit 6c3d99c7645f7c7f8331c1c7ff7453bfaeb21cc2)
This has been reported by @qknight in his Stack Overflow question:
https://stackoverflow.com/q/50678639
The correct way to override a single value would be to use something
like this:
systemd.services.nagios.serviceConfig.Restart = lib.mkForce "no";
However, this doesn't work because the check is applied for the attrsOf
type and thus the attribute values might still contain the attribute set
created by mkOverride.
The unitOption type however did already account for this, but at this
stage it's already too late.
So now the actual value is unpacked while checking the values of the
attribute set, which should allow us to override values in
serviceConfig.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra, @qknight
(cherry picked from commit 0e7c945e15)
Reason: Another user has hit this problem on Discourse[1] and I thought
I had already backported it to 18.03, apparently I didn't. Given
the time of the original commit I think this had enough testing
already so it shouldn't break anything and rather make things
less annoying.
[1]: https://discourse.nixos.org/t/is-there-a-universal-way-to-enable-a-service-auto-restart/592/3
this addresses:
- Client DoS due to large DH parameter (CVE-2018-0732)
- Cache timing vulnerability in RSA Key Generation (CVE-2018-0737)
Changelog: https://www.openssl.org/news/changelog.html#x1
(cherry picked from commit 0a40875439)
this addresses:
- Client DoS due to large DH parameter (CVE-2018-0732)
- Cache timing vulnerability in RSA Key Generation (CVE-2018-0737)
Changelog: https://www.openssl.org/news/cl102.txt
(cherry picked from commit 98a7b92261)
Unlike on linux these are not namespaced per user so this will cause
build failures if /tmp/nix-test was not removed by a previous build if
the nixbld user id doesn't match by accident. Nix already creates a
unique tempdir for builds so we can use that instead.
Fixes#44172
(cherry picked from commit 77a9745d7a)
We are patching GDM to respect GDM_SESSIONS_DIR environment
variable, which we are setting in the GDM module. Previously, we
only took care of a single code path, the one that handled session
start-up; missing the one obtaining the list of sessions.
This commit patches the second code path, and also whitelists the
GDM_SESSIONS_DIR so that it can be passed to the greeter.
Fixes#34101
Use nixos-fw chain instead of INPUT so that the rules don't keep
stacking everytime the firewall is reloaded.
This also adds a comment to each rule about the associated exporter.
(cherry picked from commit 9216da8928)
Problem: Restarting (stopping) system.slice would not only stop X11 but
also most system units/services. We obviously don't want this happening
to users when they switch from 18.03 to 18.09 or nixos-unstable.
Reason: The following change in systemd:
d8e5a93382
The commit adds system.slice to the perpetual units, which means
removing the unit file and adding it to the source code. This is done so
that system.slice can't be stopped anymore but in our case it ironically
would cause this script to stop system.slice because the unit file was
removed (and an older systemd version is still running).
Related issue: https://github.com/NixOS/nixpkgs/issues/39791
(cherry picked from commit 7098b0fcdf)
Reason: Make sure that this problem wouldn't occur if we would update
the systemd version.
from Gentoo, based on upstream commit.
(cherry picked from commit 6546d17cff)
It seems not clear if _this_ version was affected by the CVE,
but the patch seems safe enough, so apply it to be sure.
Commit 42c35dea37, which is a cherry-pick
of 28c20a4731 uses the variable 'gitea',
which is not defined in the 18.03 module.
Fix this by: gitea -> pkgs.gitea
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/darktable/versions.
These checks were done:
- built on NixOS
- Warning: no invocation of /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/darktable had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/darktable-rs-identify had a zero exit code or showed the expected version
- /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/darktable-cltest passed the binary check.
- Warning: no invocation of /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/darktable-cli had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/darktable-generate-cache had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/darktable-cmstest had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/darktable-chart had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/.darktable-wrapped had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/.darktable-rs-identify-wrapped had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/.darktable-cltest-wrapped had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/.darktable-cli-wrapped had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/.darktable-generate-cache-wrapped had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/.darktable-cmstest-wrapped had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4/bin/.darktable-chart-wrapped had a zero exit code or showed the expected version
- 1 of 14 passed binary check by having a zero exit code.
- 0 of 14 passed binary check by having the new version present in output.
- found 2.4.4 with grep in /nix/store/jgj8pvq3axhdwb75mjz3pv6a0fricl5s-darktable-2.4.4
- directory tree listing: https://gist.github.com/5bf935d4e34e2708e7c6c17628c7ee7b
- du listing: https://gist.github.com/b5ad3482552e5573dfaea42499dc0fb2
(cherry picked from commit 46f0320009)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/darktable/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/darktable-cltest help’ got 0 exit code
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/darktable-cmstest -h’ got 0 exit code
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/darktable-cmstest --help’ got 0 exit code
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/darktable-cmstest help’ got 0 exit code
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/.darktable-cmstest-wrapped -h’ got 0 exit code
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/.darktable-cmstest-wrapped --help’ got 0 exit code
- ran ‘/nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3/bin/.darktable-cmstest-wrapped help’ got 0 exit code
- found 2.4.3 with grep in /nix/store/9c4h87rp848ik02prxawwi85qzidjkmz-darktable-2.4.3
- directory tree listing: https://gist.github.com/70f09e7ec3ef4b1bba88d54f066cf9df
(cherry picked from commit 5a62cfe4d3)
The hooks directory contains now one level deep subdirectories which
need to be updated as well.
If you use gitea via ssh, ~/.ssh/authorized_keys also needs to be
updated because of the hardcoded path to gitea in the "command" option.
(cherry picked from commit 28c20a4731)
(cherry picked from commit fddd90e9ea)
This seems safe enough. It solves a bug in a conservative way;
it also adds features, possibly easing cherry-picks of fixes from master.
The regression in ext4 kernel code appears to cause no real issue
to anyone, so I hate it would block other fixes from 18.03 for longer
than a full week.
(The ext4 changes themselves fix some CVE, though apparently minor.)
Removed some redundancy (src check via meta.platforms) and made some
changes according to our style-guide.
I've changed meta.description and added meta.longDescription.
(cherry picked from commit ab593d46dc)
If executed in a pure environment (nix-shell --pure) or depending on the
`gtk3` version of the system Signal-Desktop was e.g. crashing when
clicking on a PDF attachment (instead of showing the dialog to save a
file).
Using wrapGAppsHook and setting XDG_DATA_DIRS to the correct version
fixes this bug.
The error message was the following:
```
(signal-desktop:30756): Gtk-WARNING **: 14:04:49.073: Could not find the icon 'user-home-symbolic-ltr'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
http://icon-theme.freedesktop.org/releases
(signal-desktop:30756): GLib-GIO-ERROR **: 14:04:49.134: No GSettings schemas are installed on the system
Trace/breakpoint trap
```
(cherry picked from commit 5d795355a0)
(cherry picked from commit 7ec0471242)
This isn't a real cherry pick, as I've only applied the changes
affecting Signal (these changes are required to cherry-pick further
commits) and customized the subject to avoid confusion.
Fix a serious issue with the xen-netfront driver introduced in
upstream commit f599c64fdf7d ("xen-netfront: Fix race between device
setup and open") where the MTU of the device cannot be set
properly. This should be removed once it's included in upstream.
(cherry picked from commit 656335cd8b)
The line was essentially checking whether /bin/sh exists and is
executable and if that's the case, the isScript function returns
successfully.
When asking the author of this line on IRC it seems that even they can't
remember or imagine what this was supposed to be.
In summary: Whenever /bin/sh doesn't exist during a build, *any* file
given to isScript is reported as being a script even if it isn't.
This is kinda counter-intuitive and not something what somebody would
expect from a function called "isScript".
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra
(cherry picked from commit 739c835515)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/virtualbox/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/6769l9s88jlcv3qgxpjsfr1ybkq3yvvb-virtualbox-5.2.12/bin/VBoxManage -h’ got 0 exit code
- ran ‘/nix/store/6769l9s88jlcv3qgxpjsfr1ybkq3yvvb-virtualbox-5.2.12/bin/VBoxManage --help’ got 0 exit code
- ran ‘/nix/store/6769l9s88jlcv3qgxpjsfr1ybkq3yvvb-virtualbox-5.2.12/bin/VBoxManage help’ got 0 exit code
- ran ‘/nix/store/6769l9s88jlcv3qgxpjsfr1ybkq3yvvb-virtualbox-5.2.12/bin/VBoxBalloonCtrl -h’ got 0 exit code
- ran ‘/nix/store/6769l9s88jlcv3qgxpjsfr1ybkq3yvvb-virtualbox-5.2.12/bin/VBoxBalloonCtrl --help’ got 0 exit code
- found 5.2.12 with grep in /nix/store/6769l9s88jlcv3qgxpjsfr1ybkq3yvvb-virtualbox-5.2.12
- directory tree listing: https://gist.github.com/f9bf852a0a8e6e0b4c44a9b68764850b
(cherry picked from commit 2c591d6622)
The kernel patch is required for raspberry pi, to enable the camera
module.
[dezgeg: Add some comments indicating it's only needed for 4.16]
(cherry picked from commit 438631e401)
With a config like
{
networking.interfaces."lo".ip4 = [
{ address = "10.8.8.8"; prefixLength = 32; }
];
}
a nixos-rebuild switch would take a long time, and you'd see:
$ systemctl list-jobs
JOB UNIT TYPE STATE
734400 network-interfaces.target start waiting
734450 sys-subsystem-net-devices-lo.device start running
734449 network-link-lo.service start waiting
and:
systemd[1]: sys-subsystem-net-devices-lo.device: Job sys-subsystem-net-devices-lo.device/star>
systemd[1]: sys-subsystem-net-devices-lo.device: Job sys-subsystem-net-devices-lo.device/star>
systemd[1]: Timed out waiting for device sys-subsystem-net-devices-lo.device.
This removes the device dependency for `lo` and fixes this bug.
Closes#7227
(cherry picked from commit 48d292e8a1)
Bold marked applicable changelog entries:
- Support extended attributes (xattr) in forward mode<Paste>
- Add -fsck function
- Fix several symlink race attacks
- Use memory pools for buffer handling
- Parallelize file content encryption
- Use HKDF to derive separate keys for GCM and EME
(cherry picked from commit 7e579aa994)
(cherry picked from commit 4a8104af49)
Pick wasn't entirely clean, required touchup because on master
compiler-rt is split into separate expression (and file),
which just meant the hash to update was in default.nix instead :).
Is called like this since 14321ae, but
docs were still using the old option in some cases.
Reported-By: Cedric Shahabi <cedric.shahabi@gmail.com>
(cherry picked from commit 6cabce9abd)
Linux 4.16 introduces a stackprotector detection script that returns
different results for the kernel compilation run and the spl/zfs
compilation run, as the setting for hardening are different. This
results in a broken ABI between spl/zfs and the compiled kernel,
breaking ZFS. Also disabling the fortify and stackprotector hardening,
as we do for the kernel, fixes that.
(cherry picked from commit 43a737b81c)
Not around a function that itself will grab the rng lock.
Unfortunate that we obtain/release the lock twice
but this seems least invasive way to fix this.
(cherry picked from commit 7cfdb8950d)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/php/versions.
These checks were done:
- built on NixOS
- /nix/store/n62w6pi30bkz1i08h1wr1icrabkky794-php-7.2.7/bin/phar.phar passed the binary check.
- /nix/store/n62w6pi30bkz1i08h1wr1icrabkky794-php-7.2.7/bin/phar passed the binary check.
- /nix/store/n62w6pi30bkz1i08h1wr1icrabkky794-php-7.2.7/bin/php passed the binary check.
- /nix/store/n62w6pi30bkz1i08h1wr1icrabkky794-php-7.2.7/bin/phpdbg passed the binary check.
- /nix/store/n62w6pi30bkz1i08h1wr1icrabkky794-php-7.2.7/bin/php-cgi passed the binary check.
- /nix/store/n62w6pi30bkz1i08h1wr1icrabkky794-php-7.2.7/bin/pear passed the binary check.
- /nix/store/n62w6pi30bkz1i08h1wr1icrabkky794-php-7.2.7/bin/peardev passed the binary check.
- /nix/store/n62w6pi30bkz1i08h1wr1icrabkky794-php-7.2.7/bin/pecl passed the binary check.
- /nix/store/n62w6pi30bkz1i08h1wr1icrabkky794-php-7.2.7/bin/php-fpm passed the binary check.
- 9 of 9 passed binary check by having a zero exit code.
- 0 of 9 passed binary check by having the new version present in output.
- found 7.2.7 with grep in /nix/store/n62w6pi30bkz1i08h1wr1icrabkky794-php-7.2.7
- directory tree listing: https://gist.github.com/6ecb6c21e261466b865908a41564ca3e
- du listing: https://gist.github.com/2ca1dc05af5d5240a6b63fadd59ee0d0
(cherry picked from commit 15ec13dad1)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/php/versions.
These checks were done:
- built on NixOS
- /nix/store/25l2hz7njpg9glpmslcadkgqwai5f77s-php-7.2.6/bin/phar.phar passed the binary check.
- /nix/store/25l2hz7njpg9glpmslcadkgqwai5f77s-php-7.2.6/bin/phar passed the binary check.
- /nix/store/25l2hz7njpg9glpmslcadkgqwai5f77s-php-7.2.6/bin/php passed the binary check.
- /nix/store/25l2hz7njpg9glpmslcadkgqwai5f77s-php-7.2.6/bin/phpdbg passed the binary check.
- /nix/store/25l2hz7njpg9glpmslcadkgqwai5f77s-php-7.2.6/bin/php-cgi passed the binary check.
- /nix/store/25l2hz7njpg9glpmslcadkgqwai5f77s-php-7.2.6/bin/pear passed the binary check.
- /nix/store/25l2hz7njpg9glpmslcadkgqwai5f77s-php-7.2.6/bin/peardev passed the binary check.
- /nix/store/25l2hz7njpg9glpmslcadkgqwai5f77s-php-7.2.6/bin/pecl passed the binary check.
- /nix/store/25l2hz7njpg9glpmslcadkgqwai5f77s-php-7.2.6/bin/php-fpm passed the binary check.
- 9 of 9 passed binary check by having a zero exit code.
- 0 of 9 passed binary check by having the new version present in output.
- found 7.2.6 with grep in /nix/store/25l2hz7njpg9glpmslcadkgqwai5f77s-php-7.2.6
- directory tree listing: https://gist.github.com/409d2cfaa7e805714825281fbaba0d0f
- du listing: https://gist.github.com/7fbd8e3d56524f70b3dfb94c045fccd2
(cherry picked from commit 98c4ac2fa5)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/strongswan/versions.
These checks were done:
- built on NixOS
- /nix/store/9qicaqwg2cvmahh3hqwig5bcqpd41k9a-strongswan-5.6.3/bin/pki passed the binary check.
- /nix/store/9qicaqwg2cvmahh3hqwig5bcqpd41k9a-strongswan-5.6.3/bin/charon-cmd passed the binary check.
- Warning: no invocation of /nix/store/9qicaqwg2cvmahh3hqwig5bcqpd41k9a-strongswan-5.6.3/bin/charon-systemd had a zero exit code or showed the expected version
- /nix/store/9qicaqwg2cvmahh3hqwig5bcqpd41k9a-strongswan-5.6.3/bin/ipsec passed the binary check.
- /nix/store/9qicaqwg2cvmahh3hqwig5bcqpd41k9a-strongswan-5.6.3/bin/swanctl passed the binary check.
- 4 of 5 passed binary check by having a zero exit code.
- 1 of 5 passed binary check by having the new version present in output.
- found 5.6.3 with grep in /nix/store/9qicaqwg2cvmahh3hqwig5bcqpd41k9a-strongswan-5.6.3
- directory tree listing: https://gist.github.com/258736889db4e822d054b65e7035147b
- du listing: https://gist.github.com/478dbb4f44b4ed18b112076b17451a4e
(cherry picked from commit 30c3a7f5c6)
This is necessary for OCSP and/or remote CRL verification of server
certificates to work, which is a fairly common thing to need.
(cherry picked from commit 1022dc54ba)
The configure script uses the `command` builtin command which is bash
specific while having a "#!/bin/sh" head.
This forces the use nix default shell (bash)
(cherry picked from commit 159a021bd8)
(cherry picked from commit 2653355a9c)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/qutebrowser/versions.
These checks were done:
- built on NixOS
- /nix/store/d5f7w3hcgxzhk1sgk1gjnl36nrq30wlm-qutebrowser-1.3.2/bin/qutebrowser passed the binary check.
- /nix/store/d5f7w3hcgxzhk1sgk1gjnl36nrq30wlm-qutebrowser-1.3.2/bin/..qutebrowser-wrapped-wrapped passed the binary check.
- /nix/store/d5f7w3hcgxzhk1sgk1gjnl36nrq30wlm-qutebrowser-1.3.2/bin/.qutebrowser-wrapped passed the binary check.
- 3 of 3 passed binary check by having a zero exit code.
- 0 of 3 passed binary check by having the new version present in output.
- found 1.3.2 with grep in /nix/store/d5f7w3hcgxzhk1sgk1gjnl36nrq30wlm-qutebrowser-1.3.2
- directory tree listing: https://gist.github.com/86db26ab52e4c4aaabb2949ceba69142
- du listing: https://gist.github.com/47c80976cbfff66061ccbffa47d02669
(cherry picked from commit c9fe43c668)
Peviously only the timesyncd systemd unit was disabled. This meant
that when you activate a system that has chronyd enabled the following
strange startup behaviour takes place:
systemd[1]: Starting chrony NTP daemon...
systemd[1]: Stopping Network Time Synchronization...
systemd[1]: Stopped chrony NTP daemon.
systemd[1]: Starting Network Time Synchronization...
(cherry picked from commit 56ef106848)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/l6j73nin5ip68kl9nn6zgllp88hlbdli-lastpass-cli-1.3.0/bin/lpass -V` and found version 1.3.0
- ran `/nix/store/l6j73nin5ip68kl9nn6zgllp88hlbdli-lastpass-cli-1.3.0/bin/lpass -v` and found version 1.3.0
- ran `/nix/store/l6j73nin5ip68kl9nn6zgllp88hlbdli-lastpass-cli-1.3.0/bin/lpass --version` and found version 1.3.0
- found 1.3.0 with grep in /nix/store/l6j73nin5ip68kl9nn6zgllp88hlbdli-lastpass-cli-1.3.0
- directory tree listing: https://gist.github.com/67aab5e731ed5d963e433d03c1a27870
(cherry picked from commit 3783316b6a)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/xmr-stak/versions.
These checks were done:
- built on NixOS
- /nix/store/wbq2l97g7y24hnbz1zzs17yl8qh1csd3-xmr-stak-2.4.5/bin/xmr-stak passed the binary check.
- Warning: no invocation of /nix/store/wbq2l97g7y24hnbz1zzs17yl8qh1csd3-xmr-stak-2.4.5/bin/libxmrstak_opencl_backend.so had a zero exit code or showed the expected version
- 1 of 2 passed binary check by having a zero exit code.
- 0 of 2 passed binary check by having the new version present in output.
- found 2.4.5 with grep in /nix/store/wbq2l97g7y24hnbz1zzs17yl8qh1csd3-xmr-stak-2.4.5
- directory tree listing: https://gist.github.com/d748f1490c29ab43e9426b5d283a5e4e
- du listing: https://gist.github.com/06e416d3c3db5caf733655c9ab632eea
(cherry picked from commit 1c479b27fa)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/xmr-stak/versions.
These checks were done:
- built on NixOS
- /nix/store/bfj12k7pz2bj2jzx3swkmz2kk3dfqx5p-xmr-stak-2.4.4/bin/xmr-stak passed the binary check.
- Warning: no invocation of /nix/store/bfj12k7pz2bj2jzx3swkmz2kk3dfqx5p-xmr-stak-2.4.4/bin/libxmrstak_opencl_backend.so had a zero exit code or showed the expected version
- 1 of 2 passed binary check by having a zero exit code.
- 0 of 2 passed binary check by having the new version present in output.
- found 2.4.4 with grep in /nix/store/bfj12k7pz2bj2jzx3swkmz2kk3dfqx5p-xmr-stak-2.4.4
- directory tree listing: https://gist.github.com/5ef7f1fd13c10bef56522a028b52c82e
- du listing: https://gist.github.com/be63ac59af2a152db46085c4509cdcd3
(cherry picked from commit f138129894)
We have it use our system copy regardless, but might as well.
(yes, hash does not change, since we don't fetch submodule here)
(cherry picked from commit 40b14109d3)
It seems to work fine, in python2Packages and python3Packages.
If you find a problem, let me know and I'll try to fix it.
(cherry picked from commit 3756efbdcc)
This addresses some issues regarding CVE-2018-12356. There is a
annoucement for that version on the password-store ML [1] which goes
into details.
This is more or less a backport of #42049 which couldn't be
cherry-picked due to larger changes in the pass expression.
[1] https://lists.zx2c4.com/pipermail/password-store/2018-June/003308.html
https://sqlite.org/releaselog/3_23_1.html
(also contains notes for 3.23.0)
Adds CLI support for SQLite archive files:
https://sqlite.org/sqlar.html
(cherry picked from commit a6d8d54e79)
Fixes CVE-2018-8740; /cc #41749 and #40626.
We have 3.24 on master already, but that's rather fresh and I can't see
any serious fixes in that bump. Also, the analyzer packages and other
changes in the expressions are left behind, as they don't seem required.
The test binaries hang for some reason (psynch_mutexwait),
gnupg seems to work fine so hopefully it's not an actual issue.
(cherry picked from commit eeb6211944)
Upstream changes are:
- git-annex (6.20180529) upstream; urgency=medium
* Prevent haskell http-client from decompressing gzip files, so downloads
of such files works the same as it used to with wget and curl.
* Workaround for bug in an old version of cryptonite that broke https
downloads, by using curl for downloads when git-annex is built with it.
* view, vadd: Fix crash when a git submodule has a name starting with a dot.
* Don't allow entering a view with staged or unstaged changes.
* move: --force was accidentially enabling two unrelated behaviors
since 6.20180427. The older behavior, which has never been well
documented and seems almost entirely useless, has been removed.
* copy: --force no longer does anything.
* migrate: Fix bug in migration between eg SHA256 and SHA256E,
that caused the extension to be included in SHA256 keys,
and omitted from SHA256E keys.
(Bug introduced in version 6.20170214)
* migrate: Check for above bug when migrating from SHA256 to SHA256
(and same for SHA1 to SHA1 etc), and remove the extension that should
not be in the SHA256 key.
* fsck: Detect and warn when keys need an upgrade, either to fix up
from the above migrate bug, or to add missing size information
(a long ago transition), or because of a few other past key related
bugs.
* git-annex-shell: GIT_ANNEX_SHELL_APPENDONLY makes it allow writes,
but not deletion of annexed content. Note that securing pushes to
the git repository is left up to the user.
* setpresentkey: Added --batch support.
- git-annex (6.20180509) upstream; urgency=medium
* The old git-annex Android app is now deprecated in favor of running
git-annex in termux.
* runshell: Use proot when running on Android, to work around
Android 8's ill-advised seccomp filtering of system calls,
including ones crucial for reliable thread locking.
(This will only work with termux's version of proot.)
* Fix bug in last release that crashes when using
--all or running git-annex in a bare repository. May have also
affected git-annex unused and git-annex info.
* Fix bug in last release that prevented the webapp opening on
non-Linux systems.
* Support building with hinotify-0.3.10.
* Display error message when http download fails.
* Avoid forward retry when 0 bytes were received.
- git-annex (6.20180427) upstream; urgency=medium
* move: Now takes numcopies configuration, and required content
configuration into account, and refuses to reduce the current
number of copies of a file, or remove content that a repository
requires. --force can override these checks.
Note that it's still allowed to move the content of a file
from one repository to another when numcopies is not satisfied, as long
as the move does not result in there being fewer copies.
* Fix mangling of --json output of utf-8 characters when not
running in a utf-8 locale.
* Fix build with yesod 1.6.
* Clean up some build warnings with newer versions of ghc and haskell
libraries.
* runshell: Unset LD_PRELOAD since preloaded libraries from the host
system may not get along with the bundled linker.
* runshell: Added some tweaks to make git-annex work in termux on
Android. The regular arm standalone tarball now works in termux.
* Webapp: Support being run inside termux on Android, and offer to set up
a repository on the sdcard.
* Assistant: Integrate with Termux:Boot, so when it's installed, the
assistant is autostarted on boot.
* Assistant: Fix installation of menus, icons, etc when run
from within runshell.
* import: Avoid buffering all filenames to be imported in memory.
* Improve memory use and speed of --all and git-annex info remote,
by not buffering list of all keys.
- git-annex (6.20180409) upstream; urgency=medium
* Added adb special remote which allows exporting files to Android devices.
* For url downloads, git-annex now defaults to using a http library,
rather than wget or curl. But, if annex.web-options is set, it will
use curl. To use the .netrc file, run:
git config annex.web-options --netrc
* git-annex no longer uses wget (and wget is no longer shipped with
git-annex builds).
* Enable HTTP connection reuse across multiple files for improved speed.
* Fix calculation of estimated completion for progress meter.
* OSX app: Work around libz/libPng/ImageIO.framework version skew
by not bundling libz, assuming OSX includes a suitable libz.1.dylib.
* Added annex.retry, annex.retry-delay, and per-remote versions
to configure transfer retries.
* Also do forward retrying in cases where no exception is thrown,
but the transfer failed.
* When adding a new version of a file, and annex.genmetadata is enabled,
don't copy the data metadata from the old version of the file,
instead use the mtime of the file.
* Avoid running annex.http-headers-command more than once.
* info: Added "combined size of repositories containing these files"
stat when run on a directory.
* info: Changed sorting of numcopies stats table, so it's ordered
by the variance from the desired number of copies.
* Fix resuming a download when using curl.
- git-annex (6.20180316) upstream; urgency=medium
* New protocol for communicating with git-annex-shell increases speed
of operations involving ssh remotes. When not transferring large files,
git-annex is between 200% and 400% faster using the new protocol,
and it's just as fast as before when transferring large files.
(When the remote has an old git-annex-shell, git-annex falls back
to the old slower code. This fallback is planned to be removed
after 5 years or so.)
* Note that, due to not using rsync to transfer files over ssh
any longer, permissions and other file metadata of annexed files
will no longer be preserved when copying them to and from ssh remotes.
Other remotes never supported preserving that information, so
this is not considered a regression.
* Fix data loss bug in content locking over tor, when the remote
repository is in direct mode, it neglected to check that the content
was actually present when locking it. This could cause git annex drop
to remove the only copy of a file when it thought the tor remote had
a copy.
* Fix data loss bug when the local repository uses direct mode, and a
locally modified file is dropped from a remote repsitory. The bug
caused the modified file to be counted as a copy of the original file.
(This is not a severe bug because in such a situation, dropping
from the remote and then modifying the file is allowed and has the same
end result.)
* Some downloads will be verified, even when annex.verify=false.
This is done in some edge cases where there's a likelyhood than an
object was downloaded incorrectly.
* Support exporttree=yes for rsync special remotes.
* Added backends for the BLAKE2 family of hashes, when built with
a new enough version of cryptonite.
* Improve SHA*E extension extraction code to not treat parts of the
filename that contain punctuation or other non-alphanumeric characters
as extensions. Before, such characters were filtered out.
* Better ssh connection warmup when using -J for concurrency.
Avoids ugly messages when forced ssh command is not git-annex-shell.
* Fix race condition in ssh warmup that caused git-annex to get
stuck and never process some files when run with high levels of
concurrency.
* Fix reversion introduced in 6.20171214 that caused concurrent
transfers to incorrectly fail with "transfer already in progress".
* Note that Remote/Git.hs now contains AGPL licensed code,
thus the license of git-annex as a whole is AGPL. This was already
the case when git-annex was built with the webapp enabled.
* Include amount of data transferred in progress display.
* Dial back optimisation when building on arm, which prevents
ghc and llc from running out of memory when optimising some files.
(Unfortunately this fix is incomplete due to a ghc bug.)
Before this change:
$ readelf --notes /nix/store/zf5yja02g8n8dzgs25pqfd8w3myfzgzc-qtbase-5.10.1/lib/libQt5Core.so
Displaying notes found at file offset 0x004a7778 with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 3.17.0
After:
$ readelf --notes /nix/store/sg1s9hdw0b7p6h0dwg09g4lxy1acq7y6-qtbase-5.10.1/lib/libQt5Core.so
Displaying notes found at file offset 0x004a7dcc with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 2.6.28
-----------
The above paths were before rebasing the commit onto staging,
and it'd probably be good to have someone confirm the same happens
when built on a hydra builder or other non-dtzWill machine :).
[dezgeg: added comments]
(cherry picked from commit 39696b6d56)
Without `ROOT_PATH` set, `gogs serv` tries to open logs in writing in
its store directory. This blocks cloning or pushing over ssh, and
results in a gogs internal error.
(cherry picked from commit b59570eac0)
Get libtiff on the same patch level as Debian. The imported patch file contains:
CVE-2017-9935
CVE-2017-11613
CVE-2017-17095
CVE-2017-18013
CVE-2018-5784
CVE-2018-7456
Re #41748 (master)
Re #41749 (release-18.03 - needs to be cherry-picked)
(cherry picked from commit cca45cc3e1)
Another broken URL related to: https://github.com/NixOS/nixpkgs/issues/39927
Note that the patch file has legitimately changed, because ~4 months ago Debian
replaced their CVE security fix with a newer version that fixes some additional
bugs: d6fd3b3734
(cherry picked from commit e20abf829a)
Without explicitly specifying that libsasl2 is part of the build, and
without explicitly making it part of pylibmc's linker flags for its
CPython extension, the cpython code enters a build state error where it
instead attempts to blindly `dlopen("libsasl2.so")` out of
$LD_LIBRARY_PATH; this fails as it can't be found in the store,
obviously.
The bigger problem with this is that it otherwise makes pylibmc
unusable, as it will try to immediately load libsasl2 at startup. This
means even using 'import pylibmc' at all will cause a failure.
Instead, add cyrus_sasl into the build closure of the library, and pass
an argument to the setup.py script to properly pass -lsasl2 to the C
extension. This causes a link to properly be formed.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
(cherry picked from commit 350f49734b)
Instead of explicitly depending on libelf, use
kernel.moduleBuildDependencies which was introduced in 1e77d0b975
("kernel 4.14 require libelf to compile modules.").
(cherry picked from commit 7dbd9a6378)
Fixes this:
$ nix-build -A linuxPackages.lttng-modules
[...]
/nix/store/...-linux-4.14.48-dev/lib/modules/4.14.48/source/Makefile:948: \
*** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfu
(Linux 4.16+ has other issues, so mark as broken.)
(cherry picked from commit 0f8594170a)
Backport of the (automated) version bump to address the famous UDP
amplification CVE-2018-1000115. While the issue only manifests on localhost (with our
default nixos configuration) the issue might be more relevant for people
that expose it to other hosts and only restrict the TCP access. UDP was
enabled per default, it had to be disabled. The NixOS module does only
configure the TCP port.
(cherry picked from commit 7e30cfff78)
This fixes CVE-2018-10184 a potential remote denial of service in the
http/2 module. The version bump also includes various other changes that
are described in the changelog [1]:
2018/05/18 : 1.8.9
- BUG/MINOR: pattern: Add a missing HA_SPIN_INIT() in pat_ref_newid()
- BUG/MAJOR: channel: Fix crash when trying to read from a closed socket
- BUG/MINOR: log: t_idle (%Ti) is not set for some requests
- BUG/MEDIUM: lua: Fix segmentation fault if a Lua task exits
- MINOR: h2: detect presence of CONNECT and/or content-length
- BUG/MEDIUM: h2: implement missing support for chunked encoded uploads
- BUG/MINOR: lua/threads: Make lua's tasks sticky to the current thread
- BUG/MINOR: config: disable http-reuse on TCP proxies
- BUG/MINOR: checks: Fix check->health computation for flapping servers
- BUG/MEDIUM: threads: Fix the sync point for more than 32 threads
- BUG/MINOR: lua: Put tasks to sleep when waiting for data
- DOC/MINOR: clean up LUA documentation re: servers & array/table.
- BUG/MINOR: map: correctly track reference to the last ref_elt being dumped
- BUG/MEDIUM: task: Don't free a task that is about to be run.
- BUG/MINOR: lua: schedule socket task upon lua connect()
- BUG/MINOR: lua: ensure large proxy IDs can be represented
- BUG/MEDIUM: http: don't always abort transfers on CF_SHUTR
- BUG/MEDIUM: pollers: Use a global list for fd shared between threads.
- BUG/MEDIUM: ssl: properly protect SSL cert generation
- BUG/MINOR: spoe: Mistake in error message about SPOE configuration
2018/04/19 : 1.8.8
- BUG/MEDIUM: threads: Fix the max/min calculation because of name clashes
- BUG/MEDIUM: connection: Make sure we have a mux before calling detach().
- BUG/MINOR: http: Return an error in proxy mode when url2sa fails
- BUG/MEDIUM: kqueue: When adding new events, provide an output to get errors.
- BUG/MINOR: cli: Guard against NULL messages when using CLI_ST_PRINT_FREE
- MINOR: cli: Ensure the CLI always outputs an error when it should
- DOC: lua: update the links to the config and Lua API
- BUG/CRITICAL: h2: fix incorrect frame length check
2018/04/07 : 1.8.7
- BUG/MAJOR: cache: always initialize newly created objects
- MINOR: servers: Support alphanumeric characters for the server templates names
2018/04/05 : 1.8.6
- BUG/MINOR: lua: the function returns anything
- BUG/MINOR: lua funtion hlua_socket_settimeout don't check negative values
- BUILD/MINOR: fix build when USE_THREAD is not defined
- MINOR: cli/threads: make "show fd" report thread_sync_io_handler instead of "unknown"
- MINOR: cli: make "show fd" report the mux and mux_ctx pointers when available
- BUILD/MINOR: cli: fix a build warning introduced by last commit
- BUG/MINOR: hpack: fix harmless use of uninitialized value in hpack_dht_insert
- CLEANUP: h2: rename misleading h2c_stream_close() to h2s_close()
- MINOR: h2: provide and use h2s_detach() and h2s_free()
- BUG/MAJOR: h2: remove orphaned streams from the send list before closing
- MINOR: h2: always call h2s_detach() in h2_detach()
- MINOR: h2: fuse h2s_detach() and h2s_free() into h2s_destroy()
- BUG/MEDIUM: h2/threads: never release the task outside of the task handler
- BUG/MEDIUM: h2: don't consider pending data on detach if connection is in error
- BUILD/MINOR: threads: always export thread_sync_io_handler()
- BUG/MEDIUM: h2: always add a stream to the send or fctl list when blocked
- BUG/MINOR: checks: check the conn_stream's readiness and not the connection
- BUG/MINOR: email-alert: Set the mailer port during alert initialization
- BUG/MINOR: cache: fix "show cache" output
- BUG/MINOR: fd: Don't clear the update_mask in fd_insert.
- BUG/MAJOR: cache: fix random crashes caused by incorrect delete() on non-first blocks
- BUG/MINOR: spoe: Initialize variables used during conf parsing before any check
- BUG/MINOR: spoe: Don't release the context buffer in .check_timeouts callbaclk
2018/03/23 : 1.8.5
- BUG/MINOR: threads: fix missing thread lock labels for 1.8
- BUG/MEDIUM: ssl: Don't always treat SSL_ERROR_SYSCALL as unrecovarable.
- BUG/MEDIUM: ssl: Shutdown the connection for reading on SSL_ERROR_SYSCALL
- BUG/MINOR: init: Add missing brackets in the code parsing -sf/-st
- BUG/MINOR: ssl/threads: Make management of the TLS ticket keys files thread-safe
- BUG/MEDIUM: http: Switch the HTTP response in tunnel mode as earlier as possible
- BUG/MEDIUM: ssl/sample: ssl_bc_* fetch keywords are broken.
- DOC: lua: new prototype for function "register_action()"
- DOC: cfgparse: Warn on option (tcp|http)log in backend
- BUG/MINOR: debug/pools: properly handle out-of-memory when building with DEBUG_UAF
- MINOR: debug/pools: make DEBUG_UAF also detect underflows
- BUG/MINOR: h2: Set the target of dbuf_wait to h2c
- MINOR: stats: display the number of threads in the statistics.
- BUG/MEDIUM: h2: always consume any trailing data after end of output buffers
- BUG/MEDIUM: buffer: Fix the wrapping case in bo_putblk
- BUG/MEDIUM: buffer: Fix the wrapping case in bi_putblk
- Revert "BUG/MINOR: send-proxy-v2: string size must include ('\0')"
- MINOR: systemd: Add section for SystemD sandboxing to unit file
- MINOR: systemd: Add SystemD's Protect*= options to the unit file
- MINOR: systemd: Add SystemD's SystemCallFilter option to the unit file
- MINOR/BUILD: fix Lua build on Mac OS X
- BUILD/MINOR: fix Lua build on Mac OS X (again)
- BUG/MINOR: session: Fix tcp-request session failure if handshake.
- CLEANUP: .gitignore: Ignore binaries from the contrib directory
- BUG/MINOR: unix: Don't mess up when removing the socket from the xfer_sock_list.
- BUG/MEDIUM: h2: also arm the h2 timeout when sending
- BUG/MINOR: cli: Fix a crash when passing a negative or too large value to "show fd"
- CLEANUP: ssl: Remove a duplicated #include
- CLEANUP: cli: Remove a leftover debug message
- BUG/MINOR: cli: Fix a typo in the 'set rate-limit' usage
- BUG/MEDIUM: fix a 100% cpu usage with cpu-map and nbthread/nbproc
- BUG/MINOR: force-persist and ignore-persist only apply to backends
- BUG/MEDIUM: spoe: Remove idle applets from idle list when HAProxy is stopping
- BUG/MEDIUM: threads/unix: Fix a deadlock when a listener is temporarily disabled
- BUG/MAJOR: threads/queue: Fix thread-safety issues on the queues management
- BUG/MINOR: dns: don't downgrade DNS accepted payload size automatically
- BUG/MINOR: seemless reload: Fix crash when an interface is specified.
- BUG/MINOR: cli: Fix a crash when sending a command with too many arguments
- BUILD: ssl: Fix build with OpenSSL without NPN capability
- BUG/MINOR: spoa-example: unexpected behavior for more than 127 args
- BUG/MINOR: lua: return bad error messages
- BUG/MEDIUM: tcp-check: single connect rule can't detect DOWN servers
- BUG/MINOR: tcp-check: use the server's service port as a fallback
- BUG/MEDIUM: threads/queue: wake up other threads upon dequeue
- MINOR: log: stop emitting alerts when it's not possible to write on the socket
- BUILD/BUG: enable -fno-strict-overflow by default
- DOC: log: more than 2 log servers are allowed
- DOC: don't suggest using http-server-close
- BUG/MEDIUM: h2: properly account for DATA padding in flow control
- BUG/MINOR: h2: ensure we can never send an RST_STREAM in response to an RST_STREAM
- BUG/MINOR: listener: Don't decrease actconn twice when a new session is rejected
[1] https://www.haproxy.org/download/1.8/src/CHANGELOG
(cherry picked from commit 6d03390d12)
If there is a shared object or executable that's using
position-independent code, the file's mime type is
"application/x-pie-executable", so until this change its dependencies
wouldn't be patched.
This simply adds the mime type to the search loop.
Signed-off-by: aszlig <aszlig@nix.build>
(cherry picked from commit ff5cecf821)
Reason: The fix is non-intrusive and should not break anything that
wasn't broken before. I've tested whether oracle-instantclient
builds and it still does. Other than that no other package is
using autoPatchelfHook in NixOS 18.03.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/eid-mw/versions.
These checks were done:
- built on NixOS
- Warning: no invocation of /nix/store/fb82i287dxzdi7iymk84yyvrx5ph4x41-eid-mw-4.4.2/bin/eid-viewer had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/fb82i287dxzdi7iymk84yyvrx5ph4x41-eid-mw-4.4.2/bin/.eid-viewer-wrapped had a zero exit code or showed the expected version
- /nix/store/fb82i287dxzdi7iymk84yyvrx5ph4x41-eid-mw-4.4.2/bin/beid-update-nssdb passed the binary check.
- /nix/store/fb82i287dxzdi7iymk84yyvrx5ph4x41-eid-mw-4.4.2/bin/eid-nssdb passed the binary check.
- 2 of 4 passed binary check by having a zero exit code.
- 0 of 4 passed binary check by having the new version present in output.
- found 4.4.2 with grep in /nix/store/fb82i287dxzdi7iymk84yyvrx5ph4x41-eid-mw-4.4.2
- directory tree listing: https://gist.github.com/9bc7e47978cdc6d1c57b60a0cdf06ffc
- du listing: https://gist.github.com/8f3d2be711226cec456c9d62c6e114d6
(cherry picked from commit a2f8e94439)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/qutebrowser/versions.
These checks were done:
- built on NixOS
- /nix/store/g9592dbmfj1icx0njg1dhj094v2l8rcj-qutebrowser-1.3.1/bin/qutebrowser passed the binary check.
- /nix/store/g9592dbmfj1icx0njg1dhj094v2l8rcj-qutebrowser-1.3.1/bin/..qutebrowser-wrapped-wrapped passed the binary check.
- /nix/store/g9592dbmfj1icx0njg1dhj094v2l8rcj-qutebrowser-1.3.1/bin/.qutebrowser-wrapped passed the binary check.
- 3 of 3 passed binary check by having a zero exit code.
- 0 of 3 passed binary check by having the new version present in output.
- found 1.3.1 with grep in /nix/store/g9592dbmfj1icx0njg1dhj094v2l8rcj-qutebrowser-1.3.1
- directory tree listing: https://gist.github.com/c6f74ace4cd8ac51662079876bcef904
- du listing: https://gist.github.com/c1a964f74432d7f8c83f9825d26fbad0
(cherry picked from commit a8925a2188)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/qutebrowser/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/nckfqg5crmyrx3aazk6szii42qy7v1g3-qutebrowser-1.3.0/bin/qutebrowser -h’ got 0 exit code
- ran ‘/nix/store/nckfqg5crmyrx3aazk6szii42qy7v1g3-qutebrowser-1.3.0/bin/qutebrowser --help’ got 0 exit code
- ran ‘/nix/store/nckfqg5crmyrx3aazk6szii42qy7v1g3-qutebrowser-1.3.0/bin/..qutebrowser-wrapped-wrapped -h’ got 0 exit code
- ran ‘/nix/store/nckfqg5crmyrx3aazk6szii42qy7v1g3-qutebrowser-1.3.0/bin/..qutebrowser-wrapped-wrapped --help’ got 0 exit code
- ran ‘/nix/store/nckfqg5crmyrx3aazk6szii42qy7v1g3-qutebrowser-1.3.0/bin/.qutebrowser-wrapped -h’ got 0 exit code
- ran ‘/nix/store/nckfqg5crmyrx3aazk6szii42qy7v1g3-qutebrowser-1.3.0/bin/.qutebrowser-wrapped --help’ got 0 exit code
- found 1.3.0 with grep in /nix/store/nckfqg5crmyrx3aazk6szii42qy7v1g3-qutebrowser-1.3.0
- directory tree listing: https://gist.github.com/b9f575b232cde51598aeed723a03f7ec
(cherry picked from commit 871bffd98f)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/qutebrowser/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/p9a5d6129dvx6gqbxn9fqgsmx7hnhwxb-qutebrowser-1.2.1/bin/qutebrowser -h` got 0 exit code
- ran `/nix/store/p9a5d6129dvx6gqbxn9fqgsmx7hnhwxb-qutebrowser-1.2.1/bin/qutebrowser --help` got 0 exit code
- ran `/nix/store/p9a5d6129dvx6gqbxn9fqgsmx7hnhwxb-qutebrowser-1.2.1/bin/..qutebrowser-wrapped-wrapped -h` got 0 exit code
- ran `/nix/store/p9a5d6129dvx6gqbxn9fqgsmx7hnhwxb-qutebrowser-1.2.1/bin/..qutebrowser-wrapped-wrapped --help` got 0 exit code
- ran `/nix/store/p9a5d6129dvx6gqbxn9fqgsmx7hnhwxb-qutebrowser-1.2.1/bin/.qutebrowser-wrapped -h` got 0 exit code
- ran `/nix/store/p9a5d6129dvx6gqbxn9fqgsmx7hnhwxb-qutebrowser-1.2.1/bin/.qutebrowser-wrapped --help` got 0 exit code
- found 1.2.1 with grep in /nix/store/p9a5d6129dvx6gqbxn9fqgsmx7hnhwxb-qutebrowser-1.2.1
- directory tree listing: https://gist.github.com/b85ebb5c38a8861cac255f78b5c16525
(cherry picked from commit 88423094f4)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/bind/versions.
These checks were done:
- built on NixOS
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/delv passed the binary check.
- Warning: no invocation of /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/arpaname had a zero exit code or showed the expected version
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/named-rrchecker passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/mdig passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/ddns-confgen passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/dnssec-cds passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/dnssec-dsfromkey passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/dnssec-importkey passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/dnssec-keyfromlabel passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/dnssec-keygen passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/dnssec-revoke passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/dnssec-settime passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/dnssec-signzone passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/dnssec-verify passed the binary check.
- Warning: no invocation of /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/genrandom had a zero exit code or showed the expected version
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/named passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/named-checkconf passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/named-checkzone passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/named-compilezone passed the binary check.
- Warning: no invocation of /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/named-journalprint had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/nsec3hash had a zero exit code or showed the expected version
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/rndc passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/rndc-confgen passed the binary check.
- /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2/bin/tsig-keygen passed the binary check.
- 20 of 24 passed binary check by having a zero exit code.
- 14 of 24 passed binary check by having the new version present in output.
- found 9.12.1-P2 with grep in /nix/store/zxylanld5x7l9n2n24g70qj91n4kmj5x-bind-9.12.1-P2
- directory tree listing: https://gist.github.com/d95b236ef147c4c8ad6a99ca42db1acd
- du listing: https://gist.github.com/f6bcea6b6bdce7df3f66bbf02768bd20
(cherry picked from commit d2329184a9)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/delv help` got 0 exit code
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/delv -v` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/named-rrchecker -h` got 0 exit code
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/named-rrchecker --help` got 0 exit code
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/named-rrchecker -V` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/named-rrchecker -v` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/named-rrchecker --version` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/named-rrchecker --help` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/mdig -h` got 0 exit code
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/mdig -v` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/ddns-confgen -h` got 0 exit code
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-cds -V` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-dsfromkey -V` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-importkey -V` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-keyfromlabel -V` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-keygen -V` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-revoke -V` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-settime -V` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-signzone -h` got 0 exit code
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-signzone --help` got 0 exit code
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-signzone -V` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-signzone -v` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-signzone --version` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-signzone -h` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-signzone --help` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-verify -h` got 0 exit code
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-verify --help` got 0 exit code
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-verify -V` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-verify -v` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-verify --version` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-verify -h` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/dnssec-verify --help` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/named -V` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/named -v` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/named-checkconf -v` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/named-checkzone -v` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/rndc -h` got 0 exit code
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/rndc -h` and found version 9.12.1
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/rndc-confgen -h` got 0 exit code
- ran `/nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1/bin/rndc-confgen -h` and found version 9.12.1
- found 9.12.1 with grep in /nix/store/9i6c9yx3p0gvhphd4ahj8pfcm0n78han-bind-9.12.1
- directory tree listing: https://gist.github.com/e9daefd05b7c96cd83a144018a3b6aaf
(cherry picked from commit eb7b4ce256)
This change allows users to specify an alternative database method. For
example an mpd satellite setup where another mpd on the network shares
it's database with the local instance. The `dbFile` parameter must not be
configured in that case.
(cherry picked from commit a0797bad2c)
This script is used to automatically fix issues within xml documentation
files.
The script is *for now* intended to be used ad-hoc, and the commits to
be examined.
A future discussion will define whether:
* This commit and scripts are kept.
* The script is extended for common use.
The biggest issue right now with the script is that it *could* in theory
destroy a valid space-less varlistentry.
The script could, in practical use, be changed and extended to normalize
some parts of the XML files, mainly:
* A common quoting style for attributes
* Fix-up some weird formatting automatically that xmlformat doesn't
catch
(cherry picked from commit bc0421c4cf)
The other definitions broke term, cmdsynopsis and arg tags; spaces
inside were removed, making workdsrun-ininstead of keeping them spaced.
(cherry picked from commit aa59151c21)
Applies a patch to the dd-agent derivation that fixes a compatibility
issue with the current version of iostat, which no longer contains a
colon after its table headers.
This patch is applied in order for the fix to be backportable to
existing stable releases. A final "proper" fix will be an upgrade to a
newer version of dd-agent, but that requires several other changes.
This fixes#40103.
(cherry picked from commit aee19ca7f8)
Fix openshift oc cluster up mount
(cherry picked from commit fd09c3dcae)
Reason: The basic functionality to spin up a local cluster using "oc
cluster up" is broken due to wrong paths to mount and findmnt.
(cherry picked from commit 9cb0b49673)
Reason: No-one should use signal-desktop-beta anymore, especially since
the signal-desktop updates where cherry-picked (up to version 1.11.0).
This version should not be affected by CVE-2018-10994, CVE-2018-11101
or any other security issues but it's better to be safe than sorry.
The Datadog agent requires `gohai` to be available on its `$PATH` in
order to collect certain metrics.
It would previously start up and collect certain types of metrics, but
log errors related to the missing gohai binary.
This commit configures the systemd-unit to make gohai available at
runtime.
This fixes#39810.
(cherry picked from commit f4c87183df)
This project does not have a default versioning scheme. go2nix
suggests using the date of the most recent change.
(cherry picked from commit ab500439cd)
dmd,dtools,dub: 2.079.0 -> 2.079.1 and wrap ldc2 binary with $CC
(cherry picked from commit 4aa04d185c)
Reason: This bumps the version to a newer release and fixes package
issues.
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/zziplib/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzcat -h` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzcat --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzcat help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzcat --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzdir --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzdir --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcat -h` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcat --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcat help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcat --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxordir -h` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxordir --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxordir --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcopy -h` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcopy --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/zzxorcopy --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip -v` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-mix --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-mix -v` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-mix --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-mem --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-mem -v` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-mem --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-big --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-big -v` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzzip-big --version` and found version 0.13.69
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzip-mem -h` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzip-mem --help` got 0 exit code
- ran `/nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69/bin/unzip-mem --version` and found version 0.13.69
- found 0.13.69 with grep in /nix/store/9lh4yxh3lq6mv354jvbd3gqjv4dha740-zziplib-0.13.69
- directory tree listing: https://gist.github.com/fec112f9114c98b118a59917224af5ff
(cherry picked from commit 3f36f6095f)
Split `buildCommand`, provide `unpackCmd` and add `installPhase`.
Use autoPatchelfHook, we can get rid of all the manual hacking around
with patchelf.
Use install to install to $out
(cherry picked from commit fe56ad70f0)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/wireguard-tools/versions.
These checks were done:
- built on NixOS
- /nix/store/c48vhaf6wqmra1g6sv4hv3i6vqlw7ll1-wireguard-tools-0.0.20180519/bin/wg passed the binary check.
- /nix/store/c48vhaf6wqmra1g6sv4hv3i6vqlw7ll1-wireguard-tools-0.0.20180519/bin/wg-quick passed the binary check.
- 2 of 2 passed binary check by having a zero exit code.
- 0 of 2 passed binary check by having the new version present in output.
- found 0.0.20180519 with grep in /nix/store/c48vhaf6wqmra1g6sv4hv3i6vqlw7ll1-wireguard-tools-0.0.20180519
- directory tree listing: https://gist.github.com/64bccf9c57ca84c49486890ccbf17239
- du listing: https://gist.github.com/f28d6cfd8bcbf6ab1a6c39ad40ce1606
(cherry picked from commit 410be1aa1d)
Update includes 4 security fixes, including one critical (see [0]):
* [835887] Critical: Chain leading to sandbox escape. Reported by Anonymous on 2018-04-23:
* [836858] High CVE-2018-6121: Privilege Escalation in extensions.
* [836141] High CVE-2018-6122: Type confusion in V8.
* [$5000][833721] High CVE-2018-6120: Heap buffer overflow in PDFium. Reported by Zhou Aiting(@zhouat1) of Qihoo 360 Vulcan Team on 2018-04-17
[0] https://chromereleases.googleblog.com/2018/05/stable-channel-update-for-desktop.html
PS: Didn't build Beta and Dev, verified only Stable for now
cc @bendlas @aszlig
(cherry picked from commit 18370267ef)
previously, $ORACLE_HOME had to be set for each python script using this
library.
We now patch odpi to load libclntsh.so from oracle-instantclient if
$ORACLE_HOME was not provided.
(cherry picked from commit 639f7952be)
If docker is enabled, start mesos-slave.service after docker.service
to avoid a race condition that could result in mesos-slave to fail
with "Failed to create docker: Timed out getting docker version"
(cherry picked from commit ec00b6fbb3)
- refactor into single file for all versions
- improve timing, prevent non-deterministic failures
- fix tests for i686-linux
(cherry picked from commit 13f83ba05f)
Assigning a list of 10 or more elements to an option having the type
`loaOf a` produces a configuration value that is not honoring the
order of the original list. This commit fixes this and a related issue
arising when 10 or more lists are merged into this type of option.
(cherry picked from commit 08e8701673)
Things done:
- use libGLU instead of mesa for darwin support
- move patches from local to github url
- fixup xquartz install
There may still be some issues at runtime. PRs welcome!
Fixes#40196
(cherry picked from commit c839771129)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/raw-identify -h` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/raw-identify --help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/raw-identify help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/unprocessed_raw -h` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/unprocessed_raw --help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/unprocessed_raw help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/unprocessed_raw -V` and found version 0.18.8
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/unprocessed_raw -v` and found version 0.18.8
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/unprocessed_raw --version` and found version 0.18.8
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/unprocessed_raw -h` and found version 0.18.8
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/unprocessed_raw --help` and found version 0.18.8
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/4channels -h` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/4channels --help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/4channels help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/4channels -V` and found version 0.18.8
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/4channels -v` and found version 0.18.8
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/4channels --version` and found version 0.18.8
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/4channels -h` and found version 0.18.8
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/4channels --help` and found version 0.18.8
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/simple_dcraw -h` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/simple_dcraw --help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/simple_dcraw help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/mem_image -h` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/mem_image --help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/mem_image help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/dcraw_half -h` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/dcraw_half --help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/dcraw_half help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/half_mt -h` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/half_mt --help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/half_mt help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/multirender_test -h` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/multirender_test --help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/multirender_test help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/postprocessing_benchmark -h` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/postprocessing_benchmark help` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/dcraw_emu -h` got 0 exit code
- ran `/nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8/bin/dcraw_emu help` got 0 exit code
- found 0.18.8 with grep in /nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8
- found 0.18.8 in filename of file in /nix/store/k3cxddpbxlpyp3dx8gqif6s7c63zzbrm-libraw-0.18.8
(cherry picked from commit f3d17b66fb)
This is optional (`libcardiacarrest` has a workaround for this bug
because there's `firefox-bin` that I can't fix), but with this applied things
are a bit smoother.
... to avoid race condition between udevd renaming and
networkd configuring interfaces (39069)
Fixes non-deterministic failure of
nixos.tests.predictable-interface-names.vm-test-run-predictableInterfaceNames-with-networkd
(cherry picked from commit 236703f9f3)
However, none of the exporters I tried actually _worked_, but now
shutter at least returns an error to the user (pop-up UI element)
instead of silently hanging and only leaving messages on stdout/stderr
about the missing deps.
AFAICS, this changes the failure of Screenshot->Export functionality
from a packaging bug to an application bug (upstream).
(cherry picked from commit 8a5b142545)
When opening `shutter` it adds an indicator icon to the status bar.
However this doesn't happen (and an ugly default icon will be used) if
`shutter` can't find the `hicolor-icon-theme`. In such a case a warning
like this can be found in `stderr`:
```
Gtk-WARNING **: Could not find the icon 'image-png'. The 'hicolor' theme
was not found either, perhaps you need to install it.
```
As I don't think that we should force users to install this theme
globally and several other packages including `tor-browser`, `gparted`
or `clawsmail` add `hicolor-icon-theme` to their closure this seems to
be a fair measure.
(cherry picked from commit 40226e647e)
In newer versions, instead of using $PWD to locate its ressource files,
Refind now refers to the dir containing $0.
This causes runtime errors due to missing ressources.
In lieu a wrapper binary, we now simply patch the variable 'RefindDir'
which stores the path to the ressource dir.
(cherry picked from commit adce6bf638)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/uftp/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/97wm1cjgqd5ih45689h2xmqfv7ywv8bi-uftp-4.9.6/bin/uftpd help’ got 0 exit code
- ran ‘/nix/store/97wm1cjgqd5ih45689h2xmqfv7ywv8bi-uftp-4.9.6/bin/uftp_keymgt -h’ got 0 exit code
- ran ‘/nix/store/97wm1cjgqd5ih45689h2xmqfv7ywv8bi-uftp-4.9.6/bin/uftp_keymgt --help’ got 0 exit code
- ran ‘/nix/store/97wm1cjgqd5ih45689h2xmqfv7ywv8bi-uftp-4.9.6/bin/uftp_keymgt help’ got 0 exit code
- found 4.9.6 with grep in /nix/store/97wm1cjgqd5ih45689h2xmqfv7ywv8bi-uftp-4.9.6
- directory tree listing: https://gist.github.com/c08d432d7a238559a904561aa46161bd
On nixpkgs master/staging we have 2.32 - that includes this patch.
https://nvd.nist.gov/vuln/detail/CVE-2018-7738 claims 2.32-rc1 fixes
this and upstream master hasn't changed umount completion except for
this patch, so it has to be it. /cc #38994.
To mitigate Spectre Variant 2, GCC needs to have retpoline
support (-mindirect-branch and -mfunction-return arguments on amd64
and i386).
Patches were pulled from H.J. Lu's backport branch to
4.9 (hjl/indirect/gcc-4_9-branch), available at
https://github.com/hjl-tools/gcc/tree/hjl/indirect/gcc-4_9-branch/master. Upstream
GCC does not apply patches to anything older than the
gcc-6-branch. H.J. Lu is the author of the upstream retpoline commits
as well.
Several Linux distributions already backported these patches to GCC 4
branches and some old kernels (3.13 for instance) have been recompiled
with these GCC patches. These kernels only allow to load kernel
modules that are compiled with the retpoline support.
References:
- Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1749261
- Ubuntu package: https://launchpad.net/ubuntu/+source/gcc-4.8/4.8.4-2ubuntu1~14.04.4Fixes#38394
(cherry picked from commit ada2fc088c)
* fetchs3: add configurable name
Change the default from "foo" to the basename of the s3 URL and make it
configurable.
* fetchs3: fix error on missing credentials.session_token
The session token should default to null instead of failing
* fetchs3: make use of the region argument
Set it to null if you don't want to use it
* fetchs3: prefer local build
Fetcher-types spend more time on network than CPU
(cherry picked from commit f7abcb0752)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/youtube-dl/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/3dkc0vhb4v2fyagm0p33r54f6j89sjb0-youtube-dl-2018.04.16/bin/.youtube-dl-wrapped -h’ got 0 exit code
- ran ‘/nix/store/3dkc0vhb4v2fyagm0p33r54f6j89sjb0-youtube-dl-2018.04.16/bin/.youtube-dl-wrapped --help’ got 0 exit code
- ran ‘/nix/store/3dkc0vhb4v2fyagm0p33r54f6j89sjb0-youtube-dl-2018.04.16/bin/.youtube-dl-wrapped --version’ and found version 2018.04.16
- ran ‘/nix/store/3dkc0vhb4v2fyagm0p33r54f6j89sjb0-youtube-dl-2018.04.16/bin/youtube-dl -h’ got 0 exit code
- ran ‘/nix/store/3dkc0vhb4v2fyagm0p33r54f6j89sjb0-youtube-dl-2018.04.16/bin/youtube-dl --help’ got 0 exit code
- ran ‘/nix/store/3dkc0vhb4v2fyagm0p33r54f6j89sjb0-youtube-dl-2018.04.16/bin/youtube-dl --version’ and found version 2018.04.16
- found 2018.04.16 with grep in /nix/store/3dkc0vhb4v2fyagm0p33r54f6j89sjb0-youtube-dl-2018.04.16
- directory tree listing: https://gist.github.com/359ce5add8ebf04a1dfe79aecb499137
(cherry picked from commit 65d5a82729)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/youtube-dl/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/xh1vx2vp7syc711vijy1qs452xxkmk1n-youtube-dl-2018.03.26.1/bin/.youtube-dl-wrapped -h` got 0 exit code
- ran `/nix/store/xh1vx2vp7syc711vijy1qs452xxkmk1n-youtube-dl-2018.03.26.1/bin/.youtube-dl-wrapped --help` got 0 exit code
- ran `/nix/store/xh1vx2vp7syc711vijy1qs452xxkmk1n-youtube-dl-2018.03.26.1/bin/youtube-dl -h` got 0 exit code
- ran `/nix/store/xh1vx2vp7syc711vijy1qs452xxkmk1n-youtube-dl-2018.03.26.1/bin/youtube-dl --help` got 0 exit code
- found 2018.03.26.1 with grep in /nix/store/xh1vx2vp7syc711vijy1qs452xxkmk1n-youtube-dl-2018.03.26.1
- directory tree listing: https://gist.github.com/0697ddb269c38c62a33bd198ac505324
(cherry picked from commit ba580b84b7)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/slurm/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/kpn869z54bm58ib47qmv74lv01dfyp4f-slurm-17.11.5/bin/sattach -h` got 0 exit code
- ran `/nix/store/kpn869z54bm58ib47qmv74lv01dfyp4f-slurm-17.11.5/bin/sattach --help` got 0 exit code
- ran `/nix/store/kpn869z54bm58ib47qmv74lv01dfyp4f-slurm-17.11.5/bin/sattach -V` and found version 17.11.5
- ran `/nix/store/kpn869z54bm58ib47qmv74lv01dfyp4f-slurm-17.11.5/bin/sattach --version` and found version 17.11.5
- ran `/nix/store/kpn869z54bm58ib47qmv74lv01dfyp4f-slurm-17.11.5/bin/slurmd -h` got 0 exit code
- ran `/nix/store/kpn869z54bm58ib47qmv74lv01dfyp4f-slurm-17.11.5/bin/slurmd -V` and found version 17.11.5
- found 17.11.5 with grep in /nix/store/kpn869z54bm58ib47qmv74lv01dfyp4f-slurm-17.11.5
- directory tree listing: https://gist.github.com/a4fb120a8f87f92e70daccf30910015b
(cherry picked from commit 0e0b80d4b4)
xdotool failed in rare cases when a window was already created
but not yet decorated by the window manager.
also prevent a (never observed but possible) race condition
(cherry picked from commit 6891bda370)
This is a very very very ugly workaround and it's because Chromium seems
to eat keystroke for a few seconds after a new window is created.
I haven't found a better solution yet, so let's at least unbreak the
test until we come up with a better way.
Thanks to @vcunat for bringing this to my attention and also doing the
initial bisect.
The change that brought up this problem was 2b29e40153,
which updated Chromium from version 65.0.3325.181 to version
66.0.3359.117. Unfortunately the upstream changelog[1] is way too large
to actually guess what the breaking change is.
[1]: https://chromium.googlesource.com/chromium/src/+log/65.0.3325.181..66.0.3359.117?pretty=fuller&n=10000
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @bendlas, @vcunat
(cherry picked from commit 1b1b76f70a)
It was found that Quassel could be remotely crashed and had an
unauthenticated RCE vulnerability. The public annoucement can be found
on the oss-sec archive [1]. The added patches are supposed fix both issues.
[1] http://seclists.org/oss-sec/2018/q2/77
This adds some documentation about importing modules external to
Nixpkgs, which provides context for documenting
NIXOS_EXTRA_MODULE_PATH.
Closes#30376
(cherry picked from commit 1cc97befd5)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/cups-filters/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/h8hpf5fjx7fg0p1sv9yyvg6b803k61k4-cups-filters-1.20.3/bin/foomatic-rip -h’ got 0 exit code
- ran ‘/nix/store/h8hpf5fjx7fg0p1sv9yyvg6b803k61k4-cups-filters-1.20.3/bin/foomatic-rip --help’ got 0 exit code
- found 1.20.3 with grep in /nix/store/h8hpf5fjx7fg0p1sv9yyvg6b803k61k4-cups-filters-1.20.3
- directory tree listing: https://gist.github.com/aa62a318dc23326b357322da3e567915
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 1.20.1 with grep in /nix/store/233chsllrfymrvizn74nf8sav0r0llrb-cups-filters-1.20.1
@cleverca found this bug in the declarative hooks config. Any shell
variables referenced in a hook script would get expanded by the hooks
directory builder.
Prevent variable expansion by quoting the here doc limit string.
(cherry picked from commit 3e446ecd56)
Signed-off-by: Domen Kožar <domen@dev.si>
The previous code for this accidentally picked up a "p" when computing the partition number.
This logic should be more robust
fixes#39491
(cherry picked from commit 3a47c7e8f6)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/notmuch/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/05v4k89ni4phwyxvqskr0hji49b5fmck-notmuch-0.26.1/bin/notmuch --help’ got 0 exit code
- ran ‘/nix/store/05v4k89ni4phwyxvqskr0hji49b5fmck-notmuch-0.26.1/bin/notmuch help’ got 0 exit code
- ran ‘/nix/store/05v4k89ni4phwyxvqskr0hji49b5fmck-notmuch-0.26.1/bin/notmuch --version’ and found version 0.26.1
- found 0.26.1 with grep in /nix/store/05v4k89ni4phwyxvqskr0hji49b5fmck-notmuch-0.26.1
- directory tree listing: https://gist.github.com/adeae189f9ac416571a7c0e3beca712f
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/xmr-stak/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/xdp6rb1bvdmpkd77vbqq8dq175dfvrvl-xmr-stak-2.4.3/bin/xmr-stak -h’ got 0 exit code
- ran ‘/nix/store/xdp6rb1bvdmpkd77vbqq8dq175dfvrvl-xmr-stak-2.4.3/bin/xmr-stak --help’ got 0 exit code
- found 2.4.3 with grep in /nix/store/xdp6rb1bvdmpkd77vbqq8dq175dfvrvl-xmr-stak-2.4.3
- directory tree listing: https://gist.github.com/ba044f08ae439ad36ac7e143f14e0fb0
(cherry picked from commit 42f2bd3a5d)
I've rebuild all packages that depend on gpgme and everything seems fine
so far (there are a few failures but the ones I've checked are unrelated
to gpgme).
Upstream release notes (Noteworthy changes in version 1.11.1):
* Fixed build problems in the 1.11.0 release.
* Added C++ interfaces which were planned for 1.11.0.
The 1.11.0 release came with these changes:
* New encryption API to support direct key specification including
hidden recipients option and taking keys from a file. This also
allows to enforce the use of a subkey.
* New encryption flag for the new API to enforce the use of plain
mail addresses (addr-spec).
* The import API can now tell whether v3 keys are skipped. These old
and basically broken keys are not anymore supported by GnuPG 2.1.
* The decrypt and verify API will now return the MIME flag as
specified by RFC-4880bis.
* The offline mode now has an effect on gpg by disabling all network
access. [#3831]
* A failed OpenPGP verification how returns the fingerprint of the
intended key if a recent gpg version was used for signature
creation.
* New tool gpgme-json as native messaging server for web browsers.
As of now public key encryption and decryption is supported.
Requires Libgpg-error 1.29.
* New context flag "request-origin" which has an effect when used
with GnuPG 2.2.6 or later.
* New context flag "no-symkey-cache" which has an effect when used
with GnuPG 2.2.7 or later.
* New convenience constant GPGME_KEYLIST_MODE_LOCATE.
* Improved the Python documentation.
* Fixed a potential regression with GnuPG 2.2.6 or later.
* Fixed a crash in the Python bindings on 32 bit platforms. [#3892]
* Various minor fixes.
(cherry picked from commit f76c842706)
Contains fixes for CVE-2018-1110.
(cherry picked from commit 2becf90c93)
The server unavailabality caching is a "potentially breaking" change
for some use cases, but as it seems OK on 1.1.1.1, I think we're good
for 18.03 as well.
Nothing probably uses this, but let's be pedantic and have the
pre-included channel on the install media be as close as possible to
what 'nix-channel --update' will give them.
The only remaining difference is that the channel adds programs.sqlite,
which is fundamentally unfixable.
(cherry picked from commit bd77849b2f)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 2.4.5 with grep in /nix/store/l4nmjlanshgdwrh95g1h0714zcm1kk3z-exempi-2.4.5
- directory tree listing: https://gist.github.com/2d437e9ea408cfda7abaa772865a0b82
(cherry picked from commit 34682ddc49)
Critical CVE-2018-6085: Use after free in Disk Cache. Reported by Ned Williamson on 2018-03-28
Critical CVE-2018-6086: Use after free in Disk Cache. Reported by Ned Williamson on 2018-03-30
High CVE-2018-6087: Use after free in WebAssembly. Reported by Anonymous on 2018-02-20
High CVE-2018-6088: Use after free in PDFium. Reported by Anonymous on 2018-03-15
High CVE-2018-6089: Same origin policy bypass in Service Worker. Reported by Rob Wu on 2018-02-04
High CVE-2018-6090: Heap buffer overflow in Skia. Reported by ZhanJia Song on 2018-03-12
High CVE-2018-6091: Incorrect handling of plug-ins by Service Worker. Reported by Jun Kokatsu (@shhnjk) on 2017-10-05
High CVE-2018-6092: Integer overflow in WebAssembly. Reported by Natalie Silvanovich of Google Project Zero on 2018-03-08
Medium CVE-2018-6093: Same origin bypass in Service Worker. Reported by Jun Kokatsu (@shhnjk) on 2017-11-01
Medium CVE-2018-6094: Exploit hardening regression in Oilpan. Reported by Chris Rohlf on 2016-08-01
Medium CVE-2018-6095: Lack of meaningful user interaction requirement before file upload. Reported by Abdulrahman Alqabandi (@qab) on 2016-08-11
Medium CVE-2018-6096: Fullscreen UI spoof. Reported by WenXu Wu of Tencent's Xuanwu Lab on 2017-10-19
Medium CVE-2018-6097: Fullscreen UI spoof. Reported by xisigr of Tencent's Xuanwu Lab on 2018-01-26
Medium CVE-2018-6098: URL spoof in Omnibox. Reported by Khalil Zhani on 2018-01-03
Medium CVE-2018-6099: CORS bypass in ServiceWorker. Reported by Jun Kokatsu (@shhnjk) on 2018-02-03
Medium CVE-2018-6100: URL spoof in Omnibox. Reported by Lnyas Zhang on 2018-02-11
Medium CVE-2018-6101: Insufficient protection of remote debugging prototol in DevTools . Reported by Rob Wu on 2018-02-19
Medium CVE-2018-6102: URL spoof in Omnibox. Reported by Khalil Zhani on 2018-02-20
Medium CVE-2018-6103: UI spoof in Permissions. Reported by Khalil Zhani on 2018-02-24
Medium CVE-2018-6104: URL spoof in Omnibox. Reported by Khalil Zhani on 2018-03-08
Medium CVE-2018-6105: URL spoof in Omnibox. Reported by Khalil Zhani on 2018-01-18
Medium CVE-2018-6106: Incorrect handling of promises in V8. Reported by lokihardt of Google Project Zero on 2018-01-25
Medium CVE-2018-6107: URL spoof in Omnibox. Reported by Khalil Zhani on 2018-02-02
Medium CVE-2018-6108: URL spoof in Omnibox. Reported by Khalil Zhani on 2018-02-27
Low CVE-2018-6109: Incorrect handling of files by FileAPI. Reported by Dominik Weber (@DoWeb_) on 2017-04-10
Low CVE-2018-6110: Incorrect handling of plaintext files via file:// . Reported by Wenxiang Qian (aka blastxiang) on 2017-10-24
Low CVE-2018-6111: Heap-use-after-free in DevTools. Reported by Khalil Zhani on 2017-11-02
Low CVE-2018-6112: Incorrect URL handling in DevTools. Reported by Rob Wu on 2017-12-29
Low CVE-2018-6113: URL spoof in Navigation. Reported by Khalil Zhani on 2018-01-25
Low CVE-2018-6114: CSP bypass. Reported by Lnyas Zhang on 2018-02-13
Low CVE-2018-6115: SmartScreen bypass in downloads. Reported by James Feher on 2018-03-07
Low CVE-2018-6116: Incorrect low memory handling in WebAssembly. Reported by Jin from Chengdu Security Response Center of Qihoo 360 Technology Co. Ltd. on 2018-03-15
Low CVE-2018-6117: Confusing autofill settings. Reported by Spencer Dailey on 2018-03-15
Low CVE-2018-6084: Incorrect use of Distributed Objects in Google Software Updater on MacOS. Reported by Ian Beer of Google Project Zero on 2018-03-15
(cherry picked from commit 2b29e40153)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 5.0.3 with grep in /nix/store/g5hcg35wmg25sgfjp7mvi4cx3shldbxd-libXfixes-5.0.3
- directory tree listing: https://gist.github.com/7398ada0908969ebbd1e7e629a1e0ef7
(cherry picked from commit 0e443ceb9e)
Only fixes CVE-2016-7944; /cc #38994.
All imake (xmkmf) based builds use the lib/X11/config/darwin.cf file to
define locations of cpp, cc, c++ (in /usr/bin by default). We remove the
directoy part to force darwin builds to search the $PATH for those
commands.
(cherry picked from commit 820da05d78)
- mkfs.fat needs `-n` to set a partition label, not `-L`.
- create /mnt/boot before mounting
- leave out detailed LVM example as advanced users already how to create
LVs while it is detracting for novices.
Re #38674
(cherry picked from commit bca80d67a0)
This is needed because simp_le expects two certificates in fullchain.pem, leading to error:
> Not enough PEM encoded messages were found in fullchain.pem; at least 2 were expected, found 1.
We now create a CA and sign the key with it instead, providing correct fullchain.pem.
Also cleanup service a bit -- use PATH and a private temporary directory (which
is more suitable).
(cherry picked from commit 4fc0b4edca)
Fixes#39012.
Semi-automatic update. These checks were done:
- built on NixOS
- ran `/nix/store/p5k6zxrdcnl84xjnkicm3wblq20c82l5-git-review-1.26.0/bin/.git-review-wrapped -h` got 0 exit code
- ran `/nix/store/p5k6zxrdcnl84xjnkicm3wblq20c82l5-git-review-1.26.0/bin/.git-review-wrapped --help` got 0 exit code
- ran `/nix/store/p5k6zxrdcnl84xjnkicm3wblq20c82l5-git-review-1.26.0/bin/.git-review-wrapped --version` and found version 1.26.0
- ran `/nix/store/p5k6zxrdcnl84xjnkicm3wblq20c82l5-git-review-1.26.0/bin/git-review -h` got 0 exit code
- ran `/nix/store/p5k6zxrdcnl84xjnkicm3wblq20c82l5-git-review-1.26.0/bin/git-review --help` got 0 exit code
- ran `/nix/store/p5k6zxrdcnl84xjnkicm3wblq20c82l5-git-review-1.26.0/bin/git-review --version` and found version 1.26.0
- found 1.26.0 with grep in /nix/store/p5k6zxrdcnl84xjnkicm3wblq20c82l5-git-review-1.26.0
- found 1.26.0 in filename of file in /nix/store/p5k6zxrdcnl84xjnkicm3wblq20c82l5-git-review-1.26.0
(cherry picked from commit dafc368d72)
This fixes the bug introduced by 8686b98612 which broke bundlerEnv
exprs when gemdir was a string (thus making gemset a string by
`gemset = gemdir + "/gemset.nix"`) which made it being treated as a
set.
(cherry picked from commit a6a2e75804)
Since the script running is a failure condition, we should fail the
build properly, not leaving it up to the missing output to determine
that the build went wrong. This should partly address #38952 — nix
build will print out the build log on non-zero exits.
(cherry picked from commit 4a30f2efec)
exportReferencesGraph is deprecated and doesn't have the generated
initial Nix database contain the SHA256 of the contents of the store
paths, which breaks various things under Nix 2.0.
(cherry picked from commit 487be791d7)
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/pick/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/mr0512zhzbbarb99l6v31pgsw1f8k859-pick-2.0.2/bin/pick -h’ got 0 exit code
- ran ‘/nix/store/mr0512zhzbbarb99l6v31pgsw1f8k859-pick-2.0.2/bin/pick -v’ and found version 2.0.2
- found 2.0.2 with grep in /nix/store/mr0512zhzbbarb99l6v31pgsw1f8k859-pick-2.0.2
- directory tree listing: https://gist.github.com/797cf336b38181f76cab1e08936713b1
(cherry picked from commit ab96418801)
- add ncurses: configure links against ncurses and fails otherwise
configure: error: Could not link test program to Python.
https://travis-ci.org/NixOS/nixpkgs/builds/48759067
The given hint (Maybe the main Python library has been installed
in some non-standard library path) is misleading.
The config.log reveals that the failure is due to missing ncurses link option
- with-boost-libdir is need to find Boost::IOStreams/regex/etc.
- expat/cgal are detected in /usr/lib when not specified explicitly
- boost > boost159 is needed to have -lboost_python3 (and -lboost_python)
- set pythonModule = Python;
=> inorder to be used in python.buildEnv { extraLibs = [..]; }
tested on MacOSX and in a linux Docker container with:
> nix-shell -I nixpkgs=. -p python2.pkgs.graph-tool
> nix-shell -I nixpkgs=. -p python3.pkgs.graph-tool
(cherry picked from commit a842f0e905)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/hpx/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/xg48bc9gkcq2hyk51hxy5s7x8l0s70r9-hpx-1.1.0/bin/hpxrun.py -h` got 0 exit code
- ran `/nix/store/xg48bc9gkcq2hyk51hxy5s7x8l0s70r9-hpx-1.1.0/bin/hpxrun.py --help` got 0 exit code
- found 1.1.0 with grep in /nix/store/xg48bc9gkcq2hyk51hxy5s7x8l0s70r9-hpx-1.1.0
- found 1.1.0 in filename of file in /nix/store/xg48bc9gkcq2hyk51hxy5s7x8l0s70r9-hpx-1.1.0
- directory tree listing: https://gist.github.com/377d8c673231332bb40acb55fed39e53
(cherry picked from commit e28170ccc8)
The `1822-release` build breaks on Hydra, some days ago the stable
`2.2.0` release has been tagged on upstream.
It required some new build inputs (zlib, curl, SDL2_mixer, python3) and
some minor changes in the cmakeFlags and makeFlags for the build.
See https://hydra.nixos.org/build/71818713/log
See ticket #36453 and #31747
(cherry picked from commit d7894d022c)
Otherwise the build system computes incorrect references and looks for
perf-core in /libexec. DESTDIR for normal buildsystems is never the
right choice for nixpkgs.
(cherry picked from commit 0e2b222c24)
Semi-automatic update. These checks were performed:
- built on NixOS
- found 1.19.2 with grep in /nix/store/f45rl4z9a2rqd7hdhwnj9g831z1k4ilr-libuv-1.19.2
- found 1.19.2 in filename of file in /nix/store/f45rl4z9a2rqd7hdhwnj9g831z1k4ilr-libuv-1.19.2
cc "@cstrahan"
(cherry picked from commit 04ec090f6f)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/.nextcloud-news-updater-wrapped -h` got 0 exit code
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/.nextcloud-news-updater-wrapped --help` got 0 exit code
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/.nextcloud-news-updater-wrapped -v` and found version 10.0.1
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/.nextcloud-news-updater-wrapped --version` and found version 10.0.1
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/nextcloud-news-updater -h` got 0 exit code
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/nextcloud-news-updater --help` got 0 exit code
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/nextcloud-news-updater -v` and found version 10.0.1
- ran `/nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1/bin/nextcloud-news-updater --version` and found version 10.0.1
- found 10.0.1 with grep in /nix/store/58kz8y29n2habv056d7iz20484rq87mr-nextcloud-news-updater-10.0.1
- directory tree listing: https://gist.github.com/ef3eb260a3fd46598a3b70c142c2ef2c
(cherry picked from commit a7046d5ecf)
With #36556, a check was introduced to make sure the user and group
names do not exceed their respective maximum length. This is in part
because systemd also enforces that length, but only at runtime.
So in general it's a good idea to catch as much as we can during
evaluation time, however the maximum length of the group name was set to
16 characters according groupadd(8).
The maximum length of the group names however is a compile-time option
and even systemd allows more than 16 characters. In the mentioned pull
request (#36556) there was already a report that this has broken
evaluation for people out there.
I have also checked what other distributions are doing and they set the
length to either 31 characters or 32 characters, the latter being more
common.
Unfortunately there is a difference between the maximum length enforced
by the shadow package and systemd, both for user name lengths and group
name lengths. However, systemd enforces both length to have a maximum of
31 characters and I'm not sure if this is intended or just a off-by-one
error in systemd.
Nevertheless, I choose 32 characters simply to bring it in par with the
maximum user name length.
For the NixOS assertion however, I use a maximum length of 31 to make
sure that nobody accidentally creates services that contain group names
that systemd considers invalid because of a length of 32 characters.
Signed-off-by: aszlig <aszlig@nix.build>
Closes: #38548
Cc: @vcunat, @fpletz, @qknight
(cherry picked from commit 99ba1cb424)
Setting the hash to null is a convenient way to bypass the hash check
while developing. It looks like the ability to do this was inadvertently
removed while adding vendor directory support.
This still checks that the user is explicitly setting the value but
allows null as a valid option.
(cherry picked from commit 4499513e54)
The required argument 'hostPlatform' was missing from linuxPackages_custom's
call to linuxManualConfig.
In order to prevent this in the future, this commit adds
linuxPackages_custom_tinyconfig_kernel so linuxPackages_custom gets tested.
This also adds linuxConfig, to derivate default linux configurations
via make defconfig, make tinyconfig, etc.
Closes#38035.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 0.1.9 with grep in /nix/store/nrg54a2kxlz3r8c4wf2if5vzq0y452fs-libopenshot-0.1.9
- found 0.1.9 in filename of file in /nix/store/nrg54a2kxlz3r8c4wf2if5vzq0y452fs-libopenshot-0.1.9
- directory tree listing: https://gist.github.com/a521e923923cd5ac4f188b8dede33a2e
Upstream requested that we remove these packages until the first stable
release. More details are in #38344. This isn't ideal but it seems like
the best solution for now.
Close#38344.
(cherry picked from commit 9db699e4a3)
Reason: Disable these two packages before anyone starts using them.
Especially on the stable branch (NixOS 18.03) these packages are of no
use (due to the lack of updates) and might result in unwanted upstream
bug reports.
This path changed from $out/lib/neomutt to $out/libexec/neomutt.
(cherry picked from commit 80faa73fc0)
Reason: This fix is required to use OpenPGP encryption (via GnuPG) in
NeoMutt with the default gpg.rc [0]. (When using crypt_use_gpgme this
fix isn't required.)
[0]: 32dfd7baf3/contrib/gpg.rc
Currently ahead of the upgrade to webkitgtk220x, this will make future
webkitgtk maintenance easier.
WebkitGTK, from 2.6 onwards has maintained API stability and will
continue to do so, as opposed to the jump from 2.4 to 2.6
cc @rickynils
(cherry picked from commit 80582c600d)
Currently ahead of the upgrade to webkitgtk220x, this will make future
webkitgtk maintenance easier.
WebkitGTK, from 2.6 onwards has maintained API stability and will
continue to do so, as opposed to the jump from 2.4 to 2.6
(cherry picked from commit 0b8d7fb16e)
symlink shared libraries from LD_LIBRARY_PATH into lib/julia,
as using a wrapper with LD_LIBRARY_PATH causes segmentation
faults when program returns an error:
$ julia -e 'throw(Error())'
only applied for 0.6, which is the current julia version. Will
see if we can remove the older versions in master.
- Rectifies diverging CSS by combining
nixos/nixpkgs docs CSS
- Moves our custom Highlight.js loader in to
the hljs package
- Switches the nixos docs to use SVG
callouts too
(cherry picked from commit 8f33464ca7)
Since GHC is a cross compiler, it's perfectly possible to make haskell
binaries on platforms without GHCs. `windows ++ unix` seems good enough
for now.
Also don't default `hydraPlatforms` to `platforms`. The former must be a
list of systems (strings), but the latter is a list of systems or
patterns.
(cherry picked from commit 65e24f22e6)
Otherwise obscure cross-compilations are hampered. `all` breaks all but
the initial derivation (which we can't even write yet) in an open world
setting however, so we really shouldn't have it.
(cherry picked from commit 3c8ae01a45)
Update all factorio packages to their latest version. The fact that the
experimental version is lower than the alpha version is just because
they haven't made an experimental release after the last stable.
(cherry picked from commit f56b733e31)
https://hydra.nixos.org/build/70700906
I opened an upstream bug, but their bug system is e-mail based and I
haven't got a single reply which contains an web link :(
(cherry picked from commit af16d71e88)
Without this change pkgconfig files contain incorrect values for libdir and
includedir in the form of:
prefix: /nix/store/...liblibqtxdg
libdir: ${prefix}//nix/store/.../libqtxdg/lib
includedir: ${prefix}//nix/store/.../libqtxdg/include
(cherry picked from commit a1fec88085)
We should be able to deploy a NixOS 18.03 system with the current nixops
stable release. Some options were renamed, so instead of
`mkRenamedOptionModule` we introduce them as read-only interal options
that won't be rendered in the manual.
Only the options that are needed to make nixops evaluations succeed were
added.
This commit should probably be reverted after or before the 18.09 release,
depending on the nixops 1.6 release.
The user will not get the warning that these have been renamed but
this change is mentioned in the release notes.
Fixes#34253.
(cherry picked from commit 70c6f6572d)
- Add `imageName` and `imageBaseName` options similar to the `isoName`
and `isoBaseName` options
- Make the filename of the iso match what iso-image.nix does
- Generate a nix-support/hydra-build-products like iso-image.nix does
(cherry picked from commit 4c21180a13)
service-runner had a backwards incompatible update, and parsoid 0.9.0
doesn't work with current stable MediaWiki. Instead use as a source
a repository with 0.8.0 and pinned service-runner version.
(cherry picked from commit 37546be900)
Darwin machines come with a case-insensitive filesystem by default. The
gflags package's source contains a file 'BUILD' and the build process
attempts to create a directory called 'build', which fails on
case-insensitive filesystems.
Add a prePatch hook to rename the BUILD file (which is for use with an
unrelated build tool) to something that doesn't conflict with the
'build' directory. This hook allows this derivation to be built on
case-insensitive filesystems.
Add metadata to the derivation because previously it had none.
(cherry picked from commit 66bbee3b81)
`pythonPackages.prov` has been bumped to `1.5.2`, however `nipype`
pinned `prov` to `1.5.0`. Patching `nipype/info.py` fixes this issue by
bumping to the current `prov` version in nixpkgs.
See https://hydra.nixos.org/build/71817962/log
See ticket #36453
(cherry picked from commit db0fa06fce)
Tests broke on Hydra as the `checkPhase` wasn't configured properly. By
explicitly relying on `nosetests` and injecting `LC_ALL` into the
`checkPhase` the tests work again.
The license (bsd3) according to `LICENSE` distributed with the upstream
package wasn't specified in the meta section which could've caused legal
issues.
The expression has been moved into its own file to reduce the length and
complexity of `pkgs/top-level/python-packages.nix`.
See https://hydra.nixos.org/build/70689499/log
See #36453
(cherry picked from commit 9215e03e17)
Note: the previous version was not building due to outdated upstream
dependencies.
(cherry picked from commit 1e1839239c)
Signed-off-by: Domen Kožar <domen@dev.si>
The dovecot bump to 2.3.1 caused the dovecot service to fail to start
because it would try to chgrp sockets to dovecot whereas our default
dovecot group is called dovecot2.
(cherry picked from commit 6a15c8d6f7)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/dovecot/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/c20ip7wyymd39l7zisx38ky3bxp1sybv-dovecot-2.3.1/bin/dovecot --help` got 0 exit code
- ran `/nix/store/c20ip7wyymd39l7zisx38ky3bxp1sybv-dovecot-2.3.1/bin/dovecot --version` and found version 2.3.1
- found 2.3.1 with grep in /nix/store/c20ip7wyymd39l7zisx38ky3bxp1sybv-dovecot-2.3.1
- directory tree listing: https://gist.github.com/6d90467ee7649d7efc0a48eeacfc42c8
(cherry picked from commit a668ca4aac)
The original idea behind this change (described in ticket #11064) was to
improve the assertions to avoid that users of the X server accidentally
forget to configure a DM or WM.
However this caused several issues with setups that require X, but no DM
or WM. The keymap testcases became instable as well as now disabling DMs
needs to be done explicitly.
(see https://github.com/NixOS/nixpkgs/pull/31268#issuecomment-347080036)
In the end the idea behind the change and #11064 was obviously a
mistake, so reverting it completely for now should be fine.
(cherry picked from commit 5caa22fe0a)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/php/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/phar.phar help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/phar.phar version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/phar.phar help` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php -h` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php --help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php -v` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php --version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/phpdbg -V` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/phpdbg --version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-cgi -h` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-cgi --help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-cgi -v` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-cgi --version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pear -h` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pear --help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pear help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pear -V` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pear version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/peardev -h` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/peardev --help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/peardev help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/peardev -V` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/peardev version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pecl -h` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pecl --help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pecl help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pecl -V` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/pecl version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-fpm -h` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-fpm --help` got 0 exit code
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-fpm -v` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-fpm --version` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-fpm -h` and found version 7.2.4
- ran `/nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4/bin/php-fpm --help` and found version 7.2.4
- found 7.2.4 with grep in /nix/store/jkzy4favahn0mxn1i9ags1zazg4z7y8l-php-7.2.4
- directory tree listing: https://gist.github.com/3c197892ad9174dae3d07c1dd61b418c
(cherry picked from commit 43c6a3f23a)
* with only one source bundle (per JEP-296), we can use src instead of
srcs, and avoid the need to cd in prePatch
* fetch sources from jdk10u instead of jdk10, to make it easier to
grab updates when they start coming.
* removed commented-out code that became irrelevant in the 8 -> 9
transition (*.pf files, infinality font rendering)
* create jdk10, jre10, and jre10_headless attributes in
all-packages.nix
(cherry picked from commit aabf45c163)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/telepathy-gabble/versions.
These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 0.18.4 with grep in /nix/store/pg936ixgiw96xqsrdzbwc1civylmy1q5-telepathy-gabble-0.18.4
- found 0.18.4 in filename of file in /nix/store/pg936ixgiw96xqsrdzbwc1civylmy1q5-telepathy-gabble-0.18.4
- directory tree listing: https://gist.github.com/92190024cdfe17a3e79730f988d904f6
(cherry picked from commit 14e24db9db)
- Add example for setting up nix-shell, improve rust docs
- Rust docs: add gcc rust dependencies and fix carnix commands
- Fix a typo with the carnix command.
(cherry picked from commit f7342a3625)
The compilation broke due to the flag `-Werror=int-in-bool-context`
which caused several compilation errors with GCC v7. Disabling this
warning manually with `-Wno-error` in `NIX_CFLAGS_COMPILE` should be
fine.
This package experienced several radical changes as the entire python
build in `$src/management/python` was broken since the given Python
interpreter missed several needed modules (including
`pythonPackages.qpid-python`). As the CMake build tried to invoke the
affected `setup.py` manually and patched the shebangs with `disutil` and
caused non-functional executables, I split the package up into two
parts, the actual `qpid-cpp` lib and the Python module that will be
composed using `buildEnv`.
Furthermore I added myself as maintainer for the package as the diff
became quite huge and we should have more folks available to maintain
this.
See https://hydra.nixos.org/build/71519082/log
See tickets #36453 and #31747
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.fsck.s3ql-wrapped -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.fsck.s3ql-wrapped --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.fsck.s3ql-wrapped --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/fsck.s3ql -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/fsck.s3ql --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/fsck.s3ql --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.mkfs.s3ql-wrapped -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.mkfs.s3ql-wrapped --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.mkfs.s3ql-wrapped --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/mkfs.s3ql -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/mkfs.s3ql --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/mkfs.s3ql --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.mount.s3ql-wrapped -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.mount.s3ql-wrapped --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.mount.s3ql-wrapped --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/mount.s3ql -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/mount.s3ql --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/mount.s3ql --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3ql_oauth_client-wrapped -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3ql_oauth_client-wrapped --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3ql_oauth_client-wrapped --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3ql_oauth_client -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3ql_oauth_client --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3ql_oauth_client --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3ql_verify-wrapped -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3ql_verify-wrapped --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3ql_verify-wrapped --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3ql_verify -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3ql_verify --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3ql_verify --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qladm-wrapped -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qladm-wrapped --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qladm-wrapped --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qladm -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qladm --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qladm --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qlcp-wrapped -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qlcp-wrapped --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qlcp-wrapped --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qlcp -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qlcp --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qlcp --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qlctrl-wrapped -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qlctrl-wrapped --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qlctrl-wrapped --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qlctrl -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qlctrl --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qlctrl --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qllock-wrapped -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qllock-wrapped --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qllock-wrapped --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qllock -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qllock --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qllock --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qlrm-wrapped -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qlrm-wrapped --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qlrm-wrapped --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qlrm -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qlrm --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qlrm --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qlstat-wrapped -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qlstat-wrapped --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.s3qlstat-wrapped --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qlstat -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qlstat --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/s3qlstat --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.umount.s3ql-wrapped -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.umount.s3ql-wrapped --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/.umount.s3ql-wrapped --version` and found version 2.26
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/umount.s3ql -h` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/umount.s3ql --help` got 0 exit code
- ran `/nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26/bin/umount.s3ql --version` and found version 2.26
- found 2.26 with grep in /nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26
- found 2.26 in filename of file in /nix/store/rkms0h08sfvsbpz7yp7fikhd272g28p2-s3ql-2.26
(cherry picked from commit e3db2501f9)
Thanks to pbogdan for noticing this. I'd like to have a "no direct commit"
policy implemented for my own good ^_^".
Tested with ofborg's outpaths.nix
(cherry picked from commit 67adb994bc)
The ceph-mgr daemon needs to know the location of cephs own-made python modules for some of the modules
that you can enable for it.
With wrapProgram, a wrapper is added that sets the proper pythonpath environment variable for the ceph-mgr
daemon so its modules can find the ceph python modules
(cherry picked from commit a9a7580c3f)
This makes a makefile-driven developer workflow nicer.
(cherry picked from commit 92d53362d4)
Edited to remove the emscripten references, which were new on
master
Citing from PyPI:
DEPRECATION NOTE: Please do not use this library ! It’s not working correctly in python 3, and besides that might be called a failed experiment.
(cherry picked from commit 33e16997b9)
The psmouse module is for PS/2 mouse only, which doesn't exist outside
x86. But we can test for the mousedev module just as well which is used
for the '-device usb-tablet' emulated by QEMU.
(cherry picked from commit d27f7942b7)
This build is compatible with PINE A64-LTS.
[dezgeg changed the original device tree patch to v4 of the patch series
"sunxi: sync H3, H5, A64 DTs from mainline Linux" submitted to the
upstream mailing list by Andre Przywara. Also install the
u-boot-sunxi-with-spl.bin binary similar to 32-bit boards
since it's now being built by the upstream build system.]
(cherry picked from commit 2ff31f71ae)
These derivations have not seen any updates since they were created in 2010,
and some of their sources have disappeared. There are upstream configs for
these boards, so these are now used, and they build correctly. I have no way
of testing them, and I don't if anyone even uses either board with Nix anymore.
(cherry picked from commit 01020b3263)
ARM trusted firmware is required as part of the boot process on some ARMv8-A
boards. Currently, only the RK3328 is supported in nixpkgs.
This makes the Rock64 u-boot image bootable.
(cherry picked from commit 0ab76c5a4e)
For some reason compiling the proper GHC from the binary one eventually
segfaults at some point.
Since it has never worked, just disable it and investigate later.
(cherry picked from commit a6425fc66d)
And also build in parallel.
I don't understand why we manually tediously link every single directory
from the source, but I don't want to investigate too much.
(cherry picked from commit f59eab75d2)
- Use 'somePkg == null' instead of 'somePkg == false' which is more
conventional in rest of Nixpkgs
- Use lib.optionalString where applicable
(cherry picked from commit 1645011983)
- Have only one sed expression per line
- Put the important stuff closer to the command and not hidden in some
continuation line. That is, don't do:
sed \
<boring stuff> \
<boring stuff> \
<boring stuff> \
<boring stuff> \
<boring stuff> \
<IMPORTANT STUFF>
but:
sed <IMPORTANT STUFF> \
<boring stuff> \
<boring stuff> \
<boring stuff> \
<boring stuff> \
<boring stuff>
(cherry picked from commit 1d854b479c)
backport of #37712
Currently broken on NixOS due to hardcoded modprobe binary path (see
bug #30756 from Oct 2017), no activity on a proposed fix for months.
As the protocol is terribly broken anyways, let's better remove it
completely, and not talk about anymore ;-)
Closes#30756.
(cherry picked from commit 6ac74d60ad)
This fixes a bug with changed qemu network interface names and also generally
should be preferred to using a release tag.
(cherry picked from commit 6b9771e4a7)
streamripper ships its own version of libmad, which does not compile on
clang, due to the usage of incompatible compiler flags. We can get the
build working by using the already packaged libmad, which includes
patches for clang.
(cherry picked from commit e77071289e)
- prometheus exporters are now configured with
`services.prometheus.exporters.<name>`
- the exporters are now defined by attribute sets
from which the options for each exporter are generated
- most of the exporter definitions are used unchanged,
except for some changes that should't have any impact
on the functionality.
(cherry picked from commit f4d03b5c9c)
Remove spl patch that was introduced for grsecurity which we don't support
anymore. ZFS now needs perl for some scripts that are call in the configure
script.
(cherry picked from commit f744f83072)
This is so that Qt user environment packages are also propagated. Fixes
Electrum environment installations when no other Qt applications are installed.
Added `dev` output so that closure size won't explode.
(cherry picked from commit b1b4c6c4eb)
This is to go to a reproducible image build.
Note without this options image are identical from the Docker point of
view but generated docker archives could have different hashes.
(cherry picked from commit ac0c491836)
This is to improve image creation reproducibility. Since the nar
format doesn't support hard link, the tar stream of a layer can be
different if a dependency of a layer has been built locally or if it
has been fetched from a binary cache.
If the dependency has been build locally, it can contain hard links
which are encoded in the tar stream. If the dependency has been
fetched from a binary cache, the tar stream doesn't contain any hard
link. So even if the content is the same, tar streams are different.
(cherry picked from commit 346996ceec)
Djblets is unmaintained: has not been updated since 2015, but had many releases.
Dependency django_pipeline_1_3 is broken and should anyway be removed from pythonPackages because we want to have a consistent package set.
Because the reviewboard package also hasn't been updated since 2015 and depends on djblets, it is removed as well.
(cherry picked from commit fbff08f2f2)
The send2trash library, which is now included in the notebook doesn't
succeed during build, even though it works.
(cherry picked from commit 8aaa17c52a)
Semi-automatic update. These checks were done:
- built on NixOS
- ran `/nix/store/qyrv15995w1pl2vmf1i720ii4s9gb3x3-graylog-2.4.3/bin/graylogctl -h` got 0 exit code
- ran `/nix/store/qyrv15995w1pl2vmf1i720ii4s9gb3x3-graylog-2.4.3/bin/graylogctl --help` got 0 exit code
- ran `/nix/store/qyrv15995w1pl2vmf1i720ii4s9gb3x3-graylog-2.4.3/bin/graylogctl help` got 0 exit code
- ran `/nix/store/qyrv15995w1pl2vmf1i720ii4s9gb3x3-graylog-2.4.3/bin/graylogctl -V` and found version 2.4.3
- ran `/nix/store/qyrv15995w1pl2vmf1i720ii4s9gb3x3-graylog-2.4.3/bin/graylogctl -v` and found version 2.4.3
- ran `/nix/store/qyrv15995w1pl2vmf1i720ii4s9gb3x3-graylog-2.4.3/bin/graylogctl --version` and found version 2.4.3
- ran `/nix/store/qyrv15995w1pl2vmf1i720ii4s9gb3x3-graylog-2.4.3/bin/graylogctl version` and found version 2.4.3
- ran `/nix/store/qyrv15995w1pl2vmf1i720ii4s9gb3x3-graylog-2.4.3/bin/graylogctl -h` and found version 2.4.3
- ran `/nix/store/qyrv15995w1pl2vmf1i720ii4s9gb3x3-graylog-2.4.3/bin/graylogctl --help` and found version 2.4.3
- ran `/nix/store/qyrv15995w1pl2vmf1i720ii4s9gb3x3-graylog-2.4.3/bin/graylogctl help` and found version 2.4.3
- found 2.4.3 with grep in /nix/store/qyrv15995w1pl2vmf1i720ii4s9gb3x3-graylog-2.4.3
- found 2.4.3 in filename of file in /nix/store/qyrv15995w1pl2vmf1i720ii4s9gb3x3-graylog-2.4.3
(cherry picked from commit e716a11026)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/4hdgd1vlac5isgsb728f3qjpqcs2zxqp-spacefm-1.0.6/bin/.spacefm-wrapped -h` got 0 exit code
- ran `/nix/store/4hdgd1vlac5isgsb728f3qjpqcs2zxqp-spacefm-1.0.6/bin/.spacefm-wrapped --help` got 0 exit code
- ran `/nix/store/4hdgd1vlac5isgsb728f3qjpqcs2zxqp-spacefm-1.0.6/bin/.spacefm-wrapped --version` and found version 1.0.6
- ran `/nix/store/4hdgd1vlac5isgsb728f3qjpqcs2zxqp-spacefm-1.0.6/bin/spacefm -h` got 0 exit code
- ran `/nix/store/4hdgd1vlac5isgsb728f3qjpqcs2zxqp-spacefm-1.0.6/bin/spacefm --help` got 0 exit code
- ran `/nix/store/4hdgd1vlac5isgsb728f3qjpqcs2zxqp-spacefm-1.0.6/bin/spacefm --version` and found version 1.0.6
- ran `/nix/store/4hdgd1vlac5isgsb728f3qjpqcs2zxqp-spacefm-1.0.6/bin/.spacefm-installer-wrapped --help` got 0 exit code
- ran `/nix/store/4hdgd1vlac5isgsb728f3qjpqcs2zxqp-spacefm-1.0.6/bin/.spacefm-installer-wrapped help` got 0 exit code
- ran `/nix/store/4hdgd1vlac5isgsb728f3qjpqcs2zxqp-spacefm-1.0.6/bin/spacefm-installer --help` got 0 exit code
- ran `/nix/store/4hdgd1vlac5isgsb728f3qjpqcs2zxqp-spacefm-1.0.6/bin/spacefm-installer help` got 0 exit code
- found 1.0.6 with grep in /nix/store/4hdgd1vlac5isgsb728f3qjpqcs2zxqp-spacefm-1.0.6
- directory tree listing: https://gist.github.com/1af4e8f53a36978c67e557c6c4c22b8d
(cherry picked from commit bb165a9d6f)
Origianlly the package was broken as bumping `pythonPackages.pillow` to
5.x broke `thumbor`. The latest upstream version `6.4.2` solved this
issue, so a simple package bump was sufficient.
Furthermore the following changes were made:
- moved the expression into its own file
- added myself as maintainer in case of any further breackage
- re-enabled python3 build: 6.4.2 is fine with python3, however the
`futures` dependency can't be satisfied anymore as it's part of
Python3. Therefore a patch for `setup.py` will be applied for Python3
buildsto drop the dependency
Note: the testsuite is disabled for now as several impure tests are done
and our testing environment seems to be unable to work the with the
natively compiled python modules properly.
Therefore I tested the module using the following expression:
``` nix
with import ./. {};
stdenv.mkDerivation {
name = "thumbor-test";
src = null;
buildInputs = [ python pythonPackages.thumbor ];
}
```
Inside this nix shell `thumbor` works fine and the native modules can be
imported.
See https://hydra.nixos.org/build/71062729/log
See ticket #36453
(cherry picked from commit 23e6689578)
a) set path to /run/wrappers so ping works
b) run via a target so we can easily inject other components (config copier,
appdaemon)
(cherry picked from commit 2859483fe9)
Commit 1f2b938 introduced a module for evilwm as a window-manager, but
did not actually add this module to window-manager's default.nix which
renders it useless.
(cherry picked from commit c7e1dff94e)
Using gitea over ssh had two isses:
1. No shell was set for the user
2. Gitea tried to write logs to
/nix/store/x83q12kyd9gw1pay036dxz2dq0apf17h-gitea-1.3.2-bin/log when
serving the ssh usage.
(cherry picked from commit fa76c9a385)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/wbax6msw4jcf95a3b56rgb5qyy08v3gb-autofs-5.1.4/bin/automount -h` got 0 exit code
- ran `/nix/store/wbax6msw4jcf95a3b56rgb5qyy08v3gb-autofs-5.1.4/bin/automount --help` got 0 exit code
- ran `/nix/store/wbax6msw4jcf95a3b56rgb5qyy08v3gb-autofs-5.1.4/bin/automount -V` and found version 5.1.4
- ran `/nix/store/wbax6msw4jcf95a3b56rgb5qyy08v3gb-autofs-5.1.4/bin/automount --version` and found version 5.1.4
- ran `/nix/store/wbax6msw4jcf95a3b56rgb5qyy08v3gb-autofs-5.1.4/bin/automount -h` and found version 5.1.4
- ran `/nix/store/wbax6msw4jcf95a3b56rgb5qyy08v3gb-autofs-5.1.4/bin/automount --help` and found version 5.1.4
- found 5.1.4 with grep in /nix/store/wbax6msw4jcf95a3b56rgb5qyy08v3gb-autofs-5.1.4
- directory tree listing: https://gist.github.com/419a24d78045772aea1e7ca68b950f1f
(cherry picked from commit 6cd68c2ad9)
Aspino patched `libglucose` for their own uses, however they currently
depend on glucose v4.0.
(see e31c3b4e57/patches)
The patches don't apply properly on `glucose-4.1` anymore, furthermore
the new source directory caused the `bootstrap.sh` from `aspino` which
was supposed to apply the patches and recompile the setup to break.
Furthermore some minor changes to the derivation were introduced:
- upgraded from `2016-01-31` to `2017-03-09`
- the name contains an `-unstable-` infix as upstream has no releases
- instead of a `patchPhase` the `postPatch` hook will be used for
`substituteInPlace` to keep advanced patching features from `nixpkgs`
available.
- `patchShebangs` will be called to avoid impurities because of the
implicit reliance on `/bin/sh`
- added myself as second maintainer to have more people available in
case of any further breackage
See https://hydra.nixos.org/build/70688471/log
See ticket #36453
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/zqq4z003jl443djfygasflfqk091wphx-lighttpd-1.4.49/bin/lighttpd -h` got 0 exit code
- ran `/nix/store/zqq4z003jl443djfygasflfqk091wphx-lighttpd-1.4.49/bin/lighttpd -V` and found version 1.4.49
- ran `/nix/store/zqq4z003jl443djfygasflfqk091wphx-lighttpd-1.4.49/bin/lighttpd -v` and found version 1.4.49
- ran `/nix/store/zqq4z003jl443djfygasflfqk091wphx-lighttpd-1.4.49/bin/lighttpd -h` and found version 1.4.49
- ran `/nix/store/zqq4z003jl443djfygasflfqk091wphx-lighttpd-1.4.49/bin/lighttpd-angel -h` got 0 exit code
- ran `/nix/store/zqq4z003jl443djfygasflfqk091wphx-lighttpd-1.4.49/bin/lighttpd-angel --help` got 0 exit code
- ran `/nix/store/zqq4z003jl443djfygasflfqk091wphx-lighttpd-1.4.49/bin/lighttpd-angel help` got 0 exit code
- ran `/nix/store/zqq4z003jl443djfygasflfqk091wphx-lighttpd-1.4.49/bin/lighttpd-angel -V` and found version 1.4.49
- ran `/nix/store/zqq4z003jl443djfygasflfqk091wphx-lighttpd-1.4.49/bin/lighttpd-angel -v` and found version 1.4.49
- ran `/nix/store/zqq4z003jl443djfygasflfqk091wphx-lighttpd-1.4.49/bin/lighttpd-angel --version` and found version 1.4.49
- ran `/nix/store/zqq4z003jl443djfygasflfqk091wphx-lighttpd-1.4.49/bin/lighttpd-angel -h` and found version 1.4.49
- ran `/nix/store/zqq4z003jl443djfygasflfqk091wphx-lighttpd-1.4.49/bin/lighttpd-angel --help` and found version 1.4.49
- found 1.4.49 with grep in /nix/store/zqq4z003jl443djfygasflfqk091wphx-lighttpd-1.4.49
- directory tree listing: https://gist.github.com/3f87cc8cd06f4c87b583c225172f1c2e
(cherry picked from commit f589e77842)
* Update dependencies using steam-native-runtime from Arch Linux as a
reference.
* Remove native-only Steam Runtime, just use installed libraries
instead.
* Mark native-only Steam as broken (due to segfault inside D-Bus). Seems it was
already broken for a long time. Doesn't apply to steam-run.
* Some cleanups for chrootenv.
(cherry picked from commit 9c8137ca81)
In order to adjust the language with `LC_ALL` properly the
`glibcLocales` is needed as `checkInput`. This was the only thing
preventing the testsuite from passing.
See ticket #36453
See https://hydra.nixos.org/build/70682982/nixlog/3
(cherry picked from commit 7dd7638cba)
V5 only supports python3. Since at the moment the only packages
that use ftfy are spacy and textacy which both support
python2 and 3, I propose to roll back to v4 until another package
requires v5, at that point we can make a duplicate package.
(cherry picked from commit 8187d93da2)
Upstream describes changes:
Fixes libdwarf/dwarfdump vulnerabilities related to detecting corrupt
DWARF and includes other small improvements
(cherry picked from commit 4bc0f88bb3)
This fixes the build failure by adding a missing dependency and because 0.8.11 allows a newer version of ukpostcodeparser.
(cherry picked from commit 495bb794d1)
A dependency (boost) makes use of `std::auto_ptr`, which is no longer
supported in C++17 in Clang. This change re-enables `std::auto_ptr`
capabilities.
(cherry picked from commit 833851cd6e)
Tested against all the VirtualBox VM tests.
Signed-off-by: aszlig <aszlig@nix.build>
Closes: #36127
(cherry picked from commit 273fd896bc)
Reason: The update is trivial in terms of affected packages and contains
a bunch of Linux-specific fixes.
Signed-off-by: aszlig <aszlig@nix.build>
I've started digging into the actual cause of the problem a week ago but
didn't continue fixing this.
The reason why the tests are failing is because
torvalds/linux/commit/72f5e08dbba2d01aa90b592cf76c378ea233b00b has
remapped the location of the TSS into the CPU entry area and we did
update our default kernel to version 4.14 in NixOS/nixpkgs@88530e02b6.
Back to VirtualBox: The guru meditation happens in
selmRCGuestTssPostWriteCheck, which I think is only a followup error. I
believe the right location couldn't be determined by VirtualBox and thus
the write check function triggers that panic because it's reading from
the wrong location.
So the actual problem *only* surfaces whenever we use software
virtualization, which we do for our tests because we don't have nested
virtualization available.
Our tests are also for testing the functionality of VirtualBox itself
and not certain kernel versions or kernel features, so for the time
being and until this is fixed, let's actually use kernel version 4.9 for
the guests within the VM tests. Kernel 4.9 didn't have the mentioned
change of the TSS location and thus the tests succeed.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @dtzWill
(cherry picked from commit ba816ee087)
`boost::system::posix_error` is deprecated since v1.37, however the
default Boost version in NixOS is 1.66.
The following upstream patch fixed the issue:
c9b5b13fb8
See ticket #36453
(cherry picked from commit 7da70c0b87)
conan has very strict requirements on the versions of its dependencies.
This patch adds downgraded versinos of node-semver and distro to
statisfy these requirements.
(cherry picked from commit 5fdfe61b35)
Semi-automatic update. These checks were done:
- built on NixOS
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/as2gbmap -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/as2gbmap --help` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdcdb -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdcdb --help` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/s51 -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/s51 -v` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sz80 -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sz80 -v` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/stlcs -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/stlcs -v` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/shc08 -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/shc08 -v` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sstm8 -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sstm8 -v` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdar -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdar --help` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdar -h` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdar --help` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdranlib -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdranlib --help` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdranlib -h` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdranlib --help` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdobjcopy -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdobjcopy --help` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdobjcopy -h` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdobjcopy --help` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdnm -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdnm --help` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdnm -h` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdnm --help` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/packihx -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/packihx --help` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/makebin -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdcpp --help` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdcc -h` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdcc --help` got 0 exit code
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdcc -v` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdcc --version` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdcc -h` and found version 3.7.0
- ran `/nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0/bin/sdcc --help` and found version 3.7.0
- found 3.7.0 with grep in /nix/store/5xwjrizy4782acsnrjjfpypif8yjp41n-sdcc-3.7.0
(cherry picked from commit 29ea34c6db)
The tests failed for a good reason on Darwin and should not have been
disabled. The issue has been resolved upstream with version 1.8 which
now also supports AArch64.
(cherry picked from commit 59cc47d802)
This is necessary because the standard library which is distributed with
lumail (the lumail core configuration so to speak) is written for lua5.1
apparently.
The website states 5.1 or 5.2 or 5.3, but 5.2 fails because "loadstring"
was deprecated in lua 5.2.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
(cherry picked from commit 13e95f33db)
Includes:
* Package gets a flag to use the debug build
* install phase installs all lua scripts from the package and makes
lumail find them
* global configuration which is shipped with the package can be
overridden, if desired
* parallel building enabled
(cherry picked from commit bb8e1c4512)
Following up from issue #33391, building LanguageClient-neovim now
requires some rust dependencies. This patch makes the plugin now longer
listed in vim-plugin-names file so that it will not be automatically
generated and instead lists it in non-generated plugins.
Also adds rustPlatform to arguments for vim plugins set.
The package runs fine on darwin. Using pytest as a test runner also
resolves the checkPhase issue on Python 3.5+.
(cherry picked from commit 91a9453496)
* Update fmod version to one with PulseAudio support;
* Dynamically link FluidSynth instead of using LD_LIBRARY_PATH;
* Use system libgme.
Fixes sound on some machines.
(cherry picked from commit f7c2288cfc)
Those version specs only exist to keep compat with python 3.3 which we
are not using anyway.
(cherry picked from commit 560b2bce6ce84628f97e242a3015201378a90eef)
(cherry picked from commit 679580be35)
Semi-automatic update. These checks were done:
- built on NixOS
- ran `/nix/store/l4zd353icm418x6asy4123a3gcpy14cr-taktuk-3.7.7/bin/taktuk -h` got 0 exit code
- ran `/nix/store/l4zd353icm418x6asy4123a3gcpy14cr-taktuk-3.7.7/bin/taktuk --help` got 0 exit code
- ran `/nix/store/l4zd353icm418x6asy4123a3gcpy14cr-taktuk-3.7.7/bin/taktuk help` got 0 exit code
- ran `/nix/store/l4zd353icm418x6asy4123a3gcpy14cr-taktuk-3.7.7/bin/taktuk -v` and found version 3.7.7
- ran `/nix/store/l4zd353icm418x6asy4123a3gcpy14cr-taktuk-3.7.7/bin/taktuk --version` and found version 3.7.7
- ran `/nix/store/l4zd353icm418x6asy4123a3gcpy14cr-taktuk-3.7.7/bin/taktuk version` and found version 3.7.7
- ran `/nix/store/l4zd353icm418x6asy4123a3gcpy14cr-taktuk-3.7.7/bin/taktuk -h` and found version 3.7.7
- ran `/nix/store/l4zd353icm418x6asy4123a3gcpy14cr-taktuk-3.7.7/bin/taktuk --help` and found version 3.7.7
- ran `/nix/store/l4zd353icm418x6asy4123a3gcpy14cr-taktuk-3.7.7/bin/taktuk help` and found version 3.7.7
- found 3.7.7 with grep in /nix/store/l4zd353icm418x6asy4123a3gcpy14cr-taktuk-3.7.7
- found 3.7.7 in filename of file in /nix/store/l4zd353icm418x6asy4123a3gcpy14cr-taktuk-3.7.7
(cherry picked from commit c995db0853)
This commit introduces the `toPythonApplication` function. Certain
Python packages are considered both a library and an application, that
is, they expose importable modules, but typically executables that are
part of the package are used instead.
In this case, the package needs to be added to `python-packages.nix` in
order for it to be available as a library. An alias with this function
can then be added in `all-packages.nix`, e.g.:
```
ansible = with pythonPackages; toPythonApplication ansible;
```
(cherry picked from commit 03e54c5e88)
Semi-automatic update. These checks were done:
- built on NixOS
- ran `/nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82/bin/misra.py -h` got 0 exit code
- ran `/nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82/bin/misra.py --help` got 0 exit code
- ran `/nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82/bin/misra.py help` got 0 exit code
- ran `/nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82/bin/naming.py -h` got 0 exit code
- ran `/nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82/bin/naming.py --help` got 0 exit code
- ran `/nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82/bin/naming.py help` got 0 exit code
- ran `/nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82/bin/y2038.py -h` got 0 exit code
- ran `/nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82/bin/y2038.py --help` got 0 exit code
- ran `/nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82/bin/y2038.py help` got 0 exit code
- ran `/nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82/bin/cppcheck -h` got 0 exit code
- ran `/nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82/bin/cppcheck --help` got 0 exit code
- ran `/nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82/bin/cppcheck --version` and found version 1.82
- found 1.82 with grep in /nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82
- found 1.82 in filename of file in /nix/store/klfqwbh75zch4zzdbwdyvk9qhgf28sln-cppcheck-1.82
(cherry picked from commit 62190a66ae)
Semi-automatic update. These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 190.0.1 with grep in /nix/store/y7rvgsj3077w8div5qny11xhgyjvy06c-google-cloud-sdk-190.0.1
(cherry picked from commit 84cb658505)
Outside of the nix-build the target is `x86_64-apple-darwin17.4.0`,
while inside the target is `x86_64-apple-darwin`. This difference
causes the fallback target configuration for darwin, which disables
gdb. Add a patch to make the target matching more flexible.
(cherry picked from commit 4c76a21aae)
(cherry picked from commit fe0728fa2c)
It's not included into repository checkout (which we use because of tests), so
get it from release tarball instead.
(cherry picked from commit 9edd4c8835)
Semi-automatic update. These checks were performed:
- built on NixOS
- found 4.18 with grep in /nix/store/23322yndj5lh6n4pr3maj26irnwklq31-nspr-4.18
- found 4.18 in filename of file in /nix/store/23322yndj5lh6n4pr3maj26irnwklq31-nspr-4.18
(cherry picked from commit 52b2e79a8b)
We would probably have to pick it soon anyway, due to Firefox updates.
Use systemd to create the directory for UNIX socket. Also use localhost instead
of 127.0.0.1 as is done in default cupsd.conf so that IPv6 is enabled when
available.
(cherry picked from commit 9c1c424e52)
We use default /var/run/cups/cups.sock in NixOS but here it's misdefined to be
/run/cups.sock. Return it to default.
(cherry picked from commit 998fdfdc94)
lib: rename maintainers-list.nix into maintainers/maintainer-list.nix
(cherry picked from commit 1bd790d613)
The intention is to reduce conflicts during maintenance.
@@ -20,8 +20,6 @@ under the terms of [COPYING](../COPYING), which is an MIT-like license.
(Motivation for change. Additional information.)
```
For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message).
Examples:
* nginx: init at 2.0.1
@@ -45,7 +43,7 @@ See the nixpkgs manual for more details on [standard meta-attributes](https://ni
## Writing good commit messages
In addition to writing properly formatted commit messages, it's important to include relevant information so other developers can later understand *why* a change was made. While this information usually can be found by digging code, mailing list/Discourse archives, pull request discussions or upstream changes, it may require a lot of work.
In addition to writing properly formatted commit messages, it's important to include relevant information so other developers can later understand *why* a change was made. While this information usually can be found by digging code, mailing list archives, pull request discussions or upstream changes, it may require a lot of work.
For package version upgrades and such a one-line commit message is usually sufficient.
<!-- 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
@@ -6,18 +5,15 @@
<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->
- [ ] 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)
- [ ] Tested using sandboxing ([nix.useSandbox](http://nixos.org/nixos/manual/options.html#opt-nix.useSandbox) on NixOS, or option `build-use-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 nix-review --run "nix-review wip"`
- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nox --run "nox-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
Use 2 spaces of indentation per indentation level in Nix expressions, 4 spaces in shell scripts.
Use 2 spaces of indentation per indentation level in Nix expressions, 4
spaces in shell scripts.
</para>
</listitem>
<listitem>
<para>
Do not use tab characters, i.e. configure your editor to use soft tabs. For instance, use <literal>(setq-default indent-tabs-mode nil)</literal> in Emacs. Everybody has different tab settings so it’s asking for trouble.
Do not use tab characters, i.e. configure your editor to use soft tabs.
For instance, use <literal>(setq-default indent-tabs-mode nil)</literal>
in Emacs. Everybody has different tab settings so it’s asking for
trouble.
</para>
</listitem>
<listitem>
<para>
Use <literal>lowerCamelCase</literal> for variable names, not<literal>UpperCamelCase</literal>. Note, this rule does not apply to package attribute names, which instead follow the rules in <xreflinkend="sec-package-naming"/>.
Use <literal>lowerCamelCase</literal> for variable names, not
<literal>UpperCamelCase</literal>. Note, this rule does not apply to
package attribute names, which instead follow the rules in
<xreflinkend="sec-package-naming"/>.
</para>
</listitem>
<listitem>
@@ -45,33 +52,29 @@ foo { arg = ...; }
</listitem>
<listitem>
<para>
In attribute sets or lists that span multiple lines, the attribute names or list elements should be aligned:
In attribute sets or lists that span multiple lines, the attribute names
or list elements should be aligned:
<programlisting>
# A long list.
list = [
elem1
elem2
elem3
];
list =
[ elem1
elem2
elem3
];
# A long attribute set.
attrs =
{ attr1 = short_expr;
attr2 =
if true then big_expr else big_expr;
};
# Alternatively:
attrs = {
attr1 = short_expr;
attr2 =
if true then big_expr else big_expr;
};
# Combined
listOfAttrs = [
{
attr1 = 3;
attr2 = "fff";
}
{
attr1 = 5;
attr2 = "ggg";
}
];
</programlisting>
</para>
</listitem>
@@ -89,7 +92,8 @@ attrs = { x = 1280; y = 1024; };
</listitem>
<listitem>
<para>
Breaking in the middle of a function argument can give hard-to-read code, like
Breaking in the middle of a function argument can give hard-to-read code,
like
<programlisting>
someFunction { x = 1280;
y = 1024; } otherArg
@@ -114,7 +118,8 @@ in someFunction res otherArg yetAnotherArg
</listitem>
<listitem>
<para>
The bodies of functions, asserts, and withs are not indented to prevent a lot of superfluous indentation levels, i.e.
The bodies of functions, asserts, and withs are not indented to prevent a
lot of superfluous indentation levels, i.e.
<programlisting>
{ arg1, arg2 }:
assert system == "i686-linux";
@@ -146,7 +151,8 @@ stdenv.mkDerivation { ...
</listitem>
<listitem>
<para>
Functions should list their expected arguments as precisely as possible. That is, write
Functions should list their expected arguments as precisely as possible.
@@ -160,7 +166,9 @@ args: with args; <replaceable>...</replaceable>
</programlisting>
</para>
<para>
For functions that are truly generic in the number of arguments (such as wrappers around <varname>mkDerivation</varname>) that have some required arguments, you should write them using an <literal>@</literal>-pattern:
For functions that are truly generic in the number of arguments (such as
wrappers around <varname>mkDerivation</varname>) that have some required
arguments, you should write them using an <literal>@</literal>-pattern:
The key words <emphasis>must</emphasis>, <emphasis>must not</emphasis>, <emphasis>required</emphasis>, <emphasis>shall</emphasis>, <emphasis>shall not</emphasis>, <emphasis>should</emphasis>, <emphasis>should not</emphasis>, <emphasis>recommended</emphasis>, <emphasis>may</emphasis>, and <emphasis>optional</emphasis> in this section are to be interpreted as described in <linkxlink:href="https://tools.ietf.org/html/rfc2119">RFC 2119</link>. Only <emphasis>emphasized</emphasis> words are to be interpreted in this way.
</para>
<para>
In Nixpkgs, there are generally three different names associated with a package:
In Nixpkgs, there are generally three different names associated with a
package:
<itemizedlist>
<listitem>
<para>
The <varname>name</varname> attribute of the derivation (excluding the version part). This is what most users see, in particular when using <command>nix-env</command>.
The <varname>name</varname> attribute of the derivation (excluding the
version part). This is what most users see, in particular when using
<command>nix-env</command>.
</para>
</listitem>
<listitem>
<para>
The variable name used for the instantiated package in<filename>all-packages.nix</filename>, and when passing it as a dependency to other functions. Typically this is called the <emphasis>package attribute name</emphasis>. This is what Nix expression authors see. It can also be used when installing using <command>nix-env -iA</command>.
The variable name used for the instantiated package in
<filename>all-packages.nix</filename>, and when passing it as a
dependency to other functions. Typically this is called the
<emphasis>package attribute name</emphasis>. This is what Nix expression
authors see. It can also be used when installing using <command>nix-env
Most of the time, these are the same. For instance, the package<literal>e2fsprogs</literal> has a <varname>name</varname> attribute <literal>"e2fsprogs-<replaceable>version</replaceable>"</literal>, is bound to the variable name <varname>e2fsprogs</varname> in <filename>all-packages.nix</filename>, and the Nix expression is in <filename>pkgs/os-specific/linux/e2fsprogs/default.nix</filename>.
Most of the time, these are the same. For instance, the package
<literal>e2fsprogs</literal> has a <varname>name</varname> attribute
<literal>"e2fsprogs-<replaceable>version</replaceable>"</literal>, is bound
to the variable name <varname>e2fsprogs</varname> in
<filename>all-packages.nix</filename>, and the Nix expression is in
The <literal>name</literal> attribute <emphasis>should</emphasis> be identical to the upstream package name.
Generally, try to stick to the upstream package name.
</para>
</listitem>
<listitem>
<para>
The <literal>name</literal> attribute <emphasis>must not</emphasis> contain uppercase letters — e.g.,<literal>"mplayer-1.0rc2"</literal> instead of <literal>"MPlayer-1.0rc2"</literal>.
Don’t use uppercase letters in the<literal>name</literal> attribute
— e.g., <literal>"mplayer-1.0rc2"</literal> instead of
<literal>"MPlayer-1.0rc2"</literal>.
</para>
</listitem>
<listitem>
<para>
The version part of the <literal>name</literal> attribute<emphasis>must</emphasis> start with a digit (following a dash) — e.g., <literal>"hello-0.3.1rc2"</literal>.
The version part of the <literal>name</literal> attribute
<emphasis>must</emphasis> start with a digit (following a dash) — e.g.,
<literal>"hello-0.3.1rc2"</literal>.
</para>
</listitem>
<listitem>
<para>
If a package is not a release but a commit from a repository, then the version part of the name <emphasis>must</emphasis> be the date of that (fetched) commit. The date <emphasis>must</emphasis> be in <literal>"YYYY-MM-DD"</literal> format. Also append <literal>"unstable"</literal> to the name - e.g., <literal>"pkgname-unstable-2014-09-23"</literal>.
If a package is not a release but a commit from a repository, then the
version part of the name <emphasis>must</emphasis> be the date of that
(fetched) commit. The date must be in <literal>"YYYY-MM-DD"</literal>
format. Also append <literal>"unstable"</literal> to the name - e.g.,
<literal>"pkgname-unstable-2014-09-23"</literal>.
</para>
</listitem>
<listitem>
<para>
Dashes in the package name <emphasis>should</emphasis> be preserved in new variable names, rather than converted to underscores or camel cased — e.g., <varname>http-parser</varname> instead of <varname>http_parser</varname> or <varname>httpParser</varname>. The hyphenated style is preferred in all three package names.
Dashes in the package name should be preserved in new variable names,
rather than converted to underscores or camel cased — e.g.,
<varname>http-parser</varname> instead of <varname>http_parser</varname>
or <varname>httpParser</varname>. The hyphenated style is preferred in
all three package names.
</para>
</listitem>
<listitem>
<para>
If there are multiple versions of a package, this <emphasis>should</emphasis> be reflected in the variable names in <filename>all-packages.nix</filename>, e.g. <varname>json-c-0-9</varname> and <varname>json-c-0-11</varname>. If there is an obvious “default” version, make an attribute like <literal>json-c = json-c-0-9;</literal>. See also <xreflinkend="sec-versioning"/>
If there are multiple versions of a package, this should be reflected in
the variable names in <filename>all-packages.nix</filename>, e.g.
<varname>json-c-0-9</varname> and <varname>json-c-0-11</varname>. If
there is an obvious “default” version, make an attribute like
Names of files and directories should be in lowercase, with dashes between words — not in camel case. For instance, it should be <filename>all-packages.nix</filename>, not <filename>allPackages.nix</filename> or <filename>AllPackages.nix</filename>.
Names of files and directories should be in lowercase, with dashes between
words — not in camel case. For instance, it should be
<filename>all-packages.nix</filename>, not
<filename>allPackages.nix</filename> or
<filename>AllPackages.nix</filename>.
</para>
<sectionxml:id="sec-hierarchy">
<title>Hierarchy</title>
<para>
Each package should be stored in its own directory somewhere in the<filename>pkgs/</filename> tree, i.e. in <filename>pkgs/<replaceable>category</replaceable>/<replaceable>subcategory</replaceable>/<replaceable>...</replaceable>/<replaceable>pkgname</replaceable></filename>. Below are some rules for picking the right category for a package. Many packages fall under several categories; what matters is the <emphasis>primary</emphasis> purpose of a package. For example, the <literal>libxml2</literal> package builds both a library and some tools; but it’s a library foremost, so it goes under <filename>pkgs/development/libraries</filename>.
Each package should be stored in its own directory somewhere in the
Because every version of a package in Nixpkgs creates a potential maintenance burden, old versions of a package should not be kept unless there is a good reason to do so. For instance, Nixpkgs contains several versions of GCC because other packages don’t build with the latest version of GCC. Other examples are having both the latest stable and latest pre-release version of a package, or to keep several major releases of an application that differ significantly in functionality.
Because every version of a package in Nixpkgs creates a potential
maintenance burden, old versions of a package should not be kept unless
there is a good reason to do so. For instance, Nixpkgs contains several
versions of GCC because other packages don’t build with the latest
version of GCC. Other examples are having both the latest stable and latest
pre-release version of a package, or to keep several major releases of an
application that differ significantly in functionality.
</para>
<para>
If there is only one version of a package, its Nix expression should be named <filename>e2fsprogs/default.nix</filename>. If there are multiple versions, this should be reflected in the filename, e.g. <filename>e2fsprogs/1.41.8.nix</filename> and <filename>e2fsprogs/1.41.9.nix</filename>. The version in the filename should leave out unnecessary detail. For instance, if we keep the latest Firefox 2.0.x and 3.5.x versions in Nixpkgs, they should be named <filename>firefox/2.0.nix</filename> and <filename>firefox/3.5.nix</filename>, respectively (which, at a given point, might contain versions <literal>2.0.0.20</literal> and <literal>3.5.4</literal>). If a version requires many auxiliary files, you can use a subdirectory for each version, e.g. <filename>firefox/2.0/default.nix</filename> and <filename>firefox/3.5/default.nix</filename>.
If there is only one version of a package, its Nix expression should be
named <filename>e2fsprogs/default.nix</filename>. If there are multiple
versions, this should be reflected in the filename, e.g.
<filename>e2fsprogs/1.41.8.nix</filename> and
<filename>e2fsprogs/1.41.9.nix</filename>. The version in the filename
should leave out unnecessary detail. For instance, if we keep the latest
Firefox 2.0.x and 3.5.x versions in Nixpkgs, they should be named
<filename>firefox/2.0.nix</filename> and
<filename>firefox/3.5.nix</filename>, respectively (which, at a given
point, might contain versions <literal>2.0.0.20</literal> and
<literal>3.5.4</literal>). If a version requires many auxiliary files, you
can use a subdirectory for each version, e.g.
<filename>firefox/2.0/default.nix</filename> and
<filename>firefox/3.5/default.nix</filename>.
</para>
<para>
All versions of a package <emphasis>must</emphasis> be included in<filename>all-packages.nix</filename> to make sure that they evaluate correctly.
All versions of a package <emphasis>must</emphasis> be included in
<filename>all-packages.nix</filename> to make sure that they evaluate
There are multiple ways to fetch a package source in nixpkgs. The general guideline is that you should package reproducible sources with a high degree of availability. Right now there is only one fetcher which has mirroring support and that is <literal>fetchurl</literal>. Note that you should also prefer protocols which have a corresponding proxy environment variable.
There are multiple ways to fetch a package source in nixpkgs. The general
guideline is that you should package sources with a high degree of
availability. Right now there is only one fetcher which has mirroring
support and that is <literal>fetchurl</literal>. Note that you should also
prefer protocols which have a corresponding proxy environment variable.
</para>
<para>
You can find many source fetch helpers in<literal>pkgs/build-support/fetch*</literal>.
You can find many source fetch helpers in
<literal>pkgs/build-support/fetch*</literal>.
</para>
<para>
In the file <literal>pkgs/top-level/all-packages.nix</literal> you can find fetch helpers, these have names on the form <literal>fetchFrom*</literal>. The intention of these are to provide snapshot fetches but using the same api as some of the version controlled fetchers from <literal>pkgs/build-support/</literal>. As an example going from bad to good:
In the file <literal>pkgs/top-level/all-packages.nix</literal> you can find
fetch helpers, these have names on the form <literal>fetchFrom*</literal>.
The intention of these are to provide snapshot fetches but using the same
api as some of the version controlled fetchers from
<literal>pkgs/build-support/</literal>. As an example going from bad to
Find the value to put as <literal>sha256</literal> by running <literal>nix run -f '<nixpkgs>' nix-prefetch-github -c nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS nix</literal> or <literal>nix-prefetch-url --unpack https://github.com/NixOS/nix/archive/1f795f9f44607cc5bec70d1300150bfefcef2aae.tar.gz</literal>.
</para>
</listitem>
</itemizedlist>
</para>
</section>
<sectionxml:id="sec-source-hashes">
<title>Obtaining source hash</title>
<para>
Preferred source hash type is sha256. There are several ways to get it.
</para>
<orderedlist>
<listitem>
<para>
Prefetch URL (with <literal>nix-prefetch-<replaceable>XXX</replaceable><replaceable>URL</replaceable></literal>, where <replaceable>XXX</replaceable> is one of <literal>url</literal>, <literal>git</literal>, <literal>hg</literal>, <literal>cvs</literal>, <literal>bzr</literal>, <literal>svn</literal>). Hash is printed to stdout.
</para>
</listitem>
<listitem>
<para>
Prefetch by package source (with <literal>nix-prefetch-url '<nixpkgs>' -A <replaceable>PACKAGE</replaceable>.src</literal>, where <replaceable>PACKAGE</replaceable> is package attribute name). Hash is printed to stdout.
</para>
<para>
This works well when you've upgraded existing package version and want to find out new hash, but is useless if package can't be accessed by attribute or package has multiple sources (<literal>.srcs</literal>, architecture-dependent sources, etc).
</para>
</listitem>
<listitem>
<para>
Upstream provided hash: use it when upstream provides <literal>sha256</literal> or <literal>sha512</literal> (when upstream provides <literal>md5</literal>, don't use it, compute <literal>sha256</literal> instead).
</para>
<para>
A little nuance is that <literal>nix-prefetch-*</literal> tools produce hash encoded with <literal>base32</literal>, but upstream usually provides hexadecimal (<literal>base16</literal>) encoding. Fetchers understand both formats. Nixpkgs does not standardize on any one format.
</para>
<para>
You can convert between formats with nix-hash, for example:
Extracting hash from local source tarball can be done with <literal>sha256sum</literal>. Use <literal>nix-prefetch-url file:///path/to/tarball </literal> if you want base32 hash.
</para>
</listitem>
<listitem>
<para>
Fake hash: set fake hash in package expression, perform build and extract correct hash from error Nix prints.
</para>
<para>
For package updates it is enough to change one symbol to make hash fake. For new packages, you can use <literal>lib.fakeSha256</literal>, <literal>lib.fakeSha512</literal> or any other fake hash.
</para>
<para>
This is last resort method when reconstructing source URL is non-trivial and <literal>nix-prefetch-url -A</literal> isn't applicable (for example, <linkxlink:href="https://github.com/NixOS/nixpkgs/blob/d2ab091dd308b99e4912b805a5eb088dd536adb9/pkgs/applications/video/kodi/default.nix#L73"> one of <literal>kodi</literal> dependencies</link>). The easiest way then would be replace hash with a fake one and rebuild. Nix build will fail and error message will contain desired hash.
</para>
<warning>
<para>
This method has security problems. Check below for details.
</para>
</warning>
</listitem>
</orderedlist>
<sectionxml:id="sec-source-hashes-security">
<title>Obtaining hashes securely</title>
<para>
Let's say Man-in-the-Middle (MITM) sits close to your network. Then instead of fetching source you can fetch malware, and instead of source hash you get hash of malware. Here are security considerations for this scenario:
</para>
<itemizedlist>
<listitem>
<para>
<literal>http://</literal> URLs are not secure to prefetch hash from;
</para>
</listitem>
<listitem>
<para>
hashes from upstream (in method 3) should be obtained via secure protocol;
</para>
</listitem>
<listitem>
<para>
<literal>https://</literal> URLs are secure in methods 1, 2, 3;
</para>
</listitem>
<listitem>
<para>
<literal>https://</literal> URLs are not secure in method 5. When obtaining hashes with fake hash method, TLS checks are disabled. So refetch source hash from several different networks to exclude MITM scenario. Alternatively, use fake hash method to make Nix error, but instead of extracting hash from error, extract <literal>https://</literal> URL and prefetch it with method 1.
</para>
</listitem>
</itemizedlist>
</section>
</section>
<sectionxml:id="sec-patches">
<title>Patches</title>
<para>
Patches available online should be retrieved using<literal>fetchpatch</literal>.
Patches available online should be retrieved using
<literal>fetchpatch</literal>.
</para>
<para>
@@ -858,7 +871,10 @@ patches = [
</para>
<para>
Otherwise, you can add a <literal>.patch</literal> file to the<literal>nixpkgs</literal> repository. In the interest of keeping our maintenance burden to a minimum, only patches that are unique to <literal>nixpkgs</literal> should be added in this way.
Otherwise, you can add a <literal>.patch</literal> file to the
<literal>nixpkgs</literal> repository. In the interest of keeping our
maintenance burden to a minimum, only patches that are unique to
<literal>nixpkgs</literal> should be added in this way.
Nix comes with certain defaults about what packages can and cannot be installed, based on a package's metadata. By default, Nix will prevent installation if any of the following criteria are true:
Nix comes with certain defaults about what packages can and cannot be
installed, based on a package's metadata. By default, Nix will prevent
installation if any of the following criteria are true:
</para>
<itemizedlist>
<listitem>
<para>
The package is thought to be broken, and has had its<literal>meta.broken</literal> set to <literal>true</literal>.
The package is thought to be broken, and has had its
<literal>meta.broken</literal> set to <literal>true</literal>.
</para>
</listitem>
<listitem>
<para>
The package isn't intended to run on the given system, as none of its <literal>meta.platforms</literal>match the given system.
The package's <literal>meta.license</literal>is set to a license which is
considered to be unfree.
</para>
</listitem>
<listitem>
<para>
The package's <literal>meta.license</literal> is set to a license which is considered to be unfree.
</para>
</listitem>
<listitem>
<para>
The package has known security vulnerabilities but has not or can not be updated for some reason, and a list of issues has been entered in to the package's <literal>meta.knownVulnerabilities</literal>.
The package has known security vulnerabilities but has not or can not be
updated for some reason, and a list of issues has been entered in to the
Note that all this is checked during evaluation already, and the check includes any package that is evaluated. In particular, all build-time dependencies are checked. <literal>nix-env -qa</literal> will (attempt to) hide any packages that would be refused.
Note that all this is checked during evaluation already, and the check
includes any package that is evaluated. In particular, all build-time
dependencies are checked. <literal>nix-env -qa</literal> will (attempt to)
hide any packages that would be refused.
</para>
<para>
Each of these criteria can be altered in the nixpkgs configuration.
</para>
<para>
The nixpkgs configuration for a NixOS system is set in the<literal>configuration.nix</literal>, as in the following example:
The nixpkgs configuration for a NixOS system is set in the
<literal>configuration.nix</literal>, as in the following example:
<programlisting>
{
nixpkgs.config = {
@@ -42,10 +47,13 @@
};
}
</programlisting>
However, this does not allow unfree software for individual users. Their configurations are managed separately.
However, this does not allow unfree software for individual users. Their
configurations are managed separately.
</para>
<para>
A user's of 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;
@@ -53,25 +61,31 @@
</programlisting>
</para>
<para>
Note that we are not able to test or build unfree software on Hydra due to policy. Most unfree licenses prohibit us from either executing or distributing the software.
Note that we are not able to test or build unfree software on Hydra due to
policy. Most unfree licenses prohibit us from either executing or
distributing the software.
</para>
<sectionxml:id="sec-allow-broken">
<title>Installing broken packages</title>
<para>
There are two ways to try compiling a package which has been marked as broken.
There are two ways to try compiling a package which has been marked as
broken.
</para>
<itemizedlist>
<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:
For allowing the build of a broken package once, you can use an
environment variable for a single invocation of the nix tools:
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;
}
</programlisting>
</para>
</listitem>
</itemizedlist>
<para>
The difference between a package being unsupported on some system and being broken is admittedly a bit fuzzy. If a program <emphasis>ought</emphasis> to work on a certain platform, but doesn't, the platform should be included in <literal>meta.platforms</literal>, but marked as broken with e.g. <literal>meta.broken = !hostPlatform.isWindows</literal>. Of course, this begs the question of what "ought" means exactly. That is left to the package maintainer.
</para>
</section>
<sectionxml:id="sec-allow-unfree">
<title>Installing unfree packages</title>
<para>
There are several ways to tweak how Nix handles a package which has been marked as unfree.
There are several ways to tweak how Nix handles a package which has been
marked as unfree.
</para>
<itemizedlist>
<listitem>
<para>
To temporarily allow all unfree packages, you can use an environment variable for a single invocation of the nix tools:
To temporarily allow all unfree packages, you can use an environment
variable for a single invocation of the nix tools:
It is possible to permanently allow individual unfree packages, while still blocking unfree packages by default using the <literal>allowUnfreePredicate</literal> configuration option in the user configuration file.
It is possible to permanently allow individual unfree packages, while
still blocking unfree packages by default using the
<literal>allowUnfreePredicate</literal> configuration option in the user
configuration file.
</para>
<para>
This option is a function which accepts a package as a parameter, and returns a boolean. The following example configuration accepts a package and always returns false:
This option is a function which accepts a package as a parameter, and
returns a boolean. The following example configuration accepts a package
and always returns false:
<programlisting>
{
allowUnfreePredicate = (pkg: false);
@@ -138,24 +129,25 @@
</programlisting>
</para>
<para>
For a more useful example, try the following. This configuration only allows unfree packages named flash player and visual studio code:
A more useful example, the following configuration allows only allows
It is also possible to whitelist and blacklist licenses that are specifically acceptable or not acceptable, using <literal>whitelistedLicenses</literal> and <literal>blacklistedLicenses</literal>, respectively.
It is also possible to whitelist and blacklist licenses that are
It is possible to permanently allow individual insecure packages, while still blocking other insecure packages by default using the <literal>permittedInsecurePackages</literal> configuration option in the user configuration file.
It is possible to permanently allow individual insecure packages, while
still blocking other insecure packages by default using the
<literal>permittedInsecurePackages</literal> configuration option in the
user configuration file.
</para>
<para>
The following example configuration permits the installation of the hypothetically insecure package <literal>hello</literal>, version <literal>1.2.3</literal>:
The following example configuration permits the installation of the
hypothetically insecure package <literal>hello</literal>, version
<literal>1.2.3</literal>:
<programlisting>
{
permittedInsecurePackages = [
@@ -208,13 +209,18 @@
</listitem>
<listitem>
<para>
It is also possible to create a custom policy around which insecure packages to allow and deny, by overriding the <literal>allowInsecurePredicate</literal> configuration option.
It is also possible to create a custom policy around which insecure
The <literal>allowInsecurePredicate</literal> option is a function which accepts a package and returns a boolean, much like <literal>allowUnfreePredicate</literal>.
The <literal>allowInsecurePredicate</literal> option is a function which
accepts a package and returns a boolean, much like
<literal>allowUnfreePredicate</literal>.
</para>
<para>
The following configuration example only allows insecure packages with very short names:
The following configuration example only allows insecure packages with
Note that <literal>permittedInsecurePackages</literal> is only checked if<literal>allowInsecurePredicate</literal> is not specified.
Note that <literal>permittedInsecurePackages</literal> is only checked if
<literal>allowInsecurePredicate</literal> is not specified.
</para>
</listitem>
</itemizedlist>
@@ -232,7 +239,10 @@
<title>Modify 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 override Nix packages. It must be a function that takes pkgs as an argument and returns a modified set of packages.
You can define a function called <varname>packageOverrides</varname> in your
local <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.
<programlisting>
{
packageOverrides = pkgs: rec {
@@ -249,7 +259,15 @@
<title>Build an environment</title>
<para>
Using <literal>packageOverrides</literal>, it is possible to manage packages declaratively. This means that we can list all of our desired packages within a declarative Nix expression. For example, to have <literal>aspell</literal>, <literal>bc</literal>, <literal>ffmpeg</literal>, <literal>coreutils</literal>, <literal>gdb</literal>, <literal>nixUnstable</literal>, <literal>emscripten</literal>, <literal>jq</literal>, <literal>nox</literal>, and <literal>silver-searcher</literal>, we could use the following in <filename>~/.config/nixpkgs/config.nix</filename>:
Using <literal>packageOverrides</literal>, it is possible to manage
packages declaratively. This means that we can list all of our desired
packages within a declarative Nix expression. For example, to have
To install it into our environment, you can just run <literal>nix-env -iA nixpkgs.myPackages</literal>. If you want to load the packages to be built from a working copy of <literal>nixpkgs</literal> you just run <literal>nix-env -f. -iA myPackages</literal>. To explore what's been installed, just look through <filename>~/.nix-profile/</filename>. You can see that a lot of stuff has been installed. Some of this stuff is useful some of it isn't. Let's tell Nixpkgs to only link the stuff that we want:
To install it into our environment, you can just run <literal>nix-env -iA
nixpkgs.myPackages</literal>. If you want to load the packages to be built
from a working copy of <literal>nixpkgs</literal> you just run
<literal>nix-env -f. -iA myPackages</literal>. To explore what's been
installed, just look through <filename>~/.nix-profile/</filename>. You can
see that a lot of stuff has been installed. Some of this stuff is useful
some of it isn't. Let's tell Nixpkgs to only link the stuff that we want:
<literal>pathsToLink</literal> tells Nixpkgs to only link the paths listed which gets rid of the extra stuff in the profile. <filename>/bin</filename> and <filename>/share</filename> are good defaults for a user environment, getting rid of the clutter. If you are running on Nix on MacOS, you may want to add another path as well, <filename>/Applications</filename>, that makes GUI apps available.
<literal>pathsToLink</literal> tells Nixpkgs to only link the paths listed
which gets rid of the extra stuff in the profile. <filename>/bin</filename>
and <filename>/share</filename> are good defaults for a user environment,
getting rid of the clutter. If you are running on Nix on MacOS, you may
want to add another path as well, <filename>/Applications</filename>, that
makes GUI apps available.
</para>
</section>
@@ -310,7 +317,13 @@
<title>Getting documentation</title>
<para>
After building that new environment, look through<filename>~/.nix-profile</filename> to make sure everything is there that we wanted. Discerning readers will note that some files are missing. Look inside <filename>~/.nix-profile/share/man/man1/</filename> to verify this. There are no man pages for any of the Nix tools! This is because some packages like Nix have multiple outputs for things like documentation (see section 4). Let's make Nix install those as well.
After building that new environment, look through
<filename>~/.nix-profile</filename> to make sure everything is there that
we wanted. Discerning readers will note that some files are missing. Look
inside <filename>~/.nix-profile/share/man/man1/</filename> to verify this.
There are no man pages for any of the Nix tools! This is because some
packages like Nix have multiple outputs for things like documentation (see
This provides us with some useful documentation for using our packages. However, if we actually want those manpages to be detected by man, we need to set up our environment. This can also be managed within Nix expressions.
This provides us with some useful documentation for using our packages.
However, if we actually want those manpages to be detected by man, we need
to set up our environment. This can also be managed within Nix expressions.
For this to work fully, you must also have this script sourced when you are logged in. Try adding something like this to your <filename>~/.profile</filename> file:
For this to work fully, you must also have this script sourced when you are
logged in. Try adding something like this to your
<filename>~/.profile</filename> file:
</para>
<screen>
@@ -385,10 +392,11 @@ if [ -d $HOME/.nix-profile/etc/profile.d ]; then
fi
done
fi
</screen>
</screen>
<para>
Now just run <literal>source $HOME/.profile</literal> and you can starting loading man pages from your environent.
Now just run <literal>source $HOME/.profile</literal> and you can starting
loading man pages from your environent.
</para>
</section>
@@ -396,23 +404,25 @@ fi
<title>GNU info setup</title>
<para>
Configuring GNU info is a little bit trickier than man pages. To work correctly, info needs a database to be generated. This can be done with some small modifications to our environment scripts.
Configuring GNU info is a little bit trickier than man pages. To work
correctly, info needs a database to be generated. This can be done with
some small modifications to our environment scripts.
if [ -x $out/bin/install-info -a -w $out/share/info ]; then
shopt -s nullglob
for i in $out/share/info/*.info $out/share/info/*.info.gz; do
$out/bin/install-info $i $out/share/info/dir
done
fi
if [ -x $out/bin/install-info -a -w $out/share/info ]; then
shopt -s nullglob
for i in $out/share/info/*.info $out/share/info/*.info.gz; do
$out/bin/install-info $i $out/share/info/dir
done
fi
'';
};
};
}
</screen>
</screen>
<para>
<literal>postBuild</literal> tells Nixpkgs to run a command after building the environment. In this case, <literal>install-info</literal> adds the installed info pages to <literal>dir</literal> which is GNU info's default root node. Note that <literal>texinfoInteractive</literal> is added to the environment to give the <literal>install-info</literal> command.
<literal>postBuild</literal> tells Nixpkgs to run a command after building
the environment. In this case, <literal>install-info</literal> adds the
installed info pages to <literal>dir</literal> which is GNU info's default
root node. Note that <literal>texinfoInteractive</literal> is added to the
environment to give the <literal>install-info</literal> command.
"Cross-compilation" means compiling a program on one machine for another type of machine. 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. However, there are significant advantages to rigorously distinguishing between build-time and run-time environments! Significant, because the benefits apply even when one is developing and deploying on the same machine. 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.
"Cross-compilation" means compiling a program on one machine for another
type of machine. 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 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>
This chapter will be organized in three parts. First, it will describe the basics of how to package software in a way that supports cross-compilation. Second, it will describe how to use Nixpkgs when cross-compiling. Third, it will describe the internal infrastructure supporting cross-compilation.
This chapter will be organized in three parts. First, it will describe the
basics of how to package software in a way that supports cross-compilation.
Second, it will describe how to use Nixpkgs when cross-compiling. Third, it
will describe the internal infrastructure supporting cross-compilation.
<title>Packaging in a cross-friendly manner</title>
<sectionxml:id="ssec-cross-platform-parameters">
<section>
<title>Platform parameters</title>
<para>
Nixpkgs follows the<link
xlink:href="https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html">conventions of GNU autoconf</link>. We distinguish between 3 types of platforms when building a derivation: <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 will run. The third attribute, <wordasword>target</wordasword>, is relevant only for certain specific compilers and build tools.
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>. They are always defined as attributes in the standard environment. That means one can access them like:
In Nixpkgs, these three platforms are defined as attribute sets under the
The "build platform" is the platform on which a package is built. Once someone has a built package, or pre-built binary package, the build platform should not matter and can be ignored.
The "build platform" is the platform on which a package is built. Once
someone has a built package, or pre-built binary package, the build
platform should not matter and be safe to ignore.
</para>
</listitem>
</varlistentry>
@@ -48,7 +77,9 @@
</term>
<listitem>
<para>
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.
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>
@@ -58,23 +89,44 @@
</term>
<listitem>
<para>
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 compatibility with building certain specific compilers and build tools. It can be safely ignored for all other packages.
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 compatibility 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 of specifying this single "target platform" is thus pushed to build time of the compiler. The root cause of this is that the compiler (which will be run on the host) and the standard library/runtime (which will be run on the target) are built by a single build process.
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 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.
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>
Although the existence 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.
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>
</variablelist>
<para>
The exact schema these fields follow is a bit ill-defined due to a long and convoluted evolution, but this is slowly being cleaned up. You can see examples of ones used in practice in <literal>lib.systems.examples</literal>; note how they are not all very consistent. For now, here are few fields can count on them containing:
The exact schema these fields follow is a bit ill-defined due to a long and
convoluted evolution, but this is slowly being cleaned up. You can see
examples of ones used in practice in
<literal>lib.systems.examples</literal>; note how they are not all very
consistent. For now, here are few fields can count on them containing:
</para>
<variablelist>
@@ -84,7 +136,11 @@
</term>
<listitem>
<para>
This is a two-component shorthand for the platform. Examples of this would be "x86_64-darwin" and "i686-linux"; see <literal>lib.systems.doubles</literal> for more. The first component corresponds to the CPU architecture of the platform and the second to the operating system of the platform (<literal>[cpu]-[os]</literal>). This format has built-in support in Nix, such as the <varname>builtins.currentSystem</varname> impure string.
This is a two-component shorthand for the platform. Examples of this
would be "x86_64-darwin" and "i686-linux"; see
<literal>lib.systems.doubles</literal> for more. This format isn't very
standard, but has built-in support in Nix, such as the
This is a 3- or 4- component shorthand for the platform. Examples of this would be <literal>x86_64-unknown-linux-gnu</literal> and <literal>aarch64-apple-darwin14</literal>. This is a standard format called the "LLVM target triple", as they are pioneered by LLVM. In the 4-part form, this corresponds to <literal>[cpu]-[vendor]-[os]-[abi]</literal>. This format is strictly more informative than the "Nix host double", as the previous format could analogously be termed. This needs a better name than <varname>config</varname>!
This is a 3- or 4- component shorthand for the platform. Examples of
this would be "x86_64-unknown-linux-gnu" and "aarch64-apple-darwin14".
This is a standard format called the "LLVM target triple", as they are
pioneered by LLVM and traditionally just used for the
<varname>targetPlatform</varname>. This format is strictly more
informative than the "Nix host double", as the previous format could
analogously be termed. This needs a better name than
<varname>config</varname>!
</para>
</listitem>
</varlistentry>
@@ -104,7 +167,12 @@
</term>
<listitem>
<para>
This is a Nix representation of a parsed LLVM target triple with white-listed components. This can be specified directly, or actually parsed from the <varname>config</varname>. See <literal>lib.systems.parse</literal> for the exact representation.
This is a nix representation of a parsed LLVM target triple with
white-listed components. This can be specified directly, or actually
parsed from the <varname>config</varname>. [Technically, only one need
be specified and the others can be inferred, though the precision of
inference may not be very good.] See
<literal>lib.systems.parse</literal> for the exact representation.
</para>
</listitem>
</varlistentry>
@@ -114,7 +182,10 @@
</term>
<listitem>
<para>
This is a string identifying the standard C library used. Valid identifiers include "glibc" for GNU libc, "libSystem" for Darwin's Libsystem, and "uclibc" for µClibc. It should probably be refactored to use the module system, like <varname>parse</varname>.
This is a string identifying the standard C library used. Valid
identifiers include "glibc" for GNU libc, "libSystem" for Darwin's
Libsystem, and "uclibc" for µClibc. It should probably be refactored to
use the module system, like <varname>parse</varname>.
</para>
</listitem>
</varlistentry>
@@ -124,7 +195,10 @@
</term>
<listitem>
<para>
These predicates are defined in <literal>lib.systems.inspect</literal>, and slapped onto every platform. They are superior to the ones in <varname>stdenv</varname> as they force the user to be explicit about which platform they are inspecting. Please use these instead of those.
These predicates are defined in <literal>lib.systems.inspect</literal>,
and slapped on every platform. They are superior to the ones in
<varname>stdenv</varname> as they force the user to be explicit about
which platform they are inspecting. Please use these instead of those.
</para>
</listitem>
</varlistentry>
@@ -134,99 +208,120 @@
</term>
<listitem>
<para>
This is, quite frankly, a dumping ground of ad-hoc settings (it's an attribute set). See <literal>lib.systems.platforms</literal> for examples—there's hopefully one in there that will work verbatim for each platform that is working. Please help us triage these flags and give them better homes!
This is, quite frankly, a dumping ground of ad-hoc settings (it's an
attribute set). See <literal>lib.systems.platforms</literal> for
examples—there's hopefully one in there that will work verbatim for
each platform that is working. Please help us triage these flags and
<title>Theory of dependency categorization</title>
<section>
<title>Specifying Dependencies</title>
<para>
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 running 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. If a package is being built
with a <literal>(build, host, target)</literal> platform triple of
<literal>(foo, bar, bar)</literal>, then its build-time dependencies would
have a triple of <literal>(foo, foo, bar)</literal>, and <emphasis>those
packages'</emphasis> build-time dependencies would have triple of
<literal>(foo, foo, foo)</literal>. In other words, it should take two
"rounds" of following build-time dependency edges before one reaches a
fixed point where, by the sliding window principle, the platform triple no
longer changes. Indeed, this happens with cross compilation, where only
rounds of native dependencies starting with the second necessarily coincide
with native packages.
</para>
<note>
<para>
This is a rather philosophical description that isn't very Nixpkgs-specific. For an overview of all the relevant attributes given to <varname>mkDerivation</varname>, see <xref
linkend="ssec-stdenv-dependencies"/>. For a description of how everything is implemented, see <xreflinkend="ssec-cross-dependency-implementation"/>.
The depending package's target platform is unconstrained by the sliding
window principle, which makes sense in that one can in principle build
cross compilers targeting arbitrary platforms.
</para>
</note>
<para>
In this section we explore the relationship between both runtime and build-time dependencies and the 3 Autoconf platforms.
How does this work in practice? Nixpkgs is now structured so that
build-time dependencies are taken from <varname>buildPackages</varname>,
whereas run-time dependencies are taken from the top level attribute set.
For example, <varname>buildPackages.gcc</varname> should be used at build
time, while <varname>gcc</varname> should be used at run time. Now, for
most of Nixpkgs's history, there was no <varname>buildPackages</varname>,
and most packages have not been refactored to use it explicitly. Instead,
one can use the six (<emphasis>gasp</emphasis>) attributes used for
specifying dependencies as documented in
<xreflinkend="ssec-stdenv-dependencies"/>. We "splice" together the
run-time and build-time package sets with <varname>callPackage</varname>,
and then <varname>mkDerivation</varname> for each of four attributes pulls
the right derivation out. This splicing can be skipped when not cross
compiling as the package sets are the same, but is a bit slow for cross
compiling. Because of this, a best-of-both-worlds solution is in the works
with no splicing or explicit access of <varname>buildPackages</varname>
needed. For now, feel free to use either method.
</para>
<para>
A run time dependency between two packages requires that their host platforms match. This is directly implied by the meaning of "host platform" and "runtime dependency": The package dependency exists while both packages are running on a single host platform.
</para>
<para>
A build time dependency, however, has a shift in platforms between the depending package and the depended-on package. "build time dependency" means 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.
</para>
<para>
If both the dependency and depending packages aren't compilers or other machine-code-producing tools, we're done. And indeed <varname>buildInputs</varname> and <varname>nativeBuildInputs</varname> have covered these simpler build-time and run-time (respectively) changes for many years. But if the dependency does produce machine code, we might need to worry about its target platform too. In principle, that target platform might be any of the depending package's build, host, or target platforms, but we prohibit dependencies from a "later" platform to an earlier platform to limit confusion because we've never seen a legitimate use for them.
</para>
<para>
Finally, if the depending package is a compiler or other machine-code-producing tool, it might need dependencies that run at "emit time". This is for compilers that (regrettably) insist on being built together with their source langauges' standard libraries. Assuming build != host != target, a run-time dependency of the standard library cannot be run at the compiler's build time or run time, but only at the run time of code emitted by the compiler.
</para>
<para>
Putting this all together, that means we have dependencies in the form "host → target", in at most the following six combinations:
<table>
<caption>Possible dependency types</caption>
<thead>
<tr>
<th>Dependency's host platform</th>
<th>Dependency's target platform</th>
</tr>
</thead>
<tbody>
<tr>
<td>build</td>
<td>build</td>
</tr>
<tr>
<td>build</td>
<td>host</td>
</tr>
<tr>
<td>build</td>
<td>target</td>
</tr>
<tr>
<td>host</td>
<td>host</td>
</tr>
<tr>
<td>host</td>
<td>target</td>
</tr>
<tr>
<td>target</td>
<td>target</td>
</tr>
</tbody>
</table>
</para>
<para>
Some examples will make this table clearer. Suppose there's some package that is being built with a <literal>(build, host, target)</literal> platform triple of <literal>(foo, bar, baz)</literal>. If it has a build-time library dependency, that would be a "host → build" dependency with a triple of <literal>(foo, foo, *)</literal> (the target platform is irrelevant). If it needs a compiler to be built, that would be a "build → host" dependency with a triple of <literal>(foo, foo, *)</literal> (the target platform is irrelevant). That compiler, would be built with another compiler, also "build → host" dependency, with a triple of <literal>(foo, foo, foo)</literal>.
</para>
<note>
<para>
There is also a "backlink" <varname>targetPackages</varname>, yielding a
package set whose <varname>buildPackages</varname> is the current package
set. This is a hack, though, to accommodate compilers with lousy build
systems. Please do not use this unless you are absolutely sure you are
packaging such a compiler and there is no other way.
</para>
</note>
</section>
<sectionxml:id="ssec-cross-cookbook">
<title>Cross packaging cookbook</title>
<section>
<title>Cross packagaing cookbook</title>
<para>
Some frequently encountered problems when packaging for cross-compilation should be answered here. Ideally, the information above is exhaustive, so this section cannot provide any new information, but it is ludicrous and cruel to expect everyone to spend effort working through the interaction of many features just to figure out the same answer to the same common problem. Feel free to add to this list!
Some frequently problems when packaging for crosscompilation are good to
just spell and answer. Ideally the information above is exhaustive, so this
section cannot provide any new information, but its ludicrous and cruel to
expect everyone to spend effort working through the interaction of many
features just to figure out the same answer to the same common problem.
What if my package's build system needs to build a C program to be run under the build environment?
What if my package's build system needs to build a C program to be run
under the build environment?
</para>
</question>
<answer>
@@ -236,7 +331,7 @@
</para>
</answer>
</qandaentry>
<qandaentryxml:id="cross-qa-fails-to-find-ar">
<qandaentry>
<question>
<para>
My package fails to find <command>ar</command>.
@@ -244,11 +339,15 @@
</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 `ar`.
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
My package's testsuite needs to run host platform code.
@@ -268,127 +367,112 @@
<sectionxml:id="sec-cross-usage">
<title>Cross-building packages</title>
<note>
<para>
More information needs to moved from the old wiki, especially
<linkxlink:href="https://nixos.org/wiki/CrossCompiling"/>, for this
section.
</para>
</note>
<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:
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 <nixpkgs> --arg crossSystem '(import <nixpkgs/lib>).systems.examples.fooBarBaz' -A whatever</programlisting>
</para>
<note>
<para>
Eventually we would like to make these platform examples an unnecessary convenience so that
Eventually we would like to make these platform examples an unnecessary
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 <linkxlink:href="https://github.com/NixOS/nixpkgs/issues/34274">#34274</link> tracks this inconvenience along with its root cause in crufty configuration options.
nix-build <nixpkgs> --arg crossSystem.config '<arch>-<os>-<vendor>-<abi>' -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
tracks this inconvenience along with its root cause in crufty configuration
options.
</para>
</note>
<para>
While one is free to pass both parameters in full, there's a lot of logic to fill in missing fields. As discussed in the previous section, only one of <varname>system</varname>, <varname>config</varname>, and <varname>parsed</varname> is needed to infer the other two. Additionally, <varname>libc</varname> will be inferred from <varname>parse</varname>. Finally, <literal>localSystem.system</literal> is also <emphasis>impurely</emphasis> inferred based on the platform evaluation occurs. This means it is often not necessary to pass <varname>localSystem</varname> at all, as in the command-line example in the previous paragraph.
While one is free to pass both parameters in full, there's a lot of logic to
fill in missing fields. As discussed in the previous section, only one of
<varname>system</varname>, <varname>config</varname>, and
<varname>parsed</varname> is needed to infer the other two. Additionally,
<varname>libc</varname> will be inferred from <varname>parse</varname>.
Finally, <literal>localSystem.system</literal> is also
<emphasis>impurely</emphasis> inferred based on the platform evaluation
occurs. This means it is often not necessary to pass
<varname>localSystem</varname> at all, as in the command-line example in the
previous paragraph.
</para>
<note>
<para>
Many sources (manual, wiki, etc) probably mention passing<varname>system</varname>, <varname>platform</varname>, along with the optional <varname>crossSystem</varname> to nixpkgs: <literal>import <nixpkgs> { system = ..; platform = ..; crossSystem = ..; }</literal>. Passing those two instead of <varname>localSystem</varname> is still supported for compatibility, but is discouraged. Indeed, much of the inference we do for these parameters is motivated by compatibility as much as convenience.
Many sources (manual, wiki, etc) probably mention passing
<varname>system</varname>, <varname>platform</varname>, along with the
optional <varname>crossSystem</varname> to nixpkgs: <literal>import
}</literal>. Passing those two instead of <varname>localSystem</varname> is
still supported for compatibility, but is discouraged. Indeed, much of the
inference we do for these parameters is motivated by compatibility as much
as convenience.
</para>
</note>
<para>
One would think that <varname>localSystem</varname> and<varname>crossSystem</varname> overlap horribly with the three <varname>*Platforms</varname> (<varname>buildPlatform</varname>, <varname>hostPlatform,</varname> and <varname>targetPlatform</varname>; see <varname>stage.nix</varname> or the manual). Actually, those identifiers are purposefully not used here to draw a subtle but important distinction: While the granularity of having 3 platforms is necessary to properly *build* packages, it is overkill for specifying the user's *intent* when making a build plan or package set. A simple "build vs deploy" dichotomy is adequate: the sliding window principle described in the previous section shows how to interpolate between the these two "end points" to get the 3 platform triple for each bootstrapping stage. That means for any package a given package set, even those not bound on the top level but only reachable via dependencies or <varname>buildPackages</varname>, the three platforms will be defined as one of <varname>localSystem</varname> or <varname>crossSystem</varname>, with the former replacing the latter as one traverses build-time dependencies. A last simple difference is that <varname>crossSystem</varname> should be null when one doesn't want to cross-compile, while the <varname>*Platform</varname>s are always non-null. <varname>localSystem</varname> is always non-null.
One would think that <varname>localSystem</varname> and
<varname>crossSystem</varname> overlap horribly with the three
The categorizes of dependencies developed in <xref
linkend="ssec-cross-dependency-categorization"/> are specified as lists of derivations given to <varname>mkDerivation</varname>, as documented in <xreflinkend="ssec-stdenv-dependencies"/>. In short, each list of dependencies for "host → target" of "foo → bar" is called <varname>depsFooBar</varname>, with exceptions for backwards compatibility that <varname>depsBuildHost</varname> is instead called <varname>nativeBuildInputs</varname> and <varname>depsHostTarget</varname> is instead called <varname>buildInputs</varname>. Nixpkgs is now structured so that each <varname>depsFooBar</varname> is automatically taken from <varname>pkgsFooBar</varname>. (These <varname>pkgsFooBar</varname>s are quite new, so there is no special case for <varname>nativeBuildInputs</varname> and <varname>buildInputs</varname>.) For example, <varname>pkgsBuildHost.gcc</varname> should be used at build-time, while <varname>pkgsHostTarget.gcc</varname> should be used at run-time.
If one explores nixpkgs, they will see derivations with names like
<literal>gccCross</literal>. Such <literal>*Cross</literal> derivations is
a holdover from before we properly distinguished between the host and
target platforms —the derivation with "Cross" in the name covered the
<literal>build = host != target</literal> case, while the other covered the
<literal>host = target</literal>, with build platform the same or not based
on whether one was using its <literal>.nativeDrv</literal> or
<literal>.crossDrv</literal>. This ugliness will disappear soon.
</para>
<para>
Now, for most of Nixpkgs's history, there were no <varname>pkgsFooBar</varname> attributes, and most packages have not been refactored to use it explicitly. Prior to those, there were just <varname>buildPackages</varname>, <varname>pkgs</varname>, and <varname>targetPackages</varname>. Those are now redefined as aliases to <varname>pkgsBuildHost</varname>, <varname>pkgsHostTarget</varname>, and <varname>pkgsTargetTarget</varname>. It is acceptable, even recommended, to use them for libraries to show that the host platform is irrelevant.
</para>
<para>
But before that, there was just <varname>pkgs</varname>, even though both <varname>buildInputs</varname> and <varname>nativeBuildInputs</varname> existed. [Cross barely worked, and those were implemented with some hacks on <varname>mkDerivation</varname> to override dependencies.] What this means is the vast majority of packages do not use any explicit package set to populate their dependencies, just using whatever <varname>callPackage</varname> gives them even if they do correctly sort their dependencies into the multiple lists described above. And indeed, asking that users both sort their dependencies, <emphasis>and</emphasis> take them from the right attribute set, is both too onerous and redundant, so the recommended approach (for now) is to continue just categorizing by list and not using an explicit package set.
</para>
<para>
To make this work, we "splice" together the six <varname>pkgsFooBar</varname> package sets and have <varname>callPackage</varname> actually take its arguments from that. This is currently implemented in <filename>pkgs/top-level/splice.nix</filename>. <varname>mkDerivation</varname> then, for each dependency attribute, pulls the right derivation out from the splice. This splicing can be skipped when not cross-compiling as the package sets are the same, but still is a bit slow for cross-compiling. We'd like to do something better, but haven't come up with anything yet.
</para>
</section>
<sectionxml:id="ssec-bootstrapping">
<title>Bootstrapping</title>
<para>
Each of the package sets described above come from a single bootstrapping stage. While <filename>pkgs/top-level/default.nix</filename>, coordinates the composition of stages at a high level, <filename>pkgs/top-level/stage.nix</filename> "ties the knot" (creates the fixed point) of each stage. The package sets are defined per-stage however, so they can be thought of as edges between stages (the nodes) in a graph. Compositions like <literal>pkgsBuildTarget.targetPackages</literal> can be thought of as paths to this graph.
</para>
<para>
While there are many package sets, and thus many edges, the stages can also be arranged in a linear chain. In other words, many of the edges are redundant as far as connectivity is concerned. This hinges on the type of bootstrapping we do. Currently for cross it is:
<orderedlist>
<listitem>
<para>
<literal>(native, native, native)</literal>
</para>
</listitem>
<listitem>
<para>
<literal>(native, native, foreign)</literal>
</para>
</listitem>
<listitem>
<para>
<literal>(native, foreign, foreign)</literal>
</para>
</listitem>
</orderedlist>
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 the bootstrapping stages leading up to the final stages are ignored inthe previous paragraph.
</para>
</note>
<para>
If one looks at the 3 platform triples, one can see that they overlap such that one could put them together into a chain like:
<programlisting>
(native, native, native, foreign, foreign)
</programlisting>
If one imagines the saturating self references at the end being replaced with infinite stages, and then overlays those platform triples, one ends up with the infinite tuple:
On can then imagine any sequence of platforms such that there are bootstrap stages with their 3 platforms determined by "sliding a window" that is the 3 tuple through the sequence. This was the original model for bootstrapping. Without a target platform (assume a better world where all compilers are multi-target and all standard libraries are built in their own derivation), this is sufficient. Conversely if one wishes to cross compile "faster", with a "Canadian Cross" bootstraping stage where <literal>build != host != target</literal>, more bootstrapping stages are needed since no sliding window providess the pesky <varname>pkgsBuildTarget</varname> package set since it skips the Canadian cross stage's "host".
</para>
<note>
<para>
It is much better to refer to <varname>buildPackages</varname> than <varname>targetPackages</varname>, or more broadly package sets that do not mention "target". There are three reasons for this.
</para>
<para>
First, it is because bootstrapping stages do not have a unique <varname>targetPackages</varname>. For example a <literal>(x86-linux, x86-linux, arm-linux)</literal> and <literal>(x86-linux, x86-linux, x86-windows)</literal> package set both have a <literal>(x86-linux, x86-linux, x86-linux)</literal> package set. Because there is no canonical <varname>targetPackages</varname> for such a native (<literal>build == host == target</literal>) package set, we set their <varname>targetPackages</varname>
</para>
<para>
Second, it is because this is a frequent source of hard-to-follow "infinite recursions" / cycles. When only package sets that don't mention target are used, the package set forms a directed acyclic graph. This means that all cycles that exist are confined to one stage. This means they are a lot smaller, and easier to follow in the code or a backtrace. It also means they are present in native and cross builds alike, and so more likely to be caught by CI and other users.
</para>
<para>
Thirdly, it is because everything target-mentioning only exists to accommodate compilers with lousy build systems that insist on the compiler itself and standard library being built together. Of course that is bad because bigger derivations means longer rebuilds. It is also problematic because it tends to make the standard libraries less like other libraries than they could be, complicating code and build systems alike. Because of the other problems, and because of these innate disadvantages, compilers ought to be packaged another way where possible.
</para>
</note>
<note>
<para>
If one explores Nixpkgs, they will see derivations with names like <literal>gccCross</literal>. Such <literal>*Cross</literal> derivations is a holdover from before we properly distinguished between the host and target platforms—the derivation with "Cross" in the name covered the <literal>build = host != target</literal> case, while the other covered the <literal>host = target</literal>, with build platform the same or not based on whether one was using its <literal>.nativeDrv</literal> or <literal>.crossDrv</literal>. This ugliness will disappear soon.
<varname>pkgs.appimageTools</varname> is a set of functions for extracting and wrapping <linkxlink:href="https://appimage.org/">AppImage</link> files. They are meant to be used if traditional packaging from source is infeasible, or it would take too long. To quickly run an AppImage file, <literal>pkgs.appimage-run</literal> can be used as well.
</para>
<warning>
<para>
The <varname>appimageTools</varname> API is unstable and may be subject to backwards-incompatible changes in the future.
</para>
</warning>
<sectionxml:id="ssec-pkgs-appimageTools-formats">
<title>AppImage formats</title>
<para>
There are different formats for AppImages, see <linkxlink:href="https://github.com/AppImage/AppImageSpec/blob/74ad9ca2f94bf864a4a0dac1f369dd4f00bd1c28/draft.md#image-format">the specification</link> for details.
</para>
<itemizedlist>
<listitem>
<para>
Type 1 images are ISO 9660 files that are also ELF executables.
</para>
</listitem>
<listitem>
<para>
Type 2 images are ELF executables with an appended filesystem.
</para>
</listitem>
</itemizedlist>
<para>
They can be told apart with <command>file -k</command>:
</para>
<screen>
<prompt>$ </prompt>file -k type1.AppImage
type1.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) ISO 9660 CD-ROM filesystem data 'AppImage' (Lepton 3.x), scale 0-0,
spot sensor temperature 0.000000, unit celsius, color scheme 0, calibration: offset 0.000000, slope 0.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=d629f6099d2344ad82818172add1d38c5e11bc6d, stripped\012- data
<prompt>$ </prompt>file -k type2.AppImage
type2.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) (Lepton 3.x), scale 232-60668, spot sensor temperature -4.187500, color scheme 15, show scale bar, calibration: offset -0.000000, slope 0.000000 (Lepton 2.x), scale 4111-45000, spot sensor temperature 412442.250000, color scheme 3, minimum point enabled, calibration: offset -75402534979642766821519867692934234112.000000, slope 5815371847733706829839455140374904832.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=79dcc4e55a61c293c5e19edbd8d65b202842579f, stripped\012- data
</screen>
<para>
Note how the type 1 AppImage is described as an <literal>ISO 9660 CD-ROM filesystem</literal>, and the type 2 AppImage is not.
extraPkgs = pkgs: with pkgs; [ ]; <coxml:id='ex-appimageTools-wrapping-3'/>
}</programlisting>
<calloutlist>
<calloutarearefs='ex-appimageTools-wrapping-1'>
<para>
<varname>name</varname> specifies the name of the resulting image.
</para>
</callout>
<calloutarearefs='ex-appimageTools-wrapping-2'>
<para>
<varname>src</varname> specifies the AppImage file to extract.
</para>
</callout>
<calloutarearefs='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>
<listitem>
<para>
Looking through the extracted AppImage files, reading its scripts and running <command>patchelf</command> and <command>ldd</command> on its executables. This can also be done in <command>appimage-run</command>, by setting <command>APPIMAGE_DEBUG_EXEC=bash</command>.
</para>
</listitem>
<listitem>
<para>
Running <command>strace -vfefile</command> on the wrapped executable, looking for libraries that can't be found.
Nix is a unityped, dynamic language, this means every value can potentially appear anywhere. Since it is also non-strict, evaluation order and what ultimately is evaluated might surprise you. Therefore it is important to be able to debug nix expressions.
</para>
<para>
In the <literal>lib/debug.nix</literal> file you will find a number of functions that help (pretty-)printing values while evaluation is runnnig. You can even specify how deep these values should be printed recursively, and transform them on the fly. Please consult the docstrings in <literal>lib/debug.nix</literal> for usage information.
<varname>pkgs.dockerTools</varname> is a set of functions for creating and manipulating Docker images according to the <linkxlink: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.
This function is analogous to the <command>docker build</command> command, in that it can be used to build a Docker-compatible repository tarball containing a single image with one or multiple layers. As such, the result is suitable for being loaded in Docker with <command>docker load</command>.
</para>
<para>
The parameters of <varname>buildImage</varname> with relative example values are described below:
</para>
<examplexml:id='ex-dockerTools-buildImage'>
<title>Docker build</title>
<programlisting>
buildImage {
name = "redis"; <coxml:id='ex-dockerTools-buildImage-1'/>
tag = "latest"; <coxml:id='ex-dockerTools-buildImage-2'/>
The above example will build a Docker image <literal>redis/latest</literal> from the given base image. Loading and running this image in Docker results in <literal>redis-server</literal> being started automatically.
</para>
<calloutlist>
<calloutarearefs='ex-dockerTools-buildImage-1'>
<para>
<varname>name</varname> specifies the name of the resulting image. This is the only required argument for <varname>buildImage</varname>.
</para>
</callout>
<calloutarearefs='ex-dockerTools-buildImage-2'>
<para>
<varname>tag</varname> specifies the tag of the resulting image. By default it's <literal>null</literal>, which indicates that the nix output hash will be used as tag.
</para>
</callout>
<calloutarearefs='ex-dockerTools-buildImage-3'>
<para>
<varname>fromImage</varname> is the repository tarball containing the base image. It must be a valid Docker image, such as exported by <command>docker save</command>. By default it's <literal>null</literal>, which can be seen as equivalent to <literal>FROM scratch</literal> of a <filename>Dockerfile</filename>.
</para>
</callout>
<calloutarearefs='ex-dockerTools-buildImage-4'>
<para>
<varname>fromImageName</varname> can be used to further specify the base image within the repository, in case it contains multiple images. By default it's <literal>null</literal>, in which case <varname>buildImage</varname> will peek the first image available in the repository.
</para>
</callout>
<calloutarearefs='ex-dockerTools-buildImage-5'>
<para>
<varname>fromImageTag</varname> can be used to further specify the tag of the base image within the repository, in case an image contains multiple tags. By default it's <literal>null</literal>, in which case <varname>buildImage</varname> will peek the first tag available for the base image.
</para>
</callout>
<calloutarearefs='ex-dockerTools-buildImage-6'>
<para>
<varname>contents</varname> is a derivation that will be copied in the new layer of the resulting image. This can be similarly seen as <command>ADD contents/ /</command> in a <filename>Dockerfile</filename>. By default it's <literal>null</literal>.
<varname>runAsRoot</varname> is a bash script that will run as root in an environment that overlays the existing layers of the base image with the new resulting layer, including the previously copied <varname>contents</varname> derivation. This can be similarly seen as <command>RUN ...</command> in a <filename>Dockerfile</filename>.
<note>
<para>
Using this parameter requires the <literal>kvm</literal> device to be available.
</para>
</note>
</para>
</callout>
<calloutarearefs='ex-dockerTools-buildImage-8'>
<para>
<varname>config</varname> is used to specify the configuration of the containers that will be started off the built image in Docker. The available options are listed in the <linkxlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions"> Docker Image Specification v1.2.0 </link>.
</para>
</callout>
</calloutlist>
<para>
After the new layer has been created, its closure (to which <varname>contents</varname>, <varname>config</varname> and <varname>runAsRoot</varname> contribute) will be copied in the layer itself. Only new dependencies that are not already in the existing layers will be copied.
</para>
<para>
At the end of the process, only one new single layer will be produced and added to the resulting image.
</para>
<para>
The resulting repository will only list the single image <varname>image/tag</varname>. In the case of <xreflinkend='ex-dockerTools-buildImage'/> it would be <varname>redis/latest</varname>.
</para>
<para>
It is possible to inspect the arguments with which an image was built using its <varname>buildArgs</varname> attribute.
</para>
<note>
<para>
If you see errors similar to <literal>getProtocolByName: does not exist (no such protocol name: tcp)</literal> you may need to add <literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
</para>
</note>
<note>
<para>
If you see errors similar to <literal>Error_Protocol ("certificate has unknown CA",True,UnknownCa)</literal> you may need to add <literal>pkgs.cacert</literal> to <varname>contents</varname>.
<title>Impurely Defining a Docker Layer's Creation Date</title>
<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><![CDATA[
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
hello latest 08c791c7846e 48 years ago 25.2MB
]]></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>
<programlisting><![CDATA[
pkgs.dockerTools.buildImage {
name = "hello";
tag = "latest";
created = "now";
contents = pkgs.hello;
config.Cmd = [ "/bin/hello" ];
}
]]></programlisting>
<para>
and now the Docker CLI will display a reasonable date and sort the images as expected:
<screen><![CDATA[
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
hello latest de2bf4786de6 About a minute ago 25.2MB
]]></screen>
however, the produced images will not be binary reproducible.
Run-time configuration of the container. A full list of the options are available at in the <linkxlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions"> Docker Image Specification v1.2.0 </link>.
Shell commands to run while building the final layer, without access to most of the layer contents. Changes to this layer are "on top" of all the other layers, so can create additional directories and files.
Increasing the <varname>maxLayers</varname> increases the number of layers which have a chance to be shared between different images.
</para>
<para>
Modern Docker installations support up to 128 layers, however older versions support as few as 42.
</para>
<para>
If the produced image will not be extended by other Docker builds, it is safe to set <varname>maxLayers</varname> to <literal>128</literal>. However it will be impossible to extend the image further.
</para>
<para>
The first (<literal>maxLayers-2</literal>) most "popular" paths will have their own individual layers, then layer #<literal>maxLayers-1</literal> will contain all the remaining "unpopular" paths, and finally layer #<literal>maxLayers</literal> will contain the Image configuration.
</para>
<para>
Docker's Layers are not inherently ordered, they are content-addressable and are not explicitly layered until they are composed in to an Image.
This function is analogous to the <command>docker pull</command> command, in that it can be used to pull a Docker image from a Docker registry. By default <linkxlink:href="https://hub.docker.com/">Docker Hub</link> is used to pull images.
</para>
<para>
Its parameters are described in the example below:
<varname>imageName</varname> specifies the name of the image to be downloaded, which can also include the registry namespace (e.g. <literal>nixos</literal>). This argument is required.
</para>
</callout>
<calloutarearefs='ex-dockerTools-pullImage-2'>
<para>
<varname>imageDigest</varname> specifies the digest of the image to be downloaded. This argument is required.
</para>
</callout>
<calloutarearefs='ex-dockerTools-pullImage-3'>
<para>
<varname>finalImageName</varname>, if specified, this is the name of the image to be created. Note it is never used to fetch the image since we prefer to rely on the immutable digest ID. By default it's equal to <varname>imageName</varname>.
</para>
</callout>
<calloutarearefs='ex-dockerTools-pullImage-4'>
<para>
<varname>finalImageTag</varname>, if specified, this is the tag of the image to be created. Note it is never used to fetch the image since we prefer to rely on the immutable digest ID. By default it's <literal>latest</literal>.
</para>
</callout>
<calloutarearefs='ex-dockerTools-pullImage-5'>
<para>
<varname>sha256</varname> is the checksum of the whole fetched image. This argument is required.
</para>
</callout>
<calloutarearefs='ex-dockerTools-pullImage-6'>
<para>
<varname>os</varname>, if specified, is the operating system of the fetched image. By default it's <literal>linux</literal>.
</para>
</callout>
<calloutarearefs='ex-dockerTools-pullImage-7'>
<para>
<varname>arch</varname>, if specified, is the cpu architecture of the fetched image. By default it's <literal>x86_64</literal>.
</para>
</callout>
</calloutlist>
<para>
<literal>nix-prefetch-docker</literal> command can be used to get required image parameters:
<screen>
<prompt>$ </prompt>nix run nixpkgs.nix-prefetch-docker -c nix-prefetch-docker --image-name mysql --image-tag 5
</screen>
Since a given <varname>imageName</varname> may transparently refer to a manifest list of images which support multiple architectures and/or operating systems, you can supply the <option>--os</option> and <option>--arch</option> arguments to specify exactly which image you want. By default it will match the OS and architecture of the host the command is run on.
<screen>
<prompt>$ </prompt>nix-prefetch-docker --image-name mysql --image-tag 5 --arch x86_64 --os linux
</screen>
Desired image name and tag can be set using <option>--final-image-name</option> and <option>--final-image-tag</option> arguments:
<screen>
<prompt>$ </prompt>nix-prefetch-docker --image-name mysql --image-tag 5 --final-image-name eu.gcr.io/my-project/mysql --final-image-tag prod
This function is analogous to the <command>docker export</command> command, in that it can be used to flatten a Docker image that contains multiple layers. It is in fact the result of the merge of all the layers of the image. As such, the result is suitable for being imported in Docker with <command>docker import</command>.
</para>
<note>
<para>
Using this function requires the <literal>kvm</literal> device to be available.
</para>
</note>
<para>
The parameters of <varname>exportImage</varname> are the following:
</para>
<examplexml:id='ex-dockerTools-exportImage'>
<title>Docker export</title>
<programlisting>
exportImage {
fromImage = someLayeredImage;
fromImageName = null;
fromImageTag = null;
name = someLayeredImage.name;
}
</programlisting>
</example>
<para>
The parameters relative to the base image have the same synopsis as described in <xreflinkend='ssec-pkgs-dockerTools-buildImage'/>, except that <varname>fromImage</varname> is the only required argument in this case.
</para>
<para>
The <varname>name</varname> argument is the name of the derivation output, which defaults to <varname>fromImage.name</varname>.
This constant string is a helper for setting up the base files for managing users and groups, only if such files don't exist already. It is suitable for being used in a <varname>runAsRoot</varname><xreflinkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like in the example below:
</para>
<examplexml:id='ex-dockerTools-shadowSetup'>
<title>Shadow base files</title>
<programlisting>
buildImage {
name = "shadow-basic";
runAsRoot = ''
#!${pkgs.runtimeShell}
${shadowSetup}
groupadd -r redis
useradd -r -g redis redis
mkdir /data
chown redis:redis /data
'';
}
</programlisting>
</example>
<para>
Creating base files like <literal>/etc/passwd</literal> or <literal>/etc/login.defs</literal> is necessary for shadow-utils to manipulate users and groups.
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.
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>
<literal>fetchsvn</literal>
</term>
<listitem>
<para>
Used with Subversion. Expects <literal>url</literal> to a Subversion directory, <literal>rev</literal>, and <literal>sha256</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchgit</literal>
</term>
<listitem>
<para>
Used with Git. Expects <literal>url</literal> to a Git repo, <literal>rev</literal>, and <literal>sha256</literal>. <literal>rev</literal> in this case can be full the git commit id (SHA1 hash) or a tag name like <literal>refs/tags/v1.0</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchfossil</literal>
</term>
<listitem>
<para>
Used with Fossil. Expects <literal>url</literal> to a Fossil archive, <literal>rev</literal>, and <literal>sha256</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchcvs</literal>
</term>
<listitem>
<para>
Used with CVS. Expects <literal>cvsRoot</literal>, <literal>tag</literal>, and <literal>sha256</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchhg</literal>
</term>
<listitem>
<para>
Used with Mercurial. Expects <literal>url</literal>, <literal>rev</literal>, and <literal>sha256</literal>.
</para>
</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>
<literal>fetchFromGitHub</literal>
</term>
<listitem>
<para>
<function>fetchFromGitHub</function> expects four arguments. <literal>owner</literal> is a string corresponding to the GitHub user or organization that controls this repository. <literal>repo</literal> corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as <literal>owner</literal>/<literal>repo</literal>. <literal>rev</literal> corresponds to the Git commit hash or tag (e.g <literal>v1.0</literal>) that will be downloaded from Git. Finally, <literal>sha256</literal> corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but <literal>sha256</literal> is currently preferred.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchFromGitLab</literal>
</term>
<listitem>
<para>
This is used with GitLab repositories. The arguments expected are very similar to fetchFromGitHub above.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchFromBitbucket</literal>
</term>
<listitem>
<para>
This is used with BitBucket repositories. The arguments expected are very similar to fetchFromGitHub above.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchFromSavannah</literal>
</term>
<listitem>
<para>
This is used with Savannah repositories. The arguments expected are very similar to fetchFromGitHub above.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchFromRepoOrCz</literal>
</term>
<listitem>
<para>
This is used with repo.or.cz repositories. The arguments expected are very similar to fetchFromGitHub above.
<function>buildFHSUserEnv</function> provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root with bound <filename>/nix/store</filename>, so its footprint in terms of disk space needed is quite small. This allows one to run software which is hard or unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries. It uses Linux namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without root user rights requirement. Accepted arguments are:
</para>
<variablelist>
<varlistentry>
<term>
<literal>name</literal>
</term>
<listitem>
<para>
Environment name.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>targetPkgs</literal>
</term>
<listitem>
<para>
Packages to be installed for the main host's architecture (i.e. x86_64 on x86_64 installations). Along with libraries binaries are also installed.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>multiPkgs</literal>
</term>
<listitem>
<para>
Packages to be installed for all architectures supported by a host (i.e. i686 and x86_64 on x86_64 installations). Only libraries are installed by default.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>extraBuildCommands</literal>
</term>
<listitem>
<para>
Additional commands to be executed for finalizing the directory structure.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>extraBuildCommandsMulti</literal>
</term>
<listitem>
<para>
Like <literal>extraBuildCommands</literal>, but executed only on multilib architectures.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>extraOutputsToInstall</literal>
</term>
<listitem>
<para>
Additional derivation outputs to be linked for both target and multi-architecture packages.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>extraInstallCommands</literal>
</term>
<listitem>
<para>
Additional commands to be executed for finalizing the derivation with runner script.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>runScript</literal>
</term>
<listitem>
<para>
A command that would be executed inside the sandbox and passed all the command line arguments. It defaults to <literal>bash</literal>.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
One can create a simple environment using a <literal>shell.nix</literal> like that:
</para>
<programlisting><![CDATA[
{ pkgs ? import <nixpkgs> {} }:
(pkgs.buildFHSUserEnv {
name = "simple-x11-env";
targetPkgs = pkgs: (with pkgs;
[ udev
alsaLib
]) ++ (with pkgs.xorg;
[ libX11
libXcursor
libXrandr
]);
multiPkgs = pkgs: (with pkgs;
[ udev
alsaLib
]);
runScript = "bash";
}).env
]]></programlisting>
<para>
Running <literal>nix-shell</literal> would then drop you into a shell with these libraries and binaries available. You can use this to run closed-source applications which expect FHS structure without hassles: simply change <literal>runScript</literal> to the application path, e.g. <filename>./bin/start.sh</filename> -- relative paths are supported.
Generators are functions that create file formats from nix data structures, e.g. for configuration files. There are generators available for: <literal>INI</literal>, <literal>JSON</literal> and <literal>YAML</literal>
</para>
<para>
All generators follow a similar call interface: <code>generatorName configFunctions data</code>, where <literal>configFunctions</literal> is an attrset of user-defined functions that format nested parts of the content. They each have common defaults, so often they do not need to be set manually. An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]" ] name)</code> from the <literal>INI</literal> generator. It receives the name of a section and sanitizes it. The default <literal>mkSectionName</literal> escapes <literal>[</literal> and <literal>]</literal> with a backslash.
</para>
<para>
Generators can be fine-tuned to produce exactly the file format required by your application/service. One example is an INI-file format which uses <literal>: </literal> as separator, the strings <literal>"yes"</literal>/<literal>"no"</literal> as boolean values and requires all string values to be quoted:
</para>
<programlisting>
with lib;
let
customToINI = generators.toINI {
# specifies how to format a key/value pair
mkKeyValue = generators.mkKeyValueDefault {
# specifies the generated string for a subset of nix values
mkValueString = v:
if v == true then ''"yes"''
else if v == false then ''"no"''
else if isString v then ''"${v}"''
# and delegats all other values to the default generator
else generators.mkValueStringDefault {} v;
} ":";
};
# the INI file can now be given as plain old nix values
in customToINI {
main = {
pushinfo = true;
autopush = false;
host = "localhost";
port = 42;
};
mergetool = {
merge = "diff3";
};
}
</programlisting>
<para>
This will produce the following INI file as nix string:
</para>
<programlisting>
[main]
autopush:"no"
host:"localhost"
port:42
pushinfo:"yes"
str\:ange:"very::strange"
[mergetool]
merge:"diff3"
</programlisting>
<note>
<para>
Nix store paths can be converted to strings by enclosing a derivation attribute like so: <code>"${drv}"</code>.
</para>
</note>
<para>
Detailed documentation for each generator can be found in <literal>lib/generators.nix</literal>.
Specialized <function>asserts.assertMsg</function> for checking if <varname>val</varname> is one of the elements of <varname>xs</varname>. Useful for checking enums.
</para>
<variablelist>
<varlistentry>
<term>
<varname>name</varname>
</term>
<listitem>
<para>
The name of the variable the user entered <varname>val</varname> into, for inclusion in the error message.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<varname>val</varname>
</term>
<listitem>
<para>
The value of what the user provided, to be compared against the values in <varname>xs</varname>.
<function>pkgs.nix-gitignore</function> is a function that acts similarly to <literal>builtins.filterSource</literal> but also allows filtering with the help of the gitignore format.
</para>
<sectionxml:id="sec-pkgs-nix-gitignore-usage">
<title>Usage</title>
<para>
<literal>pkgs.nix-gitignore</literal> exports a number of functions, but you'll most likely need either <literal>gitignoreSource</literal> or <literal>gitignoreSourcePure</literal>. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
Those filter functions accept the same arguments the <literal>builtins.filterSource</literal> function would pass to its filters, thus <literal>fn: gitignoreFilterSourcePure fn ""</literal> should be extensionally equivalent to <literal>filterSource</literal>. The file is blacklisted iff it's blacklisted by either your filter or the gitignoreFilter.
</para>
<para>
If you want to make your own filter from scratch, you may use
<varname>pkgs.ociTools</varname> is a set of functions for creating containers according to the <linkxlink:href="https://github.com/opencontainers/runtime-spec">OCI container specification v1.0.0</link>. Beyond that it makes no assumptions about the container runner you choose to use to run the created container.
This function creates a simple OCI container that runs a single command inside of it. An OCI container consists of a <varname>config.json</varname> and a rootfs directory.The nix store of the container will contain all referenced dependencies of the given command.
</para>
<para>
The parameters of <varname>buildContainer</varname> with an example value are described below:
<varname>args</varname> specifies a set of arguments to run inside the container. This is the only required argument for <varname>buildContainer</varname>. All referenced packages inside the derivation will be made available inside the container
</para>
</callout>
<calloutarearefs='ex-ociTools-buildContainer-2'>
<para>
<varname>mounts</varname> specifies additional mount points chosen by the user. By default only a minimal set of necessary filesystems are mounted into the container (e.g procfs, cgroupfs)
</para>
</callout>
<calloutarearefs='ex-ociTools-buildContainer-3'>
<para>
<varname>readonly</varname> makes the container's rootfs read-only if it is set to true. The default value is false <literal>false</literal>.
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. <linkxlink: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>
<sectionxml:id="sec-pkg-override">
<title><pkg>.override</title>
<para>
The function <varname>override</varname> is usually available for all the derivations in the nixpkgs expression (<varname>pkgs</varname>).
</para>
<para>
It is used to override the arguments passed to a function.
<!-- TODO: move below programlisting to a new section about extending and overlays
and reference it
-->
<programlisting>
import pkgs.path { overlays = [ (self: super: {
foo = super.foo.override { barSupport = true ; };
})]};
</programlisting>
<programlisting>
mypkg = pkgs.callPackage ./mypkg.nix {
mydep = pkgs.mydep.override { ... };
}
</programlisting>
</para>
<para>
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>
<sectionxml:id="sec-pkg-overrideAttrs">
<title><pkg>.overrideAttrs</title>
<para>
The function <varname>overrideAttrs</varname> allows overriding the attribute set passed to a <varname>stdenv.mkDerivation</varname> call, producing a new derivation based on the original one. This function is available on all derivations produced by the <varname>stdenv.mkDerivation</varname> function, which is most packages in the nixpkgs expression <varname>pkgs</varname>.
In the above example, the <varname>separateDebugInfo</varname> attribute is 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>
<para>
The argument <varname>oldAttrs</varname> is conventionally used to refer to the attr set originally passed to <varname>stdenv.mkDerivation</varname>.
</para>
<note>
<para>
Note that <varname>separateDebugInfo</varname> is processed only by the <varname>stdenv.mkDerivation</varname> function, not the generated, raw Nix derivation. Thus, using <varname>overrideDerivation</varname> will not work in this case, as it overrides only the attributes of the final derivation. It is for this reason that <varname>overrideAttrs</varname> should be preferred in (almost) all cases to <varname>overrideDerivation</varname>, i.e. to allow using <varname>stdenv.mkDerivation</varname> to process input arguments, as well as the fact that it is easier to use (you can use the same attribute names you see in your Nix code, instead of the ones generated (e.g. <varname>buildInputs</varname> vs <varname>nativeBuildInputs</varname>), and it involves less typing).
</para>
</note>
</section>
<sectionxml:id="sec-pkg-overrideDerivation">
<title><pkg>.overrideDerivation</title>
<warning>
<para>
You should prefer <varname>overrideAttrs</varname> in almost all cases, see its documentation for the reasons why. <varname>overrideDerivation</varname> is not deprecated and will continue to work, but is less nice to use and does not have as many abilities as <varname>overrideAttrs</varname>.
</para>
</warning>
<warning>
<para>
Do not use this function in Nixpkgs as it evaluates a Derivation before modifying it, which breaks package abstraction and removes error-checking of function arguments. In addition, this evaluation-per-function application incurs a performance penalty, which can become a problem if many overrides are used. It is only intended for ad-hoc customisation, such as in <filename>~/.config/nixpkgs/config.nix</filename>.
</para>
</warning>
<para>
The function <varname>overrideDerivation</varname> creates a new derivation based on an existing one by overriding the original's attributes with the attribute set produced by the specified function. This function is available on all derivations defined using the <varname>makeOverridable</varname> function. Most standard derivation-producing functions, such as <varname>stdenv.mkDerivation</varname>, are defined using this function, which means most packages in the nixpkgs expression, <varname>pkgs</varname>, have this function.
In the above example, the <varname>name</varname>, <varname>src</varname>, and <varname>patches</varname> of the derivation will be overridden, while all other attributes will be retained from the original derivation.
</para>
<para>
The argument <varname>oldAttrs</varname> is used to refer to the attribute set of the original derivation.
</para>
<note>
<para>
A package's attributes are evaluated *before* being modified by the <varname>overrideDerivation</varname> function. For example, the <varname>name</varname> attribute reference in <varname>url = "mirror://gnu/hello/${name}.tar.gz";</varname> is filled-in *before* the <varname>overrideDerivation</varname> function modifies the attribute set. This means that overriding the <varname>name</varname> attribute, in this example, *will not* change the value of the <varname>url</varname> attribute. Instead, we need to override both the <varname>name</varname> *and* <varname>url</varname> attributes.
</para>
</note>
</section>
<sectionxml:id="sec-lib-makeOverridable">
<title>lib.makeOverridable</title>
<para>
The function <varname>lib.makeOverridable</varname> is used to make the result of a function easily customizable. This utility only makes sense for functions that accept an argument set and return an attribute set.
</para>
<para>
Example usage:
<programlisting>
f = { a, b }: { result = a+b; };
c = lib.makeOverridable f { a = 1; b = 2; };
</programlisting>
</para>
<para>
The variable <varname>c</varname> is the value of the <varname>f</varname> function applied with some default arguments. Hence the value of <varname>c.result</varname> is <literal>3</literal>, in this example.
</para>
<para>
The variable <varname>c</varname> however also has some additional functions, like <linklinkend="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.
<function>prefer-remote-fetch</function> is an overlay that download sources on remote builder. This is useful when the evaluating machine has a slow upload while the builder can fetch faster directly from the source. To use it, put the following snippet as a new overlay:
<programlisting>
self: super:
(super.prefer-remote-fetch self super)
</programlisting>
A full configuration example for that sets the overlay up for your own account, could look like this
<function>pkgs.mkShell</function> is a special kind of derivation that is only useful when using it combined with <command>nix-shell</command>. It will in fact fail to instantiate when invoked with <command>nix-build</command>.
</para>
<sectionxml:id="sec-pkgs-mkShell-usage">
<title>Usage</title>
<programlisting>< as an example for how to build a Crystal package.
If the Crystal project has any dependencies, the first step is to get a `shards.nix` file encoding those. Get a copy of the project and go to its root directory such that its `shard.lock` file is in the current directory, then run `crystal2nix` in it
```bash
$ git clone https://github.com/mint-lang/mint
$ cd mint
$ git checkout 0.5.0
$ nix-shell -p crystal2nix --run crystal2nix
```
This should have generated a `shards.nix` file.
Next create a Nix file for your derivation and use `pkgs.crystal.buildCrystalPackage` as follows:
This won't build anything yet, because we haven't told it what files build. We can specify a mapping from binary names to source files with the `crystalBinaries` attribute. The project's compilation instructions should show this. For Mint, the binary is called "mint", which is compiled from the source file `src/mint.cr`, so we'll specify this as follows:
```nix
crystalBinaries.mint.src="src/mint.cr";
# ...
```
Additionally you can override the default `crystal build` options (which are currently `--release --progress --no-debug --verbose`) with
Depending on the project, you might need additional steps to get it to compile successfully. In Mint's case, we need to link against openssl, so in the end the Nix file looks as follows:
[Emscripten](https://github.com/kripken/emscripten): An LLVM-to-JavaScript Compiler
This section of the manual covers how to use `emscripten` in nixpkgs.
Minimal requirements:
* nix
* nixpkgs
Modes of use of `emscripten`:
* **Imperative usage** (on the command line):
If you want to work with `emcc`, `emconfigure` and `emmake` as you are used to from Ubuntu and similar distributions you can use these commands:
*`nix-env -i emscripten`
*`nix-shell -p 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`
## Imperative usage
A few things to note:
*`export EMCC_DEBUG=2` is nice for debugging
*`~/.emscripten`, the build artifact cache sometimes creates issues and needs to be removed from time to time
## Declarative usage
Let's see two different examples from `pkgs/top-level/emscripten-packages.nix`:
*`pkgs.zlib.override`
*`pkgs.buildEmscriptenPackage`
Both are interesting concepts.
A special requirement of the `pkgs.buildEmscriptenPackage` is the `doCheck = true` is a default meaning that each emscriptenPackage requires a `checkPhase` implemented.
* Use `export EMCC_DEBUG=2` from within a emscriptenPackage's `phase` to get more detailed debug output what is going wrong.
* ~/.emscripten cache is requiring us to set `HOME=$TMPDIR` in individual phases. This makes compilation slower but also makes it more deterministic.
### Usage 1: pkgs.zlib.override
This example uses `zlib` from nixpkgs but instead of compiling **C** to **ELF** it compiles **C** to **JS** since we were using `pkgs.zlib.override` and changed stdenv to `pkgs.emscriptenStdenv`. A few adaptions and hacks were set in place to make it working. One advantage is that when `pkgs.zlib` is updated, it will automatically update this package as well. However, this can also be the downside...
See the `zlib` example:
zlib = (pkgs.zlib.override {
stdenv = pkgs.emscriptenStdenv;
}).overrideDerivation
(old: rec {
buildInputs = old.buildInputs ++ [ pkgconfig ];
# we need to reset this setting!
NIX_CFLAGS_COMPILE="";
configurePhase = ''
# FIXME: Some tests require writing at $HOME
HOME=$TMPDIR
runHook preConfigure
#export EMCC_DEBUG=2
emconfigure ./configure --prefix=$out --shared
runHook postConfigure
'';
dontStrip = true;
outputs = [ "out" ];
buildPhase = ''
emmake make
'';
installPhase = ''
emmake make install
'';
checkPhase = ''
echo "================= testing zlib using node ================="
sed -e "s/-o fastXmlLint.js/-s EXTRA_EXPORTED_RUNTIME_METHODS='[\"ccall\", \"cwrap\"]' -o fastXmlLint.js/g" -i Makefile.emEnv
'';
buildPhase = ''
HOME=$TMPDIR
make -f Makefile.emEnv
'';
outputs = [ "out" "doc" ];
installPhase = ''
mkdir -p $out/share
mkdir -p $doc/share/${name}
cp Demo* $out/share
cp -R codemirror-5.12 $out/share
cp fastXmlLint.js* $out/share
cp *.xsd $out/share
cp *.js $out/share
cp *.xhtml $out/share
cp *.html $out/share
cp *.json $out/share
cp *.rng $out/share
cp README.md $doc/share/${name}
'';
checkPhase = ''
'';
};
### Declarative debugging
Use `nix-shell -I nixpkgs=/some/dir/nixpkgs -A emscriptenPackages.libz` and from there you can go trough the individual steps. This makes it easy to build a good `unit test` or list the files of the project.
1.`nix-shell -I nixpkgs=/some/dir/nixpkgs -A emscriptenPackages.libz`
2.`cd /tmp/`
3.`unpackPhase`
4. cd libz-1.2.3
5.`configurePhase`
6.`buildPhase`
7. ... happy hacking...
## Summary
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.
Programs in the GNOME universe are written in various languages but they all use GObject-based libraries like GLib, GTK or GStreamer. These libraries are often modular, relying on looking into certain directories to find their modules. However, due to Nix’s specific file system organization, this will fail without our intervention. Fortunately, the libraries usually allow overriding the directories through environment variables, either natively or thanks to a patch in nixpkgs. <linkxlink:href="#fun-wrapProgram">Wrapping</link> the executables to ensure correct paths are available to the application constitutes a significant part of packaging a modern desktop application. In this section, we will describe various modules needed by such applications, environment variables needed to make the modules load, and finally a script that will do the work for us.
</para>
<sectionxml:id="ssec-gnome-settings">
<title>Settings</title>
<para>
<linkxlink:href="https://developer.gnome.org/gio/stable/GSettings.html">GSettings</link> API is often used for storing settings. GSettings schemas are required, to know the type and other metadata of the stored values. GLib looks for <filename>glib-2.0/schemas/gschemas.compiled</filename> files inside the directories of <envar>XDG_DATA_DIRS</envar>.
</para>
<para>
On Linux, GSettings API is implemented using <linkxlink:href="https://wiki.gnome.org/Projects/dconf">dconf</link> backend. You will need to add <literal>dconf</literal> GIO module to <envar>GIO_EXTRA_MODULES</envar> variable, otherwise the <literal>memory</literal> backend will be used and the saved settings will not be persistent.
</para>
<para>
Last you will need the dconf database D-Bus service itself. You can enable it using <option>programs.dconf.enable</option>.
</para>
<para>
Some applications will also require <package>gsettings-desktop-schemas</package> for things like reading proxy configuration or user interface customization. This dependency is often not mentioned by upstream, you should grep for <literal>org.gnome.desktop</literal> and <literal>org.gnome.system</literal> to see if the schemas are needed.
</para>
</section>
<sectionxml:id="ssec-gnome-icons">
<title>Icons</title>
<para>
When an application uses icons, an icon theme should be available in <envar>XDG_DATA_DIRS</envar>. The package for the default, icon-less <linkxlink:href="https://www.freedesktop.org/wiki/Software/icon-theme/">hicolor-icon-theme</link> contains <linklinkend="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>
</section>
<sectionxml:id="ssec-gnome-themes">
<title>GTK Themes</title>
<para>
Previously, a GTK theme needed to be in <envar>XDG_DATA_DIRS</envar>. This is no longer necessary for most programs since GTK incorporated Adwaita theme. Some programs (for example, those designed for <linkxlink:href="https://elementary.io/docs/human-interface-guidelines#human-interface-guidelines">elementary HIG</link>) might require a special theme like <package>pantheon.elementary-gtk-theme</package>.
</para>
</section>
<sectionxml:id="ssec-gnome-typelibs">
<title>GObject introspection typelibs</title>
<para>
<linkxlink:href="https://wiki.gnome.org/Projects/GObjectIntrospection">GObject introspection</link> allows applications to use C libraries in other languages easily. It does this through <literal>typelib</literal> files searched in <envar>GI_TYPELIB_PATH</envar>.
</para>
</section>
<sectionxml:id="ssec-gnome-plugins">
<title>Various plug-ins</title>
<para>
If your application uses <linkxlink:href="https://gstreamer.freedesktop.org/">GStreamer</link> or <linkxlink:href="https://wiki.gnome.org/Projects/Grilo">Grilo</link>, you should set <envar>GST_PLUGIN_SYSTEM_PATH_1_0</envar> and <envar>GRL_PLUGIN_PATH</envar>, respectively.
Fortunately, there is <package>wrapGAppsHook</package>, that does the wrapping for us. In particular, it works in conjunction with other setup hooks that will populate the variable:
<itemizedlist>
<listitemxml:id="ssec-gnome-hooks-wrapgappshook">
<para>
<package>wrapGAppsHook</package> itself will add the package’s <filename>share</filename> directory to <envar>XDG_DATA_DIRS</envar>.
</para>
</listitem>
<listitemxml:id="ssec-gnome-hooks-glib">
<para>
<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>
<listitemxml:id="ssec-gnome-hooks-dconf">
<para>
<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.
<package>hicolor-icon-theme</package>’s setup hook will add icon themes to <envar>XDG_ICON_DIRS</envar> which is prepended to <envar>XDG_DATA_DIRS</envar> by <package>wrapGAppsHook</package>.
<package>gobject-introspection</package> setup hook populates <envar>GI_TYPELIB_PATH</envar> variable with <filename>lib/girepository-1.0</filename> directories of dependencies, which is then added to wrapper by <package>wrapGAppsHook</package>. It also adds <filename>share</filename> directories of dependencies to <envar>XDG_DATA_DIRS</envar>, which is intended to promote GIR files but it also <linkxlink:href="https://github.com/NixOS/nixpkgs/issues/32790">pollutes the closures</link> of packages using <package>wrapGAppsHook</package>.
</para>
<warning>
<para>
The setup hook <linkxlink:href="https://github.com/NixOS/nixpkgs/issues/56943">currently</link> does not work in expressions with <literal>strictDeps</literal> enabled, like Python packages. In those cases, you will need to disable it with <code>strictDeps = false;</code>.
Setup hooks of <package>gst_all_1.gstreamer</package> and <package>gnome3.grilo</package> will populate the <envar>GST_PLUGIN_SYSTEM_PATH_1_0</envar> and <envar>GRL_PLUGIN_PATH</envar> variables, respectively, which will then be added to the wrapper by <literal>wrapGAppsHook</literal>.
</para>
</listitem>
</itemizedlist>
</para>
<para>
You can also pass additional arguments to <literal>makeWrapper</literal> using <literal>gappsWrapperArgs</literal> in <literal>preFixup</literal> hook:
Most GNOME package offer <linklinkend="var-passthru-updateScript"><literal>updateScript</literal></link>, it is therefore possible to update to latest source tarball by running <command>nix-shell maintainers/scripts/update.nix --argstr package gnome3.nautilus</command> or even en masse with <command>nix-shell maintainers/scripts/update.nix --argstr path gnome3</command>. Read the package’s <filename>NEWS</filename> file to see what changed.
<computeroutput>GLib-GIO-ERROR **: <replaceable>06:04:50.903</replaceable>: No GSettings schemas are installed on the system</computeroutput>
</term>
<listitem>
<para>
There are no schemas avalable in <envar>XDG_DATA_DIRS</envar>. Temporarily add a random package containing schemas like <package>gsettings-desktop-schemas</package> to <literal>buildInputs</literal>. <linklinkend="ssec-gnome-hooks-glib"><package>glib</package></link> and <linklinkend="ssec-gnome-hooks-wrapgappshook"><package>wrapGAppsHook</package></link> setup hooks will take care of making the schemas available to application and you will see the actual missing schemas with the <linklinkend="ssec-gnome-common-issues-missing-schema">next error</link>. Or you can try looking through the source code for the actual schemas used.
<computeroutput>GLib-GIO-ERROR **: <replaceable>06:04:50.903</replaceable>: Settings schema ‘<replaceable>org.gnome.foo</replaceable>’ is not installed</computeroutput>
</term>
<listitem>
<para>
Package is missing some GSettings schemas. You can find out the package containing the schema with <command>nix-locate <replaceable>org.gnome.foo</replaceable>.gschema.xml</command> and let the hooks handle the wrapping as <linklinkend="ssec-gnome-common-issues-no-schemas">above</link>.
When using <package>wrapGAppsHook</package> with special derivers you can end up with double wrapped binaries.
</term>
<listitem>
<para>
This is because derivers like <function>python.pkgs.buildPythonApplication</function> or <function>qt5.mkDerivation</function> have setup-hooks automatically added that produce wrappers with <package>makeWrapper</package>. The simplest way to workaround that is to disable the <package>wrapGAppsHook</package> automatic wrapping with <code>dontWrapGApps = true;</code> and pass the arguments it intended to pass to <package>makeWrapper</package> to another.
</para>
<para>
In the case of a Python application it could look like:
<programlisting>
python3.pkgs.buildPythonApplication {
pname = "gnome-music";
version = "3.32.2";
nativeBuildInputs = [
wrapGAppsHook
gobject-introspection
...
];
dontWrapGApps = true;
# Arguments to be passed to `makeWrapper`, only used by buildPython*
makeWrapperArgs = [
"\${gappsWrapperArgs[@]}"
];
}
</programlisting>
And for a QT app like:
<programlisting>
mkDerivation {
pname = "calibre";
version = "3.47.0";
nativeBuildInputs = [
wrapGAppsHook
qmake
...
];
dontWrapGApps = true;
# Arguments to be passed to `makeWrapper`, only used by qt5’s mkDerivation
I am packaging a project that cannot be wrapped, like a library or GNOME Shell extension.
</term>
<listitem>
<para>
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:
<linkxlink:href="https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/gnome-3/core/gnome-shell-extensions/default.nix#L21-L24">Replacing a <envar>GI_TYPELIB_PATH</envar> in GNOME Shell extension</link>– we are using <function>substituteAll</function> to include the path to a typelib into a patch.
The following examples are hardcoding GSettings schema paths. To get the schema paths we use the functions
<itemizedlist>
<listitem>
<para>
<function>glib.getSchemaPath</function> Takes a nix package attribute as an argument.
</para>
</listitem>
<listitem>
<para>
<function>glib.makeSchemaPath</function> Takes a package output like <literal>$out</literal> and a derivation name. You should use this if the schemas you need to hardcode are in the same derivation.
<linkxlink:href="https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/pantheon/apps/elementary-files/default.nix#L78-L86">Hard-coding GSettings schema path in Vala plug-in (dynamically loaded library)</link>– here, <function>substituteAll</function> cannot be used since the schema comes from the same package preventing us from pass its path to the function, probably due to a <linkxlink:href="https://github.com/NixOS/nix/issues/1846">Nix bug</link>.
<linkxlink:href="https://github.com/NixOS/nixpkgs/blob/29c120c065d03b000224872251bed93932d42412/pkgs/development/libraries/glib-networking/default.nix#L31-L34">Hard-coding GSettings schema path in C library</link>– nothing special other than using <linkxlink:href="https://github.com/NixOS/nixpkgs/pull/67957#issuecomment-527717467">Coccinelle patch</link> to generate the patch itself.
The function <varname>buildGoPackage</varname> builds standard Go programs.
</para>
<para>
The function <varname> buildGoModule </varname>builds Go programs managed with Go modules. It builds a <linkxlink:href="https://github.com/golang/go/wiki/Modules">Go modules</link> through a two phase build:
<itemizedlist>
<listitem>
<para>
An intermediate fetcher derivation. This derivation will be used to fetch all of the dependencies of the Go module.
</para>
</listitem>
<listitem>
<para>
A final derivation will use the output of the intermediate derivation to build the binaries and produce the final output.
description = "Simple command-line snippet manager, written in Go";
homepage = https://github.com/knqyf263/pet;
license = licenses.mit;
maintainers = with maintainers; [ kalbasit ];
platforms = platforms.linux ++ platforms.darwin;
};
}
</programlisting>
</example>
<para>
<xreflinkend='ex-buildGoModule'/> is an example expression using buildGoModule, the following arguments are of special significance to the function:
<calloutlist>
<calloutarearefs='ex-buildGoModule-1'>
<para>
<varname>modSha256</varname> is the hash of the output of the intermediate fetcher derivation.
</para>
</callout>
<calloutarearefs='ex-buildGoModule-2'>
<para>
<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>
</calloutlist>
</para>
</section>
<sectionxml:id="ssec-go-legacy">
<title>Go legacy</title>
<para>
The function <varname> buildGoPackage </varname> builds legacy Go programs, not supporting Go modules.
<xreflinkend='ex-buildGoPackage'/> is an example expression using buildGoPackage, the following arguments are of special significance to the function:
<calloutlist>
<calloutarearefs='ex-buildGoPackage-1'>
<para>
<varname>goPackagePath</varname> specifies the package's canonical Go import path.
</para>
</callout>
<calloutarearefs='ex-buildGoPackage-2'>
<para>
<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>
<para>
In this example only <literal>github.com/deis/deis/client</literal> will be built.
</para>
</callout>
<calloutarearefs='ex-buildGoPackage-3'>
<para>
<varname>goDeps</varname> is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate <varname>deps.nix</varname>file for readability. The dependency data structure is described below.
</para>
</callout>
<callout arearefs='ex-buildGoPackage-4'>
<para>
<varname>buildFlags</varname> is a list of flags passed to the go build command.
</para>
</callout>
</calloutlist>
</para>
<para>
<xreflinkend='ex-buildGoPackage'/> is an example expression using
buildGoPackage, the following arguments are of special significance to the
function:
<calloutlist>
<calloutarearefs='ex-buildGoPackage-1'>
<para>
<varname>goPackagePath</varname> specifies the package's canonical Go
import path.
</para>
</callout>
<calloutarearefs='ex-buildGoPackage-2'>
<para>
<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>
<para>
In this example only <literal>github.com/deis/deis/client</literal>will
be built.
</para>
</callout>
<calloutarearefs='ex-buildGoPackage-3'>
<para>
<varname>goDeps</varname> is where the Go dependencies of a Go program are
listed as a list of package source identified by Go import path. It could
be imported as a separate <varname>deps.nix</varname> file for
readability. The dependency data structure is described below.
</para>
</callout>
<calloutarearefs='ex-buildGoPackage-4'>
<para>
<varname>buildFlags</varname> is a list of flags passed to the go build
command.
</para>
</callout>
</calloutlist>
</para>
<para>
The <varname>goDeps</varname> attribute can be imported from a separate<varname>nix</varname> file that defines which Go libraries are needed and should be included in <varname>GOPATH</varname> for <varname>buildPhase</varname>.
</para>
<para>
The <varname>goDeps</varname> attribute can be imported from a separate
<varname>nix</varname> file that defines which Go libraries are needed and
should be included in <varname>GOPATH</varname> for
<varname>buildPhase</varname>.
</para>
<examplexml:id='ex-goDeps'>
<title>deps.nix</title>
<examplexml:id='ex-goDeps'>
<title>deps.nix</title>
<programlisting>
[ <coxml:id='ex-goDeps-1'/>
{
@@ -156,51 +101,60 @@ deis = buildGoPackage rec {
}
]
</programlisting>
</example>
</example>
<para>
<calloutlist>
<calloutarearefs='ex-goDeps-1'>
<para>
<varname>goDeps</varname> is a list of Go dependencies.
</para>
</callout>
<calloutarearefs='ex-goDeps-2'>
<para>
<varname>goPackagePath</varname> specifies Go package import path.
</para>
</callout>
<calloutarearefs='ex-goDeps-3'>
<para>
<varname>fetch type</varname> that needs to be used to get package source. If <varname>git</varname> is used there should be <varname>url</varname>, <varname>rev</varname> and <varname>sha256</varname> defined next to it.
</para>
</callout>
</calloutlist>
</para>
<para>
<calloutlist>
<calloutarearefs='ex-goDeps-1'>
<para>
<varname>goDeps</varname> is a list of Go dependencies.
</para>
</callout>
<calloutarearefs='ex-goDeps-2'>
<para>
<varname>goPackagePath</varname> specifies Go package import path.
</para>
</callout>
<calloutarearefs='ex-goDeps-3'>
<para>
<varname>fetch type</varname> that needs to be used to get package source.
If <varname>git</varname> is used there should be <varname>url</varname>,
<varname>rev</varname> and <varname>sha256</varname> defined next to it.
</para>
</callout>
</calloutlist>
</para>
<para>
To extract dependency information from a Go package in automated way use<linkxlink:href="https://github.com/kamilchm/go2nix">go2nix</link>. It can produce complete derivation and <varname>goDeps</varname> file for Go programs.
</para>
<para>
To extract dependency information from a Go package in automated way use
<linkxlink: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<xreflinkend='chap-multiple-output'xrefstyle="select: title"/> where <varname>bin</varname> includes program binaries. You can test build a Go binary as follows:
<para>
<varname>buildGoPackage</varname> produces
<xreflinkend='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:
$ 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>
$ 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:
<para>
You may use Go packages installed into the active Nix profiles by adding the
file within `nixpkgs` and are used as the initial package set for
`haskellPackages`. The `hackage-packages.nix` file is not meant to be edited
by hand, but rather autogenerated by [`hackage2nix`](https://github.com/NixOS/cabal2nix/tree/master/hackage2nix),
which by default uses the [`configuration-hackage2nix.yaml`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/configuration-hackage2nix.yaml)
file to generate all the derivations.
To modify the contents `configuration-hackage2nix.yaml`, follow the
instructions on [`hackage2nix`](https://github.com/NixOS/cabal2nix/tree/master/hackage2nix).
## Other resources
- The Youtube video [Nix Loves Haskell](https://www.youtube.com/watch?v=BsBhi_r-OeE)
This directory contains build rules for idris packages. In addition,
it contains several functions to build and compose those packages.
Everything is exposed to the user via the `idrisPackages` attribute.
The easiest way to get a working idris version is to install the `idris` attribute:
callPackage
------------
```
$ # On NixOS
$ nix-env -i nixos.idris
$ # On non-NixOS
$ nix-env -i nixpkgs.idris
```
This is like the normal nixpkgs callPackage function, specialized to
idris packages.
This however only provides the `prelude` and `base` libraries. To install idris with additional libraries, you can use the `idrisPackages.with-packages` function, e.g. in an overlay in `~/.config/nixpkgs/overlays/my-idris.nix`:
in another file (say `default.nix`) to be able to build it with
```
$ nix-build -A yaml
```
## Passing options to `idris` commands
The `build-idris-package` function provides also optional input values to set additional options for the used `idris` commands.
Specifically, you can set `idrisBuildOptions`, `idrisTestOptions`, `idrisInstallOptions` and `idrisDocOptions` to provide additional options to the `idris` command respectively when building, testing, installing and generating docs for your package.
For example you could set
```
build-idris-package {
idrisBuildOptions = [ "--log" "1" "--verbose" ]
...
}
```
to require verbose output during `idris` build phase.
Bundle idris together with a list of packages. Because idris currently
only supports a single directory in its library path, you must include
all desired libraries here, including `prelude` and `base`.
<title>Support for specific programming languages and frameworks</title>
<para>
The <linklinkend="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.
The <linklinkend="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.
Note that <varname>jdk</varname> is an alias for the OpenJDK (self-built where available, or pre-built via Zulu). Platforms with OpenJDK not (yet) in Nixpkgs (<literal>Aarch32</literal>, <literal>Aarch64</literal>) point to the (unfree) <literal>oraclejdk</literal>.
Note that <varname>jdk</varname> is an alias for the OpenJDK.
</para>
<para>
JAR files that are intended to be used by other packages should be installed in <filename>$out/share/java</filename>. JDKs have a stdenv setup hook that add any JARs in the <filename>share/java</filename> directories of the build inputs to the <envar>CLASSPATH</envar> environment variable. For instance, if the package <literal>libfoo</literal> installs a JAR named <filename>foo.jar</filename> in its <filename>share/java</filename> directory, and another package declares the attribute
JAR files that are intended to be used by other packages should be installed
in <filename>$out/share/java</filename>. The OpenJDK has a stdenv setup hook
that adds any JARs in the <filename>share/java</filename> directories of the
build inputs to the <envar>CLASSPATH</envar> environment variable. For
instance, if the package <literal>libfoo</literal> installs a JAR named
<filename>foo.jar</filename> in its <filename>share/java</filename>
directory, and another package declares the attribute
<programlisting>
buildInputs = [ libfoo ];
nativeBuildInputs = [ jdk ];
buildInputs = [ jdk libfoo ];
</programlisting>
then <envar>CLASSPATH</envar> will be set to<filename>/nix/store/...-libfoo/share/java/foo.jar</filename>.
If your Java package provides a program, you need to generate a wrapper script to run it using the OpenJRE. You can use <literal>makeWrapper</literal> for this:
If your Java package provides a program, you need to generate a wrapper
Note the use of <literal>jre</literal>, which is the part of the OpenJDK package that contains the Java Runtime Environment. By using <literal>${jre}/bin/java</literal> instead of <literal>${jdk}/bin/java</literal>, you prevent your package from depending on the JDK at runtime.
Note the use of <literal>jre</literal>, which is the part of the OpenJDK
package that contains the Java Runtime Environment. By using
<literal>${jre}/bin/java</literal> instead of
<literal>${jdk}/bin/java</literal>, you prevent your package from depending
on the JDK at runtime.
</para>
<para>
Note all JDKs passthru <literal>home</literal>, so if your application requires environment variables like <envar>JAVA_HOME</envar> being set, that can be done in a generic fashion with the <literal>--set</literal> argument of <literal>makeWrapper</literal>:
It is possible to use a different Java compiler than <command>javac</command>
from the OpenJDK. For instance, to use the Eclipse Java Compiler:
<programlisting>
--set JAVA_HOME ${jdk.home}
buildInputs = [ jre ant ecj ];
</programlisting>
</para>
<para>
It is possible to use a different Java compiler than <command>javac</command> from the OpenJDK. For instance, to use the GNU Java Compiler:
(Note that here you don’t need the full JDK as an input, but just the JRE.)
The ECJ has a stdenv setup hook that sets some environment variables to cause
Ant to use ECJ, but this doesn’t work with all Ant files. Similarly, you
can use the GNU Java Compiler:
<programlisting>
nativeBuildInputs = [ gcj ant ];
buildInputs = [ gcj ant ];
</programlisting>
Here, Ant will automatically use <command>gij</command> (the GNU Java Runtime) instead of the OpenJRE.
Here, Ant will automatically use <command>gij</command> (the GNU Java
Lua packages are built by the <varname>buildLuaPackage</varname> function. This function is implemented in <linkxlink: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 <xreflinkend="sec-language-perl"/> for details.)
Lua packages are built by the <varname>buildLuaPackage</varname> function.
and works similarly to <varname>buildPerlPackage</varname>. (See
<xreflinkend="sec-language-perl"/> for details.)
</para>
<para>
Lua packages are defined in<linkxlink: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:
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.
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.
OCaml libraries should be installed in <literal>$(out)/lib/ocaml/${ocaml.version}/site-lib/</literal>. Such directories are automatically added to the <literal>$OCAMLPATH</literal> environment variable when building another package that depends on them or when opening a <literal>nix-shell</literal>.
</para>
<para>
Given that most of the OCaml ecosystem is now built with dune, nixpkgs includes a convenience build support function called <literal>buildDunePackage</literal> that will build an OCaml package using dune, OCaml and findlib and any additional dependencies provided as <literal>buildInputs</literal> or <literal>propagatedBuildInputs</literal>.
</para>
<para>
Here is a simple package example. It defines an (optional) attribute <literal>minimumOCamlVersion</literal> that will be used to throw a descriptive evaluation error if building with an older OCaml is attempted. It uses the <literal>fetchFromGitHub</literal> fetcher to get its source. It sets the <literal>doCheck</literal> (optional) attribute to <literal>true</literal> which means that tests will be run with <literal>dune runtest -p angstrom</literal> after the build (<literal>dune build -p angstrom</literal>) is complete. It uses <literal>alcotest</literal> as a build input (because it is needed to run the tests) and <literal>bigstringaf</literal> and <literal>result</literal> as propagated build inputs (thus they will also be available to libraries depending on this library). The library will be installed using the <literal>angstrom.install</literal> file that dune generates.
description = "OCaml parser combinators built for speed and memory efficiency";
license = stdenv.lib.licenses.bsd3;
maintainers = with stdenv.lib.maintainers; [ sternenseemann ];
};
}
</programlisting>
<para>
Here is a second example, this time using a source archive generated with <literal>dune-release</literal>. It is a good idea to use this archive when it is available as it will usually contain substituted variables such as a <literal>%%VERSION%%</literal> field. This library does not depend on any other OCaml library and no tests are run after building it.
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
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
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:
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
$ 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
$ 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>.)
(Of course you can also install using the attribute name: <literal>nix-env -i
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>
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.)
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.
</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.
In the fixup phase, it writes the propagated build inputs
(<varname>propagatedBuildInputs</varname>) to the file
<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>:
<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 }:
@@ -73,15 +109,20 @@ buildPerlPackage rec {
};
preConfigure = ''
echo "LIB = ${db.out}/lib" > config.in
echo "INCLUDE = ${db.dev}/include" >> config.in
echo "LIB = ${db}/lib" > config.in
echo "INCLUDE = ${db}/include" >> config.in
'';
}
</programlisting>
</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:
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:
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:
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>
<sectionxml: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:
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
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:
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
The output can be pasted into<filename>pkgs/top-level/perl-packages.nix</filename> or wherever else you need it.
</para>
</section>
<sectionxml: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.
The output can be pasted into
<filename>pkgs/top-level/perl-packages.nix</filename> or wherever else you
@@ -474,18 +478,18 @@ don't explicitly define which `python` derivation should be used. In the above
example we use `buildPythonPackage` that is part of the set `python35Packages`,
and in this case the `python35` interpreter is automatically used.
## Reference
### Interpreters
Versions 2.7, 3.5, 3.6 and 3.7 of the CPython interpreter are available as
respectively `python27`, `python35`, `python36` and `python37`. The aliases
`python2` and `python3` correspond to respectively `python27` and
`python37`. The default interpreter, `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 expressions for the interpreters can be
found in `pkgs/development/interpreters/python`.
Versions 2.7, 3.3, 3.4, 3.5 and 3.6 of the CPython interpreter are available as
respectively `python27`, `python34`, `python35` and `python36`. The PyPy interpreter
is available as `pypy`. The aliases `python2` and `python3` correspond to respectively `python27` and
`python35`. The default interpreter, `python`, maps to `python2`.
The Nix expressions for the interpreters can be found in
`pkgs/development/interpreters/python`.
All packages depending on any Python interpreter get appended
`out/{python.sitePackages}` to `$PYTHONPATH` if such directory
@@ -504,13 +508,13 @@ Each interpreter has the following attributes:
-`buildEnv`. Function to build python interpreter environments with extra packages bundled together. See section *python.buildEnv function* for usage and documentation.
-`withPackages`. Simpler interface to `buildEnv`. See section *python.withPackages function* for usage and documentation.
-`sitePackages`. Alias for `lib/${libPrefix}/site-packages`.
-`executable`. Name of the interpreter executable, e.g. `python3.7`.
-`executable`. Name of the interpreter executable, e.g. `python3.4`.
-`pkgs`. Set of Python packages for that specific interpreter. The package set can be modified by overriding the interpreter and passing `packageOverrides`.
### Building packages and applications
Python libraries and applications that use `setuptools` or
`distutils` are typically built with respectively the `buildPythonPackage` and
`distutils` are typically build with respectively the `buildPythonPackage` and
`buildPythonApplication` functions. These two functions also support installing a `wheel`.
All Python packages reside in `pkgs/top-level/python-packages.nix` and all
@@ -526,50 +530,49 @@ attribute set is created for each available Python interpreter. The available
sets are
*`pkgs.python27Packages`
*`pkgs.python34Packages`
*`pkgs.python35Packages`
*`pkgs.python36Packages`
*`pkgs.python37Packages`
*`pkgs.pypyPackages`
and the aliases
*`pkgs.python2Packages` pointing to `pkgs.python27Packages`
*`pkgs.python3Packages` pointing to `pkgs.python37Packages`
*`pkgs.python3Packages` pointing to `pkgs.python36Packages`
*`pkgs.pythonPackages` pointing to `pkgs.python2Packages`
#### `buildPythonPackage` function
The `buildPythonPackage` function is implemented in
@@ -582,38 +585,32 @@ The `buildPythonPackage` mainly does four things:
environment variable and add dependent libraries to script's `sys.path`.
* In the `installCheck` phase, `${python.interpreter} setup.py test` is ran.
As in Perl, dependencies on other Python packages can be specified in the
`buildInputs` and `propagatedBuildInputs` attributes. If something is
exclusively a build-time dependency, use `buildInputs`; if it’s (also) a runtime
dependency, use `propagatedBuildInputs`.
By default tests are run because `doCheck = true`. Test dependencies, like
e.g. the test runner, should be added to `checkInputs`.
e.g. the test runner, should be added to `buildInputs`.
By default `meta.platforms` is set to the same value
as the interpreter unless overridden otherwise.
##### `buildPythonPackage` parameters
All parameters from `stdenv.mkDerivation` function are still supported. The following are specific to `buildPythonPackage`:
All parameters from `mkDerivation` function are still supported.
* `catchConflicts ? true`: If `true`, abort package build if a package name appears more than once in dependency tree. Default is `true`.
* `disabled` ? false: If `true`, package is not build for the particular Python interpreter version.
* `dontWrapPythonPrograms ? false`: Skip wrapping of python programs.
* `permitUserSite ? false`: Skip setting the `PYTHONNOUSERSITE` environment variable in wrapped programs.
* `installFlags ? []`: A list of strings. Arguments to be passed to `pip install`. To pass options to `python setup.py install`, use `--install-option`. E.g., `installFlags=["--install-option='--cpp_implementation'"]`.
* `format ? "setuptools"`: Format of the source. Valid options are `"setuptools"`, `"pyproject"`, `"flit"`, `"wheel"`, and `"other"`. `"setuptools"` is for when the source has a `setup.py` and `setuptools` is used to build a wheel, `flit`, in case `flit` should be used to build a wheel, and `wheel` in case a wheel is provided. Use `other` when a custom `buildPhase` and/or `installPhase` is needed.
* `makeWrapperArgs ? []`: A list of strings. Arguments to be passed to `makeWrapper`, which wraps generated binaries. By default, the arguments to `makeWrapper` set `PATH` and `PYTHONPATH` environment variables before calling the binary. Additional arguments here can allow a developer to set environment variables which will be available when the binary is run. For example, `makeWrapperArgs = ["--set FOO BAR" "--set BAZ QUX"]`.
* `namePrefix`: Prepends text to `${name}` parameter. In case of libraries, this defaults to `"python3.5-"` for Python 3.5, etc., and in case of applications to `""`.
* `pythonPath ? []`: List of packages to be added into `$PYTHONPATH`. Packages in `pythonPath` are not propagated (contrary to `propagatedBuildInputs`).
* `namePrefix`: Prepended text to `${name}` parameter. Defaults to `"python3.3-"` for Python 3.3, etc. Set it to `""` if you're packaging an application or a command line tool.
* `disabled`: If `true`, package is not build for particular python interpreter version. Grep around `pkgs/top-level/python-packages.nix` for examples.
* `setupPyBuildFlags`: List of flags passed to `setup.py build_ext` command.
* `pythonPath`: List of packages to be added into `$PYTHONPATH`. Packages in `pythonPath` are not propagated (contrary to `propagatedBuildInputs`).
* `preShellHook`: Hook to execute commands before `shellHook`.
* `postShellHook`: Hook to execute commands after `shellHook`.
* `removeBinByteCode ? true`: Remove bytecode from `/bin`. Bytecode is only created when the filenames end with `.py`.
* `setupPyGlobalFlags ? []`: List of flags passed to `setup.py` command.
* `setupPyBuildFlags ? []`: List of flags passed to `setup.py build_ext` command.
The `stdenv.mkDerivation` function accepts various parameters for describing build inputs (see "Specifying dependencies"). The following are of special
interest for Python packages, either because these are primarily used, or because their behaviour is different:
* `nativeBuildInputs ? []`: Build-time only dependencies. Typically executables as well as the items listed in `setup_requires`.
* `buildInputs ? []`: Build and/or run-time dependencies that need to be be compiled for the host machine. Typically non-Python libraries which are being linked.
* `checkInputs ? []`: Dependencies needed for running the `checkPhase`. These are added to `nativeBuildInputs` when `doCheck = true`. Items listed in `tests_require` go here.
* `propagatedBuildInputs ? []`: Aside from propagating dependencies, `buildPythonPackage` also injects code into and wraps executables with the paths included in this list. Items listed in `install_requires` go here.
* `makeWrapperArgs`: A list of strings. Arguments to be passed to `makeWrapper`, which wraps generated binaries. By default, the arguments to `makeWrapper` set `PATH` and `PYTHONPATH` environment variables before calling the binary. Additional arguments here can allow a developer to set environment variables which will be available when the binary is run. For example, `makeWrapperArgs = ["--set FOO BAR" "--set BAZ QUX"]`.
* `installFlags`: A list of strings. Arguments to be passed to `pip install`. To pass options to `python setup.py install`, use `--install-option`. E.g., `installFlags=["--install-option='--cpp_implementation'"].
*`format`: Format of the source. Valid options are `setuptools` (default), `flit`, `wheel`, and `other`. `setuptools` is for when the source has a `setup.py` and `setuptools` is used to build a wheel, `flit`, in case `flit` should be used to build a wheel, and `wheel` in case a wheel is provided. In case you need to provide your own `buildPhase` and `installPhase` you can use `other`.
*`catchConflicts` If `true`, abort package build if a package name appears more than once in dependency tree. Default is `true`.
*`checkInputs` Dependencies needed for running the `checkPhase`. These are added to `buildInputs` when `doCheck = true`.
propagatedBuildInputs = with python3Packages; [ tornado_4 python-daemon ];
meta = with lib; {
...
};
}
```
This is then added to `all-packages.nix` just as any other application would be.
```nix
luigi = callPackage ../applications/networking/cluster/luigi { };
```
Since the package is an application, a consumer doesn't need to care about
python versions or modules, which is why they don't go in `pythonPackages`.
#### `toPythonApplication` function
A distinction is made between applications and libraries, however, sometimes a
package is used as both. In this case the package is added as a library to
`python-packages.nix` and as an application to `all-packages.nix`. To reduce
duplication the `toPythonApplication` can be used to convert a library to an
application.
The Nix expression shall use `buildPythonPackage` and be called from
`python-packages.nix`. A reference shall be created from `all-packages.nix` to
the attribute in `python-packages.nix`, and the `toPythonApplication` shall be
applied to the reference:
```nix
youtube-dl = with pythonPackages; toPythonApplication youtube-dl;
```
#### `toPythonModule` function
In some cases, such as bindings, a package is created using
`stdenv.mkDerivation` and added as attribute in `all-packages.nix`.
The Python bindings should be made available from `python-packages.nix`.
The `toPythonModule` function takes a derivation and makes certain Python-specific modifications.
```nix
opencv = toPythonModule (pkgs.opencv.override {
enablePython = true;
pythonPackages = self;
});
```
Do pay attention to passing in the right Python version!
#### `python.buildEnv` function
#### python.buildEnv function
Python environments can be created using the low-level `pkgs.buildEnv` function.
This example shows how to create an environment that has the Pyramid Web Framework.
@@ -727,7 +655,7 @@ Saving the following as `default.nix`
withimport<nixpkgs>{};
python.buildEnv.override{
extraLibs = [ pythonPackages.pyramid ];
extraLibs =[pkgs.pythonPackages.pyramid];
ignoreCollisions=true;
}
```
@@ -759,9 +687,8 @@ specified packages in its path.
*`extraLibs`: List of packages installed inside the environment.
*`postBuild`: Shell command executed after the build of environment.
*`ignoreCollisions`: Ignore file collisions inside the environment (default is `false`).
* `permitUserSite`: Skip setting the `PYTHONNOUSERSITE` environment variable in wrapped binaries in the environment.
#### `python.withPackages` function
#### python.withPackages function
The `python.withPackages` function provides a simpler interface to the `python.buildEnv` functionality.
It takes a function as an argument that is passed the set of python packages and returns the list
@@ -795,25 +722,9 @@ with import <nixpkgs> {};
In contrast to `python.buildEnv`, `python.withPackages` does not support the more advanced options
such as `ignoreCollisions = true` or `postBuild`. If you need them, you have to use `python.buildEnv`.
Python 2 namespace packages may provide `__init__.py` that collide. In that case `python.buildEnv`
Python 2 namespace packages may provide `__init__.py` that collide. In that case `python.buildEnv`
should be used with `ignoreCollisions = true`.
#### Setup hooks
The following are setup hooks specifically for Python packages. Most of these are
used in `buildPythonPackage`.
- `flitBuildHook` to build a wheel using `flit`.
- `pipBuildHook` to build a wheel using `pip` and PEP 517. Note a build system (e.g. `setuptools` or `flit`) should still be added as `nativeBuildInput`.
- `pipInstallHook` to install wheels.
- `pytestCheckHook` to run tests with `pytest`.
- `pythonCatchConflictsHook` to check whether a Python package is not already existing.
- `pythonImportsCheckHook` to check whether importing the listed modules works.
- `pythonRemoveBinBytecode` to remove bytecode from the `/bin` folder.
- `setuptoolsBuildHook` to build a wheel using `setuptools`.
- `setuptoolsCheckHook` to run tests with `python setup.py test`.
- `wheelUnpackHook` to move a wheel to the correct folder so it can be installed with the `pipInstallHook`.
### Development mode
Development or editable mode is supported. To develop Python packages
@@ -826,12 +737,11 @@ Given a `default.nix`:
```nix
withimport<nixpkgs>{};
pythonPackages.buildPythonPackage {
name = "myproject";
buildInputs = with pythonPackages; [ pyramid ];
buildPythonPackage{name="myproject";
src = ./.;
}
buildInputs=withpkgs.pythonPackages;[pyramid];
src=./.;}
```
Running `nix-shell` with no arguments should give you
@@ -856,7 +766,7 @@ community to help save time. No tool is preferred at the moment.
### Deterministic builds
The Python interpreters are now built deterministically.
Python 2.7, 3.5 and 3.6 are now built deterministically and 3.4 mostly.
Minor modifications had to be made to the interpreters in order to generate
deterministic bytecode. This has security implications and is relevant for
those using Python in a `nix-shell`.
@@ -880,8 +790,8 @@ example of such a situation is when `py.test` is used.
- Non-working tests can often be deselected. By default `buildPythonPackage` runs `python setup.py test`.
Most python modules follows the standard test protocol where the pytest runner can be used instead.
`py.test` supports a `-k` parameter to ignore test methods or classes:
`py.test` supports a `-k` parameter to ignore test methods or classes:
```nix
buildPythonPackage {
# ...
@@ -892,6 +802,7 @@ example of such a situation is when `py.test` is used.
'';
}
```
- Unicode issues can typically be fixed by including `glibcLocales` in `buildInputs` and exporting `LC_ALL=en_US.utf-8`.
- Tests that attempt to access `$HOME` can be fixed by using the following work-around before running tests (e.g. `preCheck`): `export HOME=$(mktemp -d)`
## FAQ
@@ -1017,13 +928,10 @@ Create this `default.nix` file, together with a `requirements.txt` and simply ex
```nix
with import <nixpkgs> {};
with python27Packages;
with pkgs.python27Packages;
stdenv.mkDerivation {
name = "impurePythonEnv";
src = null;
buildInputs = [
# these packages are required for virtualenv and pip to work:
#
@@ -1033,7 +941,7 @@ stdenv.mkDerivation {
# the following packages are related to the dependencies of your python
# project.
# In this particular example the python modules listed in the
# requirements.txt require the following packages to be installed locally
# requirements.tx require the following packages to be installed locally
# in order to compile any binary extensions they may require.
#
taglib
@@ -1043,15 +951,14 @@ stdenv.mkDerivation {
libxslt
libzip
stdenv
zlib
];
zlib ];
src = null;
shellHook = ''
# set SOURCE_DATE_EPOCH so that we can use python wheels
SOURCE_DATE_EPOCH=$(date +%s)
virtualenv --no-setuptools venv
export PATH=$PWD/venv/bin:$PATH
pip install -r requirements.txt
# set SOURCE_DATE_EPOCH so that we can use python wheels
SOURCE_DATE_EPOCH=$(date +%s)
virtualenv --no-setuptools venv
export PATH=$PWD/venv/bin:$PATH
pip install -r requirements.txt
'';
}
```
@@ -1066,14 +973,14 @@ folder and not downloaded again.
If you need to change a package's attribute(s) from `configuration.nix` you could do:
@@ -1081,77 +988,30 @@ If you need to change a package's attribute(s) from `configuration.nix` you coul
};
```
`pythonPackages.zerobin` is now globally overridden. All packages and also the
`zerobin` NixOS service use the new definition.
Note that `python-super` refers to the old package set and `python-self`
to the new, overridden version.
To modify only a Python package set instead of a whole Python derivation, use this snippet:
```nix
myPythonPackages = pythonPackages.override {
overrides = self: super: {
zerobin = ...;
};
}
```
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?
Use the following overlay template:
To alter a python package using overlays, you would use the following approach:
A `site.cfg` is created that configures BLAS based on the `blas` parameter
of the `numpy` derivation. By passing in `mkl`, `numpy` and packages depending
on `numpy` will be built with `mkl`.
The following is an overlay that configures `numpy` to use `mkl`:
```nix
self: super: {
python37 = super.python37.override {
packageOverrides = python-self: python-super: {
numpy = python-super.numpy.override {
blas = super.pkgs.mkl;
};
};
};
}
```
`mkl` requires an `openmp` implementation when running with multiple processors.
By default, `mkl` will use Intel's `iomp` implementation if no other is
specified, but this is a runtime-only dependency and binary compatible with the
LLVM implementation. To use that one instead, Intel recommends users set it with
`LD_PRELOAD`.
Note that `mkl` is only available on `x86_64-{linux,darwin}` platforms;
moreover, Hydra is not building and distributing pre-compiled binaries using it.
### What inputs do `setup_requires`, `install_requires` and `tests_require` map to?
In a `setup.py` or `setup.cfg` it is common to declare dependencies:
* `setup_requires` corresponds to `nativeBuildInputs`
* `install_requires` corresponds to `propagatedBuildInputs`
* `tests_require` corresponds to `checkInputs`
## Contributing
### Contributing guidelines
@@ -1163,5 +1023,4 @@ Following rules are desired to be respected:
* Make sure libraries build for all Python interpreters.
* By default we enable tests. Make sure the tests are found and, in the case of libraries, are passing for all interpreters. If certain tests fail they can be disabled individually. Try to avoid disabling the tests altogether. In any case, when you disable tests, leave a comment explaining why.
* Commit names of Python libraries should reflect that they are Python libraries, so write for example `pythonPackages.numpy: 1.11 -> 1.12`.
* Attribute names in `python-packages.nix` should be normalized according to [PEP 0503](https://www.python.org/dev/peps/pep-0503/#normalized-names).
This means that characters should be converted to lowercase and `.` and `_` should be replaced by a single `-` (foo-bar-baz instead of Foo__Bar.baz )
This section describes the differences between Nix expressions for Qt libraries and applications and Nix expressions for other C++ software. Some knowledge of the latter is assumed. There are primarily two problems which the Qt infrastructure is designed to address: ensuring consistent versioning of all dependencies and finding dependencies at runtime.
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>
<examplexml:id='qt-default-nix'>
<title>Nix expression for a Qt package (<filename>default.nix</filename>)</title>
Import <literal>mkDerivation</literal> and Qt (such as <literal>qtbase</literal> modules directly. <emphasis>Do not</emphasis> import Qt package sets; the Qt versions of dependencies may not be coherent, causing build and runtime failures.
</para>
</callout>
<calloutarearefs='qt-default-nix-co-2'>
<para>
Use <literal>mkDerivation</literal> instead of <literal>stdenv.mkDerivation</literal>. <literal>mkDerivation</literal> is a wrapper around <literal>stdenv.mkDerivation</literal> which applies some Qt-specific settings. This deriver accepts the same arguments as <literal>stdenv.mkDerivation</literal>; refer to <xreflinkend='chap-stdenv'/> for details.
</para>
<para>
To use another deriver instead of <literal>stdenv.mkDerivation</literal>, use <literal>mkDerivationWith</literal>:
<programlisting>
mkDerivationWith myDeriver {
# ...
}
</programlisting>
If you cannot use <literal>mkDerivationWith</literal>, please refer to <xreflinkend='qt-runtime-dependencies'/>.
</para>
</callout>
<calloutarearefs='qt-default-nix-co-3'>
<para>
<literal>mkDerivation</literal> accepts the same arguments as <literal>stdenv.mkDerivation</literal>, such as <literal>buildInputs</literal>.
</para>
</callout>
</calloutlist>
<formalparaxml:id='qt-runtime-dependencies'>
<title>Locating runtime dependencies</title>
<para>
Qt applications need to be wrapped to find runtime dependencies. If you cannot use <literal>mkDerivation</literal> or <literal>mkDerivationWith</literal> above, include <literal>wrapQtAppsHook</literal> in <literal>nativeBuildInputs</literal>:
<programlisting>
stdenv.mkDerivation {
# ...
nativeBuildInputs = [ wrapQtAppsHook ];
}
</programlisting>
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>
</formalpara>
<para>
Entries added to <literal>qtWrapperArgs</literal> are used to modify the wrappers created by <literal>wrapQtAppsHook</literal>. The entries are passed as arguments to <xreflinkend='fun-wrapProgram'/>.
Set <literal>dontWrapQtApps</literal> to stop applications from being wrapped automatically. It is required to wrap applications manually with <literal>wrapQtApp</literal>, using the syntax of <xreflinkend='fun-wrapProgram'/>:
<literal>wrapQtAppsHook</literal> ignores files that are non-ELF executables. This means that scripts won't be automatically wrapped so you'll need to manually wrap them as previously mentioned. An example of when you'd always need to do this is with Python applications that use PyQT.
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>
</note>
</section>
<para>
Libraries are built with every available version of Qt. Use the <literal>meta.broken</literal> attribute to disable the package for unsupported Qt versions:
Add a Qt library to <filename>all-packages.nix</filename> by adding it to the collection inside <literal>mkLibsForQt5</literal>. This ensures that the library is built with every available version of Qt as needed.
<examplexml:id='qt-library-all-packages-nix'>
<title>Adding a Qt library to <filename>all-packages.nix</filename></title>
<programlisting>
{
# ...
mkLibsForQt5 = self: with self; {
# ...
mylib = callPackage ../path/to/mylib {};
};
# ...
}
</programlisting>
</example>
Call your application expression using
<literal>libsForQt5.callPackage</literal> instead of
<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>
</formalpara>
<formalpara>
<title>Adding an application to Nixpkgs</title>
<para>
Add a Qt application to <filename>all-packages.nix</filename> using <literal>libsForQt5.callPackage</literal> instead of the usual <literal>callPackage</literal>. The former ensures that all dependencies are built with the same version of Qt.
<examplexml:id='qt-application-all-packages-nix'>
<title>Adding a Qt application to <filename>all-packages.nix</filename></title>
There currently is support to bundle applications that are packaged as Ruby gems. The utility "bundix" allows you to write a <filename>Gemfile</filename>, let bundler create a <filename>Gemfile.lock</filename>, and then convert this into a nix expression that contains all Gem dependencies automatically.
There currently is support to bundle applications that are packaged as Ruby
gems. The utility "bundix" allows you to write a
<filename>Gemfile</filename>, let bundler create a
<filename>Gemfile.lock</filename>, and then convert this into a nix
expression that contains all Gem dependencies automatically.
</para>
<para>
@@ -41,22 +45,16 @@ bundlerEnv rec {
</screen>
<para>
Please check in the <filename>Gemfile</filename>,<filename>Gemfile.lock</filename> and the <filename>gemset.nix</filename> so future updates can be run easily.
Please check in the <filename>Gemfile</filename>,
<filename>Gemfile.lock</filename> and the <filename>gemset.nix</filename> so
future updates can be run easily.
</para>
<para>
Updating Ruby packages can then be done like this:
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:
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>
<screen>
@@ -78,11 +76,29 @@ bundlerApp {
</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.
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.
</para>
<para>
Resulting derivations for both builders also have two helpful attributes,<literal>env</literal> and <literal>wrappedRuby</literal>. The first one allows one to quickly drop into <command>nix-shell</command> with the specified environment present. E.g. <command>nix-shell -A sensu.env</command> would give you an environment with Ruby preset so it has all the libraries necessary for <literal>sensu</literal> in its paths. The second one can be used to make derivations from custom Ruby scripts which have <filename>Gemfile</filename>s with their dependencies specified. It is a derivation with <command>ruby</command> wrapped so it can find all the needed dependencies. For example, to make a derivation <literal>my-script</literal> for a <filename>my-script.rb</filename> (which should be placed in <filename>bin</filename>) you should run <command>bundix</command> as specified above and then use <literal>bundlerEnv</literal> like this:
Resulting derivations for both builders also have two helpful attributes,
<literal>env</literal> and <literal>wrappedRuby</literal>. The first one
allows one to quickly drop into <command>nix-shell</command> with the
specified environment present. E.g. <command>nix-shell -A sensu.env</command>
would give you an environment with Ruby preset so it has all the libraries
necessary for <literal>sensu</literal> in its paths. The second one can be
used to make derivations from custom Ruby scripts which have
<filename>Gemfile</filename>s with their dependencies specified. It is a
derivation with <command>ruby</command> wrapped so it can find all the needed
dependencies. For example, to make a derivation <literal>my-script</literal>
for a <filename>my-script.rb</filename> (which should be placed in
<filename>bin</filename>) you should run <command>bundix</command> as
specified above and then use <literal>bundlerEnv</literal> like this:
There are all the schemes, collections and a few thousand packages, as defined upstream (perhaps with tiny differences).
</programlisting>
There are all the schemes, collections and a few thousand packages, as
defined upstream (perhaps with tiny differences).
</para>
</listitem>
<listitem>
<para>
By default you only get executables and files needed during runtime, and a little documentation for the core packages. To change that, you need to add <varname>pkgFilter</varname> function to <varname>combine</varname>.
By default you only get executables and files needed during runtime, and a
little documentation for the core packages. To change that, you need to
add <varname>pkgFilter</varname> function to <varname>combine</varname>.
<programlisting>
texlive.combine {
# inherit (texlive) whatever-you-want;
@@ -38,28 +44,23 @@ texlive.combine {
# elem tlType [ "run" "bin" "doc" "source" ]
# there are also other attributes: version, name
}
</programlisting>
</programlisting>
</para>
</listitem>
<listitem>
<para>
You can list packages e.g. by <command>nixrepl</command>.
<programlisting><![CDATA[
$ nixrepl
nix-repl> :l <nixpkgs>
nix-repl> texlive.collection-<TAB>
]]></programlisting>
</para>
</listitem>
<listitem>
<para>
Note that the wrapper assumes that the result has a chance to be useful. For example, the core executables should be present, as well as some core data files. The supported way of ensuring this is by including some scheme, for example <varname>scheme-basic</varname>, into the combination.
You can list packages e.g. by <command>nix-repl</command>.
Nix expressions for Vim plugins are stored in [pkgs/misc/vim-plugins](/pkgs/misc/vim-plugins). For the vast majority of plugins, Nix expressions are automatically generated by running [`./update.py`](/pkgs/misc/vim-plugins/update.py). This creates a [generated.nix](/pkgs/misc/vim-plugins/generated.nix) file based on the plugins listed in [vim-plugin-names](/pkgs/misc/vim-plugins/vim-plugin-names). Plugins are listed in alphabetical order in `vim-plugin-names` using the format `[github username]/[repository]`. For example https://github.com/scrooloose/nerdtree becomes `scrooloose/nerdtree`.
Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](/pkgs/misc/vim-plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:
dependencies = with super; [ deoplete-nvim vim-fish ];
});
```
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:
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
- [vim-pi](https://bitbucket.org/vimcommunity/vim-pi) is a plugin repository
from VAM plugin manager meant to be used by others as well used by
- [vim2nix](https://github.com/MarcWeber/vim-addon-vim2nix) which generates the
- [vim2nix](http://github.com/MarcWeber/vim-addon-vim2nix) which generates the
Nix packages can declare <emphasis>meta-attributes</emphasis> that contain information about a package such as a description, its homepage, its license, and so on. For instance, the GNU Hello package has a <varname>meta</varname> declaration like this:
Nix packages can declare <emphasis>meta-attributes</emphasis> that contain
information about a package such as a description, its homepage, its license,
and so on. For instance, the GNU Hello package has a <varname>meta</varname>
declaration like this:
<programlisting>
meta = with stdenv.lib; {
meta = {
description = "A program that produces a familiar, friendly greeting";
longDescription = ''
GNU Hello is a program that prints "Hello, world!" when you run it.
Meta-attributes are not passed to the builder of the package. Thus, a change to a meta-attribute doesn’t trigger a recompilation of the package. The value of a meta-attribute must be a string.
Meta-attributes are not passed to the builder of the package. Thus, a change
to a meta-attribute doesn’t trigger a recompilation of the package. The
value of a meta-attribute must be a string.
</para>
<para>
The meta-attributes of a package can be queried from the command-line using<command>nix-env</command>:
The meta-attributes of a package can be queried from the command-line using
<command>nix-env</command>:
<screen>
<prompt>$ </prompt>nix-env -qa hello --json
$ nix-env -qa hello --json
{
"hello": {
"meta": {
"description": "A program that produces a familiar, friendly greeting",
hello-2.3 A program that produces a familiar, friendly greeting
</screen>
</para>
@@ -81,13 +88,18 @@ hello-2.3 A program that produces a familiar, friendly greeting
</term>
<listitem>
<para>
A short (one-line) description of the package. This is shown by<command>nix-env -q --description</command> and also on the Nixpkgs release pages.
A short (one-line) description of the package. This is shown by
<command>nix-env -q --description</command> and also on the Nixpkgs
release pages.
</para>
<para>
Don’t include a period at the end. Don’t include newline characters. Capitalise the first character. For brevity, don’t repeat the name of package — just describe what it does.
Don’t include a period at the end. Don’t include newline characters.
Capitalise the first character. For brevity, don’t repeat the name of
package — just describe what it does.
</para>
<para>
Wrong: <literal>"libpng is a library that allows you to decode PNG images."</literal>
Wrong: <literal>"libpng is a library that allows you to decode PNG
images."</literal>
</para>
<para>
Right: <literal>"A library for decoding PNG images"</literal>
@@ -110,7 +122,9 @@ hello-2.3 A program that produces a familiar, friendly greeting
</term>
<listitem>
<para>
Release branch. Used to specify that a package is not going to receive updates that are not in this branch; for example, Linux kernel 3.0 is supposed to be updated to 3.0.X, not 3.1.
Release branch. Used to specify that a package is not going to receive
updates that are not in this branch; for example, Linux kernel 3.0 is
supposed to be updated to 3.0.X, not 3.1.
</para>
</listitem>
</varlistentry>
@@ -120,7 +134,8 @@ hello-2.3 A program that produces a familiar, friendly greeting
</term>
<listitem>
<para>
The package’s homepage. Example:<literal>https://www.gnu.org/software/hello/manual/</literal>
@@ -130,17 +145,8 @@ hello-2.3 A program that produces a familiar, friendly greeting
</term>
<listitem>
<para>
The page where a link to the current version can be found. Example:<literal>https://ftp.gnu.org/gnu/hello/</literal>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<varname>changelog</varname>
</term>
<listitem>
<para>
A link or a list of links to the location of Changelog for a package. A link may use expansion to refer to the correct changelog version. Example: <literal>"https://git.savannah.gnu.org/cgit/hello.git/plain/NEWS?h=v${version}"</literal>
The page where a link to the current version can be found. Example:
<literal>http://ftp.gnu.org/gnu/hello/</literal>
</para>
</listitem>
</varlistentry>
@@ -150,32 +156,46 @@ hello-2.3 A program that produces a familiar, friendly greeting
</term>
<listitem>
<para>
The license, or licenses, for the package. One from the attribute set defined in <link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix"><filename>nixpkgs/lib/licenses.nix</filename></link>. At this moment using both a list of licenses and a single license is valid. If the license field is in the form of a list representation, then it means that parts of the package are licensed differently. Each license should preferably be referenced by their attribute. The non-list attribute value can also be a space delimited string representation of the contained attribute shortNames or spdxIds. The following are all valid examples:
The license, or licenses, for the package. One from the attribute set
@@ -189,8 +209,13 @@ hello-2.3 A program that produces a familiar, friendly greeting
</term>
<listitem>
<para>
A list of names and e-mail addresses of the maintainers of this Nix expression. If you would like to be a maintainer of a package, you may want to add yourself to <link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix"><filename>nixpkgs/maintainers/maintainer-list.nix</filename></link> and write something like <literal>[ stdenv.lib.maintainers.alice stdenv.lib.maintainers.bob ]</literal>.
A list of names and e-mail addresses of the maintainers of this Nix
expression. If you would like to be a maintainer of a package, you may
and write something like <literal>[ stdenv.lib.maintainers.alice
stdenv.lib.maintainers.bob ]</literal>.
</para>
</listitem>
</varlistentry>
@@ -200,7 +225,10 @@ hello-2.3 A program that produces a familiar, friendly greeting
</term>
<listitem>
<para>
The <emphasis>priority</emphasis> of the package, used by<command>nix-env</command> to resolve file name conflicts between packages. See the Nix manual page for <command>nix-env</command> for details. Example: <literal>"10"</literal> (a low-priority package).
The <emphasis>priority</emphasis> of the package, used by
<command>nix-env</command> to resolve file name conflicts between
packages. See the Nix manual page for <command>nix-env</command> for
details. Example: <literal>"10"</literal> (a low-priority package).
</para>
</listitem>
</varlistentry>
@@ -210,48 +238,15 @@ hello-2.3 A program that produces a familiar, friendly greeting
</term>
<listitem>
<para>
The list of Nix platform types on which the package is supported. Hydra builds packages according to the platform specified. If no platform is specified, the package does not have prebuilt binaries. An example is:
The list of Nix platform types on which the package is supported. Hydra
builds packages according to the platform specified. If no platform is
specified, the package does not have prebuilt binaries. An example is:
<programlisting>
meta.platforms = stdenv.lib.platforms.linux;
</programlisting>
Attribute Set <varname>stdenv.lib.platforms</varname> defines<linkxlink:href="https://github.com/NixOS/nixpkgs/blob/master/lib/systems/doubles.nix"> various common lists</link> of platforms types.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<varname>tests</varname>
</term>
<listitem>
<warning>
<para>
This attribute is special in that it is not actually under the <literal>meta</literal> attribute set but rather under the <literal>passthru</literal> attribute set. This is due to how <literal>meta</literal> attributes work, and the fact that they are supposed to contain only metadata, not derivations.
</para>
</warning>
<para>
An attribute set with as values tests. A test is a derivation, which builds successfully when the test passes, and fails to build otherwise. A derivation that is a test needs to have <literal>meta.timeout</literal> defined.
</para>
<para>
The NixOS tests are available as <literal>nixosTests</literal> in parameters of derivations. For instance, the OpenSMTPD derivation includes lines similar to:
A timeout (in seconds) for building the derivation. If the derivation takes longer than this time to build, it can fail due to breaking the timeout. However, all computers do not have the same computing power, hence some builders may decide to apply a multiplicative factor to this value. When filling this value in, try to keep it approximately consistent with other values already present in <literal>nixpkgs</literal>.
Attribute Set <varname>stdenv.lib.platforms</varname> defines
The list of Nix platform types for which the Hydra instance at<literal>hydra.nixos.org</literal> will build the package. (Hydra is the Nix-based continuous build system.) It defaults to the value of <varname>meta.platforms</varname>. Thus, the only reason to set <varname>meta.hydraPlatforms</varname> is if you want <literal>hydra.nixos.org</literal> to build the package on a subset of <varname>meta.platforms</varname>, or not at all, e.g.
The list of Nix platform types for which the Hydra instance at
<literal>hydra.nixos.org</literal> will build the package. (Hydra is the
Nix-based continuous build system.) It defaults to the value of
<varname>meta.platforms</varname>. Thus, the only reason to set
<varname>meta.hydraPlatforms</varname> is if you want
<literal>hydra.nixos.org</literal> to build the package on a subset of
<varname>meta.platforms</varname>, or not at all, e.g.
<programlisting>
meta.platforms = stdenv.lib.platforms.linux;
meta.hydraPlatforms = [];
@@ -275,7 +276,10 @@ meta.hydraPlatforms = [];
</term>
<listitem>
<para>
If set to <literal>true</literal>, the package is marked as “broken”, meaning that it won’t show up in <literal>nix-env -qa</literal>, and cannot be built or installed. Such packages should be removed from Nixpkgs eventually unless they are fixed.
If set to <literal>true</literal>, the package is marked as “broken”,
meaning that it won’t show up in <literal>nix-env -qa</literal>, and
cannot be built or installed. Such packages should be removed from
Nixpkgs eventually unless they are fixed.
</para>
</listitem>
</varlistentry>
@@ -285,7 +289,12 @@ meta.hydraPlatforms = [];
</term>
<listitem>
<para>
If set to <literal>true</literal>, the package is tested to be updated correctly by the <literal>update-walker.sh</literal> script without additional settings. Such packages have <varname>meta.version</varname> set and their homepage (or the page specified by <varname>meta.downloadPage</varname>) contains a direct link to the package tarball.
If set to <literal>true</literal>, the package is tested to be updated
correctly by the <literal>update-walker.sh</literal> script without
additional settings. Such packages have <varname>meta.version</varname>
set and their homepage (or the page specified by
<varname>meta.downloadPage</varname>) contains a direct link to the
package tarball.
</para>
</listitem>
</varlistentry>
@@ -295,11 +304,17 @@ meta.hydraPlatforms = [];
<title>Licenses</title>
<para>
The <varname>meta.license</varname> attribute should preferrably contain a value from <varname>stdenv.lib.licenses</varname> defined in <linkxlink:href="https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix"><filename>nixpkgs/lib/licenses.nix</filename></link>, or in-place license description of the same format if the license is unlikely to be useful in another expression.
The <varname>meta.license</varname> attribute should preferrably contain a
value from <varname>stdenv.lib.licenses</varname> defined in
<filename>nixpkgs/lib/licenses.nix</filename></link>, or in-place license
description of the same format if the license is unlikely to be useful in
another expression.
</para>
<para>
Although it's typically better to indicate the specific license, a few generic options are available:
Although it's typically better to indicate the specific license, a few
generic options are available:
<variablelist>
<varlistentry>
<term>
@@ -317,10 +332,18 @@ meta.hydraPlatforms = [];
</term>
<listitem>
<para>
Unfree package that can be redistributed in binary form. That is, it’s legal to redistribute the <emphasis>output</emphasis> of the derivation. This means that the package can be included in the Nixpkgs channel.
Unfree package that can be redistributed in binary form. That is, it’s
legal to redistribute the <emphasis>output</emphasis> of the derivation.
This means that the package can be included in the Nixpkgs channel.
</para>
<para>
Sometimes proprietary software can only be redistributed unmodified. Make sure the builder doesn’t actually modify the original binaries; otherwise we’re breaking the license. For instance, the NVIDIA X11 drivers can be redistributed unmodified, but our builder applies <command>patchelf</command> to make them work. Thus, its license is <varname>"unfree"</varname> and it cannot be included in the Nixpkgs channel.
Sometimes proprietary software can only be redistributed unmodified.
Make sure the builder doesn’t actually modify the original binaries;
otherwise we’re breaking the license. For instance, the NVIDIA X11
drivers can be redistributed unmodified, but our builder applies
<command>patchelf</command> to make them work. Thus, its license is
<varname>"unfree"</varname> and it cannot be included in the Nixpkgs
channel.
</para>
</listitem>
</varlistentry>
@@ -330,7 +353,9 @@ meta.hydraPlatforms = [];
</term>
<listitem>
<para>
Unfree package that cannot be redistributed. You can build it yourself, but you cannot redistribute the output of the derivation. Thus it cannot be included in the Nixpkgs channel.
Unfree package that cannot be redistributed. You can build it yourself,
but you cannot redistribute the output of the derivation. Thus it cannot
be included in the Nixpkgs channel.
</para>
</listitem>
</varlistentry>
@@ -340,7 +365,9 @@ meta.hydraPlatforms = [];
</term>
<listitem>
<para>
This package supplies unfree, redistributable firmware. This is a separate value from <varname>unfree-redistributable</varname> because not everybody cares whether firmware is free.
This package supplies unfree, redistributable firmware. This is a
separate value from <varname>unfree-redistributable</varname> because
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.
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.
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.
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>
<sectionxml:id="sec-multiple-outputs-installing">
<section>
<title>Installing a split package</title>
<para>
When installing a package via <varname>systemPackages</varname> or<command>nix-env</command> you have several options:
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.
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.
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.
@@ -46,32 +66,43 @@
</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.
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 <xreflinkend="sec-modify-via-packageOverrides"/> to override <varname>meta.outputsToInstall</varname> attributes, but that's a rather inconvenient way.
At this moment there is no similar configurability for packages installed
by <command>nix-env</command>. You can still use approach from
<xreflinkend="sec-modify-via-packageOverrides"/> to override
<varname>meta.outputsToInstall</varname> attributes, but that's a rather
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.
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 <xreflinkend="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.)
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 <xreflinkend="multiple-output-file-type-groups"/>.)
</para>
</section>
<sectionxml:id="sec-multiple-outputs-">
<section>
<title>Writing a split derivation</title>
<para>
@@ -79,18 +110,29 @@
</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 <<filename>nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh</filename>>; 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).
In nixpkgs there is a framework supporting multiple-output derivations. It
tries to cover most cases by default behavior. You can find the source
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.
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 <xreflinkend="stdenv-separateDebugInfo"/>.
There is a special handling of the <varname>debug</varname> output,
described at <xreflinkend="stdenv-separateDebugInfo"/>.
</para>
</note>
@@ -98,15 +140,36 @@
<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.
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>).
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 <linkxlink:href="https://nixos.org/patchelf.html">patchelf</link> for more details).
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
<linkxlink:href="https://nixos.org/patchelf.html">patchelf</link> for more
details).
</para>
</section>
@@ -114,7 +177,13 @@
<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 – a default output name is defined, falling back to other possibilities if the output isn't defined.
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 – a default output name is defined,
falling back to other possibilities if the output isn't defined.
</para>
<variablelist>
@@ -124,7 +193,9 @@
</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.
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>
@@ -134,7 +205,8 @@
</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.
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>
@@ -144,7 +216,9 @@
</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.
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>
@@ -154,7 +228,9 @@
</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.
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>
@@ -164,7 +240,10 @@
</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.
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>
@@ -174,7 +253,8 @@
</term>
<listitem>
<para>
is for man pages (except for section 3). They go to<varname>man</varname> or <varname>$outputBin</varname> by default.
is for man pages (except for section 3). They go to
<varname>man</varname> or <varname>$outputBin</varname> by default.
</para>
</listitem>
</varlistentry>
@@ -184,7 +264,8 @@
</term>
<listitem>
<para>
is for section 3 man pages. They go to <varname>devman</varname> or<varname>$outputMan</varname> by default.
is for section 3 man pages. They go to <varname>devman</varname> or
<varname>$outputMan</varname> by default.
</para>
</listitem>
</varlistentry>
@@ -194,35 +275,45 @@
</term>
<listitem>
<para>
is for info pages. They go to <varname>info</varname> or<varname>$outputBin</varname> by default.
is for info pages. They go to <varname>info</varname> or
<varname>$outputBin</varname> by default.
</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<sectionxml:id="sec-multiple-outputs-caveats">
<section>
<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>.
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.)
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.
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.
Some packages have hidden assumptions on install paths, which complicates
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.
This chapter describes how to extend and change Nixpkgs packages using
overlays. Overlays are used to add layers in the fix-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.
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
The list of overlays can be set either explicitly in a Nix expression, or through <literal><nixpkgs-overlays></literal> or user configuration files.
The list of overlays is determined as follows.
</para>
<sectionxml:id="sec-overlays-argument">
<title>Set overlays in NixOS or Nix expressions</title>
<para>
If the <varname>overlays</varname> argument is not provided explicitly, we
look for overlays in a path. The path is determined as follows:
<orderedlist>
<listitem>
<para>
First, if an <varname>overlays</varname> argument to the nixpkgs function
itself is given, then that is used.
</para>
<para>
This can be passed explicitly when importing nipxkgs, for example
Otherwise, if the Nix path entry <literal><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><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>
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 <linkxlink:href="#sec-overlays-lookup">looked</link> up independently.
</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>
The list of overlays can be passed explicitly when importing nixpkgs, for example <literal>import <nixpkgs> { overlays = [ overlay1 overlay2 ]; }</literal>.
</para>
<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 looked up independently.
</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>
<sectionxml: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 <linkxlink: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><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><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>
<para>
The <filename>overlays.nix</filename> option therefore 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
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.
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>
@@ -122,19 +127,38 @@ self: super:
</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.
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.
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.
The value returned by this function should be a set similar to
Overlays are similar to other methods for customizing Nixpkgs, in particular the <literal>packageOverrides</literal> attribute described in <xreflinkend="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.
Overlays are similar to other methods for customizing Nixpkgs, in particular
the <literal>packageOverrides</literal> attribute described in
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.
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
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>).
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
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:
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
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.
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>).
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:
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>).
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.
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>).
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>:
$ 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>).
Copy <filename>.config</filename> over the new config file (e.g.
<filename>config-2.6.22-i686-smp</filename>).
</para>
</listitem>
</orderedlist>
@@ -78,12 +108,18 @@ modulesTree = [kernel]
</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.
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.
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>
@@ -94,37 +130,58 @@ modulesTree = [kernel]
<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.
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.
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.)
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:
A file like <filename>tarballs-7.5.list</filename> contains all tarballs in
<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>).
<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>.
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
The Nix expressions related to the Eclipse platform and IDE are in<linkxlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/eclipse"><filename>pkgs/applications/editors/eclipse</filename></link>.
The Nix expressions related to the Eclipse platform and IDE are in
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:
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 '<nixpkgs>' -qaP -A eclipses --description
$ nix-env -f '<nixpkgs>' -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.
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
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
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 {
@@ -164,18 +243,38 @@ packageOverrides = pkgs: {
};
}
</screen>
to your Nixpkgs configuration (<filename>~/.config/nixpkgs/config.nix</filename>) and install it by running <command>nix-env -f '<nixpkgs>' -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
to your Nixpkgs configuration
(<filename>~/.config/nixpkgs/config.nix</filename>) and install it by
running <command>nix-env -f '<nixpkgs>' -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 '<nixpkgs>' -qaP -A eclipses.plugins --description
$ nix-env -f '<nixpkgs>' -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.
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
Expanding the previous example with two plugins using the above functions we
have
<screen>
packageOverrides = pkgs: {
myEclipse = with pkgs.eclipses; eclipseWithPlugins {
@@ -212,34 +311,28 @@ packageOverrides = pkgs: {
<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, <linkxlink:href="https://github.com/hercules-ci/elm2nix#elm2nix">read about elm2nix</link>.
</para>
</section>
<sectionxml: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>
The Nix expressions for Elm reside in
<filename>pkgs/development/compilers/elm</filename>. They are generated
automatically by <command>update-elm.rb</command> script. One should specify
versions of Elm packages inside the script, clear the
<filename>packages</filename> directory and run the script from inside it.
<literal>elm-reactor</literal> is special because it also has Elm package
dependencies. The process is not automated very much for now -- you should
get the <literal>elm-reactor</literal> source tree (e.g. with
<command>nix-shell</command>) and run <command>elm2nix.rb</command> inside
it. Place the resulting <filename>package.nix</filename> file into
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:
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
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 = super: self: rec {
haskell-mode = self.melpaPackages.haskell-mode;
...
};
((emacsPackagesNgGen 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>
<sectionxml: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
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
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>.
The plugins currently available are <literal>python</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:
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>
<sectionxml:id="sec-ibus-typing-booster">
<title>ibus-engines.typing-booster</title>
<para>
This package is an ibus-based completion method to speed up typing.
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 <linkxlink: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 ];
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:
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>
<sectionxml:id="sec-nginx">
<title>Nginx</title>
<para>
<linkxlink:href="https://nginx.org/">Nginx</link> is a reverse proxy and lightweight webserver.
</para>
<sectionxml: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 <linkxlink: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 <linkxlink: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.
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 <linklinkend="chap-package-notes">package-specific development notes</link>.
</para>
<sectionxml: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>
<sectionxml: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>
<sectionxml:id="sec-emacs">
<title>Emacs</title>
<sectionxml: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:
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.
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>
<sectionxml:id="dlib">
<title>DLib</title>
<para>
<linkxlink:href="http://dlib.net/">DLib</link> is a modern, C++-based toolkit which provides several machine learning algorithms.
</para>
<sectionxml:id="compiling-without-avx-support">
<title>Compiling without AVX support</title>
<para>
Especially older CPUs don't support <linkxlink: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:
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>
<sectionxml:id="sec-steam">
<title>Steam</title>
<sectionxml: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 <linkxlink: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.
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
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>
<sectionxml:id="sec-citrix">
<title>Citrix Receiver & Citrix Workspace App</title>
<para>
<note>
<para>
Please note that the <literal>citrix_receiver</literal> package has been deprecated since its development was <linkxlink:href="https://docs.citrix.com/en-us/citrix-workspace-app.html">discontinued by upstream</link> and has been replaced by <linkxlink:href="https://www.citrix.com/products/workspace-app/">the citrix workspace app</link>.
</para>
</note>
<linkxlink:href="https://www.citrix.com/products/receiver/">Citrix Receiver</link> and <linkxlink:href="https://www.citrix.com/products/workspace-app/">Citrix Workspace App</link> are a remote desktop viewers which provide access to <linkxlink:href="https://www.citrix.com/products/xenapp-xendesktop/">XenDesktop</link> installations.
</para>
<sectionxml: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 <linkxlink:href="https://www.citrix.com/downloads/citrix-receiver/">Citrix Receiver</link> or <linkxlink: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>
<sectionxml:id="sec-citrix-custom-certs">
<title>Custom certificates</title>
<para>
The <literal>Citrix Workspace App</literal> in <literal>nixpkgs</literal> trust several certificates <linkxlink: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 <linkxlink: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>:
Some common issues when packaging software for Darwin:
Some common issues when packaging software for darwin:
</para>
<itemizedlist>
<listitem>
<para>
The Darwin <literal>stdenv</literal> uses clang instead of gcc. When referring to the compiler <varname>$CC</varname> or <command>cc</command> will work in both cases. Some builds hardcode gcc/g++ in their build scripts, that can usually be fixed with using something like <literal>makeFlags = [ "CC=cc" ];</literal> or by patching the build scripts.
The darwin <literal>stdenv</literal> uses clang instead of gcc. When
referring to the compiler <varname>$CC</varname> or <command>cc</command>
will work in both cases. Some builds hardcode gcc/g++ in their build
scripts, that can usually be fixed with using something like
<literal>makeFlags = [ "CC=cc" ];</literal> or by patching the build
scripts.
</para>
<programlisting>
stdenv.mkDerivation {
name = "libfoo-1.2.3";
# ...
buildPhase = ''
$CC -o hello hello.c
'';
}
</programlisting>
stdenv.mkDerivation {
name = "libfoo-1.2.3";
# ...
buildPhase = ''
$CC -o hello hello.c
'';
}
</programlisting>
</listitem>
<listitem>
<para>
On Darwin, libraries are linked using absolute paths, libraries are resolved by their <literal>install_name</literal> at link time. Sometimes packages won't set this correctly causing the library lookups to fail at runtime. This can be fixed by adding extra linker flags or by running <command>install_name_tool -id</command> during the <function>fixupPhase</function>.
On darwin libraries are linked using absolute paths, libraries are
resolved by their <literal>install_name</literal> at link time. Sometimes
packages won't set this correctly causing the library lookups to fail at
runtime. This can be fixed by adding extra linker flags or by running
<command>install_name_tool -id</command> during the
Even if the libraries are linked using absolute paths and resolved via their <literal>install_name</literal> correctly, tests can sometimes fail to run binaries. This happens because the <varname>checkPhase</varname> runs before the libraries are installed.
</para>
<para>
This can usually be solved by running the tests after the <varname>installPhase</varname> or alternatively by using <varname>DYLD_LIBRARY_PATH</varname>. More information about this variable can be found in the <citerefentry>
<refentrytitle>dyld</refentrytitle>
<manvolnum>1</manvolnum></citerefentry> manpage.
Some packages assume xcode is available and use <command>xcrun</command>
to resolve build tools like <command>clang</command>, etc. This causes
errors like <code>xcode-select: error: no developer tools were found at
'/Applications/Xcode.app'</code> while the build doesn't actually depend
on xcode.
</para>
<programlisting>
dyld: Library not loaded: /nix/store/7hnmbscpayxzxrixrgxvvlifzlxdsdir-jq-1.5-lib/lib/libjq.1.dylib
Some packages assume xcode is available and use <command>xcrun</command> to resolve build tools like <command>clang</command>, etc. This causes errors like <code>xcode-select: error: no developer tools were found at '/Applications/Xcode.app'</code> while the build doesn't actually depend on xcode.
</para>
<programlisting>
stdenv.mkDerivation {
name = "libfoo-1.2.3";
# ...
prePatch = ''
substituteInPlace Makefile \
--replace '/usr/bin/xcrun clang' clang
'';
}
</programlisting>
<para>
The package <literal>xcbuild</literal> can be used to build projects that really depend on Xcode. However, this replacement is not 100% compatible with Xcode and can occasionally cause issues.
The package<literal>xcbuild</literal> can be used to build projects that
really depend on Xcode, however projects that build some kind of graphical
interface won't work without using Xcode in an impure way.
Find a good place in the Nixpkgs tree to add the Nix expression for your package. For instance, a library package typically goes into <filename>pkgs/development/libraries/<replaceable>pkgname</replaceable></filename>, while a web browser goes into <filename>pkgs/applications/networking/browsers/<replaceable>pkgname</replaceable></filename>. See <xreflinkend="sec-organisation"/> for some hints on the tree organisation. Create a directory for your package, e.g.
Find a good place in the Nixpkgs tree to add the Nix expression for your
package. For instance, a library package typically goes into
In the package directory, create a Nix expression — a piece of code that describes how to build the package. In this case, it should be a <emphasis>function</emphasis> that is called with the package dependencies as arguments, and returns a build of the package in the Nix store. The expression should usually be called <filename>default.nix</filename>.
In the package directory, create a Nix expression — a piece of code that
describes how to build the package. In this case, it should be a
<emphasis>function</emphasis> that is called with the package dependencies
as arguments, and returns a build of the package in the Nix store. The
expression should usually be called <filename>default.nix</filename>.
You can have a look at the existing Nix expressions under<filename>pkgs/</filename> to see how it’s done. Here are some good ones:
You can have a look at the existing Nix expressions under
<filename>pkgs/</filename> to see how it’s done. Here are some good
ones:
<itemizedlist>
<listitem>
<para>
GNU Hello:<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/hello/default.nix"><filename>pkgs/applications/misc/hello/default.nix</filename></link>. Trivial package, which specifies some <varname>meta</varname> attributes which is good practice.
Trivial package, which specifies some <varname>meta</varname>
attributes which is good practice.
</para>
</listitem>
<listitem>
<para>
GNU cpio:<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/archivers/cpio/default.nix"><filename>pkgs/tools/archivers/cpio/default.nix</filename></link>. Also a simple package. The generic builder in <varname>stdenv</varname> does everything for you. It has no dependencies beyond <varname>stdenv</varname>.
Also a simple package. The generic builder in <varname>stdenv</varname>
does everything for you. It has no dependencies beyond
<varname>stdenv</varname>.
</para>
</listitem>
<listitem>
<para>
GNU Multiple Precision arithmetic library (GMP):<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/gmp/5.1.x.nix"><filename>pkgs/development/libraries/gmp/5.1.x.nix</filename></link>. Also done by the generic builder, but has a dependency on <varname>m4</varname>.
Also done by the generic builder, but has a dependency on
<varname>m4</varname>.
</para>
</listitem>
<listitem>
<para>
Pan, a GTK-based newsreader:<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/newsreaders/pan/default.nix"><filename>pkgs/applications/networking/newsreaders/pan/default.nix</filename></link>. Has an optional dependency on <varname>gtkspell</varname>, which is only built if <varname>spellCheck</varname> is <literal>true</literal>.
Has an optional dependency on <varname>gtkspell</varname>, which is
only built if <varname>spellCheck</varname> is <literal>true</literal>.
</para>
</listitem>
<listitem>
<para>
Apache HTTPD:<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/http/apache-httpd/2.4.nix"><filename>pkgs/servers/http/apache-httpd/2.4.nix</filename></link>. A bunch of optional features, variable substitutions in the configure flags, a post-install hook, and miscellaneous hackery.
A bunch of optional features, variable substitutions in the configure
flags, a post-install hook, and miscellaneous hackery.
</para>
</listitem>
<listitem>
<para>
Thunderbird:<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/mailreaders/thunderbird/default.nix"><filename>pkgs/applications/networking/mailreaders/thunderbird/default.nix</filename></link>. Lots of dependencies.
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.
Nixpkgs doesn’t have a decent <varname>stdenv</varname> for Java yet
so this is pretty ad-hoc.
</para>
</listitem>
<listitem>
<para>
XML::Simple, a Perl module:<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> (search for the <varname>XMLSimple</varname> attribute). Most Perl modules are so simple to build that they are defined directly in <filename>perl-packages.nix</filename>; no need to make a separate file for them.
(search for the <varname>XMLSimple</varname> attribute). Most Perl
modules are so simple to build that they are defined directly in
<filename>perl-packages.nix</filename>; no need to make a separate file
for them.
</para>
</listitem>
<listitem>
<para>
Adobe Reader:<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/adobe-reader/default.nix"><filename>pkgs/applications/misc/adobe-reader/default.nix</filename></link>. Shows how binary-only packages can be supported. In particular the <link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/adobe-reader/builder.sh">builder</link> uses <command>patchelf</command> to set the RUNPATH and ELF interpreter of the executables so that the right libraries are found at runtime.
uses <command>patchelf</command> to set the RUNPATH and ELF interpreter
of the executables so that the right libraries are found at runtime.
</para>
</listitem>
</itemizedlist>
@@ -93,59 +138,80 @@
<itemizedlist>
<listitem>
<para>
All <varnamelinkend="chap-meta">meta</varname> attributes are optional, but it’s still a good idea to provide at least the <varname>description</varname>, <varname>homepage</varname> and <varname
All <varnamelinkend="chap-meta">meta</varname> attributes are
optional, but it’s still a good idea to provide at least the
<varname>description</varname>, <varname>homepage</varname> and
<varname
linkend="sec-meta-license">license</varname>.
</para>
</listitem>
<listitem>
<para>
You can use <command>nix-prefetch-url</command><replaceable>url</replaceable> to get the SHA-256 hash of source distributions. There are similar commands as <command>nix-prefetch-git</command> and <command>nix-prefetch-hg</command> available in <literal>nix-prefetch-scripts</literal> package.
You can use <command>nix-prefetch-url</command>(or similar
nix-prefetch-git, etc) <replaceable>url</replaceable> to get the
SHA-256 hash of source distributions. There are similar commands as
<command>nix-prefetch-git</command> and
<command>nix-prefetch-hg</command> available in
<literal>nix-prefetch-scripts</literal> package.
</para>
</listitem>
<listitem>
<para>
A list of schemes for <literal>mirror://</literal> URLs can be found in<link
A list of schemes for <literal>mirror://</literal> URLs can be found in
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="http://hydra.nixos.org/job/nix/trunk/tarball/latest/download-by-type/doc/manual/#chap-writing-nix-expressions">chapter on writing Nix expressions</link>.
The exact syntax and semantics of the Nix expression language, including
the built-in function, are described in the Nix manual in the
Add a call to the function defined in the previous step to<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix"><filename>pkgs/top-level/all-packages.nix</filename></link> with some descriptive name for the variable, e.g. <varname>libfoo</varname>.
Add a call to the function defined in the previous step to
The attributes in that file are sorted by category (like “Development / Libraries”) that more-or-less correspond to the directory structure of Nixpkgs, and then by attribute name.
The attributes in that file are sorted by category (like “Development /
Libraries”) that more-or-less correspond to the directory structure of
Nixpkgs, and then by attribute name.
</para>
</listitem>
<listitem>
<para>
To test whether the package builds, run the following command from the root of the nixpkgs source tree:
To test whether the package builds, run the following command from the
root of the nixpkgs source tree:
<screen>
<prompt>$ </prompt>nix-build -A libfoo</screen>
where <varname>libfoo</varname> should be the variable name defined in the previous step. You may want to add the flag <option>-K</option> to keep the temporary build directory in case something fails. If the build succeeds, a symlink <filename>./result</filename> to the package in the Nix store is created.
$ nix-build -A libfoo</screen>
where <varname>libfoo</varname> should be the variable name defined in the
previous step. You may want to add the flag <option>-K</option> to keep
the temporary build directory in case something fails. If the build
succeeds, a symlink <filename>./result</filename> to the package in the
Nix store is created.
</para>
</listitem>
<listitem>
<para>
If you want to install the package into your profile (optional), do
Optionally commit the new package and open a pull request<link
xlink:href="https://github.com/NixOS/nixpkgs/pulls">to nixpkgs</link>, or use <link
xlink:href="https://discourse.nixos.org/t/about-the-patches-category/477"> the Patches category</link> on Discourse for sending a patch without a GitHub account.
Optionally commit the new package and open a pull request, or send a patch
to <literal>https://groups.google.com/forum/#!forum/nix-devel</literal>.
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.)
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.
Since the last release, there have been thousands of changes and new
packages by numerous contributors. For details, see the commit logs.
</para>
</section>
<sectionxml:id="release-notes-0.13">
<section>
<title>Release 0.13 (February 5, 2010)</title>
<para>
@@ -47,15 +51,18 @@
</itemizedlist>
</para>
</section>
<sectionxml:id="release-notes-0.12">
<section>
<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:
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.
Nixpkgs now has a manual. In particular, it describes the standard build
environment in detail.
</para>
</listitem>
<listitem>
@@ -115,7 +122,9 @@
</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.
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>
@@ -127,10 +136,16 @@
</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.
The following people contributed to this release: Andres Löh, Arie
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>
<sectionxml:id="release-notes-0.11">
<section>
<title>Release 0.11 (September 11, 2007)</title>
<para>
@@ -138,12 +153,25 @@
<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.
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:
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
@@ -154,57 +182,91 @@ postInstall() {
}
genericBuild</programlisting>
(the <literal>gzip</literal> builder), you can just add this attribute to the derivation:
(the <literal>gzip</literal> builder), you can just add this attribute to
and so a separate build script becomes unnecessary. This should allow us to get rid of most builders in Nixpkgs.
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,
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
since the <literal>-g</literal> would be interpreted as a separate
argument to <command>configure</command>. Now you can say
which does the right thing. Idem for <literal>makeFlags</literal>,<literal>installFlags</literal>, <literal>checkFlags</literal> and <literal>distFlags</literal>.
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.,
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.,
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
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> 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.
<function>fetchurl</function> will first try to download this file from
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:
Second, <function>fetchurl</function> has support for widely-mirrored
distribution sites such as SourceForge or the Linux kernel archives.
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.
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.
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.
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>
<sectionxml:id="release-notes-0.10">
<section>
<title>Release 0.10 (October 12, 2006)</title>
<note>
<para>
This release of Nixpkgs requires<link
xlink:href='http://nixos.org/releases/nix/nix-0.10/'>Nix 0.10</link> or higher.
@@ -297,15 +363,32 @@ xlink:href='http://nixos.org/releases/nix/nix-0.10/'>Nix 0.10</link> or higher.
<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.
<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.
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:
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 = {
@@ -315,7 +398,9 @@ xlink:href='http://nixos.org/releases/nix/nix-0.10/'>Nix 0.10</link> or higher.
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.)
(Actually, <literal>firefox.enableRealPlayer</literal> is the
<emphasis>only</emphasis> configuration option currently available, but
more are sure to be added.)
</para>
</listitem>
<listitem>
@@ -324,8 +409,17 @@ xlink:href='http://nixos.org/releases/nix/nix-0.10/'>Nix 0.10</link> or higher.
<itemizedlist>
<listitem>
<para>
<literal>i686-cygwin</literal>, i.e., Windows (using<linkxlink: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>.
<literal>i686-cygwin</literal>, i.e., Windows (using
<linkxlink: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>
@@ -340,7 +434,9 @@ xlink:href='http://nixos.org/releases/nix/nix-0.10/'>Nix 0.10</link> or higher.
</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.
<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>
@@ -376,10 +472,21 @@ xlink:href='http://nixos.org/releases/nix/nix-0.10/'>Nix 0.10</link> or higher.
</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.
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
For instance, the package <varname>strategoxt</varname> doesn’t build with the GNU Make in <literal>stdenv</literal> (version 3.81), so we call it with an augmented <literal>stdenv</literal> that uses GNU Make 3.80:
For instance, the package <varname>strategoxt</varname> doesn’t build
with the GNU Make in <literal>stdenv</literal> (version 3.81), so we call
it with an augmented <literal>stdenv</literal> that uses GNU Make 3.80:
It has also become much easier to experiment with changes to the<literal>stdenv</literal> setup script (which notably contains the generic builder). Since edits to <filename>pkgs/stdenv/generic/setup.sh</filename> trigger a rebuild of <emphasis>everything</emphasis>, this was formerly quite painful. But now <literal>stdenv</literal> contains a function to “regenerate” <literal>stdenv</literal> with a different setup script, allowing the use of a different setup script for specific packages:
It has also become much easier to experiment with changes to the
<literal>stdenv</literal> setup script (which notably contains the generic
builder). Since edits to <filename>pkgs/stdenv/generic/setup.sh</filename>
trigger a rebuild of <emphasis>everything</emphasis>, this was formerly
quite painful. But now <literal>stdenv</literal> contains a function to
“regenerate” <literal>stdenv</literal> with a different setup script,
allowing the use of a different setup script for specific packages:
Packages can now have a human-readable <emphasis>description</emphasis> field. Package descriptions are shown by <literal>nix-env -qa --description</literal>. In addition, they’re shown on the Nixpkgs release page. A description can be added to a package as follows:
Packages can now have a human-readable <emphasis>description</emphasis>
field. Package descriptions are shown by <literal>nix-env -qa
--description</literal>. In addition, they’re shown on the Nixpkgs
release page. A description can be added to a package as follows:
<programlisting>
stdenv.mkDerivation {
name = "exult-1.2";
@@ -416,26 +533,34 @@ stdenv.mkDerivation {
description = "A reimplementation of the Ultima VII game engine";
};
}</programlisting>
The <varname>meta</varname> attribute is not passed to the builder, so changes to the description do not trigger a rebuild. Additional <varname>meta</varname> attributes may be defined in the future (such as the URL of the package’s homepage, the license, etc.).
The <varname>meta</varname> attribute is not passed to the builder, so
changes to the description do not trigger a rebuild. Additional
<varname>meta</varname> attributes may be defined in the future (such as
the URL of the package’s homepage, the license, etc.).
</para>
</listitem>
</itemizedlist>
<para>
The following people contributed to this release: Andres Löh, Armijn Hemel, Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof, Martin Bravenboer, Merijn de Jonge, Rob Vermaas and Roy van den Broek.
The following people contributed to this release: Andres Löh, Armijn Hemel,
Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof, Martin
Bravenboer, Merijn de Jonge, Rob Vermaas and Roy van den Broek.
</para>
</section>
<sectionxml:id="release-notes-0.9">
<section>
<title>Release 0.9 (January 31, 2006)</title>
<para>
There have been zillions of changes since the last release of Nixpkgs. Many packages have been added or updated. The following are some of the more notable changes:
There have been zillions of changes since the last release of Nixpkgs. Many
packages have been added or updated. The following are some of the more
notable changes:
</para>
<itemizedlist>
<listitem>
<para>
Distribution files have been moved to<link
Distribution files have been moved to
<link
xlink:href="http://nixos.org/"/>.
</para>
</listitem>
@@ -451,17 +576,24 @@ stdenv.mkDerivation {
</listitem>
<listitem>
<para>
The old, unofficial Xlibs has been replaced by the official modularised X11 distribution from X.org, i.e., X11R7.0. X11R7.0 consists of 287 (!) packages, all of which are in Nixpkgs though not all have been tested. It is now possible to build a working X server (previously we only had X client libraries). We use a fully Nixified X server on NixOS.
The old, unofficial Xlibs has been replaced by the official modularised
X11 distribution from X.org, i.e., X11R7.0. X11R7.0 consists of 287 (!)
packages, all of which are in Nixpkgs though not all have been tested. It
is now possible to build a working X server (previously we only had X
client libraries). We use a fully Nixified X server on NixOS.
</para>
</listitem>
<listitem>
<para>
The Sun JDK 5 has been purified, i.e., it doesn’t require any non-Nix components such as <filename>/lib/ld-linux.so.2</filename>. This means that Java applications such as Eclipse and Azureus can run on NixOS.
The Sun JDK 5 has been purified, i.e., it doesn’t require any non-Nix
components such as <filename>/lib/ld-linux.so.2</filename>. This means
that Java applications such as Eclipse and Azureus can run on NixOS.
</para>
</listitem>
<listitem>
<para>
Hardware-accelerated OpenGL support, used by games like Quake 3 (which is now built from source).
Hardware-accelerated OpenGL support, used by games like Quake 3 (which is
now built from source).
</para>
</listitem>
<listitem>
@@ -476,7 +608,8 @@ stdenv.mkDerivation {
</listitem>
<listitem>
<para>
Some support for cross-compilation: cross-compiling builds of GCC and Binutils, and cross-compiled builds of the C library uClibc.
Some support for cross-compilation: cross-compiling builds of GCC and
Binutils, and cross-compiled builds of the C library uClibc.
</para>
</listitem>
<listitem>
@@ -485,7 +618,8 @@ stdenv.mkDerivation {
<itemizedlist>
<listitem>
<para>
teTeX, including support for building LaTeX documents using Nix (with automatic dependency determination).
teTeX, including support for building LaTeX documents using Nix (with
automatic dependency determination).
</para>
</listitem>
<listitem>
@@ -495,12 +629,14 @@ stdenv.mkDerivation {
</listitem>
<listitem>
<para>
System-level packages to support NixOS, e.g. Grub, GNU<literal>parted</literal> and so on.
System-level packages to support NixOS, e.g. Grub, GNU
<literal>parted</literal> and so on.
</para>
</listitem>
<listitem>
<para>
<literal>ecj</literal>, the Eclipse Compiler for Java, so we finally have a freely distributable compiler that supports Java 5.0.
<literal>ecj</literal>, the Eclipse Compiler for Java, so we finally
have a freely distributable compiler that supports Java 5.0.
</para>
</listitem>
<listitem>
@@ -525,7 +661,8 @@ stdenv.mkDerivation {
</listitem>
<listitem>
<para>
<literal>kdelibs</literal>. This allows us to add KDE-based packages (such as <literal>kcachegrind</literal>).
<literal>kdelibs</literal>. This allows us to add KDE-based packages
(such as <literal>kcachegrind</literal>).
</para>
</listitem>
</itemizedlist>
@@ -534,14 +671,17 @@ stdenv.mkDerivation {
</itemizedlist>
<para>
The following people contributed to this release: Andres Löh, Armijn Hemel, Bogdan Dumitriu, Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof, Martin Bravenboer, Rob Vermaas and Roy van den Broek.
The following people contributed to this release: Andres Löh, Armijn Hemel,
Bogdan Dumitriu, Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof,
Martin Bravenboer, Rob Vermaas and Roy van den Broek.
</para>
</section>
<sectionxml:id="release-notes-0.8">
<section>
<title>Release 0.8 (April 11, 2005)</title>
<para>
This release is mostly to remain synchronised with the changed hashing scheme in Nix 0.8.
This release is mostly to remain synchronised with the changed hashing
scheme in Nix 0.8.
</para>
<para>
@@ -560,16 +700,22 @@ stdenv.mkDerivation {
</itemizedlist>
</para>
</section>
<sectionxml:id="release-notes-0.7">
<section>
<title>Release 0.7 (March 14, 2005)</title>
<itemizedlist>
<listitem>
<para>
The bootstrap process for the standard build environment on Linux (stdenv-linux) has been improved. It is no longer dependent in its initial bootstrap stages on the system Glibc, GCC, and other tools. Rather, Nixpkgs contains a statically linked bash and curl, and uses that to download other statically linked tools. These are then used to build a Glibc and dynamically linked versions of all other tools.
The bootstrap process for the standard build environment on Linux
(stdenv-linux) has been improved. It is no longer dependent in its initial
bootstrap stages on the system Glibc, GCC, and other tools. Rather,
Nixpkgs contains a statically linked bash and curl, and uses that to
download other statically linked tools. These are then used to build a
Glibc and dynamically linked versions of all other tools.
</para>
<para>
This change also makes the bootstrap process faster. For instance, GCC is built only once instead of three times.
This change also makes the bootstrap process faster. For instance, GCC is
built only once instead of three times.
</para>
<para>
(Contributed by Armijn Hemel.)
@@ -577,13 +723,17 @@ stdenv.mkDerivation {
</listitem>
<listitem>
<para>
Tarballs used by Nixpkgs are now obtained from the same server that hosts Nixpkgs (<link
xlink:href="http://catamaran.labs.cs.uu.nl/"/>). This reduces the risk of packages being unbuildable due to moved or deleted files on various servers.
Tarballs used by Nixpkgs are now obtained from the same server that hosts
Nixpkgs (<link
xlink:href="http://catamaran.labs.cs.uu.nl/"/>). This
reduces the risk of packages being unbuildable due to moved or deleted
files on various servers.
</para>
</listitem>
<listitem>
<para>
There now is a generic mechanism for building Perl modules. See the various Perl modules defined in pkgs/system/all-packages-generic.nix.
There now is a generic mechanism for building Perl modules. See the
various Perl modules defined in pkgs/system/all-packages-generic.nix.
The Nixpkgs project receives a fairly high number of contributions via GitHub pull requests. Reviewing and approving these is an important task and a way to contribute to the project.
The nixpkgs project receives a fairly high number of contributions via GitHub
pull-requests. Reviewing and approving these is an important task and a way
to contribute to the project.
</para>
<para>
The high change rate of Nixpkgs makes any pull request that remains open for too long 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 this issue. 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
xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc">least recently</link> updated pull requests. We highly encourage looking at <linkxlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+review%3Anone+status%3Asuccess+-label%3A%222.status%3A+work-in-progress%22+no%3Aproject+no%3Aassignee+no%3Amilestone"> this list of ready to merge, unreviewed pull requests</link>.
The high change rate of nixpkgs makes any pull request that remains open for
too long 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
When reviewing a pull request, please always be nice and polite. Controversial changes can lead to controversial opinions, but it is important to respect every community member and their work.
When reviewing a pull request, please always be nice and polite.
Controversial changes can lead to controversial opinions, but it is important
to respect every community member and their work.
</para>
<para>
GitHub provides reactions as a simple and quick way to provide feedback to pull requests or any comments. The thumb-down reaction should be used with care and if possible accompanied with some explanation so the submitter has directions to improve their contribution.
GitHub provides reactions as a simple and quick way to provide feedback to
pull-requests or any comments. The thumb-down reaction should be used with
care and if possible accompanied with some explanation so the submitter has
directions to improve their contribution.
</para>
<para>
pullrequest reviews should include a list of what has been reviewed in a comment, so other reviewers and mergers can know the state of the review.
Pull-request reviews should include a list of what has been reviewed in a
comment, so other reviewers and mergers can know the state of the review.
</para>
<para>
All the review template samples provided in this section are generic and meant as examples. Their usage is optional and the reviewer is free to adapt them to their liking.
All the review template samples provided in this section are generic and
meant as examples. Their usage is optional and the reviewer is free to adapt
A package update is the most trivial and common type of pullrequest. These pull requests mainly consist of updating the version part of the package name and the source hash.
A package update is the most trivial and common type of pull-request. These
pull-requests mainly consist of updating the version part of the package
name and the source hash.
</para>
<para>
It can happen that non-trivial updates include patches or more complex changes.
It can happen that non-trivial updates include patches or more complex
changes.
</para>
<para>
@@ -49,12 +75,13 @@
<itemizedlist>
<listitem>
<para>
Add labels to the pullrequest. (Requires commit rights)
Add labels to the pull-request. (Requires commit rights)
</para>
<itemizedlist>
<listitem>
<para>
<literal>8.has: package (update)</literal> and any topic label that fit the updated package.
<literal>8.has: package (update)</literal> and any topic label that fit
the updated package.
</para>
</listitem>
</itemizedlist>
@@ -76,7 +103,9 @@
<itemizedlist>
<listitem>
<para>
<linkxlink:href="https://help.github.com/articles/about-codeowners/">CODEOWNERS</link> will make GitHub notify users based on the submitted changes, but it can happen that it misses some of the package maintainers.
mention-bot usually notifies GitHub users based on the submitted
changes, but it can happen that it misses some of the package
maintainers.
</para>
</listitem>
</itemizedlist>
@@ -88,12 +117,15 @@
<itemizedlist>
<listitem>
<para>
License can change with version updates, so it should be checked to match the upstream license.
License can change with version updates, so it should be checked to
match the upstream license.
</para>
</listitem>
<listitem>
<para>
If the package has no maintainer, a maintainer must be set. This can be the update submitter or a community member that accepts to take maintainership of the package.
If the package has no maintainer, a maintainer must be set. This can be
the update submitter or a community member that accepts to take
maintainership of the package.
</para>
</listitem>
</itemizedlist>
@@ -110,22 +142,27 @@
<itemizedlist>
<listitem>
<para>
pullrequests are often targeted to the master or staging branch, and building the pull request locally when it is submitted can trigger many source builds.
Pull-requests are often targeted to the master or staging branch, and
building the pull-request locally when it is submitted can trigger many
source builds.
</para>
<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.
It is possible to rebase the changes on nixos-unstable or
nixpkgs-unstable for easier review by running the following commands
$ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD <co
xml:id='reviewing-rebase-4'/>
</screen>
<calloutlist>
<calloutarearefs='reviewing-rebase-1'>
<para>
This should be done only once to be able to fetch channel branches from the nixpkgs-channels repository.
This should be done only once to be able to fetch channel branches
from the nixpkgs-channels repository.
</para>
</callout>
<calloutarearefs='reviewing-rebase-2'>
@@ -135,12 +172,14 @@
</callout>
<calloutarearefs='reviewing-rebase-3'>
<para>
Fetching the pullrequest changes, <varname>PRNUMBER</varname> is the number at the end of the pull request title and <varname>BASEBRANCH</varname> the base branch of the pull request.
Fetching the pull-request changes, <varname>PRNUMBER</varname> is the
number at the end of the pull-request title and
<varname>BASEBRANCH</varname> the base branch of the pull-request.
</para>
</callout>
<calloutarearefs='reviewing-rebase-4'>
<calloutarearefs='reviewing-rebase-3'>
<para>
Rebasing the pullrequest changes to the nixos-unstable branch.
Rebasing the pull-request changes to the nixos-unstable branch.
</para>
</callout>
</calloutlist>
@@ -148,10 +187,14 @@
</listitem>
<listitem>
<para>
The <linkxlink: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.
The <linkxlink:href="https://github.com/madjar/nox">nox</link> tool can
be used to review a pull-request content in a single command. It doesn't
rebase on a channel branch so it might trigger multiple source builds.
<varname>PRNUMBER</varname> should be replaced by the number at the end
Module updates are submissions changing modules in some ways. These often contains changes to the options or introduce new options.
Module updates are submissions changing modules in some ways. These often
contains changes to the options or introduce new options.
</para>
<para>
@@ -311,12 +359,13 @@
<itemizedlist>
<listitem>
<para>
Add labels to the pullrequest. (Requires commit rights)
Add labels to the pull-request. (Requires commit rights)
</para>
<itemizedlist>
<listitem>
<para>
<literal>8.has: module (update)</literal> and any topic label that fit the module.
<literal>8.has: module (update)</literal> and any topic label that fit
the module.
</para>
</listitem>
</itemizedlist>
@@ -328,7 +377,8 @@
<itemizedlist>
<listitem>
<para>
<linkxlink:href="https://help.github.com/articles/about-codeowners/">CODEOWNERS</link> will make GitHub notify users based on the submitted changes, but it can happen that it misses some of the package maintainers.
Mention-bot notify GitHub users based on the submitted changes, but it
can happen that it miss some of the package maintainers.
</para>
</listitem>
</itemizedlist>
@@ -345,7 +395,9 @@
<itemizedlist>
<listitem>
<para>
Type should be appropriate (string related types differs in their merging capabilities, <literal>optionSet</literal> and <literal>string</literal> types are deprecated).
Type should be appropriate (string related types differs in their
merging capabilities, <literal>optionSet</literal> and
<literal>string</literal> types are deprecated).
</para>
</listitem>
<listitem>
@@ -362,19 +414,23 @@
<itemizedlist>
<listitem>
<para>
<literal>mkRenamedOptionModule</literal> and<literal>mkAliasOptionModule</literal> functions provide way to make option changes backward compatible.
<literal>mkRenamedOptionModule</literal> and
<literal>mkAliasOptionModule</literal> functions provide way to make
option changes backward compatible.
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
Ensure that removed options are declared with<literal>mkRemovedOptionModule</literal>
Ensure that removed options are declared with
<literal>mkRemovedOptionModule</literal>
</para>
</listitem>
<listitem>
<para>
Ensure that changes that are not backward compatible are mentioned in release notes.
Ensure that changes that are not backward compatible are mentioned in
Add labels to the pullrequest. (Requires commit rights)
Add labels to the pull-request. (Requires commit rights)
</para>
<itemizedlist>
<listitem>
<para>
<literal>8.has: module (new)</literal> and any topic label that fit the module.
<literal>8.has: module (new)</literal> and any topic label that fit the
module.
</para>
</listitem>
</itemizedlist>
@@ -437,7 +494,9 @@
<itemizedlist>
<listitem>
<para>
Type should be appropriate (string related types differs in their merging capabilities, <literal>optionSet</literal> and <literal>string</literal> types are deprecated).
Type should be appropriate (string related types differs in their
merging capabilities, <literal>optionSet</literal> and
<literal>string</literal> types are deprecated).
</para>
</listitem>
<listitem>
@@ -459,7 +518,8 @@
</listitem>
<listitem>
<para>
Module documentation should be declared with<literal>meta.doc</literal>.
Module documentation should be declared with
<literal>meta.doc</literal>.
</para>
</listitem>
</itemizedlist>
@@ -471,14 +531,15 @@
<itemizedlist>
<listitem>
<para>
For example, enabling a module should not open firewall ports by default.
For example, enabling a module should not open firewall ports by
If you consider having enough knowledge and experience in a topic and would like to be a long-term reviewer for related submissions, please contact the current reviewers for that topic. They will give you information about the reviewing process. The main reviewers for a topic can be hard to find as there is no list, but checking past pull requests to see who reviewed or git-blaming the code to see who committed to that topic can give some hints.
If you consider having enough knowledge and experience in a topic and would
like to be a long-term reviewer for related submissions, please contact the
current reviewers for that topic. They will give you information about the
reviewing process. The main reviewers for a topic can be hard to find as
there is no list, but checking past pull-requests to see who reviewed or
git-blaming the code to see who committed to that topic can give some hints.
</para>
<para>
Container system, boot system and library changes are some examples of the pull requests fitting this category.
Container system, boot system and library changes are some examples of the
It is possible for community members that have enough knowledge and experience on a special topic to contribute by merging pull requests.
It is possible for community members that have enough knowledge and
experience on a special topic to contribute by merging pull requests.
</para>
<para>
@@ -536,8 +604,10 @@ policy.
-->
<para>
In a case a contributor definitively leaves the Nix community, they should create an issue or post on <link
xlink:href="https://discourse.nixos.org">Discourse</link> with references of packages and modules they maintain so the maintainership can be taken over by other contributors.
In a case a contributor leaves definitively the Nix community, he should
create an issue or notify the mailing list with references of packages and
modules he maintains so the maintainership can be taken over by other
Read <linkxlink:href="https://nixos.org/nixpkgs/manual/">Manual (How to write packages for Nix)</link>.
Read <linkxlink:href="https://nixos.org/nixpkgs/manual/">Manual (How to
write packages for Nix)</link>.
</para>
</listitem>
<listitem>
@@ -22,17 +23,21 @@
<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.
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:
For example: <command>nixos-version</command> returns
<command>15.05.git.0998212 (Dingo)</command>. So you can do:
<command>nix-env -i pkg-name -f <path to your local nixpkgs folder></command>
<command>nix-env -i pkg-name -f <path to your local nixpkgs
folder></command>
</para>
</listitem>
</itemizedlist>
@@ -138,11 +149,15 @@ Additional information.
</listitem>
<listitem>
<para>
<emphasis>If you don't want to install pkg in you profile</emphasis>.
<emphasis>If you don't want to install pkg in you
profile</emphasis>.
<itemizedlist>
<listitem>
<para>
<command>nix-build -A pkg-attribute-name <path to your local nixpkgs folder>/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>.
<command>nix-build -A pkg-attribute-name <path to your local
nixpkgs folder>/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>
@@ -150,7 +165,9 @@ Additional information.
</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.
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>
@@ -162,7 +179,10 @@ Additional information.
<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=<path to your local nixpkgs folder> --fast</command>.
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=<path to your local
nixpkgs folder> --fast</command>.
</para>
</listitem>
</itemizedlist>
@@ -173,7 +193,9 @@ Additional information.
</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>.
If you have commits <command>pkg-name: oh, forgot to insert
whitespace</command>: squash commits in this case. Use <command>git rebase
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.
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:
When a PR is created, it will be pre-populated with some checkboxes detailed
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.
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
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.
Sandboxing is not enabled by default in Nix due to a small performance hit
Depending if you use NixOS or other platforms you can use one of the following methods to enable sandboxing <emphasisrole="bold">before</emphasis> building the package:
Depending if you use NixOS or other platforms you can use one of the
following methods to enable sandboxing
<emphasisrole="bold">before</emphasis> building the package:
<itemizedlist>
<listitem>
<para>
<emphasisrole="bold">Globally enable sandboxing on NixOS</emphasis>: add the following to <filename>configuration.nix</filename>
<emphasisrole="bold">Globally enable sandboxing on NixOS</emphasis>:
add the following to <filename>configuration.nix</filename>
<screen>nix.useSandbox = true;</screen>
</para>
</listitem>
<listitem>
<para>
<emphasisrole="bold">Globally enable sandboxing on non-NixOS platforms</emphasis>: add the following to: <filename>/etc/nix/nix.conf</filename>
<emphasisrole="bold">Globally enable sandboxing on non-NixOS
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.
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>
<sectionxml:id="submitting-changes-nixos-tests">
<section>
<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>.
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
<title>Tested compilation of all pkgs that depend on this change using <command>nix-review</command></title>
<section>
<title>Tested compilation of all pkgs that depend on this change using <command>nox-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.
<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.
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
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.
Commits must be sufficiently tested before being merged, both for the master and staging branches.
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.
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.
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.
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. <linkxlink:href="https://web.archive.org/web/20160528180406/http://comments.gmane.org/gmane.linux.distributions.nixos/13447">Read policy here</link>.
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.
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. <linkxlink: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.
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
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.
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:
@@ -421,7 +515,7 @@ 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
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
