pkgbuilds

Garuda Linux PKGBUILDs

Este repositório contém PKGBUILDs para todos os pacotes que atualmente residem em seu repositório garuda . Ele é operado no GitLab devido ao uso extensivo de seu CI e possui um espelho GitHub somente leitura.

Escopo deste repositório

Todos os nossos próprios PKGBUILDs estão contidos aqui. Historicamente, estes foram divididos em seus próprios repositórios. Para facilitar a localização do PKGBUILD correto, bem como para permitir contribuições mais rápidas, recentemente os consolidamos neste novo repositório. Estão incluídos todos os PKGBUILDs dos pacotes, incluindo seus arquivos de configuração (isso se aplica a arquivos menores como o garuda-fish-config ). Para alguns deles, como os pacotes garuda-*-settings , o conteúdo ainda pode ser encontrado em seus respectivos repositórios.

Encontrou algum problema?

Se ocorrer algum problema de embalagem ou algo semelhante, não hesite em reportá-lo através da nossa seção de problemas. Você pode clicar aqui para criar um novo.

Como contribuir?

Agradecemos muito contribuições de qualquer tipo! ? Para fazer isso, siga estas etapas:

• Crie um fork deste repositório.
• Clone seu fork localmente (breve tutorial do git).
• Adicione as alterações desejadas aos PKGBUILDs ou ao código-fonte.
• Certifique-se de que shellcheck e shfmt não relatem problemas com os arquivos alterados
  • As dependências necessárias precisam ser instaladas antes, por exemplo. via sudo pacman -S shfmt shellcheck
  • Execute o script lint.sh via bash ./.ci/lint.sh verifique o código
  • Aplique automaticamente certas sugestões via bash ./ci/lint.sh apply
• Faça commit usando uma mensagem de commit convencional e envie quaisquer alterações de volta para seu fork.
  • O aplicativo commitzen ajuda a criar uma mensagem de commit adequada. Você pode instalá-lo via pip, pois atualmente não há nenhum pacote nos repositórios do Arch: pip install --user -U Commitizen . Em seguida, prossiga executando cz commit na pasta clonada.
• Crie uma nova solicitação de mesclagem em nosso repositório principal.
• Verifique se alguma das execuções do pipeline falhou e aplique eventuais sugestões.

Em seguida, revisaremos as alterações e, eventualmente, mesclá-las-emos.

Lidando com certos problemas de embalagem

Pacotes obsoletos e quebrados

Há casos de pacotes obsoletos, que não servem mais para nada e também fazem com que os sistemas não consigam atualizar. Isso pode ser resolvido adicionando o pacote a conflicts() de garuda-common-settings e auto-pacman de garuda-update . O resultado é que o pacote ofensivo é removido automaticamente devido ao conflito.

Ferramentas de CI/construção

O seguinte foi parcialmente retirado da documentação das ferramentas de construção, omitindo informações não relevantes para este repositório. Caso você esteja procurando instruções de configuração, consulte o README completo.

Em geral

As implantações podem ser acionadas automaticamente alterando o conteúdo dentro de um diretório PKGBUILD ou anexando [deploy *] à mensagem de commit. Ao contrário das verificações do PKGBUILD, estas estão disponíveis apenas para commits no branch main . São suportados:

• [deploy all] : Implanta uma rotina garuda completa, ou seja, todos os PKGBUILDs neste repositório.
• [deploy $pkgname] : Implanta o pacote pkgname , o que significa que substituindo-o por garuda-bash-settings , seria implementado garuda-bash-settings .

Depois que qualquer uma dessas combinações for detectada, a implantação será iniciada após algumas verificações serem concluídas com êxito. Os registros de implantações anteriores podem ser inspecionados na seção Pipelines.

Solavancos automatizados

Este repositório fornece um pipeline de meia hora que atualiza todos os PKGBUILDs para suas versões mais recentes se sua fonte residir em outro repositório , com base na tag disponível mais recente. Em seguida, ele atualiza as somas de verificação e envia as alterações de volta para o branch principal. Uma nova implantação é acionada automaticamente anexando [deploy *] à mensagem de commit. Isso significa que é suficiente enviar uma nova tag para acionar a implantação de uma nova versão do pacote para esses pacotes. Aviso importante:

• Isto não se aplica a pacotes que possuem todos os seus arquivos neste repositório
• As tags não devem ser prefixadas com um v
• As informações necessárias sobre a fonte de um pacote são fornecidas através do arquivo SOURCES. Cada linha segue o esquema $url $pkgname $project_id . Este último é usado para recuperar a tag mais recente por meio da API GitLab e pode ser encontrado na página de configurações gerais do repositório.

As últimas execuções deste trabalho podem ser inspecionadas navegando na seção de pipelines, cada pipeline com o crachá agendado foi executado pelo cronômetro. Além disso, o pipeline pode ser acionado manualmente navegando na seção de agendamentos do pipeline e clicando em run pipeline schedule .

Atualizando versões manualmente

Para alguns PKGBUILDs, como garuda-fish-config , todos os arquivos residem neste repositório. Ao atualizar PKGBUILDs, certifique-se de atualizar também o arquivo .SRCINFO correspondente, pois este é usado para analisar todas as informações relacionadas ao pacote!

Adicionando pacotes

Adicionar pacotes é tão fácil quanto criar uma nova pasta com o nome $pkgbase do pacote. Coloque o PKGBUILD e todos os outros arquivos necessários aqui. Adicionar pacotes AUR é, portanto, tão simples quanto clonar seu repositório e remover a pasta .git . O CI depende de arquivos .SRCINFO para analisar a maioria das informações, portanto, é importante tê-los em vigor e atualizados no caso de pacotes autogerenciados. Por fim, adicione uma pasta .CI contendo a configuração básica ( CI_PKGBUILD_SOURCE é necessário caso seu pacote externo, PKBUILDs autogerenciados não precisem dele), confirme quaisquer alterações e envie as alterações de volta para o branch principal. Por favor, siga a convenção convencional de commit ao fazer isso (cz-cli pode ajudar com isso!). Isso significa commits como:

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

Isso não apenas ajuda a ter um histórico de commits uniforme, mas também permite a geração automática de changelog.

Removendo pacotes

Isso pode ser feito removendo a pasta que contém o PKGBUILD do pacote. Um trabalho de limpeza removerá automaticamente qualquer pacote obsoleto por meio da execução do pipeline on-commit . Isso também considerará quaisquer pacotes divididos que um pacote possa produzir. Renomear pastas também conta como remoção de pacotes.

Pipeline de confirmação

Sempre que enviar um novo commit, o pipeline de CI realizará as seguintes ações:

• Verificando quando a última tag scheduled foi criada. Isso é usado para determinar quais pacotes precisam ser agendados.
• Ele analisa cada commit para uma string [deploy $foldername] , aceitando apenas valores válidos derivados das pastas PKGBUILD existentes. [deploy all] também é um parâmetro válido. O erro ortográfico $pkgname é um erro fatal aqui. Quaisquer problemas devem ser corrigidos e forçados.
• Em seguida, os arquivos alterados são analisados. Isso também inclui pacotes removidos. Qualquer conteúdo de pasta relevante alterado causará uma implantação do pacote correspondente.
• A ação final é construir os parâmetros de agendamento (entregando-os ao trabalho agendado por meio de artefatos) e remover todos os pacotes obsoletos caso uma etapa anterior seja detectada.
• Caso todas essas ações sejam bem-sucedidas, a tag scheduled será atualizada, para que possamos consultá-la em uma execução posterior do pipeline.

Pipeline dentro do cronograma

Meia hora

A cada meia hora, o pipeline dentro do cronograma realizará algumas tarefas:

• Atualizando o modelo de CI do repositório de modelos (caso esteja habilitado via .ci/config )
• Verifique se a tag agendada não existe ou se a tag agendada não aponta para HEAD (neste caso aborte a missão!)
• Verifique se existe a árvore de trabalho .state que contém o estado dos pacotes, se existir, ele a configura. Caso contrário, ele o recriará do zero (por exemplo, ao forçar o push)
• Verifique se o último commit é automatizado (contendo "chore(packages): update packages [skip ci]"), se sim, o commit resultante do agendamento irá sobrescrevê-lo para manter o histórico de commits limpo.
• Colete carimbos de data/hora AUR de pacotes para determinar se um PKGBUILD foi alterado
• Percorra cada pacote válido e execute as seguintes ações:
  • Leia o arquivo .CI/config para obter informações sobre a configuração do pacote (por exemplo, se deve gerenciar o repositório AUR, a fonte do PKGBUILD, etc.)
  • Atualize o PKGBUILD nos seguintes casos:
    • CI_PKGBUILD_SOURCE está definido como gitlab : atualiza o PKGBUILD das tags do repositório GitLab
    • CI_PKGBUILD_SOURCE está definido como aur : Atualiza o PKGBUILD do repositório AUR, extraindo o repositório git e substituindo os arquivos existentes pelos novos. Se o carimbo de data/hora do AUR não puder ser coletado antes, a atualização do pacote será ignorada.
    • CI_PKGBUILD_SOURCE não está definido como gitlab ou aur : tenta atualizar o PKGBUILD extraindo o repositório especificado em CI_PKGBUILD_SOURCE. Caso a clonagem não seja bem-sucedida após 2 tentativas, o processo de atualização será ignorado.
  • Caso CI_GIT_COMMIT esteja definido nas variáveis ​​de configuração dos pacotes, o último commit da URL git definida na seção source do PKGBUILD é atualizado. Se for diferente, agende uma compilação.
  • Caso exista um gancho personalizado ( .CI/update.sh dentro do diretório do pacote), ele será executado - isso pode ser usado para atualizar PKGBUILDs com um script personalizado.
  • Gravando variáveis ​​necessárias de volta em .CI/config (por exemplo, hash Git)
• Atualize o PKGBUILD silenciosamente em caso de pequenas alterações, crie um PR para revisão em caso de atualizações importantes (e somente se CI_HUMAN_REVIEW for verdadeiro)
  • As atualizações só serão consideradas se o diff realmente relatar alterações entre a pasta PKGBUILD atual e o repositório AUR PKGBUILD
  • Qualquer alteração feita nos arquivos de origem é detectada, mas isso não detecta alterações maliciosas na origem do projeto upstream que o pacote constrói
• A árvore de trabalho do estado é atualizada com novas informações
• Os parâmetros de agendamento estão sendo criados e entregues ao trabalho agendado por meio de artefato
• Ramos obsoletos (por exemplo, PRs de revisão mesclados) estão sendo eliminados
• A tag programada é atualizada novamente

Diário

Uma programação diária de pipeline foi adicionada para pacotes específicos que geram seu pkgver dinamicamente. Para utilizá-lo, defina CI_ON_TRIGGER=daily dentro do arquivo .CI/config do pacote.

Agendamento manual

Agendando pacotes sem commits do git

Os pacotes podem ser adicionados manualmente ao agendamento acessando a página de execuções do pipeline, selecionando "Executar pipeline" e adicionando PACKAGES como uma variável com os nomes dos pacotes como seu valor. O pipeline então pegará os pacotes e os agendará. PACKAGES também pode ser definido como all para agendar todos os pacotes. Caso um ou mais pacotes estejam sendo agendados, ele precisa seguir o formato pkgname1:pkgname2:pkgname3 .

Executando pipelines programados sob demanda

Isso pode ser feito acessando a página de execuções do pipeline e selecionando "Executar pipeline" (o símbolo de reprodução). Será fornecido um link para a página do pipeline, onde os logs do pipeline poderão ser obtidos.

Adicionando interferência

Coloque o arquivo de interferência necessário na pasta .CI de uma pasta PKGBUILD:

• prepare : Um script que está sendo executado após a configuração do chroot de construção. Ele pode ser usado para gerar variáveis ​​de ambiente ou modificar outras coisas antes do início da compilação.
  • Se algo precisar ser configurado antes do processo de compilação real, os comandos podem ser enviados inserindo, por exemplo. $CAUR_PUSH 'source /etc/profile' . Da mesma forma, conflitos de pacotes podem ser resolvidos, por exemplo. da seguinte forma: $CAUR_PUSH 'yes | pacman -S nftables' (aspas simples são importantes porque queremos que as variáveis/pipes sejam avaliadas no tempo de execução do convidado e não enquanto interferem)
• interfere.patch : um arquivo de patch que pode ser usado para corrigir vários arquivos ou PKGBUILD se muitas alterações forem necessárias. Todas as alterações precisam ser adicionadas a este arquivo.
• PKGBUILD.prepend : o conteúdo deste arquivo é adicionado ao início do PKGBUILD.
• PKGBUILD.append : o conteúdo deste arquivo é adicionado ao final do PKGBUILD. Corrigir build() é tão fácil quanto adicionar build() fixo a este arquivo. Isso pode ser usado para todos os tipos de correções. Se algo precisar ser adicionado a um array, isso é tão fácil quanto makedepend+=(somepackage) .
• on-failure.sh : um script que será executado se a compilação falhar.
• on-success.sh : um script que será executado se a construção for bem-sucedida.

Batendo pkgrel

Isso agora é feito adicionando a variável necessária CI_PACKAGE_BUMP a .CI/config . Veja abaixo para mais informações.

Árvores de dependência

O IC constrói árvores de dependência automaticamente. Eles são passados ​​para o gerenciador Chaotic como um artefato de CI e lidos sempre que um comando de agendamento está sendo executado. Nenhuma intervenção manual é necessária.

.CI/config

O arquivo .CI/config dentro de cada diretório de pacote contém sinalizadores adicionais para controlar os pipelines e construir processos.

• CI_MANAGE_AUR : Ao definir esta variável como true , o CI atualizará o repositório AUR correspondente no final de uma execução de pipeline se ocorrerem alterações (omitindo arquivos relacionados ao CI)
• CI_PACKAGE_BUMP : Controla os aumentos de pacotes para todos os pacotes que não têm CI_MANAGE_AUR definido como true . Aumenta pkgrel em 0.1 para cada aumento de +1 nesta variável.
• CI_PKGBUILD_SOURCE : Define a fonte de todos os arquivos relacionados ao PKGBUILD, usados ​​para extrair arquivos atualizados de repositórios remotos. Os valores válidos a partir de agora são:
  • gitlab : extrai o PKGBUILD das tags do repositório GitLab. Ele precisa seguir o formato gitlab:$PROJECT_ID . O ID pode ser obtido navegando na seção geral de configurações do repositório.
  • aur : Extrai o PKGBUILD do repositório AUR, extraindo o repositório git e substituindo os arquivos existentes pelos novos.
• CI_ON_TRIGGER : Pode ser fornecido caso um gatilho de agendamento especial deva agendar o pacote correspondente. Isso pode ser usado para agendar pacotes diariamente, definindo o valor como daily . Como isso verifica se "$TRIGGER == $CI_ON_TRIGGER", qualquer agendamento personalizado pode ser criado usando agendamentos de pipeline e definindo TRIGGER como midnight , adicionando um agendamento adequado e definindo CI_ON_TRIGGER para qualquer pacote afetado como midnight .
• CI_REBUILD_TRIGGERS : Adicione pacotes conhecidos por causar reconstruções nesta variável. Uma lista de repositórios para rastrear versões de pacotes é fornecida por meio do parâmetro CI_LIB_DB dos repositórios. Cada versão do pacote é hash e despejada em .ci/lib.state . Cada execução de pipeline agendada compara versões verificando incompatibilidades de hash e irá colidir cada pacote afetado por meio de CI_PACKAGE_BUMP .
• BUILDER_CACHE_SOURCES : pode ser definido como true caso as fontes devam ser armazenadas em cache entre compilações. Isto pode ser útil no caso de fontes lentas ou que não estão disponíveis o tempo todo. As fontes serão limpas automaticamente após 1 mês, o que é importante caso os pacotes sejam removidos ou a fonte seja alterada.

Gerenciando pacotes AUR

Os pacotes AUR também podem ser gerenciados através deste repositório de forma automatizada usando .CI_CONFIG . Isso significa que após cada pipeline agendado e confirmado, o repositório AUR será atualizado para refletir as alterações feitas nos arquivos da pasta PKGBUILD. Arquivos não relevantes para a manutenção do AUR (por exemplo, pastas .CI ) serão omitidos. A mensagem de commit reflete o fato de que o commit foi criado por um pipeline de CI e contém o link para o histórico de commits do repositório de origem e a execução do pipeline que acionou o commit de atualização.

Atualizando os scripts do CI

Isso é feito automaticamente por meio do pipeline de CI. Assim que as alterações forem detectadas no repositório de modelos, todos os arquivos serão atualizados para a versão atual.

Problemas e falhas de pipeline

Falha no último pipeline de confirmação

Isso pode acontecer por alguns motivos, por exemplo, por ter fornecido um nome de pacote inválido. Isso faz com que a tag scheduled não seja atualizada. Nesse caso, o pipeline dentro do cronograma não poderá ser executado. O último pipeline on-commit precisa ser corrigido antes que o pipeline on-schedule possa ser executado novamente. No entanto, as falhas de compilação não são contabilizadas, pois a tag scheduled já seria atualizada assim que os parâmetros de agendamento fossem gerados. Forçar o envio de um commit fixo é ativamente incentivado nesse caso, pois o envio de outro commit fará com que o CI avalie os commits anteriores que perdeu, levando a perceber o mesmo problema novamente e a desistir em vez de continuar silenciosamente. Esta foi uma decisão de design para evitar que falhas fossem ignoradas.

Redefinindo a fila de compilação

Pode haver casos raros em que seja necessária uma redefinição da fila de construção. Isso pode ser feito desligando a instância central do Redis, removendo seu dump e reiniciando seu serviço.

Gerente Caótico

Esta ferramenta é distribuída como contêineres Docker e consiste em um par de instâncias de gerenciador e construtor.

• Gerenciador: registry.gitlab.com/garuda-linux/tools/chaotic-manager/manager
• Construtor: registry.gitlab.com/garuda-linux/tools/chaotic-manager/builder
  • Este contém a lógica real por trás das compilações de pacotes (vistas aqui) conhecidas no infra 3.0 como interfere.sh , database.sh etc.
  • Seleciona pacotes para construir a partir da instância do Redis gerenciada pela instância do gerenciador

O gerenciador é usado pelo GitLab CI no trabalho schedule-package , agendando pacotes adicionando-os à fila de construção. O construtor pode ser usado por qualquer máquina capaz de executar o contêiner. Ele escolherá os empregos disponíveis em nossa instância central do Redis.

Configuração de desenvolvimento

Este repositório apresenta um flake NixOS, que pode ser usado para configurar as coisas necessárias, como ganchos e verificações de pré-confirmação, bem como utilitários necessários, automaticamente via direnv. Isso inclui a verificação de PKGBUILDs via shellcheck e shfmt . São necessários nix (o gerenciador de pacotes) e direnv, depois disso, o ambiente pode ser acessado executando direnv allow .