From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7478A3858D35; Mon, 11 Oct 2021 20:51:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7478A3858D35 From: "carlos at redhat dot com" To: libc-locales@sourceware.org Subject: [Bug localedata/20664] Unexpected collation in en_US.UTF-8, different to ICU CLDR Date: Mon, 11 Oct 2021 20:51:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: localedata X-Bugzilla-Version: 2.23 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 2.33 X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: bug_status resolution target_milestone Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: libc-locales@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-locales mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 20:51:47 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D20664 Carlos O'Donell changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.33 --- Comment #7 from Carlos O'Donell --- (In reply to Kirill Elagin from comment #6) > I am getting collation results as expected (meaning, no difference between > en_US.UTF-8 and POSIX) for the example strings with glibc 2.32. >=20 > Is this issue safe to close? In glibc 2.32 we upgraded to Unicode 13.0.0, and glibc 2.35 (Feb 2, 2022) w= ill include Unicode 14.0.0 support. Neither of these updates substantially chan= ged collation (involved in sort). However, I agree with you that Fedora 34 with glibc 2.33 that we get matching results: echo -e "+00\n-0c\n+02\n-02" | LC_ALL=3Den_US.UTF-8 sort +00 +02 -02 -0c The collation data always had < which results in + < -. I'm marking this as RESOLVED/FIXED in glibc 2.33. We can reopen if we run into = this again to determine what is the root cause of the original mis-ordering in 2= .32. --=20 You are receiving this mail because: You are on the CC list for the bug.=