pkgbuilds

Garuda Linux PKGBUILD

Este repositorio contiene PKGBUILD para todos los paquetes que actualmente residen en su repositorio garuda . Se opera en GitLab debido al uso extensivo de su CI y tiene un espejo de GitHub de solo lectura.

Alcance de este repositorio

Todos nuestros propios PKGBUILD están contenidos aquí. Históricamente, estos se dividieron en sus propios repositorios. Para facilitar la búsqueda del PKGBUILD correcto, así como para permitir una contribución más rápida, recientemente los consolidamos en este nuevo repositorio. Se incluyen los PKGBUILD de todos los paquetes, incluidos sus archivos de configuración (esto se aplica a archivos más pequeños como garuda-fish-config ). Para algunos de ellos, como los paquetes garuda-*-settings , es posible que el contenido aún se encuentre en sus respectivos repositorios.

¿Encontraste algún problema?

Si ocurre algún problema con el embalaje o algo similar, no dude en informarlo a través de nuestra sección de problemas. Puede hacer clic aquí para crear uno nuevo.

¿Cómo contribuir?

¡Apreciamos mucho las contribuciones de cualquier tipo! ? Para hacerlo, siga estos pasos:

• Crea una bifurcación de este repositorio.
• Clona tu bifurcación localmente (breve tutorial de git).
• Agregue los cambios deseados a PKGBUILD o al código fuente.
• Asegúrese de que shellcheck y shfmt no informen problemas con los archivos modificados
  • Las dependencias necesarias deben instalarse antes, por ejemplo. vía sudo pacman -S shfmt shellcheck
  • Ejecute el script lint.sh a través de bash ./.ci/lint.sh verifique el código
  • Aplicar automáticamente ciertas sugerencias a través de bash ./ci/lint.sh apply
• Confirme utilizando un mensaje de confirmación convencional y envíe cualquier cambio a su bifurcación.
  • La aplicación de confirmación ayuda a crear un mensaje de confirmación adecuado. Puede instalarlo a través de pip ya que actualmente no hay ningún paquete en los repositorios de Arch: pip install --user -U Commitizen . Luego proceda ejecutando cz commit en la carpeta clonada.
• Cree una nueva solicitud de fusión en nuestro repositorio principal.
• Compruebe si alguna de las ejecuciones de la canalización falla y aplique posibles sugerencias.

Luego revisaremos los cambios y eventualmente los fusionaremos.

Manejo de ciertos problemas de embalaje

Paquetes obsoletos y rotos

Hay casos de paquetes obsoletos, que ya no sirven para nada y además provocan que los sistemas no puedan actualizarse. Estos se pueden manejar agregando el paquete a conflicts() de garuda-common-settings y auto-pacman de garuda-update . El resultado es que el paquete infractor se elimina automáticamente debido al conflicto.

CI/herramientas de construcción

Lo siguiente está tomado parcialmente de la documentación de las herramientas de compilación, omitiendo información que no es relevante para este repositorio. En caso de que esté buscando instrucciones de configuración, utilice el archivo README completo.

General

Las implementaciones pueden activarse automáticamente cambiando el contenido dentro de un directorio PKGBUILD o agregando [deploy *] al mensaje de confirmación. A diferencia de las comprobaciones PKGBUILD, estas solo están disponibles para confirmaciones en la rama main . Los compatibles son:

• [deploy all] : implementa una rutina garuda completa, es decir, todos los PKGBUILD en este repositorio.
• [deploy $pkgname] : implementa el paquete pkgname , lo que significa que al reemplazarlo con garuda-bash-settings , se implementaría garuda-bash-settings .

Una vez que se detecta cualquiera de esas combinaciones, la implementación comienza después de que se completen con éxito algunas comprobaciones. Los registros de implementaciones anteriores se pueden inspeccionar a través de la sección Canalizaciones.

Golpes automatizados

Este repositorio proporciona un proceso cada media hora que actualiza todos los PKGBUILD a sus últimas versiones si su fuente reside en otro repositorio , según la última etiqueta disponible. Luego procede a actualizar las sumas de verificación y envía los cambios a la rama principal. Se activa automáticamente una nueva implementación al agregar [deploy *] al mensaje de confirmación. Eso significa que es suficiente enviar una nueva etiqueta para activar la implementación de una nueva versión de paquete para estos paquetes. Aviso importante:

• Esto no se aplica a paquetes que tienen todos sus archivos en este repositorio.
• Las etiquetas no deben tener el prefijo v
• La información necesaria sobre el origen de un paquete se proporciona a través del archivo SOURCES. Cada línea sigue el esquema $url $pkgname $project_id . Este último se utiliza para recuperar la etiqueta más reciente a través de la API de GitLab y se puede encontrar en la página de configuración general del repositorio.

Las últimas ejecuciones de este trabajo se pueden inspeccionar navegando por la sección de canalizaciones; el temporizador ejecutó cada canalización con la insignia programada . Además, la canalización se puede activar manualmente navegando por la sección de cronogramas de canalización y presionando ejecutar programación de canalización .

Actualizar versiones manualmente

Para algunos PKGBUILD, como garuda-fish-config , todos los archivos residen en este repositorio. Al actualizar PKGBUILD, asegúrese de actualizar también el archivo .SRCINFO correspondiente, ya que éste se utiliza para analizar toda la información relacionada con el paquete.

Agregar paquetes

Agregar paquetes es tan fácil como crear una nueva carpeta con el nombre de $pkgbase del paquete. Coloque aquí el PKGBUILD y todos los demás archivos necesarios. Por lo tanto, agregar paquetes AUR es tan simple como clonar su repositorio y eliminar la carpeta .git . CI se basa en archivos .SRCINFO para analizar la mayor parte de la información; por lo tanto, es importante tenerlos implementados y actualizados en el caso de paquetes autoadministrados. Finalmente, agregue una carpeta .CI que contenga la configuración básica (se requiere CI_PKGBUILD_SOURCE en caso de que su paquete externo, los PKBUILD autoadministrados no lo necesiten), confirme cualquier cambio y envíe los cambios nuevamente a la rama principal. Siga la convención de confirmación convencional mientras lo hace (¡cz-cli puede ayudar con eso!). Esto significa confirmaciones como:

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

Esto no sólo ayuda a tener un historial de confirmaciones uniforme, sino que también permite la generación automática de registros de cambios.

Eliminando paquetes

Esto se puede hacer eliminando la carpeta que contiene el PKGBUILD de un paquete. Luego, un trabajo de limpieza eliminará automáticamente cualquier paquete obsoleto mediante la ejecución de la canalización on-commit . Esto también considerará cualquier paquete dividido que pueda producir un paquete. Cambiar el nombre de las carpetas también cuenta como eliminar paquetes.

Canalización en compromiso

Cada vez que se impulsa una nueva confirmación, la canalización de CI llevará a cabo las siguientes acciones:

• Comprobando cuándo se creó la última etiqueta scheduled . Esto se utiliza para determinar qué paquetes deben programarse.
• Analiza cada confirmación en busca de una cadena [deploy $foldername] y solo acepta valores válidos derivados de las carpetas PKGBUILD existentes. [deploy all] también es un parámetro válido. Escribir mal $pkgname es un error fatal aquí. Cualquier problema debe solucionarse y forzarse.
• Luego, se analizan los archivos modificados. Esto también incluye paquetes eliminados. Cualquier cambio en el contenido de la carpeta relevante provocará la implementación del paquete correspondiente.
• La acción final es crear los parámetros de programación (entregándolos al trabajo programado a través de artefactos) y eliminar todos los paquetes obsoletos en caso de que se detecte un paso anterior.
• En caso de que todas estas acciones se realicen correctamente, la etiqueta scheduled se actualiza para que podamos consultarla en una ejecución posterior del proceso.

Tubería según lo previsto

cada media hora

Cada media hora, el pipeline realizará según lo previsto algunas tareas:

• Actualización de la plantilla de CI desde el repositorio de plantillas (en caso de que esté habilitado a través de .ci/config )
• Compruebe si la etiqueta programada no existe o si la programada no apunta a HEAD (en este caso, ¡aborte la misión!)
• Compruebe si existe el árbol de trabajo .state que contiene el estado de los paquetes; si existe, lo configura. De lo contrario, lo recrea desde cero (por ejemplo, al forzar el envío)
• Compruebe si la última confirmación está automatizada (contiene "tarea (paquetes): actualizar paquetes [omitir ci]"); en caso afirmativo, la confirmación resultante de la programación la sobrescribirá para mantener limpio el historial de confirmaciones.
• Recopile marcas de tiempo AUR de paquetes para determinar si un PKGBUILD cambió
• Recorra cada paquete válido y lleve a cabo las siguientes acciones:
  • Lea el archivo .CI/config para obtener información sobre la configuración del paquete (por ejemplo, si se debe administrar el repositorio AUR, la fuente de PKGBUILD, etc.)
  • Actualice PKGBUILD en los siguientes casos:
    • CI_PKGBUILD_SOURCE está configurado en gitlab : actualiza PKGBUILD desde las etiquetas del repositorio de GitLab
    • CI_PKGBUILD_SOURCE está configurado en aur : actualiza PKGBUILD desde el repositorio AUR, incorporando el repositorio git y reemplazando los archivos existentes con los nuevos. Si no se pudo recopilar la marca de tiempo AUR antes, se omitirá la actualización del paquete.
    • CI_PKGBUILD_SOURCE no está configurado en gitlab o aur : intenta actualizar PKGBUILD extrayendo el repositorio especificado en CI_PKGBUILD_SOURCE. En caso de que la clonación no haya tenido éxito después de 2 intentos, se omitirá el proceso de actualización.
  • En caso de que CI_GIT_COMMIT esté configurado en las variables de configuración del paquete, se actualiza la última confirmación de la URL de git establecida en la sección source de PKGBUILD. Si difiere, programe una compilación.
  • En caso de que exista un enlace personalizado ( .CI/update.sh dentro del directorio del paquete), se ejecuta; esto se puede usar para actualizar PKGBUILD con un script personalizado.
  • Escribir las variables necesarias en .CI/config (por ejemplo, Git hash)
• Actualice PKGBUILD de forma silenciosa en caso de cambios menores, cree un PR para revisión en caso de actualizaciones importantes (y solo si CI_HUMAN_REVIEW es verdadero)
  • Las actualizaciones solo se consideran si la diferencia realmente informa cambios entre la carpeta PKGBUILD actual y el repositorio AUR PKGBUILD.
  • Se detecta cualquier cambio realizado en los archivos fuente; sin embargo, esto no detecta cambios maliciosos en la fuente del proyecto ascendente que crea el paquete.
• El árbol de trabajo estatal se actualiza con nueva información.
• Los parámetros de programación se crean y se entregan al trabajo programado a través de un artefacto
• Se están eliminando ramas obsoletas (p. ej., relaciones públicas de revisión fusionadas)
• La etiqueta programada se actualiza nuevamente

A diario

Se ha agregado un cronograma de canalización diario para paquetes específicos que generan su pkgver dinámicamente. Para utilizarlo, configure CI_ON_TRIGGER=daily dentro del archivo .CI/config del paquete.

Programación manual

Programación de paquetes sin confirmaciones de git

Los paquetes se pueden agregar a la programación manualmente yendo a la página de ejecución de la canalización, seleccionando "Ejecutar canalización" y agregando PACKAGES como una variable con los nombres de los paquetes como su valor. Luego, el oleoducto recogerá los paquetes y los programará. PACKAGES también se puede configurar en all para programar todos los paquetes. En caso de que se programen uno o varios paquetes, debe seguir el formato pkgname1:pkgname2:pkgname3 .

Ejecución de canalizaciones programadas bajo demanda

Esto se puede hacer yendo a la página de ejecución de canalización, seleccionando "Ejecutar canalización" (el símbolo de reproducción). Se proporcionará un enlace a la página de la tubería, donde se pueden obtener los registros de la tubería.

Añadiendo interferencia

Coloque el archivo de interferencia requerido en la carpeta .CI de una carpeta PKGBUILD:

• prepare : un script que se ejecuta después de que se haya configurado el chroot del edificio. Se puede utilizar para obtener variables de entorno o modificar otras cosas antes de que comience la compilación.
  • Si es necesario configurar algo antes del proceso de compilación real, los comandos se pueden enviar insertando, por ejemplo. $CAUR_PUSH 'source /etc/profile' . Asimismo, los conflictos de paquetes se pueden resolver, por ejemplo. de la siguiente manera: $CAUR_PUSH 'yes | pacman -S nftables' (las comillas simples son importantes porque queremos que las variables/canalizaciones se evalúen en el tiempo de ejecución del invitado y no mientras interfieren)
• interfere.patch : un archivo de parche que se puede utilizar para reparar varios archivos o PKGBUILD si se requieren muchos cambios. Todos los cambios deben agregarse a este archivo.
• PKGBUILD.prepend : el contenido de este archivo se agrega al comienzo de PKGBUILD.
• PKGBUILD.append : el contenido de este archivo se agrega al final de PKGBUILD. Arreglar build() es tan fácil como agregar el build() fijo a este archivo. Esto se puede utilizar para todo tipo de correcciones. Si es necesario agregar algo a una matriz, esto es tan fácil como makedepend+=(somepackage) .
• on-failure.sh : un script que se ejecuta si falla la compilación.
• on-success.sh : un script que se ejecuta si la compilación se realiza correctamente.

Paquete de golpes

Esto ahora se lleva a cabo agregando la variable requerida CI_PACKAGE_BUMP a .CI/config . Consulte a continuación para obtener más información.

Árboles de dependencia

El CI crea árboles de dependencia automáticamente. Se pasan al administrador de Chaotic como un artefacto de CI y se leen cada vez que se ejecuta un comando de programación. No se necesita intervención manual.

.CI/config

El archivo .CI/config dentro de cada directorio de paquetes contiene indicadores adicionales para controlar las canalizaciones y crear procesos.

• CI_MANAGE_AUR : al establecer esta variable en true , el CI actualizará el repositorio AUR correspondiente al final de la ejecución de una canalización si se producen cambios (omitiendo los archivos relacionados con el CI).
• CI_PACKAGE_BUMP : controla los cambios de paquetes para todos los paquetes que no tienen CI_MANAGE_AUR establecido en true . Aumenta pkgrel en 0.1 por cada aumento de +1 de esta variable.
• CI_PKGBUILD_SOURCE : establece el origen de todos los archivos relacionados con PKGBUILD, que se utiliza para extraer archivos actualizados de repositorios remotos. Los valores válidos a partir de ahora son:
  • gitlab : extrae el PKGBUILD de las etiquetas del repositorio de GitLab. Debe seguir el formato gitlab:$PROJECT_ID . El ID se puede obtener navegando por la sección general de configuración del repositorio.
  • aur : extrae el PKGBUILD del repositorio de AUR, incorpora el repositorio de git y reemplaza los archivos existentes con los nuevos.
• CI_ON_TRIGGER : se puede proporcionar en caso de que un activador de programación especial deba programar el paquete correspondiente. Esto se puede utilizar para programar paquetes diariamente, estableciendo el valor en daily . Dado que esto verifica si "$TRIGGER == $CI_ON_TRIGGER", se puede crear cualquier cronograma personalizado usando cronogramas de canalización y configurando TRIGGER en midnight , agregando un cronograma adecuado y configurando CI_ON_TRIGGER para cualquier paquete afectado en midnight .
• CI_REBUILD_TRIGGERS : agrega paquetes que se sabe que causan reconstrucciones en esta variable. Se proporciona una lista de repositorios para rastrear las versiones de paquetes a través del parámetro CI_LIB_DB de los repositorios. Cada versión del paquete se codifica y se descarga en .ci/lib.state . Cada ejecución de canalización programada compara versiones comprobando discrepancias de hash y eliminará cada paquete afectado a través de CI_PACKAGE_BUMP .
• BUILDER_CACHE_SOURCES : se puede establecer en true en caso de que las fuentes deban almacenarse en caché entre compilaciones. Esto puede resultar útil en caso de fuentes lentas o fuentes que no están disponibles todo el tiempo. Las fuentes se borrarán automáticamente después de 1 mes, lo cual es importante en caso de que se eliminen paquetes o cambie la fuente.

Administrar paquetes AUR

Los paquetes AUR también se pueden administrar a través de este repositorio de forma automatizada usando .CI_CONFIG . Esto significa que después de cada canalización programada y en confirmación, el repositorio AUR se actualizará para reflejar los cambios realizados en los archivos de la carpeta PKGBUILD. Se omitirán los archivos que no sean relevantes para el mantenimiento de AUR (por ejemplo, carpetas .CI ). El mensaje de confirmación refleja el hecho de que la confirmación fue creada por una canalización de CI y contiene el enlace al historial de confirmaciones del repositorio de origen y la ejecución de la canalización que desencadenó la confirmación de actualización.

Actualización de los scripts del CI

Esto se hace automáticamente a través de la canalización de CI. Una vez que se hayan detectado cambios en el repositorio de plantillas, todos los archivos se actualizarán a la versión actual.

Problemas y fallas en la tubería

Falló la última canalización de confirmación

Esto puede suceder por varios motivos, por ejemplo, haber proporcionado un nombre de paquete no válido. Esto hace que la etiqueta scheduled no se actualice. En este caso, la canalización según lo previsto no podrá ejecutarse. La última canalización en confirmación debe repararse antes de que la canalización según lo programado pueda ejecutarse nuevamente. Sin embargo, los errores de compilación no se contabilizan ya que la etiqueta scheduled se actualizaría tan pronto como se generaran los parámetros de programación. En tal caso, se recomienda activamente forzar una confirmación fija, ya que presionar otra confirmación hará que el CI evalúe las confirmaciones anteriores que omitió, lo que llevará a notar el mismo problema nuevamente y abandonar en lugar de continuar en silencio. Esta ha sido una decisión de diseño para evitar que se pasen por alto los fallos.

Restablecer la cola de compilación

Puede haber casos excepcionales en los que sea necesario restablecer la cola de compilación. Esto se puede hacer cerrando la instancia central de Redis, eliminando su volcado y reiniciando su servicio.

Gerente caótico

Esta herramienta se distribuye como contenedores Docker y consta de un par de instancias de administrador y constructor.

• Administrador: registry.gitlab.com/garuda-linux/tools/chaotic-manager/manager
• Constructor: registry.gitlab.com/garuda-linux/tools/chaotic-manager/builder
  • Este contiene la lógica real detrás de las compilaciones de paquetes (vistas aquí) conocidas desde infra 3.0 como interfere.sh , database.sh , etc.
  • Elige paquetes para compilar desde la instancia de Redis administrada por la instancia del administrador

GitLab CI utiliza el administrador en el trabajo schedule-package , programando paquetes agregándolos a la cola de compilación. El constructor puede ser utilizado por cualquier máquina capaz de ejecutar el contenedor. Seleccionará los trabajos disponibles de nuestra instancia central de Redis.

Configuración de desarrollo

Este repositorio cuenta con un copo de NixOS, que se puede usar para configurar las cosas necesarias, como comprobaciones y ganchos de confirmación previa, así como las utilidades necesarias, automáticamente a través de direnv. Esto incluye verificar los PKGBUILD mediante shellcheck y shfmt . Se necesitan nix (el administrador de paquetes) y direnv; después de eso, se puede ingresar al entorno ejecutando direnv allow .