ABI changes still pending for glibc 2.32?

ABI changes still pending for glibc 2.32?

[Carlos O'Donell]

Community,

What ABI changes are still pending for glibc 2.32?

Jim, You called out RISC-V patches that need review. Do they impact ABI?

Alistair, You called out the semctl_syscall() changes. I assume they impact ABI?

Adhemerval, What is your status reviewing semctl_syscall()?

Vineet, What is the status of the ARC port?

For context I'm considering a few ABI changes to be allowed next week while we
enter "slushy" ABI freeze and I want to narrow that list down.

-- 
Cheers,
Carlos.

Re: ABI changes still pending for glibc 2.32?

[H.J. Lu]

On Fri, Jun 26, 2020 at 9:11 AM Carlos O'Donell via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> Community,
>
> What ABI changes are still pending for glibc 2.32?
>
> Jim, You called out RISC-V patches that need review. Do they impact ABI?
>
> Alistair, You called out the semctl_syscall() changes. I assume they impact ABI?
>
> Adhemerval, What is your status reviewing semctl_syscall()?
>
> Vineet, What is the status of the ARC port?
>
> For context I'm considering a few ABI changes to be allowed next week while we
> enter "slushy" ABI freeze and I want to narrow that list down.
>

Also <sys/platform/x86.h>:

https://sourceware.org/pipermail/libc-alpha/2020-June/115397.html

-- 
H.J.

Re: ABI changes still pending for glibc 2.32?

[Vineet Gupta]

Hi Carlos,

On 6/26/20 9:11 AM, Carlos O'Donell wrote:
> Vineet, What is the status of the ARC port?

Pretty good if you ask me ;-)

I don't think ARC port leads to any public ABI changes (but does depend on semctl
changes as we follow the same ABI). Any ensuing common changes (non ABI) have long
since been merged.

I've recently posted v7 so it's been through a fair bit of review and rework.
Special shout-out to Adhemeral and Joseph for that.
Honestly it seems production quality to me, just waiting for the green light from
past-reviewers / maintainers.

Thx,
-Vineet

Re: ABI changes still pending for glibc 2.32?

[Alistair Francis]

On Fri, Jun 26, 2020 at 9:11 AM Carlos O'Donell <carlos@redhat.com> wrote:
>
> Community,
>
> What ABI changes are still pending for glibc 2.32?
>
> Jim, You called out RISC-V patches that need review. Do they impact ABI?

The RISC-V patches add support for RV32, which currently doesn't
exist. I guess it depends on what you mean by impact, but it doesn't
change the ABI per se, it just adds new targets.

>
> Alistair, You called out the semctl_syscall() changes. I assume they impact ABI?

Yep, they do.

Alistair

>
> Adhemerval, What is your status reviewing semctl_syscall()?
>
> Vineet, What is the status of the ARC port?
>
> For context I'm considering a few ABI changes to be allowed next week while we
> enter "slushy" ABI freeze and I want to narrow that list down.
>
> --
> Cheers,
> Carlos.
>

Re: ABI changes still pending for glibc 2.32?

[Szabolcs Nagy]

The 06/26/2020 12:11, Carlos O'Donell via Libc-alpha wrote:
> Community,
> 
> What ABI changes are still pending for glibc 2.32?

do you consider abi between rtld and
libc as abi change?

the aarch64 branch protection patches
change the link_map struct (to record
what modules are marked with the bti
gnu property).

and the surplus static tls patches add
new fields to the rtld_global struct.

> 
> Jim, You called out RISC-V patches that need review. Do they impact ABI?
> 
> Alistair, You called out the semctl_syscall() changes. I assume they impact ABI?
> 
> Adhemerval, What is your status reviewing semctl_syscall()?
> 
> Vineet, What is the status of the ARC port?
> 
> For context I'm considering a few ABI changes to be allowed next week while we
> enter "slushy" ABI freeze and I want to narrow that list down.
> 
> -- 
> Cheers,
> Carlos.
> 

-- 

Re: ABI changes still pending for glibc 2.32?

[Florian Weimer]

* Szabolcs Nagy:

> The 06/26/2020 12:11, Carlos O'Donell via Libc-alpha wrote:
>> Community,
>> 
>> What ABI changes are still pending for glibc 2.32?
>
> do you consider abi between rtld and
> libc as abi change?

I don't.

> the aarch64 branch protection patches
> change the link_map struct (to record
> what modules are marked with the bti
> gnu property).

This is not public ABI.  Still it's probably a good idea to get these
changes in early next month, shortly after the public ABI changes.

> and the surplus static tls patches add
> new fields to the rtld_global struct.

Likewise.

Re: ABI changes still pending for glibc 2.32?

[Florian Weimer]

* Carlos O'Donell via Libc-alpha:

> What ABI changes are still pending for glibc 2.32?

I would like to see __rseq_abi and __libc_single_threaded to make it
into the release.

Jonathan Wakely is validating the glibc binary128 long double changes
for POWER, which could reveal ABI problems that would ideally be fixed
before the release.

Re: ABI changes still pending for glibc 2.32?

[Adhemerval Zanella]

On 26/06/2020 18:11, Alistair Francis via Libc-alpha wrote:
> On Fri, Jun 26, 2020 at 9:11 AM Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> Community,
>>
>> What ABI changes are still pending for glibc 2.32?
>>
>> Jim, You called out RISC-V patches that need review. Do they impact ABI?
> 
> The RISC-V patches add support for RV32, which currently doesn't
> exist. I guess it depends on what you mean by impact, but it doesn't
> change the ABI per se, it just adds new targets.
> 
>>
>> Alistair, You called out the semctl_syscall() changes. I assume they impact ABI?
> 
> Yep, they do.
> 
> Alistair
> 
>>
>> Adhemerval, What is your status reviewing semctl_syscall()?

I think v9 still does not get it right what we are discussing and I am 
rewriting it to get this moving forward.

>>
>> Vineet, What is the status of the ARC port?
>>
>> For context I'm considering a few ABI changes to be allowed next week while we
>> enter "slushy" ABI freeze and I want to narrow that list down.
>>
>> --
>> Cheers,
>> Carlos.
>>

Re: ABI changes still pending for glibc 2.32?

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

Am Freitag, 26. Juni 2020, 18:11:23 CEST schrieb Carlos O'Donell via Libc-
alpha:
> Community,
> 
> What ABI changes are still pending for glibc 2.32?
> 

Independent of ABI changes, now's probably also a good time to decide about 
bug 25923, 'Regression: en_US date_fmt and d_t_fmt and "%a %d %b" vs. "%a %b 
%e"'.

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

Whichever way it goes, the later this is finalized the worse...


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: ABI changes still pending for glibc 2.32?

[Carlos O'Donell]

On 6/30/20 6:38 PM, Andreas K. Huettel via Libc-alpha wrote:
> Am Freitag, 26. Juni 2020, 18:11:23 CEST schrieb Carlos O'Donell via Libc-
> alpha:
>> Community,
>>
>> What ABI changes are still pending for glibc 2.32?
>>
> 
> Independent of ABI changes, now's probably also a good time to decide about 
> bug 25923, 'Regression: en_US date_fmt and d_t_fmt and "%a %d %b" vs. "%a %b 
> %e"'.
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=25923
> 
> Whichever way it goes, the later this is finalized the worse...

It's on the release blocker list. I'll get this fixed.

-- 
Cheers,
Carlos.

Re: ABI changes still pending for glibc 2.32?

[Andreas K. Hüttel]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

Am Samstag, 4. Juli 2020, 00:24:13 EEST schrieb Carlos O'Donell:
> > Independent of ABI changes, now's probably also a good time to decide
> > about
> > bug 25923, 'Regression: en_US date_fmt and d_t_fmt and "%a %d %b" vs. "%a
> > %b %e"'.
> > 
> > https://sourceware.org/bugzilla/show_bug.cgi?id=25923
> > 
> > Whichever way it goes, the later this is finalized the worse...
> 
> It's on the release blocker list. I'll get this fixed.

Fixed as in

1) follow the slow distros like RHEL, which are two releases behind and can 
still patch it in the release branch without impact to users,

or fixed as in 

2) follow the fast distros like Gentoo, where users have already screamed at 
the maintainers and adapted their scripts (while threatening to switch to 
musl)?

:)

I'm mostly asking because this will have an impact on my policy for Gentoo 
stable. 
If we follow 1), then it would make sense to keep Gentoo stable 2-3 releases 
back (like 2.29) to avoid silliness. 
Current Gentoo stable is 2.30, with 2.31 stabilization pending.


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: ABI changes still pending for glibc 2.32?

[Carlos O'Donell]

On 7/3/20 5:52 PM, Andreas K. Hüttel wrote:
> Am Samstag, 4. Juli 2020, 00:24:13 EEST schrieb Carlos O'Donell:
>>> Independent of ABI changes, now's probably also a good time to decide
>>> about
>>> bug 25923, 'Regression: en_US date_fmt and d_t_fmt and "%a %d %b" vs. "%a
>>> %b %e"'.
>>>
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=25923
>>>
>>> Whichever way it goes, the later this is finalized the worse...
>>
>> It's on the release blocker list. I'll get this fixed.
> 
> Fixed as in
> 
> 1) follow the slow distros like RHEL, which are two releases behind and can 
> still patch it in the release branch without impact to users,
> 
> or fixed as in 
> 
> 2) follow the fast distros like Gentoo, where users have already screamed at 
> the maintainers and adapted their scripts (while threatening to switch to 
> musl)?

The first report of the bug I saw was filed 2020-05-03:
https://bugzilla.redhat.com/show_bug.cgi?id=1830623

I immediately took it to the list here on 2020-05-05:
https://sourceware.org/pipermail/libc-alpha/2020-May/113634.html

I immediately filed bug 25923:
https://sourceware.org/bugzilla/show_bug.cgi?id=25923

If a defect is detected in a fast moving distro, please file it upstream.

Good communication is required if we are going to fix bugs, and I feel
like this community is accomodating and reaches out to downstreams like
Gentoo to get involved.

My opinion is that the *larger* body of users has only started to see
this problem and will lobby their distributions to fix the issue.

Therefore I think the best course of action is to minimize the impact
of commit 7395f3a0efad9fc51bb54fa383ef6524702e0c49 and switch the month
back.

While I am Canadian, I can attest to having US knowledge and sensibilities,
and I find '%a %b %e %r %Z %Y' more "natural looking" and expected.
I can also confirm 24H clocks are uncommon and all business use 12H clocks
for opening and closing times etc.

> :)
> 
> I'm mostly asking because this will have an impact on my policy for Gentoo 
> stable. 
> If we follow 1), then it would make sense to keep Gentoo stable 2-3 releases 
> back (like 2.29) to avoid silliness. 
> Current Gentoo stable is 2.30, with 2.31 stabilization pending.
 
If you stay 2-3 releases behind then *other* faster moving distros will
serve to identify bugs like this and they will get fixed before you see
them. However, you will then be 2-3 releases behind and have all of those
kinds of problems i.e. Debian Buster is at 2.28 (3, soon 4 releases behind).
This is your choice. I don't call it "silly" because it's a real bug and an
adjustment to locale data to better suit those using _DATE_FMT via
_nl_langinfo().

In this case the regression was identified in the released Fedora 32, with
the upcoming Fedora 33 being based on glibc 2.32 would contain the fix
along with any backports to active Fedora releases (in this case for F32).

-- 
Cheers,
Carlos.

Re: ABI changes still pending for glibc 2.32?

[Andreas K. Hüttel]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

Am Mittwoch, 8. Juli 2020, 22:56:12 EEST schrieb Carlos O'Donell:
>
> The first report of the bug I saw was filed 2020-05-03:
> https://bugzilla.redhat.com/show_bug.cgi?id=1830623
>

>
> This is your choice. I don't call it "silly" because it's a real bug and an
> adjustment to locale data to better suit those using _DATE_FMT via
> _nl_langinfo().
> 

Yeah there was maybe my non-US bias involved. 

We did get some report on it, but I discarded that because I saw the change as 
obvious cleanup (on the same level as the regular header fixing, "well it 
breaks something but we'll have to do it one day").

Then again, in a wider sense from that perspective probably "going metric" 
would also be a valid bug fix... :D

Anyway, looking forward to 2.32 and thanks for your work!

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: ABI changes still pending for glibc 2.32?

[Carlos O'Donell]

On 7/10/20 8:59 AM, Andreas K. Hüttel wrote:
> Am Mittwoch, 8. Juli 2020, 22:56:12 EEST schrieb Carlos O'Donell:
>>
>> The first report of the bug I saw was filed 2020-05-03:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1830623
>>
> 
>>
>> This is your choice. I don't call it "silly" because it's a real bug and an
>> adjustment to locale data to better suit those using _DATE_FMT via
>> _nl_langinfo().
>>
> 
> Yeah there was maybe my non-US bias involved. 
> 
> We did get some report on it, but I discarded that because I saw the change as 
> obvious cleanup (on the same level as the regular header fixing, "well it 
> breaks something but we'll have to do it one day").
> 
> Then again, in a wider sense from that perspective probably "going metric" 
> would also be a valid bug fix... :D

We have to ask our users :-)
 
> Anyway, looking forward to 2.32 and thanks for your work!

Thank you. I take it this means you are OK with the plan going forward.

I have review from Florian so I'll probably push the en_US fix next
week and give Rafal or Mike time to comment.

-- 
Cheers,
Carlos.

Re: ABI changes still pending for glibc 2.32?

[Andreas K. Hüttel]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

Am Freitag, 10. Juli 2020, 23:39:22 EEST schrieb Carlos O'Donell:
>
> > Then again, in a wider sense from that perspective probably "going metric"
> > would also be a valid bug fix... :D
> 
> We have to ask our users :-)
> 
> > Anyway, looking forward to 2.32 and thanks for your work!
> 
> Thank you. I take it this means you are OK with the plan going forward.

Yes, please go ahead. 

Medium term a backport to the older release branches would be nice.

> 
> I have review from Florian so I'll probably push the en_US fix next
> week and give Rafal or Mike time to comment.


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: ABI changes still pending for glibc 2.32?

[Florian Weimer]

* Andreas K. Hüttel via Libc-alpha:

> Am Freitag, 10. Juli 2020, 23:39:22 EEST schrieb Carlos O'Donell:
>>
>> > Then again, in a wider sense from that perspective probably "going metric"
>> > would also be a valid bug fix... :D
>> 
>> We have to ask our users :-)
>> 
>> > Anyway, looking forward to 2.32 and thanks for your work!
>> 
>> Thank you. I take it this means you are OK with the plan going forward.
>
> Yes, please go ahead. 
>
> Medium term a backport to the older release branches would be nice.

I expect that few distributions want to change locales during a
release in this way.  If you want to pick up the change, I'd suggest a
local backport.

Re: ABI changes still pending for glibc 2.32?

[Andreas K. Hüttel]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

>
> > Medium term a backport to the older release branches would be nice.
> 
> I expect that few distributions want to change locales during a
> release in this way.  If you want to pick up the change, I'd suggest a
> local backport.

Well either it's a bug, then it needs to be fixed. Or 2.30 and 2.31 are 
somehow ... different? I mean, this is the whole point why I made noise in the 
first place. 

"You need to treat 2.30 and 2.31 differently, but we changed things again in 
2.32" is precisely what I meant with "sillyness".

Anyway. I'll just cherry-pick it, preferably before we stabilize 2.31. Then 
2.31 would need to be treated special only on non-Gentoo machines, and for us 
only 2.30 is special. (Does that sound any better to anyone? Not sure...)

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: ABI changes still pending for glibc 2.32?

[Carlos O'Donell]

On 7/11/20 12:27 PM, Andreas K. Hüttel wrote:
>>
>>> Medium term a backport to the older release branches would be nice.
>>
>> I expect that few distributions want to change locales during a
>> release in this way.  If you want to pick up the change, I'd suggest a
>> local backport.
> 
> Well either it's a bug, then it needs to be fixed. Or 2.30 and 2.31 are 
> somehow ... different? I mean, this is the whole point why I made noise in the 
> first place. 

We *should* have fixed in 2.30, but we failed to do so.

The problem is now this:

* When do users expect such layout to change?

  - Do users expect point releases to change time formatting?

  - Do users expect point releases to change collation sorting?

  - ...

In Fedora we have actively avoided changing some of these things, even if
they were wrong, because people were already working around the bugs and
expected only to see fixes in a major upgrade e.g. dnf system-upgrade.
They otherwise generally expected things to be stable in the released
version.

This is entirely a choice that you need to make as the downstream
maintainer.

I think upstream glibc should be as conservative in the release branches
as the union of the downstream distros.

Thus in public glibc release branches we don't generally:

* Change the collation of existing strings in the release.

* Change existing locales in ways which are visible and change widths,
  or lengths of vaious strings.

Yes, it does mean 2.30 and 2.31 are special, but it also means that people
can rely on their workarounds to work for all installed 2.30 and 2.31.

-- 
Cheers,
Carlos.