t3206-range-diff failures on non x86 arches (was: [ANNOUNCE] Git v2.40.0-rc1)

From: Todd Zullinger <tmz@pobox.com>
Date: Mar 1, 2023, 19:37 UTC
Message-ID: <Y/+paI8WGSmEbv/w@pobox.com>
In-Reply-To: <xmqqilfknzen.fsf@gitster.g>

Junio C Hamano wrote:

> A release candidate Git v2.40.0-rc1 is now available for testing at
> the usual places.  It is comprised of 458 non-merge commits since
> v2.39.0, contributed by 78 people, 30 of which are new faces [*].

On Fedora, rc1 fails most tests in t3206-range-diff.sh on 3 of the 5 supported architectures: aarch64, ppc64le, and s390x. These tests succeed on i686 and x86_64. They passed on all arches with rc0.

Here's a snipptet from the test summary and a common failure from the tests:

t3206-range-diff.sh                              (Wstat: 256 (exited 1) Tests: 42 Failed: 23)
  Failed tests:  2-4, 6, 8-19, 21-22, 32-34, 40, 42

+++ diff -u expect actual --- expect 2023-03-01 18:23:20.689515509 +0000 +++ actual 2023-03-01 18:23:20.679515420 +0000

@@ -1,4 +1,4 @@
-1:  4de457d = 1:  35b9b25 s/5/A/
-2:  fccce22 = 2:  de345ab s/4/A/
-3:  147e64e = 3:  9af6654 s/11/B/
-4:  a63e992 = 4:  2901f77 s/12/B/
+1:  4de457d2c0d218f48d66f45f9b30f3aa62562105 = 1:  35b9b25f76d404d09a23e6c8efa96c3ce19e19aa s/5/A/
+2:  fccce22f8c95220a7283f047ecc6f042a54ad902 = 2:  de345ab3de2b56a1e208e46197bb77829a6e1f3a s/4/A/
+3:  147e64ef5365f843f378dcfd60c4b8115146a35a = 3:  9af6654000a6c3235196f874c6fa58c970fcf233 s/11/B/
+4:  a63e992599e14e34a5664fe3f213fa8ad8977fe1 = 4:  2901f773f3f322646e189b37ffe99a47ad6d456a s/12/B/
error: last command exited with $?=1
not ok 2 - simple A..B A..C (unmodified)

I can share the full build log if it will help, though it's
rather large.  It includes the test-results and trash
directory, which can be extracted.  I've found that helpful
when I run into failures only on architectures for which I
don't have easy access.

Without bistecting, I'm guessing this is likely to be
related to this change?

>  * sscanf(3) used in "git symbolic-ref --short" implementation found
>    to be not working reliably on macOS in UTF-8 locales.  Rewrite the
>    code to avoid sscanf() altogether to work it around.
>    (merge 613bef56b8 jk/shorten-unambiguous-ref-wo-sscanf later to maint).

If it's not somewhat obvious to others, I can try to dig
more out of the build output later today.

-- 
Todd