Re: Bug#942674: Acknowledgement (git: FTBFS on big-endian targets - testsuite failure)
Control: tags -1 +patch
The attached patch fixes the problem for me. It comes from [1].
Thanks,
Adrian
> [1] https://www.spinics.net/lists/git/msg368292.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From: SZEDER =?utf-8?B?R8OhYm9y?= <szeder.dev@gmail.com>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Junio C Hamano <gitster@pobox.com>
Cc: Todd Zullinger <tmz@pobox.com>, git@vger.kernel.org
Subject: [PATCH] test-progress: fix test failures on big-endian systems
On Sat, Oct 19, 2019 at 11:38:40PM +0200, John Paul Adrian Glaubitz wrote:
> The testsuite is failing again on s390x and all other big-endian targets in
> Debian. For a full build log on s390x see [1].
Gah, my progress display fixes strike again...
I think the patch below should fix it, but I could only test it on
little-endian systems. Could you please confirm that it indeed works
on big-endian as well?
--- >8 ---
Subject: [PATCH] test-progress: fix test failures on big-endian systems
In 't0500-progress-display.sh' all tests running 'test-tool progress
--total=<N>' fail on big-endian systems, e.g. like this:
+ test-tool progress --total=3 Working hard
[...]
+ test_i18ncmp expect out
--- expect 2019-10-18 23:07:54.765523916 +0000
+++ out 2019-10-18 23:07:54.773523916 +0000
@@ -1,4 +1,2 @@
-Working hard: 33% (1/3)<CR>
-Working hard: 66% (2/3)<CR>
-Working hard: 100% (3/3)<CR>
-Working hard: 100% (3/3), done.
+Working hard: 0% (1/12884901888)<CR>
+Working hard: 0% (3/12884901888), done.
The reason for that bogus value is that '--total's parameter is parsed
via parse-options's OPT_INTEGER into a uint64_t variable [1], so the
two bits of 3 end up in the "wrong" bytes on big-endian systems
(12884901888 = 0x300000000).
Change the type of that variable from uint64_t to int, to match what
parse-options expects; in the tests of the progress output we won't
use values that don't fit into an int anyway.
[1] start_progress() expects the total number as an uint64_t, that's
why I chose the same type when declaring the variable holding the
value given on the command line.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
t/helper/test-progress.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/helper/test-progress.c b/t/helper/test-progress.c
index 4e9f7fafdf..42b96cb103 100644
--- a/t/helper/test-progress.c
+++ b/t/helper/test-progress.c
@@ -29,7 +29,7 @@ void progress_test_force_update(void);
int cmd__progress(int argc, const char **argv)
{
- uint64_t total = 0;
+ int total = 0;
const char *title;
struct strbuf line = STRBUF_INIT;
struct progress *progress;
--
2.24.0.rc0.472.ga6f06c86b4
Reply to: