Random failures in sysa help2man 1.36.4

[nanonyme]

help2man-1.36.4: beginning build using script help2man-1.36.4.sh
help2man-1.36.4: getting sources.
help2man-1.36.4.tar.gz: OK
help2man-1.36.4: unpacking source.
help2man-1.36.4: preparing source.
Applying patch: /sysa/help2man-1.36.4/patches/date.patch
patching file help2man.PL
help2man-1.36.4: configuring source.
checking for perl... perl
checking for a BSD-compatible install... /usr/bin/install -c
checking for makeinfo... :
checking for install-info... :
configure: creating ./config.status
config.status: creating Makefile
help2man-1.36.4: compiling source.
perl help2man.PL
Extracting help2man (with variable substitutions)
make help2man
make[1]: Entering directory `/sysa/help2man-1.36.4/build/help2man-1.36.4'
make[1]: `help2man' is up to date.
make[1]: Leaving directory `/sysa/help2man-1.36.4/build/help2man-1.36.4'
./help2man --include=./help2man.h2m \
    --output=help2man.1 ./help2man
make: ./x86/bin/kaem: Shell program not found
make: *** [help2man.1] Error 127
Subprocess error 2

[nanonyme]

@doraskayo pointed out it's unexpected it's calling kaem this late in sysa.

[stikonas]

Hmm, never seen anything like that...

It indeed looks like make is somehow calling kaem... The string "./x86/bin/kaem" appears to be coming from stage0-posix sysa/kaem.x86:./x86/bin/kaem --verbose --strict --file ./x86/kaem.run i.e. when kaem is built early in stage0-posix and is first invoked.

Perhaps perl is buggy and somehow read stuff from the wrong file? We know at the very least that perl is somewhat buggy:

    # fix a broken shebang
    chmod +w help2man
    tail -n +6 help2man > help2man.tmp
    echo "#!${PREFIX}/bin/perl" > help2man
    cat help2man.tmp >> help2man
    rm help2man.tmp

Perhaps whatever causes shebang to be broken has a small chance of causing this.

[doraskayo]

It seems that this can be caused by having a wrong value in the SHELL environment variable.

Do we expect bash to override it in this context?

I saw that kaem sets it to point at itself, and sysa's run.sh is originally called from kaem context. See: https://github.com/oriansj/mescc-tools/commit/9f25544301798ef60bdf5e714fab09db1d4d4403

[rick-masters]

This problem occurs because make is running the following rule (from Makefile.in):

$(target).1: $(srcdir)/$(target).PL $(srcdir)/$(target).h2m
        $(MAKE) $(target)
        ./$(target) --include=$(srcdir)/$(target).h2m \
            --output=$@ ./$(target)

Note that $(target) is set to help2man.

This rule is triggered because help2man.PL has a more recent time than help2man.1. This can happen, rarely, when tar extracts help2man.PL after help2man.1 and the current time (in seconds precision) changes between extracting those two files. Only in this case will make consider help2man.PL to be more recent than help2man.1.

So, make builds help2man (which is done with help2man.PL) and then runs help2man to generate help2man.1.

But, help2man cannot be executed because it has an incorrect shebang line at the top. This is a known problem for which live-bootstrap already has a workaround for - a workaround is in the build shell script help2man-1.36.sh which fixes the shebang (see below).

Note that if the shebang were not broken, this issue would not have occurred because the running help2man would have worked.

So, it's worth exploring why the shebang is wrong in the first place. The reason for this is that the perl script help2man.PL that creates help2man is not operating correctly. It depends on the variables $Config{startperl}, $Config{shebang}, and $Config{perlpath} but those variables are not set. The first line of shebang is written using $Config{startperl} and the second line uses $Config{perlpath}. They are not set, which results in this malformed header in help2man:

 -w
eval 'exec  -wS $0 ${1+"$@"}'
    if $running_under_some_shell;

It should probably look something like this:

#!/usr/bin/perl -w
eval 'exec /usr/bin/perl -wS $0 ${1+"$@"}'
    if $running_under_some_shell;

Note, this article talks about setting those variables like this when configuring the perl build:

./Configure -des -Dstartperl='#!/my/shebang'

I looked at the perl 5.6.2 build script in live-bootstrap and it was not obvious how to do this.

A simple solution for me was changing the help2man-1.36.4.sh compile section to just avoid running help2man until the shebang is fixed:

src_compile() {
    # Ensure man page is not rebuilt which avoids broken shebang (see below)
    touch help2man.1
    make MAKEINFO=true

    # fix a broken shebang
    chmod +w help2man
    tail -n +6 help2man > help2man.tmp
    echo "#!${PREFIX}/bin/perl" > help2man
    cat help2man.tmp >> help2man
    rm help2man.tmp
}

[rick-masters]

The right way to set the perl $Config variables is to add the variables to sysa/perl-5.6.2/files/config.sh. I will have a PR forthcoming that fixes perl and removes the help2man shebang workaround, and new checksums.

[rick-masters]

Unfortunately, this problem is not resolved. While the failure building the man page has been fixed, the timing problem while extracting the files from tar still exists. So, help2man.1 can still be rebuilt and with the previous PR this now succeeds. (Fixing perl was a good thing to be sure). Yay. However, the successful man page rebuild causes the checksum to be different for the resulting package and so the build fails anyway.

The forthcoming PR avoids the timing problem in the way originally suggested.