You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The install-sh file that python uses for autotools is horribly outdated. Last update was 16 years ago and it's being copied from automake's source code.
Updating it to modern standards could potentially fix issues for systems that use autotools, but it has the downside of having some backwards incompatible changes e.g. [0][1] (or you can search at their NEWS file [2]) which could break some previous applied workarounds.
As things stand, there is no bug at the moment and autotools just work so would a PR for updating install-sh to a newer version be considered?
Alright the static scanner warns in the case of a typo being made where the variable is actually used, but since the variable is indeed not used, that doesn't not make it a bug.
Can this be fixed as part of this issue, or do I need to open a new one?
Currently both AIX build-bots fail in the build phase with:
renaming build/scripts-3.8/pydoc3 to build/scripts-3.8/pydoc3.8
renaming build/scripts-3.8/idle3 to build/scripts-3.8/idle3.8
renaming build/scripts-3.8/2to3 to build/scripts-3.8/2to3-3.8
./install-sh -c -m 644 ./Tools/gdb/libpython.py python-gdb.py
./install-sh: not found
FYI: On my manual build server I have coreutils "install" installed, and it seems install-sh is not called in that case (which is why I never saw with manual builds)
FYI: There is also an issue (I hope side-effect) that pyexpat is not building while install-sh is not executing.
Activity
stratakis commentedon Sep 21, 2018
The install-sh file that python uses for autotools is horribly outdated. Last update was 16 years ago and it's being copied from automake's source code.
Updating it to modern standards could potentially fix issues for systems that use autotools, but it has the downside of having some backwards incompatible changes e.g. [0][1] (or you can search at their NEWS file [2]) which could break some previous applied workarounds.
As things stand, there is no bug at the moment and autotools just work so would a PR for updating install-sh to a newer version be considered?
[0] http://git.savannah.gnu.org/cgit/automake.git/commit/lib/install-sh?id=84a98180dd37a32891800fb9aafdf685bab74252
[1] http://git.savannah.gnu.org/cgit/automake.git/commit/lib/install-sh?id=bd44db1abdeea3643ba0387de24af7539da644e4
[2] http://git.savannah.gnu.org/cgit/automake.git/tree/NEWS
zware commentedon Sep 21, 2018
If there's no actual bug, it certainly does not need to be done on maintenance branches.
vstinner commentedon Oct 18, 2018
New changeset b7ad31c by Victor Stinner (stratakis) in branch 'master':
bpo-34765: Update the install-sh file (GH-9592)
b7ad31c
vstinner commentedon Oct 18, 2018
Thanks Charalampos Stratakis for the change!
I concur. Since install-sh has been updated in the master branch, I close the issue.
stratakis commentedon Oct 25, 2018
Adding to this, the reason I initially caught up with that, was due to a coverity scan.
More explicitly:
Error: SHELLCHECK_WARNING: [#def1]
/usr/lib64/python3.6/config-3.6dm-x86_64-linux-gnu/install-sh:63:1: warning: transform_arg appears unused. Verify it or export it. [SC2034]
# 61|
# 62| transformbasename=""
# 63|-> transform_arg=""
# 64| instcmd="$mvprog"
# 65| chmodcmd="$chmodprog 0755"
Error: SHELLCHECK_WARNING: [#def2]
/usr/lib64/python3.6/config-3.6m-x86_64-linux-gnu/install-sh:63:1: warning: transform_arg appears unused. Verify it or export it. [SC2034]
# 61|
# 62| transformbasename=""
# 63|-> transform_arg=""
# 64| instcmd="$mvprog"
# 65| chmodcmd="$chmodprog 0755"
So the transform_arg is unused, but I'm not well versed with autotools so I don't know the implications of that.
stratakis commentedon Oct 25, 2018
Generic reference on the issue:
https://github.com/koalaman/shellcheck/wiki/SC2034
stratakis commentedon Oct 25, 2018
Alright the static scanner warns in the case of a typo being made where the variable is actually used, but since the variable is indeed not used, that doesn't not make it a bug.
aixtools commentedon Oct 29, 2018
This is closed, however, since this was merged the AIX buildbots have failed. This is because the file mode bits lack the -x
root@x066:[/data/prj/python/git/cpython-master]find . -name install-sh -ls
148833829 16 -rw-r--r-- 1 root felt 15368 Oct 29 17:34 ./install-sh
Can this be fixed as part of this issue, or do I need to open a new one?
Currently both AIX build-bots fail in the build phase with:
renaming build/scripts-3.8/pydoc3 to build/scripts-3.8/pydoc3.8
renaming build/scripts-3.8/idle3 to build/scripts-3.8/idle3.8
renaming build/scripts-3.8/2to3 to build/scripts-3.8/2to3-3.8
./install-sh -c -m 644 ./Tools/gdb/libpython.py python-gdb.py
./install-sh: not found
aixtools commentedon Oct 29, 2018
FYI: On my manual build server I have coreutils "install" installed, and it seems install-sh is not called in that case (which is why I never saw with manual builds)
FYI: There is also an issue (I hope side-effect) that pyexpat is not building while install-sh is not executing.
I see the new PR - thx for the quick response!
vstinner commentedon Oct 29, 2018
New changeset ed271b2 by Victor Stinner in branch 'master':
bpo-34765: install-sh is executable (GH-10225)
ed271b2
vstinner commentedon Oct 29, 2018
I made install-sh executable again.
aixtools commentedon Oct 30, 2018
The AIX build-bots thank you. Back to "failed-test" status.
1721 ... failed test (failure)
1720 ... failed compile (failure)