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>
```
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.
