From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ez55G-0002A3-2Y for guix-patches@gnu.org; Thu, 22 Mar 2018 14:37:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ez55C-0004mc-Q5 for guix-patches@gnu.org; Thu, 22 Mar 2018 14:37:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:40230) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ez55C-0004mT-LT for guix-patches@gnu.org; Thu, 22 Mar 2018 14:37:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ez55C-0002Pb-DW for guix-patches@gnu.org; Thu, 22 Mar 2018 14:37:02 -0400 Subject: bug#30873: [PATCH core-updates 1/3] gnu: glibc: Update to 2.27. Resent-To: guix-patches@gnu.org Resent-Message-ID: From: Marius Bakke In-Reply-To: <87bmfhgu9a.fsf@gnu.org> 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> Date: Thu, 22 Mar 2018 19:36:47 +0100 Message-ID: <87fu4sklds.fsf@fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" 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: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 30873-done@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s writes: > 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. = It=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 ju= dge > 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 bu= gs, 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= done > under the assumption that people use releases, not intermediate > snapshots. > > I understand that glibc=E2=80=99s 2.27 branch is stable, contains nothing= 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. All the distros I've checked take the entire branch, so we are the "odd kid out". But I guess that's nothing new. ;-) > 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? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlqz978ACgkQoqBt8qM6 VPpu7wf7BtByio+Y7RPRrkIkGCAb0R2CEUADffYj4j0Lo+jSiUWmuez1cDrWQiLV eGbIHPLHq1Gr1EKpMCwVd8olh08+yAchuQjIZvNQ1Yi1HVi21IIi+QYU4Q21k0NX qI0JIeLK7YJgkX0VR7UGTk4b7yP0ae7+9E9oc62hlzFuU48mhLcENsaQVPwIGkbx hhV4J93YOmstuDo9EZBrvzTdX1d0boh4Jj6jyQdtUP0m5BmWar+PFvU7o4YdK0Hp BH4Q8F4nXZt95NKBIgNfozSKNUszThhL0c9o+8zNBP9k0jld82A/SS4TjEE9wEt+ McxZ1Xq8XpVcklSqHPSgub9iUaNGjg== =SJKp -----END PGP SIGNATURE----- --=-=-=--