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.