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

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

[Sarah Julia Kriesch]

I am one of the zsystems Maintainers (s390x architecture) at openSUSE 
and git can not be built any more since the update from 2.37.3 to 
2.38.0, and with 2.38.1 afterwards. We have tried to debug it.

There is no real test error output, but we can identify, that it is 
happening in the test part with check-chainlint.

[  386s] + ./.make -j2 test
[  386s] /usr/bin/make -C git-gui  gitexecdir='/usr/libexec/git' all
[  387s] /usr/bin/make -C gitk-git  all
[  387s] /usr/bin/make -C templates  SHELL_PATH='/bin/sh' 
PERL_PATH='/usr/bin/perl'
[  387s] make[1]: Entering directory 
'/home/abuild/rpmbuild/BUILD/git-2.38.1/templates'
[  387s] : no custom templates yet
[  387s] make[1]: Leaving directory 
'/home/abuild/rpmbuild/BUILD/git-2.38.1/templates'
[  387s] /usr/bin/make -C t/ all
[  387s] make[1]: Entering directory 
'/home/abuild/rpmbuild/BUILD/git-2.38.1/t'
[  387s] rm -f -r 'test-results'
[  387s] make[1]: Leaving directory 
'/home/abuild/rpmbuild/BUILD/git-2.38.1/t'
[  387s] make[1]: Entering directory 
'/home/abuild/rpmbuild/BUILD/git-2.38.1/t'
[  387s] make[1]: *** [Makefile:83: check-chainlint] Error 1
[  387s] make[1]: Leaving directory 
'/home/abuild/rpmbuild/BUILD/git-2.38.1/t'
[  387s] make[1]: *** Waiting for unfinished jobs....
[  388s] make: *** [Makefile:3075: test] Error 2
[  388s] error: Bad exit status from /var/tmp/rpm-tmp.ztqAAp (%check)
[  388s]

We figured out, that the perl script have been changed there in the last 
month.
I have to give the hint, that all versions of openSUSE for s390x are 
affected by this build failure. Builds are working for the other 
architectures.

How can we fix this issue?

-- 
Sarah Julia Kriesch
openSUSE

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

[Martin Ågren]

Hi Sarah,

On Tue, 1 Nov 2022 at 19:38, Sarah Julia Kriesch
<sarah.kriesch@opensuse.org> wrote:
>
> I am one of the zsystems Maintainers (s390x architecture) at openSUSE
> and git can not be built any more since the update from 2.37.3 to
> 2.38.0, and with 2.38.1 afterwards. We have tried to debug it.
>
> There is no real test error output, but we can identify, that it is
> happening in the test part with check-chainlint.

> [  387s] make[1]: *** [Makefile:83: check-chainlint] Error 1
> [  387s] make[1]: Leaving directory
> '/home/abuild/rpmbuild/BUILD/git-2.38.1/t'
> [  387s] make[1]: *** Waiting for unfinished jobs....
> [  388s] make: *** [Makefile:3075: test] Error 2
> [  388s] error: Bad exit status from /var/tmp/rpm-tmp.ztqAAp (%check)

> How can we fix this issue?

You can disable this feature by setting the GIT_TEST_CHAIN_LINT
environment variable to "0". That should hopefully allow you to run the
tests successfully.

That shouldn't risk you anything, like reduce test coverage or similar.
That the tests are chainlint-ok (roughly speaking, that they are written
the way the Git project likes its tests) has already been established by
many others at this point.

I'm cc-ing the resident chainlint expert.

Martin

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

[Taylor Blau]

On Tue, Nov 01, 2022 at 08:05:36PM +0100, Martin Ågren wrote:
> > How can we fix this issue?
>
> You can disable this feature by setting the GIT_TEST_CHAIN_LINT
> environment variable to "0". That should hopefully allow you to run the
> tests successfully.

Indeed. It would be nice to get some more helpful output from the
chainlint machinery when whatever is happening here happens.

I've never not had chainlint output when I was expecting it (and, I
often get chainlint output when I'm *not* expecting any ;-)), so I
wonder what is going on here.

Thanks,
Taylor

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

[Martin Ågren]

On Tue, 1 Nov 2022 at 20:05, Martin Ågren <martin.agren@gmail.com> wrote:
>
> Hi Sarah,
>
> On Tue, 1 Nov 2022 at 19:38, Sarah Julia Kriesch
> <sarah.kriesch@opensuse.org> wrote:
> >
> > I am one of the zsystems Maintainers (s390x architecture) at openSUSE
> > and git can not be built any more since the update from 2.37.3 to
> > 2.38.0, and with 2.38.1 afterwards. We have tried to debug it.
> >
> > There is no real test error output, but we can identify, that it is
> > happening in the test part with check-chainlint.
>
> > [  387s] make[1]: *** [Makefile:83: check-chainlint] Error 1
> > [  387s] make[1]: Leaving directory
> > '/home/abuild/rpmbuild/BUILD/git-2.38.1/t'
> > [  387s] make[1]: *** Waiting for unfinished jobs....
> > [  388s] make: *** [Makefile:3075: test] Error 2
> > [  388s] error: Bad exit status from /var/tmp/rpm-tmp.ztqAAp (%check)
>
> > How can we fix this issue?
>
> You can disable this feature by setting the GIT_TEST_CHAIN_LINT
> environment variable to "0". That should hopefully allow you to run the
> tests successfully.
>
> That shouldn't risk you anything, like reduce test coverage or similar.
> That the tests are chainlint-ok (roughly speaking, that they are written
> the way the Git project likes its tests) has already been established by
> many others at this point.

On further reading, it appears this error happens in the
"check-chainlint" target without even checking this environment variable
(that happens elsewhere). I doubt my original suggestion will be a
complete workaround.

One approach might be to patch the "check-chainlint" target into a
no-op, possibly combined with turning off the chainlinting as I
mentioned above. My makefile-foo is unfortunately not sufficiently
advanced to immediately spot what might be going on here.

At any rate, all of the above is just about working around the issue. As
for a proper fix, let's hope someone like Eric can chime in.

Martin

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

[Eric Sunshine]

On Tue, Nov 1, 2022 at 3:41 PM Martin Ågren <martin.agren@gmail.com> wrote:
> On Tue, 1 Nov 2022 at 20:05, Martin Ågren <martin.agren@gmail.com> wrote:
> > > There is no real test error output, but we can identify, that it is
> > > happening in the test part with check-chainlint.
> >
> > > [  387s] make[1]: *** [Makefile:83: check-chainlint] Error 1
>
> On further reading, it appears this error happens in the
> "check-chainlint" target without even checking this environment variable
> (that happens elsewhere). I doubt my original suggestion will be a
> complete workaround.
>
> One approach might be to patch the "check-chainlint" target into a
> no-op, possibly combined with turning off the chainlinting as I
> mentioned above. My makefile-foo is unfortunately not sufficiently
> advanced to immediately spot what might be going on here.
>
> At any rate, all of the above is just about working around the issue. As
> for a proper fix, let's hope someone like Eric can chime in.

Makefile-foo or not, there isn't much to go on here since the `make`
output doesn't show the actual problem. Squinting at the
`check-chainlint` target in "t/Makefile", I wonder if the problem is
with the line-splicing and missing command termination; that is, it
could just be a shell syntax error which is picked up by more strict
shells such as `dash`. In particular, in this hunk of code:

    { \
        echo "# chainlint: $(CHAINLINTTMP_SQ)/tests" && \
        for i in $(CHAINLINTTESTS); do \
            echo "# chainlint: $$i" && \
            sed -e '/^[   ]*$$/d' chainlint/$$i.expect; \
        done \
    } >'$(CHAINLINTTMP_SQ)'/expect && \

if you add a semicolon after `done` like this:

    done; \

does that fix the problem?

If not, then you may want to remove the "@" from the "@mkdir -p ..."
in the body of the `check-chainlint` rule in t/Makefile so that `make`
will print out the actual command(s) it is running, and then invoke
the target manually with `make -C t check-chainlint`. With the actual
commands visible, copy/paste in the terminal to run each command
individually and check the exit status $? after each command
invocation to find which, if any, is failing.

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

[Todd Zullinger]

Sarah Julia Kriesch wrote:
> I am one of the zsystems Maintainers (s390x architecture) at openSUSE and
> git can not be built any more since the update from 2.37.3 to 2.38.0, and
> with 2.38.1 afterwards. We have tried to debug it.

I don't know if it's of much help, but for what it's worth
2.38.0 and 2.38.1 been built in Fedora for s390x without
issue.  Build logs and artifacts for 2.38.1 can be found
here:

    https://koji.fedoraproject.org/koji/buildinfo?buildID=2077983

-- 
Todd

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

[Sarah Julia Kriesch]

 > Gesendet: Mittwoch, 02. November 2022 um 19:49 Uhr
 > Von: "Todd Zullinger" <tmz@pobox.com>
 > An: "Sarah Julia Kriesch" <sarah.kriesch@opensuse.org>
 > Cc: git@vger.kernel.org, andreas.stieger@gmx.de
 > Betreff: Re: git can not be built for s390x since update to git-2.38.0
 >
 > Sarah Julia Kriesch wrote:
 > > I am one of the zsystems Maintainers (s390x architecture) at 
openSUSE and
 > > git can not be built any more since the update from 2.37.3 to 
2.38.0, and
 > > with 2.38.1 afterwards. We have tried to debug it.
 >
 > I don't know if it's of much help, but for what it's worth
 > 2.38.0 and 2.38.1 been built in Fedora for s390x without
 > issue.  Build logs and artifacts for 2.38.1 can be found
 > here:
 >
 >     https://koji.fedoraproject.org/koji/buildinfo?buildID=2077983
 >
Thank you for the hint, that it is working for Fedora!
I have compared your spec file with ours and found, that you have got a 
BuildRequires for jgit only for s390x.

That has solved the problem. Is there any special reason, that s390x 
needs jgit for git builds?

Best regards,
Sarah
 > --
 > Todd
 >
-- 
Sarah Julia Kriesch
openSUSE

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

[Sarah Julia Kriesch]

It seems, that I did a mistake.
I thought, that I have tested it based on openSUSE Factory without 
excluding the tests.
It is failing continuously with adding the tests.

I have seen, that Fedora is excluding many tests additionnally for 
s390x. That is another difference in the spec file:
https://src.fedoraproject.org/rpms/git/blob/rawhide/f/git.spec

We have also identified this week, that chainlint.pl --stats says "0 
tests". That can explain the empty output.

~/rpmbuild/BUILD/git-2.38.1/t> /usr/bin/perl chainlint.pl --stats 
--emit-all chainlinttmp/tests
total: 0 workers, 0 scripts, 0 tests, 0 errors, 0.01s/0.01s (wall/user)

Best regards,
Sarah

Am 06.11.22 um 19:32 schrieb Sarah Julia Kriesch:
> > Gesendet: Mittwoch, 02. November 2022 um 19:49 Uhr
> > Von: "Todd Zullinger" <tmz@pobox.com>
> > An: "Sarah Julia Kriesch" <sarah.kriesch@opensuse.org>
> > Cc: git@vger.kernel.org, andreas.stieger@gmx.de
> > Betreff: Re: git can not be built for s390x since update to git-2.38.0
> >
> > Sarah Julia Kriesch wrote:
> > > I am one of the zsystems Maintainers (s390x architecture) at 
> openSUSE and
> > > git can not be built any more since the update from 2.37.3 to 
> 2.38.0, and
> > > with 2.38.1 afterwards. We have tried to debug it.
> >
> > I don't know if it's of much help, but for what it's worth
> > 2.38.0 and 2.38.1 been built in Fedora for s390x without
> > issue.  Build logs and artifacts for 2.38.1 can be found
> > here:
> >
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=2077983
> >
>
>
> Best regards,
> Sarah
> > --
> > Todd
> >

-- 
Sarah Julia Kriesch
openSUSE

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

[Eric Sunshine]

On Sun, Nov 6, 2022 at 2:18 PM Sarah Julia Kriesch
<sarah.kriesch@opensuse.org> wrote:
> We have also identified this week, that chainlint.pl --stats says "0
> tests". That can explain the empty output.
>
> ~/rpmbuild/BUILD/git-2.38.1/t> /usr/bin/perl chainlint.pl --stats
> --emit-all chainlinttmp/tests
> total: 0 workers, 0 scripts, 0 tests, 0 errors, 0.01s/0.01s (wall/user)

Was `--stats` added for debugging this issue, or is that somehow part
of your build process?

What is the content of the "chainlinttmp/tests" file? Is it empty?

It is quite curious that it reports 0 scripts. It should report 1
script even if chainlinttmp/file is empty. This might point a finger
at File::Glob::bsd_glob() returning an empty list for some reason, or
the problem could be a failure with Perl "ithreads".

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

[Todd Zullinger]

Sarah Julia Kriesch wrote:
> Thank you for the hint, that it is working for Fedora!
> I have compared your spec file with ours and found, that you have got a
> BuildRequires for jgit only for s390x.
> 
> That has solved the problem. Is there any special reason, that s390x needs
> jgit for git builds?

It's the opposite -- but the rpm conditional is quite long
and ugly though, so it's not as clear it could be.  It
excludes jgit for the test suite entirely on Fedora 35 and
newer¹.

On prior releases, it was excluded for x86 and s390x
architectures.  For s390x, the issue was that the jgit
daemon frequently hung on during builds and was painful to
try and debug without access to the architecture.  (For the
few tests which use jgit, it was simpler to just not test on
s390x).

¹ Every few releases (it seems), some part of the java
  dependency chain gets close to being dropped from the
  distribution.  After disabling and enalbing jgit several
  times, I've left it disabled, even though jgit has managed
  to remain in Fedora.  As much as I'd like to run the
  compatibilty tests, I don't like the "OMG, git will be
  removed from Fedora because some dependency of jgit is
  going away!" every couple of releases. :)

-- 
Todd

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

[Todd Zullinger]

Sarah Julia Kriesch wrote:
> I have seen, that Fedora is excluding many tests additionnally for s390x.

FWIW, those tests are only excluded when building on RHEL-8,
where they fail.  The same tests work fine on Fedora and
RHEL-9, so I have presumed that the issue is due to some
quirk(s) in RHEL-8 on s390x.

The Fedora git package supports building for RHEL largely as
a convenience.  I've got no vested interest in s390x, so I
disabled the tests on that OS/hardware combination rather
than trying to get access to it in order to debug.  :)

-- 
Todd

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

[Eric Sunshine]

[cc:+git; taking this back to the mailing list so others can weigh in]

On Wed, Nov 9, 2022 at 1:38 AM Sarah Julia Kriesch
<sarah.kriesch@opensuse.org> wrote:
>  > Gesendet: Sonntag, 06. November 2022 um 21:42 Uhr
>  > Von: "Eric Sunshine" <sunshine@sunshineco.com>
>  >
>  > On Sun, Nov 6, 2022 at 2:18 PM Sarah Julia Kriesch
>  > <sarah.kriesch@opensuse.org> wrote:
>  > > We have also identified this week, that chainlint.pl --stats says "0
>  > > tests". That can explain the empty output.
>  > >
>  > > ~/rpmbuild/BUILD/git-2.38.1/t> /usr/bin/perl chainlint.pl --stats
>  > > --emit-all chainlinttmp/tests
>  > > total: 0 workers, 0 scripts, 0 tests, 0 errors, 0.01s/0.01s (wall/user)
>  >
>  > Was `--stats` added for debugging this issue, or is that somehow part
>  > of your build process?
>  >
> Yes. We tried to debug that manually. Therefore, we have added the --stats.
>
>  > What is the content of the "chainlinttmp/tests" file? Is it empty?
>  >
> It is empty.
>
>  > It is quite curious that it reports 0 scripts. It should report 1
>  > script even if chainlinttmp/file is empty. This might point a finger
>  > at File::Glob::bsd_glob() returning an empty list for some reason, or
>  > the problem could be a failure with Perl "ithreads".

Do you happen to know if Perl is built with "ithreads" on your
platform, and if so, is "ithread" support working?

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.

[1]: https://lore.kernel.org/git/CAPig+cS184iKk6icG6ML=X+6Ng=fJyfic8izFyp1hT40cChm4g@mail.gmail.com/

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

[Ævar Arnfjörð Bjarmason]

On Mon, Nov 21 2022, Eric Sunshine wrote:

> [cc:+git; taking this back to the mailing list so others can weigh in]
>
> On Wed, Nov 9, 2022 at 1:38 AM Sarah Julia Kriesch
> <sarah.kriesch@opensuse.org> wrote:
>>  > Gesendet: Sonntag, 06. November 2022 um 21:42 Uhr
>>  > Von: "Eric Sunshine" <sunshine@sunshineco.com>
>>  >
>>  > On Sun, Nov 6, 2022 at 2:18 PM Sarah Julia Kriesch
>>  > <sarah.kriesch@opensuse.org> wrote:
>>  > > We have also identified this week, that chainlint.pl --stats says "0
>>  > > tests". That can explain the empty output.
>>  > >
>>  > > ~/rpmbuild/BUILD/git-2.38.1/t> /usr/bin/perl chainlint.pl --stats
>>  > > --emit-all chainlinttmp/tests
>>  > > total: 0 workers, 0 scripts, 0 tests, 0 errors, 0.01s/0.01s (wall/user)
>>  >
>>  > Was `--stats` added for debugging this issue, or is that somehow part
>>  > of your build process?
>>  >
>> Yes. We tried to debug that manually. Therefore, we have added the --stats.
>>
>>  > What is the content of the "chainlinttmp/tests" file? Is it empty?
>>  >
>> It is empty.
>>
>>  > It is quite curious that it reports 0 scripts. It should report 1
>>  > script even if chainlinttmp/file is empty. This might point a finger
>>  > at File::Glob::bsd_glob() returning an empty list for some reason, or
>>  > the problem could be a failure with Perl "ithreads".
>
> Do you happen to know if Perl is built with "ithreads" on your
> platform, and if so, is "ithread" support working?
>
> 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.
>
> [1]: https://lore.kernel.org/git/CAPig+cS184iKk6icG6ML=X+6Ng=fJyfic8izFyp1hT40cChm4g@mail.gmail.com/

I can also reproduce this on gcc202. It's the same issue with ending up
with an empty "tests" file.
	
	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

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...

That box is built with "useithreads=define", so it's not that it doesn't
support threading in general.

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

[Eric Sunshine]

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).

>         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?

> 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?

> That box is built with "useithreads=define", so it's not that it doesn't
> support threading in general.

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

[Eric Sunshine]

On Sun, Nov 6, 2022 at 2:18 PM Sarah Julia Kriesch
<sarah.kriesch@opensuse.org> wrote:
> I have seen, that Fedora is excluding many tests additionnally for
> s390x. That is another difference in the spec file:
> https://src.fedoraproject.org/rpms/git/blob/rawhide/f/git.spec
>
> We have also identified this week, that chainlint.pl --stats says "0
> tests". That can explain the empty output.
>
> ~/rpmbuild/BUILD/git-2.38.1/t> /usr/bin/perl chainlint.pl --stats
> --emit-all chainlinttmp/tests
> total: 0 workers, 0 scripts, 0 tests, 0 errors, 0.01s/0.01s (wall/user)

This sounds like the same issue as reported here[1].

[1]: https://lore.kernel.org/git/CANYNYEHXU8ivgAOa8EO5e9kOcbu6XF7rj+9EcSrbDQE+Rvyw_Q@mail.gmail.com/

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

[Ævar Arnfjörð Bjarmason]

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.

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

[Eric Sunshine]

On Tue, Nov 22, 2022 at 5:10 PM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> On that platform, this also works:
>         diff --git 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;

Thanks for digging into this. Your diagnosis matches the diagnosis in [1].

> 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.

Yup, I suggested the same in [2] as a would-be-nice-to-have-eventually
patch, although only as a fallback, not as a proper fix for the
reported problem since a real fix (as you have above and as in [1])
would return the correct core count.

[1]: https://lore.kernel.org/git/CANYNYEHXU8ivgAOa8EO5e9kOcbu6XF7rj+9EcSrbDQE+Rvyw_Q@mail.gmail.com/
[2]: https://lore.kernel.org/git/CAPig+cQ6_7wf6C280Rqi7mcTCiQp-n5GiLWTPazfcUcGFeZi0g@mail.gmail.com/