Upgrade Glibc to 2.18

[edolstra]

Git branch: https://github.com/NixOS/nixpkgs/tree/glibc-2.18

Hydra jobset: http://hydra.nixos.org/jobset/nixos/glibc-2.18

Status compared to master: http://hydra.nixos.org/jobset/nixos/glibc-2.18/latest-eval?compare=trunk-combined

[vcunat]

Any idea about the importance of this update? (I suppose we fixed CVEs already by individual patches against previous version.)

Why I ask: I see many thousand breakages on Hydra, whereas stdenv only has a few hundred now. From that point of view it seems better to first stabilize stdenv (and merge) before making it even more complicated by this. There are even 8 months old changes in master..stdenv-updates, and many are very useful (recurring reports by users, etc.).

[edolstra]

That's why I put it in a separate branch. (I think we should get rid of the whole "stdenv-updates" branch concept, because it tends to lead to a huge branch that takes forever to get merged.)

There are 6 new CVEs by the way (in 2.17 and 2.18): https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;hb=HEAD

[vcunat]

Ah, so do I get it right that there are CVEs fixed that haven't been yet addressed in master/stdenv-updates? I think we should find patches for the CVEs and apply those immediately to master (and release-13.10), if such patches exist (I suppose other distros also use and test them).

(a side issue, but related)

OK, now that we have the stable-branch concept, I expect that less tested changes (even stdenv-changes) could be merged more often. It would be ideal to have just small topic branches (preferably short-lived), only for the reason to make Hydra build all, so we can see build regressions and make testing possible for those who don't want to rebuild.

Would it be possible that Hydra did such automated rebuilds? E.g. we could have "test/*" branches, which would get picked-up when created and built (with low priority); also the same for pull requests would be IMO very useful.

[edolstra]

Right, AFAIK all these CVEs also apply to 2.17. I've just fixed them in the glibc-2.18 branch (101f62a). Hopefully they apply cleanly to 2.17.

Yeah, I think small topic branches are better. Hydra can easily build them. The main reason for having a big stdenv-updates branch (combining updates to reduce the amount of change in master) is gone now that we have a stable branch.

[edolstra]

Merged in 9f75797.