Блог

Начиная с Fedora32 (и Fedora 33 тоже), моя сборка libreoffice RPM больше не будет запускаться. Кажется, что он прерывается, когда /usr/lib/rpm/redhat/brp-mangle-shebangs вызывается Дженкинсом. Я изменил brp-mangle-shebangs , чтобы получить конкретный файл, который прерывает сборку. Это результат:

   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)
 

Этот скрипт, похоже, пытается прочитать shebangs из текстовых файлов, а затем прерывается? Я, честно говоря, понятия не имею, что происходит, поскольку Дженкинс не скажет мне точно, где возникает ошибка. Так что я даже не знаю, прав ли я в своем предположении. Все, что я могу сказать, это то, что эта точная сборка работает на сервере fedora31 buildserver.

У вас, ребята, есть какие-либо намеки на то, почему эта сборка может тормозить или как ее отладить дальше? Честно говоря, я сейчас очень растерян.

Долгая история, но похоже, что «первопричиной» является «особенность» в команде установки GNU.

Обычно (включено linux/unix ), когда a file создается, is получает свой файл mode (разрешения) через umask . Кроме x того, разрешение на выполнение дополнительно удалено.

Однако, когда вы install открываете файл, install команда не зависит от того, является ли файл данными или сценарием, и отказывается удалять . x (Похоже, что install всегда используется mode = 0755 (он же «-rwxr-xr-x»).

Примеры:

 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
 

т. Е. Вам нужно вручную включить --mode опцию для каждого install , особенно если вам нужно сохранить x статус бита выполнения файла (например, вкл. или выкл.).

Комментарий: Я подозреваю, что /usr/lib/rpm/redhat/brp-mangle-shebangs был добавлен в RHEL/Fedora, чтобы уменьшить случаи RPM «случайного» создания файлов .s x в режиме выполнения по ошибке. (Подсказка: было бы хорошим дополнением, если install бы он только распространял / устанавливал x режим, в котором исходный файл x изначально имел бит. Но я не могу представить, сколько установок это изменение тогда сломается!)

Обратите внимание, что libreoffice .rpm RHEL / Fedora «предупреждает» не только об этом. ZFS … «Эти предупреждения возникают, когда мы (неправильно) включаем файлы данных и конфигурации в строки автоматического создания скриптов»

Заглядывая немного дальше, мне любопытно, не знает ли automake об install агностическом / индифферентном mode поведении файла по умолчанию. В основном потому zfs , что в исходный код, похоже, также добавлены многочисленные исправления для исправления их Makefile.ac переменные, особенно: dist_pkgdata_SCRIPTS и dist_pkgdata_DATA . например.

 pkgdatadir = $(datadir)/@PACKAGE@/test-runner/include
dist_pkgdata_SCRIPTS = 
    logapi.shlib

dist_pkgdata_DATA = 
    stf.shlib
 

Обновить:

RHEL8 имеет двоичный файл /usr/bin/install, вероятно, «скомпилированную» версию этого сценария оболочки: install-sh … Нарушающая строка # 444, где перезаписывается umask:

 # 443: Copy the file name to the temp name.
(umask $cp_umask amp;amp; $doit_exec $cpprog "$src" "$dsttmp") amp;amp; 
 

Очень зрелый код … «Консорциум авторских прав (C) 1994 X» … Поэтому я уверен, что есть веская причина для переопределения umask .

Странно, что двоичная версия по install умолчанию всегда создает файлы с eXecute-bit набором.