In 4.1, the build system changed, and it now wants to execute ld like this:
ld -r -o util/scripting-engines/libperf-in.o util/scripting-engines/trace-event-perl.o util/scripting-engines/trace-event-python.o
The actual problem seems to be that `buildInputs = [elfutils ...]`
causes 'ld' to point to elfutils in PATH instead of the usual binutils.
So remove elfutils from buildInputs and set NIX_CFLAGS_* manually. This
is a slight hack, but there is some precedent:
0761f81da7/pkgs/tools/package-management/rpm/default.nix (L13)Fixes#9095.
This allows all utilties to at least run, though most still fail
because they expect to be able to read a non-existent config file.
Also, aa-notify refuses to run due to a self-check on the filename,
which cannot be preceded by a '.'. This has to be patched or we
need to set PERL5LIB some other way.
This was untested and didn't function without a dbus patch which wasn't
applied to the system dbus package, so it wasn't used at all.
Also, it creates a weird cyclic dependency if we want systemd to depend
on libapparmor (for AppArmorProfiles= support), because libapparmor then
wants dbus, and dbus wants systemd. Oof.
Luckily, this feature and whatnot will probably all be irrelevant in the
glorious kdbus-based future, and the dbus patches aren't even upstream I
think. So we can just drop it.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
`nix-env -qaP -A pkgs.darwin`
pkgs.darwin.libutil:
Commented-out because the package definition doesn't exist. The source
doesn't even provide a Makefile...
pkgs.darwin.objc4_pure:
Commented-out because the package is broken and referencing unknown
applefetchsource and libc_old names. It doesn't seem to be used by any
other packages too.
```
william@exodus ~> htop
htop 1.0.3 aborting. Please report bug at http://hisham.hm/htop
Please include in your report the following backtrace:
htop(CRT_handleSIGSEGV+0x32)[0x4177b2]
/nix/store/xaz2f0mxklh0kh231h6spzbiblq1fm5b-glibc-2.21/lib/libc.so.6(+0x33460)[0x7f9fb9157460]
/nix/store/bdnzh93qibc3cimdw8fj94wwa4wjpw5f-ncurses-6.0/lib/libncursesw.so.6(+0x33f91)[0x7f9fb97faf91]
/nix/store/bdnzh93qibc3cimdw8fj94wwa4wjpw5f-ncurses-6.0/lib/libncursesw.so.6(doupdate_sp+0xc1d)[0x7f9fb97fe0ad]
/nix/store/bdnzh93qibc3cimdw8fj94wwa4wjpw5f-ncurses-6.0/lib/libncursesw.so.6(wrefresh+0x39)[0x7f9fb97ecf09]
/nix/store/bdnzh93qibc3cimdw8fj94wwa4wjpw5f-ncurses-6.0/lib/libncursesw.so.6(_nc_wgetch+0x12a)[0x7f9fb97e583a]
/nix/store/bdnzh93qibc3cimdw8fj94wwa4wjpw5f-ncurses-6.0/lib/libncursesw.so.6(wgetch+0x25)[0x7f9fb97e6555]
htop(ScreenManager_run+0x15a)[0x40ee8a]
htop(main+0x487)[0x4069b7]
/nix/store/xaz2f0mxklh0kh231h6spzbiblq1fm5b-glibc-2.21/lib/libc.so.6(__libc_start_main+0xf5)[0x7f9fb9144995]
htop(_start+0x29)[0x406af9]
Additionally, in order to make the above backtrace useful,
please also run the following command to generate a disassembly of your
binary:
objdump -d `which htop` > ~/htop.objdump
and then attach the file ~/htop.objdump to your bug report.
Thank you for helping to improve htop!
fish: “htop” terminated by signal SIGABRT (Abort)
```
Not sure whether this was broken in the first place (8cd6d53) or if it
went broken afterwards (due to the version bump in 04e39bd), but it
isn't included in the store path at current master.
So I've tested the commit and kbd now correctly includes the Neo layout.
At the upstream URL at http://git.uclibc.org/uClibc/snapshot/, older
versions are dropped at a regular basis. Unfortunately the tarball
"uClibc-20150131.tar.bz2" has already been deleted from that directory
and I didn't find a mirror providing the same file.
So I've switched it to use fetchzip from the cgit site instead of using
fetchgit directly. The reason why I didn't use fetchgit is that we'd
need need git, which depends (indirectly? not sure, haven't checked) on
libiconv and that in turn triggers an assertion if we're on Linux and
are cross-building using uclibc.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This provides support for Ubuntu Fan Networking [1].
This includes:
* The fanctl package, and a corresponding NixOS service.
* iproute patches.
* kernel patches.
closes#9188
1: https://wiki.ubuntu.com/FanNetworking
Close#9218.
It's our default kernel (now and for the upcoming release).
- 304 won't build with 4.1,
- 173 didn't even build with 3.14 due to other issues (3.12 is OK ATM)
- all legacy drivers are up-to-date with upstream releases.
In f18efaf26e, the "patches" attribute was erroneously renamed to
"patch". If you follow the original bug report[1], you'll see that this
has long since been fixed upstream (using a different patch).
1: https://bugs.gentoo.org/show_bug.cgi?id=331447
Pipework lets you connect together containers in arbitrarily complex
scenarios. Pipework uses cgroups and namespace and works with "plain"
LXC containers (created with lxc-start), and with the awesome Docker.
I'm not sure precisely in what micro-version the API change was made, so
the check for 3.18.0 and above may not be quite correct. But it's at
least sufficient for every version currently included in NixOS.
nvidia's EGL stack looks for libGLESv2.so.2 at runtime (confirmed by
watching strace), however builder.sh only provides a libGLESv2.so.1
symlink.
@vcunat ported to legacy_340; older ones don't produce GLES.
An interesting thing is that: stdenv != overrideCC stdenv gcc49;
I'm not sure why that is, but it doesn't seem important.
/cc maintainers: @nckx, @garbas, @abbradar, @cstrahan, @grwlf.
(cherry picked from commit 3064b6a0cc)
An interesting thing is that: stdenv != overrideCC stdenv gcc49;
I'm not sure why that is, but it doesn't seem important.
/cc maintainers: @nckx, @garbas, @abbradar, @cstrahan, @grwlf.
Namespace support is required by the `unshare` tool used in
`nixos-install`. It's enabled by the x86 defconfig, but not by
e.g. multi_v7_defconfig. So enable it here so that `nixos-install`
can work on ARM.
These are not supported by systemd so no reason to keep them around.
(cherry picked from commit ee10e165dc)
Conflicts:
pkgs/os-specific/linux/kernel/linux-3.4.nix
