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 5b77b0d2f1eda9a42fe188eafb499230741e7925)
(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 6546d17cfff4fc2a0f867d15f0d431e604b25740)
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.
"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.
"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>
<section>
<title>Platform parameters</title>
<para>
Nixpkgs follows the <linkxlink:href="https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html">common historical convention of GNU autoconf</link> of distinguishing between 3 types of platform: <wordasword>build</wordasword>, <wordasword>host</wordasword>, and <wordasword>target</wordasword>.
<title>Platform parameters</title>
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.
historical convention of GNU autoconf</link> of distinguishing between 3
types of platform: <wordasword>build</wordasword>,
<wordasword>host</wordasword>, and <wordasword>target</wordasword>. In
summary, <wordasword>build</wordasword> is the platform on which a package
is being built, <wordasword>host</wordasword> is the platform on which it
is to run. The third attribute, <wordasword>target</wordasword>, is
relevant only for certain specific compilers and build tools.
</para>
<para>
In Nixpkgs, these three platforms are defined as attribute sets under the names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>, and <literal>targetPlatform</literal>.
All three are always defined as attributes in the standard environment, and at the top level. That means one can get at them just like a dependency in a function that is imported with<literal>callPackage</literal>:
<programlisting>{ stdenv, buildPlatform, hostPlatform, fooDep, barDep, .. }: ...buildPlatform...</programlisting>, or just off <varname>stdenv</varname>:
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>
<varlistentry>
<term><varname>hostPlatform</varname></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.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>targetPlatform</varname></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.
</para>
<para>
The build process of certain compilers is written in such a way that the compiler resulting from a single build can itself only produce binaries for a single platform.
The task specifying this single "target platform" is thus pushed to build time of the compiler.
The root cause of this mistake is often that the compiler (which will be run on the host) and the the standard library/runtime (which will be run on the target) are built by a single build process.
</para>
<para>
There is no fundamental need to think about 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 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:
</para>
<variablelist>
<varlistentry>
<term><varname>system</varname></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.
This format isn't very standard, but has built-in support in Nix, such as the <varname>builtins.currentSystem</varname> impure string.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>config</varname></term>
<listitem>
<para>
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>
<varlistentry>
<term><varname>parsed</varname></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>.
[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>
<varlistentry>
<term><varname>libc</varname></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>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>is*</varname></term>
<listitem>
<para>
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>
<varlistentry>
<term><varname>platform</varname></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!
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
In Nixpkgs, these three platforms are defined as attribute sets under the
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>
<varlistentry>
<term>
<varname>parsed</varname>
</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>. [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>
<varlistentry>
<term>
<varname>libc</varname>
</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>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<varname>is*</varname>
</term>
<listitem>
<para>
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>
<varlistentry>
<term>
<varname>platform</varname>
</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!
</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section>
<title>Specifying Dependencies</title>
<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>
In this section we explore the relationship between both runtime and buildtime dependencies and the 3 Autoconf platforms.
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>
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>
<note>
<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.
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>
<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>
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>
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>
<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>
</note>
</section>
<section>
<title>Cross packagaing cookbook</title>
<para>
Some frequently problems when packaging for cross compilation 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.
Feel free to add to this list!
</para>
<qandaset>
<qandaentry>
<question><para>
What if my package's build system needs to build a C program to be run under the build environment?
More information needs to moved from the old wiki, especially <linkxlink:href="https://nixos.org/wiki/CrossCompiling"/>, for this section.
</para></note>
<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: <programlisting>
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 <programlisting>
<para>
Eventually we would like to make these platform examples an unnecessary
convenience so that
<programlisting>
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 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.
</para>
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>. 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 then is <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
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></note>
</section>
<para>
To be written.
</para>
<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.
and works similarly to <varname>buildPerlPackage</varname>. (See
<xreflinkend="sec-language-perl"/> for details.)
</para>
</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>.
@@ -871,8 +871,10 @@ Executing `python setup.py bdist_wheel` in a `nix-shell `fails with
```
ValueError: ZIP does not support timestamps before 1980
```
This is because files are included that depend on items in the Nix store which have a timestamp of, that is, it corresponds to January the 1st, 1970 at 00:00:00. And as the error informs you, ZIP does not support that.
The command `bdist_wheel` takes into account `SOURCE_DATE_EPOCH`, and `nix-shell` sets this to 1. By setting it to a value corresponding to 1980 or later, or by unsetting it, it is possible to build wheels.
This is because files from the Nix store (which have a timestamp of the UNIX epoch of January 1, 1970) are included in the .ZIP, but .ZIP archives follow the DOS convention of counting timestamps from 1980.
The command `bdist_wheel` reads the `SOURCE_DATE_EPOCH` environment variable, which `nix-shell` sets to 1. Unsetting this variable or giving it a value corresponding to 1980 or later enables building wheels.
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>
<para>
Qt is a comprehensive desktop and mobile application development toolkit for C++.
Legacy support is available for Qt 3 and Qt 4, but all current development uses Qt 5.
The Qt 5 packages in Nixpkgs are updated frequently to take advantage of new features,
but older versions are typically retained until their support window ends.
The most important consideration in packaging Qt-based software is ensuring that each package and all its dependencies use the same version of Qt 5;
this consideration motivates most of the tools described below.
</para>
<sectionxml:id="ssec-qt-libraries">
<title>Packaging Libraries for Nixpkgs</title>
<sectionxml:id="ssec-qt-libraries"><title>Packaging Libraries for Nixpkgs</title>
<para>
Whenever possible, libraries that use Qt 5 should be built with each
available version. Packages providing libraries should be added to the
top-level function <varname>mkLibsForQt5</varname>, which is used to build a
set of libraries for every Qt 5 version. A special
<varname>callPackage</varname> function is used in this scope to ensure that
the entire dependency tree uses the same Qt 5 version. Import dependencies
unqualified, i.e., <literal>qtbase</literal> not
<literal>qt5.qtbase</literal>. <emphasis>Do not</emphasis> import a package
set such as <literal>qt5</literal> or <literal>libsForQt5</literal>.
</para>
<para>
Whenever possible, libraries that use Qt 5 should be built with each available version.
Packages providing libraries should be added to the top-level function <varname>mkLibsForQt5</varname>,
which is used to build a set of libraries for every Qt 5 version.
A special <varname>callPackage</varname> function is used in this scope to ensure that the entire dependency tree uses the same Qt 5 version.
Import dependencies unqualified, i.e., <literal>qtbase</literal> not <literal>qt5.qtbase</literal>.
<emphasis>Do not</emphasis> import a package set such as <literal>qt5</literal> or <literal>libsForQt5</literal>.
</para>
<para>
If a library does not support a particular version of Qt 5, it is best to
mark it as broken by setting its <literal>meta.broken</literal> attribute. A
package may be marked broken for certain versions by testing the
<literal>qtbase.version</literal> attribute, which will always give the
current Qt 5 version.
</para>
</section>
<para>
If a library does not support a particular version of Qt 5, it is best to mark it as broken by setting its <literal>meta.broken</literal> attribute.
A package may be marked broken for certain versions by testing the <literal>qtbase.version</literal> attribute, which will always give the current Qt 5 version.
</para>
<sectionxml:id="ssec-qt-applications">
<title>Packaging Applications for Nixpkgs</title>
<para>
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>
<para>
Qt 5 maintains strict backward compatibility, so it is generally best to
build an application package against the latest version using the
<varname>libsForQt5</varname> library set. In case a package does not build
with the latest Qt version, it is possible to pick a set pinned to a
particular version, e.g. <varname>libsForQt55</varname> for Qt 5.5, if that
is the latest version the package supports. If a package must be pinned to
an older Qt version, be sure to file a bug upstream; because Qt is strictly
backwards-compatible, any incompatibility is by definition a bug in the
application.
</para>
<para>
When testing applications in Nixpkgs, it is a common practice to build the
package with <literal>nix-build</literal> and run it using the created
symbolic link. This will not work with Qt applications, however, because
they have many hard runtime requirements that can only be guaranteed if the
package is actually installed. To test a Qt application, install it with
<literal>nix-env</literal> or run it inside <literal>nix-shell</literal>.
</para>
</section>
</section>
<sectionxml:id="ssec-qt-applications"><title>Packaging Applications for Nixpkgs</title>
<para>
Call your application expression using <literal>libsForQt5.callPackage</literal> instead of <literal>callPackage</literal>.
Import dependencies unqualified, i.e., <literal>qtbase</literal> not <literal>qt5.qtbase</literal>.
<emphasis>Do not</emphasis> import a package set such as <literal>qt5</literal> or <literal>libsForQt5</literal>.
</para>
<para>
Qt 5 maintains strict backward compatibility, so it is generally best to build an application package against the latest version using the <varname>libsForQt5</varname> library set.
In case a package does not build with the latest Qt version, it is possible to pick a set pinned to a particular version, e.g. <varname>libsForQt55</varname> for Qt 5.5, if that is the latest version the package supports.
If a package must be pinned to an older Qt version, be sure to file a bug upstream;
because Qt is strictly backwards-compatible, any incompatibility is by definition a bug in the application.
</para>
<para>
When testing applications in Nixpkgs, it is a common practice to build the package with <literal>nix-build</literal> and run it using the created symbolic link.
This will not work with Qt applications, however, because they have many hard runtime requirements that can only be guaranteed if the package is actually installed.
To test a Qt application, install it with <literal>nix-env</literal> or run it inside <literal>nix-shell</literal>.
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>.
<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>.
<programlisting>
texlive.combine {
# inherit (texlive) whatever-you-want;
pkgFilter = pkg:
@@ -30,31 +45,47 @@ texlive.combine {
# there are also other attributes: version, name
}
</programlisting>
</para></listitem>
<listitem><para>
You can list packages e.g. by <command>nix-repl</command>.
<programlisting>
</para>
</listitem>
<listitem>
<para>
You can list packages e.g. by <command>nix-repl</command>.
<programlisting>
$ nix-repl
nix-repl> :l <nixpkgs>
nix-repl> texlive.collection-<TAB>
</programlisting>
</para></listitem>
</para>
</listitem>
</itemizedlist>
</section>
</section>
<section>
<title>Known problems</title>
<section><title>Known problems</title>
<itemizedlist>
<listitem><para>
Some tools are still missing, e.g. luajittex;</para></listitem>
<listitem><para>
some apps aren't packaged/tested yet (asymptote, biber, etc.);</para></listitem>
<listitem><para>
feature/bug: when a package is rejected by <varname>pkgFilter</varname>, its dependencies are still propagated;</para></listitem>
<listitem><para>
in case of any bugs or feature requests, file a github issue or better a pull request and /cc @vcunat.</para></listitem>
<listitem>
<para>
Some tools are still missing, e.g. luajittex;
</para>
</listitem>
<listitem>
<para>
some apps aren't packaged/tested yet (asymptote, biber, etc.);
</para>
</listitem>
<listitem>
<para>
feature/bug: when a package is rejected by <varname>pkgFilter</varname>,
its dependencies are still propagated;
</para>
</listitem>
<listitem>
<para>
in case of any bugs or feature requests, file a github issue or better a
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>
<section><title>Introduction</title>
<para>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.</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.</para></note>
</section>
<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.
</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.
</para>
</note>
</section>
<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:
</para>
<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:</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.</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.</para>
<para>TODO: more about tweaking the attribute, etc.</para></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.</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.</para></note>
</listitem>
<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.
</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.
</para>
<para>
TODO: more about tweaking the attribute, etc.
</para>
</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.
</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.
</para>
</note>
</listitem>
</itemizedlist>
</section>
</section>
<section>
<title>Using a split package</title>
<section><title>Using a split package</title>
<para>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>
</section>
<para>
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>
</section>
<section>
<title>Writing a split derivation</title>
<section><title>Writing a split derivation</title>
<para>Here you find how to write a derivation that produces multiple outputs.</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).</para>
<para>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. By convention, the first output should contain the executable programs provided by the package as that output is used by Nix in string conversions, allowing references to binaries like <literal>${pkgs.perl}/bin/perl</literal> to always work. Typically you also want to have the main <varname>out</varname> output, as it catches any files that didn't get elsewhere.</para>
<para>
Here you find how to write a derivation that produces multiple outputs.
</para>
<note><para>There is a special handling of the <varname>debug</varname> output, described at <xreflinkend="stdenv-separateDebugInfo"/>.</para></note>
<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
<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.</para>
<variablelist>
<title>File type groups</title>
<varlistentry><term><varname>
$outputDev</varname></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.
</para></listitem>
</varlistentry>
<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.
</para>
<varlistentry><term><varname>
$outputBin</varname></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.
</para></listitem></varlistentry>
<varlistentry><term><varname>
$outputLib</varname></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.
</para></listitem></varlistentry>
<varlistentry><term><varname>
$outputDoc</varname></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.
</para></listitem></varlistentry>
<varlistentry><term><varname>
$outputDevdoc</varname></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.
</para></listitem></varlistentry>
<varlistentry><term><varname>
$outputMan</varname></term><listitem><para>
is for man pages (except for section 3). They go to <varname>man</varname> or <varname>$outputBin</varname> by default.
</para></listitem></varlistentry>
<varlistentry><term><varname>
$outputDevman</varname></term><listitem><para>
is for section 3 man pages. They go to <varname>devman</varname> or <varname>$outputMan</varname> by default.
</para></listitem></varlistentry>
<varlistentry><term><varname>
$outputInfo</varname></term><listitem><para>
is for info pages. They go to <varname>info</varname> or <varname>$outputBin</varname> by default.
</para></listitem></varlistentry>
</variablelist>
<variablelist>
<varlistentry>
<term>
<varname> $outputDev</varname>
</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.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<varname> $outputBin</varname>
</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.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<varname> $outputLib</varname>
</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.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<varname> $outputDoc</varname>
</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.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<varname> $outputDevdoc</varname>
</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.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<varname> $outputMan</varname>
</term>
<listitem>
<para>
is for man pages (except for section 3). They go to
<varname>man</varname> or <varname>$outputBin</varname> by default.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<varname> $outputDevman</varname>
</term>
<listitem>
<para>
is for section 3 man pages. They go to <varname>devman</varname> or
<varname>$outputMan</varname> by default.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<varname> $outputInfo</varname>
</term>
<listitem>
<para>
is for info pages. They go to <varname>info</varname> or
<varname>$outputBin</varname> by default.
</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<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>.</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.)</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.</para></listitem>
<listitem><para>Some packages have hidden assumptions on install paths, which complicates splitting.</para></listitem>
</itemizedlist>
<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>.
</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.)
</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.
</para>
</listitem>
<listitem>
<para>
Some packages have hidden assumptions on install paths, which complicates
<para>Read <linkxlink:href="https://nixos.org/nixpkgs/manual/">Manual (How to write packages for Nix)</link>.</para>
</listitem>
<listitem>
<para>Fork the repository on GitHub.</para>
</listitem>
<listitem>
<para>Create a branch for your future fix.
<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.
<itemizedlist>
<listitem>
<para>For example: <command>nixos-version</command> returns <command>15.05.git.0998212 (Dingo)</command>. So you can do:</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para>
Read <linkxlink:href="https://nixos.org/nixpkgs/manual/">Manual (How to
write packages for Nix)</link>.
</para>
</listitem>
<listitem>
<para>
Fork the repository on GitHub.
</para>
</listitem>
<listitem>
<para>
Create a branch for your future fix.
<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.
<itemizedlist>
<listitem>
<para>
For example: <command>nixos-version</command> returns
<command>15.05.git.0998212 (Dingo)</command>. So you can do:
</para>
</listitem>
</itemizedlist>
<screen>
$ git checkout 0998212
$ git checkout -b 'fix/pkg-name-update'
</screen>
</para>
</listitem>
<listitem>
<para>Please avoid working directly on the <command>master</command> branch.</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>Make commits of logical units.
<itemizedlist>
<listitem>
<para>If you removed pkgs, made some major NixOS changes etc., write about them in <command>nixos/doc/manual/release-notes/rl-unstable.xml</command>.</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>Check for unnecessary whitespace with <command>git diff --check</command> before committing.</para>
</listitem>
<listitem>
<para>Format the commit in a following way:</para>
</para>
</listitem>
<listitem>
<para>
Please avoid working directly on the <command>master</command> branch.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
Make commits of logical units.
<itemizedlist>
<listitem>
<para>
If you removed pkgs, made some major NixOS changes etc., write about
<command>nix-env -i pkg-name -f <path to your local nixpkgs folder></command>
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>add pkg ->
<itemizedlist>
<listitem>
<para>Make sure it's in <command>pkgs/top-level/all-packages.nix</command>
</para>
</listitem>
<listitem>
<para>
<command>nix-env -i pkg-name -f <path to your local nixpkgs folder></command>
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
<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>.</para>
</listitem>
</itemizedlist>
</para>
</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.</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>NixOS and its modules:
<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>.</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</itemizedlist>
</para>
</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>.</para>
</listitem>
<listitem>
<para>Rebase you branch against current <command>master</command>.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Submitting changes</title>
<itemizedlist>
<listitem>
<para>Push your changes to your fork of nixpkgs.</para>
</listitem>
<listitem>
<para>Create pull request:
<itemizedlist>
<listitem>
<para>Write the title in format <command>(pkg-name | nixos/<module>): improvement</command>.
<itemizedlist>
<listitem>
<para>If you update the pkg, write versions <command>from -> to</command>.</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>Write in comment if you have tested your patch. Do not rely much on <command>TravisCI</command>.</para>
</listitem>
<listitem>
<para>If you make an improvement, write about your motivation.</para>
</listitem>
<listitem>
<para>Notify maintainers of the package. For example add to the message: <command>cc @jagajaga @domenkozar</command>.</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</itemizedlist>
</section>
<section>
<itemizedlist>
<listitem>
<para>
Push your changes to your fork of nixpkgs.
</para>
</listitem>
<listitem>
<para>
Create pull request:
<itemizedlist>
<listitem>
<para>
Write the title in format <command>(pkg-name | nixos/<module>):
improvement</command>.
<itemizedlist>
<listitem>
<para>
If you update the pkg, write versions <command>from -> to</command>.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
Write in comment if you have tested your patch. Do not rely much on
<command>TravisCI</command>.
</para>
</listitem>
<listitem>
<para>
If you make an improvement, write about your motivation.
</para>
</listitem>
<listitem>
<para>
Notify maintainers of the package. For example add to the message:
<command>cc @jagajaga @domenkozar</command>.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Pull Request Template</title>
<para>
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:
<para>
When a PR is created, it will be pre-populated with some checkboxes detailed
below:
</para>
<section>
<title>Tested using sandboxing</title>
<para>
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
<title>Tested using sandboxing</title>
<para>
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
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.
</para>
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.
</para>
</section>
</section>
<section>
<title>Hotfixing pull requests</title>
<itemizedlist>
<listitem>
<para>Make the appropriate changes in you branch.</para>
</listitem>
<listitem>
<para>Don't create additional commits, do
<itemizedlist>
<listitem>
<para><command>git rebase -i</command></para>
</listitem>
<listitem>
<para>
<command>git push --force</command> to your branch.</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Commit policy</title>
<itemizedlist>
<listitem>
<para>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.</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.</para>
</listitem>
</itemizedlist>
<section>
<title>Master branch</title>
</section>
<section>
<title>Hotfixing pull requests</title>
<itemizedlist>
<listitem>
<para>
It should only see non-breaking commits that do not cause mass rebuilds.
</para>
</listitem>
<listitem>
<para>
Make the appropriate changes in you branch.
</para>
</listitem>
<listitem>
<para>
Don't create additional commits, do
<itemizedlist>
<listitem>
<para>
<command>git rebase -i</command>
</para>
</listitem>
<listitem>
<para>
<command>git push --force</command> to your branch.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Staging branch</title>
</section>
<section>
<title>Commit policy</title>
<itemizedlist>
<listitem>
<para>
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.
<para>You can override the Linux kernel and associated packages using
the option <option>boot.kernelPackages</option>. For instance, this
selects the Linux 3.10 kernel:
<title>Linux Kernel</title>
<para>
You can override the Linux kernel and associated packages using the option
<option>boot.kernelPackages</option>. For instance, this selects the Linux
3.10 kernel:
<programlisting>
boot.kernelPackages = pkgs.linuxPackages_3_10;
</programlisting>
Note that this not only replaces the kernel, but also packages that
are specific to the kernel version, such as the NVIDIA video drivers.
This ensures that driver packages are consistent with the
kernel.</para>
<para>The default Linux kernel configuration should be fine for most users. You can see the configuration of your current kernel with the following command:
Note that this not only replaces the kernel, but also packages that are
specific to the kernel version, such as the NVIDIA video drivers. This
ensures that driver packages are consistent with the kernel.
</para>
<para>
The default Linux kernel configuration should be fine for most users. You can
see the configuration of your current kernel with the following command:
<programlisting>
zcat /proc/config.gz
</programlisting>
If you want to change the kernel configuration, you can use the
<entry>A string containing an expression (expands to <literal>"/nix/store/<replaceable>hash</replaceable>-bash-<replaceable>version</replaceable>/bin/sh"</literal>)</entry>
<entry>A string containing an expression (expands to <literal>"/nix/store/<replaceable>hash</replaceable>-bash-<replaceable>version</replaceable>/bin/sh"</literal>)</entry>
<filename>/etc/systemd/system</filename> since those take precedence over
<filename>/run/systemd/system</filename>. That’s why the unit is
installed as <filename>tmp-httpd.service</filename> here.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</varlistentry>
</variablelist>
</para>
</chapter>
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.
