AUR Trusted User guidelines (Português)
O Trusted User (TU) ("Usuário confiado") é um membro da comunidade encarregado de manter o AUR funcionando. Ele/Ela mantém pacotes populares (comunicando com o upstream e enviando-o patches quando necessário) e vota em assuntos administrativos. Um TU é eleito de membros ativos da comunidade pelos atuais TUs em um processo democrático. TUs são os únicos membros que têm a última palavra na direção do AUR.
Os TUs são governados usando as TU bylaws ("Estatuto dos TUs")
Lista de tarefas para novos Trusted Users
- Ler este artigo de wiki por completo.
- Ler as TU Bylaws.
- Certificar-se de que os detalhes da sua conta no AUR estejam atualizados.
- Adicionar a si próprio à página de Trusted Users.
- Se inscrever na lista de discussão pública de desenvolvimento do Arch Linux, arch-dev-public.
- Solicitar inscrição à lista de discussão interna de trusted user.
- Lembrar um administrador do BBS de alterar sua conta nos fóruns.
- Perguntar a algum TU pela chave do #archlinux-tu e se fazer presente no canal. Você não tem que fazer isso, mas seria interessante já que é lá que a maioria dos segredos ocultos são apresentados e é onde muitas novas ideias são concebidas.
- Se você precisar de um bouncer, peça ao heftig por um convite de Matrix ou execute
givemequasselno servidor soyuz.archlinux.org, então autentique-se usando Quassel. - Uma vez no canal, se você quiser uma manta de @archlinux/trusteduser/*, peça ao nosso contato no grupo, ioni, para obter uma.
- Se você precisar de um bouncer, peça ao heftig por um convite de Matrix ou execute
- Criar uma chave PGP para assinatura de pacotes ou usar sua chave PGP existente. Certifique-se de que a chave também contém uma subchave criptográfica de forma você possa receber tokens de verificação criptografados.
- Enviar um e-mail assinado para Jelle van der Waa (jelle@vdwaa.nl):
- Anexar uma chave pública SSH. Se você não possuir uma, use
ssh-keygenpara gerar uma. Verifique na página wiki Using SSH Keys para mais informações sobre chaves SSH. - Solicitar que ele lhe dê permissão à arch-dev-public.
- Falar para ele se você deseja um e-mail @archlinux.org.
- Nome de usuário e endereço de e-mail preferidos cuja senha inicial deve ser enviada para ter acesso na interface dev (archweb). Se você já tem uma conta, peça para ser adicionado ao grupo de Trusted Users.
- Anexar uma chave pública SSH. Se você não possuir uma, use
- Pedir a seu patrocinador (sponsor):
- para lhe conceder o status de TU no AUR.
- para abrir uma nova tarefa no projeto "Keyring" do rastreador de erro seguindo as instruções nesta mensagem na ordem de ter sua chave PGP assinado pelos três detentores de chave mestre.
- Instalar o pacote devtools.
- Configurar sua chave privada ssh para os servidores
orion.archlinux.orgerepos.archlinux.org. - Testar a conexão SSH para seunome@orion.archlinux.org (assim que você tiver permissões).
- Se você não for promovido a um grupo de Trusted User no rastreador de erro em dois dias, relate isso como um bug para arch-dev-public.
- Começar a contribuir!
O TU e o AUR
Os TUs 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 TUs.
Os TUs devem também verificar os PKGBUILDs por pequenos erros, sugerir correções e melhoras. O TU 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 TUs 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 real 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). Veja [1] para detalhes.
- Modificar a identidade do committer ou autor
Use git filter-branch --env-filter com as variáveis de ambiente GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME and 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.O TU 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 todos os projetos no rastreador de erro, use grep no log do Subversion e envie uma mensagem rápida para o canal IRC privado de TUs.
- Wrappers do pacman, como uma exceção especial, nunca serão permitidos. Se desejar adicionar um auxiliar 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 TUs é necessário para que o pacote seja aceito na [extra]. Adições propostas por TUs com grande número de pacotes "não-populares" provavelmente serão rejeitadas.
- Os TUs 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 TUs 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 DeveloperWiki:HOWTO Be A Packager.
Abandonando pacotes
Se um TU 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 TU possa mantê-lo. Um pacote pode ainda ser abandonado mesmo se nenhum outro TU quiser mantê-lo, mas os TUs 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 TU.
Movendo pacotes do AUR para [extra]
Siga os procedimentos normais para adição de um pacote ao [extra] (DeveloperWiki:HOWTO Be A Packager), mas lembre-se de remover o pacote correspondente do AUR!
Movendo pacotes do [extra] para AUR
Remova o pacote usando as instruções acima e envie o seu tarball fonte para o AUR.
Movendo pacotes do [extra-testing] para [extra]
$ ssh repos.archlinux.org /community/db-move community-testing community <pacote>
Compilação remota no build.archlinux.org
Trusted Users 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 para soyuz 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 em soyuz 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 soyuz 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 soyuz, 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 soyuz. Exportar sua chave público para soyuz, 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 SVN. Você pode configurar um novo par de chaves SSH no servidor (é altamente desencorajado colocar sua chave privada local no soyuz 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 soyuz se você o habilitou anteriormente (ele não está em execução por padrão).
Configure seu ambiente de compilação no soyuz:
~/.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 PKGBUILD.com.
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 soyuz 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 e $LOCAL_UID pelos seus respectivos valores.
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 retirada de um Trusted User
Quando um TU renuncia, a seguinte lista tem que ser seguida -- essas etapas não se aplicam quando um TU renuncia, mas 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 retirado deve ser desabilitada no Archweb e adicionada ao grupo "Retired Trusted users". O retirado deve ser removido dos "Trusted Users" e as permissões de repositório devem ser reduzidas a zero.
- O acesso shell a nossos servidores devem ser desabilitados. (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 Trusted Users retirados.
- Remova o grupo de TU de suas contas AUR.