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)
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 #41750
(cherry picked from commit 627444cfc2)
The use of this function is disallowed in nixpkgs, and purely there for
the convenience of downstream users. This improves closure size without
any loss of functionality.
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.
(cherry picked from commit 7979cb54e6)
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
(cherry picked from commit 8ae91ea6a3)
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.
(cherry picked from commit ce86b8f1b4)
This makes the startup wrapper work as intended instead of
re-downgrading Dropbox after each time it updates itself.
(cherry picked from commit 7a9784c571)
also re-enable for continuity on stable branch. this (perhaps final) release
should at least *work* with the rest of release-17.09 but will probably
see no further development and should remain "dropped" in master.
This passes the correct compilation flags to the builder so we pick up
the path to sqlite, and (despite the fact that it's a development
version), also updates to version 1.55_07 to fix
https://github.com/DBD-SQLite/DBD-SQLite/issues/28
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.
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)
I originally wrote this for packaging proprietary games in Vuizvui[1]
but I thought it would be generally useful as we have a fair amount of
proprietary software lurking around in nixpkgs, which are a bit tedious
to maintain, especially when the library dependencies change after an
update.
So this setup hook searches for all ELF executables and libraries in the
resulting output paths after install phase and uses patchelf to set the
RPATH and interpreter according to what dependencies are available
inside the builder.
For example consider something like this:
stdenv.mkDerivation {
...
nativeBuildInputs = [ autoPatchelfHook ];
buildInputs = [ mesa zlib ];
...
}
Whenever for example an executable requires mesa or zlib, the RPATH will
automatically be set to the lib dir of the corresponding dependency.
If the library dependency is required at runtime, an attribute called
runtimeDependencies can be used to list dependencies that are added to
all executables that are discovered unconditionally.
Beside this, it also makes initial packaging of proprietary software
easier, because one no longer has to manually figure out the
dependencies in the first place.
[1]: https://github.com/openlab-aux/vuizvui
Signed-off-by: aszlig <aszlig@nix.build>
Closes: #34506
(cherry picked from commit 1cba74dfc1)
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)
Pass the -L flag to curl to make it follow redirects. This fixes an
issue I found when setting up reverse proxy for Jenkins. Without this
fix, the returned HTTP code was stuck at 302, making postStart fail the
service (it expects 200 or 403).
(cherry picked from commit 5de8f99f03)
This solves the `Cannot access native keychain` warning from
IntelliJ-based IDEs. Previously IDEA was unable to find `libsecret` as
it was not part of its library path.
Please keep in mind that the keyring daemon that can be enabled on
NixOS with `services.gnome3.gnome-keyring.enable = true` must be
running.
(cherry picked from commit a38466a340)
Cabal 1.x says:
| Warning: This package indirectly depends on multiple versions of the same
| package. This is highly likely to cause a compile failure.
But in version 2.x, that warning is split into two lines differently:
| Warning:
| This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
This commit modifies the call to "egrep" to recognize both versions by virtue
of the "-z" flag, which essentially interprets the whole configure-time output
as one long line.
(cherry picked from commit 016aa581a7)
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)
As per #30645, fish with fish-foreign-env prints this
(harmless) warning:
```
set: Tried to change the read-only variable “_”
```
This patch was developed by @rnhmjoj in the aforementioned
issue discussion
(cherry picked from commit edfdc1d818)
* The environment variables NIX_CONF_DIR, NIX_BUILD_HOOK and
NIX_REMOTE are no longer needed.
* A /bin/sh (from busybox) is provided by default in sandboxes.
* Various options were renamed.
(cherry picked from commit 700e21d6da)
Also remove myself from meta.maintainers,
as I can't really give them too much maintenance.
(cherry picked from commit 655446c7f5)
I see some security fixes in the ChangeLog.
This fixes choppy audio in WebRTC. Firefox's closure already includes
libpulseaudio anyway, so this shouldn't affect closure size either.
(cherry picked from commit de5bbd0a73)
[806388] High CVE-2018-6056: Incorrect derived class instantiation in V8. Reported by lokihardt of Google Project Zero on 2018-01-26
(cherry picked from commit 0d20bf0287)
A CACHEDIR.TAG file indicates that the contents can be automatically
re-generated. This is not really true for Nix store paths. (Well _Nix_
can recreate them, but that's different.)
I noticed this issue as I was restoring full system backup that "for
some reason" always missed /nix/store/*-fc-cache (found by `nix-store
--verify --repair`). Turns out I was excluding caches from my backup...
(cherry picked from commit 8ea7a302bd)
See https://github.com/NixOS/nixpkgs/issues/34383
On master the expressions have changed nontrivially,
so it's going to be separately done work.
(And we expect gcc7 by default for every package on master soon.)
As stated by Sylvestre Ledru (@sylvestre) on Nov 22, 2017 at
https://github.com/NixOS/nixpkgs/issues/31843#issuecomment-346372756 we
have permission to use the official firefox branding.
Fur purposes of documentation the statement of @sylvestre:
> As the person who did part of the work described in the LWN article
> and release manager working for Mozilla, I can confirm the statement
> that I made in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006
>
> @garbas shared with me the list of patches applied for the Nix package.
> As they are just for portability and tiny modifications, they don't
> alter the experience of the product. In parallel, Rok also shared the
> build options. They seem good (even if I cannot judge the quality of the
> packaging of the underlying dependencies like sqlite, png, etc).
> Therefor, as long as you keep the patch queue sane and you don't alter
> the experience of Firefox users, you won't have any issues using the
> official branding.
(cherry picked from commit ce08581088 &
discussed at https://github.com/NixOS/nixpkgs/issues/31843#issuecomment-364681920)
If you have more than 1 User with hasedPassword Option set it generates
```
rm -f /var/lib/mosquitto/passwd
touch /var/lib/mosquitto/passwd
echo 'user1:$6$xxx' > /var/lib/mosquitto/passwd
echo 'user2:$6$xxx' > /var/lib/mosquitto/passwd
```
Which ends up in only having 1 user.
fixes#34804
(cherry picked from commit 7e76b127cd)
Update to latest stable version from the 5.1 branch. Also fixes
compilation of the host driver on 4.15.
Changelog:
* GUI: mouse events did not reach host windows behind the transparent VM window (Mac OS X hosts only; bug #16246)
* Audio: fixed accidental crashes when using the AC'97 sound emulation (bug #16959)
* Audio: fixed crash when default input or output devices have changed (bugs #16968, #16969, #17004)
* Audio: fixed recording when using the ALSA backend
* Audio: fixed handle leak when using the OSS backend
* E1000: fixed a crash related to VLAN traffic over internal network (5.1.26 regression; bug #16960)
* NAT: apply --natbindip1 to TCP connections (bug #16478)
* OVF: when importing an appliance with XHCI controller, don't add an OHCI controller.
* Mac OS X hosts: fixed a GUI crash if Spotlight is used from file dialogs (5.1.20 regression; bugs #16935, #16953)
* Linux hosts: fixed creating fixed sized VDI images (bug #17010)
* Linux hosts / guests: fixes for Linux 4.4 of openSUSE Leap 42.3 (bug #16966)
* Bridged networking: align outgoing packet at word boundary, preventing Windows host crash in MsLbfoProvider.
* Linux Additions: kernel drm driver support for custom EL7 Linux 3.10 kernel
* Solaris Additions: hide an informational message on the bootup console
* GUI: translation updates
* GUI: Fixed double mouse cursor when using mouse integration without Guest Additions, actually a Qt 5.6 bug fixed with QT 5.6.3 (Mac OS X hosts only; bug #15610)
* Solaris hosts: allow increasing MTU size for host-only adapter to 9706 bytes to support jumbo frames
* Linux hosts: glibc 2.26 compile fix
* Windows Additions: 3D related crash fix (bugs #17082, #17092)
* GUI: fixed occasional screen corruption when host screen resolution is changed
* User interface: increase proposed disk size when creating new VMs for Windows 7 and newer
* Serial: fixed broken communication with certain devices on Linux hosts
* VMM: Fixed problems using 256MB VRAM in raw-mode VMs
* Audio: added HDA support for more exotic guests (e.g. Haiku)
* Audio: fixed playback with ALSA backend (5.1.28 regression)
* USB/OHCI: fixed a problem where OHCI emulation might sporadically drop data transfers
* Windows hosts: VirtualBoxManager in the Python API no longer calls CoUninitialize when destroyed
* Linux hosts: fixed VBoxNetFlt kernel module compilation failure with Linux kernel 4.14
* Linux guests: fixed kernel module compilation and other problems with Linux kernel 4.14
Upstream killed the pkgs server but src continues to serve up the exact
same content, so we can just point there and all hashes should be unchanged.
(morally a cherry-pick of dfd300c81d)
Since firefox 58.0.1 the google api key is now stored at an absolute
path ($TMPDIR/ga). Since variable expansion in `configureFlags` does not
really work (as expected) the build started failing when using the
legacy firefox build system. With the newer `./mach` based builds
firefox reads the configure flags from `.mozconfig` instead.
This commit moves the `with-google-api-keyfile=` setting into the
`preConfigure` phase where we can properly expand `$TMPDIR` into
whatever the path is.
(cherry picked from commit 42b9b8f7c8)
Various bugfixes and minor changes:
- doveadm: Fix crash in proxying (or dsync replication) if remote is
running older than v2.2.33
- auth: Fix memory leak in %{ldap_dn}
- dict-sql: Fix data types to work correctly with Cassandra
- dovecot-lda was logging to stderr instead of to the log file.
* doveadm director commands wait for the changes to be visible in the
whole ring before they return. This is especially useful in testing.
* Environments listed in import_environment setting are now set or
preserved when executing standalone commands (e.g. doveadm)
+ doveadm proxy: Support proxying logs. Previously the logs were
visible only in the backend's logs.
+ Added %{if}, see https://wiki2.dovecot.org/Variables#Conditionals
+ Added a new notify_status plugin, which can be used to update dict
with current status of a mailbox when it changes. See
https://wiki2.dovecot.org/Plugins/NotifyStatus
+ Mailbox list index can be disabled for a namespace by appending
":LISTINDEX=" to location setting.
+ dsync/imapc: Added dsync_hashed_headers setting to specify which
headers are used to match emails.
+ pop3-migration: Add pop3_migration_ignore_extra_uidls=yes to ignore
mails that are visible in POP3 but not IMAP. This could happen if
new mails were delivered during the migration run.
+ pop3-migration: Further improvements to help with Zimbra
+ pop3-migration: Cache POP3 UIDLs in imapc's dovecot.index.cache
if indexes are enabled. These are used to optimize incremental syncs.
+ cassandra, dict-sql: Use prepared statements if protocol version>3.
+ auth: Added %{ldap_dn} variable for passdb/userdb ldap
- acl: The "create" (k) permission in global acl-file was sometimes
ignored, allowing users to create mailboxes when they shouldn't have.
- sdbox: Mails were always opened when expunging, unless
mail_attachment_fs was explicitly set to empty.
- lmtp/doveadm proxy: hostip passdb field was ignored, which caused
unnecessary DNS lookups if host field wasn't an IP
- lmtp proxy: Fix crash when receiving unexpected reply in RCPT TO
- quota_clone: Update also when quota is unlimited (broken in v2.2.31)
- mbox, zlib: Fix assert-crash when accessing compressed mbox
- doveadm director kick -f parameter didn't work
- doveadm director flush <host> resulted flushing all hosts, if <host>
wasn't an IP address.
- director: Various fixes to handling backend/director changes at
abnormal times, especially while ring was unsynced. These could have
resulted in crashes, non-optimal behavior or ignoring some of the
changes.
- director: Use less CPU in imap-login processes when moving/kicking
many users.
- lmtp: Session IDs were duplicated/confusing with multiple RCPT TOs
when lmtp_rcpt_check_quota=yes
- doveadm sync -1 fails when local mailboxes exist that do not exist
remotely. This commonly happened when lazy_expunge mailbox was
autocreated when incremental sync expunged mails.
- pop3: rawlog_dir setting didn't work
We had problems to get borg's own test suite running.
This test is intended to perform a quick smoke test to see whether we
have missed not any important dependency necessary to create backups
with borg.
tested with:
$ nix-build nixos/release.nix -A tests.borgbackup.x86_64-linux
(cherry picked from commit 8a5f77ffbc)
The unnecessary dependency of sockets.target on kresd.service causes a
dependency cycle preventing kresd.service from starting at boot:
sockets.target -> kresd.service -> basic.target -> sockets.target
(cherry picked from commit f19d959ef1)
Release tarballs are deleted after a new release.
(cherry picked from commit f833dd7067)
This cherry-pick also syncs imagemagick with the version on master. The
change to github was not previously cherry-picked and lead to hash
mismatches.
See #32386 -- while Mono in general should build correctly with parallel
building, it seems the 4.4 branch has broken.
Instead, allow parallel build support to be overridden by individual
versions, and default to true.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
(cherry picked from commit 90bcfc78c3)
The CVE patches weren't previously applied because they depend on the
enableCopyDevicesPatch parameter. The naming of the patches attribute in
base.nix was misleading.
The new rsync release now really fixes:
* CVE-2017-15994
* CVE-2017-16548
* CVE-2017-17433
* CVE-2017-17434
(cherry picked from commit 57ecb3a8f0)
* maintainers: add flokli
* sphinx_guzzle_theme: init at 0.7.11
This adds sphinx_guzzle_theme, which is used for sphinx documentation in
various projects, including BorgBackup.
(cherry picked from commit ab2cc75f78)
this introduces a standard approach to playing with patches from the
gentoo repository.
the patches for 64 are a first guess during a build in progress
cc @YorikSar @aszlig
(cherry picked from commit dbb774c5e1)
... after applying glibc patches.
It's not clear (yet) why this older rustc (test) got broken.
Newer rustc (used for Firefox) has the very same test that still passes.
Somewhat amusingly given its name, "clang.patch" applies to both 5 and 6
but is the cause of ncurses6 breakage on 6 but is required on 5...
gcc is happy in all four configurations:
5 5p 6 6p
gcc ✓ ✓ ✓ ✓
clang ✗ ✓ ✓ ✗
Which is why this commit enables the patch for 5 but not 6;
this matches behavior in Gentoo, for example.
For further simplification, we also use gcc-5 patch regardless.
(cherry picked from commit 96f0d3b908)
- The package does not seem to function with `pypy` (#33997)
- Our default interpreter should be used. If one wants extra performance
(e.g. using PyPy) they can override or modify the expression however
they want, but not in Nixpkgs.
(cherry picked from commit fbaf5fd677)
This change is backwards compatible since the ELK tools at version 5.x
remain unchanged.
The test suite now both tests ELK-5 and ELK-6.
(cherry picked from commit 803077ef1c)
Darwin requires dependency on MacPasteboard
The test runs successfully when executed interactively from a nix-shell.
Disable doCheck as paste pasteboard is not accessible in (non-interactive) nix-build.
(cherry picked from commit 9e2e219608)
This potentially addresses CVE-2017-1000494.
Changes since last version bump:
2017/12/11:
Fix buffer over run in minixml.c
Fix uninitialized variable access in upnpreplyparse.c
(cherry picked from commit 761ed40c5c)
changelog since the last version bump:
2017/12/12:
Fix a few buffer overrun in SSDP and SOAP parsing
2017/11/02:
PCP : reset epoch after address change
2017/05/26:
merge https://github.com/miniupnp/miniupnp/tree/randomize_url branch
2017/05/24:
get SSDP packet receiving interface index and use it to check if the
packet is from a LAN
2017/03/13:
default to client address for AddPortMapping when <NewInternalClient>
is empty
pass ext_if_name to add_pinhole()
2016/12/23:
Fix UDA-1.2.10 Man header empty or invalid
2016/12/16:
Do not try to open IPv6 sockets once it is disabled
2016/12/01:
Fix "AddPinhole Twice" test
2016/11/11:
fixes build for Solaris/SunOS
2016/07/23:
fixes build error on DragonFly BSD
(cherry picked from commit addf1d5da3)
gcc provides wrappers for binutils' ar, nm and ranlib
executables, which must be used instead when using link-time
optimisation. See also:
http://manpages.ubuntu.com/manpages/zesty/man1/aarch64-linux-gnu-gcc-ar-5.1.html
The upstream version of avr-gcc-ar searches in paths passed to
the configure script for the avr-ar binary that it wraps, falling
back to searching PATH instead. Thus currently avr-gcc-ar works on
Nix, but only if avrbinutils is already in the environment.
This change bakes the path to avr-ar into avr-gcc-ar, since its path
is known at compile time. It also no longer searches PATH, meaning the
user's local environment won't override this path.
Note that avr-gcc-nm and avr-gcc-ranlib are compiled from the same
source file as avr-gcc-ar, just with different compiler flags.
Testing on master (without avrbinutils in the environment):
$ nix-build -A avrgcc
$ result/bin/avr-gcc-ar --version
result/bin/avr-gcc-ar: Cannot find binary 'avr-ar'
Testing on branch with this fix:
$ nix-build -A avrgcc
$ result/bin/avr-gcc-ar --version
GNU ar (GNU Binutils) 2.26.20160125
...
(cherry picked from commit 6bfa42218d)
This commit adds the CentOS 7.4 base image from the CentOS mirror, for use with
building RPMs or evaluating Nix expressions in a CentOS image.
When CentOS 7.5 comes out, I will swap this URL to the permanently vaulted image.
(cherry picked from commit b1ec502c1e)
This commit adds the CentOS 7.3 base image from the CentOS vault, for use with
building RPMs or evaluating Nix expressions.
(cherry picked from commit 368432e17f)
Few things:
* Discord binary has RUNPATH not RPATH set
* patchelf uses RUNPATH if it already exits, so deps end up in RUNPATH
* RUNPATH isn't searched for plugins or transitive deps
* ..badness results
Despite this, it currently seems to work-- with the caveat
that it has a little bar on top complaining about how
"it looks like your installation is corrupt".
This fixes that warning and does some minor cleanup.
(cherry picked from commit 8753b10808)
Fix a vulnerability caused by Cross-Origin Resource Sharing (CORS)
in the JSONRPC interface. Previous versions of Electrum are
vulnerable to port scanning and deanonimization attacks from
malicious websites. Wallets that are not password-protected are
vulnerable to theft.
(cherry picked from commit 34c776eaa1)
Recently, the postgres superuser name has changed. Using the configured
and correct username here fixes database initialisation.
(cherry picked from commit aeeac71231)
From the release notes [1]:
* Fix a vulnerability caused by Cross-Origin Resource Sharing (CORS)
in the JSONRPC interface. Previous versions of Electrum are
vulnerable to port scanning and deanonimization attacks from
malicious websites. Wallets that are not password-protected are
vulnerable to theft.
See this [2] for explanation.
[1] https://github.com/spesmilo/electrum/blob/3.0.4/RELEASE-NOTES
[2] https://github.com/spesmilo/electrum/issues/3374
(cherry picked from commit 207bf49c8d)
Note that due to runtime impurities, non-NixOS users must prepend and export
QT_PLUGIN_PATH=${qt5.qtbase.qtPluginPrefix}
and
LD_LIBRARY_PATH=/run/opengl-driver/lib
before running electrum, lest it fail to find runtime dependencies or pick
up mismatching libraries from the host system.
(cherry picked from commit 97ab2f0d8b)
Plotting seems to be a core feature now, with a menu entry available by
default. Without the matplotlib dependency this opens a warning popup
though.
(cherry picked from commit 89dc04fe93)
This fork of jsonrpclib supports Python 3 and is necessary for electrum
from version 3.0.0 onwards.
Adding myself - moredread - as maintainer.
(cherry picked from commit ab447d9d76)
- Java 9 (JDK) is now supported
- Data Guard in DBA panel is only available for 12c and higher connections
- Updated the NoSQL drivers to version 4.5
- Added support for defining consumer group mappings for CLIENT_ID
- Preferences Search feature now covers all options
- Differentiate between a temporary connection used in the unshared worksheet and a truly private connection used internally for things like the UT Repos or the Instance Viewer....the naming logic for the Unshared Worksheet is now 'MyConn (Unshared)' instead of 'MyConn__1'
- RAC support added to Real Time SQL Monitoring
(cherry picked from commit ad87adfe96)
Support is perhaps claimed upstream, but it's never built successfully
on Hydra, so let's disable that until someone fixes it.
(cherry picked from commit 616048bcbf)
In this expression the boolean flags `buildUser` and `buildKernel` determine
if either userspace tools or the kernel module is being built.
cc #33166
(cherry picked from commit 6b74d2ca07)
[...]
make modules -C /nix/store/h1vzl6bq4wif3m8dd1bw2p3fv4shjg3n-linux-4.14.9-dev/lib/modules/4.14.9/build EXTRA_CFLAGS=-Werror-implicit-function-declaration M=/tmp/nix-build-spl-kernel-2017-11-16-4.14.9.drv-0/source/build
/nix/store/h1vzl6bq4wif3m8dd1bw2p3fv4shjg3n-linux-4.14.9-dev/lib/modules/4.14.9/source/Makefile:939: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.
This patch introduces kernel.moduleBuildDependencies to avoid the logic "stdenv.lib.optional (stdenv.lib.versionAtLeast kernel.version "4.14") libelf" in multiple places.
[dezgeg did some minor tweaks on top]
(cherry picked from commit 1e77d0b975)
This makes the commonHook option work also for (read-only) Nix store
paths. Currently it fails on the second activation, because the
destination is read-only.
(cherry picked from commit 7c481aa7c1)
This reverts a part of commit 559433d0db.
The problem with removing those options completely is that without them
tor-browser's config differs from the official config (which may or may
not be a problem for fingerprinting).
(cherry picked from commit dd853e846c)
Nothing in Nixpkgs depends on pytestquickcheck, and @lsix says that the old
version is not compatible with the current pytest in the release branch.
Users were confused that the error message said config.networking.hostId, and indeed that did nothing to fix their problem.
Update the error message to specify the option they should actually set.
(cherry picked from commit 9f31fe81aa)
Updated in master in 7ce848309eFixes#32797
Changelog:
* Fix crashes with Jinja2 themes and tag indexes
* Ignore empty tags in HTML metadata reader
* Fix crash when compiling empty ``.html`` posts
I think the current one applies the -exec only to those that match
'-type d'. Let's switch it to something that humans can understand...
(cherry picked from commit 758b4c1ea4)
(Yes it should use 'find -print0 | xargs -0' but I'm really afraid of
screwing up again in the same way. Nix doesn't allow spaces and/or
newlines in store paths anyway and it has -maxdepth 1 -mindepth 1 so it
won't fail in practice. If someone can provide a *tested* that doesn't
suffer from the same problems, feel free to improve.)
Without this, when you've enabled networkmanager and start a
nixos-container the container will briefly have its specified IP
address but then networkmanager starts managing it causing the IP
address to be dropped.
(cherry picked from commit 5572de75a0)
Fakeroot seems to always give the owner write bit to any files touched
inside it (presumably to easily simulate the fact that root can still
modify such files). So do an explicit chmod to remove them.
This should finally solve #32242 after the EC2 images are regenerated
with this change.
https://hydra.nixos.org/build/66143116
(cherry picked from commit c9f71974f8)
(cherry picked from commit 875eaf0821)
This is necessary for nixos-rebuild running on NixOS with Nix 1.12pre to be able
to build NixOS with Nix 1.11: otherwise the rebuild fails right after building
Nix 1.11 with "Unexpected EOF reading a line"
See also https://github.com/NixOS/nix/issues/1740
They aren't meant to be critical (uncatchable) errors.
Tested with nix-env + checkMeta:
[ "x86_64-linux" "i686-linux" "x86_64-darwin" "aarch64-linux" ]
(cherry picked from commit 3a110ea3f9)
- tracing seems annoying enough
- we get errors for all packages instead of aborting on the first one
- easier to differentiate from unwanted packages (broken, unfree, etc.)
(cherry picked from commit 76bf375a16)
This is done by adding two patches, one is the complete patch containing
the upstream fixes for version 5.2.2 backported against version 5.1.26.
The other one is basically the same patch, but only the relevant changes
for the guest additions and the hunks changed to use CR/LF instead of LF
line endings.
Both patches are based on [r62611], however the revision turned out to
not be the right one corresponding to the tarball, so instead of
rebasing the patch again I looked at the conflicts and the changes that
have been introduced in [r64183] was the reason for the conflict.
So I manually edited the second hunk for vbox_drv.c and dropped the
first three lines of context (those declaring the "i" variable). The
hunk still is distinct enough (not even another "vgacon_text_force" in
the source) so we shouldn't run into weird conflicts if we'd bump
VirtualBox to version 5.1.30.
While we could have fixed this by just updating VirtualBox to version
5.2.2, this would be a bit too intrusive (like @vcunat mentioned in
https://github.com/NixOS/nixpkgs/pull/31037#issuecomment-350556636), not
only in our ecosystem but because version 5.2 has some known upstream
issues that are not resolved yet.
Quoting from https://www.virtualbox.org/wiki/Downloads:
Note: (updated 8 December 2017) The Guest Additions image with the
5.2.2 release still has some known problems with certain Linux
distributions when 3D acceleration is enabled.
I have tested this change by running all the tests in the "virtualbox"
NixOS VM test against basically all of the kernel versions we ship
except linux-testing (4.15-rc1) and specialized versions. So the
specific linuxPackages_* attributes I've tested were:
* linuxPackages_4_4 (failed, see below)
* linuxPackages_4_9
* linuxPackages_4_13
* linuxPackages_4_14
Running the tests for Linux 4.4 have failed because the KVM guest
machines couldn't be started and timed out. However after running the
tests with the same kernel but the nixpkgs revision prior to this
commit, the tests had the same issue, so the test failure is unrelated
to this commit.
[r62611]: https://www.virtualbox.org/changeset/62611/vbox
[r64183]: https://www.virtualbox.org/changeset/64183/vbox
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @svanderburg
Fixes: #32537
28299f669a introduced the first Python
packages having multiple outputs. The required outputs were not picked
up by `python.buildEnv` (#31857).
This commit modifies `python.buildEnv` so that it always includes the
$out output and thus fixes#31857.
(cherry picked from commit 163ba09117)
Many of the fixes seem to have potential to be vulnerabilities,
though most aren't labeled with a CVE number. /cc #32459
(cherry picked from commit 8f4f9b6223)
/cc #32459. I can't see any other CVE patches that are either
backported upstream to the 0.26 branch or applied in some distro.
(cherry picked from commit 332a800de3)
There are also non-security changes in the releases. /cc #32459.
Printing test OK, and I tested work with some postscript files.
I also fixed the license - it was changed in 2013 :-/
(cherry picked from commit ca6952fcb7)
extraMeta was being fed as passthru without being processed by stdenv,
so without those changes, adding the security attribute would be useless.
(cherry picked from commit 13797ff522)
I *suspect* that NV_VM_OPERATIONS_STRUCT_HAS_FAULT isn't detected
in our case for some reason, so this patch doesn't make a difference.
In any case, the patch seems unlikely to make anything worse.
(cherry picked from commit e9550f290c)
This now builds with kernel 4.13; Debian has only the typo patch there.
Curiously, .settings still fails to link on x86_64-linux but works
on i686-linux, just as with .135.
(cherry picked from commit 1e4d675c4e)
New features:
* Support for retrieving reverse PTRs.
* Support for subnet-ranges.
* Add logging (aszlig/hetzner#14).
Fixes:
* Hide internal methods from the public API.
* Fix Python 3 compatibility.
* Fix for creating admin accounts with Hetzner's new login site.
* Fix __repr__/__str__ issue with some exceptions (aszlig/hetzner#23).
* Fix login for RobotWebInterface
Changes for the hetznerctl utility:
* show: Show subnets
* show: Show reverse PTRs
* New 'rdns' subcommand for getting/setting/removing reverse-PTRs.
* Use 'argparse' instead of 'optparse'.
* Add command for managing admin accounts.
* New '--debug' flag for printing debugging information.
This also fixesNixOS/nixops#778.
Tested building against Python 2.7 and Python 3.6.
Signed-off-by: aszlig <aszlig@nix.build>
(cherry picked from commit 6841064ac5)
Reason: This unbreaks the NixOps Hetzner target, because the admin
sub-account couldn't be created on initial deploy.
Closes#32137
Conflicts:
pkgs/os-specific/linux/kernel/manual-config.nix
[dezgeg: I picked this because it contains the bits that will be needed
once 4.15 is out]
Simple daemon for keeping system timezone up-to-date via geoclue2.
Sadly i3 status needs to be restarted for timezone changes.
(cherry picked from commit d64ba1c060)
Signed-off-by: Domen Kožar <domen@dev.si>
There are basically no changes, but the version number is much nicer ;-)
Explicit deletion of gtk-goc isn't needed anymore (see doc/multiple-output.xml).
(cherry picked from commit 68bfcad289)
To sign in to dropbox, a browser must be available in the FHS env. We cannot
ensure that the user's browser of choice is available, so we provide Firefox as
a default.
Resolves: #31667
(cherry picked from commit 7dee7d6ddb)
Qt applications running in an FHS env need to have xkeyboardconfig installed for
keyboard input.
Resolves: #31741
(cherry picked from commit 18cc8d482d)
Fixes#32169: build with kernel 4.13.
Unfortunately, 4.13 is going away very soon and for 4.14 doesn't build.
I only tested building it, but these minor bumps should be safe.
(cherry picked from commit 2dfbc5f8ed)
The problem doesn't happen for me locally, but on Hydra
we tend to experience more flakiness in networking tests.
(cherry picked from commit fe83d91157)
- There used to be a conflict between gdm and getty both trying to
access tty1
- This conflict was fixed by running gdm on tty7 instead
(cherry picked from commit c46d4dab96)
OS X by default has a case-insensitive filesystem, and fetching
all-cabal-hashes there fails due to a hash mismatch caused by package
pairs like compactable and Compactable. This partitions the package set
such that each partition contains no equivalent-up-to-case pairs.
(cherry picked from commit 843e0992ca)
The munin-node service used wrapProgram to inject environment variables.
This doesn't work because munin plugins depend on argv[0], which is
overwritten when the executable is a script with a shebang line (example
below).
This commit removes the wrappers and instead passes the required
environment variables to munin-node.
Eliminating the wrappers resulted in some broken plugins, e.g., meminfo
and hddtemp_smartctl. That was fixed with the per-plugin configuration.
Example:
The plugin if_eth0 is a symlink to /.../plugins/if_, which uses $0
to determine that it should monitor traffic on the eth0 interface.
if_ is a wrapped program, and runs `exec -a "$0" .if_-wrapped`
.if_-wrapped has a "#!/nix/.../bash" line, which results in bash
changing $0, and as a result the plugin thinks my interface
is called "-wrapped".
(cherry picked from commit bd3e49a80e)
Add a new patch (adding_sconfdir_munin-node.patch) to be able to
configure the location of plugin-conf.d (otherwise it has to be
configured at build time). This patch is very similar to the
existing 'adding_servicedir_munin-node.patch'.
(cherry picked from commit a2dc37c7d1)
postage is no longer maintained and has been replaced by the identical
pgmanage. See:
https://github.com/workflowproducts/postage#postage-has-been-replaced-with-pgmanage
This patch introduces the new pgmanage package and module but leaves
the existing postage package and module intact so that we don't break
compatibility with existing 17.09 configurations.
We do emit a warning advising users to upgrade to pgmanage.
Note that in 18.03 enabling the 'services.postage.enable' option will
cause an assertion error to be thrown instructing users to change to
pgmanage.
Product renamed to match the name used on the Product website and inside
the update.xml used by the update script.
This also updated the version to 173.3727.79.
(cherry picked from commit b2b995f65a)
With this disabled, cameras would not get a `/dev/mediaX` entry matching
the `/dev/videoX` which broke any application (e.g: `uvcdynctrl -l`,
`media-ctl -p`) depending on this interface.
(cherry picked from commit 7cdd12e4e9)
The error got introduced by 4f3d971ef5,
which removed the *Text attributes from the option.
This in turn leads to an evaluation error while building the
manual/manpage, because oraclejre8 is marked unfree.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @jbgi, @orivej, @globin
(cherry picked from commit 0e790b9f66)
Only the Oracle JRE is supported by Atlassian appsAtlassian apps
(see https://jira.atlassian.com/browse/JRASERVER-46152)
Plus Atlassian apps are non free so the switch logic always chose
Oracle JRE anyway.
Option is kept in case someone want to patch apps to support openjdk.
(cherry picked from commit 4f3d971ef5)
ffmpeg is now built as a separate derivation using the kodi makefile to avoid
having to rebuild ffmpeg every time kodi is changed.
Additionally, due to the far superior cmake output a number of dependencies were
identified that have been added as well.
(cherry picked from commit 737558b7bb)
* Project is hosted on github.com.
* The -Wno-nonnull-compare fix is included in 0.9.7, so remove it from
this package expression.
(cherry picked from commit b06c5a678d)
Looking at upstream git repo (git://github.com/Yubico/pam-u2f.git) the
docs initially said the path was ~/.yubico/u2f_keys, but it was later
changed to ~/.config/Yubico/u2f_keys (in 2015).
I have run pam_u2f.so with "debug" option and observed that the correct
path indeed is ~/.config/Yubico/u2f_keys.
(cherry picked from commit 3f36f167e6)
Also fix numberous bugs, such as:
- Not getting confused on more flags taking file arguments.
- Ensuring children reexport their children, but the original
binary/library doesn't.
- Not spawning children when it turns out we just dynamically link
under the threshold but our total number of inputs exceeeds it.
- Children were always named `libunnamed-*`, when that name was
supposed to be the last resort only.
In addition to the script, we also patch ld-wrapper to respect `.dylib`
and `.so` alike. In a future version of nixpkgs, this can be so enabled
by defaut. Newer nixpkgs will probably do this by default.
- fetch with `fetchPypi`
- add license, description and myself as maintainer
(cherry picked from commit c122dadb51)
Also adds name attribute as the pname feature for python derivations was
introduced after 17.09.
This includes adding a new xcbuild-based libutil build to test the waters a bit there.
We'll need to get xcbuild into the stdenv bootstrap before we can make the main build,
but it's nice to see that it can work.
(cherry picked from commit e86991e1e8)
The llfuse package depends on fuse which refuses to build on darwin. But
according to a comment in the setup.py of borgbackup [1] it's ok to leave it out
if it's not available. Most of borgbackup should work without it. Would be great
to make it work on darwin but i am not sure if it's possible to get fuse to work
on darwin. I do not know enough about it ;)
After this modification at least the "borg mount" subcommand is broken due to
the missing llfuse module. But the rest seems to work normally.
[1] 72232a9bd5/setup.py (L32)
(cherry picked from commit 629e17b9fd)
The acl libraray is only required by the borgbackup package if building on a
linux platform. Adding it only in this case should be fine. Also see the
conditional in the setup.py at [1].
[1] 72232a9bd5/setup.py (L768)
(cherry picked from commit b159ed5069)
This reverts commit e9776f0446.
Firefox is part of the tested job, so this will block new channels
releases. A new channel release is needed for the ACME ToS hash fix.
(cherry picked from commit 78eaae0204)
Reason: Follow-up from 33f482e0ac, this
*actually* was the version I've been testing for two weeks.
Signed-off-by: aszlig <aszlig@nix.build>
This update contains a lot of fixes that are too much to be summarized
here, so here is the upstream changelog (basically "git log"):
https://github.com/vim/vim/commits/v8.0.1250
The main reason for this bump is that I got annoyed by a bug that was
fixed in upstream version 8.0.1194, which caused a race condition during
vim startup when it's trying to retrieve background colors from the
terminal.
Sometimes it could happen that random commands are executed at Vim
startup (typically pasting the "" buffer) and after bisecting I've found
out that version 8.0.1194 indeed fixed this problem.
The reason why I'm updating to version 8.0.1250 is that when looking
through the Git log it contains a whole lot of fixes but no new
features, so I'd assume it's safe to upgrade.
I've tested all packages that depend on Vim and they still succeed
building. In addition to that I've used the new version for a couple of
hours without any issue.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @lovek323, @LnL7, @vaibhavsagar
(cherry picked from commit 74260a4922)
Reason: The bug described above is no longer occuring and I've tested
this on a daily basis since two weeks.
- update and automate merging
The automated merging process should eliminate the need for keeping a
nixos-specific merged repository around
fixes#29806
(cherry picked from commit 8ba0b7bc3b)
fixes#31548
`nixos-option` evals the description and the '`' is used to
define shell commands.
Due to this, the following error appears:
```
$ nixos-option services.postgresql.superUser
Value:
"root"
Default:
"root"
Description:
/run/current-system/sw/bin/nixos-option: line 294: root: command not found
/run/current-system/sw/bin/nixos-option: line 294: postgres: command not found
NixOS traditionally used as superuser, most other distros use .
From 17.09 we also try to follow this standard. Internal since changing this value
would lead to breakage while setting up databases.
```
(cherry picked from commit 82062f7080)
Merge pull request #31526 from srhb/fix-php-external-pcre
Since #30963 (bbb6ca75da on release-17.09) regex
subgroup matches in mod_php were returning incorrect results due to symbol
conflicts between system pcre used by Apache and pcre build into php.
(cherry picked from commit b62ad4f22b)
travis is too slow for us and confuse contributors, who think they have
to get travis tests green.
We have now pr bots instead.
(cherry picked from commit 44917c46b1)
Since the update to Python 3.6.3 in f906d6d18e
some of the Hypothesis tests in natsort suddenly begin to fail with
errors like this one:
res = '\x00\x00', f = <built-in function strxfrm>
> return partial(reduce, lambda res, f: f(res), functions)
E ValueError: embedded null character
The tests didn't fail with Python 3.6.2, but they did fail with Python
3.5 already.
I didn't dig through what the exact problem was, but I'd guess that the
problem could lie in Hypothesis itself. Unfortunately updating to the
latest version of Hypothesis didn't turn out to be that easy as well,
because the newer versions have a circular dependency on pytest and a
few other libraries.
So I opted against updating Hypothesis for now and just mark the tests
as "expected to fail" on purpose so that whenever we someday have a
newer version of Hypothesis, the build for natsort will fail and we can
remove this patch again.
Tested against Python 2.7, 3.4, 3.5 and 3.6 and all of the builds now
succeed.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @jluttine, @FRidh
(cherry picked from commit e13c6645b1)
Includes security fixes for CVE-2017-15398 and CVE-2017-15399.
Also fixes builds for beta and dev branches:
- backport https://webrtc-review.googlesource.com/9384 to fix build for
new webrtc revision
- for dev branch fix gn bootstrap, see
https://chromium-review.googlesource.com/758584
- for 63+ manpage now is not generated during ninja build, it is
processed with sed using packagers tools included in sources
(cherry picked from commit 7105bb68cc)
Currently we wrap ssh so it can find the config file passed in by
<ssh-config-file>. If one however uses ProxyCommand ssh, then ssh that
is on PATH is taken (which is also unavailable when using nix-shell
--pure), which is the plain ${openssh}/bin/ssh.
This commit makes sure our wrapped ssh is available on PATH.
(cherry picked from commit f8eed5f7a5)
This fixes#28768 because during an image build, Nix sees bad store
timestamps and attempts to fix them, but can't fix them on a running
system (due to being inside a builder). Since timestamps on the store
are supposed to be 1 anyway, if we fix this, that fixes image building
inside booted images made this way.
Note that this adds quite a bit of noise to the output, because running
`cptofs` under `faketime` causes a bunch of seemingly spurious error
messages and my attempts to suppress them all failed. We'll fix it when
`cptofs` gets a native timestamp preservation feature.
This is required by the new c5.* instance types.
Note that this changes disk names from /dev/xvd* to
/dev/nvme0n*. Amazon Linux has a udev rule that calls a Python script
named "ec2nvme-nsid" to create compatibility symlinks. We could use
that, but it would mean adding Python to the AMI closure...
(cherry picked from commit 54da9cc944)
Sometimes (especially in the default route case) it is required to NOT
add routes for all allowed IP ranges. One might run it's own custom
routing on-top of wireguard and only use the wireguard addresses to
exchange prefixes with the remote host.
(cherry picked from commit 846070e028)
Before this change, trying to build LAME on Darwin would throw an error:
Undefined symbols for architecture x86_64:
"_lame_init_old", referenced from:
-exported_symbol[s_list] command line option
ld: symbol(s) not found for architecture x86_64
clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation)
(cherry picked from commit e82dc084d4)
Quoth the release notes:
> It includes several bugfixes, including a bugfix for a crash issue that
had affected relays under memory pressure. It also adds a new directory
authority, Bastet.
(cherry picked from commit 5a64e446ff)
The OpenNTPD constraints feature requires a valid chain of SSL
certificates, but the default path in openntpd didn't match the one in
NixOS.
Unfortunately the configured certificate path becomes hardcoded into the
binary, so this feature will likely still fail on other
distributions/operating systems, unless the path coincides with the
NixOS path or the user sets up a symlink.
(cherry picked from commit f7616c4f5e)
Instead of adapting Dropbox to NixOS with patchelf, NixOS is adapted to Dropbox
with an FHS user environment. A crash due to missing libXert (#15356) is
fixed. The client's automatic updater is fixed; this obviates the need to
update Dropbox in Nixpkgs every time the client is updated upstream!
Resolves: #15356
(cherry picked from commit 9a9ea65de9)
Notable recent changes:
- Northern Cyprus resumed EU rules starting 2017-10-29.
- Namibia will switch from +01 with DST to +02 all year, affecting
UT offsets starting 2018-04-01.
- Sudan will switch from +03 to +02 on 2017-11-01.
- Tonga will not observe DST on 2017-11-05.
- Turks & Caicos will switch from -04 all year to -05 with US DST,
affecting UT offset starting 2018-11-04.
(cherry picked from commit bfd57788b6)
An amended git tag, apparently. There are only changes in documentation
and whitespace changes in code. Sigh. Uncovered by c3255fe8ec.
(cherry picked from commit f90c468ea5)
The website of MuPDF says that MuPDF is licensed under the terms of the GNU
Affero General Public License. However, I didn't see which version of that
license they mean.
A clear statement that MuPDF is licensed under the terms of AGPL >= 3 is
included in the README file of their Git repository:
git://git.ghostscript.com/mupdf.git
(cherry picked from commit 3afcba3e0a)
(cherry picked from commit 53c6b01a81)
This fix is perhaps borderline for inclusion on 17.09,
but we have a stdenv rebuild anyway, so let's fix the hangs.
- This fixes tests after sqlite update, also tested via nixStable
and via building some other perl reverse dependencies.
- The patch was conflicting due to upstream changes,
but those changes allowed us to minimize the patch.
- meta from nix-generate-from-cpan
/cc #30927.
(cherry picked from commit 5618691751)
fixes japanese input & some obscure security issues:
`An important Electron update improving security. A precautionary measure, but it’s always good to be up to date.` and
`A small release containing nothing but another Electron update, this one better than the last.`
(cherry picked from commit a2437393f0)
Reverse the PartOf dependency between network-setup and network-addresses-*
This was joint work of: @nh2, @domenkozar, @fpletz, @aszlig and @basvandijk
at the NixCon 2017 hackathon.
also fix beta/dev build - use harfbuzz from sources
Unfortunatelly after [0] chromium doesn't support using harfbuzz provided by
system while using vendored version of freetype.
Disabling usage of separate harfbuzz for now.
[0] https://chromium-review.googlesource.com/c/chromium/src/+/696241
When autoFormat is enabled, in order to successfully create a filesystem,
certain filesystems require specific options to be passed to mkfs to prevent
it from asking questions. This commit sets default formatOptions to "-q"
for "jfs" and "reiserfs" filesystems for this purpose.
Resolves#29140.
(cherry picked from commit e3f97e514d)
Removes following warnings:
[cb,WARN] (pcbc/ext L:418) igbinary serializer is not found
[cb,WARN] (pcbc/ext L:425) zlib compressor is not found
(cherry picked from commit 30721a280f)
Since basically forever, it randomly fails with
do not know how to unpack source archive /nix/store/d821jkm8bgkdcv924nk7qr1q06l9is35-x42-plugins-20170428.tar.xz
on Hydra.
https://hydra.nixos.org/build/62793688
(cherry picked from commit 4068703502)
These ones don't have a single pass on 17.09 and weren't disabled in ZHF
for some reason:
gnome3-gdm: broken since 2016-10-25
ec2-config: broken since 2017-04-03 @copumpkin
pam-oath-login: broken since 2017-05-31 @grahamc
Disable them on 17.09 (and in ~1mo I will disable them on master if
they're still broken as well).
Noticed in https://hydra.nixos.org/jobset/nixos/release-17.09#tabs-errors:
````
hydra-eval-jobs returned exit code 1:
building path(s) '/nix/store/wxcbjli7m98yymnxrxkf6pigr7a05zad-id_ed25519.pub'
building '/nix/store/gyig2d7cry98647h0grfilq26cpc1wy8-id_ed25519.pub.drv'...
````
Issue #29774
(cherry picked from commit 2f3786e7ef)
Include and lib are not in ${glew} but in ${glew.dev}.
This changes what is found by the cmake of opensubdiv and some features
are now enabled, such as OpenGL 4.2 support.
(cherry picked from commit 2348c6ce56)
ShellCheck depends on GHC which is quite a large package to have in the
build-time closure of all NixOS systems.
(cherry picked from commit e866bb421a)
Commit 271d3f7a43 ("prometheus service: globalConfig.labels is obsolete")
removed globalConfig.labels. Update the test config accordingly.
(cherry picked from commit 774d05878a)
The NIST elliptic curve groups (ecp192 etc.) are only available if the
OpenSSL plugin is enabled, and these groups are currently the only EC
groups supported on iOS and macOS devices.
(cherry picked from commit b59013249e)
error: while evaluating the attribute ‘darwin-tested’ at /build/git-export/lib/attrsets.nix:199:44:
[..]
while evaluating the attribute ‘nix-info.x86_64-darwin’ at /build/git-export/lib/attrsets.nix:199:44:
attribute ‘x86_64-darwin’ missing, at /build/git-export/pkgs/top-level/release.nix:50:15
(cherry picked from commit 9805818d24)
"batch" is a shell script so invoking it via setuid wrapper never worked
anyway. (The kernel drops perms on executables with shebang.) A previous
nixpkgs commit made "batch" invoke the NixOS setuid "at" wrapper to gain
needed privileges.
Thanks to @yesbox for noticing.
(cherry picked from commit 497108b456)
Commit 987aac7 and issue #18183 were intended to fix support for other
things, but in the process, changed mdns_minimal to use the wrong return
setting, resulting in permanent failures in early boot, affecting things
like issue #30459.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
(cherry picked from commit ea50efcc67)
CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
(cherry picked from commit 629965a532)
Lately failing i686 tests like firefox have been blocking channel
releases. We're still building the tests for systems with limited
support but won't delay a channel release if they fail.
(cherry picked from commit 874a3c033c)
Broken since #30143.
I can't say I understand why this combination is apparently unsupported.
i686-linux is a second-tier platform now, but firefox is still kept a
channel blocker...
(cherry picked from commit e067d26f43)
This module doesn't exist since v4.3, where the ext3 driver was removed
as ext4.ko can mount ext3 filesystems as well.
(cherry picked from commit e86b78363d)
On Darwin, keep the Ruby and libffi libraries and binaries bundled
with Vagrant instead of linking to the Nix ones, to avoid errors about
libraries not found.
(cherry picked from commit 97d9f0b5bb)
The file was generated with the update script that is part
of the nix expressions for enpass.
Also, it seems that 5.4 has some issues with dropbox sync,
this was the original rationale to look for a newer version.
(cherry picked from commit 0d7e0b4ec2)
Previously, libmupdf.so did not have DT_NEEDED references to its
dependencies. Packages which linked against libmupdf would have to also
manually link against its dependencies as well.
(cherry picked from commit 9c53b9cff9)
The source distribution contains binaries (probably for testing) that
make the Avira virus scanner treat it as malware on account of a “bad
ELF header”. Apart from being preferable in general, the HTTPS download
makes the file opaque to the overeager AV scanner in transparent
proxying setups.
Also adapt to the fact that the canonical downloads now point to a URL
like this:
https://releases.llvm.org/4.0.1/llvm-4.0.1.src.tar.xz
(cherry picked from commit 0e2e3afd65)
Before this fix, it seemed to be trying to merge our postFetch with the
patch normalization logic, but accidentally clobbering the whole thing
with the passed-in value.
(cherry picked from commit dd8a42a224)
Upgrade to latest version of Vagrant.
After installation, the following messages appear whenever vagrant runs.
These were already present in previous versions, I'm not sure if/what
to do about them:
Ignoring ffi-1.9.18 because its extensions are not built. Try: gem pristine ffi --version 1.9.18
Ignoring unf_ext-0.0.7.4 because its extensions are not built. Try: gem pristine unf_ext --version 0.0.7.4
Ignoring wdm-0.1.1 because its extensions are not built. Try: gem pristine wdm --version 0.1.1
(cherry picked from commit 9bcd1de373)
Hopefully the message will make accidental full evaluations of NixPkgs
(and their inevitable failures) easier to notice and debug.
By suggestion from @grahamc (in his IRC gchristensen form)
(cherry picked from commit df812e3487)
Changes:
* The patch `glusterfs-fix-unsubstituted-autoconf-macros` was deleted
because the issue was fixed upstream:
https://bugzilla.redhat.com/show_bug.cgi?id=1450588
* The `glusterd-ganesha.c` part of `glusterfs-use-PATH-instead-of-hardcodes`
was detleted because `glusterd-ganesha.c` was removed upstream
without replacement that has the relevant hardcoded paths.
Closes https://github.com/NixOS/nixpkgs/pull/29062
(cherry picked from commit 8f4084004e)
The renaming of gitlab-ci-mutli-runner to gitlab-runner
is finally complete. Symlinking is thus no longer needed.
(cherry picked from commit 824f2e2a28)
I assume we don't need to have multiple versions of gccgo,
so let me keep it aligned with our default gcc version.
(cherry picked from commit d5bf6a0d2c)
geoclue2 without GNOME requires glib_networking in order to make HTTPS
connections to location providers. Additionally, geoclue2 crashes if an
NMEA provider is found on the network without GSettings support.
Also moved intltool to nativeBuildInputs as per good practices.
(cherry picked from commit e1b74291bd)
nixos/lib/make-channel.nix:16:
echo -n ${nixpkgs.rev or nixpkgs.shortRev} > .git-revision
This means the .git-revision exists in nixos channels, but not
Nixpkgs channels. Adding it to the nixpkgs channel makes it a
common API for any Nixpkgs use cases.
(cherry picked from commit 5a43eec070)
The output of ./configure shows all modules/plugins, both enabled and
disabled. With this info we can finally build the _complete_ list of
modules. We were missing these:
mod_authn_gssapi
mod_authn_ldap
mod_geoip
(I hit this as I was building lighttpd with ldap support and the NixOS
module said ldap was unsupported, due to these missing entries in
allKnownModules.)
(cherry picked from commit d26f8b5e00)
powertop attempt to load some kernel modules like msr by calling
modprobe. This is the counterpart to
88e43eb39b which has the powertop
executable search PATH for modprobe rather than hardcoding /sbin, and
actually adds the directory containing modprobe to its PATH for the
systemd service.
(cherry picked from commit fadb906b2f)
Hash was forgotten in
a26ae760e2.
The newer version of pkg_resources, 36.4.0, is actually incomplete.
Therefore, let's stick with the older version which didn't cause any
issues.
(cherry picked from commit 23ad2b2e7a)
This stops the derivation from overriding the default patchPhase, which
right now prevents adding a list of patches in the "patches" attribute.
(cherry picked from commit 92852fd193)
librsvg hooks itself into gdk-pixbuf and then uses gdk-pixbuf-thumbnailer
as the thumbnailer, extending its supported MIME type list.
Unfortunately, librsvg assumes the thumbnailer will be located in the same
bindir as librsvg binaries would, which is not true on Nix-powered systems.
This commit corrects the bindir path of the thumbnailer to the gdk_pixbuf
derivation.
(cherry picked from commit dd200f8197)
Just like Nautilus (see #29970), GNOME Control Center also uses
gnome-desktop for generating thumbnails. In particular, it tries
to make a thumbnail from a file choosen as a profile picture, and
when it does not succeed, it will not allow that file to be chosen.
Of course, whithout a thumbnailer, it will always fail.
43129a1cfd/panels/user-accounts/um-photo-dialog.c (L190-L192)
Since gnome-desktop scans `thumbnailers` directories under the paths
in `XDG_DATA_DIRS`, gdk-pixbuf had to be added to the path to provide
access to image thumbnailer.
(cherry picked from commit a093bf8b88)
cc #15558
Components are now part of the base install
(previously it seems no components were included),
which I believe mostly removes the need for the srcComponents bit.
Debian is only other distro packaging this according
to repology, and they don't include additional libraries
which further suggests they're at least non-essential :).
As for the Caneda/Libraries repository, copying these
into the "libraries" directory with similar files
does not cause them to be auto-registered anyway,
as far as I can tell the application has a static
list of components (in the source) and additional
components need to be added using the GUI
making bundling them a bit useless and misleading.
caneda also now requires qt5 and doesn't appear to require
either libxml2 or libxslt.
This is "a bit" hacky tho...
The improvement is that it now covers the stable as well as the preview
releases and doesn't require Python 3.4 anymore.
(cherry picked from commit 5257232ac7)
This is a better default for NixOS because it ensures that config
changes happen fully when NixOS users expect it.
(cherry picked from commit 18eecae4b6)
Prevents glustereventsd failing at startup in case it starts
before glusterd has started (whose `preStart` would also
create the needed directory).
(cherry picked from commit 08f7e4516c)
This introduces dependency cycles.
A network file system to be running is not required for a network
connection to be available.
19759cfeab (commitcomment-22044519)
(cherry picked from commit 5e2815dfb7)
This fixes the ./update-all script to actually fetch all the available
providers (thanks pagination). It was also improver to user a more
compact representation of the data.
(cherry picked from commit 9f2ff1d31a)
Some Git commands are implemented as Perl scripts. Some of these
scripts use Perl modules from CPAN. Without wrapping these programs to
set `GITPERLLIB`, these programs would not be fully functional because
some Perl libraries are found to be missing at runtime.
Fixes#29996
(cherry picked from commit f795d78d86)
When overriding gnupg to uss pinentry gnome3 frontend, there is
a dependency cycle:
gnupg → pinentry_gnome → gcr → gnupg
This commit overrides the gnupg required by gcr to not build GUI.
(cherry picked from commit b34a891295)
pinentry 0.9.6 changed the `qt4` flag to just `qt`. Additionally,
the `--with-x` option has not been there for a while. This commit
renames and removes the flags, respectively.
(cherry picked from commit 75bf151d25)
The pinentry_gnome package requires gcr. Unfortunately, when configure
asks about the library (or `pkg-config --libs gcr-base-3` is used) it
fails because glib is not in scope.
```
$ pkg-config --libs gcr-base-3
Package glib-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glib-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'glib-2.0', required by 'gcr-base-3', not found
```
This commit moves glib and gtk to `propagatedBuildInputs` so pkgconfig
could find them.
See also 38b58bab62
(cherry picked from commit adbba9d5f6)
Nautilus, resp. gnome-desktop, scans `thumbnailers` directories
under the paths in `XDG_DATA_DIRS`. gdk-pixbuf was not, for some
reason, listed in the variable, therefore Nautilus did not generate
image thumbnails.
I also add librsvg to the variable so that SVG files can be rendered.
It does not work at the moment, though, because of incorrect path to
the renderer.
(cherry picked from commit baa7e397c1)
In #26879, GNOME Online Accounts support was removed resulting in
repeated authentication prompts for users relying on services like
Google Calendar.
This commit removes the build flag that disabled the support.
(cherry picked from commit 29dd3accf5)
Looks trival, but it is easy to make the mistake
to add linuxPackages.bcc to systemPackages,
which breaks if the not the default kernel is used.
(cherry picked from commit 44b6a1509d)
The current `remotes` option is a string option containing nullmailer remote
definitions. However, those definitions may contain secret credentials and
should therefore not be put world-readable in the nix store.
I added a `remotesFile` option, which allows to specify a path to the remotes
definition file instead. This way, the definitions can be kept outside of the
nix store with more secure file permissions.
(cherry picked from commit e741cc4881)
Apparently gwrap will not compile with guile-2.2 [1], even though the
news for version 1.9.15 says it "allows" Guile 2.2 [2]:
> it will _not_ compile using 2.2
Furthermore, it seems like it isn't being developed anymore either [1]:
> Also note that g-wrap itself is not being further developed anymore,
> it is recommended for new projects to use Guile's dynamic FFI.
Also, guile-gnome-2.16.5 is apparently compatible with guile-2.2 [3],
but I'm not sure how they built it with guile-2.2 because gwrap 1.9.15
(latest release) apparently doesn't build with guile-2.2. (And certainly
when I try to build gwrap 1.9.15 with guile-2.2 it doesn't work. Maybe
it can be made to work with certain compile flags, but I haven't pursued
that further due to [1] anyway.) This is why guile-gnome is still on
2.16.4 here. Because, although 2.16.5 can still (apparently) build with
guile-2.0.14, guile_2_0 is only at guile-2.0.13.
So to update guile-gnome to 2.16.5, guile_2_0 would first have to be
updated to 2.0.14.
[1]: http://lists.nongnu.org/archive/html/g-wrap-dev/2016-08/msg00001.html
[2]: http://www.nongnu.org/g-wrap/news.html
[3]: https://www.gnu.org/software/guile-gnome/news.html
(cherry picked from commit f1b7d0a54f)
This also upgrades the hsevm package from v0.6.4 to v0.8.5.
The project `dapp` which depends on hsevm was also updated to use the
new name, so I have also upgraded that package from version v0.5.3 to
v0.5.7.
I also added a `dontCheck` to a Hackage dependency because its test
suite depends on Git and runs a bunch of Git repository manipulations.
(cherry picked from commit 74edd2c5db)
building
Extracting Bazel installation...
Loading:
Analyzing: target //source/exe:envoy-static
ERROR: java.io.IOException: Could not read the crosstool configuration file 'CROSSTOOL file /tmp/nix-build-envoy-1.3.0.drv-0/envoy-v1.3.0-src/.home/.cache/bazel/_bazel_nixbld1/cbe181aaebf3d7253cbcf6057028e514/external/local_config_cc/CROSSTOOL', because of a parser error (945:1: Expected identifier. Found '%')
INFO: Elapsed time: 3.065s
FAILED: Build did NOT complete successfully
builder for ‘/nix/store/09wh9hd81529pgr3ddwfw68higfzkfgr-envoy-1.3.0.drv’ failed with exit code 2
error: build of ‘/nix/store/09wh9hd81529pgr3ddwfw68higfzkfgr-envoy-1.3.0.drv’ failed
(cherry picked from commit 49a060ea1f)
The build provides as text a summary of the build, including the
absolute path of the compiler used for compilation. Unfortunately, this
pulls in stdenv.cc as a transitive closure.
So this change just calls remove-references-to as a postInstall step for
the one stdenv.cc dependency.
See #29889 for details.
(cherry picked from commit 405c7f9e437a89bbebc3e2663e8fcc74e69783d6)
Consul is a service you typically want to have running all the time;
it's not supposed to quit by itself.
(cherry picked from commit f4c53f1940)
Closes#29861.
We now wait for dhcpcd to acquire a lease but dhcpcd is restarted on
system activation. As wpa_supplicant is stopped while dhcpcd is
restarting a significant delay is introduced on systems with wireless
network connections only. This changes the wpa_supplicant service to
also be restarted together with dhcpcd in case both services were
changed.
(cherry picked from commit 725dee203a)
This reverts commit 0c81594a29.
It's no longer needed since systemd-vconsole-setup enumerates all ttys
until it finds a suitable one since systemd v234.
(cherry picked from commit 4a2442032e)
The current version is broken:
- there's no `openFirewall` attribute directly in the `cfg` set
- the `port` option is an attribute of the `confOptions` set
I used the proper attribute for the firewall port and moved the `openFirewall`
option directly up to the `services.znc` set, as it's rather a general option
for the whole service than a znc-specific option (which are located inside the
`confOptions` set).
Unfortunately wlc 0.0.10 seems to be the cause for segfaults on sway,
way-cooler and orbment.
This will also build wlc with all optional packages (i.e. zlib,
valgrind and doxygen).
(cherry picked from commit 2d640b9d6e)
* Grants enough privileges to the configured user so that it can run
mysqldump.
* Adds a nixos test.
* Use systemd timers instead of a cronjob (by @fadenb).
* Creates a new user for backups by default, instead of using mysql
user.
* Ensures that backup user has write permissions on backup location.
* Write backup to a temporary file before renaming so that a failed
backup won't overwrite the previous backup, and so that the backup
location will never contain a partial backup.
Breaking changes:
* Renamed period to calendar to reflect the change in how to
configure the backup time.
* A failed backup will no longer result in cron sending an e-mail --
users' monitoring systems must be updated.
Resolves#24728
(cherry picked from commit 56eba66f77)
tinc can figure this out based on DeviceType.
I also got `/dev/net/tun FD in bad state` after a particular upgrade.
(cherry picked from commit ad8cb0917f)
While it's annoying to pollute the user database with a lot of nixbld*
users, 10 users is really too low for many modern systems.
(cherry picked from commit 79d547b4bb)
* openjdk 8: code cleanup
as recommended by 0xABAB in #27194
* openjdk 9: init at ea build 176
this starts with copy of 8.nix and just updates hashes and replaces 8
with 9. it also tweaks the version handling because we aren't dealing
with an update version yet.
* openjdk 9: adapt patches from openjdk 8
fix-java-home: surrounding code changed slightly
swing-use-gtk-jdk9: location of the file being patched changed due to
modularization
read-truststore-from-env: the code that handles the trustStore was
refactored out into a helper class in upstream commit
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/904861872c0e
adlc_updater: this isn't present anymore
* openjdk 9: make two more warnings-as-errors non-fatal
this requires that we switch to configureFlagsArray to deal with
whitespace
the errors being suppressed are show below:
* For target support_native_java.desktop_libawt_xawt_awt_Robot.o:
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c: In function 'isXCompositeDisplay':
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:152:50: error: embedded '\0' in format
[-Werror=format-contains-nul]
snprintf(NET_WM_CM_Sn, sizeof(NET_WM_CM_Sn), "_NET_WM_CM_S%d\0", screenNumber);
^
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:152:50: error: embedded '\0' in format
[-Werror=format-contains-nul]
cc1: all warnings being treated as errors
* For target support_native_jdk.hotspot.agent_libsa_ps_core.o:
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/hotspot/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c: In function 'read_exec_segments':
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/hotspot/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c:834:7: error: ignoring return value of 'pread', declared
with attribute warn_unused_result [-Werror=unused-result]
pread(ph->core->exec_fd, interp_name, exec_php->p_filesz, exec_php->p_offset);
^
cc1: all warnings being treated as errors
* openjdk 9: ea+176 -> ea+180
* openjdk 9: TODO disable infinality patches, at least to start
the code being patched here seems to have changed substantially or
perhaps even disappeared altogether. need to investigate whether
these patches are still relevant.
* openjdk 9: update installPhase for modularization
* separate jdk and jre images are now present under build/*/images
* samples have been removed (JEP 298)
-- TODO that JEP says demos will be gone too, but it seems some are still present?
* bina directory is no longer present
* openjdk 9: TODO handle *.pf files or purge this code completely
* openjdk 9: update minimal jre components
in particular, the name of the config option for headless has changed,
per https://bugs.openjdk.java.net/browse/JDK-8163102
* TODO about echo -n vs printWords, #27427
(cherry picked from commit 02fe1207ab)
Spamassassin expects its system-wide configuration at /etc/spamassassin, and
some user tools (like sa-learn) need to read those configuration files.
Therefore, we provide a symlink from /etc/spamassassin to the appropriate Nix
store path to make sure those tools work without the user having to pass an
elaborate --siteconfig path that, potentially, changes every time the system
updates.
Fixes https://github.com/NixOS/nixpkgs/issues/29414.
(cherry picked from commit bfab392e6e)
Storing the build configuration caused Firefox to retain a dependency
on gcc, glibc.dev and icu4c.dev.
This reduces the size of the firefox closure from 587 to 415 MiB.
(cherry picked from commit c03326445b)
This reduces the closure size of Emacs from 575 to 279 MiB. Dumping
Emacs had a chance of leaking parts of the environment (such as $PATH)
into the dumped executable. This hopefully fixes it. (It's a bit hard
to tell since the effect is not deterministic.)
(cherry picked from commit cf599d3f99)
In particular, this moves share/kf5 to the "out" output. This prevents
kdelibs4support from pulling kdoctools.dev into its closure (via
share/kf5/kdoctools/customization/dtd/kdex.dtd, which references
${kdoctools}/share/kf5).
This reduces the closure size of kdelibs4support by 156 MiB.
(cherry picked from commit b790a31204)
While the last wlc upgrade (05d79c03ec)
makes it possible to build sway 0.14.0 it also breaks the current build
of sway 0.13.0.
Unfortunately sway 0.14.0 segfaults on launch and I couldn't fix it yet
(there are multiple upstream issues as well). I'll overwrite the wlc
version for sway in order to have a usable version in nixpkgs for the
meantime.
(cherry picked from commit 676f5cb02c)
The code was a bit messy (unused parameters, etc.) and caused some
warnings/errors which could potentially cause some problems.
(cherry picked from commit 4b85b23534)
Oracle JDK 9 does not seems to contain jre directory, so oraclejre9
package now uses a dedicated archive file.
There is no 32-bit version nor arm version (yet). If Oracle releases
them, I will update the package.
(cherry picked from commit 692fcd9f53)
oslo-service:
needs to disable tests due to network errors when importing eventlet
for tests ( socket.getprotobyname('tcp') -> no such protocol )
eventlet: 0.17.4 -> 0.20.0
cannot update to 0.21.0 due to version pinning ( < 0.21.0 ) of oslo-service
monotonic: 0.4 -> 1.3
oslo-serialization: 1.10.0 -> 2.20.0
oslo-utils: 2.6.0 -> 3.29.0
oslo-concurrency: 2.7.0 -> 3.22.0
oslo-log: 1.12.1 -> 3.31.0
oslo-context: 0.7.0 -> 2.18.1
routes: 1.12.3 -> 2.4.1
webob: 1.4.1 -> 1.7.3
when updating i rewrote the package to use fetchPypi for making future
updating easier
(cherry picked from commit 78621e384c)
also updated the following dependencies:
keystoneauth1: 3.1.0 -> 3.2.0
disabled tests which require oslo-config, oslo-test or requests-kerberos
oslo-i18n: 2.7.0 -> 3.18.0
oslotest: 1.12.0 -> 2.18.0
os-client-config: 1.8.1 -> 1.28.0
needed to disable testing due to circular dependency with oslotest
mox3: 0.11.0 -> 0.23.0
disable tests for py36 due to upstream bug
debtcollector: 0.9.0 -> 1.17.0
tests enabled
extra packages:
requestsexceptions: init at 1.3.0
(cherry picked from commit 7251699081)
Add testssl.sh which is a nice utility for testing TLS/SSL
capabilities of servers without having to use any kind of
web-service. It's very useful for testing setups of services before
deployment and such.
(cherry picked from commit 02d9d40d99)
Currently, the contents closure is copied to the layer but there is no
nix database initialization. If pkgs.nix is added in the contents,
nix-store doesn't work because there is no nix database.
From the contents of the layer, this commit generates and loads the
database in the nix store of the container. This only works if there
is no parent layer that already have a nix store (to support several
nix layers, we would have to merge nix databases of parent layers).
We also add an example to play with the nix store inside the
container. Note it seems `more` is a missing dependency of the nix
package!
(cherry picked from commit df589a438e)
The openldap dependency is only used for the audisp z/OS plugin.
This is not useful on Linux, so always disable this.
(cherry picked from commit 49fc06ed0a)
Multiprocess tabs always crash, as first reported by the issue mentioned
below. It is now consistently reproducible both on NixOS and non-NixOS
for me, so I've decided to add a toggle to conveniently disable
multiprocess support as a work-around.
Closes https://github.com/NixOS/nixpkgs/issues/27759 but does
not really fix the underlying problem ...
(cherry picked from commit 69e3817eb6)
Systemd is complaining that it can't delay the startup of device units.
We have a before dependency on the respective device unit for every
netdev service, which doesn't make any sense because we create the
actual interface in this service.
(cherry picked from commit 13a110e696)
Previously, depending on the environment and the type of interface that
was created, the configured IPs of an interface wouldn't be applied on a
nixos-rebuild switch. It works after a reboot.
This patch ensures that the network-addresses service is started
either via the network-link service or if the networking target is
activated (i.e. on system activation).
Fixes#28474#16230.
(cherry picked from commit 3a670daa98)
The program `qemu-img` is needed during creation of virtual machines
with qcow2 images. Otherwise creation of such VMs (e.g. with
virt-manager) are failing.
(cherry picked from commit 32e4e2c47b)
kbfs was not working with the lastest keybase update
(ef3cb5cc47).
We should enforce update of keybase/keybase-ui and kbfs (like done here:
f74a1e6bcb)
all together to avoid API problems.
(cherry picked from commit b50ae94ed3)
* gnome3: only maintain single GNOME 3 package set
GNOME 3 was split into 3.10 and 3.12 in #2694. Unfortunately, we barely have the resources
to update a single version of GNOME. Maintaining multiple versions just does not make sense.
Additionally, it makes viewing history using most Git tools bothersome.
This commit renames `pkgs/desktops/gnome-3/3.24` to `pkgs/desktops/gnome-3`, removes
the config variable for choosing packageset (`environment.gnome3.packageSet`), updates
the hint in maintainer script, and removes the `gnome3_24` derivation from `all-packages.nix`.
Closes: #29329
* maintainers/scripts/gnome: Use fixed GNOME 3 directory
Since we now allow only a single GNOME 3 package set, specifying
the working directory is not necessary.
This commit sets the directory to `pkgs/desktops/gnome-3`.
(cherry picked from commit 69698ec11c)
- add flannel support
- remove deprecated authorizationRBACSuperAdmin option
- rename from deprecated poratalNet to serviceClusterIpRange
- add nodeIp option for kubelet
- kubelet, add br_netfilter to kernelModules
- enable firewall by default
- enable dns by default on node and on master
- disable iptables for docker by default on nodes
- dns, restart on failure
- update tests
and other minor changes
(cherry picked from commit 7dfeac88ac)
The libcrypto patch didn't work well with `salt-ssh` (that code failed on
remote machines), so let's make Nix-based library lookup as fallback.
https://github.com/saltstack/salt/issues/43350
(cherry picked from commit a5b8c0c2de)
reading the code, it's hard to see how this test was *ever* supposed to
pass. interestingly, peeking across the fence, guix have disabled this test
too for the same reason.
note that tests don't actually run *at all* on py27 but that's a problem
for another day
(cherry picked from commit 9ca4f39b97)
Error is:
ERROR: In procedure %resolve-variable:
ERROR: Unbound variable: use-syntax
FAIL: sxml.ssax.scm
Also add pkg-config so that configure script can find libguile.
Relevant to #28643
(cherry picked from commit 913e770fa8)
1. The chmod 400 with the preset cookie prevented restarts, as
on the second boot it would fail to write to the cookie. Oops.
2. As far as I can tell, sasl logs were disabled because of the
following error:
{error,{cannot_log_to_tty,sasl_report_tty_h,not_installed}}
Not because we actually wanted to disable them. This meant the
management plugin wasn't usable due to a bug set to be fixed in
3.7.0.
(cherry picked from commit f3b9ac73e2)
Add another option for debugging instead. Lots of users have been
complaining about this default behaviour.
This patch also cleans up the EFI bootloader entries in the ISO.
(cherry picked from commit 3d040f9305)
TeXLive version is effectively identical anyway, and it caused an
unneccessary file name collision.
Fixes: #29671
(cherry picked from commit 8d001911db)
This has been broken nearly all the time due to the patches needed to
iproute2 not being compatible with the newer versions we have been
shipping. As long as Ubuntu does not manage to upstream these changes
so they are maintained with iproute2 and we don't have a maintainer
updating these patches to new iproute2 versions it is not feasible to
have this available.
(cherry picked from commit 08b09fdc5c)
This reverts commit 670b4e29ad. The change
added in this commit was controversial when it was originally suggested
in https://github.com/NixOS/nixpkgs/pull/29205. Then that PR was closed
and a new one opened, https://github.com/NixOS/nixpkgs/pull/29503,
effectively circumventing the review process. I don't agree with this
modification. Adding an option 'resolveLocalQueries' to tell the locally
running name server that it should resolve local DNS queries feels
outright nuts. I agree that the current state is unsatisfactory and that
it should be improved, but this is not the right way.
This option got introduced in 7904499542
and it didn't check whether mailUser and mailGroup are null, which they
are by default.
Now we're only creating the user if createMailUser is set in conjunction
with mailUser and the group if mailGroup is set as well.
I've added a NixOS VM test so that we can verify whether dovecot works
without any additional options set, so it serves as a regression test
for issue #29466 and other issues that might come up with future changes
to the Dovecot service.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #29466
Cc: @qknight, @abbradar, @ixmatus, @siddharthist, @peti
(cherry picked from commit 3ba2095a42)
We were using 'Combined Image JSON + Filesystem Changeset Format' [1] to
unpack and pack image and this patch switches to the format used by the registry.
We used the 'repository' file which is not generated by Skopeo when it
pulls an image. Moreover, all information of this file are also in the
manifest.json file.
We then use the manifest.json file instead of 'repository' file. Note
also the manifest.json file is required to push an image with Skopeo.
Fix#29636
[1] 749d90e10f/image/spec/v1.1.md (combined-image-json--filesystem-changeset-format)
(cherry picked from commit 35f205a4b6)
Ensure that modules required by all declared fileSystems are explicitly
loaded. A little ugly but fixes the deferred mount test.
See also https://github.com/NixOS/nixpkgs/issues/29019
(cherry picked from commit 1df6cf5d1d)
Add the `extraGitoliteRc` option to customize the `.gitolite.rc`
configuration file declaratively.
Resolves#29249.
(cherry picked from commit c73a3813fa)
* indentation, retab
* url handling for alternative version names
* handling for alt. download url format
* made unknown channel error non-fatal
(cherry picked from commit 14f2e0cd36)
Boot fails when a keyfile is configured for all encrypted filesystems
and no other luks devices are configured. This is because luks support is only
enabled in the initrd, when boot.initrd.luks.devices has entries. When a
fileystem has a keyfile configured though, it is setup by a custom
command, not by boot.initrd.luks.
This commit adds an internal config flag to enable luks support in the
initrd file, even if there are no luks devices configured.
(cherry picked from commit 2000fba561)
Currently the `rpc-gssd.service` has a `ConditionPathExists` clause that can
never be met, because it's looking for stateful data inside `/nix/store`.
`auth-rpcgss-module.service` also only starts if this file exists.
FixesNixOS/nixpkgs#29509.
(cherry picked from commit 98a2316166)
This includes fuse-common (fusePackages.fuse_3.common) as recommended by
upstream. But while fuse(2) and fuse3 would normally depend on
fuse-common we can't do that in nixpkgs while fuse-common is just
another output from the fuse3 multiple-output derivation (i.e. this
would result in a circular dependency). To avoid building fuse3 twice I
decided it would be best to copy the shared files (i.e. the ones
provided by fuse(2) and fuse3) from fuse-common to fuse (version 2) and
avoid collision warnings by defining priorities. Now it should be
possible to install an arbitrary combination of "fuse", "fuse3", and
"fuse-common" without getting any collision warnings. The end result
should be the same and all changes should be backwards compatible
(assuming that mount.fuse from fuse3 is backwards compatible as stated
by upstream [0] - if not this might break some /etc/fstab definitions
but that should be very unlikely).
My tests with sshfs (version 2 and 3) didn't show any problems.
See #28409 for some additional information.
[0]: https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0
(cherry picked from commit 351f5fc585)
This pervents the user from accidently commiting the key to the nix store.
If providing a path instead of a string.
(cherry picked from commit 8ed758696c)
The license of CompCert is not a generic "INRIA" license. It is "INRIA Non-Commercial
Agreement for the CompCert verified compiler". As unfortunate as it may seem, this
is a non-free license (clearly mentioned as such in its preamble). See also #20256.
(cherry picked from commit 8fde5790b4)
* First attempt at making elvish compile on darwin
* Fixed cyclic dependency on darwin
This fixes the "cycle detected in the references of" error when building
on darwin. The fix is based on the solution in issue #18131.
* Use version 0.10 and not 0.10.1, which is not officially released yet
(cherry picked from commit 8b8a2fd542)
It actually requires flake8-future-import but manages to download it
from the Internet when run outside the sandbox.
(cherry picked from commit 2c2cd34b54)
We cannot rely on wrapPythonPrograms to wrap the installed executables because
they are symlinks (which it ignores). Instead, we have to emulate it to make
the wrappers ourselves.
(cherry picked from commit 1e2ebee42a)
- Fix finding SDL (would previously fail unless gcc was in environment)
- Use ghostscript rather than xpdf for rendering as it has a slightly
smaller closure
- Fix broken link for reasoning behind name change
- Add self to maintainers
- Add reference to DejaVu fonts so it can always find the OSD fonts
- Install manpage into correct location
(cherry picked from commit 05101d32c0)
The getty@.service unit already has an ExecStart so we cannot simply set a new
one in order to override it or we will get this error:
systemd[1]: getty@tty1.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing.
Instead "reset" ExecStart by setting it to empty which is the systemd way of
doing it.
(cherry picked from commit 6558f81bc9)
This depends ultimately on texlive which is a big build and depends on
lots of libraries which often get security updates. This triggers
mass rebuilds because systemd depends on gnutls which depends on
p11_kit.
This was introduced with 93d80f1951.
(cherry picked from commit 0a2c39e205)
properly also in case dhcpcd being used.
Without network-online.target, coturn will fail to listen on addresses that
come up with dhcpcd.
(cherry picked from commit a9f60224f8)
Previously services depending on network-online.target would wait until
dhcpcd times out if it was enabled and a static network address
configuration was used. Setting the default gateway statically is enough
for the networking to be considered online.
This also adjusts the relevant networking tests to wait for
network-online.target instead of just network.target.
(cherry picked from commit b179908414)
By default, awesome will use "devel" as a version name
(or `git describe`). This has led to awesome always
showing "devel" for its version.
Some extensions depend on version information to figure
out what features they can use.
This change overrides the version for the build from the
derivations' `version` attribute.
(cherry picked from commit 824b30a715)
If neither database.password or database.passwordFile were provided,
it would try and fail to coerce null to a string.
This fixes the situation where there is no password for the database.
Resolves#27950
(cherry picked from commit 6460e459de)
This does break the API of being able to import any lib file and get
its libs, however I'm not sure people did this.
I made this while exploring being able to swap out docFn with a stub
in #2305, to avoid functor performance problems. I don't know if that
is going to move forward (or if it is a problem or not,) but after
doing all this work figured I'd put it up anyway :)
Two notable advantages to this approach:
1. when a lib inherits another lib's functions, it doesn't
automatically get put in to the scope of lib
2. when a lib implements a new obscure functions, it doesn't
automatically get put in to the scope of lib
Using the test script (later in this commit) I got the following diff
on the API:
+ diff master fixed-lib
11764a11765,11766
> .types.defaultFunctor
> .types.defaultTypeMerge
11774a11777,11778
> .types.isOptionType
> .types.isType
11781a11786
> .types.mkOptionType
11788a11794
> .types.setType
11795a11802
> .types.types
This means that this commit _adds_ to the API, however I can't find a
way to fix these last remaining discrepancies. At least none are
_removed_.
Test script (run with nix-repl in the PATH):
#!/bin/sh
set -eux
repl() {
suff=${1:-}
echo "(import ./lib)$suff" \
| nix-repl 2>&1
}
attrs_to_check() {
repl "${1:-}" \
| tr ';' $'\n' \
| grep "\.\.\." \
| cut -d' ' -f2 \
| sed -e "s/^/${1:-}./" \
| sort
}
summ() {
repl "${1:-}" \
| tr ' ' $'\n' \
| sort \
| uniq
}
deep_summ() {
suff="${1:-}"
depth="${2:-4}"
depth=$((depth - 1))
summ "$suff"
for attr in $(attrs_to_check "$suff" | grep -v "types.types"); do
if [ $depth -eq 0 ]; then
summ "$attr" | sed -e "s/^/$attr./"
else
deep_summ "$attr" "$depth" | sed -e "s/^/$attr./"
fi
done
}
(
cd nixpkgs
#git add .
#git commit -m "Auto-commit, sorry" || true
git checkout fixed-lib
deep_summ > ../fixed-lib
git checkout master
deep_summ > ../master
)
if diff master fixed-lib; then
echo "SHALLOW MATCH!"
fi
(
cd nixpkgs
git checkout fixed-lib
repl .types
)
(cherry picked from commit 152c63c9ff)
This partially undoes the change from 8788bfe762.
The 'doBenchmark' name is more consistent with the naming scheme used for
other phases, like 'doCheck', 'doHaddock', etc.
(cherry picked from commit 33e34aa95b)
In the maintenance release bump in
90059701a8 a certain change to /test/ was
backported from Python 3:
- bpo-30207: To simplify backports from Python 3, the test.test_support
module was converted into a package and renamed to test.support. The
test.script_helper module was moved into the test.support package.
Names test.test_support and test.script_helper are left as aliases to
test.support and test.support.script_helper.
(cherry picked from commit 96d15eaddb)
The bzero-patch was merged upstream in
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16103, so it does no
longer apply.
Additionally - to make the build succeed on darwin systems more recent
than our nixpkgs.darwin.xnu kernel version - we need to teach the build
the version of the xnu headers we provide, instead of letting the build
figure out the actual system version using `uname -r`.
(cherry picked from commit c71fd76822)
(cherry picked from commit cab5d25d3081a6d13773264000a308a7e07938b8)
When the user specifies the networking.nameservers setting in the
configuration file, it must take precedence over automatically
derived settings.
The culprit was services.bind that made the resolver set to
127.0.0.1 and ignore the nameserver setting.
This patch adds a flag to services.bind to override the nameserver
to localhost. It defaults to true. Setting this to false prevents the
service.bind and dnsmasq.resolveLocalQueries settings from
overriding the users' settings.
Also, when the user specifies a domain to search, it must be set in
the resolver configuration, even if the user does not specify any
nameservers.
This will get propagated down to other libraries loaded because
everything in nixpkgs references CF based on an rpath entry.
(cherry picked from commit cc1bfbd9a7)
New features since version 3.2.0:
* G'MIC Plugin
* Touch Painting
* Smart Patch Tool
* New Brush Presets
The full release notes can be found at:
https://krita.org/en/release-notes-for-krita-3-2/
Version 3.2.1 contains these fixes:
* Crash on startup if only OpenGL 2.1 is found: if you had to disable
opengl for 3.2.0, you can try to enable it again
* A crash when changing layer types in the gmic-qt plugin
* A bug where gmic-qt could crash on odd-sized images
* A regression where using the text tool would break the brush tool
* The option to use the native platform's file dialogs was restored
* A bug where selecting the line tool would disable the flow slider
* Some issues with the LUT docker were fixed
Upstream release notes for 3.2.1:
https://krita.org/en/item/krita-3-2-1-released/
I've dropped the patch, because it was already from the upstream
development version and thus is also included in this release.
Built and tested using a few images and just playing around with a few
new features.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @abbradar, @Mic92, @kragniz
(cherry picked from commit 8180085733)
the systemd.unit(5) discussion of wantedBy and requiredBy is in the
[Install] section, and thus focused on stateful 'systemctl enable'.
so, clarify that in NixOS, wantedBy & requiredBy are still what most
users want, and not to be confused with enabled.
(cherry picked from commit cfbac1beb4)
remove sqlite-amalgamation and put it internal to the zandronum folder,
as it is only used by zandronum. Patches needed to avoid build impurities
and to get the correct protocol version to connect to public servers.
remove zandronum_bin as it is no longer needed
(cherry picked from commit 990ea8789d)
Remove an obsolete patch
Add lassulus to maintainers
Supply the build with the correct version number and changelog
(cherry picked from commit f4dfa30d24)
This avoids running out of space in space-constrained environments,
e.g. VMs with relatively small amounts of memory and tmp on tmpfs
(cherry picked from commit 77ce02201e)
- Update to version 3.24-2, released on 2017 Aug 3
- Remove versions for GNOME 3.22 and 3.20. The version for 3.24 should
work with them as well.
(cherry picked from commit 6319210b8a)
Update physlock to a more current version which supports PAM and
systemd-logind. Amongst others, this should work now with the slim
login manager without any additional configuration, because it does
not rely on the utmp mechanism anymore.
(cherry picked from commit ae87a30a83)
* prometheus-collectd-exporter service: init module
Supports JSON and binary (optional) protocol
of collectd.
* nixos/prometheus-collectd-exporter: submodule is not needed for collectdBinary
(cherry picked from commit 334e23d244)
There are currently two ways to build Openstack image. This just picks
best of both, to keep only one!
- Image is resizable
- Cloudinit is enable
- Password authentication is disable by default
- Use the same layer than other image builders (ec2, gce...)
(cherry picked from commit 3a377e26b2)
The section was strange to read, as the initial example already used
`listOf' which is mentioned in the very first paragraph. Then you read
in a subsection about `listOf' and the exact same example is given
once again.
(cherry picked from commit 4d101993bf)
tinc prior to 1.1 doesn't have the `tinc` executable,
and `tincd` isn't of any use while the daemon already runs.
(cherry picked from commit 8cea87c1eb)
In c0cf19608f the function
`aspellWithDicts` was introduced, that allows to build a derivation
consisting of aspell and specified dictionaries. In
96457d26dd a fix was included to properly
find the dictionaries.
Issue #29429 describes that, while the current method works for the
aspell binary, it does not in case of the API.
This commit rewrites the wrapper into a single derivation, create a
single tree of symbolic references to both the binary and the
dictionaries so that its possible to find the dictionaries with the API.
Furthermore, the binary is wrapped so it can still find the dictionaries
as well.
(cherry picked from commit 91f7042aa0)
Before this patch, a VM was used to spawn docker that pulled the
VM. Now, the tool Skopeo does this job well so we can simplify our
dockerTools since we doesn't need Docker anymore:)
This also fixe the regression described in
https://github.com/NixOS/nixpkgs/issues/29271 : cntlm proxy doesn't
work in 17.09 while it worked in 17.03.
Note Skopeo doesn't produce the same output than docker pull so, we
have to update sha.
(cherry picked from commit 01174c5f4d)
Signed-off-by: Domen Kožar <domen@dev.si>
The patch was removed during chromium update.
It won't build, but the error seems the same as before chromium update...
(cherry picked from commit 9a55f74e43)
For various reasons, big Nix attrsets look ugly in the generated manual
page[1]. Use literalExample to fix it.
[1] Quotes around attribute names are lost, newlines inside multi-line
strings are shown as '\n' and attrs written on multiple lines are joined
into one.
(cherry picked from commit 6b7a9376f1)
The command `oc cluster up` mainly runs code though Docker containers.
However, in pkg/bootstrap/docker/host/host.go, nsenter is used to run
some commands on the host. For this to work on NixOS, we need to provide
the absolute path to the required programs.
(cherry picked from commit a3dde7776b)
- Updated from 1.5.0 to 3.6.0 (this is just the next version, but Red
Hat did quite the version bump there)
- Added 'v' to the version; it is used by `oc cluster up` to determine
which image should be downloaded.
- Added myself as a maintainer.
(cherry picked from commit f8a72662cf)
`qtkeyring` can use `gnome-keyring`, but it needs some help to find it.
I have not enabled this by default because not everyone who uses this will want
to pull in GNOME dependencies.
(cherry picked from commit e828dcb5cd)
This is used to platform specific library and exectuable extensions. In
the next commit I'll replace a bunch of ad-hoc logic with it.
(cherry picked from commit 741839a687)
Commit 8537cf0f81
("CONTRIBUTING.md: suggest "nixos/<module>" prefix for NixOS changes")
only changed CONTRIBUTING.md file and forgot about the Nixpkgs manual.
(I didn't know this information was stored in two places.)
(cherry picked from commit 56a047c7a1)
To wait for the docker deamon, curl requests are sent. However, if a
http proxy is set, it will respond instead of the docker daemon.
To avoid this, we send docker ps command instead of curl command.
(cherry picked from commit 132e790735)
ftfy package was added for spaCy and is only used by spaCy.
This change downgrades its version to meet the bounds specified by
spaCy (>=4.4.2,<5.0.0).
Relevant to #28643.
(cherry picked from commit 566f5e9e8d)
It's broken on all versions of Python (I've tried 2.7, 3.4, 3.5, 3.6)
I think the root cause is that PyBrain is not working with numpy >= 1.12.0 as I reported here:
https://github.com/pybrain/pybrain/issues/217
(The relevant release notes may be found here):
https://docs.scipy.org/doc/numpy-1.12.0/release.html#compatibility-notes
The PyBrain github repo does not seem very active (last commit 18 months ago, last release 3 years),
so I have some doubts as to whether this will be fixed any time soon.
I suppose an alternative solution could be to reintroduce the explicit dependency to numpy 1.11. But,
this is not entirely trivial: in c9b4a2f319, the versions 1.10, 1.11, 1.12 were folded into a single version.
Also, the numpy dependency is not a direct one, but is implied via scipy
(cherry picked from commit 50d36558a4)
Continuation of #28053
gnome-disk-image-mounter from gnome-disk-utility was not wrapped, resulting in an
error due to the inability to find gsettings schemas.
This commit replaces the manual wrapping of gnome-disks binary with wrapGAppsHook
so that all binaries are wrapped correctly.
(cherry picked from commit b64f149ea9)
https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00211.html
> This is an emergency release to fix a security vulnerability in Emacs.
>
> Enriched Text mode has its support for decoding 'x-display' disabled.
> This feature allows saving 'display' properties as part of text.
> Emacs 'display' properties support evaluation of arbitrary Lisp forms
> as part of instantiating the property, so decoding 'x-display' is
> vulnerable to executing arbitrary malicious Lisp code included in the
> text (e.g., sent as part of an email message).
(cherry picked from commit 78f457c76c)
The backslash wasn't properly escaped, and "\." is apparently equal to
".". So it's accidentally filtering out these valid file names (in
Nixpkgs):
trace: excluding clfswm
trace: excluding larswm
trace: excluding mkpasswd
While at it, turn the file filter stricter to what it was before
e2589b3ca2. That is, the file name must
start with a dot: '.swp', '.foo.swo' are filtered but 'bar.swf' is not.
(cherry picked from commit 9275c3387e)
Google publishes prebuilt tensorflow whl for python 3.4, 3.5, 3.6,
but nix expression for tensorflow only supported 3.5.
This change adds support for python-3.6.
- avr-gcc 5.3.0 -> 5.4.0
closes#28220
Since the packages do not share a common prefix anymore, you need
to define the current store paths in your project's Makefile.
Example for an atmega644 build:
CFLAGS += -I /nix/store/9rffxzds5crcpm76g3nr03jx0aa657cf-avr-libc-2.0.0/avr/include
CFLAGS += -B /nix/store/9rffxzds5crcpm76g3nr03jx0aa657cf-avr-libc-2.0.0/avr/lib/avr5
CFLAGS += -L /nix/store/9rffxzds5crcpm76g3nr03jx0aa657cf-avr-libc-2.0.0/avr/lib/avr5
CFLAGS += -L /nix/store/8409dj9js4i5901i63275wxdm783l0p6-avr-gcc-5.4.0/lib/gcc/avr/5.4.0/avr5
(cherry picked from commit 6a458c169b)
It doesn't look good when the initial admin user is named
"<hash>-gitolite-admin" and the key stored as
"<hash>-gitolite-admin.pub". Instead, make it simply "gitolite-admin"
and "gitolite-admin.pub".
(cherry picked from commit 6b9ee30672)
This updates namecoin from a legacy version from about 3 years ago
(https://github.com/namecoin/namecoin-legacy) to
the new namecoin-core.
(cherry picked from commit 8bd3664f373cb78a0526dc8a86e750f55b96420a)
(cherry picked from commit 31f349dbb4)
Use consistent no-space style. (All documentation I've seen use no
space, and the generated section headings from the NixOS module also use
no space.)
(cherry picked from commit fc02a0265a)
This is the latest release from Cadsoft, before they were bought by
Autocad. Autocad has released 8.x, but
- it requires reworking the Nix expression (different packaging)
- the paid license version requires a monthly subscription fee, you never
"own" the software (AFAICT).
Due to the licensing change in 8.x, I think keeping Eagle 7.x around is
a good idea.
(cherry picked from commit 28f780b320)
https://hydra.nixos.org/build/59943791
This package is a library and has no reverse dependencies. (It was once
used by diffoscope, but it changed to use a different library).
(cherry picked from commit 373b2231be)
This is set in the hardened linux config as well but sysctl is more
flexible & works with any boot.kernelPackages
(cherry picked from commit 2bce0b13e7)
These changes reduce file accesses outside TBB_HOME or the Nix store, as
determined by running under strace -e access,open,stat.
(cherry picked from commit f84125c3b1)
Aften is an audio encoder which generates compressed audio streams based on
ATSC A/52 specification. This type of audio is also known as AC-3 or Dolby®
Digital and is one of the audio codecs used in DVD-Video content.
Homepage: http://aften.sourceforge.net/
(cherry picked from commit 6e009edc41)
* tigervnc: correct default ssh client path
The -via command sets up an ssh tunnel, but is hardcoded to /usr/bin/ssh
upstream. This patches it to use the nixpkgs openssh client.
* tigervnc: patch ssh path correctly
(cherry picked from commit e9183fd2d4)
This fixes:
Traceback (most recent call last):
File "/nix/store/7f9arl3f9xyj8sm05mkanh2mlp217192-glusterfs-3.10.2/libexec/glusterfs/glusterfind/changelog.py", line 22, in <module>
import libgfchangelog
File "/nix/store/7f9arl3f9xyj8sm05mkanh2mlp217192-glusterfs-3.10.2/libexec/glusterfs/glusterfind/libgfchangelog.py", line 21, in <module>
libgfc = CDLL("libgfchangelog.so", use_errno=True, mode=RTLD_GLOBAL)
File "/nix/store/nlyr5ankhi7yvva8zndi718zj37js270-python-2.7.13-env/lib/python2.7/ctypes/__init__.py", line 362, in __init__
self._handle = _dlopen(self._name, mode)
OSError: libgfchangelog.so: cannot open shared object file: No such file or directory
Connection to 10.0.0.2 closed.
when running `glusterfind pre`.
Done by setting PYTHONPATH/LD_LIBRARY_PATH as for the other
Python scripts.
(cherry picked from commit abc96aae47)
Fixes error
File "/nix/store/lxpsl84km87xpk59nai6a33ihgpfs7qr-glusterfs-3.10.2/libexec/glusterfs/glusterfind/changelog.py", line 105, in populate_pgfid_and_inodegfid
file_xattrs = xattr.list(p)
AttributeError: 'module' object has no attribute 'list'
when using `glusterfind pre`.
(cherry picked from commit 8e329da496)
It seems that the recaptcha-client package is no longer maintained.
* The latest released version (1.0.6) is from the year 2011;
* The project page does not mention which Python versions are supported
* The project is hosted on google code, which is discontinued
I was able to succesfully build with Python versions 3.3, 3.4, but not
3.5, 3.6.
This is probably a fallout from #28557 merge and revert.
I can't see why exactly this happened, but it seems a safe fix.
(cherry picked from commit c86eb1da5f)
Fixes a number of CVEs:
- a DNS request hijacking vulnerability. (CVE-2017-0902)
- an ANSI escape sequence vulnerability. (CVE-2017-0899)
- a DoS vulnerability in the query command. (CVE-2017-0900)
- a vulnerability in the gem installer that allowed a malicious gem to overwrite arbitrary files. (CVE-2017-0901)
(cherry picked from commit 9f51b3c105)
Otherwise if you try to listing all available packages, you will get a
hard error on platforms not supported by this package. Consequently the
tarball job was broken.
(cherry picked from commit f9ea527a02)
Add pkgconfig as buildinput, so that the install path is correctly set
with cmake. PkgConfig is an optional dependency for rtags, but they
say it's necessary if you want to replace the prefix with
CMAKE_INSTALL_PREFIX. See:
caad9ac494/cmake/BashCompletion.cmake (L13)
Furthermore, I let the configurePhase of the rtags emacs package be a
noop.
(cherry picked from commit 311a1ee33a)
The build was failing with gcc 6.4.0; using the samee gcc6 patch Arch
Linux uses fixed the build.
This commit also refactors out the builder.sh possibly fixing the
NOGUI make flag option.
(cherry picked from commit 8b0de80e55)
Set LD=$CC to fix this build error:
...
ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/Boost/Geometry/Utils/Utils.bs')
ld -shared -O2 -L/nix/store/sgjc1147vi5hd57ck9xgck5xjkydg5lz-glibc-2.25/lib -fstack-protector-strong -o blib/arch/auto/Boost/Geometry/Utils/Utils.so buildtmp/Utils.o -lstdc++
buildtmp/Utils.o: In function `_GLOBAL__sub_I_Utils.c':
Utils.c:(.text.startup+0x1a): undefined reference to `__dso_handle'
/nix/store/yf4p5w2v4h4i8rja9zw1akp007av624j-binutils-2.28.1/bin/ld: buildtmp/Utils.o: relocation R_X86_64_PC32 against undefined hidden symbol `__dso_handle' can not be used when making a shared object
/nix/store/yf4p5w2v4h4i8rja9zw1akp007av624j-binutils-2.28.1/bin/ld: final link failed: Bad value
error building blib/arch/auto/Boost/Geometry/Utils/Utils.so from buildtmp/Utils.o at /nix/store/7q2hps69zkj501lsmvnd2ry95mmdbh80-perl-5.24.2/lib/perl5/5.24.2/ExtUtils/CBuilder/Base.pm line 321.
builder for ‘/nix/store/bdwqvgxlgcqsmlqfh0d74jkpw96p78kh-perl-Boost-Geometry-Utils-0.15.drv’ failed with exit code 2
error: build of ‘/nix/store/bdwqvgxlgcqsmlqfh0d74jkpw96p78kh-perl-Boost-Geometry-Utils-0.15.drv’ failed
(cherry picked from commit c24820db93)
I realize that advanced users like to configure services with Nix
attrsets, but I don't think we should remove the option to use the
(configuration) language provided by upstream.
(cherry picked from commit eed14baec3)
This is a security release theoretically under emgargo, but leaked by
Mageia and Fedora.
We have permission to deliver this prior to public release.
(cherry picked from commit 993a83d395)
This reverts commit 0a944b345e, reversing
changes made to 61733ed6cc.
I dislike these massive stdenv changes with unclear motivation,
especially when they involve gratuitous mass renames like NIX_CC ->
NIX_BINUTILS. The previous such rename (NIX_GCC -> NIX_CC) caused
months of pain, so let's not do that again.
(cherry picked from commit ec8d41f08c)
cctool's as needs to be told use to use gnu as, or else we'd need a
dependency cycle between cctools and clang for this case.
In general, this is not a problem because clang uses its own integrated
assembler where possible, and gnu as otherwise.
(cherry picked from commit eb326c9cb7)
When keys get refreshed a folder with the permissions of the root user
get created in the home directory of the user dnscrypt-wrapper. This
prevents the service from restarting.
In addition to that the parameters of dnscrypt-wrapper have
changed in upstream and in the newly packaged software.
(cherry picked from commit ca54a86162)
@dezgeg caught my error--the issue isn't building help2man, but running
it on cross-compiled binaries.
This effectively reverts 0825f30fd2 as
far as behavior is concerned, but keeps the removal of `crossAttrs`.
(cherry picked from commit 28e4975bd1)
One of the goals of 74f5fe5 was to allow passing in a custom stdenv,
which would be used for genericBuilder's `mkDerivation` call. That does
work, but if packages takes `stdenv` as an parameter for any reason,
they'll get the default one instead. This change remedies it.
(cherry picked from commit 19de1f537e)
Add openssh as dependency for sftp-server. When connecting, x2goclient
crashes if it can't find that executable.
(cherry picked from commit a8aef188c8)
There is no maintainer for this package, probably not many users.
It requires effort to fix all third-party modules for this old kernel
versions. It might contain unpatched security holes.
For Pixel chromebooks, we have the samus-kernel.
Apart from that https://github.com/GalliumOS/linux might be a good choice.
(cherry picked from commit 44f93731d6)
This change statically links the `dhall-*` family of executables so that
they start up more quickly on NixOS. This also updates the `dhallToNix`
utility to use the statically linked `dhall-to-nix` executable
(cherry picked from commit fd2c8d0a00)
The main thing is that I'm convinced the license can't be free when it
restricts redistribution to certain platforms. That probably holds with
the usual definitions like from Debian, FSF or OSI.
(cherry picked from commit 8414d8386b)
Upstream bug fixes:
* pen and touchscreen input handling bugfixes
* fix a minor bug with save file paths in Windows (D. German)
* use GDK macros (not WIN32) to disable X11-specific code (T.
Schoonjans)
* export to PDF and printing: fix resolution loss on some pdf
backgrounds
* disable xinput during modal dialog boxes
* avoid data corruption when exporting to overwrite a PDF
* fix path search order for toolbar bitmaps
* text and image tools activate on button release instead of button
press to avoid subsequent confusion between clicks in toolbar and
drawing area
* fix "pen disable touch" when touchscreen sends prox events (A.
Kittenberger)
* fix crash when pasting text or images via xclip
* updated Italian translation (Marco Ciampa)
New upstream features:
* add space and shift-space bindings to page down/up (D. German)
* add A5 paper (D. German)
* config option to export successive layers to separate PDF pages
* config option to create new file when trying to open non-existent
.xoj
The full change log along with bug numbers can be found at:
https://sourceforge.net/p/xournal/code/ci/Release-0_4_8_2016/tree/ChangeLog
I've dropped gdk-quartz-backend.patch, because I believe it has been
fixed upstream.
Here are the upstream changes relevant for the patch (shortened, because
SourceForge has really long URLs):
http://bit.ly/2vXW8n0 -> src/Makefile.am
http://bit.ly/2gDnjl7 -> src/xo-file.c
http://bit.ly/2xJ5K7A -> src/xo-misc.c
Tested building and using the application.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @7c6f434c, @dguibert
Cc: @johbo who has introduced the patch in #21842
(cherry picked from commit 8436e9bfcd)
In Nix 1.12 sandboxed builds are performed in /build/ directory which conflicts
with the regex in docs/CMakeLists.txt, and generated documentation ends up in
wrong directory -> https://hydra.nixos.org/build/53914969/nixlog/1 -> CTRL-F
abi.txt
(cherry picked from commit e22a77217d)
See PR #28960 for details about the problem. There is some
non-determinism surrounding copies of the Speedy/Speedy11 font, so
deleting one makes it deterministic again without losing anything.
(cherry picked from commit 7d231c5435)
Did this when spliting off binutils-wrapper from cc-wrapper in
40e9b2a7e6: I deleted the file instead of
moving it.
(cherry picked from commit 3601a97e3c)
Factor a binutils wrapper out of cc-wrapper. While only LD is wrapped,
the setup hook defines environment variables on behalf of other
utilites.
(cherry picked from commit 40e9b2a7e6)
Environment variable filter in substituteAll was not precise and produced
undefined and invalid variable names. Vladimír Čunát tried to fix that in [1],
but `env -0` did not work during Darwin bootstrap, so [2] reverted this change
and replaced an error due to invalid variables with a warning. Recently in #28057
John Ericson added `set -u` to `setup.sh` and undefined variables made the setup
fail during e.g. `nix-build -A gnat` with `setup: line 519: !varName: unbound
variable`.
[1] 62fc8859c1
[2] 81df035429
(cherry picked from commit a09d9e7cd4)
This becomes necessary if more wrappers besides cc-wrapper start
supporting hardening flags. Also good to make the warning into an
error.
Also ensure interface is being used right: Not as a string, not just in
bash.
(cherry picked from commit 97a48835b7)
GCC just passes `-z ...` flags to ld unaltered, and they are already
passed to LD anyways. On the other hand, `-pie` affects gcc behavior
too.
(cherry picked from commit 822a8d0148)
I missed this in 799435b7ca.
This time I used "git grep -F pythonPackages.deluge" just to be sure :-)
Thanks a lot to @roconnor for spotting this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: @roconnor
(cherry picked from commit 880a0409e8)
These have been throwing exceptions since grsec was deprecated, so
potential users should have had due to time to migrate their configs.
(cherry picked from commit 5125e209a9)
Potential disadvantage: ghostscript will become visible to user,
so there may e.g. be (new) collisions in nix-env due to this.
Fixes#28411.
(cherry picked from commit 828bc3812c)
It's now the default. /cc #19456
This makes a real build simplification, because in our current
bootstrapping+aliases, `gcc6` attribute is not the default compiler
but a derivation *built by* the default compiler.
nix-exec didn't build before this commit already
(cherry picked from commit 53998f5036)
Grub configs include the NixOS version and date they were built, now
systemd can have fun too:
version Generation 99 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-08-30
version Generation 100 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-08-30
version Generation 101 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-08-31
version Generation 102 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-09-01
version Generation 103 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-09-02
version Generation 104 NixOS 17.09beta41.1b8c7786ee, Linux Kernel 4.9.46, Built on 2017-09-02
version Generation 105 NixOS 17.09.git.1b8c778, Linux Kernel 4.9.46, Built on 2017-09-02
(cherry picked from commit 62652be111)
pyrtlsdr needs pandoc at build time. Fixes the build since commit
f6eb190e70
("python.pkgs.pyrtlsdr: disable tests to fix build"). (That commit
bumped the package to a new version.)
(cherry picked from commit 2cf1b94b82)
Z3 has supported optimization features since the 4.4.x release, so this can be
removed.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
(cherry picked from commit 54ae0aa1b0)
Upstream changes:
* Tesseract 4.00.00alpha:
* Version parsing: Ignore suffix (so '4.00.00alpha' == (4, 0, 0))
* Libtesseract: Load libtesseract.so.4 instead of libtesseract.so.3
if available
* Support for Tesseract 3.05.00:
* Builders: Split field 'tess_conf' into 'tess_flags' and 'tess_conf'
* Libtesseract: If available, use
TessBaseAPIDetectOrientationScript() instead of
TessBaseAPIDetectOS
* Libtesseract:
* Workaround: Prevents possible segfault in image_to_string() when
the target language is not available
Full upstream change log can be found at:
https://github.com/openpaperwork/pyocr/blob/b006123d1d002711b9/ChangeLog
The tesseract.patch for supporting Tesseract version 3.05.00 has been
applied upstream and we can safely drop it.
We now use substituteInPlace in conjunction with a patch to insert the
relevant store paths instead of sed, so it's less fragile whenever we
have upstream changes in handling of these paths.
I've tested this by reverting 48a941e29f and applying a build
fix patch of Cuneiform 1.1.0 from Arch Linux, because right now
Cuneiform is an experimental version that can't be fixed on behalf of
pyocr (the reason is that pyocr needs to get a list of languages, which
doesn't work in that version anymore).
In addition to that I've successfully built paperwork-backend which by
now is the one package which depends on pyocr. However, I didn't do
runtime tests of Paperwork.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @7c6f434c
(cherry picked from commit ca1ea69972)
We already have a patch feeling lonely inside the python-modules
directory and to have everything at one place let's actually move pyocr
into its own dedicated directory so it's easier to patch it up (which
we're going to).
Right now, the package fails to build because of a few test failures, so
I haven't tested this apart from evaluating.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(cherry picked from commit 3086fc7f83)
In order to run the tests for the external plugins of beets, we need to
have beets itself as a dependency. So in order to do that, we now pass
beets without plugins and tests to the nativeBuildInputs of the plugins
so that we can run them.
As soon as the plugins are built they become part of the final beets,
which also has tests enabled, so disabling the tests for beets
derivation that is used for external plugin tests is a non-issue here
because they're going to be executed anyway.
Enabling tests for the alternatives plugin is pretty straightforward,
but in order to run tests for the copyartifacts plugin, we need to bump
the source code to the latest Git master.
The reason for this is that the version that was in use until now
required to have the beets source directory alongside of the
copyartifacts source code, but we already have beets available as a
normal dependency.
Updating copyartifacts to latest master largely consists of unit test
changes and a few Python 3 compatibility changes. However, one change
has the biggest stat, which is
sbarakat/beets-copyartifacts@1a0c281da0.
Fortunately, the last change is just moving the implementation to a
newer API from upstream beets and by the looks of the implementation it
seems to break support for moving files. However, reverting this commit
also reveals that moving files was already broken before, so it wouldn't
matter much whether we have this version bump or not.
Tested with the following command:
nix-build -E '(import ./. {}).beets.override {
enableAlternatives = true;
enableCopyArtifacts = true;
}'
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @domenkozar, @pjones, @Profpatsch, @michalrus
(cherry picked from commit 40b76c8809)
Regression introduced by 94351197cd.
Running the tests results in the following traceback:
...
File ".../unittest/loader.py", line 91, in loadTestsFromName
module = __import__('.'.join(parts_copy))
File ".../test/regrtest.py", line 184, in <module>
for module in sys.modules.itervalues():
RuntimeError: dictionary changed size during iteration
The reason for this is that the test directory itself is called "test"
and the package including regrtest.py is also called "test", so the
loader tries to load tests from its own implementation.
We could fix this by changing PYTHONPATH and/or making the test
directory a proper package, but we'd still have failing tests because
beets itself is required to run the tests.
However for now I'm just removing the unit_tests kwarg in setup.py so
that we have the same behaviour as before the initially mentioned
commit.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(cherry picked from commit bd2aeb4883)
- Update to version 2.0.10
- Use wrapGAppsHook to wrap binaries
- Use gstreamer-1.0
- Add dependence on libappindicator
(cherry picked from commit 1f48ad8699)
Regression introduced by fa5e343242.
The deluge package no longer resides in pythonPackages but now is a
top-level package.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @grantwwu, @fpletz
(cherry picked from commit 799435b7ca)
This has been introduced in 6a6fb6d31c.
Relying on non-free software by default is probably a bad idea. Apart
from the fact that (sane) people usually don't want to have it sitting
on their system even people who don't care will have to set
"allowUnfree" to true in order to install conky.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @canndrew, @Mic92
(cherry picked from commit 7f99876f50)
previous mkDefault did not work as expected,
as it did not overwrite the original submodule's defaults when the user
did not specify any custom options at all.
(cherry picked from commit 786e9711f5)
GMime home has moved to Github as the list of commits clearly shows,
i.e.:
b5cbc68a67
The description is updated as well to be closer to the one used there
and over at gnome.org.
(cherry picked from commit ddaa696a4e)
The newer DEB packages have a setuid file, creating an error when
unpacking the source during the build phase.
As dpkg doesn't have a way to pass parameters to tar, dpkg is then
told to just extract the filesystem tar file and that is unpacked by
tar directly.
Fixes#28494
(cherry picked from commit fae458c5e7)
@@ -12,11 +12,11 @@ under the terms of [COPYING](../COPYING), which is an MIT-like license.
## Submitting changes
* Format the commit messages in the following way:
* Format the commits in the following way:
```
(pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc)
(Motivation for change. Additional information.)
```
@@ -25,21 +25,18 @@ under the terms of [COPYING](../COPYING), which is an MIT-like license.
* nginx: init at 2.0.1
* firefox: 54.0.1 -> 55.0
* nixos/hydra: add bazBaz option
Dual baz behavior is needed to do foo.
* nixos/nginx: refactor config generation
The old config generation system used impure shell scripts and could break in specific circumstances (see #1234).
* `meta.description` should:
* Be capitalized.
* Not start with the package name.
* Not have a period at the end.
* `meta.license` must be set and fit the upstream license.
* If there is no upstream license, `meta.license` should default to `stdenv.lib.licenses.unfree`.
* `meta.maintainers` must be set.
* Be capitalized
* Not start with the package name
* Not have a dot at the end
See the nixpkgs manual for more details on [standard meta-attributes](https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes) and on how to [submit changes to nixpkgs](https://nixos.org/nixpkgs/manual/#chap-submitting-changes).
See the nixpkgs manual for more details on how to [Submit changes to nixpkgs](https://nixos.org/nixpkgs/manual/#chap-submitting-changes).
- [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nox --run "nox-review wip"`
- [ ] Tested execution of all binary files (usually in `./result/bin/`)
* [Nix Wiki](https://nixos.org/wiki/) (deprecated, see milestone ["Move the Wiki!"](https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Move+the+wiki%21%22))
* [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
* [Continuous package builds for 17.09 release](https://hydra.nixos.org/jobset/nixos/release-17.09)
* [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
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.
Nixpkgs is increasingly adopting this opinion in that packages should be written with cross-compilation in mind, and nixpkgs should evaluate in a similar way (by minimizing cross-compilation-specific special cases) whether or not one is cross-compiling.
</para>
<para>
@@ -30,11 +30,11 @@
<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>.
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.
The three GNU Autoconf platforms,<wordasword>build</wordasword>, <wordasword>host</wordasword>, and <wordasword>target</wordasword>, are historically the result of much confusion.
<linkxlink:href="https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html"/> clears this up somewhat but there is more to be said.
An important advice to get out the way is, unless you are packaging a compiler or other build tool, just worry about the build and host platforms.
Dealing with just two platforms usually better matches people's preconceptions, and in this case is completely correct.
</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>:
@@ -52,7 +52,7 @@
<varlistentry>
<term><varname>hostPlatform</varname></term>
<listitem><para>
The "host platform" is the platform on which a package will be run.
The "host platform" is the platform on which a package is run.
This is the simplest platform to understand, but also the one with the worst name.
</para></listitem>
</varlistentry>
@@ -60,24 +60,22 @@
<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.
The "target platform" is black sheep.
The other two intrinsically apply to all compiled software—or any build process with a notion of "build-time" followed by "run-time".
The target platform only applies to programming tools, and even then only is a good for for some of them.
Briefly, GCC, Binutils, GHC, and certain other tools are written in such a way such that a single build can only compile code for a single platform.
Thus, when building them, one must think ahead about which platforms they wish to use the tool to produce machine code for, and build binaries for each.
</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.
There is no fundamental need to think about the target ahead of time like this.
LLVM, for example, was designed from the beginning with cross-compilation in mind, and so a normal LLVM binary will support every architecture that LLVM supports.
If the tool supports modular or pluggable backends, one might imagine specifying a <emphasis>set</emphasis> of target platforms / backends one wishes to support, rather than a single one.
</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.
The biggest reason for mess, if there is one, is that many compilers have the bad habit a build process that builds the compiler and standard library/runtime together.
Then the specifying target platform is essential, because it determines the host platform of the standard library/runtime.
Nixpkgs tries to avoid this where possible too, but still, because the concept of a target platform is so ingrained now in Autoconf and other tools, it is best to support it as is.
Tools like LLVM that don't need up-front target platforms can safely ignore it like normal packages, and it will do no harm.
</para>
</listitem>
</varlistentry>
@@ -157,22 +155,14 @@
<section>
<title>Specifying Dependencies</title>
<para>
In this section we explore the relationship between both runtime and buildtime dependencies and the 3 Autoconf platforms.
</para>
<para>
A runtime dependency between 2 packages implies that between them both the host and target platforms match.
This is directly implied by the meaning of "host platform" and "runtime dependency":
The package dependency exists while both packages are running on a single host platform.
</para>
<para>
A build time dependency, however, implies a shift in platforms between the depending package and the depended-on package.
The meaning of a build time dependency is that to build the depending package we need to be able to run the depended-on's package.
The depending package's build platform is therefore equal to the depended-on package's host platform.
Analogously, the depending package's host platform is equal to the depended-on package's target platform.
</para>
<para>
In this manner, given the 3 platforms for one package, we can determine the three platforms for all its transitive dependencies.
As mentioned in the introduction to this chapter, one can think about a buildtime vs run time distinction whether cross-compiling or not.
In the case of cross-compilation, this corresponds with whether a derivation running on the native or foreign platform is produced.
An interesting thing to think about is how this corresponds with the three Autoconf platforms.
In the run-time case, the depending and depended-on package simply have matching build, host, and target platforms.
But in the build-time case, one can imagine "sliding" the platforms one over.
The depended-on package's host and target platforms (respectively) become the depending package's build and host platforms.
This is the most important guiding principle behind cross-compilation with Nixpkgs, and will be called the <wordasword>sliding window principle</wordasword>.
In this manner, given the 3 platforms for one package, we can determine the three platforms for all its transitive dependencies.
</para>
<para>
Some examples will probably make this clearer.
@@ -187,58 +177,19 @@
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"/>.
Instead, one can use the four attributes used for specifying dependencies as documented in <xreflinkend="ssec-stdenv-attributes"/>.
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.
There is also a "backlink" <varname>__targetPackages</varname>, yielding a package set whose <varname>buildPackages</varname> is the current package set.
This is a hack, though, to accommodate compilers with lousy build systems.
Please do not use this unless you are absolutely sure you are packaging such a compiler and there is no other way.
</para></note>
</section>
<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?
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>
You can use them programmatically, or on the command line like <command>nix-build <nixpkgs> --arg crossSystem '(import <nixpkgs/lib>).systems.examples.fooBarBaz'</command>.
</para>
<note>
<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>
</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.
is for <emphasis>developer</emphasis> documentation. Currently we count gtk-doc and devhelp books in there. It goes to <varname>devdoc</varname> or is removed (!) by default. This is because e.g. gtk-doc tends to be rather large and completely unused by nixpkgs users.
is for <emphasis>developer</emphasis> documentation. Currently we count gtk-doc 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.
As described in the Nix manual, almost any <filename>*.drv</filename> store path in a derivation's attribute set will induce a dependency on that derivation.
<varname>mkDerivation</varname>, however, takes a few attributes intended to, between them, include all the dependencies of a package.
This is done both for structure and consistency, but also so that certain other setup can take place.
For example, certain dependencies need their bin directories added to the <envar>PATH</envar>.
That is built-in, but other setup is done via a pluggable mechanism that works in conjunction with these dependency attributes.
See <xreflinkend="ssec-setup-hooks"/> for details.
</para>
<para>
Dependencies can be broken down along three axes: their host and target platforms relative to the new derivation's, and whether they are propagated.
The platform distinctions are motivated by cross compilation; see <xreflinkend="chap-cross"/> for exactly what each platform means.
<footnote><para>
The build platform is ignored because it is a mere implementation detail of the package satisfying the dependency:
As a general programming principle, dependencies are always <emphasis>specified</emphasis> as interfaces, not concrete implementation.
</para></footnote>
But even if one is not cross compiling, the platforms imply whether or not the dependency is needed at run-time or build-time, a concept that makes perfect sense outside of cross compilation.
For now, the run-time/build-time distinction is just a hint for mental clarity, but in the future it perhaps could be enforced.
</para>
<para>
The extension of <envar>PATH</envar> with dependencies, alluded to above, proceeds according to the relative platforms alone.
The process is carried out only for dependencies whose host platform matches the new derivation's build platform–i.e. which run on the platform where the new derivation will be built.
<footnote><para>
Currently, that means for native builds all dependencies are put on the <envar>PATH</envar>.
But in the future that may not be the case for sake of matching cross:
the platforms would be assumed to be unique for native and cross builds alike, so only the <varname>depsBuild*</varname> and <varname>nativeBuildDependencies</varname> dependencies would affect the <envar>PATH</envar>.
</para></footnote>
For each dependency <replaceable>dep</replaceable> of those dependencies, <filename><replaceable>dep</replaceable>/bin</filename>, if present, is added to the <envar>PATH</envar> environment variable.
</para>
<para>
The dependency is propagated when it forces some of its other-transitive (non-immediate) downstream dependencies to also take it on as an immediate dependency.
Nix itself already takes a package's transitive dependencies into account, but this propagation ensures nixpkgs-specific infrastructure like setup hooks (mentioned above) also are run as if the propagated dependency.
</para>
<para>
It is important to note dependencies are not necessary propagated as the same sort of dependency that they were before, but rather as the corresponding sort so that the platform rules still line up.
The exact rules for dependency propagation can be given by assigning each sort of dependency two integers based one how it's host and target platforms are offset from the depending derivation's platforms.
Those offsets are given are given below in the descriptions of each dependency list attribute.
Algorithmically, we traverse propagated inputs, accumulating every propagated dep's propagated deps and adjusting them to account for the "shift in perspective" described by the current dep's platform offsets.
This results in sort a transitive closure of the dependency relation, with the offsets being approximately summed when two dependency links are combined.
We also prune transitive deps whose combined offsets go out-of-bounds, which can be viewed as a filter over that transitive closure removing dependencies that are blatantly absurd.
</para>
<para>
We can define the process precisely with <linkxlink:href="https://en.wikipedia.org/wiki/Natural_deduction">Natural Deduction</link> using the inference rules.
This probably seems a bit obtuse, but so is the bash code that actually implements it!
<footnote><para>
The <function>findInputs</function> function, currently residing in <filename>pkgs/stdenv/generic/setup.sh</filename>, implements the propagation logic.
</para></footnote>
They're confusing in very different ways so...hopefully if something doesn't make sense in one presentation, it does in the other!
<programlisting>
let mapOffset(h, t, i) = i + (if i <= 0 then h else t - 1)
let mapOffset(h, t, i) = i + (if i <= 0 then h else t - 1)
dep(h0, _, A, B)
propagated-dep(h1, t1, B, C)
h0 + h1 in {-1, 0, 1}
h0 + t1 in {-1, 0, -1}
-------------------------------------- Take immediate deps' propagated deps
propagated-dep(mapOffset(h0, t0, h1),
mapOffset(h0, t0, t1),
A, C)</programlisting>
<programlisting>
propagated-dep(h, t, A, B)
-------------------------------------- Propagated deps count as deps
dep(h, t, A, B)</programlisting>
Some explanation of this monstrosity is in order.
In the common case, the target offset of a dependency is the successor to the target offset: <literal>t = h + 1</literal>.
That means that:
<programlisting>
let f(h, t, i) = i + (if i <= 0 then h else t - 1)
let f(h, h + 1, i) = i + (if i <= 0 then h else (h + 1) - 1)
let f(h, h + 1, i) = i + (if i <= 0 then h else h)
let f(h, h + 1, i) = i + h
</programlisting>
This is where the "sum-like" comes from above:
We can just sum all the host offset to get the host offset of the transitive dependency.
The target offset is the transitive dep is simply the host offset + 1, just as it was with the dependencies composed to make this transitive one;
it can be ignored as it doesn't add any new information.
</para>
<para>
Because of the bounds checks, the uncommon cases are <literal>h = t</literal> and <literal>h + 2 = t</literal>.
In the former case, the motivation for <function>mapOffset</function> is that since its host and target platforms are the same, no transitive dep of it should be able to "discover" an offset greater than its reduced target offsets.
<function>mapOffset</function> effectively "squashes" all its transitive dependencies' offsets so that none will ever be greater than the target offset of the original <literal>h = t</literal> package.
In the other case, <literal>h + 1</literal> is skipped over between the host and target offsets.
Instead of squashing the offsets, we need to "rip" them apart so no transitive dependencies' offset is that one.
</para>
<para>
Overall, the unifying theme here is that propagation shouldn't be introducing transitive dependencies involving platforms the needing package is unaware of.
The offset bounds checking and definition of <function>mapOffset</function> together ensure that this is the case.
Discovering a new offset is discovering a new platform, and since those platforms weren't in the derivation "spec" of the needing package, they cannot be relevant.
From a capability perspective, we can imagine that the host and target platforms of a package are the capabilities a package requires, and the depending package must provide the capability to the dependency.
</para>
<variablelist>
<title>Variables specifying dependencies</title>
<varlistentry>
<term><varname>depsBuildBuild</varname></term>
<listitem>
<para>
A list of dependencies whose host and target platforms are the new derivation's build platform.
This means a <literal>-1</literal> host and <literal>-1</literal> target offset from the new derivation's platforms.
They are programs/libraries used at build time that furthermore produce programs/libraries also used at build time.
If the dependency doesn't care about the target platform (i.e. isn't a compiler or similar tool), put it in <varname>nativeBuildInputs</varname>instead.
The most common use for this <literal>buildPackages.stdenv.cc</literal>, the default C compiler for this role.
That example crops up more than one might think in old commonly used C libraries.
</para>
<para>
Since these packages are able to be run at build time, that are always added to the <envar>PATH</envar>, as described above.
But since these packages are only guaranteed to be able to run then, they shouldn't persist as run-time dependencies.
This isn't currently enforced, but could be in the future.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>nativeBuildInputs</varname></term>
<listitem>
<para>
A list of dependencies whose host platform is the new derivation's build platform, and target platform is the new derivation's host platform.
This means a <literal>-1</literal> host offset and <literal>0</literal> target offset from the new derivation's platforms.
They are programs/libraries used at build time that, if they are a compiler or similar tool, produce code to run at run time—i.e. tools used to build the new derivation.
If the dependency doesn't care about the target platform (i.e. isn't a compiler or similar tool), put it here, rather than in <varname>depsBuildBuild</varname> or <varname>depsBuildTarget</varname>.
This would be called <varname>depsBuildHost</varname> but for historical continuity.
</para>
<para>
Since these packages are able to be run at build time, that are added to the <envar>PATH</envar>, as described above.
But since these packages only are guaranteed to be able to run then, they shouldn't persist as run-time dependencies.
This isn't currently enforced, but could be in the future.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>depsBuildTarget</varname></term>
<listitem>
<para>
A list of dependencies whose host platform is the new derivation's build platform, and target platform is the new derivation's target platform.
This means a <literal>-1</literal> host offset and <literal>1</literal> target offset from the new derivation's platforms.
They are programs used at build time that produce code to run at run with code produced by the depending package.
Most commonly, these would tools used to build the runtime or standard library the currently-being-built compiler will inject into any code it compiles.
In many cases, the currently-being built compiler is itself employed for that task, but when that compiler won't run (i.e. its build and host platform differ) this is not possible.
Other times, the compiler relies on some other tool, like binutils, that is always built separately so the dependency is unconditional.
</para>
<para>
This is a somewhat confusing dependency to wrap ones head around, and for good reason.
As the only one where the platform offsets are not adjacent integers, it requires thinking of a bootstrapping stage <emphasis>two</emphasis> away from the current one.
It and it's use-case go hand in hand and are both considered poor form:
try not to need this sort dependency, and try not avoid building standard libraries / runtimes in the same derivation as the compiler produces code using them.
Instead strive to build those like a normal library, using the newly-built compiler just as a normal library would.
In short, do not use this attribute unless you are packaging a compiler and are sure it is needed.
</para>
<para>
Since these packages are able to be run at build time, that are added to the <envar>PATH</envar>, as described above.
But since these packages only are guaranteed to be able to run then, they shouldn't persist as run-time dependencies.
This isn't currently enforced, but could be in the future.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>depsHostHost</varname></term>
<listitem><para>
A list of dependencies whose host and target platforms match the new derivation's host platform.
This means a both <literal>0</literal> host offset and <literal>0</literal> target offset from the new derivation's host platform.
These are packages used at run-time to generate code also used at run-time.
In practice, that would usually be tools used by compilers for metaprogramming/macro systems, or libraries used by the macros/metaprogramming code itself.
It's always preferable to use a <varname>depsBuildBuild</varname> dependency in the derivation being built than a <varname>depsHostHost</varname> on the tool doing the building for this purpose.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>buildInputs</varname></term>
<listitem>
<para>
A list of dependencies whose host platform and target platform match the new derivation's.
This means a <literal>0</literal> host offset and <literal>1</literal> target offset from the new derivation's host platform.
This would be called <varname>depsHostTarget</varname> but for historical continuity.
If the dependency doesn't care about the target platform (i.e. isn't a compiler or similar tool), put it here, rather than in <varname>depsBuildBuild</varname>.
</para>
<para>
These often are programs/libraries used by the new derivation at <emphasis>run</emphasis>-time, but that isn't always the case.
For example, the machine code in a statically linked library is only used at run time, but the derivation containing the library is only needed at build time.
Even in the dynamic case, the library may also be needed at build time to appease the linker.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>depsTargetTarget</varname></term>
<listitem><para>
A list of dependencies whose host platform matches the new derivation's target platform.
This means a <literal>1</literal> offset from the new derivation's platforms.
These are packages that run on the target platform, e.g. the standard library or run-time deps of standard library that a compiler insists on knowing about.
It's poor form in almost all cases for a package to depend on another from a future stage [future stage corresponding to positive offset].
Do not use this attribute unless you are packaging a compiler and are sure it is needed.
The propagated equivalent of <varname>nativeBuildInputs</varname>.
This would be called <varname>depsBuildHostPropagated</varname> but for historical continuity.
For example, if package <varname>Y</varname> has <literal>propagatedNativeBuildInputs = [X]</literal>, and package <varname>Z</varname> has <literal>buildInputs = [Y]</literal>, then package <varname>Z</varname> will be built as if it included package <varname>X</varname> in its <varname>nativeBuildInputs</varname>.
If instead, package <varname>Z</varname> has <literal>nativeBuildInputs = [Y]</literal>, then <varname>Z</varname> will be built as if it included <varname>X</varname> in the <varname>depsBuildBuild</varname> of package <varname>Z</varname>, because of the sum of the two <literal>-1</literal> host offsets.
@@ -450,12 +188,58 @@ From a capability perspective, we can imagine that the host and target platforms
<varlistentry>
<term><varname>NIX_DEBUG</varname></term>
<listitem><para>If set, <literal>stdenv</literal> will print some
debug information during the build. In particular, the
<command>gcc</command> and <command>ld</command> wrapper scripts
will print out the complete command line passed to the wrapped
tools.</para></listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>Variables specifying dependencies</title>
<varlistentry>
<term><varname>nativeBuildInputs</varname></term>
<listitem><para>
A natural number indicating how much information to log.
If set to 1 or higher, <literal>stdenv</literal> will print moderate debug information during the build.
In particular, the <command>gcc</command> and <command>ld</command> wrapper scripts will print out the complete command line passed to the wrapped tools.
If set to 6 or higher, the <literal>stdenv</literal> setup script will be run with <literal>set -x</literal> tracing.
If set to 7 or higher, the <command>gcc</command> and <command>ld</command> wrapper scripts will also be run with <literal>set -x</literal> tracing.
A list of dependencies used by the new derivation at <emphasis>build</emphasis>-time.
I.e. these dependencies should not make it into the package's runtime-closure, though this is currently not checked.
For each dependency <replaceable>dir</replaceable>, the directory <filename><replaceable>dir</replaceable>/bin</filename>, if it exists, is added to the <envar>PATH</envar> environment variable.
Other environment variables are also setup via a pluggable mechanism.
For instance, if <varname>buildInputs</varname> contains Perl, then the <filename>lib/site_perl</filename> subdirectory of each input is added to the<envar>PERL5LIB</envar> environment variable.
See <xreflinkend="ssec-setup-hooks"/> for details.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>buildInputs</varname></term>
<listitem><para>
A list of dependencies used by the new derivation at <emphasis>run</emphasis>-time.
Currently, the build-time environment is modified in the exact same way as with <varname>nativeBuildInputs</varname>.
This is problematic in that when cross-compiling, foreign executables can clobber native ones on the <envar>PATH</envar>.
Even more confusing is static-linking.
A statically-linked library should be listed here because ultimately that generated machine code will be used at run-time, even though a derivation containing the object files or static archives will only be used at build-time.
Like <varname>nativeBuildInputs</varname>, but these dependencies are <emphasis>propagated</emphasis>:
that is, the dependencies listed here are added to the <varname>nativeBuildInputs</varname> of any package that uses <emphasis>this</emphasis> package as a dependency.
So if package Y has <literal>propagatedNativeBuildInputs = [X]</literal>, and package Z has <literal>nativeBuildInputs = [Y]</literal>,
then package X will appear in Z’s build environment automatically.
<para>If set to <literal>true</literal>, <literal>stdenv</literal> will
pass specific flags to <literal>make</literal> and other build tools to
enable parallel building with up to <literal>build-cores</literal>
workers.</para>
<para>Unless set to <literal>false</literal>, some build systems with good
support for parallel building including <literal>cmake</literal>,
<literal>meson</literal>, and <literal>qmake</literal> will set it to
<literal>true</literal>.</para>
</listitem>
<listitem><para>If set, <literal>stdenv</literal> will pass specific
flags to <literal>make</literal> and other build tools to enable
parallel building with up to <literal>build-cores</literal>
workers.</para></listitem>
</varlistentry>
<varlistentry>
@@ -871,7 +648,7 @@ script) if it exists.</para>
By default, when cross compiling, the configure script has <option>--build=...</option> and <option>--host=...</option> passed.
Packages can instead pass <literal>[ "build" "host" "target" ]</literal> or a subset to control exactly which platform flags are passed.
Compilers and other tools should use this to also pass the target platform, for example.
<footnote><para>Eventually these will be passed when in native builds too, to improve determinism: build-time guessing, as is done today, is a risk of impurity.</para></footnote>
Note eventually these will be passed when in native builds too, to improve determinism: build-time guessing, as is done today, is a risk of impurity.
</para></listitem>
</varlistentry>
@@ -995,14 +772,13 @@ but only if the <varname>doCheck</varname> variable is enabled.</para>
<varlistentry>
<term><varname>doCheck</varname></term>
<listitem><para>
Controls whether the check phase is executed.
By default it is skipped, but if <varname>doCheck</varname> is set to true, the check phase is usually executed.
Thus you should set <programlisting>doCheck = true;</programlisting> in the derivation to enable checks.
The exception is cross compilation.
Cross compiled builds never run tests, no matter how <varname>doCheck</varname> is set,
as the newly-built program won't run on the platform used to build it.
</para></listitem>
<listitem><para>If set to a non-empty string, the check phase is
executed, otherwise it is skipped (default). Thus you should set
<programlisting>
doCheck = true;</programlisting>
in the derivation to enable checks.</para></listitem>
</varlistentry>
<varlistentry>
@@ -1139,20 +915,6 @@ following:
<listitem><para>If set, libraries and executables are not
stripped. By default, they are.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>dontStripHost</varname></term>
<listitem><para>
Like <varname>dontStripHost</varname>, but only affects the <command>strip</command> command targetting the package's host platform.
Useful when supporting cross compilation, but otherwise feel free to ignore.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>dontStripTarget</varname></term>
<listitem><para>
Like <varname>dontStripHost</varname>, but only affects the <command>strip</command> command targetting the packages' target platform.
Useful when supporting cross compilation, but otherwise feel free to ignore.
Nix itself considers a build-time dependency merely something that should previously be built and accessible at build time—packages themselves are on their own to perform any additional setup.
In most cases, that is fine, and the downstream derivation can deal with it's own dependencies.
But for a few common tasks, that would result in almost every package doing the same sort of setup work---depending not on the package itself, but entirely on which dependencies were used.
</para>
<para>
In order to alleviate this burden, the <firstterm>setup hook></firstterm>mechanism was written, where any package can include a shell script that [by convention rather than enforcement by Nix], any downstream reverse-dependency will source as part of its build process.
That allows the downstream dependency to merely specify its dependencies, and lets those dependencies effectively initialize themselves.
No boilerplate mirroring the list of dependencies is needed.
</para>
<para>
The Setup hook mechanism is a bit of a sledgehammer though: a powerful feature with a broad and indiscriminate area of effect.
The combination of its power and implicit use may be expedient, but isn't without costs.
Nix itself is unchanged, but the spirit of adding dependencies being effect-free is violated even if the letter isn't.
For example, if a derivation path is mentioned more than once, Nix itself doesn't care and simply makes sure the dependency derivation is already built just the same—depending is just needing something to exist, and needing is idempotent.
However, a dependency specified twice will have its setup hook run twice, and that could easily change the build environment (though a well-written setup hook will therefore strive to be idempotent so this is in fact not observable).
More broadly, setup hooks are anti-modular in that multiple dependencies, whether the same or different, should not interfere and yet their setup hooks may well do so.
</para>
<para>
The most typical use of the setup hook is actually to add other hooks which are then run (i.e. after all the setup hooks) on each dependency.
For example, the C compiler wrapper's setup hook feeds itself flags for each dependency that contains relevant libaries and headers.
This is done by defining a bash function, and appending its name to one of
<envar>envBuildBuildHooks</envar>`,
<envar>envBuildHostHooks</envar>`,
<envar>envBuildTargetHooks</envar>`,
<envar>envHostHostHooks</envar>`,
<envar>envHostTargetHooks</envar>`, or
<envar>envTargetTargetHooks</envar>`.
These 6 bash variables correspond to the 6 sorts of dependencies by platform (there's 12 total but we ignore the propagated/non-propagated axis).
</para>
<para>
Packages adding a hook should not hard code a specific hook, but rather choose a variable <emphasis>relative</emphasis> to how they are included.
Returning to the C compiler wrapper example, if it itself is an <literal>n</literal> dependency, then it only wants to accumulate flags from <literal>n + 1</literal> dependencies, as only those ones match the compiler's target platform.
The <envar>hostOffset</envar> variable is defined with the current dependency's host offset <envar>targetOffset</envar> with its target offset, before it's setup hook is sourced.
Additionally, since most environment hooks don't care about the target platform,
That means the setup hook can append to the right bash array by doing something like
<programlistinglanguage="bash">
addEnvHooks "$hostOffset" myBashFunction
</programlisting>
</para>
<para>
The <emphasis>existence</emphasis> of setups hooks has long been documented and packages inside Nixpkgs are free to use these mechanism.
Other packages, however, should not rely on these mechanisms not changing between Nixpkgs versions.
Because of the existing issues with this system, there's little benefit from mandating it be stable for any period of time.
</para>
<para>
Here are some packages that provide a setup hook.
Since the mechanism is modular, this probably isn't an exhaustive list.
Then again, since the mechanism is only to be used as a last resort, it might be.
<para>The following packages provide a setup hook:
<variablelist>
<varlistentry>
<term>Bintools Wrapper</term>
<term>CC Wrapper</term>
<listitem>
<para>
Bintools Wrapper wraps the binary utilities for a bunch of miscellaneous purposes.
These are GNU Binutils when targetting Linux, and a mix of cctools and GNU binutils for Darwin.
[The "Bintools" name is supposed to be a compromise between "Binutils" and "cctools" not denoting any specific implementation.]
Specifically, the underlying bintools package, and a C standard library (glibc or Darwin's libSystem, just for the dynamic loader) are all fed in, and dependency finding, hardening (see below), and purity checks for each are handled by Bintools Wrapper.
Packages typically depend on CC Wrapper, which in turn (at run time) depends on Bintools Wrapper.
CC Wrapper wraps a C toolchain for a bunch of miscellaneous purposes.
Specifically, a C compiler (GCC or Clang), Binutils (or the CCTools + binutils mashup when targetting Darwin), and a C standard library (glibc or Darwin's libSystem) are all fed in, and dependency finding, hardening (see below), and purity checks for each are handled by CC Wrapper.
Packages typically depend on only CC Wrapper, instead of those 3 inputs directly.
</para>
<para>
Bintools Wrapper was only just recently split off from CC Wrapper, so the division of labor is still being worked out.
For example, it shouldn't care about about the C standard library, but just take a derivation with the dynamic loader (which happens to be the glibc on linux).
Dependency finding however is a task both wrappers will continue to need to share, and probably the most important to understand.
Dependency finding is undoubtedly the main task of CC wrapper.
It is currently accomplished by collecting directories of host-platform dependencies (i.e. <varname>buildInputs</varname> and <varname>nativeBuildInputs</varname>) in environment variables.
Bintools Wrapper's setup hook causes any <filename>lib</filename> and <filename>lib64</filename> subdirectories to be added to <envar>NIX_LDFLAGS</envar>.
Since CC Wrapper and Bintools Wrapper use the same strategy, most of the Bintools Wrapper code is sparsely commented and refers to CC Wrapper.
But CC Wrapper's code, by contrast, has quite lengthy comments.
Bintools Wrapper merely cites those, rather than repeating them, to avoid falling out of sync.
CC wrapper's setup hook causes any <filename>include</filename> subdirectory of such a dependency to be added to <envar>NIX_CFLAGS_COMPILE</envar>, and any <filename>lib</filename> and <filename>lib64</filename> subdirectories to <envar>NIX_LDFLAGS</envar>.
The setup hook itself contains some lengthy comments describing the exact convoluted mechanism by which this is accomplished.
</para>
<para>
A final task of the setup hook is defining a number of standard environment variables to tell build systems which executables full-fill which purpose.
They are defined to just be the base name of the tools, under the assumption that Bintools Wrapper's binaries will be on the path.
They are defined to just be the base name of the tools, under the assumption that CC Wrapper's binaries will be on the path.
Firstly, this helps poorly-written packages, e.g. ones that look for just <command>gcc</command> when <envar>CC</envar> isn't defined yet <command>clang</command> is to be used.
Secondly, this helps packages not get confused when cross-compiling, in which case multiple Bintools Wrappers may simultaneously be in use.
<footnote><para>
Each wrapper targets a single platform, so if binaries for multiple platforms are needed, the underlying binaries must be wrapped multiple times.
As this is a property of the wrapper itself, the multiple wrappings are needed whether or not the same underlying binaries can target multiple platforms.
</para></footnote>
<envar>BUILD_</envar>- and <envar>TARGET_</envar>-prefixed versions of the normal environment variable are defined for the additional Bintools Wrappers, properly disambiguating them.
Secondly, this helps packages not get confused when cross-compiling, in which case multiple CC wrappers may be simultaneous in use (targeting different platforms).
<envar>BUILD_</envar>- and <envar>TARGET_</envar>-prefixed versions of the normal environment variable are defined for the additional CC Wrappers, properly disambiguating them.
</para>
<para>
A problem with this final task is that Bintools Wrapper is honest and defines <envar>LD</envar> as <command>ld</command>.
A problem with this final task is that CC Wrapper is honest and defines <envar>LD</envar> as <command>ld</command>.
Most packages, however, firstly use the C compiler for linking, secondly use <envar>LD</envar> anyways, defining it as the C compiler, and thirdly, only so define <envar>LD</envar> when it is undefined as a fallback.
This triple-threat means Bintools Wrapper will break those packages, as LD is already defined as the actual linker which the package won't override yet doesn't want to use.
This triple-threat means CC Wrapper will break those packages, as LD is already defined as the actually linker which the package won't override yet doesn't want to use.
The workaround is to define, just for the problematic package, <envar>LD</envar> as the C compiler.
A good way to do this would be <command>preConfigure = "LD=$CC"</command>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>CC Wrapper</term>
<listitem>
<para>
CC Wrapper wraps a C toolchain for a bunch of miscellaneous purposes.
Specifically, a C compiler (GCC or Clang), wrapped binary tools, and a C standard library (glibc or Darwin's libSystem, just for the dynamic loader) are all fed in, and dependency finding, hardening (see below), and purity checks for each are handled by CC Wrapper.
Packages typically depend on CC Wrapper, which in turn (at run time) depends on Bintools Wrapper.
</para>
<para>
Dependency finding is undoubtedly the main task of CC Wrapper.
This works just like Bintools Wrapper, except that any <filename>include</filename> subdirectory of any relevant dependency is added to <envar>NIX_CFLAGS_COMPILE</envar>.
The setup hook itself contains some lengthy comments describing the exact convoluted mechanism by which this is accomplished.
</para>
<para>
CC Wrapper also like Bintools Wrapper defines standard environment variables with the names of the tools it wraps, for the same reasons described above.
Importantly, while it includes a <command>cc</command> symlink to the c compiler for portability, the <envar>CC</envar> will be defined using the compiler's "real name" (i.e. <command>gcc</command> or <command>clang</command>).
This helps lousy build systems that inspect on the name of the compiler rather than run it.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Perl</term>
<listitem>
<para>
Adds the <filename>lib/site_perl</filename> subdirectory of each build input to the <envar>PERL5LIB</envar> environment variable.
For instance, if <varname>buildInputs</varname> contains Perl, then the <filename>lib/site_perl</filename> subdirectory of each input is added to the <envar>PERL5LIB</envar> environment variable.
</para>
</listitem>
<listitem><para>Adds the <filename>lib/site_perl</filename> subdirectory
of each build input to the <envar>PERL5LIB</envar>
checkConfigError 'The option value .* in .* is not of type.*unsigned integer.*' config.value ./declare-int-unsigned-value.nix ./define-value-int-negative.nix
# positive
checkConfigError 'The option value .* in .* is not of type.*positive integer.*' config.value ./declare-int-positive-value.nix ./define-value-int-zero.nix
checkConfigError 'The option value .* in .* is not of type.*between.*-21 and 43.*inclusive.*' config.value ./declare-int-between-value.nix ./define-value-int-negative.nix
# Check mkForce without submodules.
set -- config.enable ./declare-enable.nix ./define-enable.nix
<para>This section lists the release notes for each stable version of NixOS
and current unstable revision.</para>
<xi:includehref="rl-1803.xml"/>
<xi:includehref="rl-1709.xml"/>
<xi:includehref="rl-1703.xml"/>
<xi:includehref="rl-1609.xml"/>
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.
