From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eyiS2-0007Rm-5S for guix-patches@gnu.org; Wed, 21 Mar 2018 14:27:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eyiRy-0007bu-3X for guix-patches@gnu.org; Wed, 21 Mar 2018 14:27:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:38301) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eyiRy-0007bm-0H for guix-patches@gnu.org; Wed, 21 Mar 2018 14:27:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eyiRx-0006Qr-P3 for guix-patches@gnu.org; Wed, 21 Mar 2018 14:27:01 -0400 Subject: [bug#30873] [PATCH core-updates 1/3] gnu: glibc: Update to 2.27. Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <20180320102045.31795-1-mbakke@fastmail.com> <20180320102419.32286-1-mbakke@fastmail.com> <87r2oe6g36.fsf@gnu.org> <877eq6adrn.fsf@fastmail.com> Date: Wed, 21 Mar 2018 19:26:25 +0100 In-Reply-To: <877eq6adrn.fsf@fastmail.com> (Marius Bakke's message of "Tue, 20 Mar 2018 17:54:36 +0100") Message-ID: <87bmfhgu9a.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Marius Bakke Cc: 30873@debbugs.gnu.org Heya Marius! Marius Bakke skribis: > 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. Good. :-) > 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=3D22517 > * https://sourceware.org/bugzilla/show_bug.cgi?id=3D22848 [...] > 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? =E2=80=9CWhich ones do we pick=E2=80=9D summarizes the problem, I think. I= t=E2=80=99s upstream=E2=80=99s job to pick a set of changes and declare a new release. = It seems to me that we=E2=80=99re kinda doing the glibc release manager=E2=80= =99s job here, except we lack insight compared to them: it=E2=80=99s harder for us to judge which changes are critical, which changes are just the beginning of broader modifications/fixes, etc. I=E2=80=99d be willing to just use upstream=E2=80=99s release. It has bugs= , no doubts, but the next release will have its own bugs too. :-) Furthermore, SONAMEs and symbol versioning is quite critical, but it=E2=80=99s usually d= one under the assumption that people use releases, not intermediate snapshots. I understand that glibc=E2=80=99s 2.27 branch is stable, contains nothing b= ut bug fixes, and in that sense is rather safe. Still=E2=80=A6 WDYT? BTW, what about emailing the libc people to add you to the list of distro maintainers at ? I think it could be useful. Thanks! Ludo=E2=80=99.