Re: [Nix-dev] Hotfixing glibc

2016-02-17 Thread Herwig Hochleitner
Yeah, but I get what you're saying: Poking our own hole into the store would set a bad precedent. And disk space is cheap (except on hydra ;-) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Hotfixing glibc

2016-02-17 Thread Herwig Hochleitner
2016-02-17 18:46 GMT+01:00 Shea Levy : > Details are at > https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/replace-dependency.nix, > but basically yes it goes into all dependents and copies them over to a new > output with references updated, based on the same

Re: [Nix-dev] Hotfixing glibc

2016-02-17 Thread Shea Levy
There is a much better solution available to entirely replace a bad store path without violating any nix invariants (e.g. modifying store paths), see http://lists.science.uu.nl/pipermail/nix-dev/2016-February/019564.html for an example. It does have the same dynamic-only limitation, of

Re: [Nix-dev] Hotfixing glibc

2016-02-17 Thread Herwig Hochleitner
​s/for glibc in/for glib in/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Hotfixing glibc

2016-02-17 Thread Herwig Hochleitner
To fix the horrendous glibc bug [1] on my system, without rebuilding my whole system, I just rebuilt glibc with the fix from master. Then i just softlinked older versions of glibc-2.21 to the fixed one, by doing the following in a zsh: # uses zsh/files to be able to use mv and ls # while glib is