This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
Pythons find_library is broken with binutils 2.34, and numpy could not import libraries because of not properly aligned ELF's.
This is the second time binutils 2.34 got reverted. Next time, we should have a dedicated Hydra job for it.
This reverts commit 629fa8a2d4, reversing
changes made to 4ddd080d19.
The current version of glibc implements support for kernels down to
3.2.0 (and we make sure to enable such support with apporopriate
--enable-kernel setting). The current RHEL6 operating system is based on
a maintained kernel based on 2.6.32 with lots of backports. We provide
basic support for this specific kernel by patching glibc to provide an
exception for this specific version of kernel. This allows for nixpkgs
software distribution to work on RHEL6 and it does so quite well with
almost no problems. There are, however, a few syscalls that are missing
in the 2.6.32 kernel, one of which is prlimit64. This commit provides a
fallback that uses an older {get,set}rlimit syscalls in cases when
prlimit64 is not available. This should streamline the experience for
nixpkgs users wanting to run it on RHEL6, namely, this fixes one of the
tests in findutils.
See also discussion in guix:
https://lists.gnu.org/archive/html/guix-devel/2018-03/msg00356.html
It's certainly better to have those two caveats than not evaluate.
Both seem rather niche. Unfortunately I failed to find a better way.
I started testing builds of several cross variants; all seem OK.
References to the host toolchain are leaking through debug symbols in
glibc, causing gnu cross-builds to always depend on the host toolchain.
The decision to not strip was made in 2012 in order to improve GNU/Hurd
support, and I suspect the reasons that justified it back then do not
apply anymore in 2019.
Closure size before:
/nix/store/v5pxj0bgg627hic2khk4d43z6cjp5v7d-hello-2.10-armv7l-unknown-linux-gnueabihf 596.8M
After:
/nix/store/llp1ncmpar406rc2vhj7g5ix4yqwna3n-hello-2.10-armv7l-unknown-linux-gnueabihf 23.6M
Previously we only build C.UTF-8 as part of the locale-archive
that comes with the glibc core package.
However for consistent use of LANG=C.UTF-8 we also want support
in our glibcLocales as well.
fixes https://github.com/NixOS/nixpkgs/issues/57974
glibc's buildsystem uses its own executables to generate locales.
This does not work for cross-compilation so instead we use localedef
from buildPackages.
This round is without the systemd CVE,
as we don't have binaries for that yet.
BTW, I just ignore darwin binaries these days,
as I'd have to wait for weeks for them.
