Accepting request 1062299 from home:Andreas_Schwab:glibc:rebuild

- tests-tsprintf.patch: Avoid testsuite failure with glibc >= 2.37

OBS-URL: https://build.opensuse.org/request/show/1062299
OBS-URL: https://build.opensuse.org/package/show/devel:libraries:c_c++/mpfr?expand=0&rev=75

mpfr.changes

@@ -1,3 +1,8 @@
+-------------------------------------------------------------------
+Tue Jan 31 15:58:22 UTC 2023 - Andreas Schwab <schwab@suse.de>
+
+- tests-tsprintf.patch: Avoid testsuite failure with glibc >= 2.37
+
 -------------------------------------------------------------------
 Mon Jan  9 08:22:17 UTC 2023 - Richard Biener <rguenther@suse.com>
 

mpfr.spec

@@ -27,6 +27,7 @@ Source0:        https://www.mpfr.org/mpfr-%{version}/mpfr-%{version}.tar.xz
 Source1:        https://www.mpfr.org/mpfr-%{version}/mpfr-%{version}.tar.xz.asc
 Source2:        %{name}.keyring
 Source3:        baselibs.conf
+Patch0:         tests-tsprintf.patch
 BuildRequires:  gmp-devel
 BuildRequires:  pkgconfig
 
@@ -67,6 +68,7 @@ based on the GMP multiple-precision library.
 
 %prep
 %setup -q
+%patch0 -p1
 
 %build
 %configure \

tests-tsprintf.patch

@@ -0,0 +1,56 @@
+From 5172494c09718ffcb7ef1f19b3b211e3bce8781a Mon Sep 17 00:00:00 2001
+From: Vincent Lefevre <vincent@vinc17.net>
+Date: Tue, 10 Jan 2023 17:05:17 +0100
+Subject: [PATCH] [tests/tsprintf.c] Modified a buggy test of the thousands
+ separator.
+
+The test
+
+  check_vsprintf ("+01,234,567  :", "%0+ -'13.10Pd:", (mpfr_prec_t) 1234567);
+
+is based on the output from glibc up to 2.36, which is incorrect:
+
+  https://sourceware.org/bugzilla/show_bug.cgi?id=23432
+
+The GNU C Library has apparently been partially fixed in its Git
+repository for the future 2.37, since a tsprintf failure has been
+reported (this is a bug in this test, not in the MPFR library):
+
+  https://sympa.inria.fr/sympa/arc/mpfr/2023-01/msg00001.html
+
+So, modified the test to avoid the particular case of leading zeros
+due to the precision field larger than the number of digits. This
+case has already been tested without the thousands separator (where
+there are no issues with the C libraries), so that we do not miss
+much testing. Added a comment explaining the issue and a possible
+solution for future testing of this particular case (if need be).
+---
+ tests/tsprintf.c | 12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/tests/tsprintf.c b/tests/tsprintf.c
+index c68b2ba71..c0182503b 100644
+--- a/tests/tsprintf.c
++++ b/tests/tsprintf.c
+@@ -1719,7 +1719,17 @@ test_locale (void)
+   check_sprintf ("000000001,000", "%'013.4Rg", x);
+ 
+ #ifdef PRINTF_GROUPFLAG
+-  check_vsprintf ("+01,234,567  :", "%0+ -'13.10Pd:", (mpfr_prec_t) 1234567);
++  /* Do not test the thousands separator with a precision field larger
++     than the number of digits (thus needing leading zeros), such as
++     "%0+ -'13.10Pd:" (used up to MPFR 4.2.0), since the GNU libc is
++     buggy: https://sourceware.org/bugzilla/show_bug.cgi?id=23432
++     We don't know about the other implementations.
++     If we wanted to check that and avoid a failure of the test because of
++     a buggy C library (while MPFR would be consistent with the C library),
++     we could compare the MPFR output with both the correct output and the
++     output from the C library (possibly buggy). But to do that in a clean
++     way, this would require a change in the check_vsprintf() call. */
++  check_vsprintf ("+1,234,567   :", "%0+ -'13Pd:", (mpfr_prec_t) 1234567);
+ #endif
+ 
+   mpfr_clear (x);
+-- 
+2.39.1
+