GNU bug report logs - #54832
[patch] update glibc to 2.35

Previous Next

Full log

Message #26 received at 54832 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: zamfofex <zamfofex <at> twdb.moe>
Cc: Maxime Devos <maximedevos <at> telenet.be>, 54832 <at> debbugs.gnu.org
Subject: Re: bug#54832: [patch] update glibc to 2.35
Date: Sun, 17 Jul 2022 12:06:47 +0200

Hi!

Sorry for the long delay.

zamfofex <zamfofex <at> twdb.moe> skribis:

>> Could you confirm that these patches are no longer needed?
>
> I don’t remember exactly what my thought process was for removing the ‘glibc-dl-cache’ patch except that it wasn’t applicable anymore. At any rate, I don’t fully understand what the patch is actually doing, so it’s a bit difficult to assess whether it’s still necessary to me. (Help would be appreciated!)

There’s a comment at the top of ‘glibc-dl-cache.patch’ that explains
what it does, but see
<https://guix.gnu.org/en/blog/2021/taming-the-stat-storm-with-a-loader-cache/>
for details.  I can take a look and update it.

> Other than that, I did verify the other two patches, and it seems the regexes 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’re copying them to the “static” output anyway, so why not let them in ‘files’?
>
> Those files need to be present in both the ‘static’ and ‘out’ outputs,

Why?

> whereas without considering them specially, they would be moved to the
> ‘static’ output (with ‘rename-file’ as opposed to ‘copy-file’). Is a
> comment worthwhile? What should I write? I could explain the change in
> glibc that made those into empty ‘.a’ files and link to the
> changelog. Is that enough?

We’d need a comment like “Keep empty .a files in OUT in addition to
STATIC because …”.

>> 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 the newer version works with the previous glibc too?

Ideally yes.

>> Like Maxime wrote, please start the patch with a short comment explaining what it does, and with a link to the upstream commit or bug report.
>
> I’m still confused about what I should link to. I can write a comment explaining the issues and link to the IRC conversation we held, or maybe even to this thread. But I don’t think there actually is “an upstream commit or bug report” that I could link to.

When applying a patch to a package, we seek to document the reason why
we’re doing it, to ease maintenance; usually, patches come from a bug
report or from a change upstream, so we would like to it.

>> One last thing: could you use ‘git format-patch’ and (optionally) ‘git send-email’ to send a revised patch?
>
> I definitely don’t mind investigating using those tools more carefully! I think I can prepare and send another patch once my questions are clarified.

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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.