Issue
Since Fedora32 (so Fedora 33 too) my libreoffice RPM Build wont run anymore. It seems to break when /usr/lib/rpm/redhat/brp-mangle-shebangs is called by jenkins. I modified brp-mangle-shebangs to get the specific file which breaks the build. Thats the output:
+ read shebang_line
+ orig_shebang='Denne utvidelsen blir en del av Calc, og tilbyr nye metoder for løsing til bruk i optimering av ikke-lineære programmeringsmodeller.'
+ '[' 'Denne utvidelsen blir en del av Calc, og tilbyr nye metoder for løsing til bruk i optimering av ikke-lineære programmeringsmodeller.' = 'Denne utvidelsen blir en del av Calc, og tilbyr nye metoder for løsing til bruk i optimering av ikke-lineære programmeringsmodeller.' ']'
+ echo '*** WARNING: ./opt/loffice/libreoffice6.4/share/extensions/nlpsolver/description-nb.txt is executable but has no shebang, removing executable bit'
*** WARNING: ./opt/loffice/libreoffice6.4/share/extensions/nlpsolver/description-nb.txt is executable but has no shebang, removing executable bit
++ stat -c %y ./opt/loffice/libreoffice6.4/share/extensions/nlpsolver/description-nb.txt
+ ts='2021-01-28 16:22:30.267085614 +0100'
+ chmod -x ./opt/loffice/libreoffice6.4/share/extensions/nlpsolver/description-nb.txt
+ touch -d '2021-01-28 16:22:30.267085614 +0100' /opt/loffice/libreoffice6.4/share/extensions/nlpsolver/description-nb.txt
+ continue
+ IFS=
+ read -r line
+ f=./opt/loffice/libreoffice6.4/share/extensions/package.txt
+ path=/opt/loffice/libreoffice6.4/share/extensions/package.txt
+ '[' -n '' ']'
+ '[' -n '' ']'
+ read shebang_line
Fehler: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.R2w2T5 (%install)
This script seems to try to read shebangs from textfiles and then breaks? I honestly have no clue what is going on since jenkins wont tell me exactly where the error occurs. So i event dont know if im right with my assumption. All i can tell is, that this exact build works on the fedora31 buildserver.
Do you guys have any hints on why this build could be braking or how to debug it any further? Im pretty lost right now to be honest.
Solution
A long story, but it appears that the "root-cause" is a "feature" in the GNU install command.
Normally (on linux/unix), when a file is created is gets its file mode (permissions) via the umask. Moreover the execute x permission is additionally stripped.
However when you "install" a file, the install command is agnostic to whether the file either data or script, and refuses to strip the x. (It appears that install always uses mode = 0755 (a.k.a. "-rwxr-xr-x").
Examples:
umask=0027
600 -rw------- mod_0700_data # from: chmod go-rwx mod_0700_data
700 -rwx------ mod_0700_xowner # from: chmod 0700 mod_0700_xowner
777 -rwxrwxrwx mod_0777_xscript # from: chmod a+rwx mod_0777_xscript
640 -rw-r----- mod_touch # from: touch mod_touch
600 -rw------- mod_cp_data # from: cp mod_0700_data mod_cp_data
600 -rw------- mod_cp_xowner # from: cp mod_0700_xowner mod_cp_xowner
750 -rwxr-x--- mod_cp_xscript # from: cp mod_0777_xscript mod_cp_xscript
600 -rw------- mod_cp_-p_data # from: cp -p mod_0700_data mod_cp_-p_data
700 -rwx------ mod_cp_-p_xowner # from: cp -p mod_0700_xowner mod_cp_-p_xowner
777 -rwxrwxrwx mod_cp_-p_xscript # from: cp -p mod_0777_xscript mod_cp_-p_xscript
755 -rwxr-xr-x mod_install_data # from: install mod_0700_data mod_install_data
755 -rwxr-xr-x mod_install_xowner # from: install mod_0700_xowner mod_install_xowner
755 -rwxr-xr-x mod_install_xscript # from: install mod_0777_xscript mod_install_xscript
600 -rw------- mod_install_data+mode # from: install --mode =600 mod_0700_data mod_install_data+mode
700 -rwx------ mod_install_xowner+mode # from: install --mode =700 mod_0700_xowner mod_install_xowner+mode
777 -rwxrwxrwx mod_install_xscript+mode # from: install --mode =777 mod_0777_xscript mod_install_xscript+mode
i.e. you need to manually include the --mode option on every install , especially if you need to preserve the file's x execute bit status (eg. on vs. off).
Commentary: I suspect that /usr/lib/rpm/redhat/brp-mangle-shebangs was added to RHEL/Fedora to reduce the incidences of .RPMs "accidentally" creating x execute-mode files by mistake. (Hint: It would be a nice addition if install would only spread/set the x mode where the original file had an x bit in place originally. But I hate to imagine how many installs this change would then break!)
Note that libreoffice are not the only .rpm to be "warned" by RHEL/Fedora. ZFS ... "These warnings are caused when we (incorrectly)
include data & config files in the_SCRIPTS automake lines"
Looking a bit further afield, I am curious if automake is unaware of install's agnostic/indifferent default file mode behavior. Mainly because zfs source code also appears to have added numerous patches to repair their Makefile.ac's variables, especially: dist_pkgdata_SCRIPTS and dist_pkgdata_DATA. eg.
pkgdatadir = $(datadir)/@PACKAGE@/test-runner/include
dist_pkgdata_SCRIPTS = \
logapi.shlib
dist_pkgdata_DATA = \
stf.shlib
Update:
RHEL8 has a binary /usr/bin/install, probably a "compiled" version of this shell script: install-sh ... The offending line is #444, where the umask is overwritten:
# 443: Copy the file name to the temp name.
(umask $cp_umask && $doit_exec $cpprog "$src" "$dsttmp") &&
Very mature code ... "Copyright (C) 1994 X Consortium" ... So I'm sure there is a good reason for overriding the umask.
Odd that the binary version of install defaults to always creating files with the eXecute-bit set.
Answered By - NevilleDNZ
Answer Checked By - Timothy Miller (JavaFixing Admin)
