Instead of putthing them in the wrong place and then pointing alog at it
via default config, put them in the right place and don't touch the
default config.
This reverts commit ff1e372849.
We only want to build GCC once. Cross compilation infrastructure means
this should not be needed.
Revert "arm-frc-linux-gnueabi-gcc: init at 4.9.4"
This reverts commit ff1e372849.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/efivar/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/09zlj936d2jvjwdmj9c9f843fd86bcs3-efivar-35/bin/efivar -h’ got 0 exit code
- ran ‘/nix/store/09zlj936d2jvjwdmj9c9f843fd86bcs3-efivar-35/bin/efivar --help’ got 0 exit code
- ran ‘/nix/store/09zlj936d2jvjwdmj9c9f843fd86bcs3-efivar-35/bin/efivar help’ got 0 exit code
- found 35 with grep in /nix/store/09zlj936d2jvjwdmj9c9f843fd86bcs3-efivar-35
- directory tree listing: https://gist.github.com/6f811428a47ee181fc412ef78ff64450
This has already been patched against gnumake4 (519f0b8db2)
but we still have packages depending on gnumake3, so let's also apply
the same patch to gnumake 3.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @shlevy, @vcunat
During the last staging merge I assume that we turned on
-Werror=format-security by default (haven't checked in-depth though),
which actually is a good thing.
This causes the rtkit build to now fail, so I took a patch from Debian
to fix these issues.
Signed-off-by: aszlig <aszlig@nix.build>
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/knot-dns/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/p1k7d2y5aa4haxlkkn2jadviwvl5plcc-ipset-6.38/bin/ipset -h’ got 0 exit code
- ran ‘/nix/store/p1k7d2y5aa4haxlkkn2jadviwvl5plcc-ipset-6.38/bin/ipset --help’ got 0 exit code
- ran ‘/nix/store/p1k7d2y5aa4haxlkkn2jadviwvl5plcc-ipset-6.38/bin/ipset help’ got 0 exit code
- found 2.6.6 in filename of file in /nix/store/p1k7d2y5aa4haxlkkn2jadviwvl5plcc-ipset-6.38
- directory tree listing: https://gist.github.com/f62ed14efd30650e1e05f1af8d5c2af4
Pull request #38470 added support for running/building kernels without
modules. This got merged in 38e04bbf29 but
unfortunately while this works perfectly on kernels without modules it
also makes sure that *every* kernel gets no modules.
So all of our VM tests fail since that merge with something like this:
machine# loading module loop...
machine# modprobe: FATAL: Module loop not found in directory /lib/modules/4.14.33
machine# loading module vfat...
machine# modprobe: FATAL: Module vfat not found in directory /lib/modules/4.14.33
machine# loading module nls_cp437...
machine# modprobe: FATAL: Module nls_cp437 not found in directory /lib/modules/4.14.33
machine# loading module nls_iso8859-1...
machine# modprobe: FATAL: Module nls_iso8859-1 not found in directory /lib/modules/4.14.33
machine# loading module fuse...
machine# modprobe: FATAL: Module fuse not found in directory /lib/modules/4.14.33
machine# loading module dm_mod...
machine# modprobe: FATAL: Module dm_mod not found in directory /lib/modules/4.14.33
I shortly tested this against the "misc" VM test and the test is working
again.
In the long term (and I currently don't have time for this) it would be
better to also have a VM test which tests a kernel without modules.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @roberth, @7c6f434c