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
