Ludovic Courtès writes: > Hello! > > Thanks for working on this update! Crazy that it turned out to be this > difficult. > > Marius Bakke skribis: > >> +++ b/gnu/packages/patches/glibc-2.27-git-fixes.patch >> @@ -0,0 +1,12765 @@ >> +This patch includes all post-release fixes for version 2.27 up to commit >> +3b922526415d1af93fe5a0e3caf7e6a790cb1619. >> + >> +https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.27/master >> + >> +Generated by "git diff glibc-2.27..release/2.27/master". > > In general I’d be in favor of not doing that, unless the fixes are > important (build issue, security issue, etc.), as was the case when we > packaged 2.26; and, if there are important fixes, I’d rather extract > them from the whole patch stream, and skip unrelated changes. > > For example, I’m sure we can live without the locale updates that show > up in this patch set. :-) > > Do you know which of these patches are really needed? > > Thoughts? Hello! I was hoping you'd comment on this ;-) There are actually not a lot of high severity fixes in 2.27 yet. I opted for this mostly as a proof-of-concept for a couple of reasons. * Giving the GNU C Library special treatment is OK IMO. * In 2.26, cherry-picking individual fixes was not feasible. ** However, using the same method, the 2.26 diff is "only" 27k lines/904k. It does mean growing the Guix repository up to ~1MiB every six months, but in the large scale of things, it doesn't seem that bad. Yet, I'm not sure if it makes sense to do this now. There are only a handful of "important" commits on 2.27 so far. Additionally, the 2.27 release manager has said he would do 2.27.1 once (if?) enough patches has piled up, so maybe there is hope for the future. The question is which do we pick? Portability fixes for arches we don't (yet) support? Some of the locale fixes seem genuine, and not just typos, e.g.: * https://sourceware.org/bugzilla/show_bug.cgi?id=22517 * https://sourceware.org/bugzilla/show_bug.cgi?id=22848 Actually, now that I've scoured the history, reverting this one commit brings the patch from 12921 to 2391 lines: . ~2k isn't too bad IMO. Yet, I've attached a patch with only the following commits, and without NEWS and ChangeLog updates. It's 547 lines, which is more palatable; but may grow longer than the unified approach since it includes git commit logs. 56170e064e2b21ce204f0817733e92f1730541ea 516fa6080481a1433c173320b1c1432868e1e38a f36553bf6a4f69070f99badbdab5802b43e6e211 7c6304182b9f422b782ace1cdd3efbde056aec36 78a90c2f74a2012dd3eff302189e47ff6779a757 1e52d8e65a58c49a48549053a1b89c06240e0c6c But, we risk missing important commits this way, and may cause headaches for people wanting to port Guix to a new architecture. And the approach doesn't really scale for branches approaching ~100 commits. Regardless, here is a patch with just the above commits. Let me know if you spot others in the history that look important. WDYT? I suppose we'll have to revisit this with every 'core-updates'. :-)