From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 17 06:07:01 2022 Received: (at 54832) by debbugs.gnu.org; 17 Jul 2022 10:07:01 +0000 Received: from localhost ([127.0.0.1]:46742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oD1Ay-0006Vp-Jp for submit@debbugs.gnu.org; Sun, 17 Jul 2022 06:07:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47502) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oD1Au-0006VZ-46 for 54832@debbugs.gnu.org; Sun, 17 Jul 2022 06:06:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43940) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oD1Ao-0001eB-5b; Sun, 17 Jul 2022 06:06:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=4fDJybS7viZYNqllxb1SdseeD/8LFPaQhEF4UkXivG8=; b=OJGbcpdT13rf2Yoya/EW Rs2seUiYNzgto9B0Mieoo0/Qx7RiDQwwkExYM1szpg261Cx27kN1NHLhHhiseh0dS/1NJgwW0Xe5p /FMAN3ec4MCGo1ek7+eVK5dbaf0oOp6541+/rA3SyrGRG+6HMcuvdxxdVVKXh97UbF1K1uzNINaay w3S8FjxlseQVOXOKJEotkOyjFO4cjxwYL6MWRz8/fGAU2yhwZ3oG5CuOOAF/uraBR8GRDW4VI3i3C ULVlywCCayricFfThz2ULBcr7+ODQczdn2CFkW8cKY9y+cJCBbzYCAuqQuOM2J5fDtFelqowP16Hs XS7LuQtXeYkiNA==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201]:50524 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oD1An-0004W4-Ql; Sun, 17 Jul 2022 06:06:50 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: zamfofex Subject: Re: bug#54832: [patch] update glibc to 2.35 References: <935236349.13698.1649553391613@privateemail.com> <87r14ubhyu.fsf@gnu.org> <818784149.855838.1654517187059@privateemail.com> Date: Sun, 17 Jul 2022 12:06:47 +0200 In-Reply-To: <818784149.855838.1654517187059@privateemail.com> (zamfofex@twdb.moe's message of "Mon, 6 Jun 2022 09:06:27 -0300 (BRT)") Message-ID: <874jzg59zc.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54832 Cc: Maxime Devos , 54832@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi! Sorry for the long delay. zamfofex skribis: >> Could you confirm that these patches are no longer needed? > > I don=E2=80=99t remember exactly what my thought process was for removing= the =E2=80=98glibc-dl-cache=E2=80=99 patch except that it wasn=E2=80=99t a= pplicable anymore. At any rate, I don=E2=80=99t fully understand what the p= atch is actually doing, so it=E2=80=99s a bit difficult to assess whether i= t=E2=80=99s still necessary to me. (Help would be appreciated!) There=E2=80=99s a comment at the top of =E2=80=98glibc-dl-cache.patch=E2=80= =99 that explains what it does, but see for details. I can take a look and update it. > Other than that, I did verify the other two patches, and it seems the reg= exes they were patching have already been fixed upstream! Great. >> Could you explain why the empty .a files need special treatment? In the= end, it seems we=E2=80=99re copying them to the =E2=80=9Cstatic=E2=80=9D o= utput anyway, so why not let them in =E2=80=98files=E2=80=99? > > Those files need to be present in both the =E2=80=98static=E2=80=99 and = =E2=80=98out=E2=80=99 outputs, Why? > whereas without considering them specially, they would be moved to the > =E2=80=98static=E2=80=99 output (with =E2=80=98rename-file=E2=80=99 as op= posed to =E2=80=98copy-file=E2=80=99). Is a > comment worthwhile? What should I write? I could explain the change in > glibc that made those into empty =E2=80=98.a=E2=80=99 files and link to t= he > changelog. Is that enough? We=E2=80=99d need a comment like =E2=80=9CKeep empty .a files in OUT in add= ition to STATIC because =E2=80=A6=E2=80=9D. >> This should be done in a separate patch. > > That is fine. Though I will note that the previous version of m4 did not = work with the updated glibc, so I think it would make sense to updated it *= before* updating glibc in the commit history. Do I need to verify whether t= he newer version works with the previous glibc too? Ideally yes. >> Like Maxime wrote, please start the patch with a short comment explainin= g what it does, and with a link to the upstream commit or bug report. > > I=E2=80=99m still confused about what I should link to. I can write a com= ment explaining the issues and link to the IRC conversation we held, or may= be even to this thread. But I don=E2=80=99t think there actually is =E2=80= =9Can upstream commit or bug report=E2=80=9D that I could link to. When applying a patch to a package, we seek to document the reason why we=E2=80=99re doing it, to ease maintenance; usually, patches come from a b= ug report or from a change upstream, so we would like to it. >> One last thing: could you use =E2=80=98git format-patch=E2=80=99 and (op= tionally) =E2=80=98git send-email=E2=80=99 to send a revised patch? > > I definitely don=E2=80=99t mind investigating using those tools more care= fully! I think I can prepare and send another patch once my questions are c= larified. Perfect. I realize upgrading glibc is a rather tricky task, so thanks for giving it a try! Surely we can team up to get it past the finish line. Thanks! Ludo=E2=80=99.