Ricardo Wurmus <[email protected]> writes: > Leo Famulari <[email protected]> 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.
I should note that now every Guix command first prints this: GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread I suspect that this is not good. Guix was built with the grafted glibc. -- Ricardo
