Package Maintainer guidelines (Português)
O Mantenedores de Pacote, ou Package Maintainers, são membros de uma equipe do Arch Linux encarregada de manter o AUR funcionando. Ele/Ela mantém pacotes populares (comunicando-se com o upstream e enviando-o patches quando necessário) e vota em assuntos administrativos. Um Mantenedor de Pacote é eleito de membros ativos da comunidade pelos atuais Mantenedores de Pacote em um processo democrático. Mantenedores de Pacote são os únicos membros que têm a última palavra na direção do AUR.
Os Mantenedores de Pacote são governados usando as Package Maintainer bylaws ("Estatuto dos Mantenedores de Pacote")
Lista de tarefas para novos Mantenedores de Pacote
- Ler este artigo de wiki por completo.
- Ler as Package Maintainer Bylaws.
- Certificar-se de que os detalhes da sua conta no AUR estejam atualizados.
- Pedir que um de seus patrocinadores (sponsors) lhe dê o status de Mantenedor de Pacote no AUR.
- Lembrar um bureaucrat de adicionar sua conta wiki ao grupo Arch Linux Package Maintainers
- Lembrar um administrador do BBS de alterar sua conta nos fóruns.
- Pedir a um de seus patrocinadores as chaves de #archlinux-staff e #archlinux-packaging e participar nos canais (isso não é obrigatório, mas é uma ótima forma de conhecer partes da equipe e colaborar).
- Se você precisar de um bouncer, peça ao heftig por um convite de Matrix.
- Se você quiser uma manta de
@archlinux/package-maintainer/nome-de-usuário, peça aos nossos contatos de grupos para obter uma.
- Pedir a um de seus patrocinadores para criar um ticket no rastreador de problemas do repositório de infraestrutura (usando o modelo
Onboarding) e forneça-os com as seguintes informações:- Uma chave pública SSH. Se você não possuir uma, siga SSH keys#Generating an SSH key pair para criar uma.
- Um nome de usuário que será usado para sua conta SSO e para seu endereço de e-mail
@archlinux.org(a ser criado). - Seu nome completo.
- Seu endereço de e-mail (pessoal) e um ID de chave pública PGP válido para ele, que será usado para fornecer a senha inicial da interface do desenvolvedor (archweb) para você e que será vinculado a sua conta SSO (a ser criada).
- Se seu endereço de e-mail particular ou
nome-de-usuário@archlinux.org(a ser criado) deve ser usado para as listas de e-mail não públicas e ter permissão para postar na lista de discussão arch-dev-public.
- Definir a senha para seu endereço de e-mail
@archlinux.orgseguindo DeveloperWiki:Staff Services#Email. - Criar um par de chaves PGP para assinatura de pacote seguindo o fluxo de trabalho para adicionar uma nova chave de empacotador (usando seu novo endereço
nome-de-usuário@archlinux.orgcomo uid). - Pedir a um de seus patrocinadores para criar um ticket no rastreador de problemas do repositório archlinux-keyring (usando o modelo
New Packager Key) para ter sua chave PGP assinada por (pelo menos) três principais detentores de chaves. - Instalar o pacote devtools.
-
Configurar sua chave privada ssh para os servidores
orion.archlinux.orgerepos.archlinux.org. - Testar a conexão SSH para
nome-de-usuário@orion.archlinux.org(assim que você tiver permissões). - Começar a contribuir!
O Mantenedor de Pacote e o AUR
Os Mantenedores de Pacote deveriam também fazer um esforço para verificar o envio de pacotes no AUR por códigos maliciosos e o correto seguimento dos padrões dos PKGBUILD. Em cerca de 80% dos casos, os PKGBUILDs no AUR são muito simples e podem ter rapidamente verificadas a sanidade e os códigos maliciosos pela equipe de Mantenedores de Pacote.
Os Mantenedores de Pacote devem também verificar os PKGBUILDs por pequenos erros, sugerir correções e melhoras. O Mantenedor de Pacote deve se tentar certificar-se de que todos os pacotes sigam Arch Packaging Guidelines/Standards (Diretrizes/Padrões de Empacotamento do Arch) e ao fazer isso, compartilhar suas habilidades com outros criadores de pacotes em um esforço em criar um padrão de criação de pacotes por toda a distribuição.
Os Mantenedores de Pacote também estão em uma posição de documentar práticas recomendadas.
Reescrevendo histórico Git
Em alguns casos, é necessário reescrever o histórico de um repositório do AUR, por exemplo, quando um usuário inadvertidamente usa seu nome legal em um commit publicado. Isso pode ser automatizado com git-filter-branch(1).
Para realizar um push forçado para um novo histórico, encaminhe a variável de ambiente AUR_OVERWRITE=1 para o git-push(1).
Em detalhes, isso inclui adicionar SendEnv AUR_OVERWRITE à sua configuração AUR SSH e definir o env var em seu comando push: AUR_OVERWRITE=1 git push --force.
Veja [1] para detalhes.
- Modificar a identidade do committer ou autor
Instale git-filter-repo e execute:
$ git-filter-repo --name-callback 'return name.replace(b"Nome antigo", b"Nome novo")' --email-callback 'return email.replace(b"antigo@email.com", b"novo@email.com")'
name.replace("Bás Ssze".encode("utf-8"), b"novonome")'
Alternativamente, use git filter-branch --env-filter com as variáveis de ambiente GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME e GIT_COMMITTER_EMAIL. Por exemplo:
git filter-branch --env-filter ' if test "$GIT_AUTHOR_EMAIL" = "lepetit@prince.com"; then GIT_AUTHOR_EMAIL=user@users.noreply.github.com fi if test "$GIT_AUTHOR_NAME" = "Antoine de Saint-Exupéry"; then GIT_AUTHOR_NAME=user fi'
git log --pretty=fuller para exibir o author e o committer.Lidando com requisições no AUR
Os Mantenedores de Pacote devem verificar periodicamente as requisições enviadas no AUR. Para isso existem algumas regras genéricas sobre o que verificar para cada tipo de requisição:
- Requisição para tornar órfão
- verifique se o pedido tem mais de 14 dias (a coluna de data fica vermelha na visão geral) (você não pode aceitá-lo antes disso de qualquer maneira)
- verifique se não houve atualização do próprio pacote (commit ou release) feita nos últimos 14 dias
- verifique se não houve comentário do mantenedor do pacote no AUR feito nos últimos 14 dias
Se todos os pontos acima forem atendidos, você poderá aceitar a requisição para tornar órfão.
O Mantenedor de Pacote e extra, diretrizes para manutenção de pacotes
Regras para a entrada de pacotes no repositório extra
- Um pacote não pode já existir em qualquer um dos repositórios do Arch Linux. você deve tomar os cuidados necessários para se certificar que nenhum outro empacotador está no processo de promoção do mesmo pacote. Veja os comentários do pacote do AUR, leia os últimos títulos de assuntos no aur-general, pesquise em todos os projetos no rastreador de erro[link inativo 2024-01-13 ⓘ], faça um grep no git-log(1) e envie uma mensagem rápida para o canal IRC privado "packaging".
-
Wrappers do pacman, como uma exceção especial, nunca serão permitidos. Se desejar adicionar auxiliares do AUR, escreva um e-mail para
arch-dev-publiccom a adição proposta e respeite as objeções fornecidas pelos membros da equipe.
- Somente pacotes "populares" podem entrar no repositório, sendo definido pelo 1% de uso no pkgstats ou 10 votos no AUR.
- Exceções automáticas a esta regra são:
- pacotes de internacionalização (i18n)
- pacotes de acessibilidade
- drivers
- dependências de pacotes que satisfazem a definição de populares, incluindo makedeps e optdeps
- pacotes que são parte de uma coleção e têm a intenção de ser distribuídos juntos, fornecendo uma parte da coleção satisfaz a definição de popular
- Quaisquer adições não cobertas por nenhum dos critérios acima devem ser propostas na lista de discussão aur-general, explicando o motivo para a dispensa (ex.: pacote renomeado, novo pacote). O acordo de três outros Mantenedores de Pacote é necessário para que o pacote seja aceito na extra. Adições propostas por Mantenedores de Pacote com grande número de pacotes "não-populares" provavelmente serão rejeitadas.
- Os Mantenedores de Pacote são incentivados a mover os pacotes mantidos do extra, se eles tiverem baixo uso. Nenhuma aplicação será necessária, apesar de que a renúncia de pacotes de Mantenedores de Pacote pode ser filtrada antes que ocorra adoção.
- É uma boa prática sempre incrementar o pkgrel em 1 (em outras palavras, defina o para n + 1) ao promover um pacote do AUR. Isso é para facilitar atualizações automáticas para aqueles que já têm o pacote instalado, de forma que eles podem continuar a receber atualizações a partir do canal oficial. Um outro efeito positivo disto é que usuários não são avisados que sua cópia local é mais nova, como é o caso se um empacotador redefinir o pkgrel para 1.
Acessando e atualizando o repositório
Veja o guia do empacotador.
Abandonando pacotes
Se um Mantenedor de Pacote não pode ou não quer mais manter um pacote, um aviso deve ser postado na Lista de Discussão do AUR, para que outro mantenedor de pacote possa mantê-lo. Um pacote pode ainda ser abandonado mesmo se nenhum outro Mantenedor de Pacote quiser mantê-lo, mas os Mantenedores de Pacote devem evitar de deixar muitos pacotes soltos (eles não deveriam manter mais do que possam dar conta). Se um pacote se tornou obsoleto ou não é mais usado, ele também pode ser completamente removido.
Se um pacote foi removido completamente, o mesmo pode ser enviado novamente (do zero) para o AUR, onde um usuário normal pode manter o pacote ao invés de um Mantenedor de Pacote.
Movendo pacotes do AUR para extra
Siga os procedimentos normais para adição de um pacote ao extra usando as instruções do guia do empacotador, mas lembre-se de remover o pacote correspondente do AUR!
Movendo pacotes do extra para AUR
Remova o pacote usando as instruções do guia do empacotador e envie o seu tarball fonte para o AUR.
Movendo pacotes do extra-testing para extra
Mova o pacote do repositório extra-testing para o repositório extra usando as instruções do guia do empacotador.
Compilação remota no build.archlinux.org
Mantenedor de Pacote e Desenvolvedores podem se conectar ao build.archlinux.org via SSH para, entre outros, criar pacotes usando o devtools. Isso tem diversas vantagens sobre a configuração local:
- Compilações são rápidas e a velocidade de rede é alta.
- O ambiente precisa ser configurado apenas uma vez.
- Seu sistema local não precisa ser Arch Linux.
O processo é semelhante ao de uma configuração local com devtools. Seu GnuPG privado é necessário para assinar, mas você não quer enviá-lo por razões óbvias de segurança. Como tal, você precisará encaminhar o soquete de agente do GnuPG de sua máquina local para o servidor: isso permitirá que você assine pacotes no servidor de compilação sem comunicar sua chave. Isso também significa que precisamos desabilitar o agente no servidor antes de podermos executar qualquer coisa.
Primeiro, conecte-se ao servidor de compilação e desabilite-o:
$ ssh build.archlinux.org $ systemctl --user mask gpg-agent.service
Certifique-se de que o gpg-agent não esteja em execução (systemctl --user stop gpg-agent.service). Neste ponto, certifique-se de que não existem soquetes na pasta apontada por gpgconf --list-dir socketdir. Em caso afirmativo, remova-os ou efetue o logout e novamente.
Se você tem um $GNUPGHOME personalizado (por exemplo, para movê-lo para ~/.config/gnupg), você precisará desmarcar isso, pois não é possível no gnupg definir o homedir sem configurar o socketdir.
No servidor de compilação, StreamLocalBindUnlink yes está definido no sshd_config, então remover os soquetes manualmente no logout não é necessário.
Enquanto as chaves privadas PGP permanecem em sua máquina local, as chaves públicas devem estar no servidor de compilação. Exportar sua chave público para o servidor de compilação, por exemplo da sua máquina local
$ scp ~/.gnupg/pubring.gpg build.archlinux.org:~/.gnupg/pubring.gpg
O SSH é necessário para fazer checkout e commit no repositório Git. Você pode configurar um novo par de chaves SSH no servidor (é altamente desencorajado colocar sua chave privada local no servidor por motivos de segurança) ou reutilizar as chaves locais por meio do encaminhamento de soquete. Se você optar por este último, certifique-se de desabilitar o ssh-agent no servidor de compilação se você o habilitou anteriormente (ele não está em execução por padrão).
Configure seu ambiente de compilação no servidor de compilação:
~/.makepkg.conf
PACKAGER="John Doe <john@doe.example>" ## Opcional PKGDEST="/home/johndoe/packages" SRCDEST="/home/johndoe/sources" SRCPKGDEST="/home/johndoe/srcpackages" LOGDEST="/home/johndoe/logs" ## Se sua chave PGP não é a padrão, especifique a impressão digital correta: GPGKEY="ABCD1234..."
Desabilite o cache de senha com as seguintes configurações:
gpg-agent.conf
default-cache-ttl 0 max-cache-ttl 0
Como desejaremos manter nosso agente GPG normal em execução com suas configurações atuais, executaremos outro agente GPG dedicado à tarefa em questão. Crie uma pasta ~/.gnupg-archlinux e crie uma ligação simbólica de ~/.gnupg, exceto ~/.gnupg/gpg-agent.conf. Configure o novo agente GPG:
~/.gnupg-archlinux
extra-socket /home/doe/.gnupg-archlinux/S.gpg-agent.extra default-cache-ttl 0 max-cache-ttl 0 pinentry-program /usr/bin/pinentry-gtk-2
O gpg-agent-extra.socket será encaminhado para build.archlinux.org.
Inicie o agente dedicado com:
$ gpg-agent --homedir ~/.gnupg-archlinux --daemon
Conecte-se com:
$ ssh -R $REMOTE_SSH_AUTH_SOCK:$SSH_AUTH_SOCK -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra build.archlinux.org
ou, se estiver usando GnuPG como seu agente SSH, com:
$ ssh -R /run/user/REMOTE_UID/gnupg/S.gpg-agent.ssh:/run/user/LOCAL_UID/gnupg/S.gpg-agent.ssh -R /run/user/REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra build.archlinux.org
Substitua REMOTE_UID e LOCAL_UID pelo seu identificador de usuário como retornado por id -u no servidor de compilação e localmente, respectivamente.
Se estiver usando ssh-agent, substitua REMOTE_SSH_AUTH_SOCK pelo caminho para o soquete SSH no host remoto (pode ser qualquer coisa).
Você pode tornar o encaminhamento permanente para esse host. Por exemplo, com gpg-agent.ssh:
~/.ssh/config
Host build.archlinux.org RemoteForward /run/user/REMOTE_UID/gnupg/S.gpg-agent /run/user/LOCAL_UID/gnupg/S.gpg-agent.extra RemoteForward /run/user/REMOTE_UID/gnupg/S.gpg-agent.ssh /run/user/LOCAL_UID/gnupg/S.gpg-agent.ssh
Novamente, substitua REMOTE_UID com o UID do servidor de compilação.
A partir de então, o procedimento deve ser exatamente igual a uma compilação local:
$ ssh build.archlinux.org $ pkgctl repo clone existing-package $ ...
Lista de TODO na renúncia de um Mantenedor de Pacote
Quando um Mantenedor de Pacote renuncia, a seguinte lista tem que ser seguida -- essas etapas não se aplicam quando um Mantenedor de Pacote renuncia sendo ainda um desenvolvedor.
- Todos os pacotes empacotados pelo TU retirado devem ser resignados (portanto, recompilados). Pacotes empacotados pelo retirado podem ser localizados no Archweb https://archlinux.org/packages/?sort=&q=&empacotador=$empacotador&flagged=, sendo empacotador o nome de usuário no Archweb.
- A conta do renunciado deve ser desabilitada no Archweb e adicionada ao grupo "Retired Package maintainers". O retirado deve ser removido dos "Package Maintainers" e as permissões de repositório devem ser reduzidas a zero.
- O acesso shell a nossos servidores deve ser desabilitado. (especialmente repos.archlinux.org, pkgbuild.com)
- A chave GPG deve ser removida e um novo pacote archlinux-keyring deve ser enviado para os repositórios. Crie um relatório de erro no projeto do chaveiro para remover as chaves dos Mantenedores de Pacote retirados.
- Remova o grupo de Mantenedor de Pacote de suas contas AUR.
- Um bureaucrat deve remover sua conta wiki do grupo Arch Linux Package Maintainers.
- Um administrador do BBS deve mudar sua conta nos fóruns.