glibc 2.34 - Slushy freeze effective immediately.

glibc 2.34 - Slushy freeze effective immediately.

[Carlos O'Donell]

Community,

We are in slushy freeze right now. I'm reviewing the last of the ABI
changes we want to make in glibc 2.34.

The ABI changes that are currently under review:

- Move nss_dns into libc.
https://patchwork.sourceware.org/project/glibc/list/?series=2407

- Remove malloc hooks.
https://patchwork.sourceware.org/project/glibc/list/?series=2406

- nss_files move.
https://patchwork.sourceware.org/project/glibc/list/?series=2386

- Add close_range, closefrom, and posix_spawn_file_actions_closefrom_np
https://patchwork.sourceware.org/project/glibc/list/?series=2363

- Define PTHREAD_STACK_MIN to sysconf(_SC_THREAD_STACK_MIN)
https://patchwork.sourceware.org/project/glibc/list/?series=2345

- x86: Install <bits/platform/x86.h> [BZ #27958]
https://patchwork.sourceware.org/project/glibc/list/?series=2272

If you have any others please respond to this thread and we can discuss
the inclusion requirements.

-- 
Cheers,
Carlos.

glibc 2.34 - Hard ABI freeze effective immediately.

[Carlos O'Donell]

On 7/4/21 10:43 PM, Carlos O'Donell wrote:
> We are in slushy freeze right now. I'm reviewing the last of the ABI
> changes we want to make in glibc 2.34.

The ABI freeze is now hard freeze, I would like to avoid any further ABI
changes that are not on this list.

If you have an ABI change please reach and respond to this thread 
immediately with the request.

I would like to spend this week and next fixing any remaining bugs
and doing machine testing.
 
> The ABI changes that are currently under review:
> 
> - Move nss_dns into libc.
> https://patchwork.sourceware.org/project/glibc/list/?series=2407

I have reviewed v2 and I think it should be included in 2.34.

I have just reviewed the final v3 changes so this should go in on Monday.
 
> - Remove malloc hooks.
> https://patchwork.sourceware.org/project/glibc/list/?series=2406

I have reviewed v8 and I think it should be included in 2.34.

I'll review a v9 for inclusion.

> - nss_files move.
> https://patchwork.sourceware.org/project/glibc/list/?series=2386

This was reviewed by Adhemerval and committed July 7th.

> - Add close_range, closefrom, and posix_spawn_file_actions_closefrom_np
> https://patchwork.sourceware.org/project/glibc/list/?series=2363

This was committed by Adhemerval on July 8th.

> - Define PTHREAD_STACK_MIN to sysconf(_SC_THREAD_STACK_MIN)
> https://patchwork.sourceware.org/project/glibc/list/?series=2345

I have reviewed this, and it was committed by HJ on July 9th.

> - x86: Install <bits/platform/x86.h> [BZ #27958]
> https://patchwork.sourceware.org/project/glibc/list/?series=2272

I have reviewed this and requested some changes.

I have reviewed this again and I am discussing the final wording with HJ.

I think this should be included in glibc 2.34 and we will get there.

-- 
Cheers,
Carlos.

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Florian Weimer]

* Carlos O'Donell via Libc-alpha:

> On 7/4/21 10:43 PM, Carlos O'Donell wrote:
>> We are in slushy freeze right now. I'm reviewing the last of the ABI
>> changes we want to make in glibc 2.34.
>
> The ABI freeze is now hard freeze, I would like to avoid any further ABI
> changes that are not on this list.
>
> If you have an ABI change please reach and respond to this thread 
> immediately with the request.

I suggest to add __ioctl_time64 and related functions on 32-bit, for
future-proofing the time64 ABI:

  Additional time64 aliases
  <https://sourceware.org/pipermail/libc-alpha/2021-July/128485.html>

Thanks,
Florian

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Adhemerval Zanella]

On 19/07/2021 10:51, Florian Weimer via Libc-alpha wrote:
> * Carlos O'Donell via Libc-alpha:
> 
>> On 7/4/21 10:43 PM, Carlos O'Donell wrote:
>>> We are in slushy freeze right now. I'm reviewing the last of the ABI
>>> changes we want to make in glibc 2.34.
>>
>> The ABI freeze is now hard freeze, I would like to avoid any further ABI
>> changes that are not on this list.
>>
>> If you have an ABI change please reach and respond to this thread 
>> immediately with the request.
> 
> I suggest to add __ioctl_time64 and related functions on 32-bit, for
> future-proofing the time64 ABI:
> 
>   Additional time64 aliases
>   <https://sourceware.org/pipermail/libc-alpha/2021-July/128485.html>

I will review these.

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Florian Weimer]

* Adhemerval Zanella:

> On 19/07/2021 10:51, Florian Weimer via Libc-alpha wrote:
>> * Carlos O'Donell via Libc-alpha:
>> 
>>> On 7/4/21 10:43 PM, Carlos O'Donell wrote:
>>>> We are in slushy freeze right now. I'm reviewing the last of the ABI
>>>> changes we want to make in glibc 2.34.
>>>
>>> The ABI freeze is now hard freeze, I would like to avoid any further ABI
>>> changes that are not on this list.
>>>
>>> If you have an ABI change please reach and respond to this thread 
>>> immediately with the request.
>> 
>> I suggest to add __ioctl_time64 and related functions on 32-bit, for
>> future-proofing the time64 ABI:
>> 
>>   Additional time64 aliases
>>   <https://sourceware.org/pipermail/libc-alpha/2021-July/128485.html>
>
> I will review these.

Thanks.  I need to repost it because of several conflicts.

Thanks,
Florian

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Carlos O'Donell]

On 7/19/21 10:30 AM, Florian Weimer via Libc-alpha wrote:
> * Adhemerval Zanella:
> 
>> On 19/07/2021 10:51, Florian Weimer via Libc-alpha wrote:
>>> * Carlos O'Donell via Libc-alpha:
>>>
>>>> On 7/4/21 10:43 PM, Carlos O'Donell wrote:
>>>>> We are in slushy freeze right now. I'm reviewing the last of the ABI
>>>>> changes we want to make in glibc 2.34.
>>>>
>>>> The ABI freeze is now hard freeze, I would like to avoid any further ABI
>>>> changes that are not on this list.
>>>>
>>>> If you have an ABI change please reach and respond to this thread 
>>>> immediately with the request.
>>>
>>> I suggest to add __ioctl_time64 and related functions on 32-bit, for
>>> future-proofing the time64 ABI:
>>>
>>>   Additional time64 aliases
>>>   <https://sourceware.org/pipermail/libc-alpha/2021-July/128485.html>
>>
>> I will review these.
> 
> Thanks.  I need to repost it because of several conflicts.

This is now complete, we have time64 aliases so this part of the ABI is now frozen.

-- 
Cheers,
Carlos.

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Carlos O'Donell]

On 7/22/21 8:28 AM, Carlos O'Donell wrote:
> On 7/19/21 10:30 AM, Florian Weimer via Libc-alpha wrote:
>> * Adhemerval Zanella:
>>
>>> On 19/07/2021 10:51, Florian Weimer via Libc-alpha wrote:
>>>> * Carlos O'Donell via Libc-alpha:
>>>>
>>>>> On 7/4/21 10:43 PM, Carlos O'Donell wrote:
>>>>>> We are in slushy freeze right now. I'm reviewing the last of the ABI
>>>>>> changes we want to make in glibc 2.34.
>>>>>
>>>>> The ABI freeze is now hard freeze, I would like to avoid any further ABI
>>>>> changes that are not on this list.
>>>>>
>>>>> If you have an ABI change please reach and respond to this thread 
>>>>> immediately with the request.
>>>>
>>>> I suggest to add __ioctl_time64 and related functions on 32-bit, for
>>>> future-proofing the time64 ABI:
>>>>
>>>>   Additional time64 aliases
>>>>   <https://sourceware.org/pipermail/libc-alpha/2021-July/128485.html>
>>>
>>> I will review these.
>>
>> Thanks.  I need to repost it because of several conflicts.
> 
> This is now complete, we have time64 aliases so this part of the ABI is now frozen.

Actually, turns out I'm wrong, we need a few more hours for this.

We'll be frozen soon.

-- 
Cheers,
Carlos.

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Florian Weimer]

* Carlos O'Donell:

> On 7/22/21 8:28 AM, Carlos O'Donell wrote:
>> On 7/19/21 10:30 AM, Florian Weimer via Libc-alpha wrote:
>>> * Adhemerval Zanella:
>>>
>>>> On 19/07/2021 10:51, Florian Weimer via Libc-alpha wrote:
>>>>> * Carlos O'Donell via Libc-alpha:
>>>>>
>>>>>> On 7/4/21 10:43 PM, Carlos O'Donell wrote:
>>>>>>> We are in slushy freeze right now. I'm reviewing the last of the ABI
>>>>>>> changes we want to make in glibc 2.34.
>>>>>>
>>>>>> The ABI freeze is now hard freeze, I would like to avoid any further ABI
>>>>>> changes that are not on this list.
>>>>>>
>>>>>> If you have an ABI change please reach and respond to this thread 
>>>>>> immediately with the request.
>>>>>
>>>>> I suggest to add __ioctl_time64 and related functions on 32-bit, for
>>>>> future-proofing the time64 ABI:
>>>>>
>>>>>   Additional time64 aliases
>>>>>   <https://sourceware.org/pipermail/libc-alpha/2021-July/128485.html>
>>>>
>>>> I will review these.
>>>
>>> Thanks.  I need to repost it because of several conflicts.
>> 
>> This is now complete, we have time64 aliases so this part of the ABI is now frozen.
>
> Actually, turns out I'm wrong, we need a few more hours for this.
>
> We'll be frozen soon.

I've pushed my two time64 patches.  I don't have anything else left.

Thanks,
Florian

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Carlos O'Donell]

On 7/18/21 10:15 PM, Carlos O'Donell wrote:
> On 7/4/21 10:43 PM, Carlos O'Donell wrote:
>> We are in slushy freeze right now. I'm reviewing the last of the ABI
>> changes we want to make in glibc 2.34.
> 
> The ABI freeze is now hard freeze, I would like to avoid any further ABI
> changes that are not on this list.
> 
> If you have an ABI change please reach and respond to this thread 
> immediately with the request.
> 
> I would like to spend this week and next fixing any remaining bugs
> and doing machine testing.
>  
>> The ABI changes that are currently under review:
>>
>> - Move nss_dns into libc.
>> https://patchwork.sourceware.org/project/glibc/list/?series=2407
> 
> I have reviewed v2 and I think it should be included in 2.34.
> 
> I have just reviewed the final v3 changes so this should go in on Monday.

This is complete. This ABI is now moved and frozen.
  
>> - Remove malloc hooks.
>> https://patchwork.sourceware.org/project/glibc/list/?series=2406
> 
> I have reviewed v8 and I think it should be included in 2.34.
> 
> I'll review a v9 for inclusion.

Review is complete. I consider this ABI frozen. Siddhesh please commit.
 
>> - nss_files move.
>> https://patchwork.sourceware.org/project/glibc/list/?series=2386
> 
> This was reviewed by Adhemerval and committed July 7th.
> 
>> - Add close_range, closefrom, and posix_spawn_file_actions_closefrom_np
>> https://patchwork.sourceware.org/project/glibc/list/?series=2363
> 
> This was committed by Adhemerval on July 8th.

Done.

>> - Define PTHREAD_STACK_MIN to sysconf(_SC_THREAD_STACK_MIN)
>> https://patchwork.sourceware.org/project/glibc/list/?series=2345
> 
> I have reviewed this, and it was committed by HJ on July 9th.

Done.

>> - x86: Install <bits/platform/x86.h> [BZ #27958]
>> https://patchwork.sourceware.org/project/glibc/list/?series=2272
> 
> I have reviewed this and requested some changes.
> 
> I have reviewed this again and I am discussing the final wording with HJ.
> 
> I think this should be included in glibc 2.34 and we will get there.
 
I'm reviewing v3 right now.

I consider the ABI final at this point.

-- 
Cheers,
Carlos.

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Adhemerval Zanella]

On 22/07/2021 09:31, Carlos O'Donell via Libc-alpha wrote:
> On 7/18/21 10:15 PM, Carlos O'Donell wrote:
>> On 7/4/21 10:43 PM, Carlos O'Donell wrote:
>>> We are in slushy freeze right now. I'm reviewing the last of the ABI
>>> changes we want to make in glibc 2.34.
>>
>> The ABI freeze is now hard freeze, I would like to avoid any further ABI
>> changes that are not on this list.
>>
>> If you have an ABI change please reach and respond to this thread 
>> immediately with the request.
>>
>> I would like to spend this week and next fixing any remaining bugs
>> and doing machine testing.
>>  
>>> The ABI changes that are currently under review:
>>>
>>> - Move nss_dns into libc.
>>> https://patchwork.sourceware.org/project/glibc/list/?series=2407
>>
>> I have reviewed v2 and I think it should be included in 2.34.
>>
>> I have just reviewed the final v3 changes so this should go in on Monday.
> 
> This is complete. This ABI is now moved and frozen.
>   
>>> - Remove malloc hooks.
>>> https://patchwork.sourceware.org/project/glibc/list/?series=2406
>>
>> I have reviewed v8 and I think it should be included in 2.34.
>>
>> I'll review a v9 for inclusion.
> 
> Review is complete. I consider this ABI frozen. Siddhesh please commit.
>  
>>> - nss_files move.
>>> https://patchwork.sourceware.org/project/glibc/list/?series=2386
>>
>> This was reviewed by Adhemerval and committed July 7th.
>>
>>> - Add close_range, closefrom, and posix_spawn_file_actions_closefrom_np
>>> https://patchwork.sourceware.org/project/glibc/list/?series=2363
>>
>> This was committed by Adhemerval on July 8th.
> 
> Done.
> 
>>> - Define PTHREAD_STACK_MIN to sysconf(_SC_THREAD_STACK_MIN)
>>> https://patchwork.sourceware.org/project/glibc/list/?series=2345
>>
>> I have reviewed this, and it was committed by HJ on July 9th.
> 
> Done.
> 
>>> - x86: Install <bits/platform/x86.h> [BZ #27958]
>>> https://patchwork.sourceware.org/project/glibc/list/?series=2272
>>
>> I have reviewed this and requested some changes.
>>
>> I have reviewed this again and I am discussing the final wording with HJ.
>>
>> I think this should be included in glibc 2.34 and we will get there.
>  
> I'm reviewing v3 right now.
> 
> I consider the ABI final at this point.
> 

Do we still have time for the posix_spawnattr_tcsetpgrp_np [1]? I think the
code should be simple enough.

[1] https://patchwork.sourceware.org/project/glibc/patch/20210617175751.1619846-2-adhemerval.zanella@linaro.org/

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Carlos O'Donell]

On 7/22/21 9:24 AM, Adhemerval Zanella wrote:
> Do we still have time for the posix_spawnattr_tcsetpgrp_np [1]? I think the
> code should be simple enough.
> 
> [1] https://patchwork.sourceware.org/project/glibc/patch/20210617175751.1619846-2-adhemerval.zanella@linaro.org/
No, I do not think we have enough time, or to be more precise I want 
to review the use case, ask Godmar to verify that API does what is
required, and *then* include it in the release.

I want to use the remaining 6 days to fix bugs without any further
ABI work.

I would like to see:
- LD_AUDIT bugs fixed.
- pthread condvar bugs fixed.
- C.UTF-8 added as supported (resolved Florian's last comment about U+FFFD usage).

-- 
Cheers,
Carlos.

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Siddhesh Poyarekar]

On Fri, Jul 23, 2021 at 10:44 AM Carlos O'Donell <carlos@redhat.com> wrote:
> I would like to see:
> - LD_AUDIT bugs fixed.
> - pthread condvar bugs fixed.
> - C.UTF-8 added as supported (resolved Florian's last comment about U+FFFD usage).

I've posted a few fixes to mtrace, build fixes for hurd and
disable-tunables, etc.  Could they be considered too?  Oh, and the
setlocale error checking.

Thanks,
Siddhesh

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Carlos O'Donell]

On 7/23/21 1:53 AM, Siddhesh Poyarekar wrote:
> On Fri, Jul 23, 2021 at 10:44 AM Carlos O'Donell <carlos@redhat.com> wrote:
>> I would like to see:
>> - LD_AUDIT bugs fixed.
>> - pthread condvar bugs fixed.
>> - C.UTF-8 added as supported (resolved Florian's last comment about U+FFFD usage).
> 
> I've posted a few fixes to mtrace, build fixes for hurd and
> disable-tunables, etc.  Could they be considered too?  Oh, and the
> setlocale error checking.

I want to minimize the number of changes we make this week.

If they can wait until glibc 2.35 opens then I think they should.

We can backport fixes into the released 2.34 branch if they are relevant
to Fedora 35 e.g. setlocale error checking.

-- 
Cheers,
Carlos.

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Samuel Thibault]

Hello,

Carlos O'Donell via Libc-alpha, le lun. 26 juil. 2021 10:22:40 -0400, a ecrit:
> On 7/23/21 1:53 AM, Siddhesh Poyarekar wrote:
> > On Fri, Jul 23, 2021 at 10:44 AM Carlos O'Donell <carlos@redhat.com> wrote:
> >> I would like to see:
> >> - LD_AUDIT bugs fixed.
> >> - pthread condvar bugs fixed.
> >> - C.UTF-8 added as supported (resolved Florian's last comment about U+FFFD usage).
> > 
> > I've posted a few fixes to mtrace, build fixes for hurd and
> > disable-tunables, etc.  Could they be considered too?  Oh, and the
> > setlocale error checking.
> 
> I want to minimize the number of changes we make this week.
> 
> If they can wait until glibc 2.35 opens then I think they should.

The build fix for hurd is very trivial, and needed to be able to get
make check
to produce an actual output.

Samuel

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Siddhesh Poyarekar]

On 7/26/21 7:58 PM, Samuel Thibault wrote:
>> I want to minimize the number of changes we make this week.
>>
>> If they can wait until glibc 2.35 opens then I think they should.
> 
> The build fix for hurd is very trivial, and needed to be able to get
> make check
> to produce an actual output.

I already pushed it, I think Carlos was referring to the remaining fixes 
that haven't yet been reviewed.

Siddhesh

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Samuel Thibault]

Siddhesh Poyarekar, le lun. 26 juil. 2021 20:07:25 +0530, a ecrit:
> On 7/26/21 7:58 PM, Samuel Thibault wrote:
> > > I want to minimize the number of changes we make this week.
> > > 
> > > If they can wait until glibc 2.35 opens then I think they should.
> > 
> > The build fix for hurd is very trivial, and needed to be able to get
> > make check
> > to produce an actual output.
> 
> I already pushed it, I think Carlos was referring to the remaining fixes
> that haven't yet been reviewed.

Ok thanks!

Samuel

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Adhemerval Zanella]

On 23/07/2021 02:13, Carlos O'Donell wrote:
> On 7/22/21 9:24 AM, Adhemerval Zanella wrote:
>> Do we still have time for the posix_spawnattr_tcsetpgrp_np [1]? I think the
>> code should be simple enough.
>>
>> [1] https://patchwork.sourceware.org/project/glibc/patch/20210617175751.1619846-2-adhemerval.zanella@linaro.org/
> No, I do not think we have enough time, or to be more precise I want 
> to review the use case, ask Godmar to verify that API does what is
> required, and *then* include it in the release.

Fair enough.

> 
> I want to use the remaining 6 days to fix bugs without any further
> ABI work.
> 
> I would like to see:
> - LD_AUDIT bugs fixed.
> - pthread condvar bugs fixed.
> - C.UTF-8 added as supported (resolved Florian's last comment about U+FFFD usage).
> 

I would like to add some extra time64 tests changes [1].  They do not touch
the code, besides libsupport.

[1] https://patchwork.sourceware.org/project/glibc/list/?series=2510

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Carlos O'Donell]

On 7/23/21 9:13 AM, Adhemerval Zanella wrote:
> 
> 
> On 23/07/2021 02:13, Carlos O'Donell wrote:
>> On 7/22/21 9:24 AM, Adhemerval Zanella wrote:
>>> Do we still have time for the posix_spawnattr_tcsetpgrp_np [1]? I think the
>>> code should be simple enough.
>>>
>>> [1] https://patchwork.sourceware.org/project/glibc/patch/20210617175751.1619846-2-adhemerval.zanella@linaro.org/
>> No, I do not think we have enough time, or to be more precise I want 
>> to review the use case, ask Godmar to verify that API does what is
>> required, and *then* include it in the release.
> 
> Fair enough.
> 
>>
>> I want to use the remaining 6 days to fix bugs without any further
>> ABI work.
>>
>> I would like to see:
>> - LD_AUDIT bugs fixed.
>> - pthread condvar bugs fixed.
>> - C.UTF-8 added as supported (resolved Florian's last comment about U+FFFD usage).
>>
> 
> I would like to add some extra time64 tests changes [1].  They do not touch
> the code, besides libsupport.
> 
> [1] https://patchwork.sourceware.org/project/glibc/list/?series=2510

Absolutely, we should review this and merge it.

I see the 32-bit builder failed this series:
NONE -> FAIL : socket/tst-socket-timestamp
NONE -> FAIL : socket/tst-socket-timestamp-time64


-- 
Cheers,
Carlos.

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Adhemerval Zanella]

On 26/07/2021 10:00, Carlos O'Donell wrote:
> On 7/23/21 9:13 AM, Adhemerval Zanella wrote:
>>
>>
>> On 23/07/2021 02:13, Carlos O'Donell wrote:
>>> On 7/22/21 9:24 AM, Adhemerval Zanella wrote:
>>>> Do we still have time for the posix_spawnattr_tcsetpgrp_np [1]? I think the
>>>> code should be simple enough.
>>>>
>>>> [1] https://patchwork.sourceware.org/project/glibc/patch/20210617175751.1619846-2-adhemerval.zanella@linaro.org/
>>> No, I do not think we have enough time, or to be more precise I want 
>>> to review the use case, ask Godmar to verify that API does what is
>>> required, and *then* include it in the release.
>>
>> Fair enough.
>>
>>>
>>> I want to use the remaining 6 days to fix bugs without any further
>>> ABI work.
>>>
>>> I would like to see:
>>> - LD_AUDIT bugs fixed.
>>> - pthread condvar bugs fixed.
>>> - C.UTF-8 added as supported (resolved Florian's last comment about U+FFFD usage).
>>>
>>
>> I would like to add some extra time64 tests changes [1].  They do not touch
>> the code, besides libsupport.
>>
>> [1] https://patchwork.sourceware.org/project/glibc/list/?series=2510
> 
> Absolutely, we should review this and merge it.
> 
> I see the 32-bit builder failed this series:
> NONE -> FAIL : socket/tst-socket-timestamp
> NONE -> FAIL : socket/tst-socket-timestamp-time64

Ok, now we have some logs, I will take a look into it.

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Adhemerval Zanella]

On 26/07/2021 10:00, Carlos O'Donell wrote:
> On 7/23/21 9:13 AM, Adhemerval Zanella wrote:
>>
>>
>> On 23/07/2021 02:13, Carlos O'Donell wrote:
>>> On 7/22/21 9:24 AM, Adhemerval Zanella wrote:
>>>> Do we still have time for the posix_spawnattr_tcsetpgrp_np [1]? I think the
>>>> code should be simple enough.
>>>>
>>>> [1] https://patchwork.sourceware.org/project/glibc/patch/20210617175751.1619846-2-adhemerval.zanella@linaro.org/
>>> No, I do not think we have enough time, or to be more precise I want 
>>> to review the use case, ask Godmar to verify that API does what is
>>> required, and *then* include it in the release.
>>
>> Fair enough.
>>
>>>
>>> I want to use the remaining 6 days to fix bugs without any further
>>> ABI work.
>>>
>>> I would like to see:
>>> - LD_AUDIT bugs fixed.
>>> - pthread condvar bugs fixed.
>>> - C.UTF-8 added as supported (resolved Florian's last comment about U+FFFD usage).
>>>
>>
>> I would like to add some extra time64 tests changes [1].  They do not touch
>> the code, besides libsupport.
>>
>> [1] https://patchwork.sourceware.org/project/glibc/list/?series=2510
> 
> Absolutely, we should review this and merge it.
> 
> I see the 32-bit builder failed this series:
> NONE -> FAIL : socket/tst-socket-timestamp
> NONE -> FAIL : socket/tst-socket-timestamp-time64

Carlos, this again does seems another container runtime filtering issue.
The non 64-bit shows the following log: 

../sysdeps/unix/sysv/linux/tst-socket-timestamp.c:156: numeric comparison failure
   left: 1 (0x1); from: errno
  right: 9 (0x9); from: EBADF
../sysdeps/unix/sysv/linux/tst-socket-timestamp.c:94: numeric comparison failure
   left: -1 (0xffffffff); from: r
  right: 4 (0x4); from: sizeof (int)
../sysdeps/unix/sysv/linux/tst-socket-timestamp.c:95: numeric comparison failure
   left: -84852 (0xfffeb48c); from: msg
  right: 0 (0x0); from: exp_msg
Didn't expect signal from child: got `Segmentation fault'

The first issue on line 156 is:

155   TEST_COMPARE (recvmmsg (-1, NULL, 0, 0, NULL), -1);
156   TEST_COMPARE (errno, EBADF);

It means that a recvmmsg syscall is returning EPERM instead of EBADF
for an *invalid* file descriptor, even with the input size is set to
0 (which should not trigger any EFAULT from the kernel).

The another issue is that the recvmsg/recvmmsg is failing for some
reason:

 85   int r;
 86   if (use_multi_call)
 87     {
 88       r = recvmmsg (s, &mmhdr, 1, 0, NULL);
 89       if (r >= 0)
 90         r = mmhdr.msg_len;
 91     }
 92   else
 93     r = recvmsg (s, &mmhdr.msg_hdr, 0);
 94   TEST_COMPARE (r, sizeof (int));
 95   TEST_COMPARE (msg, exp_msg);

I tested both 32-bit and 64-bit tests on multiple kernel (3.10, 4.4, 4.15,
and 5.11) without any issue, but all without any container runtime.

The tests creates and binds on a random TCP/IP port, so it *might* be the
case. I think I can use a socketpair using AF_UNIX for this tests (I need
to verify if SO_TIMESTAMPNS are set for such case), but I will need some
strace output to understand exactly why it is failing on the buildbot.

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Siddhesh Poyarekar]

On 7/22/21 6:01 PM, Carlos O'Donell via Libc-alpha wrote:
>>> - Remove malloc hooks.
>>> https://patchwork.sourceware.org/project/glibc/list/?series=2406
>>
>> I have reviewed v8 and I think it should be included in 2.34.
>>
>> I'll review a v9 for inclusion.
> 
> Review is complete. I consider this ABI frozen. Siddhesh please commit.

Thank you for the reviews.  Pushed.

Siddhesh

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[H.J. Lu]

On Sun, Jul 18, 2021 at 7:16 PM Carlos O'Donell via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> On 7/4/21 10:43 PM, Carlos O'Donell wrote:
> > We are in slushy freeze right now. I'm reviewing the last of the ABI
> > changes we want to make in glibc 2.34.
>
> The ABI freeze is now hard freeze, I would like to avoid any further ABI
> changes that are not on this list.
>
> If you have an ABI change please reach and respond to this thread
> immediately with the request.
>
> I would like to spend this week and next fixing any remaining bugs
> and doing machine testing.
>
> > The ABI changes that are currently under review:
> >
> > - Move nss_dns into libc.
> > https://patchwork.sourceware.org/project/glibc/list/?series=2407
>
> I have reviewed v2 and I think it should be included in 2.34.
>
> I have just reviewed the final v3 changes so this should go in on Monday.
>
> > - Remove malloc hooks.
> > https://patchwork.sourceware.org/project/glibc/list/?series=2406
>
> I have reviewed v8 and I think it should be included in 2.34.
>
> I'll review a v9 for inclusion.
>
> > - nss_files move.
> > https://patchwork.sourceware.org/project/glibc/list/?series=2386
>
> This was reviewed by Adhemerval and committed July 7th.
>
> > - Add close_range, closefrom, and posix_spawn_file_actions_closefrom_np
> > https://patchwork.sourceware.org/project/glibc/list/?series=2363
>
> This was committed by Adhemerval on July 8th.
>
> > - Define PTHREAD_STACK_MIN to sysconf(_SC_THREAD_STACK_MIN)
> > https://patchwork.sourceware.org/project/glibc/list/?series=2345
>
> I have reviewed this, and it was committed by HJ on July 9th.
>
> > - x86: Install <bits/platform/x86.h> [BZ #27958]
> > https://patchwork.sourceware.org/project/glibc/list/?series=2272
>
> I have reviewed this and requested some changes.
>
> I have reviewed this again and I am discussing the final wording with HJ.
>
> I think this should be included in glibc 2.34 and we will get there.
>
> --
> Cheers,
> Carlos.
>

It was a mistake to export _r_debug from ld.so:

https://sourceware.org/bugzilla/show_bug.cgi?id=28130

I'd like to deprecate _r_debug in glibc 2.34 and replace it with:

/* Return the address of that structure used by the dynamic linker.  */
extern struct r_debug * __r_debug_location (void) __attribute_const__;
#define _r_debug (*__r_debug_location ())

so that I can extend struct r_debug for libraries loaded with dlmopen:

https://gitlab.com/x86-psABIs/Linux-ABI/-/issues/2

-- 
H.J.

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Florian Weimer]

* H. J. Lu via Libc-alpha:

> It was a mistake to export _r_debug from ld.so:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=28130
>
> I'd like to deprecate _r_debug in glibc 2.34 and replace it with:
>
> /* Return the address of that structure used by the dynamic linker.  */
> extern struct r_debug * __r_debug_location (void) __attribute_const__;
> #define _r_debug (*__r_debug_location ())
>
> so that I can extend struct r_debug for libraries loaded with dlmopen:
>
> https://gitlab.com/x86-psABIs/Linux-ABI/-/issues/2

We need to keep it as a symbol because debuggers use it.

If GCC had a an attribute that says, no copy relocation please, we could
perhaps use that in <link.h>.

Maybe we can turn it into a compat symbol.  But it's too late for such
changes in glibc 2.34.

The replacement could use a separate symbol version (GLIBC_DEBUG) with
different ABI stability rules, which would pave the way towards
backporting.

Thanks,
Florian

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[H.J. Lu]

On Sun, Jul 25, 2021 at 2:55 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu via Libc-alpha:
>
> > It was a mistake to export _r_debug from ld.so:
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=28130
> >
> > I'd like to deprecate _r_debug in glibc 2.34 and replace it with:
> >
> > /* Return the address of that structure used by the dynamic linker.  */
> > extern struct r_debug * __r_debug_location (void) __attribute_const__;
> > #define _r_debug (*__r_debug_location ())
> >
> > so that I can extend struct r_debug for libraries loaded with dlmopen:
> >
> > https://gitlab.com/x86-psABIs/Linux-ABI/-/issues/2
>
> We need to keep it as a symbol because debuggers use it.

_r_debug is only needed in the static executable.  Debuggers should use
DT_DEBUG for dynamic executables.

> If GCC had a an attribute that says, no copy relocation please, we could
> perhaps use that in <link.h>.
>
> Maybe we can turn it into a compat symbol.  But it's too late for such

We can make it a compat symbol:

1. Add a function, __r_debug_location, which returns the address of
_r_debug:

/* Return the address of that structure used by the dynamic linker.  */
extern struct r_debug * __r_debug_location (void) __attribute_const__;

2. Hide _r_debug in ld.so by defining _r_debug with __r_debug_location:

 #define _r_debug (*__r_debug_location ())

The existing dynamic executables with _r_debug reference will get a copy
of _r_debug which won't be updated by ld.so.  But DT_DEBUG will work with
debuggers.
3. The static executables linked against glibc 2.34 will get the _r_debug
symbol from __r_debug_location definition in libc.a.

> changes in glibc 2.34.
>
> The replacement could use a separate symbol version (GLIBC_DEBUG) with
> different ABI stability rules, which would pave the way towards
> backporting.

There is no need for a special version symbol.   I have a proposal to make
it both forward and backward compatible.

-- 
H.J.

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Florian Weimer]

* H. J. Lu:

> On Sun, Jul 25, 2021 at 2:55 PM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * H. J. Lu via Libc-alpha:
>>
>> > It was a mistake to export _r_debug from ld.so:
>> >
>> > https://sourceware.org/bugzilla/show_bug.cgi?id=28130
>> >
>> > I'd like to deprecate _r_debug in glibc 2.34 and replace it with:
>> >
>> > /* Return the address of that structure used by the dynamic linker.  */
>> > extern struct r_debug * __r_debug_location (void) __attribute_const__;
>> > #define _r_debug (*__r_debug_location ())
>> >
>> > so that I can extend struct r_debug for libraries loaded with dlmopen:
>> >
>> > https://gitlab.com/x86-psABIs/Linux-ABI/-/issues/2
>>
>> We need to keep it as a symbol because debuggers use it.
>
> _r_debug is only needed in the static executable.  Debuggers should use
> DT_DEBUG for dynamic executables.

We don't really know that for sure, do we?  This needs more
investigation, and we are out of time for the release.

>> changes in glibc 2.34.
>>
>> The replacement could use a separate symbol version (GLIBC_DEBUG) with
>> different ABI stability rules, which would pave the way towards
>> backporting.
>
> There is no need for a special version symbol.   I have a proposal to make
> it both forward and backward compatible.

If it's GLIBC_2.35, we won't be able to backport it.

Thanks,
Florian

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Andreas Schwab]

On Jul 25 2021, H.J. Lu via Libc-alpha wrote:

> 1. Add a function, __r_debug_location, which returns the address of
> _r_debug:

There is no need for that.  Debuggers can easily find the unique
instance, and there are no other uses.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[Carlos O'Donell]

On 7/25/21 3:46 PM, H.J. Lu wrote:
> On Sun, Jul 18, 2021 at 7:16 PM Carlos O'Donell via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>>
>> On 7/4/21 10:43 PM, Carlos O'Donell wrote:
>>> We are in slushy freeze right now. I'm reviewing the last of the ABI
>>> changes we want to make in glibc 2.34.
>>
>> The ABI freeze is now hard freeze, I would like to avoid any further ABI
>> changes that are not on this list.
>>
>> If you have an ABI change please reach and respond to this thread
>> immediately with the request.
>>
>> I would like to spend this week and next fixing any remaining bugs
>> and doing machine testing.
>>
>>> The ABI changes that are currently under review:
>>>
>>> - Move nss_dns into libc.
>>> https://patchwork.sourceware.org/project/glibc/list/?series=2407
>>
>> I have reviewed v2 and I think it should be included in 2.34.
>>
>> I have just reviewed the final v3 changes so this should go in on Monday.
>>
>>> - Remove malloc hooks.
>>> https://patchwork.sourceware.org/project/glibc/list/?series=2406
>>
>> I have reviewed v8 and I think it should be included in 2.34.
>>
>> I'll review a v9 for inclusion.
>>
>>> - nss_files move.
>>> https://patchwork.sourceware.org/project/glibc/list/?series=2386
>>
>> This was reviewed by Adhemerval and committed July 7th.
>>
>>> - Add close_range, closefrom, and posix_spawn_file_actions_closefrom_np
>>> https://patchwork.sourceware.org/project/glibc/list/?series=2363
>>
>> This was committed by Adhemerval on July 8th.
>>
>>> - Define PTHREAD_STACK_MIN to sysconf(_SC_THREAD_STACK_MIN)
>>> https://patchwork.sourceware.org/project/glibc/list/?series=2345
>>
>> I have reviewed this, and it was committed by HJ on July 9th.
>>
>>> - x86: Install <bits/platform/x86.h> [BZ #27958]
>>> https://patchwork.sourceware.org/project/glibc/list/?series=2272
>>
>> I have reviewed this and requested some changes.
>>
>> I have reviewed this again and I am discussing the final wording with HJ.
>>
>> I think this should be included in glibc 2.34 and we will get there.
>>
>> --
>> Cheers,
>> Carlos.
>>
> 
> It was a mistake to export _r_debug from ld.so:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=28130
> 
> I'd like to deprecate _r_debug in glibc 2.34 and replace it with:
> 
> /* Return the address of that structure used by the dynamic linker.  */
> extern struct r_debug * __r_debug_location (void) __attribute_const__;
> #define _r_debug (*__r_debug_location ())
> 
> so that I can extend struct r_debug for libraries loaded with dlmopen:
> 
> https://gitlab.com/x86-psABIs/Linux-ABI/-/issues/2
 
This needs more review, and is too late for glibc 2.34.

I'm happy to review the situation once we open glibc 2.35.

I think that fixing _r_debug and discussing dlmopen will take several
weeks to achieve consensus and review existing best practice and
patches.

Do you have a strong objection to waiting for glibc 2.35?

-- 
Cheers,
Carlos.

Re: glibc 2.34 - Hard ABI freeze effective immediately.

[H.J. Lu]

On Mon, Jul 26, 2021 at 7:29 AM Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 7/25/21 3:46 PM, H.J. Lu wrote:
> > On Sun, Jul 18, 2021 at 7:16 PM Carlos O'Donell via Libc-alpha
> > <libc-alpha@sourceware.org> wrote:
> >>
> >> On 7/4/21 10:43 PM, Carlos O'Donell wrote:
> >>> We are in slushy freeze right now. I'm reviewing the last of the ABI
> >>> changes we want to make in glibc 2.34.
> >>
> >> The ABI freeze is now hard freeze, I would like to avoid any further ABI
> >> changes that are not on this list.
> >>
> >> If you have an ABI change please reach and respond to this thread
> >> immediately with the request.
> >>
> >> I would like to spend this week and next fixing any remaining bugs
> >> and doing machine testing.
> >>
> >>> The ABI changes that are currently under review:
> >>>
> >>> - Move nss_dns into libc.
> >>> https://patchwork.sourceware.org/project/glibc/list/?series=2407
> >>
> >> I have reviewed v2 and I think it should be included in 2.34.
> >>
> >> I have just reviewed the final v3 changes so this should go in on Monday.
> >>
> >>> - Remove malloc hooks.
> >>> https://patchwork.sourceware.org/project/glibc/list/?series=2406
> >>
> >> I have reviewed v8 and I think it should be included in 2.34.
> >>
> >> I'll review a v9 for inclusion.
> >>
> >>> - nss_files move.
> >>> https://patchwork.sourceware.org/project/glibc/list/?series=2386
> >>
> >> This was reviewed by Adhemerval and committed July 7th.
> >>
> >>> - Add close_range, closefrom, and posix_spawn_file_actions_closefrom_np
> >>> https://patchwork.sourceware.org/project/glibc/list/?series=2363
> >>
> >> This was committed by Adhemerval on July 8th.
> >>
> >>> - Define PTHREAD_STACK_MIN to sysconf(_SC_THREAD_STACK_MIN)
> >>> https://patchwork.sourceware.org/project/glibc/list/?series=2345
> >>
> >> I have reviewed this, and it was committed by HJ on July 9th.
> >>
> >>> - x86: Install <bits/platform/x86.h> [BZ #27958]
> >>> https://patchwork.sourceware.org/project/glibc/list/?series=2272
> >>
> >> I have reviewed this and requested some changes.
> >>
> >> I have reviewed this again and I am discussing the final wording with HJ.
> >>
> >> I think this should be included in glibc 2.34 and we will get there.
> >>
> >> --
> >> Cheers,
> >> Carlos.
> >>
> >
> > It was a mistake to export _r_debug from ld.so:
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=28130
> >
> > I'd like to deprecate _r_debug in glibc 2.34 and replace it with:
> >
> > /* Return the address of that structure used by the dynamic linker.  */
> > extern struct r_debug * __r_debug_location (void) __attribute_const__;
> > #define _r_debug (*__r_debug_location ())
> >
> > so that I can extend struct r_debug for libraries loaded with dlmopen:
> >
> > https://gitlab.com/x86-psABIs/Linux-ABI/-/issues/2
>
> This needs more review, and is too late for glibc 2.34.
>
> I'm happy to review the situation once we open glibc 2.35.
>
> I think that fixing _r_debug and discussing dlmopen will take several
> weeks to achieve consensus and review existing best practice and
> patches.
>
> Do you have a strong objection to waiting for glibc 2.35?
>

2.35 is OK.

Thanks.

-- 
H.J.