Usando o sistema de construção Koji

Usando Koji no Fedora

O Koji Build System é o sistema de compilação de RPM do Fedora. Os empacotadores usam o cliente koji para solicitar compilações de pacotes e obter informações sobre o sistema de compilação. Koji é executado em cima do Mock para construir pacotes RPM para arquiteturas específicas e garantir que eles sejam construídos corretamente.

Você pode usar o comando koji diretamente ou usar fedpkg, um script que interage com o sistema de empacotamento RPM e outros subsistemas, como git e o próprio koji.

Instalando o Koji

Configuração do Koji

O arquivo de configuração do cliente global-local para koji é /etc/koji.conf. Você não deve precisar alterar os padrões para construir pacotes do Fedora. Isso permite que você use o sistema de construção primário, bem como sistemas de construção de arquitetura secundários.

Construindo com alvos do fedpkg

Ao construir com fedpkg dentro de um repositório git, cada push é automaticamente marcado via git. Tudo o que você precisa fazer para construir o pacote é executar fedpkg build. Isso aciona uma solicitação de construção para o branch. Fácil!

Também é possível direcionar uma tag específica do koji:

fedpkg build --target ALVO

Por exemplo, se estiver construindo em rawhide com uma tag lateral para atualizar a API de muitos pacotes, como f39-python, use o seguinte:

fedpkg build --target 'f39-python'

Construções encadeadas

Às vezes você quer ter certeza de que uma construção foi bem-sucedida antes de lançar a próxima, por exemplo, quando você deseja reconstruir um pacote contra uma dependência que acabou de ser reconstruída. fedpkg fornece um comando chain-build para ajudar com isso. Conforme explicado no guia de atualização de pacotes, cadeias multi-construção como esta devem ser criadas em uma tag lateral, e você pode usar fedpkg chain-build para fazer as construções na tag lateral.

Para fazer uma construção encadeada para uma tag lateral, primeiro crie a tag lateral, conforme explicado no guia de atualização de pacotes. No caso mais simples, basta fazer:

fedpkg request-side-tag

Isso exibirá um comando que você pode usar para aguardar a criação da tag lateral. Execute esse comando e, quando ele sair, faça:

fedpkg chain-build --target=side-tag-name libwidget libgizmo

substituindo side-tag-name pelo nome real da sua tag lateral.

O pacote atual é adicionado ao final da lista CHAIN. Dois pontos (:) podem ser usados no parâmetro CHAIN para definir grupos de pacotes. Os pacotes em qualquer grupo serão construídos em paralelo e todos os pacotes em um grupo deverão ser compilados com sucesso e preencher o repositório antes que o próximo grupo comece a ser construídos. Por exemplo:

fedpkg chain-build --target=side-tag-name libwidget libaselib : libgizmo :

faz com que libwidget e libaselib sejam construídos em paralelo, seguidos por libgizmo e então o pacote em seu diretório atual. Se nenhum grupo for definido, os pacotes serão construídos sequencialmente.

Se uma construção falhar, as construções seguintes serão canceladas, mas as construções que já foram bem-sucedidas serão enviadas para o repositório.

Nota: É possível fazer uma construção encadeada diretamente no destino de compilação padrão do Rawhide, mas isso não é mais recomendado ou confiável. Construir para o alvo Rawhide padrão cria automaticamente uma atualização imediatamente, e algumas atualizações do Rawhide agora estão sujeitas a testes de controle. Se qualquer pacote na cadeia estiver sujeito a testes de portas e um deles falhar, esse pacote nunca alcançará stable e o resto da cadeia não será capaz de construir. É bastante provável que isso aconteça com cadeias contendo pacotes de caminho crítico. Ao usar uma tag lateral, nenhuma atualização será criada automaticamente e cada compilação estará imediatamente disponível no buildroot da tag lateral sem a necessidade de passar nos testes primeiro. Você pode criar a atualização manualmente depois que todas as compilações forem concluídas, e os testes não encontrarão problemas de dependência se você reconstruir todos os pacotes dependentes corretamente.

Scratch Builds

Às vezes é útil poder construir um pacote no buildroot (diretório raiz da construção) sem realmente incluí-lo no lançamento. Isso é chamado de scratch build (em tradução livre, construção de rascunho).

A seção a seguir aborda o uso direto do koji, bem como a ferramenta fedpkg, para fazer scratch builds.

Para criar uma scratch build a partir de alterações que você não confirmou, faça o seguinte:

fedpkg scratch-build --srpm

A partir do mais recente commit do git:

koji build --scratch rawhide 'url do git'

Se você faz o commit das alterações para o git e está no branch atual, você pode fazer uma scratch build com fedpkg, que envolve a ferramenta de linha de comando koji com as opções apropriadas:

fedpkg scratch-build

Para executar uma scratch build para uma arquitetura específica:

fedpkg scratch-build --arches <archs>

<archs> pode ser uma lista separada por vírgulas de diversas arquiteturas.

Finalmente, é possível combinar o comando scratch-build com uma tag koji específica no formato:

fedpkg scratch-build --target ALVO

Execute fedpkg scratch-build --help ou koji build --help para mais informações.

Falhas de construção

Se seu pacote falha na construção, você obtém um erro, por exemplo:

420066 buildArch kernel-2.6.18-1.2739.10.9.el9.jjf.215394.2.src.rpm,
ia64): open (build-1.example.com) -> FAILED: BuildrootError:
error building package (arch ia64), mock exited with status 10

Investigue por que a construção falhou examinando os arquivos de log. Se houver um build.log, comece por aí. Caso contrário, veja init.log.

Cada trabalho iniciado com êxito recebe um ID de tarefa exclusivo, listado em sua saída.

Os logs podem ser encontrados na interface web, nas páginas Task da tarefa que falhou. Alternativamente, use koji watch-log, junto com o ID da tarefa, para visualizar os logs. Consulte a saída de ajuda para obter mais detalhes.

Uso avançado do Koji

Tentamos tornar o Koji autodocumentado sempre que possível. A ferramenta de linha de comando imprime uma lista de comandos válidos e cada comando suporta --help. Por exemplo:

$ koji help

Os comandos do Koji são:
build                Constrói um pacote a partir do código-fonte
cancel-task          Cancele uma tarefa
help                 Lista os comandos disponíveis
latest-build         Imprime os rpms mais recentes para uma tag
latest-pkg           Imprime as construções mais recentes para uma tag
[...]
$ koji build --help

usage: koji build [options]  tag URL
(Specify the --help global option for a list of other help options)

options:
-h, --help            show this help message and exit
--skip-tag            Do not attempt to tag package
--scratch             Perform a scratch build
--nowait              Don't wait on the build
[...]

Usando koji para gerar uma configuração do mock para replicar um buildroot

koji pode ser usado para replicar uma raiz de construção (buildroot) para depuração local.

koji mock-config --help
Usage: koji mock-config [options] name
(Specify the --help global option for a list of other help options)

Options:
  -h, --help            show this help message and exit
  --arch=ARCH           Specify the arch
  --tag=TAG             Create a mock config for a tag
  --task=TASK           Duplicate the mock config of a previous task
  --buildroot=BUILDROOT
                        Duplicate the mock config for the specified buildroot
                        id
  --mockdir=DIR         Specify mockdir
  --topdir=DIR          Specify topdir
  --topurl=URL          url under which Koji files are accessible
  --distribution=DISTRIBUTION
                        Change the distribution macro
  -o FILE               Output to a file

Por exemplo, para obter o buildroot mais recente para a execução de f38-build:

koji mock-config --tag f38-build --arch=x86_64 --topurl=http://kojipkgs.fedoraproject.org/ f38

Você deve passar --topurl=http://kojipkgs.fedoraproject.org/ para qualquer comando mock-config para obter um mock-config funcional do koji do Fedora.

Usando Koji para controlar tarefas

Listar tarefas:

koji list-tasks

Listar apenas tarefas solicitadas por você:

koji list-tasks --mine

Reenfileirar uma tarefa já processada (a sintaxe geral é: koji resubmit [options] taskID):

koji resubmit 3

Construindo um pacote com a ferramenta de linha de comando

Em vez de usar o alvo fedpkg, você também pode usar diretamente a ferramenta de linha de comando, koji.

Para construir um pacote, a sintaxe é:

koji build <alvo de construção> <URL git>

Por exemplo:

koji build f38-candidate 'url git'

O comando koji build cria uma tarefa de construção no Koji. Por padrão, a ferramenta aguardará e imprimirá atualizações de status até que a construção seja concluída. Você pode substituir isso com a opção --nowait.

Para o koji do Fedora, o URL git DEVE ser baseado em pkgs.fedoraproject.org. Outros repositórios git arbitrários não podem ser usados para construções.

Organização de tags e pacotes no Koji

Terminologia

No Koji, às vezes é necessário distinguir entre um pacote em geral, uma construção específica de um pacote e os vários arquivos rpm criados por uma construção. Quando a precisão é necessária, estes termos devem ser interpretados da seguinte forma:

  • Pacote: O nome de um rpm fonte. Isso se refere ao pacote em geral e não a uma construção ou subpacote em particular. Por exemplo: kernel, glibc, etc.

  • Construção: Uma construção específica de um pacote. Isto se refere a toda a construção: todos os arcos e subpacotes. Por exemplo: kernel-2.6.9-34.EL, glibc-2.3.4-2.19.

  • RPM: Um rpm específico. Uma arquitetura e subpacote específicos de uma construção. Por exemplo: kernel-2.6.9-34.EL.x86_64, kernel-devel-2.6.9-34.EL.s390, glibc-2.3.4-2.19.i686, glibc-common-2.3.4-2.19.ia64

Tags e alvos

Koji organiza pacotes usando tags No Koji, uma tag é basicamente uma coleção de pacotes:

  • Tags têm suporte a hierarquia

  • Cada tag tem sua própria lista de pacotes válidos (herdáveis)

  • A propriedade do pacote pode ser definida por tag (herdável)

  • Ao construir, você especifica um alvo em vez de uma tag

Um alvo de construção especifica onde um pacote deve ser compilado e como ele deve ser marcado posteriormente. Isso permite que os nomes dos destinos permaneçam fixos à medida que as tags mudam através dos lançamentos.

Comandos do Koji para tags

Alvos

Você pode obter uma lista completa de alvos (ou targets) de construção com o seguinte comando:

$ koji list-targets

Você pode ver apenas um único alvo com a opção --name:

$ koji list-targets --name f38
Name                           Buildroot                      Destination
---------------------------------------------------------------------------------------------
f38                            f38-build                      f38-updates-candidate

Isso indica que uma construção para o destino f38 usará um buildroot com pacotes da tag f38-build e marcará os pacotes resultantes como f38-updates-candidate.

Você provavelmente não deseja construir no rawhide. Se o Fedora N for o mais recente, para construir o próximo, escolha f\{N+1}.

Tags

Você pode obter uma lista de tags com o seguinte comando:

$ koji list-tags
Pacotes

Conforme mencionado acima, cada tag possui sua própria lista de pacotes que podem ser colocados na tag. Para ver essa lista de tags, use o comando list-pkgs:

$ koji list-pkgs --tag f38

A primeira coluna é o nome do pacote, a segunda informa de qual tag a entrada do pacote foi herdada e a terceira informa o proprietário do pacote.

Construções mais recentes

Para ver as versões mais recentes de uma tag, use o comando latest-pkg:

$ koji latest-pkg --all f38

A saída fornece não apenas as compilações mais recentes, mas também de qual tag elas foram herdadas e quem as construiu.