Пожалуйста, ознакомьтесь с предыдущими документами.
git show
, чтобы сохранить информацию об авторе.<constraints>
<sandbox>qemu</sandbox>
</constraints>
``` **Что делать, если пакет всегда отображается как заблокированный и не может быть построен?**
Отредактируйте страницу `Meta` проекта, в котором находится пакет, добавив в строку `repository name=` следующие параметры: `rebuild="local" block="never" linkedbuild="off"`.
Meta
?
<publish> <enable|disable/> </publish>
позволяет контролировать публикацию пакета на сервере загрузки, <build> <enable|disable/> </build>
позволяет контролировать построение пакета. Страница Meta
проекта контролирует все пакеты в проекте, а страница Meta
пакета контролирует только этот пакет. В строке repository name=
страницы Meta
проекта есть параметр path project=
, который определяет зависимости проекта, то есть откуда проект берёт зависимости для построения.Project Config
проекта?
Она имеет большое значение и используется для более продвинутых настроек. Когда вы станете более опытным, вы сможете изучить её, [документация](https://openbuildservice.org/help/manuals/obs-user-guide/cha. obs. prjconfig. html).Project Config
проекта, добавив следующий код для решения проблемы "ложного застревания" на этапе %build, а на этапе %check используйте __spec_check_pre:
Макросы: %__spec_build_pre %{___build_pre} \ case %{name} in \ имя_пакета) \ function keepalive() { while true; do sleep 28000; date; done } \ keepalive & ;; \ esac :Макросы
Repositories
построенного пакета, выбрав опцию Use for Build Flag
. Это значение по умолчанию. Затем добавьте проект, содержащий успешный пакет, в зависимости целевого проекта и расположите его перед существующими зависимостями, как описано выше в разделе о метке Meta
; если успешный пакет и целевой пакет находятся в одном проекте, то эта операция не требуется.Repositories
пакета и установите флажок Publish Flag
.osc build
инициализирует эту среду и выполняет сборку пакетов внутри неё.osc log|less
в директории, где был вынесен пакет. Чтобы избежать удаления логов последующими сборками, сохраните их отдельно.error: Bad exit status from /var/tmp/rpm-tmp.kp0vhP (%build)
?
Это означает, что произошла ошибка при выполнении скрипта /var/tmp/rpm-tmp.kp0vhP в стадии %build процесса сборки. Процесс сборки состоит из отдельных стадий, таких как %prep, %build, %install, %check, каждый из которых имеет свой shell-скрипт, выполняющий все задачи данной стадии. Эти скрипты соответствуют описанию пакета в файле spec. Просмотр этого скрипта позволяет понять, какие условия были установлены, как раскрывались макросы и какие конкретные команды были выполнены.chroot /var/tmp/build-root/xx_проект
mount --bind /proc /var/tmp/build-root/xx_проект/proc
перед вводом в среду сборки. Не забудьте отмонтировать /proc после выхода из среды сборки.Как повторно выполнить команду, которая вызвала ошибку, в среде сборки?
Метод 1: Найдите и повторно выполните команду, вызвавшую ошибку. Из-за настроек среды, эта команда может не выполниться корректно.
Метод 2: Выполните соответствующий скрипт /var/tmp/rpm-tmp. xxx. Вы можете предварительно отредактировать этот скрипт. Это более надежный метод.
Метод 3: Используйте команду osc build --stage=xx
для повторного выполнения определенной стадии сборки. Подробности см. в справке по osc
и rpmbuild
. Повторное выполнение отдельных стадий не всегда возможно, например, %check, из-за отсутствия файлов, созданных предыдущими стадиями.osc build --noinit
.rm -rf /var/tmp/{build-root,osbuild-packagecache}
.chroot
и установить пакеты с помощью rpm -i
. Это более сложный процесс, и при сборке необходимо добавить параметр --noinit
, чтобы предотвратить автоматическое удаление вручную установленных пакетов.31.Какой обычно используется подход для исправления пакетов? - Выберите знакомый вам язык программирования и пакет - Анализируйте логи - Устраняйте проблемы с зависимостями - Сравнивайте успешные логи для x86_64 и aarch64 - Проверяйте обновления пакета в его исходном репозитории - Изучайте решения других пользователей - Ищите информацию в интернете - Отладьте исходный код 32. Как обрабатывать ошибки, вызванные настройками среды, производительностью или временем ожидания? Не нужно исправлять пакет, достаточно уведомить maintainer. 33. Можно ли просто обновить пакет, а не исправлять его? Да, можно. Проект OBS Factory:RISC-V предназначен для ротационного обновления пакетов; ветка roll в промежуточном репозитории используется для хранения обновлений исходного кода, которые можно указать при создании запроса на изменение (PR) в этот репозиторий. В PR, помимо стандартных требований, необходимо сделать краткий анализ изменений API для оценки возможных проблем совместимости. 34. Можно ли добавить новый пакет? Да, можно, но потребуется причина. Для этого можно создать issue или обратиться к SIG. 35. Можно ли подать заявку на статус maintainer, как в других дистрибутивах? Добро пожаловать! Ожидается, что вы будете поддерживать выбранный пакет в хорошем состоянии. 36. Какие еще способы участия существуют? Все, что способствует развитию openEuler RISC-V, допустимо, например: улучшение документации, предоставление отчетов о системе, разработка приложений и т. д.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )