pkgbuilds

Гаруда Linux PKGBUILDs

Этот репозиторий содержит PKGBUILD для всех пакетов, которые в настоящее время находятся в репозитории garuda . Он работает на GitLab благодаря широкому использованию его CI и имеет зеркало GitHub только для чтения.

Объем этого репозитория

Здесь содержатся все наши собственные PKGBUILD. Исторически они были разделены на отдельные репозитории. Чтобы упростить поиск правильных PKGBUILD, а также ускорить внесение изменений, мы недавно объединили их в этот новый репозиторий. Включены PKGBUILD всех пакетов, включая их файлы конфигурации (это относится к меньшим файлам, таким как garuda-fish-config ). Содержимое некоторых из них, например пакетов garuda-*-settings , все еще можно найти в соответствующих репозиториях.

Обнаружили проблему?

Если возникнут какие-либо проблемы с упаковкой или подобные вещи, не стесняйтесь сообщать о них через наш раздел проблем. Вы можете нажать здесь, чтобы создать новый.

Как внести свой вклад?

Мы высоко ценим любой вклад! ? Для этого выполните следующие действия:

• Создайте вилку этого репозитория.
• Клонируйте свою вилку локально (краткое руководство по Git).
• Добавьте нужные изменения в PKGBUILD или исходный код.
• Убедитесь, что Shellcheck и shfmt сообщают об отсутствии проблем с измененными файлами.
  • Необходимые зависимости должны быть установлены заранее, например. через sudo pacman -S shfmt shellcheck
  • Запустите скрипт lint.sh через bash ./.ci/lint.sh и проверьте код.
  • Автоматически применять определенные предложения через bash ./ci/lint.sh apply
• Зафиксируйте, используя обычное сообщение о фиксации, и отправьте любые изменения обратно в свою вилку.
  • Приложение commitizen помогает создать подходящее сообщение о фиксации. Вы можете установить его через pip, поскольку в настоящее время в репозиториях Arch нет пакета: pip install --user -U Commitizen . Затем продолжите, запустив cz commit в клонированной папке.
• Создайте новый мерж-реквест в нашем основном репозитории.
• Проверьте, не произошел ли сбой в каком-либо из запусков конвейера, и примените возможные предложения.

Затем мы рассмотрим изменения и в конечном итоге объединим их.

Решение некоторых проблем с упаковкой

Устаревшие и сломанные пакеты

Бывают случаи, когда устаревшие пакеты больше не служат никакой цели, а также приводят к тому, что системы не могут обновляться. Их можно решить, добавив пакет в conflicts() garuda-common-settings и auto-pacman garuda-update . В результате пакет-нарушитель автоматически удаляется из-за конфликта.

CI/инструменты сборки

Следующее частично взято из документации инструментов сборки, без информации, не относящейся к этому репозиторию. Если вам нужны инструкции по установке, пожалуйста, используйте полный README.

Общий

Развертывание может быть автоматически инициировано либо изменением содержимого внутри каталога PKGBUILD, либо добавлением [deploy *] к сообщению о фиксации. В отличие от проверок PKGBUILD, они доступны только для коммитов в main ветке. Поддерживаются:

• [deploy all] : развертывает полную процедуру garuda , то есть все PKGBUILD в этом репозитории.
• [deploy $pkgname] : развертывает пакет pkgname , что означает, что, заменив его на garuda-bash-settings , можно будет развернуть garuda-bash-settings .

Как только любая из этих комбинаций будет обнаружена, развертывание начнется после успешного завершения нескольких проверок. Журналы прошлых развертываний можно просмотреть в разделе «Конвейеры».

Автоматизированные удары

Этот репозиторий предоставляет получасовой конвейер, который обновляет все PKGBUILD до последних версий, если их источник находится в другом репозитории , на основе последнего доступного тега. Затем он приступает к обновлению контрольных сумм и отправляет изменения обратно в основную ветку. Новое развертывание автоматически запускается путем добавления [deploy *] к сообщению о фиксации. Это означает, что достаточно отправить новый тег, чтобы инициировать развертывание новой версии пакета для этих пакетов. Важное примечание:

• Это не относится к пакетам, все файлы которых находятся в этом репозитории.
• Теги не должны начинаться с префикса v.
• Необходимая информация об источнике пакета предоставляется через файл SOURCES. Каждая строка соответствует схеме $url $pkgname $project_id . Последний используется для получения последнего тега через GitLab API и его можно найти на странице общих настроек репозитория.

Последние запуски этого задания можно просмотреть, просмотрев раздел конвейеров: каждый конвейер с запланированным значком был выполнен по таймеру. Кроме того, конвейер можно запустить вручную, просмотрев раздел расписаний конвейера и нажав «Запустить расписание конвейера» .

Обновление версий вручную

Для некоторых PKGBUILD, таких как garuda-fish-config , все файлы находятся в этом репозитории. При обновлении PKGBUILD обязательно обновите соответствующий файл .SRCINFO , поскольку он используется для анализа всей информации, связанной с пакетом!

Добавление пакетов

Добавить пакеты так же просто, как создать новую папку с именем $pkgbase пакета. Поместите сюда PKGBUILD и все другие необходимые файлы. Таким образом, добавить пакеты AUR так же просто, как клонировать его репозиторий и удалить папку .git . CI использует файлы .SRCINFO для анализа большей части информации, поэтому важно иметь их на месте и в актуальном состоянии в случае самоуправляемых пакетов. Наконец, добавьте папку .CI , содержащую базовую конфигурацию ( CI_PKGBUILD_SOURCE требуется на случай, если внешний пакет самоуправляемых PKBUILD не нуждается в ней), зафиксируйте все изменения и отправьте их обратно в основную ветку. При этом следуйте общепринятому соглашению о фиксации (cz-cli может в этом помочь!). Это означает, что коммиты типа:

• feat($pkgname): init
• fix($pkgname): fix xyz
• chore($pkgname): update PKGBUILD
• ci(config): update

Это не только помогает иметь единую историю коммитов, но и позволяет автоматически создавать журнал изменений.

Удаление пакетов

Это можно сделать, удалив папку, содержащую PKGBUILD пакета. Затем задание очистки автоматически удалит любой устаревший пакет посредством запуска конвейера on-commit . При этом также будут учитываться любые разделенные пакеты, которые может создавать пакет. Переименование папок также считается удалением пакетов.

Конвейер фиксации

Каждый раз при отправке нового коммита конвейер CI выполняет следующие действия:

• Проверка времени создания последней scheduled метки. Это используется для определения того, какие пакеты необходимо запланировать.
• Он анализирует каждый коммит на наличие строки [deploy $foldername] , принимая только допустимые значения, полученные из существующих папок PKGBUILD. [deploy all] также является допустимым параметром. Ошибка в написании $pkgname здесь является фатальной ошибкой. Любые проблемы необходимо решать и решать принудительно.
• Затем измененные файлы анализируются. Сюда также входят удаленные пакеты. Любое изменение содержимого соответствующей папки приведет к развертыванию соответствующего пакета.
• Последнее действие — построить параметры расписания (передать их запланированному заданию через артефакты) и удалить все устаревшие пакеты в случае обнаружения более раннего шага.
• В случае успешного выполнения всех этих действий scheduled тег обновляется, и мы можем обратиться к нему при следующем запуске конвейера.

Трубопровод по графику

каждые полчаса

Каждые полчаса конвейер по расписанию будет выполнять несколько задач:

• Обновление шаблона CI из репозитория шаблонов (если это включено через .ci/config )
• Проверьте, не существует ли запланированный тег или запланированное не указывает на HEAD (в этом случае прервать миссию!)
• Проверьте, существует ли рабочее дерево .state, содержащее состояние пакетов. Если оно существует, оно настраивает его. В противном случае он воссоздает его с нуля (например, при принудительном нажатии).
• Проверьте, является ли последний коммит автоматизированным (содержащим «работа (пакеты): обновить пакеты [skip ci]»), если да, то коммит, полученный по расписанию, перезапишет его, чтобы сохранить историю коммитов чистой.
• Собирайте временные метки пакетов AUR, чтобы определить, изменился ли PKGBUILD.
• Просмотрите каждый действительный пакет и выполните следующие действия:
  • Прочтите файл .CI/config чтобы получить информацию о конфигурации пакета (например, нужно ли управлять репозиторием AUR, источником PKGBUILD и т. д.).
  • Обновите PKGBUILD в следующих случаях:
    • Для CI_PKGBUILD_SOURCE установлено значение gitlab : обновляет PKGBUILD из тегов репозитория GitLab.
    • Для CI_PKGBUILD_SOURCE установлено значение aur : обновляет PKGBUILD из репозитория AUR, извлекая репозиторий git и заменяя существующие файлы новыми. Если метку времени AUR не удалось получить ранее, обновление пакета пропускается.
    • Для CI_PKGBUILD_SOURCE не установлено значение gitlab или aur : пытается обновить PKGBUILD, извлекая репозиторий, указанный в CI_PKGBUILD_SOURCE. Если клонирование не удалось после двух попыток, процесс обновления пропускается.
  • Если в переменных конфигурации пакетов установлен CI_GIT_COMMIT, обновляется последняя фиксация URL-адреса git, установленного в source разделе PKGBUILD. Если оно отличается, запланируйте сборку.
  • Если существует специальный хук ( .CI/update.sh внутри каталога пакета), он выполняется — его можно использовать для обновления PKGBUILD с помощью специального сценария.
  • Запись необходимых переменных обратно в .CI/config (например, хэш Git)
• Либо обновите PKGBUILD автоматически в случае незначительных изменений, либо создайте PR для проверки в случае крупных обновлений (и только если CI_HUMAN_REVIEW имеет значение true)
  • Обновления учитываются только в том случае, если diff действительно сообщает об изменениях между текущей папкой PKGBUILD и репозиторием AUR PKGBUILD.
  • Обнаруживаются любые изменения, внесенные в исходные файлы, однако при этом не обнаруживаются вредоносные изменения в исходном коде исходного проекта, который создает пакет.
• Рабочее дерево состояния обновляется новой информацией.
• Параметры расписания строятся и передаются запланированному заданию через артефакт.
• Устаревшие ветки (например, объединенные обзорные PR) сокращаются.
• Запланированный тег снова обновляется.

Ежедневно

Для определенных пакетов было добавлено ежедневное расписание конвейера, которые динамически генерируют свои pkgver . Чтобы использовать его, установите CI_ON_TRIGGER=daily внутри файла .CI/config пакета.

Ручное планирование

Планирование пакетов без коммитов git

Пакеты можно добавить в расписание вручную, перейдя на страницу запуска конвейера, выбрав «Запустить конвейер» и добавив PACKAGES в качестве переменной с именами пакетов в качестве значения. Затем конвейер подберет пакеты и запланирует их. PACKAGES также можно установить на all , чтобы запланировать все пакеты. Если один или несколько пакетов запланированы, они должны иметь формат pkgname1:pkgname2:pkgname3 .

Запуск запланированных конвейеров по требованию

Это можно сделать, перейдя на страницу запуска конвейера и выбрав «Запустить конвейер» (символ воспроизведения). Будет предоставлена ​​ссылка на страницу конвейера, где можно получить журналы конвейера.

Добавление помех

Поместите необходимый файл помех в папку .CI папки PKGBUILD:

• prepare : сценарий, который выполняется после настройки chroot здания. Его можно использовать для получения переменных среды или изменения других вещей перед началом компиляции.
  • Если что-то необходимо настроить перед фактическим процессом компиляции, команды можно передать, вставив, например. $CAUR_PUSH 'source /etc/profile' . Аналогичным образом можно решить конфликты пакетов, например. следующим образом: $CAUR_PUSH 'yes | pacman -S nftables' (одинарные кавычки важны, потому что мы хотим, чтобы переменные/каналы оценивались во время выполнения гостя, а не во время вмешательства)
• interfere.patch : файл исправления, который можно использовать для исправления нескольких файлов или PKGBUILD, если требуется много изменений. Все изменения необходимо внести в этот файл.
• PKGBUILD.prepend : содержимое этого файла добавляется в начало PKGBUILD.
• PKGBUILD.append : содержимое этого файла добавляется в конец PKGBUILD. Исправить build() так же просто, как добавить исправленную build() в этот файл. Это можно использовать для всех видов исправлений. Если что-то нужно добавить в массив, это так же просто, как makedepend+=(somepackage) .
• on-failure.sh : сценарий, который выполняется в случае сбоя сборки.
• on-success.sh : сценарий, который выполняется в случае успешного завершения сборки.

Натыкаясь на пкгрел

Теперь это выполняется путем добавления необходимой переменной CI_PACKAGE_BUMP в .CI/config . Дополнительную информацию см. ниже.

Деревья зависимостей

CI автоматически строит деревья зависимостей. Они передаются менеджеру Chaotic как артефакт CI и считываются при каждом выполнении команды расписания. Ручное вмешательство не требуется.

.CI/конфигурация

Файл .CI/config внутри каждого каталога пакета содержит дополнительные флаги для управления конвейерами и процессами сборки.

• CI_MANAGE_AUR : установив для этой переменной значение true , CI обновит соответствующий репозиторий AUR в конце запуска конвейера, если произойдут изменения (без файлов, связанных с CI).
• CI_PACKAGE_BUMP : управляет изменениями пакетов для всех пакетов, для которых для CI_MANAGE_AUR не установлено значение true . Он увеличивает pkgrel на 0.1 за каждое увеличение этой переменной на +1 .
• CI_PKGBUILD_SOURCE : устанавливает источник для всех файлов, связанных с PKGBUILD, используемых для получения обновленных файлов из удаленных репозиториев. Действительные значения на данный момент:
  • gitlab : извлекает PKGBUILD из тегов репозитория GitLab. Он должен иметь формат gitlab:$PROJECT_ID . Идентификатор можно получить, просмотрев общий раздел настроек репозитория.
  • aur : извлекает PKGBUILD из репозитория AUR, извлекая репозиторий git и заменяя существующие файлы новыми.
• CI_ON_TRIGGER : может быть предоставлен в случае, если специальный триггер расписания должен запланировать соответствующий пакет. Это можно использовать для ежедневного планирования пакетов, установив значение daily . Поскольку при этом проверяется, соответствует ли «$TRIGGER == $CI_ON_TRIGGER», любое пользовательское расписание может быть создано с использованием расписаний конвейера и установки TRIGGER на midnight , добавления подходящего расписания и установки CI_ON_TRIGGER для любого затронутого пакета на midnight .
• CI_REBUILD_TRIGGERS : добавьте в эту переменную пакеты, которые, как известно, вызывают пересборку. Список репозиториев, для которых нужно отслеживать версии пакетов, предоставляется через параметр CI_LIB_DB репозиториев. Каждая версия пакета хешируется и сбрасывается в .ci/lib.state . Каждый запланированный запуск конвейера сравнивает версии, проверяя несоответствия хэш-значений, и обрабатывает каждый затронутый пакет через CI_PACKAGE_BUMP .
• BUILDER_CACHE_SOURCES : может быть установлено значение true , если источники должны кэшироваться между сборками. Это может быть полезно в случае медленных источников или источников, которые недоступны постоянно. Исходные файлы будут удалены автоматически через 1 месяц, что важно в случае удаления пакетов или изменения исходного кода.

Управление пакетами AUR

Пакетами AUR также можно управлять через этот репозиторий автоматически, используя .CI_CONFIG . Это означает, что после каждого запланированного конвейера и конвейера при фиксации репозиторий AUR будет обновляться, чтобы отразить изменения, внесенные в файлы папки PKGBUILD. Файлы, не относящиеся к обслуживанию AUR (например, папки .CI ), будут опущены. Сообщение о фиксации отражает тот факт, что фиксация была создана конвейером CI, и содержит ссылку на историю фиксации исходного репозитория и запуск конвейера, который инициировал фиксацию обновления.

Обновление скриптов CI

Это делается автоматически через конвейер CI. Как только изменения будут обнаружены в репозитории шаблонов, все файлы будут обновлены до текущей версии.

Проблемы и сбои конвейера

Сбой последнего конвейера фиксации

Это может произойти по нескольким причинам, например, если указано неверное имя пакета. Это приводит к тому, что scheduled тег не обновляется. В этом случае запланированный конвейер не сможет работать. Прежде чем плановый конвейер сможет снова запуститься, необходимо исправить последний конвейер фиксации. Однако сбои сборки не учитываются, поскольку scheduled тег будет обновлен уже после создания параметров планирования. В таком случае активно поощряется принудительная отправка фиксированного коммита, так как принудительная отправка другой фиксации заставит CI оценить предыдущие пропущенные им коммиты, что приведет к повторному обнаружению той же проблемы и выходу из строя вместо молчаливого продолжения. Это дизайнерское решение, призванное предотвратить упущение из виду сбоев.

Сброс очереди сборки

В редких случаях может потребоваться сброс очереди сборки. Это можно сделать, завершив работу центрального экземпляра Redis, удалив его дамп и перезапустив службу.

Хаотичный менеджер

Этот инструмент распространяется в виде контейнеров Docker и состоит из пары экземпляров менеджера и компоновщика.

• Менеджер: registry.gitlab.com/garuda-linux/tools/chaotic-manager/manager /chaotic-manager/manager
• Строитель: registry.gitlab.com/garuda-linux/tools/chaotic-manager/builder /tools/chaotic-manager/builder
  • Он содержит реальную логику сборки пакетов (см. здесь), известную из infra 3.0, например interfere.sh , database.sh и т. д.
  • Выбирает пакеты для сборки из экземпляра Redis, управляемого экземпляром менеджера.

Менеджер используется GitLab CI в задании schedule-package , планируя пакеты, добавляя их в очередь сборки. Построитель может использоваться на любой машине, способной запустить контейнер. Он выберет доступные вакансии из нашего центрального экземпляра Redis.

Настройка разработки

В этом репозитории есть флейк NixOS, который можно использовать для автоматической настройки необходимых вещей, таких как перехваты и проверки перед фиксацией, а также необходимых утилит через direnv. Сюда входит проверка PKGBUILD с помощью shellcheck и shfmt . Необходимы nix (менеджер пакетов) и direnv, после этого в среду можно войти, запустив direnv allow .