* sublime3: replace hardcoded /bin/bash with /usr/bin/env
exec.py in Default.package-sublime calls /bin/bash with subprocess.
See Issue #12011. Because of this builds could not be started from
withtin Sublime Text.
* sublime3: use wrapped of bash to fix internal build system
Without the wrapped version of bash (a symlink to $bash/bin/bash)
with LD_PRELOAD to glibc an relocation error occurs when trying
to run builds from within Sublime Text 3. See Issue #12011.
(cherry picked from commit 1893ed54dc)
This allows gitweb to expand '~' in /etc/gitconfig. Without a $HOME
variable, it fails to list any projects and instead show the text
"No such projects found" in the UI.
Setting $HOME to the gitweb project root seems like a sensible value.
(cherry picked from commit d916ce2ef4)
This setting should ensure that email notifications are sent
*only* when the commit caused the build to start failing. That
is, no more "the build is still failing" spam.
As an alternative we could consider disabling email
notifications outright and possibly enable IRC notifications
instead.
(cherry picked from commit 541b3ec1bc)
* Moved the wordpress sources derivation to the attribute pkgs.wordpress. This
makes it easier to override.
* Also introduce the `package` option for the wordpress virtual host config which
defaults to pkgs.wordpress.
* Also fixed the test in nixos/tests/wordpress.nix.
This fixes a somewhat critical (security?) bug.
We are trying to get it merged upstream but have had no response from
the ordinary maintainer in over a week.
(See <https://github.com/keenerd/jshon/issues/53>.)
fixes#23727
(cherry picked from commit 5d6ea2d64e)
Having `glib` in the build inputs will allow its build hook to
trigger. Also adds `gsettings_desktop_schemas` as a dependency since
Eclipse appears to need the schemas under certain circumstances.
(cherry picked from commit 5228bc9f2e)
(cherry picked from commit 0ff2179e0f)
The 3.4 branch is not maintained upstream anymore, and it's probably
vulnerable. Moreover, update to 3.5 should cause no problems.
Both patches are conflicting. Keeping the vulnerability unpatched in qemu
binaries used for nixos test is tolerable.
(cherry picked from commit 3a4e2376e4)
New upstream patch function and patches for fixing a bug in the patch for
CVE-2017-5667 and the following security issues:
* CVE-2016-7907
* CVE-2016-9602
* CVE-2016-10155
* CVE-2017-2620
* CVE-2017-2630
* CVE-2017-5525
* CVE-2017-5526
* CVE-2017-5579
* CVE-2017-5856
* CVE-2017-5857
* CVE-2017-5987
* CVE-2017-6058
(cherry picked from commit c512180f9c)
(cherry picked from commit 641ad2e922)
The LD_LIBRARY_PATH variable does nothing on Darwin, but
DYLD_LIBRARY_PATH does the same thing, so splice in the right variable
based on which system we're working on.
(cherry picked from commit d34ee526a8)
The configuration { services.openssh.enable = true;
services.openssh.forwardX11 = false; } caused
programs.ssh.setXAuthLocation to be set to false, which was not the
intent. The intent is that programs.ssh.setXAuthLocation should be
automatically enabled if needed or if xauth is already available.
(cherry picked from commit d69dce080d)
Fixes:
* CVE-2017-2615
* CVE-2017-5667
* CVE-2017-5898
* CVE-2017-5931
* CVE-2017-5973
We are vulnerable to even more CVEs but those are either not severe like
memory leaks in obscure situations or upstream hasn't acknowledged the
patch yet.
cc #23072
(cherry picked from commit 6bafe64a20)
XSA-197 Issue Description:
> The compiler can emit optimizations in qemu which can lead to double
> fetch vulnerabilities. Specifically data on the rings shared
> between qemu and the hypervisor (which the guest under control can
> obtain mappings of) can be fetched twice (during which time the
> guest can alter the contents) possibly leading to arbitrary code
> execution in qemu.
More: https://xenbits.xen.org/xsa/advisory-197.html
XSA-199 Issue Description:
> The code in qemu which implements ioport read/write looks up the
> specified ioport address in a dispatch table. The argument to the
> dispatch function is a uint32_t, and is used without a range check,
> even though the table has entries for only 2^16 ioports.
>
> When qemu is used as a standalone emulator, ioport accesses are
> generated only from cpu instructions emulated by qemu, and are
> therefore necessarily 16-bit, so there is no vulnerability.
>
> When qemu is used as a device model within Xen, io requests are
> generated by the hypervisor and read by qemu from a shared ring. The
> entries in this ring use a common structure, including a 64-bit
> address field, for various accesses, including ioport addresses.
>
> Xen will write only 16-bit address ioport accesses. However,
> depending on the Xen and qemu version, the ring may be writeable by
> the guest. If so, the guest can generate out-of-range ioport
> accesses, resulting in wild pointer accesses within qemu.
More: https://xenbits.xen.org/xsa/advisory-199.html
XSA-207 Issue Description:
> Certain internal state is set up, during domain construction, in
> preparation for possible pass-through device assignment. On ARM and
> AMD V-i hardware this setup includes memory allocation. On guest
> teardown, cleanup was erroneously only performed when the guest
> actually had a pass-through device assigned.
More: https://xenbits.xen.org/xsa/advisory-207.html
XSA-209 Issue Description:
> When doing bitblt copy backwards, qemu should negate the blit width.
> This avoids an oob access before the start of video memory.
More: https://xenbits.xen.org/xsa/advisory-208.html
XSA-208 Issue Description:
> In CIRRUS_BLTMODE_MEMSYSSRC mode the bitblit copy routine
> cirrus_bitblt_cputovideo fails to check wethehr the specified memory
> region is safe.
More: https://xenbits.xen.org/xsa/advisory-209.html
(cherry picked from commit cc4919da89)
This should solve CVE-2016-5131 and some other bugs, but not what Suse
calls CVE-2016-9597: https://bugzilla.suse.com/show_bug.cgi?id=1017497
The bugzilla discussion seems to indicate that the CVE is referenced
incorrectly and only shows reproducing when using command-line flags
that are considered "unsafe".
CVE-2016-9318 also remains unfixed, as I consider their reasoning OK:
https://lwn.net/Alerts/714411/
/cc #22826.
(cherry picked from commit 5ad81ab09c)
Fixes this:
$ gscriptor
Can't load '/nix/store/17w6hdwbli924v7d43xxxp66qhgqpc24-perl-Pango-1.227/lib/perl5/site_perl/5.22.2/x86_64-linux-thread-multi/auto/Pango/Pango.so' for module Pango: /nix/store/17w6hdwbli924v7d43xxxp66qhgqpc24-perl-Pango-1.227/lib/perl5/site_perl/5.22.2/x86_64-linux-thread-multi/auto/Pango/Pango.so: undefined symbol: cairo_font_type_to_sv at /nix/store/5z1wn7knhckr3a0asb8lzp99sdai09f2-perl-5.22.2/lib/perl5/5.22.2/x86_64-linux-thread-multi/DynaLoader.pm line 193.
at /nix/store/srdac7af3nz6fb74haa8l8ls9wd9pas0-perl-Gtk2-1.2498/lib/perl5/site_perl/5.22.2/x86_64-linux-thread-multi/Gtk2.pm line 31.
Compilation failed in require at /nix/store/srdac7af3nz6fb74haa8l8ls9wd9pas0-perl-Gtk2-1.2498/lib/perl5/site_perl/5.22.2/x86_64-linux-thread-multi/Gtk2.pm line 31.
BEGIN failed--compilation aborted at /nix/store/srdac7af3nz6fb74haa8l8ls9wd9pas0-perl-Gtk2-1.2498/lib/perl5/site_perl/5.22.2/x86_64-linux-thread-multi/Gtk2.pm line 31.
Compilation failed in require at /nix/store/sgy2xsyvmam09pl25x8gb507gyiz9ybn-pcsc-tools-1.4.25/bin/.gscriptor-wrapped line 28.
BEGIN failed--compilation aborted at /nix/store/sgy2xsyvmam09pl25x8gb507gyiz9ybn-pcsc-tools-1.4.25/bin/.gscriptor-wrapped line 28.
(cherry picked from commit 73112a6e78)
This reverts commit fd7e5cbae5.
Apparently there were some potentially disruptive changes,
and the security issues don't seem really important, so perhaps
we won't update, at least for now.
https://github.com/NixOS/nixpkgs/issues/22699
The tests have failed because Chromium has started up displaying the
following error message in a dialog window:
Chromium can not be run as root.
Please start Chromium as a normal user. If you need to run as root for
development, rerun with the --no-sandbox flag.
So let's run as user "alice" and pass all commands using the small
helper function "ru" (to keep it short, it's for "Run as User").
Tested it by running the "stable" test on x86_64-linux.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: @globin
(cherry picked from commit cd10e3c4ff)
* All projects are available under NCSA license,
other than dragonegg.
* "Runtime" projects are dual-licensed under
both NCSA and MIT:
libc++, libc++abi, compiler-rt
* I don't mention MIT for compiler-rt as
we only build it as part of LLVM.
(cherry picked from commit 947c26972b)
html5lib 1.0b9 made a breaking API change that requires beautifulsoup
4.5 or newer, which would require upgrading flexget to support.
See in master 0cb52dc836
* Fix#1132 for SERVFAIL zones perform backoff, and remembers the timeout on next startup.
* Fix null memcpy for radixtree with single link element.
* Robust fix against missing master in tcp_open for xfrd.
* Fix wildcards in include: config statements with chroot enabled.
* suppress compile warning in lex files.
* Fix to try every master once, then wait for timeout or notify.
* Save backoff timeout into xfrd.state file, this file has a higher version number now. Old files are skipped silently (causes refresh) and created as new files upon exit.
* Fix restart of zone transfers when new config becomes available.
From the Debian advisory:
Jann Horn of Google Project Zero discovered that NTFS-3G, a read-write
NTFS driver for FUSE, does not scrub the environment before executing
modprobe with elevated privileges. A local user can take advantage of
this flaw for local root privilege escalation.
(cherry picked from commit 19f23d00fd)
From the Red Hat advisory:
* A vulnerability was discovered in spice in the server's protocol
handling. An authenticated attacker could send crafted messages to
the spice server causing a heap overflow leading to a crash or
possible code execution. (CVE-2016-9577)
* A vulnerability was discovered in spice in the server's protocol
handling. An attacker able to connect to the spice server could send
crafted messages which would cause the process to crash.
(CVE-2016-9578)
(cherry picked from commit 77e920d874)
gst-plugins-bad:
From the Arch Linux advisory:
- CVE-2017-5843 (arbitrary code execution): A double-free issue has
been found in gstreamer before 1.10.3, in
gst_mxf_demux_update_essence_tracks.
- CVE-2017-5848 (denial of service): An out-of-bounds read has been
found in gstreamer before 1.10.3, in gst_ps_demux_parse_psm.
More: https://lwn.net/Vulnerabilities/713772/
gst-plugins-base:
From the Arch Linux advisory:
- CVE-2017-5837 (denial of service): A floating point exception issue
has been found in gstreamer before 1.10.3, in
gst_riff_create_audio_caps.
- CVE-2017-5839 (denial of service): An endless recursion issue
leading to stack overflow has been found in gstreamer before 1.10.3,
in gst_riff_create_audio_caps.
- CVE-2017-5842 (arbitrary code execution): An off-by-one write has
been found in gstreamer before 1.10.3, in
html_context_handle_element.
- CVE-2017-5844 (denial of service): A floating point exception issue
has been found in gstreamer before 1.10.3, in
gst_riff_create_audio_caps.
More: https://lwn.net/Vulnerabilities/713773/
gst-plugins-good:
From the Arch Linux advisory:
- CVE-2016-10198 (denial of service): An invalid memory read flaw has
been found in gstreamer before 1.10.3, in
gst_aac_parse_sink_setcaps.
- CVE-2016-10199 (denial of service): An out of bounds read has been
found in gstreamer before 1.10.3, in qtdemux_tag_add_str_full.
- CVE-2017-5840 (denial of service): An out-of-bounds read has been
found in gstreamer before 1.10.3, in qtdemux_parse_samples.
- CVE-2017-5841 (denial of service): An out-of-bounds read has been
found in gstreamer before 1.10.3, in gst_avi_demux_parse_ncdt.
- CVE-2017-5845 (denial of service): An out-of-bounds read has been
found in gstreamer before 1.10.3, in gst_avi_demux_parse_ncdt.
More: https://lwn.net/Vulnerabilities/713774/
gst-plugins-ugly:
From the Arch Linux advisory:
- CVE-2017-5846 (denial of service): An out-of-bounds read has been
found in gstreamer before 1.10.3, in
gst_asf_demux_process_ext_stream_props.
- CVE-2017-5847 (denial of service): An out-of-bounds read has been
found in gstreamer before 1.10.3, in
gst_asf_demux_process_ext_content_desc.
More: https://lwn.net/Vulnerabilities/713775/
gstreamer:
From the Arch Linux advisory:
An out of bounds read has been found in gstreamer before 1.10.3, in
gst_date_time_new_from_iso8601_string.
More: https://lwn.net/Vulnerabilities/713776/
(cherry picked from commit afd59811a1)
The first release in the 4.9 branch.
I've also migrated my update scripts to SHA-512 so that'll
be the hash of choice for grsec packages going forward.
(cherry picked from commit 0d422c5db5)
Upstream bug: https://bugs.ghostscript.com/show_bug.cgi?id=697457
A new release containing this fix is expected in march; until then,
apply patch from upstream. Note that there have been essentially no
changes between 0.13 and this patch.
(cherry picked from commit 83f83ca434)
The most recent version on the sourceforge page is 0.11 which is quite
old; the official upstream site has 0.13; judging by the commit delta,
there've been quite a few bug fixes etc since 0.11.
(cherry picked from commit 12284fff17)
* packagekit: disable nix-backend
Packagekit fails to build on my machines, as long as it's nix-backend is enabled
* packagekit: add 'enableNixBackend' as an option
(cherry picked from commit fa80bf7b0d)
(cherry picked from commit 7ea20c9e27)
[Bjørn: add lib/maintainers.nix entry. On master branch, this entry
originates from the "kmix: init at 16.12.1" commit (doesn't apply
cleanly on release-16.09).]
libnl was accidentally downgrades to 2.3.29 in
8d342d20b5 instead of being upgraded to
2.3.29 so this fixes that.
(cherry picked from commit 6dcc4623ac)
In category `tools`, subcategory `text`, add a package definition for
the program [`agrep`] [1] — "Approximate `grep` for fast fuzzy string
searching".
I have tested this patch per nixpkgs manual section 11.1 ("Making
patches").
[1]: <https://www.tgries.de/agrep/>
(cherry picked from commit 0033f6076e)
The fixes in NEWS seem like having a possible security impact.
(cherry picked from commit 8e5e365265)
The security update of gnutls-3.5.x won't build against libtasn1-4.8.
In particular, this includes a fix for using ephemeral disks for /tmp,
and adds AMIs for the new eu-west-2 (London) and us-east-2 (Ohio)
regions.
(cherry picked from commit 42a7d906d9)
* Sync systemd units with upstream. Upstream uses SIGUSR2 instead of SIGHUP
to reload the clamd service.
* Convert freshclam service to a oneshot service activated by a systemd timer.
This way we can make clamd wait for freshclam to finish fetching the virus
database before failing to start if the database doesn't exist yet.
* Fixes console tools to work as expected as they require hardcoded config
file locations.
(cherry picked from commit 9e1e3b2880)
This makes the response file handling more consistent with GCC.
For example, a reponse file may contain:
"-Wl,$ORIGIN"
GCC will treat this as a double quoted string and not expand the
variable reference. Previously, cc-wrapper would expand the variable
in the same was as if the string was provided on the command line.
(cherry picked from commit 175461e09b)
The existing URL has gone dark; this commit adds one from fedoraproject.org
that still works. We put the new mirror first since ed is in the bootstrap
path, and 16.09 bootstrap doesn't try later URLs.
(cherry picked from commit 547b203b9a)
Look for primary source file below
http://zlib.net/fossils/ as opposed to
http://zlib.net/
. zlib-1.2.8.tar.gz is still available at the former location, and will likely
remain there. In addition, it's important that the first URL work since zlib
is in the bootstrap path, and 16.09 (at least) bootstrap doesn't try to fetch
from later ones.
(cherry picked from commit d042abef26)
- Floating Point Exception (aka FPE or divide by zero) in
opj_pi_next_cprl function in openjp2/pi.c:523 in OpenJPEG
2.1.2. (CVE-2016-9112)
- There is a NULL Pointer Access in function imagetopnm of
convert.c:1943(jp2) of OpenJPEG 2.1.2. image->comps[compno].data is
not assigned a value after initialization(NULL). Impact is Denial of
Service. (CVE-2016-9114)
- NULL Pointer Access in function imagetopnm of convert.c:2226(jp2) in
OpenJPEG 2.1.2. Impact is Denial of Service. Someone must open a
crafted j2k file. (CVE-2016-9116)
- Heap Buffer Overflow (WRITE of size 4) in function pnmtoimage of
convert.c:1719 in OpenJPEG 2.1.2. (CVE-2016-9118)
(cherry picked from commit 428927ffa6)
This code in amazon-image.nix:
if mountFS "$device" "$mp" "" auto; then
if [ -z "$diskForUnionfs" ]; then diskForUnionfs="$mp"; fi
fi
relies on mountFS to return a zero exit status if mounting
succeeds. But the lustrateRoot check in mountFS was causing a non-zero
exit status. As a result /disk0 would be mounted, but not used for
/tmp.
(cherry picked from commit d082ed8c35dec48aee2afd1303b3c8b2a1b242b0)
(cherry picked from commit b297af42d2)
requiredSystemFeatures is not a meta attribute but a derivation
attribute. So "big-parallel" was being ignored on e.g. chromium,
causing it to be built (and timing out) on slow machines.
http://hydra.nixos.org/build/45819778#tabs-buildsteps
(cherry picked from commit b4f401104d)
It turns out that "journalctl -f | grep -m 1 pattern" will block for
one more line after "pattern" appears, which can take a long time.
(cherry picked from commit bb0ce819b3)
The cobite.com urls seem to have disappeared or been moved. I've failed
to find where they might have gone, so use debian's mirrored sources
instead.
(cherry picked from commit b4c5916e85)
The profile minimal has several drawbacks: no man pages, unusual 'dbus'
lib that makes many X11 pieces to rebuild, etc.
With xz compression in the squashfs, despite these additions, the iso is
smaller than what it was in 16.09.
(cherry picked from commit e0078b2cb5)
Patch is from https://github.com/opencv/opencv/pull/6009. Upstream doesn't
seem particularly enthusiastic about a 3.1.x point release, so who knows
when this fix would otherwise see the light of day.
Mostly a cherry-pick of bcb1cf0db4
Unfortunately bleach depends on an older version of html5lib and cannot
use the latest version because the sanitizer module has been moved out.
https://github.com/mozilla/bleach/issues/217
This item is cherry-picked to unbreak bleach and thus matrix-synapse on stable.
(cherry picked from commit 2f977b4af1)
See #20639. Patch has to be in nixpkgs because fetchurl depends on curl.
(cherry picked from commit 9007303001)
Signed-off-by: Domen Kožar <domen@dev.si>
It seems that it is a GPL violation to distribute zfs in the
installation ISOs.
https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
If anyone knows the issue better and has a reason to reenable it
legally, feel free to reenable it. I don't know much about it.
(cherry picked from commit 33d07c7ea9)
The line
websockets = callPackage ../development/python-modules/websockets { };
was accidentally included in the commit.
(cherry picked from commit c1dd42e7d6)
(cherry picked from commit b5fcd04f1f)
In the `meta`data for the `google-fonts` package --
- the `homepage` field was set to the URL
<https://www.google.com/fontsl>, which would appear to be a
misspelt version of <https://www.google.com/fonts>, which now
redirects to <https://fonts.google.com>.
- the `description` field referred to Google Fonts as "Google Font".
This patch corrects these errors, and updates the `homepage` URL.
(cherry picked from commit 44b932316b)
In a user namespace, sending credentials for an unmapped user return
EINVAL instead of EPERM. So handle that case.
(cherry picked from commit adc2a8f648)
Switching to git tags means we don't get pre-generated configure
scripts. Thusly, run bootstrap ourselves.
For https://github.com/NixOS/nixpkgs/issues/21289
For CVE-2016-8863 (remote code execution)
(cherry picked from commit 0d3f0f05e2)
In a user namespace, sending credentials for an unmapped user return
EINVAL instead of EPERM. So handle that case.
http://hydra.nixos.org/build/44839000
The use of unionfs-fuse (57a0f14064)
slows down the KDE 5 test enough that it hits Hydra timeouts. (E.g. on
my laptop it went from ~5 min to ~30 min.) So disable it for the KDE
test.
http://hydra.nixos.org/build/45127422
This essentially unbreaks deploying new Hetzner machines with NixOps,
because the Hetzner robot has changed its way of handling admin
accounts.
It also now provides a more helpful error message (instead of an
AssertionError) if admin account creation has failed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: Graham Christensen <graham@grahamc.com>
Issue: https://github.com/NixOS/nixops/issues/563
(cherry picked from commit ccbce6b11a)
Notably contains fix for CVE-2016-1254
cc @grahamc
(cherry picked from commit 3e92b56be3)
Note that 0.2.9 is the new stable release, but we'll probably hold off
on putting that onto 16.09 for the time being, unless somebody requests
it sooner. 0.2.8 is in maintenace mode so hopefully still receives
important bugfixes going forward.
This works around:
machine: must succeed: nix-store -qR /run/current-system | grep nixos-
machine# error: changing ownership of path ‘/nix/store’: Invalid argument
Probably Nix shouldn't be anal about the ownership of the store unless
it's trying to build/write to the store.
http://hydra.nixos.org/build/45093872/nixlog/17/raw
The build consists of downloading some stuff & writing a wrapper, the
additional Hydra load is hardly justified.
(cherry picked from commit b55cef7514)
- Fixes#19673; it caused problems in combination with buildEnv.
- As noted, X falls back to /tmp:
https://github.com/NixOS/nixpkgs/issues/19673#issuecomment-258871876
- Removing the directory is still required, as X would attempt to write
into it if allowed - and probably succeed in case the user set
nix.readOnlyStore = false; (X runs as root).
- Archeology link: 9d1569316.
(cherry picked from commit 33abc705b3)
fixes libnss_myhost, libnss_mymachines, libnss_resolve are located here
(cherry picked from commit 3b763fef44)
/cc #21175. I confirm the libraries are located in .out on 16.09 as well.
The 16.09-nixpkgs source tarball Imagemagick-6.9.6-7.tar.xz source tarball is
not available on any of the existing mirrors. We here add one that has it.
(cherry picked from commit e314e5b930)
Without this we get the following Python exception when trying to fetch
a graph in the graphite web app:
File "/nix/store/nj62jqk2xmp5c3h93pfnlqn66qj1kkvs-python-2.7.12-env/lib/python2.7/site-packages/opt/graphite/webapp/graphite/storage.py", line 335, in fetch
return whisper.fetch(self.fs_path, startTime, endTime, now)
TypeError: fetch() takes at most 3 arguments (4 given)
Fixes#21032.
(cherry picked from commit b4005bbac0)
Since Nix now runs builds in a user namespace with uid == 0, this
triggered the message
warning: the group ‘nixbld’ specified in ‘build-users-group’ does not exist
which make-tarball.nix turns into a fatal error. So clear
build-users-group.
http://hydra.nixos.org/build/44817408
(cherry picked from commit 7a586794d4)
The reason to patch QEMU is that with latest Nix, tests like "printing"
or "misc" fail because they expect the store paths to be owned by uid 0
and gid 0.
Starting with NixOS/nix@5e51ffb1c2, Nix
builds inside of a new user namespace. Unfortunately this also means
that bind-mounted store paths that are part of the derivation's inputs
are no longer owned by uid 0 and gid 0 but by uid 65534 and gid 65534.
This in turn causes things like sudo or cups to fail with errors about
insecure file permissions.
So in order to avoid that, let's make sure the VM always gets files
owned by uid 0 and gid 0 and does a no-op when doing a chmod on a store
path.
In addition, this adds a virtualisation.qemu.program option so that we
can make sure that we only use the patched version if we're *really*
running NixOS VM tests (that is, whenever we have imported
test-instrumentation.nix).
Tested against the "misc" and "printing" tests.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(cherry picked from commit 6cfb3b6364)
From release notes:
OPENAFS-SA-2016-003: file and directory names leak due to
reuse of directory objects without zeroing the contents
(12461 12462 12463 12464 12465)
(cherry picked from commit e0b850147d)
Upstream sets the soname, so binaries compiled against libdwarf.so will
link against libdwarf.so.1 at runtime. Install libdwarf.so.1 and
symlink libdwarf.so to it so both linking and runtime loading work again.
(cherry picked from commit 469e5e7768)
Without this, running hhvm fails, for example.
All of the dependencies listed here are used via command-line tools. So
use getBin to avoid unnecessarily depending on development headers.
(cherry picked from commit 5a6d6d4451)
This needs to be included for VirtualBox to detect that it needs to start the video driver. "modesetting" is also set in virtualbox-image.nix but this line seems to take precedence over that one (even though the virtualbox-image.nix has a higher override?) This should fix the problems that I and a few others have been having with the .ova files built for nixos.org.
Fixes#20007.
`systemd.hideProcessInformation = true`, would break interactions
requiring polkit arbitration such as initating poweroff/reboot as a
normal user; the polkit daemon cannot be expected to make decisions
about processes that don't exist as far as it is concerned.
systemd-logind lacks the `sys_ptrace` capability and so needs to be part
of the designated proc gid, even though it runs as root.
Fixes https://github.com/NixOS/nixpkgs/issues/20948
(cherry picked from commit 984d9ebb56)
Per upstream, this contains primarily stability & performance fixes.
Notably, the relase fixes a bug that would sometimes make clients
unusable after leaving standby mode, as well as plugging a memory leak.
(cherry picked from commit d06bf820ea)
This reverts commit e38b74ba89.
I failed to notice f19c961b4e461da045f2e72e73701059e5117be0; better
use that fix instead.
(cherry picked from commit 4c7323545b)
It was lacking the dbus configuration to bind to
org.freedesktop.DisplayManager, and it was passing fixed TTY/display
numbers to the X server (see 9be012f0d4).
(cherry picked from commit 69bea26ea9)
This reverts commit 5d804566df.
This was an error on my part. I had the commit sitting on my local master
and pulled upstream to rebase my commit before pushing. I didn't notice
there was a commit bumping lxc and the auto-merge on the rebase.
(cherry picked from commit e43f2fc868)
This update includes many security related fixes.
Version 4.2.0 fixes:
- CVE-2008-4796
- CVE-2013-4214
Version 4.2.2 fixes:
- CVE-2016-9565
Version 4.2.3 fixes:
- CVE-2016-8641
See https://www.nagios.org/projects/nagios-core/history/4x/ for full
detail changes.
(cherry picked from commit 5b6d52b4fb)
Support for TkAgg was broken due to the package `tk` being split into
multiple outputs: The setup script was unable to locate the tk headers.
This patch fixes that by passing the include path from `tk.dev`
explicitly
Package attempt to write /etc/bash_completion.d, I directed it to
"${out}/etc/bash_completion.d" as it was suggested.
(cherry picked from commit 36053e4907ccee9cd1845da87ae2846384571c0a)
It fails on Hydra now; I can't reproduce it locally and don't feel like
debugging it. It might be due to the warning below. That appears on
x86_64-linux as well, but we've got no problems in there so far...
warning: call to primitive-fork while multiple threads are running;
further behavior unspecified. See "Processes" in the
manual, for more information.
(cherry picked from commit 7a88f314cb)
Fixes#20758.
As of right now, rogue.rogueforge.net has been down for at least several hours
(likely more).
We add two mirrors here which are likely to be more reliable. We keep the
original download location as a fallback, in case that estimate turns out to be
incorrect.
(cherry picked from commit aad48be62b)
Fixes#20713, though I'm certain nixpkgs contains loads of places
without proper quoting, as (ba)sh unfortunately encourages that.
The only plus side is that most of such problems in nixpkgs aren't
actually security problems but mere annoyance to those who are foolish
enough to use "weird" characters in critical names.
(cherry picked from commit 8ebfce0eda)
This is a fix for the current package source file
http://www.greenwoodsoftware.com/less/less-483.tar.gz
not being available anymore.
We bump the less version back to 481, and adjust the source package hash
accordingly. This is a (slight) downgrade from 483 as opposed to an
upgrade since
a) 481 is the current Recommended version by http://www.greenwoodsoftware.com/less/download.html
b) Upstream is unreliable about keeping experimental versions around.
(cherry picked from commit 0f9f74f1d5)
CVE-2015-8972: stack buffer overflow related to user move input, where 160 characters of input can crash gnuchess
(cherry picked from commit 4a5c66135a)
In `scripts/Makefile.modinst`, the code that generates the list of
modules to install passes file names via the command line. When
installing a grsecurity kernel, this list appears to exceed the
shell's argument list limit, as in
make[2]: execvp: /nix/store/[...]-bash-4.3-p46/bin/bash: Argument list too long
The build does not fail, however, but the list of modules to be installed ends
up being empty. Thus, the resulting kernel package output contains no modules,
rendering it useless.
We work around this by patching the makefile to use `find -exec` to
process files. Why this would occur for grsecurity and not other
kernels is unknown, most likely there's something *else* that is
actually causing this behaviour, so this is a temporary fix until that
cause is found.
Fixes https://github.com/NixOS/nixpkgs/issues/20490
(cherry picked from commit e38b74ba89)
Add patch to the clang update.py script for chromium that makes it work
the same as in qt57.qtwebengine. This avoids issues with the
subprocess.call that is used to run update.sh not liking the path it is
passed in certain build enviroments. update.sh is no longer used.
(cherry picked from commit bd0ffa50aa)
This is an updated version of #16561 with added qt.conf to fix QtWebEngineProcess not being able to find locales copied to 5.7
(cherry picked from commit c15f3a8bbe)
This is an updated version of #16561 with added qt.conf to fix QtWebEngineProcess not being able to find locales
(cherry picked from commit cfda4310d6)
The matrix-synapse user has `createHome = true;` which runs before the
`preStart` script, so the home directory will always exist and the block
will never execute.
Also don't include default path to keys in the configuration file,
because synapse will choke if it tries to open them before they
exist (even with `--generate-keys`).
(cherry picked from commit 08d7fbb42d)
since hplip is a Python package that doesn't use setuptools. Note that a
setup.py is provided, however, using buildPythonPackage fails.
(cherry picked from commit d9c7a14c6a)
This is necessary to fix the build for (at least) darwin. If the
arguments are not specified explicitly then homebrew-install locations
are assumed for at least "icu".
Closes#20395.
This reverts commit d393c6c538.
The commit removed C++11 compatibility on darwin by overriding the
--std=c++0x flag in CXXFLAGS. Which lead to a failing build of mapnik,
which depends on the move constructors being available in the icu-lib.
Since it builds fine without the headerpad_max_install_names flag, we
simply undo the change that introduced this flag.
Vagrant on macOS is distributed as a .dmg installer. Luckily, the
internal contents of that archive resemble that of the .deb we use for
linux. In fact, the similarity is enough that if we move its `embedded`
directory to `opt/vagrant/embedded` and its `bin` to `usr/bin` (and back
again after installation), the derivation's installPhase (which replaces
embedded libs & binaries with those from the package's inputs) can
remain exactly the same between macOS and linux.
(cherry picked from commit 224a6b85fa)
Relaxes overly strict bounds on base (3 > && < 4.8). The dataenc
package is unmaintained so there is no corresponding upstream issue.
(cherry picked from commit 31f8367c67)
In the [discussion](https://github.com/NixOS/nixpkgs/pull/18801) of this pull
request @LnL7 was unable to complete a darwin build because the
python_framework.patch does not apply and suggests it should be removed.
(cherry picked from commit d81a6e6f9c)
- fix wrongly used *native* build inputs;
- remove confusing `prePatch = "cd src";` ;
- adapt RPATH handling to multiple-output changes;
- don't list full compiler flags in vim --version,
as that would keep references to -dev paths.
Together, the closure of the default feature-set drops almost by 100 MB.
The lean vim attribute would *not* lose any references due to patching
--version, so we only apply it for vim_configurable.
(cherry picked from commit 51feecbe88)
(cherry picked from commit 1667046505)
The derivations are unchanged, except for being bumped to the last
7.4.x version (I avoided major update to 8.x here).
node.js 0.10 reaches end of LTS in a few days (see https://github.com/nodejs/LTS for details). Therefore I removed it and set 3 dependant packages to broken as they don't build anymore
(cherry picked from commit 162c65fc87)
Signed-off-by: Domen Kožar <domen@dev.si>
`cmake` should be in `nativeBuildInputs` as it is only required at build time. For obvious reasons we can't have the tests running during a cross-compile. I figured I'd update the package version while I was at it, though these changes have also been tested independently of the version update.
(cherry picked from commit 854d16d74e)
This is the merge c67a7ee731 from master
but backported to stable, which brings a bunch of security updates to
Chromium:
CVE-2016-5198: Out of bounds memory access in V8
CVE-2016-5181: Universal XSS in Blink
CVE-2016-5182: Heap overflow in Blink
CVE-2016-5183: Use after free in PDFium
CVE-2016-5184: Use after free in PDFium
CVE-2016-5185: Use after free in Blink
CVE-2016-5187: URL spoofing
CVE-2016-5188: UI spoofing
CVE-2016-5192: Cross-origin bypass in Blink
CVE-2016-5189: URL spoofing
CVE-2016-5186: Out of bounds read in DevTools
CVE-2016-5191: Universal XSS in Bookmarks
CVE-2016-5190: Use after free in Internals
CVE-2016-5193: Scheme bypass
Detailed announcements about these changes can be found here (latest to
oldest):
https://googlechromereleases.blogspot.de/2016/11/stable-channel-update-for-desktop.htmlhttps://googlechromereleases.blogspot.de/2016/10/stable-channel-update-for-desktop_20.htmlhttps://googlechromereleases.blogspot.de/2016/10/stable-channel-update-for-desktop.html
The implementation of this backport differs in that we copy the
cc-wrapper to the Chromium directory and add support for handling
response files. Thanks to @bendlas for the work on this.
Tests and builds pass successfully on my Hydra at:
https://headcounter.org/hydra/eval/339329
Cc: @grahamc, @bendlas, @shlevy, @sternenseemann
Closes: #19565Closes: #20120
Sometimes it happens that the "Type to search or enter a URL to
navigate" popup doesn't show, but all we need to know at this time is
whether Chromium has finished starting up.
So checking for the "startup done" page is a better option here.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Versions before 56 already had experimental support for Gtk 3 and since
version 56, Gtk 3 _seemed_ to become the default. Although it's now
requiring *both* Gtk 2 and Gtk3, so let's supply the dependency for now
to get it to build.
In the future however we might want to add use_gtk3 to the GN flags and
get rid of Gtk 2 completely.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Before version 54, the WideVine CDM plugin was built unconditionally and
it seems since version 54 this now is dependent upon a GYP/GN flag on
whether to include the CDM shared library or not.
Also, we now use a patch from Gentoo which should hopefully get the CDM
plugin to work properly, at least according to their bugtracker:
https://bugs.gentoo.org/show_bug.cgi?id=547630
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Overview of updated versions:
stable: 54.0.2840.71 -> 54.0.2840.90
beta: 55.0.2883.21 -> 55.0.2883.35
dev: 56.0.2897.0 -> 56.0.2906.0
This is to get our Chromium versions in par with the latest upstream
ones before merging in the GN migration changes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
So far we had the bundled Flash player plugin that came with Chrome, but
since version 54 the Chrome package doesn't include PPAPI Flash anymore.
Instead we're going to download the PPAPI Flash plugin directly from
Adobe and try to use them for all release channels of Chromium.
Of course it would be nice if we'd have an updater for it but for now
it's important that we don't break things for people who are currently
forced to use Flash.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Seems that these libraries aren't the ones Chromium is expecting to be,
so let's switch to use the bundled version of these libraries instead.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Previously I've added the extra file common-gn.nix in addition to
common.nix, so we can possibly have a smooth transition from current
stable to the new version 54.
Unfortunately, version 53 is already EOL and we have to move to version
54 as soon as possible so we can only use GN and thus it doesn't make
sense to provide expressions for GYP anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should now be the upstream default and there also is no more flag
for GN to set it, so we'll no longer need it on our side as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This only uses the most basic GN flags which should represent the GYP
flags we had before. In order to get rid most of the GYP cruft, we now
have common.nix and common-gn.nix which are mostly the same, just that
the latter is only for GN builds.
The GN implementation is far from complete and currently not even
builds, so we need more work to get the beta and dev channels building.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is the standalone version of GN used currently solely for building
Chromium. An upstream bug report is available at
https://crbug.com/504074 to support a standalone build without needing
various components from the Chromium source tree.
Because there isn't a standalone vrsion available, I'm choosing
0.0.0.${date} as the version scheme here so that we don't conflict with
versioned releases from upstream someday[TM].
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The previous patch to this file removed the docdev output, but did
not actually provide the files that were in the docdev output in out.
This patch fixes the issue.
(cherry picked from commit 0a2b08884c)
I got:
$ nix-env -f . -iA manpages
$ man mmap
No manual entry for mmap
which is suboptimal for a package that "documents the Linux kernel and
C library interfaces that are employed by user-space programs"
(https://www.kernel.org/doc/man-pages/).
(cherry picked from commit e84a3524b5)
This fixes a build failure caused by a new version of tagsoup
that broke download-curl's dependency bounds
Fixes issue #20141. Backports a minimal change from the regular
Hackage import on master.
* gstreamer-1.0: make gst-launch find plugins again
gst-launch and friends are in the "dev" output now.
* gstreamer-1.0: lower priority on plugins from $NIX_PROFILES
Suffix the plugin paths from $NIX_PROFILES instead of prefixing them to
$GST_PLUGIN_SYSTEM_PATH. If a program has specifically set up its plugin
path to some custom/specific version, we don't want plugins from
$NIX_PROFILES to mess things up by having higher priority.
(cherry picked from commit b1df5bf89b)
It seems very unlikely to break anything.
Otherwise, systemd-logind fails to work because SECCOMP_FILTER cannot be
enabled with OABI_COMPAT set. We don't need OABI_COMPAT at all on ARM, I
guess.
With this change, the rpi kernel boots fine for raspberrypi2.
We discussed this change with Dezgeg.
(cherry picked from commit a97db109a2)
KDE Frameworks 5.26 requires Qt 5.6. Qt 5.6 is a designated LTS release;
only proprietary packages should use older versions.
(cherry picked from commit 16dafb018e)
Include an upstream patch to fix an annoying bug where OSD windows have
the dialog flag set, causing OSDs associated with auto-hiding panels to
be invisible.
(cherry picked from commit ee2d5a3758)
A patch was already included to find the path to Xwayland, but the build
was not actually using it because it wasn't a buildInput.
(cherry picked from commit 1b255790b4)
Previously, the list of CA certificates was generated with a perl script
which is included in curl. As this script is not very flexible, this commit
refactors the expression to use the python script that Debian uses to
generate their CA certificates from Mozilla's trust store in NSS.
[SL: The following was true of the original commit but was backed out
of the cherry pick]:
Additionally, an option was added to the cacerts derivation and the
`security.pki` module to blacklist specific CAs.
(cherry picked from commit 0d59fc1169)
A simple program to read/write from/to any location in memory.
Unfortunately the homepage doesn't have a versioned source code download
URL. On the other hand, the program is pretty stable, with no change for
the last 12 years...
(cherry picked from commit a6283c1126)
This had already been fixed in f52f9bf7cd,
but the problem was reintroduced in
bce59a1a8b because the path to the XML
files changed.
(cherry picked from commit af01fa71e0)
This commit includes two changes:
1. A new `extraConfig` option to allow administrators to set any
vsftpd configuration option that isn't directly supported by this
derivation.
2. Correctly set the `anon_root` vsftpd option to `anonymousUserHome`
(cherry picked from commit d19967bf48)
This commit changes callHackage to use a deterministic version of the Hackage
checkout from https://github.com/commercialhaskell/all-cabal-hashes by default.
This means that packages uploaded to Hackage after today will be available to
callHackage only after "pkgs/data/misc/hackage/default.nix" has been updated.
People who want the previous behavior where we always had the latest version of
Hackage available -- at the cost of frequent downloads from Github --, can add
the following override to their "~/.nixpkgs/config.nix" file:
{
packageOverrides = super: {
all-cabal-hashes = builtins.fetchTarball "https://github.com/commercialhaskell/all-cabal-hashes/archive/hackage.tar.gz";
};
}
(cherry picked from commit fac1168816)
I hope it's without mistake now. I re-checked the download,
avoiding the binary caches where it would go usually.
(cherry picked from commit 80d956caf3)
The test complains[1][2] that
Failed to start message bus: Failed to bind socket "/run/dbus/system_bus_socket": No such file or directory
In 639e5401ff, the dbus socket dir is set
to `/run/dbus`; in the test vm `/var/run/dbus` is used, but the standard
`/run -> /var/run` link is typically not created until stage 2 init, not
in the minimal init used here. Thus, dbus fails to run within the test
environment . Fix by changing `/var/run/dbus` to simply `/run/dbus`.
[1]: https://hydra.nixos.org/build/42534725
[2]: https://hydra.nixos.org/build/42523834
(cherry picked from commit c86fe2224e)
From LWN:
From the NVD entries:
CVE-2016-5501: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality,
integrity, and availability via vectors related to Core, a different
vulnerability than CVE-2016-5538.
CVE-2016-5538: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality,
integrity, and availability via vectors related to Core, a different
vulnerability than CVE-2016-5501.
CVE-2016-5605: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.1.4 in Oracle Virtualization allows remote
attackers to affect confidentiality and integrity via vectors related
to VRDE.
CVE-2016-5608: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect availability via vectors
related to Core, a different vulnerability than CVE-2016-5613.
CVE-2016-5610: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality,
integrity, and availability via vectors related to Core.
CVE-2016-5611: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect confidentiality via
vectors related to Core.
CVE-2016-5613: Unspecified vulnerability in the Oracle VM VirtualBox
component before 5.0.28 and 5.1.x before 5.1.8 in Oracle
Virtualization allows local users to affect availability via vectors
related to Core, a different vulnerability than CVE-2016-5608.
(cherry picked from commit 69e8bac9cd)
Notably, this pulls in the dirtycow fix from upstream (but I've been
unable to execute the POC exploits on grsec kernels without that fix
...)
(cherry picked from commit 5440c1a64c)
It was already ordered after systemd-udev-settle.service, but that
doesn't do anything if no other units require
systemd-udev-settle.service. This was causing random failures during X
server startup, e.g.
machine# [ 12.691372] display-manager[607]: (EE) open /dev/dri/card0: No such file or directory
http://hydra.nixos.org/build/41062823
(cherry picked from commit e6bcff4d53)
As of systemd 231, the LD_LIBRARY_PATH fix applied in the installPhase of rkt's
build was no longer valid, causing rkt to fail to work. This patch changes the
path to point to the new location of libsystemd, which is in ${systemd.lib}.
(cherry picked from commit a0295e21c5)
The hashes are now generated by downloading from a mirror with a
known-good connection because the KDE rotation has several poor
mirrors. Packages are still built by downloading from the rotation.
(cherry picked from commit 85b4359109)
At the time of the last upgrade, the new driver wasn't available on
anything but their US mirror. Pinning to the US mirror isn't
recommended or preferable, but I did it anyway to be able to get the
upgrade out.
(cherry picked from commit 634a098940)
This adds the containers.<name>.enableTun option allowing containers to
access /dev/net/tun. This is required by openvpn, tinc, etc. in order to
work properly inside containers.
The new option builds on top of two generic options
containers.<name>.additionalCapabilities and
containers.<name>.allowedDevices which also can be used for example when
adding support for FUSE later down the road.
Backported to 16.09.
On Linux, libiconv is an alias of glibc. Propagating glibc breaks
using GCC 6 as an override (not sure why). So let's not do that.
(cherry picked from commit dfc94720b8)
If the display managers crashes continuously in loops it prevents the
user from switching to the console and try to fix things. Especially
when using the "auto" display manager it can happen quite easily.
This has more correct semantics, allows for multiple patches, and makes
using overrideDerivation to add/remove patches work as expected.
(cherry picked from commit b1c83e8928)
This is the simplest way to reenable the use of BLCR
(which at present requires linux version >3.12 <3.18)
until we find a better solution.
This reverts commit 6a9e765e27.
Adds support for OAuth2 (among other things).
(cherry picked from commit 3f7d2f72e7)
[Bjørn: Small conflict due to commit 3ba16c82 ("Do not use top-level
buildPythonPackage or buildPythonApplication"), fixed by incorporating
the changes from that commit.]
Tornado 4.0.1 is old and insecure, however, a package still depends on
it. We now move the package from the main Python package set into the
expression of the package that needs it.
(cherry picked from commit 354c588cf2)
Fixes this:
$ echo establish_context | gpshell
establish_context
establish_context failed with error 0xFFFFFFFFFFFFFFFF (libgppcscconnectionplugin.so.1.0.1: cannot open shared object file: No such file or directory)
Have to use LD_LIBRARY_PATH instead of patchelf, because it's
libglobalplatform.so.6 (from globalplatform package) that needs
libgppcscconnectionplugin.so.1.0.1, not gpshell itself. And because
RPATH doesn't "propagate" from one ELF to another, the library isn't
found. One can argue that globalplatform should depend on
gppcscconnectionplugin, but it touches on the still-unsolved "plugin"
issue in Nix packaging, so leaving that alone.
(cherry picked from commit b0d77698bf)
This makes sure that if the system was powered off when the timer was
supposed to trigger, it will run the next time the system boots up.
(cherry picked from commit 1623476904)
Reason: Unobtrusive patch that may fix broken/outdated TLS
certificates, depending on your powered-on/powered-off patterns.
Also update libopenshot (0.1.1 -> 0.1.2) and libopenshot-audio (0.1.1 ->
0.1.2). Both libraries seem to be somewhat version coupled with
openshot (all three projects had a release at the same time).
Openshot now depends on ZMQ.
Test notes: the application runs, but I managed to crash it after doing
this:
* Import pictures and video
* Add two pictures to the timeline (next to each other)
* Drag the 2nd picture partly over over the first
(creates an effect). App dies.
The last output from the app is:
timeline_webview:INFO addTransition...
Unhandled Python exception
Aborted
The same crash happens with v2.0.7 though.
(cherry picked from commit 3e6ce75b8f)
Per #17143 on GitHub, `gnome-maps` currently fails due to missing
Webkit2. Adding `webkitgtk` to `buildInputs` fixes the issue.
(cherry picked from commit ecd41c19b8)
(cherry picked from commit 6c6ebf5d33)
A bugfix release, recommended for all users by upstream. In
particular, it resolves an issue that potentially could result in
unwanted data loss.
The builder does almost nothing, and I hate to have to copy hundreds of
megabytes to a builds slave because of that.
(cherry picked from commit a745f87b7f)
Regression introduced by 4dcb685af9.
Unsetting the environment variable shortly before using it is not going
to end up very well, so let's just filter out the variable from the
output of export and unset it shortly afterwards.
This fixes the runInMachine NixOS test.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(cherry picked from commit b4e2b6bc6a)
This fixes two bugs:
* When socket activation is detected, the service itself is added to stop-start list instead of its sockets.
* When service is marked to restart instead of stop (`StopIfChanged = no`) we don't need to restart sockets.
(cherry picked from commit d37458ad06)
This is a standard environment that doesn't contain a C/C++
compiler. This is mostly to prevent trivial builders like runCommand
and substituteAll from pulling in gcc for simple configuration changes
on NixOS.
(cherry picked from commit 0cb16a6955)
Obviously there are more improvements that can be done here,
especially moving headers to .dev, but that's not entirely trivial and
probably not worth it since kde4 is old.
(cherry picked from commit d65af13533)
Fixes#18840: too large closure of mesa_drivers.
Tested atop 16.09:
- clang compiles a hello-world app;
- mesa seems to link OK;
- ispc builds.
Size comparison:
- 80 MB of full llvm-3.7 on 16.03;
- 200 MB of full llvm-3.9 on 16.09 before this patch;
- 50 MB of libLLVM after this commit.
(cherry picked from commit d2965a7d85)
By deduplicating libXvMC*.so and {r600,radionsi}_drv_video.so, this
reduces the size of the drivers output from 63.3 MiB to 49.8 MiB.
(cherry picked from commit 28a659974a)
The use of multiple outputs in libarchive broke it. Since this is an
ancient version of cmake, let's fix it by just using
--no-system-libarchive.
(cherry picked from commit e03d1ababa)
The following changes are included:
1) install user unit files from upstream dbus
2) use absolute paths to config for --system and --session instances
3) make socket activation of user units configurable
There has been a number of PRs to address this, so this one does the
bare minimum, which is to make the functionality available and
configurable but defaults to off.
Related PRs:
- #18382
- #18222
Avoid these warnings from being errors:
usbredirhost.c: In function 'usbredirhost_can_write_iso_package':
usbredirhost.c:1023:19: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
DEBUG("START dropping isoc packets %lu buffer > %lu hi threshold",
^
usbredirhost.c:1023:19: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
DEBUG("START dropping isoc packets %lu buffer > %lu hi threshold",
^
usbredirhost.c:1028:19: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
DEBUG("STOP dropping isoc packets %lu buffer < %lu low threshold",
^
usbredirhost.c:1028:19: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
DEBUG("STOP dropping isoc packets %lu buffer < %lu low threshold",
^
usbredirhost.c: In function 'usbredirhost_set_iso_threshold':
usbredirhost.c:1162:11: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
DEBUG("higher threshold is %lu bytes | lower threshold is %lu bytes",
^
usbredirhost.c:1162:11: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
DEBUG("higher threshold is %lu bytes | lower threshold is %lu bytes",
I think in all of these cases, the incorrect format modifier just causes
wrong debug prints on i686.
(cherry picked from commit b3af42011b)
Since some changes to the setuid wrappers, there is a symlink involved
and it doesn't resolve correctly inside the chroot. Do the check inside
the chroot to make it work again.
(cherry picked from commit a34ec1517f)
- Set a cmake flag to allow cmake to find CUDA automatically.
- Pass -D_FORCE_INLINES to work around
/nix/store/8sl4jfs3nq0pkq4gg655s3axrxdx7z29-glibc-2.24-dev/include/string.h: In function 'void* __mempcpy_inline(void*, const void*, size_t)':
/nix/store/8sl4jfs3nq0pkq4gg655s3axrxdx7z29-glibc-2.24-dev/include/string.h:650:42: error: 'memcpy' was not declared in this scope
https://github.com/BVLC/caffe/issues/4046
This fixes OpenSubdiv and Blender.
(cherry picked from commit 5ade8fff79)
We need to rewrite attributes passed via files to their location in
/tmp/xchg in the VM. Otherwise functions like runCommand don't work.
(cherry picked from commit 75baee8523)
Probably as a result of 992c514a20, it
was not being started anymore.
My understanding of systemd.special(7) (section "Special passive
system units") is that the firewall should want network-pre.target,
rather than the other way around (not very intuitive...). This in
itself does not cause the firewall to be wanted, which is why the
wanted-by relationship with multi-user.target is necessary.
http://hydra.nixos.org/build/39965589
(cherry picked from commit abdc5961c3)
We were pulling in 44 MiB of fonts in the default configuration, which
is a bit excessive for headless configurations like EC2
instances. Note that dejavu_minimal ensures that remote X11-forwarded
applications still have a basic font regardless.
(cherry picked from commit 5b5c2fb9c0)
It appears that packageOverrides no longer overrides aliases, so
aliases like
dbus_tools = self.dbus.out;
dbus_daemon = self.dbus.daemon;
now use the old, non-overriden version of dbus. That seems like a
pretty serious regression in general, but for this particular problem,
I've fixed it by replacing dbus_daemon by dbus.daemon and dbus_tools
by dbus.
(cherry picked from commit ba70ce28ae)
Get rid of the "or null" stuff. Also change 'cfg . "foo"' to 'cfg.foo'.
Also fixed what appears to be an actual bug: in postStartScript,
cfg.attribute (where attribute is a function argument) should be
cfg.${attribute}.
(cherry picked from commit b9df84cd4f)
This works around missing newer wayland symbols when running
some older packages on a system with updated opengl drivers.
We have no good solution yet, unfortunately. This commit might
break packages that rely on new wayland features, but those
should be a minority.
(cherry picked from commit 7a003eb9d5)
Every interactive zsh sources /etc/zshrc (see STARTUP/SHUTDOWN FILES in zshautll(1))
Therefor every interactive zsh process will respect the content of these variables.
Using `export` will also lead to child processes inheriting this value.
This leads to problems, if other interactive shells are spawned such as bash,
because they use an incomptabible history format (without timestamps).
There seems to be also cases, where the local HISTSIZE in ~/.zshrc is
not sourced but /etc/zshrc, which leads to history truncation in other shells.
(cherry picked from commit 9049ab1a3b)
Includes supporting binary src for x86_64-linux, x86_64-darwin, and
i686-linux which were previously unsupported and failed grossly before.
(cherry picked from commit 46ff1c385f)
The hash provided in commit 072917ea5d is
faulty, either because the upstream tarball has changed or because it
was wrong in the first place, no matter what happened we can't really
verify if we don't have the tarball with the old hash.
To double-check I've verified the hash against the one from Gentoo[1],
which has the following SHA256:
b46c26a9e773b2c620acd2f96d69408f14a279aefaedfefed002ecf898a1ecf2
After being converted into base 32 the hash does match with ours.
Note that I haven't tested building all Chromium channels (yet), but we
can fix upcoming issues later because right now it doesn't build anyway
because of the failing hash check.
[1]: https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/chromium/Manifest?id=2de0f5e4ffeb46a478c589b21d5bbcfd5736e57b
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(cherry picked from commit 0c2683cc11)
jq has not had a release since v1.5 in August 2015, so backport both of
these patches (the fix for CVE-2015-8863 is in the current master, while
the fix for CVE-2016-4074 is not yet in master).
(cherry picked from commit bfbca9dacd)
It'll likely be useful because of #16779, at least for some users.
Most of the change sneaked in c68850c6b already, by mistake.
(cherry picked from commit 0593ad2b16)
...instead of mesa_noglu.out. Closures of systems remain unchanged,
as both are in (and the .out output is very small anyway).
This is to make sure that we use lib*GL* that aren't slowed down by grsecurity.
(cherry picked from commit c68850c6be)
All swap device option sets "have" a label, it's just that sometimes it's
undefined. Because we set a `device` attribute when we have a label anyway it's
ok to just check device prefix.
Fixes#18891.
(cherry picked from commit a63ca1bf3d)
CockroachDB is failing to build on `x86_64-darwin` according to
Hydra. I don't have a Mac or Windows machine to debug the builds
on so I can't support those.
(cherry picked from commit 65198a9082)
Configuration format has changed from MongoDB 2.6 to
YAML and MongoDB 2.4 is EOL since March 2016.
(cherry picked from commit 5cd565e507)
Signed-off-by: Domen Kožar <domen@dev.si>
* influxdb module: add postStart
* cadvisor module: increase TimeoutStartSec
Under high load, the cadvisor module can take longer than the default 90
seconds to start. This change should hopefully fix the test on Hydra.
(cherry picked from commit 2d2c311304)
If a gemspec has UTF-8 characters in it, ruby will fail loading it with
invalid multibyte char (US-ASCII)
This change forces the encoding to be correct, we assume everyone now
uses UTF-8.
(cherry picked from commit 62df82efcf)
Using types.str doesn't work if you want to mkBefore/mkAfter across
different module definitions, because it only allows for one definition
for the same priority.
This is especially useful if you deploy Hetzner machines via NixOps,
because the physical specification already defines localCommands.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(cherry picked from commit 97801380b0)
It looks like the cpu type part of modalias might have changed, my
systems (4.4.20 and 4.7.2) show something like the following:
```
cpu:type:x86,ven0000fam0006mod003F:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0017,0018,0019,001A,001C,002B,0034,003B,003D,0068,006F,0070,0072,0074,0075,0076,007D,0080,0081,0089,008C,008D,0091,0093,0094,0095,0096,0097,0098,0099,009A,009B,009C,009D,009E,009F,00C0,00C5,0120,0123,0125,0127,0128,0129,012A,0140
```
Update the rngd modalias rule to match this so udev properly has
systemd start rngd.
(cherry picked from commit a560223119)
Fixes#18712. Now firefox uses the notification daemon, if available.
Unfortunately, the same approach didn't work for thunderbird; I don't
know why.
(cherry picked from commit f27a970f2d)
- logDriver option, use journald for logging by default
- keep storage driver intact by default, as docker has sane defaults
- do not choose storage driver in tests, docker will choose by itself
- use dockerd binary as "docker daemon" command is deprecated and will be
removed
- add overlay2 to list of storage drivers
(cherry picked from commit 5d9c62541a)
bower2nix and fetch-bower need git in the PATH to operate. This wrapping
got lost with the nodePackages updates.
(Fixes#18454)
(cherry picked from commit 952c477f90)
Also change to https src.url.
Changelog at https://www.opensmtpd.org/announces/release-6.0.0.txt
In particular, note that
- logging format has been reworked so scripts that consume opensmtpd
logs may need updating
- dhparams option has been removed
(cherry picked from commit 2db487e6bf)
(cherry picked from commit 040b941b4c)
No problems reported so far, and we've got a couple weeks to stabilize
anyway. It seems required to support some new GPUs, #17991.
Enables previously manually disabled stackprotector and stackguard
randomization.
From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511811:
If glibc is built with the --enable-stackguard-randomization option,
each application gets a random canary value (at runtime) from /dev/urandom.
If --enable-stackguard-randomization is absent, applications get a static
canary value of "0xff0a0000". This is very unfortunate, because the
attacker may be able to bypass the stack protection mechanism, by placing
those 4 bytes in the canary word, before the actual canary check is
performed (for example in memcpy-based buffer overflows).
(cherry picked from commit 3ba99f83a7)
Note: only basic testing has been done so far; also see FIXME items.
AMENDed to reduce git history size significantly:
- fix 2015->2016 bugs in fixedHashes.nix
- purge all sha512 from pkgs.nix
It's not clear to me what this is achieving, plus for some reason this
is causing an evaluation error in hyperterm. So let's hope it's not
really needed...
(cherry picked from commit 06b2ff50b9)
This moves libsystemd.so and libudev.so into systemd.lib, and gets rid
of libudev (which just contained a copy of libudev.so and the udev
headers). It thus reduces the closure size of all packages that
(indirectly) depend on libsystemd, of which there are quite a few (for
instance, PulseAudio and dbus). For example, it reduces the closure of
Blender from 430.8 to 400.8 MiB.
(cherry picked from commit 78178d5854)
This removes locales, bash completion and crap like that. This cuts
6.5 MiB from the NixOS system closure (which unfortunately contains
two copies of util-linux, because of the need to break a dependency
cycle with systemd).
(cherry picked from commit 8295089e6a)
This introduces VirtualBox version 5.1.6 along with a few refactored
stuff, notably:
* Kernel modules and user space applications are now separate
derivations.
* If config.pulseaudio doesn't exist in nixpkgs config, the default is
now to build with PulseAudio modules.
* A new updater to keep VirtualBox up to date.
All subtests in nixos/tests/virtualbox.nix succeed on my machine and
VirtualBox was reported to be working by @DamienCassou (although with
unrelated audio problems for another fix/branch) and @calbrecht.
(cherry picked from commit 1781e95577)
These changes are needed to be able to run the system emulator (QEMU)
from Android Studio. In addition to the added dependencies,
$LD_LIBRARY_PATH had to be changed from --set to --prefix, so that libGL
is found (on NixOS).
(cherry picked from commit 3e5fe418f8)
This commit fixes a problem that occurs with externally linked haskell
libraries on Darwin. It does this by adding the libraries to the
--extra-lib-dirs flag and the DYLD_LIBRARY_PATH environment variable.
(cherry picked from commit 475c8bfb7d)
Compiling python with "-Wl,-stack_size,1000000" causes problems when
compiling for example pygobject3. pygobject3 uses "python3.x-config
--ldflags" during installation and then fails when
"-Wl,-stack_size,1000000" is present. Maybe we should investigate
removing this during the build of pyobject3, but this stack_size flag is
also not used on the popular darwin homebrew-core channel for python3.5,
so it seems safe to remove it.
(cherry picked from commit b7819e38c4)
The packages "which" and "ncurses" are needed for building pygobject3
(on darwin) during the checkPhase. The ncurses library is necessary only
because python3.5 is currently built using "-lncurses" and pygobject3
wants the same libraries that python3.5 was compiled with. (Because it
uses "python3.5-config --ldflags" during the build)
(cherry picked from commit 717c76716f)
I see no use to keep it. I doesn't build since April,
and noone has bothered to fixup the multiple-output problem.
(cherry picked from commit f348e6ff5a)
Some parts are slightly puzzling, but it seems to work and it didn't
seem economical to put more effort into it.
(cherry picked from commit 001bde3df0)
When using the rsync:// protocol, duplicity expects to find the rsync binary in the path.
Without rsync in the path, duplicity fails with the following error
Attempt 1 failed. AttributeError: 'NoneType' object has no attribute 'rfind'
Adding rsync to the path enables the rsync:// protocol to work correctly.
(cherry picked from commit 8df0bb7aac)
[Bjørn: sort alphabetially in plugins.nix, capitalize meta.description,
add space around assignment operator, indent multi-line string.]
(cherry picked from commit efb5206701)
Configuring haste-compiler-0.5.5.0...
Setup: At least the following dependencies are missing:
HTTP -any,
bzlib -any,
either -any,
ghc-simple -any,
system-fileio -any,
tar -any
The commit message in 1a2b47463b is
incorrect -- the package seemed to work because only the help message
was invoked:
result/bin/txt2man -h
To guard against such trivial successes, this commit introduces a
test.
(cherry picked from commit 440d721915)
This partially reverts commit ab9537ca22.
From the manpage of systemd-nspawn(1):
Note that systemd-nspawn will mount file systems private to the
container to /dev, /run and similar.
Testing this in a shell turns out:
$ sudo systemd-nspawn --bind-ro=/nix/store "$(readlink "$(which ls)")" /proc
Spawning container aszlig on /home/aszlig.
Press ^] three times within 1s to kill container.
/etc/localtime does not point into /usr/share/zoneinfo/, not updating
container timezone.
1 execdomains kpageflags stat
acpi fb loadavg swaps
asound filesystems locks sys
buddyinfo fs meminfo sysrq-trigger
bus interrupts misc sysvipc
cgroups iomem modules thread-self
cmdline ioports mounts timer_list
config.gz irq mtrr timer_stats
consoles kallsyms net tty
cpuinfo kcore pagetypeinfo uptime
crypto key-users partitions version
devices keys scsi vmallocinfo
diskstats kmsg self vmstat
dma kpagecgroup slabinfo zoneinfo
driver kpagecount softirqs
Container aszlig exited successfully.
So the test on whether PID 1 exists in /proc is enough, because if we
use PID namespaces there actually _is_ a PID 1 (as shown above) and the
special file systems are already mounted. A test on the $containers
variable actually mounts them twice.
This unbreaks NixOS containers and I've tested this against the
containers-imperative NixOS test.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @rickynils, @shlevy, @edolstra
(cherry picked from commit dd98b6fb9f)
This reverts commit 3c0fdefd84.
We have to keep more history because travis build could be
triggered after new commit is made, meaning it won't be able
to checkout the repository.
(cherry picked from commit e986cb3425)
Signed-off-by: Domen Kožar <domen@dev.si>
The loopback-based tests use a storage size of 102400 blocks (one block
is 1024 bytes), which doesn't seem to fit for btrfs volumes in recent
btrfs versions. I'm setting this to 409600 (400 MB) now so that it
should be enough for later versions in case they need even more space
for subvolumes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(cherry picked from commit 75efdc6502)
Signed-off-by: Domen Kožar <domen@dev.si>
Fixes this:
$ sudo mcelog
...
unknown-error-trigger: line 21: logger: command not found
unknown-error-trigger: line 22: logger: command not found
(cherry picked from commit 2bf421d197)
linphone stil uses polarssl, which was replaced by mbedTLS and is no
more available on NixOS.
Until this is fixed upstream we disable LIME (IM encryption).
(cherry picked from commit 273898f4ba)
Signed-off-by: Domen Kožar <domen@dev.si>
3.10.2 is available from github but there is no autoconfigured tarball
and they added a dependency that's not packaged for nix (bctoolbox)
(cherry picked from commit 53c4003559)
Signed-off-by: Domen Kožar <domen@dev.si>
This update was generated by hackage2nix v2.0.1-6-geb712e9 using the following inputs:
- Hackage: 306f478c30
- LTS Haskell: d7ece2dc93
- Stackage Nightly: e911d6ed33
This way, stage-2 behaves correctly also for libvirt-lxc containers.
Some more discussion on this:
a7a08188bfbfe46a653b
(cherry picked from commit ab9537ca22)
The following doesn't seem to be quite right and I have missed this when
I was introducing qtkeychain in the first place:
-- Installing: /nix/store/...-qtkeychain-0.4.0/$out/share/qt/translations/qtkeychain_de.qm
-- Installing: /nix/store/...-qtkeychain-0.4.0/$out/share/qt/translations/qtkeychain_ro.qm
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(cherry picked from commit da24fbd0ec)
Fixes#14910 and #18358
Deployed to an existing server, restarted sshd and polkit to verify
they don't fail.'
(cherry picked from commit 8f95e6f6aa)
Signed-off-by: Domen Kožar <domen@dev.si>
@ehmry: please have a look so that we can cherry-pick in release-16.09
and move forward on #18209
(cherry picked from commit 39e197ab1c)
Signed-off-by: Domen Kožar <domen@dev.si>
Fixes the following security problems:
- CVE-2016-5147: Universal XSS in Blink
- CVE-2016-5148: Universal XSS in Blink
- CVE-2016-5149: Script injection in extensions
- CVE-2016-5150: Use after free in Blink
- CVE-2016-5151: Use after free in PDFium
- CVE-2016-5152: Heap overflow in PDFium
- CVE-2016-5153: Use after destruction in Blink
- CVE-2016-5154: Heap overflow in PDFium
- CVE-2016-5155: Address bar spoofing
- CVE-2016-5156: Use after free in event bindings
- CVE-2016-5157: Heap overflow in PDFium
- CVE-2016-5158: Heap overflow in PDFium
- CVE-2016-5159: Heap overflow in PDFium
- CVE-2016-5160: Extensions web accessible resources bypass
- CVE-2016-5161: Type confusion in Blink.
- CVE-2016-5162: Extensions web accessible resources bypass
- CVE-2016-5163: Address bar spoofing
- CVE-2016-5164: Universal XSS using DevTools
- CVE-2016-5165: Script injection in DevTools
- CVE-2016-5166: SMB Relay Attack via Save Page As
- CVE-2016-5167: Various fixes from internal audits, fuzzing and other initiatives
(cherry picked from commit 7949e69382)
````
run_tests.sh: interpreter directive changed from "/bin/bash" to "/nix/store/nyj6xd7s1n1w8c0xdwk5ddhi7bjcyi9x-bash-4.3-p46/bin/bash"
No virtual environment found...create one? (Y/n) builder for ‘/nix/store/qcrhq2f7llvzyc37ili94ff50z7vlgn3-python2.7-keystoneclient-1.8.1.drv’ failed with exit code 1
error: build of ‘/nix/store/qcrhq2f7llvzyc37ili94ff50z7vlgn3-python2.7-keystoneclient-1.8.1.drv’ failed
````
(cherry picked from commit 2ae5fb2723)
As the comment indicates this was a workaround that has since been fixed
upstream.
(cherry picked from commit 3beacc4dbe)
Signed-off-by: Domen Kožar <domen@dev.si>
This builds elisp to setup an emacs buffer with the packages given
available. See shlevy/nix-buffer for more information.
Currently only modifies $PATH.
(cherry picked from commit 05c132486d)
gnomepanel was part of Gnome 2 and is currently broken.
There seemed to be no runtime dependency to gnomepanel and building also
seems to work fine without it.
(cherry picked from commit 1a5bb68696)
The -rc kernels are quite likely to break out-of-tree modules and thus
cause unnecessary Hydra failures.
(Note that linux_testing already has `hydraPlatforms = [];` but that
does not prevent the package from being built since it has reverse
dependencies. Arguably that could be considered undesirable and thus
fixing that could be considered the proper fix, but this should do
for now.)
(cherry picked from commit c536a3fa2f)
The new setuid-wrappers in /run cannot be executed by users due to:
1) the temporary directory does not allow access
2) the /run is mounted nosuid
(cherry picked from commit 8d977ead38)
Signed-off-by: Domen Kožar <domen@dev.si>
Version 5 does not yet work with the ghcWithHoogle infrastructure. This
fixes Hoogle to version 4 as a temporary measure.
(cherry picked from commit f9f680013c)
Signed-off-by: Domen Kožar <domen@dev.si>
Fixes build against dpdk 16.06
Tested build against linux, linux_latest, linux_3_18, linux_4_1,
linux_4_6, linux_grsec_nixos, linux_chromiumos_3_18.
While this is pre-release, the delta since 10.10.1.0 seems to contain
primarily fixes or internal improvements.
Also cleanup build inputs while we're at it.
(cherry picked from commit 65786ba322)
After splitting the DejaVuSans.ttf file into a multiple output in the
dejavu_fonts Nixpkgs expression it is not possible to install in the
user profile due to the collision. The attached patch makes a new
package without the collision for user environment installing.
From fae78903c6ce56eda70a1a9a6914c41d248b15e8 Mon Sep 17 00:00:00 2001
From: Karn Kallio <kkallio@skami.org>
Date: Sat, 3 Sep 2016 14:09:36 -0400
Subject: [PATCH] dejavu-fonts : Prepare an environment package without
collision.
(cherry picked from commit a785cec01b)
I don't know why the builder uses `lndir ${dbus-python} $out`,
but this commit should work around the problem caused by
dbus-python starting to propagate some inputs.
(cherry picked from commit fcc76325ef)
Looks to be incompatible with the PaX constification plugin:
> /tmp/nix-build-wireguard-unstable-2016-08-08.drv-0/WireGuard-experimental-0.0.20160808/src/device.c:329:29: error: constified variable 'link_ops' placed into writable section ".data..read_mostly"
static struct rtnl_link_ops link_ops __read_mostly = {
https://hydra.nixos.org/build/39671573/log/raw
See also https://github.com/NixOS/nixpkgs/issues/18209
(cherry picked from commit ca465eeeb1)
In the pygobject package of pythonPackages the codegen python files are
executable and get wrapped, which causes pygtk to not build because it
uses the python program to execute them. The attached patch makes them
not executable so they do not get wrapped and cause pygtk to fail its
build.
From 931b7998658fa72323c9a76e7b336fe726a9cc61 Mon Sep 17 00:00:00 2001
From: Karn Kallio <kkallio@skami.org>
Date: Fri, 2 Sep 2016 15:30:42 -0400
Subject: [PATCH] pygobject: prevent wrapping of codegen/*.py files.
(cherry picked from commit ce3daae51a)
* the default output for buildGoPackage is not "out" anymore
* go 1.7 has removed the linker flag deprecation which breaks packer's
Makefile
(cherry picked from commit 511344a56d)
Signed-off-by: Domen Kožar <domen@dev.si>
These are now showing up as broken builds in Hydra since 2daefaf457.
None of these compiled even in 16.03 and I think all of them are
for pretty obsolete hardware, so just mark them as broken.
(In principle the xorg generator could be made to ignore them but that
would be more work.)
(cherry picked from commit 79d673e21c)
After making multiple outputs in the mesa_glu package the headers are
not included in the mesa attribute. The attached patch puts them in it.
From ced24208a300bea8234e7898ae6fec34fbd67289 Mon Sep 17 00:00:00 2001
From: Karn Kallio <kkallio@skami.org>
Date: Thu, 1 Sep 2016 16:18:23 -0400
Subject: [PATCH] mesa: Add the mesa glu headers to the mesa attribute.
(cherry picked from commit 49d59ce0ad)
@@ -14,22 +14,14 @@ under the terms of [COPYING](../COPYING), which is an MIT-like license.
* Format the commits in the following way:
```
(pkg-name | service-name): (from -> to | init at version | refactor | etc)
(Motivation for change. Additional information.)
```
`(pkg-name | service-name): (from -> to | init at version | refactor | etc)`
Examples:
* nginx: init at 2.0.1
* firefox: 3.0 -> 3.1.1
* hydra service: add bazBaz option
Dual baz behavior is needed to do foo.
* nginx service: 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
@@ -38,12 +30,6 @@ under the terms of [COPYING](../COPYING), which is an MIT-like license.
See the nixpkgs manual for more details on how to [Submit changes to nixpkgs](https://nixos.org/nixpkgs/manual/#chap-submitting-changes).
## Writing good commit messages
In addition to writing properly formatted commit messages, it's important to include relevant information so other developers can later understand *why* a change was made. While this information usually can be found by digging code, mailing list archives, pull request discussions or upstream changes, it may require a lot of work.
For package version upgrades and such a one-line commit message is usually sufficient.
## Reviewing contributions
See the nixpkgs manual for more details on how to [Review contributions](https://nixos.org/nixpkgs/manual/#sec-reviewing-contributions).
* [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.03 release](https://hydra.nixos.org/jobset/nixos/release-17.03)
* [Continuous package builds for 16.09 release](https://hydra.nixos.org/jobset/nixos/release-16.09)
* [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
* [Tests for 17.03 release](https://hydra.nixos.org/job/nixos/release-17.03/tested#tabs-constituents)
* [Tests for 16.09 release](https://hydra.nixos.org/job/nixos/release-16.09/tested#tabs-constituents)
"Cross-compilation" means compiling a program on one machine for another type of machine.
For example, a typical use of cross compilation is to compile programs for embedded devices.
These devices often don't have the computing power and memory to compile their own programs.
One might think that cross-compilation is a fairly niche concern, but there are advantages to being rigorous about distinguishing build-time vs run-time environments even when one is developing and deploying on the same machine.
Nixpkgs is increasingly adopting 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>
This chapter will be organized in three parts.
First, it will describe the basics of how to package software in a way that supports cross-compilation.
Second, it will describe how to use Nixpkgs when cross-compiling.
Third, it will describe the internal infrastructure supporting cross-compilation.
<title>Packaging in a cross-friendly manner</title>
<section>
<title>Platform parameters</title>
<para>
The three GNU Autoconf platforms, <wordasword>build</wordasword>, <wordasword>host</wordasword>, and <wordasword>cross</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 are guaranteed to contain at least a <varname>platform</varname> field, which contains detailed information on the platform.
All three are always defined at the top level, so one can get at them just like a dependency in a function that is imported with <literal>callPackage</literal>:
These platforms should all have the same structure in all scenarios, but that is currently not the case.
When not cross-compiling, they will each contain a <literal>system</literal> field with a short 2-part, hyphen-separated summering string name for the platform.
But, when when cross compiling, <literal>hostPlatform</literal> and <literal>targetPlatform</literal> may instead contain <literal>config</literal> with a fuller 3- or 4-part string in the manner of LLVM.
We should have all 3 platforms always contain both, and maybe give <literal>config</literal> a better name while we are at it.
</para></warning>
<variablelist>
<varlistentry>
<term><varname>buildPlatform</varname></term>
<listitem><para>
The "build platform" is the platform on which a package is built.
Once someone has a built package, or pre-built binary package, the build platform should not matter and be safe to ignore.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>hostPlatform</varname></term>
<listitem><para>
The "host platform" is the platform on which a package is run.
This is the simplest platform to understand, but also the one with the worst name.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>targetPlatform</varname></term>
<listitem>
<para>
The "target platform" is black sheep.
The other two intrinsically apply to all compiled software—or any build process with a notion of "build-time" followed by "run-time".
The target platform only applies to programming tools, and even then only is a good for for some of them.
Briefly, GCC, Binutils, GHC, and certain other tools are written in such a way such that a single build can only compiler code for a single platform.
Thus, when building them, one must think ahead about what platforms they wish to use the tool to produce machine code for, and build binaries for each.
</para>
<para>
There is no fundamental need to think about the target ahead of time like this.
LLVM, for example, was designed from the beginning with cross-compilation in mind, and so a normal LLVM binary will support every architecture that LLVM supports.
If the tool supports modular or pluggable backends, one might imagine specifying a <emphasis>set</emphasis> of target platforms / backends one wishes to support, rather than a single one.
</para>
<para>
The biggest reason for mess, if there is one, is that many compilers have the bad habit a build process that builds the compiler and standard library/runtime together.
Then the specifying target platform is essential, because it determines the host platform of the standard library/runtime.
Nixpkgs tries to avoid this where possible too, but still, because the concept of a target platform is so ingrained now in Autoconf and other tools, it is best to support it as is.
Tools like LLVM that don't need up-front target platforms can safely ignore it like normal packages, and it will do no harm.
</para>
</listitem>
</varlistentry>
</variablelist>
<note><para>
If you dig around nixpkgs, you may notice there is also <varname>stdenv.cross</varname>.
This field defined as <varname>hostPlatform</varname> when the host and build platforms differ, but otherwise not defined at all.
This field is obsolete and will soon disappear—please do not use it.
</para></note>
</section>
<section>
<title>Specifying Dependencies</title>
<para>
As mentioned in the introduction to this chapter, one can think about a build time vs run time distinction whether cross-compiling or not.
In the case of cross-compilation, this corresponds with whether a derivation running on the native or foreign platform is produced.
An interesting thing to think about is how this corresponds with the three Autoconf platforms.
In the run-time case, the depending and depended-on package simply have matching build, host, and target platforms.
But in the build-time case, one can imagine "sliding" the platforms one over.
The depended-on package's host and target platforms (respectively) become the depending package's build and host platforms.
This is the most important guiding principle behind cross-compilation with Nixpkgs, and will be called the <wordasword>sliding window principle</wordasword>.
In this 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.
If a package is being built with a <literal>(build, host, target)</literal> platform triple of <literal>(foo, bar, bar)</literal>, then its build-time dependencies would have a triple of <literal>(foo, foo, bar)</literal>, and <emphasis>those packages'</emphasis> build-time dependencies would have triple of <literal>(foo, foo, foo)</literal>.
In other words, it should take two "rounds" of following build-time dependency edges before one reaches a fixed point where, by the sliding window principle, the platform triple no longer changes.
Indeed, this happens with cross compilation, where only rounds of native dependencies starting with the second necessarily coincide with native packages.
</para>
<note><para>
The depending package's target platform is unconstrained by the sliding window principle, which makes sense in that one can in principle build cross compilers targeting arbitrary platforms.
</para></note>
<para>
How does this work in practice? Nixpkgs is now structured so that build-time dependencies are taken from 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 four attributes used for specifying dependencies as documented in <linklinkend="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.
<varname>system</varname> and <varname>platform</varname> together determine the system on which packages are built, and <varname>crossSystem</varname> specifies the platform on which packages are ultimately intended to run, if it is different.
This still works, but with more recent changes, one can alternatively pass <varname>localSystem</varname>, containing <varname>system</varname> and <varname>platform</varname>, for symmetry.
</para>
<para>
One would think that <varname>localSystem</varname> and <varname>crossSystem</varname> overlap horribly with the three <varname>*Platforms</varname> (<varname>buildPlatform</varname>, <varname>hostPlatform,</varname> and <varname>targetPlatform</varname>; see <varname>stage.nix</varname> or the manual).
Actually, those identifiers are purposefully not used here to draw a subtle but important distinction:
While the granularity of having 3 platforms is necessary to properly *build* packages, it is overkill for specifying the user's *intent* when making a build plan or package set.
A simple "build vs deploy" dichotomy is adequate: the sliding window principle described in the previous section shows how to interpolate between the these two "end points" to get the 3 platform triple for each bootstrapping stage.
That means for any package a given package set, even those not bound on the top level but only reachable via dependencies or <varname>buildPackages</varname>, the three platforms will be defined as one of <varname>localSystem</varname> or <varname>crossSystem</varname>, with the former replacing the latter as one traverses build-time dependencies.
A last simple difference then is <varname>crossSystem</varname> should be null when one doesn't want to cross-compile, while the <varname>*Platform</varname>s are always non-null.
<varname>localSystem</varname> is always non-null.
If one explores nixpkgs, they will see derivations with names like <literal>gccCross</literal>.
Such <literal>*Cross</literal> derivations is a holdover from before we properly distinguished between the host and target platforms
—the derivation with "Cross" in the name covered the <literal>build = host != target</literal> case, while the other covered the <literal>host = target</literal>, with build platform the same or not based on whether one was using its <literal>.nativeDrv</literal> or <literal>.crossDrv</literal>.
@@ -74,6 +74,7 @@ can do is write a simple Nix expression which sets up an environment for you,
requiring you only to type `nix-shell`. Say we want to have Python 3.5, `numpy`
and `toolz`, like before, in an environment. With a `shell.nix` file
containing
```nix
withimport<nixpkgs>{};
@@ -96,29 +97,26 @@ We will first have a look at how Python packages are packaged on Nix. Then, we w
#### Python packaging on Nix
On Nix all packages are built by functions. The main function in Nix for building Python packages is [`buildPythonPackage`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/python/build-python-package.nix).
On Nix all packages are built by functions. The main function in Nix for building Python packages is [`buildPythonPackage`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/python-modules/generic/default.nix).
Let's see how we would build the `toolz` package. According to [`python-packages.nix`](https://raw.githubusercontent.com/NixOS/nixpkgs/master/pkgs/top-level/python-packages.nix) `toolz` is build using
Note also the line `doCheck = false;`, we explicitly disabled running the test-suite.
#### Develop local package
As a Python developer you're likely aware of [development mode](http://setuptools.readthedocs.io/en/latest/setuptools.html#development-mode) (`python setup.py develop`);
As a Python developer you're likely aware of [development mode](http://pythonhosted.org/setuptools/setuptools.html#development-mode) (`python setup.py develop`);
instead of installing the package this command creates a special link to the project code.
That way, you can run updated code without having to reinstall after each and every change you make.
Development mode is also available. Let's see how you can use it.
Development mode is also available on Nix as [explained](http://nixos.org/nixpkgs/manual/#ssec-python-development) in the Nixpkgs manual.
Let's see how you can use it.
In the previous Nix expression the source was fetched from an url. We can also refer to a local source instead using
`src = ./path/to/source/tree;`
```nix
src=./path/to/source/tree;
```
If we create a `shell.nix` file which calls `buildPythonPackage`, and if `src`
is a local source, and if the local source has a `setup.py`, then development
It is important to note that due to how development mode is implemented on Nix it is not possible to have multiple packages simultaneously in development mode.
@@ -422,21 +409,36 @@ and in this case the `python35` interpreter is automatically used.
### Interpreters
Versions 2.7, 3.3, 3.4, 3.5 and 3.6 of the CPython interpreter are available as
respectively`python27`, `python33`, `python34`, `python35` and `python36`. The PyPy interpreter
is available as `pypy`. The aliases `python2` and `python3` correspond to respectively `python27` and
`python35`. The default interpreter,`python`, maps to`python2`.
The Nix expressions for the interpreters can be found in
Versions 2.6, 2.7, 3.3, 3.4 and 3.5 of the CPython interpreter are available on
Nix and are available as `python26`,`python27`, `python33`, `python34` and
`python35`. The PyPy interpreter is also available as `pypy`. Currently, the
aliases `python` and`python3` correspond to respectively`python27` and
`python35`. The Nix expressions for the interpreters can be found in
`pkgs/development/interpreters/python`.
#### Missing modules standard library
The interpreters `python26` and `python27` do not include modules that
require external dependencies. This is done in order to reduce the closure size.
The following modules need to be added as `buildInput` explicitly:
*`python.modules.bsddb`
*`python.modules.curses`
*`python.modules.curses_panel`
*`python.modules.crypt`
*`python.modules.gdbm`
*`python.modules.sqlite3`
*`python.modules.tkinter`
*`python.modules.readline`
For convenience `python27Full` and `python26Full` are provided with all
modules included.
All packages depending on any Python interpreter get appended
`out/{python.sitePackages}` to `$PYTHONPATH` if such directory
exists.
#### Missing `tkinter` module standard library
To reduce closure size the `Tkinter`/`tkinter` is available as a separate package, `pythonPackages.tkinter`.
#### Attributes on interpreters packages
Each interpreter has the following attributes:
@@ -446,21 +448,18 @@ Each interpreter has the following attributes:
-`buildEnv`. Function to build python interpreter environments with extra packages bundled together. See section *python.buildEnv function* for usage and documentation.
-`withPackages`. Simpler interface to `buildEnv`. See section *python.withPackages function* for usage and documentation.
-`sitePackages`. Alias for `lib/${libPrefix}/site-packages`.
-`executable`. Name of the interpreter executable, e.g.`python3.4`.
-`pkgs`. Set of Python packages for that specific interpreter. The package set can be modified by overriding the interpreter and passing `packageOverrides`.
-`executable`. Name of the interpreter executable, ie `python3.4`.
### Building packages and applications
Python libraries and applications that use `setuptools` or
`distutils` are typically build with respectively the `buildPythonPackage` and
`buildPythonApplication` functions. These two functions also support installing a `wheel`.
Python packages (libraries) and applications that use `setuptools` or
`distutils` are typically built with respectively the `buildPythonPackage` and
`buildPythonApplication` functions.
All Python packages reside in `pkgs/top-level/python-packages.nix` and all
applications elsewhere. In case a package is used as both a library and an application,
then the package should be in `pkgs/top-level/python-packages.nix` since only those packages are made
available for all interpreter versions. The preferred location for library expressions is in
applications elsewhere. Some packages are also defined in
`pkgs/development/python-modules`. It is important that these packages are
called from`pkgs/top-level/python-packages.nix` and not elsewhere, to guarantee
called in`pkgs/top-level/python-packages.nix` and not elsewhere, to guarantee
the right version of the package is built.
Based on the packages defined in `pkgs/top-level/python-packages.nix` an
@@ -472,42 +471,35 @@ sets are
*`pkgs.python33Packages`
*`pkgs.python34Packages`
*`pkgs.python35Packages`
*`pkgs.python36Packages`
*`pkgs.pypyPackages`
and the aliases
*`pkgs.python2Packages` pointing to `pkgs.python27Packages`
*`pkgs.pythonPackages` pointing to `pkgs.python27Packages`
*`pkgs.python3Packages` pointing to `pkgs.python35Packages`
*`pkgs.pythonPackages` pointing to `pkgs.python2Packages`
#### `buildPythonPackage` function
The `buildPythonPackage` function is implemented in
description = "Twisted, an event-driven networking engine written in Python";
license = stdenv.lib.licenses.mit; };
};
The `buildPythonPackage` mainly does four things:
@@ -542,7 +534,7 @@ All parameters from `mkDerivation` function are still supported.
* `postShellHook`: Hook to execute commands after `shellHook`.
* `makeWrapperArgs`: A list of strings. Arguments to be passed to `makeWrapper`, which wraps generated binaries. By default, the arguments to `makeWrapper` set `PATH` and `PYTHONPATH` environment variables before calling the binary. Additional arguments here can allow a developer to set environment variables which will be available when the binary is run. For example, `makeWrapperArgs = ["--set FOO BAR" "--set BAZ QUX"]`.
* `installFlags`: A list of strings. Arguments to be passed to `pip install`. To pass options to `python setup.py install`, use `--install-option`. E.g., `installFlags=["--install-option='--cpp_implementation'"].
*`format`: Format of the source. Valid options are `setuptools` (default), `flit`, `wheel`, and `other`. `setuptools` is for when the source has a `setup.py` and `setuptools` is used to build a wheel, `flit`, in case `flit` should be used to build a wheel, and `wheel` in case a wheel is provided. In case you need to provide your own `buildPhase` and `installPhase` you can use `other`.
*`format`: Format of the source. Options are `setup` for when the source has a `setup.py` and `setuptools` is used to build a wheel, and `wheel` in case the source is already a binary wheel. The default value is `setup`.
*`catchConflicts` If `true`, abort package build if a package name appears more than once in dependency tree. Default is `true`.
*`checkInputs` Dependencies needed for running the `checkPhase`. These are added to `buildInputs` when `doCheck = true`.
@@ -557,32 +549,29 @@ Because with an application we're not interested in multiple version the prefix
Python environments can be created using the low-level `pkgs.buildEnv` function.
This example shows how to create an environment that has the Pyramid Web Framework.
Recursively updating a package can be done with `pkgs.overridePackages` as explained in the Nixpkgs manual.
Python attribute sets are created for each interpreter version. We will therefore override the attribute set for the interpreter version we're interested.
In the following example we change the name of the package `pandas` to `foo`.
The requested package `blaze` depends on `pandas` which itself depends on`scipy`.
A typical use case is to switch to another version of a certain package. For example, in the Nixpkgs repository we have multiple versions of `django` and`scipy`.
In the following example we use a different version of `scipy`. All packages in `newpkgs` will now use the updated `scipy` version.
```
with import <nixpkgs> {};
If you want the whole of Nixpkgs to use your modifications, then you can use `overlays`
as explained in this manual. In the following example we build a `inkscape` using a different version of `numpy`.
@@ -807,32 +776,32 @@ This is because files are included that depend on items in the Nix store which h
The command `bdist_wheel` takes into account `SOURCE_DATE_EPOCH`, and `nix-shell` sets this to 1. By setting it to a value corresponding to 1980 or later, or by unsetting it, it is possible to build wheels.
If you are using the `bepasty-server` package somewhere, for example in `systemPackages` or indirectly from `services.bepasty`, then a `nixos-rebuild switch` will rebuild the system but with the `bepasty-server` package using a different `src` attribute. This way one can modify `python` based software/libraries easily. Using `self` and `super` one can also alter dependencies (`buildInputs`) between the old state (`self`) and new state (`super`).
## Contributing
@@ -926,8 +825,7 @@ If you are using the `bepasty-server` package somewhere, for example in `systemP
Following rules are desired to be respected:
*Python libraries are supposed to be called from `python-packages.nix` and packaged with `buildPythonPackage`. The expression of a library should be in `pkgs/development/python-modules/<name>/default.nix`. Libraries in `pkgs/top-level/python-packages.nix` are sorted quasi-alphabetically to avoid merge conflicts.
*Python applications live outside of `python-packages.nix` and are packaged with `buildPythonApplication`.
*Make sure libraries build for all Python interpreters.
*By default we enable tests. Make sure the tests are found and, in the case of libraries, are passing for all interpreters. If certain tests fail they can be disabled individually. Try to avoid disabling the tests altogether. In any case, when you disable tests, leave a comment explaining why.
* Commit names of Python libraries should include `pythonPackages`, for example `pythonPackages.numpy: 1.11 -> 1.12`.
*Make sure package builds for all python interpreters. Use `disabled` argument to `buildPythonPackage` to set unsupported interpreters.
*If tests need to be disabled for a package, make sure you leave a comment about reasoning.
*Packages in `pkgs/top-level/python-packages.nix` are sorted quasi-alphabetically to avoid merge conflicts.
*Python libraries are supposed to be in `python-packages.nix` and packaged with `buildPythonPackage`. Python applications live outside of `python-packages.nix` and are packaged with `buildPythonApplication`.
<para>Qt is a comprehensive desktop and mobile application development toolkit for C++. Legacy support is available for Qt 3 and Qt 4, but all current development uses Qt 5. The Qt 5 packages in Nixpkgs are updated frequently to take advantage of new features, but older versions are typically retained to support packages that may not be compatible with the latest version. When packaging applications and libraries for Nixpkgs, it is important to ensure that compatible versions of Qt 5 are used throughout; this consideration motivates the tools described below.</para>
<para>The information in this section applies to Qt 5.5 and later.</para>
<para>Qt is an application development toolkit for C++. Although it is
not a distinct programming language, there are special considerations
for packaging Qt-based programs and libraries. A small set of tools
and conventions has grown out of these considerations.</para>
<para>Libraries that depend on Qt 5 should be built with each available version to avoid linking a dependent package against incompatible versions of Qt 5. (Although Qt 5 maintains backward ABI compatibility, linking against multiple versions at once is generally not possible; at best it will lead to runtime faults.) Packages that provide libraries should be added to the top-level function <varname>mkLibsForQt5</varname>, which is used to build a set of libraries for every Qt 5 version. The <varname>callPackage</varname> provided in this scope will ensure that only one Qt version will be used throughout the dependency tree. Dependencies should be imported unqualified, i.e. <literal>qtbase</literal> not <literal>qt5.qtbase</literal>, so that <varname>callPackage</varname> can do its work. <emphasis>Do not</emphasis> import a package set such as <literal>qt5</literal> or <literal>libsForQt5</literal> into your package; although it may work fine in the moment, it could well break at the next Qt update.</para>
<para>If a library does not support a particular version of Qt 5, it is best to mark it as broken by setting its <literal>meta.broken</literal> attribute. A package may be marked broken for certain versions by testing the <literal>qtbase.version</literal> attribute, which will always give the current Qt 5 version.</para>
<para>Packages that provide libraries should be listed in
<varname>qt5LibsFun</varname> so that the library is built with each
Qt version. A set of packages is provided for each version of Qt; for
example, <varname>qt5Libs</varname> always provides libraries built
with the latest version, <varname>qt55Libs</varname> provides
libraries built with Qt 5.5, and so on. To avoid version conflicts, no
top-level attributes are created for these packages.</para>
<para>Applications generally do not need to be built with every Qt version because they do not provide any libraries for dependent packages to link against. The primary consideration is merely ensuring that the application itself and its dependencies are linked against only one version of Qt. To call your application expression, use <literal>libsForQt5.callPackage</literal> instead of <literal>callPackage</literal>. Dependencies should be imported unqualified, i.e. <literal>qtbase</literal> not <literal>qt5.qtbase</literal>. <emphasis>Do not</emphasis> import a package set such as <literal>qt5</literal> or <literal>libsForQt5</literal> into your package; although it may work fine in the moment, it could well break at the next Qt update.</para>
<para>Application packages do not need to be built with every Qt
version. To ensure consistency between the package's dependencies,
call the package with <literal>qt5Libs.callPackage</literal> instead
of the usual <literal>callPackage</literal>. An older version may be
selected in case of incompatibility. For example, to build with Qt
5.5, call the package with
<literal>qt55Libs.callPackage</literal>.</para>
<para>It is generally best to build an application package against the <varname>libsForQt5</varname> library set. In case a package does not build with the latest Qt version, it is possible to pick a set pinned to a particular version, e.g. <varname>libsForQt55</varname> for Qt 5.5, if that is the latest version the package supports.</para>
<para>Several environment variables must be set at runtime for Qt
applications to function correctly, including:</para>
<para>Qt-based applications require that several paths be set at runtime. This is accomplished by wrapping the provided executables in a package with <literal>wrapQtProgram</literal> or <literal>makeQtWrapper</literal> during the <literal>postFixup</literal> phase. To use the wrapper generators, add <literal>makeQtWrapper</literal> to <literal>nativeBuildInputs</literal>. The wrapper generators support the same options as <literal>wrapProgram</literal> and <literal>makeWrapper</literal> respectively. It is usually only necessary to generate wrappers for programs intended to be invoked by the user.</para>
accepts the same options as <literal>makeWrapper</literal>.
</para>
</section>
<sectionxml:id="ssec-qt-kde"><title>KDE</title>
<para>The KDE Frameworks are a set of libraries for Qt 5 which form the basis of the Plasma desktop environment and the KDE Applications suite. Packaging a Frameworks-based library does not require any steps beyond those described above for general Qt-based libraries. Frameworks-based applications should not use <literal>makeQtWrapper</literal>; instead, use <literal>kdeWrapper</literal> to create the necessary wrappers: <literal>kdeWrapper { unwrapped = <replaceable>expr</replaceable>; targets = <replaceable>exes</replaceable>; }</literal>, where <replaceable>expr</replaceable> is the un-wrapped package expression and <replaceable>exes</replaceable> is a list of strings giving the relative paths to programs in the package which should be wrapped.</para>
<para>Many of the considerations above also apply to KDE packages,
especially the need to set the correct environment variables at
runtime. To ensure that this is done, invoke <literal>wrapKDEProgram
<replaceable>program</replaceable></literal> during
installation. <literal>wrapKDEProgram</literal> also generates a
<literal>ksycoca</literal> database so that required data and services
can be found. Like its Qt counterpart,
<literal>wrapKDEProgram</literal> accepts the same options as
<para>The support code currently recognizes some particular kinds of outputs and either instructs the build system of the package to put files into their desired outputs or it moves the files during the fixup phase. Each group of file types has an <varname>outputFoo</varname> variable specifying the output name where they should go. If that variable isn't defined by the derivation writer, it is guessed – a default output name is defined, falling back to other possibilities if the output isn't defined.</para>
<variablelist>
<varlistentry><term><varname>
$outputDev</varname></term><listitem><para>
is for development-only files. These include C(++) headers, pkg-config, cmake and aclocal files. They go to <varname>dev</varname> or <varname>out</varname> by default.
</para></listitem>
</varlistentry>
</para></listitem></varlistentry>
<varlistentry><term><varname>
$outputBin</varname></term><listitem><para>
is meant for user-facing binaries, typically residing in bin/. They go to <varname>bin</varname> or <varname>out</varname> by default.
</para></listitem></varlistentry>
</para></listitem></varlistentry>
<varlistentry><term><varname>
$outputLib</varname></term><listitem><para>
is meant for libraries, typically residing in <filename>lib/</filename> and <filename>libexec/</filename>. They go to <varname>lib</varname> or <varname>out</varname> by default.
</para></listitem></varlistentry>
</para></listitem></varlistentry>
<varlistentry><term><varname>
$outputDoc</varname></term><listitem><para>
is for user documentation, typically residing in <filename>share/doc/</filename>. It goes to <varname>doc</varname> or <varname>out</varname> by default.
</para></listitem></varlistentry>
</para></listitem></varlistentry>
<varlistentry><term><varname>
$outputDevdoc</varname></term><listitem><para>
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.
</para></listitem></varlistentry>
$outputDocdev</varname></term><listitem><para>
is for <emphasis>developer</emphasis> documentation. Currently we count gtk-doc and man3 pages in there. It goes to <varname>devdoc</varname> or is removed (!) by default. This is because e.g. gtk-doc tends to be rather large and completely unused by nixpkgs users.
</para></listitem></varlistentry>
<varlistentry><term><varname>
$outputMan</varname></term><listitem><para>
is for man pages (except for section 3). They go to <varname>man</varname> or <varname>doc</varname> or <varname>$outputBin</varname> by default.
</para></listitem></varlistentry>
<varlistentry><term><varname>
$outputDevman</varname></term><listitem><para>
is for section 3 man pages. They go to <varname>devman</varname> or <varname>$outputMan</varname> by default.
</para></listitem></varlistentry>
</para></listitem></varlistentry>
<varlistentry><term><varname>
$outputInfo</varname></term><listitem><para>
is for info pages. They go to <varname>info</varname> or <varname>doc</varname> or <varname>$outputMan</varname> by default.
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 set up 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.
A less confusing solution to this would be nice.
</para></listitem>
<listitem><para>A list of dependencies used by
<literal>stdenv</literal> to set up the environment for the build.
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 set up 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
Like <varname>nativeBuildInputs</varname>, but these dependencies are <emphasis>propagated</emphasis>:
that is, the dependencies listed here are added to the <varname>nativeBuildInputs</varname> of any package that uses <emphasis>this</emphasis> package as a dependency.
So if package Y has <literal>propagatedBuildInputs = [X]</literal>, and package Z has <literal>buildInputs = [Y]</literal>, then package X will appear in Z’s build environment automatically.
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.
