Zen

Translation

Perform some RPM header checks. First, check that the Vendor contains the expected string as defined in the configuration file. Second, check that the build host is in the expected subdomain as defined in the configuration file. Third, check the Summary string for any unprofessional words. Fourth, check the Description for any unprofessional words. Lastly, if there is a before build specified, check for differences between the before and after build values of the previous RPM header values and report them.
Выполните некоторые проверки заголовка RPM. Сначала убедитесь, что поставщик содержит ожидаемую строку, определенную в файле конфигурации. Во-вторых, убедитесь, что хост сборки находится в ожидаемом поддомене, как определено в файле конфигурации. В-третьих, проверьте строку Summary на наличие непрофессиональных слов. В-четвертых, проверьте описание на наличие непрофессиональных слов. Наконец, если задано значение до сборки, проверьте различия между значениями до и после сборки значений предыдущих заголовков RPM и сообщите о них.
534/5110 · 511

Sign in to save translations.

English Russian Actions
Verify the string specified in the License tag of the RPM metadata describes permissible software licenses as defined by the license database. Also checks to see if the License tag contains any unprofessional words as defined in the configuration file.
Убедитесь, что строка, указанная в теге License метаданных RPM, описывает допустимые лицензии на программное обеспечение, определенные в базе данных лицензий. Также проверьте, содержит ли тег License какие-либо некорректные слова, определенные в файле конфигурации.
Check all binary RPMs in the build for any empty payloads. When comparing two builds, report new packages in the after build with empty payloads.
Проверьте все бинарные RPM в до и после сборки на наличие пустых данных. При сравнении двух сборок сообщайте о новых пакетах после сборки с пустыми данными.
Check all binary RPMs in the before and after builds for any empty payloads. Packages that lost payload data from the before build to the after build are reported.
Проверьте все двоичные RPM в сборках до и после на предмет пустых полезных данных. Сообщается о пакетах, которые потеряли данные между сборками.
Perform some RPM header checks. First, check that the Vendor contains the expected string as defined in the configuration file. Second, check that the build host is in the expected subdomain as defined in the configuration file. Third, check the Summary string for any unprofessional words. Fourth, check the Description for any unprofessional words. Lastly, if there is a before build specified, check for differences between the before and after build values of the previous RPM header values and report them.
Выполните некоторые проверки заголовка RPM. Сначала убедитесь, что поставщик содержит ожидаемую строку, определенную в файле конфигурации. Во-вторых, убедитесь, что хост сборки находится в ожидаемом поддомене, как определено в файле конфигурации. В-третьих, проверьте строку Summary на наличие непрофессиональных слов. В-четвертых, проверьте описание на наличие непрофессиональных слов. Наконец, если задано значение до сборки, проверьте различия между значениями до и после сборки значений предыдущих заголовков RPM и сообщите о них.
Perform some checks on man pages in the RPM payload. First, check that each man page is compressed. Second, check that each man page contains valid content. Lastly, check that each man page is installed to the correct path.
Выполните некоторые проверки на страницах руководства в полезной нагрузке RPM. Сначала убедитесь, что каждая страница справочника сжата. Во-вторых, убедитесь, что каждая справочная страница содержит валидный контент. Наконец, убедитесь, что путь установки каждой страницы man валидный.
Check that XML files included in the RPM payload are well-formed.
Убедитесь, что файлы XML, включенные в RPM загрузку, правильно сформированы.
Perform several checks on ELF files. First, check that ELF objects do not contain an executable stack. Second, check that ELF objects do not contain text relocations. When comparing builds, check that the ELF objects in the after build did not lose a PT_GNU_RELRO segment. When comparing builds and there is a list of forbidden library functions, make sure nothing uses them.
Выполните несколько проверок файлов ELF. Сначала убедитесь, что объекты ELF не содержат исполняемый стек. Во-вторых, убедитесь, что объекты ELF не содержат текстовых перемещений. При сравнении сборок убедитесь, что объекты ELF в после сборки не потеряли сегмент PT_GNU_RELRO. При сравнении сборок убедитесь, что объекты ELF в после сборки не потеряли -D_FORTIFY_SOURCE. Наконец, если есть список запрещенных библиотечных функций, убедитесь, что они не используются.
Perform syntax and file reference checks on *.desktop files. Syntax errors and invalid file references are reported as errors.
Выполните проверку синтаксиса и ссылок на файлы в файлах *.desktop. Синтаксические ошибки и неправильные ссылки на файлы сообщаются как ошибки.
Check that the 'Release' tag in the RPM spec file includes the %{?dist} directive.
Убедитесь, что тег 'Release' в файле спецификации RPM содержит %{?dist} директиву.
Ensure the spec file name conforms to the NAME.spec naming format.
Убедитесь, что имя файла спецификации соответствует формату имен NAME.spec.
Ensure compliance with modularity build and packaging policies (only valid for module builds, no-op otherwise).
Обеспечьте соответствия политикам сборки и упаковки модульности (действительны только для сборок модулей, в противном случае - нет).
Check minimum required Java bytecode version in class files, report bytecode version changes between builds, and report if bytecode versions are exceeded. The bytecode version is vendor specific to releases and defined in the configuration file.
Проверьте на минимальную требуемую версию байт-кода Java в файлах классов, сообщите об изменениях версии байт-кода между сборками и сообщите, превышены ли версии байт-кода. Версия байт-кода зависит от поставщика и определяется в файле конфигурации.
Report changed files from the before build to the after build. Certain file changes will raise additional warnings if the concern is more critical than just reporting changes (e.g., a suspected security impact). Any gzip, bzip2, or xz compressed files will have their uncompressed content compared only, which will allow changes through in the compression level used. Message catalog files (.mo) are unpacked and compared using diff(1). Public C and C++ header files are preprocessed and compared using diff(1). Any changes with diff output are included in the results.
Отчет об измененных файлах от до сборки до сборки. Определенные изменения файла вызовут дополнительные предупреждения, если проблема важнее, чем просто сообщение об изменениях (например, связанная с безопасностью). Любые сжатые файлы gzip, bzip2 или xz будут сравниваться только со своим несжатым содержимым, что позволит изменять используемый уровень сжатия. Файлы каталога сообщений (.mo) распаковываются и сравниваются с помощью diff(1). Публичные заголовочные файлы C и C ++ предварительно обрабатываются и сравниваются с использованием diff(1). Любые изменения с выводом diff включены в результаты.
Report files that have moved installation paths or across subpackages between builds. Files moved with a security path prefix generate special reporting in case a security review is required. Rebased packages report these findings at the INFO level while non-rebased packages report them at the VERIFY level or higher.
Сообщение о файлах, для которых были перемещены пути установки или между подпакетами между сборками. Файлы, перемещенные с префиксом пути безопасности, создают специальный отчет на случай, если потребуется проверка безопасности. Обновленные пакеты сообщают об этих результатах на уровне INFO, в то время как неперебазированные пакеты сообщают о них на уровне VERIFY или выше.
Report removed files from the before build to the after build. Shared libraries get additional reporting output as they may be unexpected dependency removals. Files removed with a security path prefix generate special reporting in case a security review is required. Source RPMs and debuginfo files are ignored by this inspection. Rebased packages report these findings at the INFO level while non-rebased packages report them at the VERIFY level or higher.
Сообщение об удаленных файлах из предыдущей сборки после сборки. Общие библиотеки получают дополнительный отчет, поскольку они могут быть неожиданными удалениями зависимостей. Файлы, удаленные с префиксом пути безопасности, попадут специальный отчет на случай, если потребуется проверка безопасности. Исходные RPM и файлы debuginfo игнорируются этой проверкой. Обновленные пакеты сообщают об этих результатах на уровне INFO, в то время как неперебазированные пакеты сообщают о них на уровне VERIFY или выше.
Report added files from the before build to the after build. Debuginfo files are ignored as are files that match the patterns defined in the configuration file. Files added to security paths generate special reporting in case a security review is required. New setuid and setgid files raise a security warning unless the file is in the fileinfo list. Rebased packages report these findings at the INFO level while non-rebased packages report them at the VERIFY level or higher.
Сообщение о добавленных файлах от предыдущей сборки до последующей. Файлы Debuginfo игнорируются, как и файлы, соответствующие шаблонам, определенным в файле конфигурации. Файлы, добавленные в пути безопасности, создают специальные отчеты на случай, если потребуется проверка безопасности. Новые файлы setuid и setgid вызывают предупреждение системы безопасности, если файл не находится в списке fileinfo. Обновленные пакеты сообщают об этих результатах на уровне INFO, в то время как неперебазированные пакеты сообщают о них на уровне VERIFY или выше.
Report Source archives defined in the RPM spec file changing content between the before and after build. If the source archives change and the package is on the rebaseable list, the change is reported as informational. Otherwise the change is reported as a rebase of the package and requires inspection.
Архивы источников отчетов, определенные в файле спецификации RPM, меняют содержимое между сборкой до и после сборки. Если исходные архивы изменяются и пакет находится в списке с возможностью переназначения, изменение отображается как информационное. В противном случае изменение регистрируется как перебазирование пакета и требует проверки.
Report files and directories owned by unexpected users and groups. Check to make sure executables are owned by the correct user and group. If a before and after build have been specified, also report ownership changes.
Файлы отчетов и каталоги, принадлежащие неожиданным пользователям и группам. Убедитесь, что исполняемые файлы принадлежат правильному пользователю и группе. Если таковые были указаны до и после сборки, также сообщите об изменениях владельца.
For all shell scripts in the build, perform a syntax check on it using the shell defined in its #! line (shell must also be listed in shell section of the configuration data). If the syntax check returns non-zero, report it to the user and return a combined stdout and stderr. If comparing two builds, perform the previous check but also report if a previously bad script is now passing the syntax check.
Для всех сценариев оболочки в сборке выполните проверку синтаксиса, используя оболочку, определенную в ее #! line (оболочка также должна быть указана в разделе оболочки данных конфигурации). Если проверка синтаксиса вернет ненулевое значение, сообщите об этом пользователю и верните объединенные stdout и stderr. При сравнении двух сборок выполните предыдущую проверку, но также сообщите, проходит ли проверка синтаксиса ранее некорректный сценарий.

Loading…

User avatar None

String updated in the repository
Perform some RPM header checks. First, check that the Vendor contains the expected string as defined in the configuration file. Second, check that the build host is in the expected subdomain as defined in the configuration file. Third, check the Summary string for any unprofessional words. Fourth, check the Description for any unprofessional words. Lastly, if there is a before build specified, check for differences between the before and after build values of the previous RPM header values and report them.
Выполните некоторые проверки заголовка RPM. Сначала убедитесь, что поставщик содержит ожидаемую строку, определенную в файле конфигурации. Во-вторых, убедитесь, что хост сборки находится в ожидаемом поддомене, как определено в файле конфигурации. В-третьих, проверьте строку Summary на наличие непрофессиональных слов. В-четвертых, проверьте описание на наличие непрофессиональных слов. Наконец, если задано значение до сборки, проверьте различия между значениями до и после сборки значений предыдущих заголовков RPM и сообщите о них.
a year ago
Browse all string changes

Things to check

Placeholders 1

The following format strings are missing: Description, Vendor

Reset

Glossary

English Russian
No related strings found in the glossary.

14709880 String information

Flags
placeholders:RPM:Vendor:Description:Summary
Source string location
include/inspect.h:1359
String age
a year ago
Last updated
a year ago
Source string age
a year ago
Translation file
ru_RU.po, string 4