[bug#54832] [patch] update glibc to 2.35

[Ludovic Courtès]

Hi!

Sorry for the long delay.

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