From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42539) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ezIsk-0005JP-7c for guix-patches@gnu.org; Fri, 23 Mar 2018 05:21:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ezIsg-0004WG-Ek for guix-patches@gnu.org; Fri, 23 Mar 2018 05:21:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:40771) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ezIsg-0004W8-Ah for guix-patches@gnu.org; Fri, 23 Mar 2018 05:21:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ezIsg-00028r-0t for guix-patches@gnu.org; Fri, 23 Mar 2018 05:21:02 -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> <87bmfhgu9a.fsf@gnu.org> <87fu4sklds.fsf@fastmail.com> Date: Fri, 23 Mar 2018 10:20:38 +0100 In-Reply-To: <87fu4sklds.fsf@fastmail.com> (Marius Bakke's message of "Thu, 22 Mar 2018 19:36:47 +0100") Message-ID: <87h8p7kv15.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-done@debbugs.gnu.org Hello Marius, Marius Bakke skribis: > Ludovic Court=C3=A8s writes: [...] >> =E2=80=9CWhich ones do we pick=E2=80=9D summarizes the problem, I think.= It=E2=80=99s >> upstream=E2=80=99s job to pick a set of changes and declare a new releas= e. 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 j= udge >> 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 b= ugs, 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 usuall= y done >> under the assumption that people use releases, not intermediate >> snapshots. >> >> I understand that glibc=E2=80=99s 2.27 branch is stable, contains nothin= g but >> bug fixes, and in that sense is rather safe. Still=E2=80=A6 >> >> WDYT? > > I pushed the patch with the cherry-picked fixes. I'd rather not > knowingly break "date" on some locales, or introduce runtime issues on > i686. But I do agree that these things should really be upstreams job. Great, makes sense! > All the distros I've checked take the entire branch, so we are the "odd > kid out". But I guess that's nothing new. ;-) Heheh. :-) >> BTW, what about emailing the libc people to add you to the list of >> distro maintainers at ? >> I think it could be useful. > > That might be useful indeed. I'll look into it. > > I think we're getting ready to build core-updates now. Should we try > starting the 'core' subset on Hydra? Maybe also set a 'freeze' date? Note that berlin has been building the =E2=80=98core=E2=80=99 subset for a = while already. With berlin it=E2=80=99s harder to see what the status is, curren= tly, though =E2=80=98guix weather=E2=80=99 and =E2=80=9Cmake assert-*=E2=80=9D s= hould help. As for the freeze date, it could be within a couple of days if we see that there=E2=80=99s no issue with the =E2=80=98core=E2=80=99 subset. Thoughts? Do you want to be the time keeper or should it be someone else? :-) Ludo=E2=80=99.