Re: git can not be built for s390x since update to git-2.38.0

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Nov 22 2022, Eric Sunshine wrote:

> On Tue, Nov 22, 2022 at 9:41 AM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> On Mon, Nov 21 2022, Eric Sunshine wrote:
>> > The empty "chainlinttmp/tests" file also sounds suspicious. If you
>> > haven't already done so, I would recommend following the advice in [1]
>> > and running each command individually which Makefile would have run;
>> > this might allow you to isolate the problematic command or shell
>> > construct if such exists.
>>
>> I can also reproduce this on gcc202. It's the same issue with ending up
>> with an empty "tests" file.
>
> Were you able to determine why the "tests" file is empty? The creation
> loop is simple enough:
>
>     for i in $(CHAINLINTTESTS); do \
>         echo "test_expect_success '$$i' '" && \
>         sed -e '/^# LINT: /d' chainlint/$$i.test && \
>         echo "'"; \
>     done >'$(CHAINLINTTMP_SQ)'/tests && \
>
> and the file is never changed after that (or shouldn't be).

Sorry. I meant that the result of running *against* the non-empty test
file is empty. I.e.:

	$ perl chainlint.pl chainlinttmp/tests ; echo $?
	0

Anyway, the "fix" here can also be:

	 $jobs = ncores() if $jobs < 1;
	+$jobs = 1 if $jobs < 1;

I.e. it's another case of bad /proc/cpuinfo parsing.

On that platform, this also works:
	
	diff --git a/t/chainlint.pl b/t/chainlint.pl
	index 976db4b8a0..e6bc476fc5 100755
	--- a/t/chainlint.pl
	+++ b/t/chainlint.pl
	@@ -656,7 +656,7 @@ sub ncores {
	        # Windows
	        return $ENV{NUMBER_OF_PROCESSORS} if exists($ENV{NUMBER_OF_PROCESSORS});
	        # Linux / MSYS2 / Cygwin / WSL
	-       do { local @ARGV='/proc/cpuinfo'; return scalar(grep(/^processor\s*:/, <>)); } if -r '/proc/cpuinfo';
	+       do { local @ARGV='/proc/cpuinfo'; return scalar(grep(/^(?:CPU\d+|processor\s*):/, <>)); } if -r '/proc/cpuinfo';
	        # macOS & BSD
	        return qx/sysctl -n hw.ncpu/ if $^O =~ /(?:^darwin$|bsd)/;
	        return 1;

But a generic guard against parse failure seems prudent.

>>         avar@gcc202:/run/user/1632/git/t$ uname -a
>>         Linux gcc202 6.0.0-4-sparc64-smp #1 SMP Debian 6.0.8-1 (2022-11-11) sparc64 GNU/Linux
>>         avar@gcc202:/run/user/1632/git/t$ lsb_release -a
>>         No LSB modules are available.
>>         Distributor ID: Debian
>>         Description:    Debian GNU/Linux bookworm/sid
>>         Release:        n/a
>>         Codename:       bookworm
>
> This is one of the compile-machines to which you have access?

Yes, and you can get access to it too. The GCC farm is open for free
software development, you only need to send in an E-Mail request, ssh
key etc.

>> The change at the tip of
>> https://lore.kernel.org/git/221122.86cz9fbyln.gmgdl@evledraar.gmail.com/
>> fixes it for me, i.e. getting rid of the perl threads stuff...
>
> I'm confused. How does a change to chainlint.pl -- which only reads
> the "tests" file -- fix the empty "tests" file?

It doesn't, sorry, see above.