Leo Famulari writes: >> For future updates to the glibc we would have to re-evaluate if the >> current RHEL 6.x kernel still supports all features the glibc expects, >> and decide once more if we can justify patching glibc to allow that one >> particular kernel version. > > Yes... and this will probably continue for many years. But I do think we > should do something to work around the issue now, and reevaluate our > solution when the pressure is off. > > It would be nice if the graft only applied to x86_64-linux, but I've > never considered if that is easy to do or not. I don’t know if we can graft a package only for a single architecture. At least at the time of ungrafting we could apply the patch only on x86_64 (and only rebuild the world for that architecture). FWIW: I’ve applied this patch to the installation at the MDC and it works fine. The biggest downside here is the slowness of grafts over NFS (I still need to update the protocol to NFS 4.1) and the many lines of output that are amplified by communicating with a remote daemon. Other than that I’m happy that this crisis could be temporarily averted. I’d like to have this in master, though, so that people can run “guix pull” again and actually get working software. -- Ricardo