Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade Glibc to 2.18 #1317

Closed
edolstra opened this issue Dec 2, 2013 · 5 comments
Closed

Upgrade Glibc to 2.18 #1317

edolstra opened this issue Dec 2, 2013 · 5 comments
Assignees
Milestone

Comments

@edolstra
Copy link
Member

edolstra commented Dec 2, 2013

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

@ghost ghost assigned edolstra Dec 2, 2013
@vcunat
Copy link
Member

vcunat commented Dec 2, 2013

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
Copy link
Member Author

edolstra commented Dec 2, 2013

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
Copy link
Member

vcunat commented Dec 2, 2013

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
Copy link
Member Author

edolstra commented Dec 2, 2013

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
Copy link
Member Author

Merged in 9f75797.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants