Monday Patch Queue Review update (2024-01-08)

Monday Patch Queue Review update (2024-01-08)

[Carlos O'Donell]

Most recent meeting status is always here:
https://sourceware.org/glibc/wiki/PatchworkReviewMeetings#Update

Meeting: 2024-01-08 @ 0900h EST5EDT

Video/Audio: https://bbb.linuxfoundation.org/room/adm-alk-1uu-7fu

IRC: #glibc on OFTC.

Review new patches and restart review at the top.

 - State NEW delegate NOBODY at 484 patches.
 - Carlos's SLI at 242 days average patch age in queue and 118723 accumulated patch days.
 - Starting at 83534.
 - The release is coming up in February 2024.
 - Adhemerval: One patch which should be added to release blockers.
 - [v2] linux: Fix fstat64 on alpha and sparc64 (Adhemerval)
  - Needs to be included to fix the failures.
 - [PATCH] Remove ia64-linux-gnu (Adhemerval)
  - Removal was blocked on Linux 6.7 release.
  - Once build-many-glibcs gets linux 6.7 support we will need a special case if we don't deprecate it.
  - Carlos: To review the ia64 removal.
 - Improve rounding to interger function for C23 (Adhemerval)
 - [v3] posix: Sync tempname with gnulib (Adhemerval)
  - Risk could be tempname breakage?
  - Defer to 2.40.
 - [v2] stdlib: Reinstate stable mergesort implementation on qsort (Adhemerval)
  - Florian to review.
  - This is a release blocker for 2.39 since we want to avoid further application issues.
 - Already merged the AArch64 SME support, nothing further for aarch64 for 2.39.
 - Should glibc update to autoconf 2.72?
  - There is a specific clang issue and requires an update to autoconf 2.72.
  - Given that clang needs out of tree patches anyway then it makes it less urgent.
  - Carlos: I expect that glibc won't update to autoconf 2.72 until August or even later to allow the distributions to include newer autoconf.
 - Maxim: Preference for the ia64 port to be removed in glibc to support simpliciation of gcc backends.
 - Carlos: I want to make forward progress on pthread condvar missing signal, and pthread cancellation fixes from Adhemerval.
 - Szabolcs: The old way that CET worked, that used to be in glibc code, and that code assumed that certain things are done by kernel/userspace and the new kernel ABI assumes userspace has to do things.
  - Adhemerval: Please raise this on the CET thread.
  - Szabolcs: Will raise the issues on the thread.
  - Carlos: If the semantics of the dynamic loader change based on markup and when the callbacks are called is unclear then we can refactor or document.
  - Adhemerval: Shadow stack for 32-bit doesn't work, is that an issue?
  - Carlos: It is not an issue that it doesn't work with i686.

-- 
Cheers,
Carlos.