Difference between revisions of "AUR Trusted User Guidelines (Português)"

From ArchWiki
Jump to: navigation, search
(aur.archlinux.org -> sigurd.archlinux.org rename)
m (Use translated template)
 
(12 intermediate revisions by 5 users not shown)
Line 2: Line 2:
 
[[en:AUR Trusted User Guidelines]]
 
[[en:AUR Trusted User Guidelines]]
 
[[es:AUR Trusted User Guidelines]]
 
[[es:AUR Trusted User Guidelines]]
[[zh-CN:AUR Trusted User Guidelines]]
+
[[ja:AUR Trusted User ガイドライン]]
{{Article summary start}}
+
[[zh-hans:AUR Trusted User Guidelines]]
{{Article summary text|Explica as diretrizes dos Trusted Users do Arch User Repository.}}
+
{{Related articles start (Português)}}
{{Article summary heading|Relacionado}}
+
{{Related|Arch User Repository (Português)}}
{{Article summary wiki|Arch User Repository}}
+
{{Related articles end}}
{{Article summary end}}
+
O '''Trusted User (TU)''' ("Usuário confiado") é um membro da comunidade encarregado de manter o AUR funcionando. Ele/Ela mantém pacotes populares ([https://mailman.archlinux.org/pipermail/aur-general/2010-September/010649.html 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.
 
 
O '''Trusted User (TU)''' ("Usuário confiável") é um membro da comunidade encarregado de manter o AUR funcionando. Ele/Ela mantém pacotes populares ([https://mailman.archlinux.org/pipermail/aur-general/2010-September/010649.html 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 [https://aur.archlinux.org/trusted-user/TUbylaws.html TU bylaws] ("Estatuto dos TUs")
 
Os TUs são governados usando as [https://aur.archlinux.org/trusted-user/TUbylaws.html TU bylaws] ("Estatuto dos TUs")
Line 16: Line 14:
 
# Ler este artigo de wiki por completo.
 
# Ler este artigo de wiki por completo.
 
# Ler as [https://aur.archlinux.org/trusted-user/TUbylaws.html TU Bylaws].
 
# Ler as [https://aur.archlinux.org/trusted-user/TUbylaws.html TU Bylaws].
# Certificar-se de que os detalhes da sua conta no [[Arch User Repository|AUR]] estão atualizados e que seu patrocinador tenha lhe concedido o status de TU.
+
# Certificar-se de que os detalhes da sua conta no [[AUR (Português)|AUR]] estejam atualizados e que seu patrocinador tenha lhe concedido o status de TU.
 
# Adicionar a si próprio à página de [[Trusted Users]].
 
# Adicionar a si próprio à página de [[Trusted Users]].
# Relembrar Allan/Andrea de alterar sua conta nos fóruns.
+
# Se inscrever na lista de discussão pública de desenvolvimento do Arch Linux, [https://lists.archlinux.org/listinfo/arch-dev-public arch-dev-public].
 +
# Lembrar um [https://bbs.archlinux.org/userlist.php?username=&show_group=1&sort_by=username&sort_dir=ASC&search=Submit administrador do BBS] de alterar sua conta nos fóruns.
 
# Perguntar a algum TU pela chave do #archlinux-tu@freenode e aparecer 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.
 
# Perguntar a algum TU pela chave do #archlinux-tu@freenode e aparecer 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ê ainda não fizer parte do grupo de Trusted User no bug tracker em dois dias, relate isso como um bug para Andrea Scarpino (andrea@archlinux.org).
+
# Criar uma chave PGP para [[package signing|assinatura de pacotes]] ou use 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.
# Envie ao Ionuț Bîru (ibiru@archlinux.org) todas as informações baseadas neste [https://www.archlinux.org/trustedusers/ modelo] para ter acesso à interface de desenvolvimento.
+
# Enviar ao Ionuț Bîru (ibiru@archlinux.org) oru ao Florian Pritz (bluewind@xinu.at) um e-mail com todas as informações baseadas neste [https://www.archlinux.org/trustedusers/ modelo] para ter acesso à interface de desenvolvimento (archweb).
# Instalar o pacote {{pkg|devtools}}.
+
# Enviar um e-mail assinado para o Florian:
# Enviar um e-mail para o Lukas Fleischer contendo uma chave pública de SSH em anexo. Se você não tiver uma, use {{ic|ssh-keygen}} para criar uma. Verifique na página wiki [[Using SSH Keys]] para mais informações sobre chaves SSH.
+
#* Anexe uma chave pública SSH. Se você não possuir uma, use {{ic|ssh-keygen}} para gerar uma. Verifique na página wiki [[Using SSH Keys]] para mais informações sobre chaves SSH.
# Criar uma chave PGP para [[package signing|assinatura de pacotes]].
+
#* Solicitar que ele lhe dê permissão à arch-dev-public.
# Enviar um e-mail assinado digitalmente para todos os [http://www.archlinux.org/master-keys/ donos de Chaves Mestras] incluindo sua chave PGP e a impressão digital da chave completa relacionada. Sua chave precisa estar assinada por pelo menos três dos cinco titulares de chaves mestras.
+
#* Façar para ele se você deseja um e-mail @archlinux.org.
# Criar os diretórios {{ic|~/staging/community}} e {{ic|~/staging/community-testing}} (e {{ic|~/staging/multilib}}, se você está interessado em manter pacotes multilib) no sigurd.archlinux.org. Essa etapa é '''importante''', pois os scripts do devtools usam este diretório para processar a chegada de pacotes.
+
# 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 sintruções [https://lists.archlinux.org/pipermail/arch-dev-public/2013-September/025456.html nesta mensagem] na ordem de ter sua chave PGP assinado pelos três detentores de chave mestre.
 +
# Instale o pacote {{pkg|devtools}}.
 +
# [[Arch_User_Repository (Português)#Autenticação|Configurar sua chave privada ssh]] para os servidores {{ic|orion.archlinux.org}} e {{ic|repos.archlinux.org}}.
 +
# Teste a conexão SSH para seunome@orion.archlinux.org (assim que você tiver permissões).
 +
# Se você não for acrescentado 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!
 
# Começar a contribuir!
  
 
==O TU e o [unsupported]==
 
==O TU e o [unsupported]==
  
Os TUs deveriam também fazer um esforço para verificar o envio de pacotes no UNSUPPORTED por códigos maliciosos e o correto seguimento dos padrões dos PKGBUILD. Em cerca de 80% dos casos, os PKGBUILDs no UNSUPPORTED são muito simples e podem ter rapidamente verificadas a sanidade e os códigos maliciosos pela equipe de TUs.
+
Os TUs deveriam também fazer um esforço para verificar o envio de pacotes no UNSUPPORTED por códigos maliciosos e o correto seguimento dos padrões dos PKGBUILD. Em cerca de 80% dos casos, os PKGBUILDs no UNSUPPORTED 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 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.
Line 40: Line 45:
  
 
=== Regras para a Entrada de Pacotes no Repositório [community] ===
 
=== Regras para a Entrada de Pacotes no Repositório [community] ===
 +
 +
* 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 [https://mailman.archlinux.org/mailman/listinfo/aur-general aur-general], pesquise [https://bugs.archlinux.org/index.php?project=0&do=index&switch=1 todos os projetos no rastreador de erro], use [[wikipedia:Grep|grep]] no [http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.log.html log do Subversion] e envie uma mensagem rápida para o [[IRC channel|canal IRC]] privado de TUs.
  
 
* Somente pacotes "populares" podem entrar no repositório, sendo definido pelo 1% de uso no [https://www.archlinux.de/?page=PackageStatistics pkgstats] ou 10 votos no AUR.
 
* Somente pacotes "populares" podem entrar no repositório, sendo definido pelo 1% de uso no [https://www.archlinux.de/?page=PackageStatistics pkgstats] ou 10 votos no AUR.
  
 
* Exceções automáticas a esta regra são:
 
* Exceções automáticas a esta regra são:
** pacotes i18n
+
** pacotes de internacionalização (i18n)
 
** pacotes de acessibilidade
 
** pacotes de acessibilidade
 
** drivers
 
** drivers
** dependências de pacotes que satisfazem a definição de populares, incluindo makedeps e optdeps
+
** 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 distribuidos juintos, fornecendo uma parte da coleção satisfaz a definição de popular
+
** 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 [community]. Adições propostas por TUs com grande número de pacotes "não-populares" provavelmente serão rejeitadas.
 
* 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 [community]. Adições propostas por TUs com grande número de pacotes "não-populares" provavelmente serão rejeitadas.
  
* Os TUs são fortemente encorajados a mover os pacotes mantidos do [community], se eles tem baixo uso. Nenhuma aplicação será necessária, apesar de que a renúncia de pacotes de TUs podem ser filtrados antes que ocorra adoção.
+
* Os TUs são incentivados a mover os pacotes mantidos do [community], 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 ===
 
=== Acessando e Atualizando o Repositório ===
 
          
 
          
O repositório [community] agora usa '''devtools''', que é o mesmo sistema usado para enviar pacotes para o [core] e [extra], apesar de usar outro servidor {{ic|sigurd.archlinux.org}} ao invés de {{ic|gerolde.archlinux.org}}. Por isso, a maioria das instruções no [[DeveloperWiki:HOWTO Be A Packager|Guia do Empacotador]] funciona sem qualquer outro comentário. Informações que são específicas para o repositório [community] (como URLs alteradas) foram inseridas aqui. O devtools exige dos empacotadores a [[Arch_Build_System#Set_the_PACKAGER_variable_in_.2Fetc.2Fmakepkg.conf|definição da variável PACKAGER]]. Isso é feito no {{ic|/usr/share/devtools/makepkg-{i686,x86_64}.conf}} já que o arquivo de configuração padrão não é colocado em um chroot do zero.
+
O repositório [community] agora usa '''devtools''', que é o mesmo sistema usado para enviar pacotes para o [core] e [extra], apesar de usar outro servidor {{ic|nymeria.archlinux.org}} ao invés de {{ic|gerolde.archlinux.org}}. Por isso, a maioria das instruções no [[DeveloperWiki:HOWTO Be A Packager|Guia do Empacotador]] funciona sem qualquer outro comentário. Informações que são específicas para o repositório [community] (como URLs alteradas) foram inseridas aqui. O devtools exige que os empacotadores [[Makepkg#Packager_information|definam a variável PACKAGER]] no {{ic|makepkg.conf}}.
 +
 
 +
Inicialmente, você deve fazer um '''checkout não-recursivo''' do repositório [community]: <nowiki>svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community</nowiki>
  
Inicialmente, você deveria fazer um '''checkout não-recursivo''' do repositório [community]:
+
Isso cria um diretório chamado "svn-community" contendo nada, além de uma pasta ".svn".
svn checkout -N svn+ssh://sigurd.archlinux.org/srv/svn-packages
 
  
Isso cria um diretório chamado "svn-packages", o qual contém nada. Ele, na verdade, sabe que é um checkout de svn.
+
Para realizar '''checkout''', '''atualizar''' todos os pacotes ou '''adicionar''' um pacote, veja o [[DeveloperWiki:HOWTO Be A Packager|Guia do Empacotador]].
  
Para fazer '''checkout''', '''update''' em todos pacotes ou '''add''' de um pacote, veja o [[DeveloperWiki:HOWTO Be A Packager|Guia do empacotador]].
+
Para '''remover''' um pacote:
 +
ssh orion.archlinux.org /community/db-remove community arch pkgname
  
Para fazer '''remove''' de um pacote:
+
Aqui e no texto seguinte, ''arch'' pode ser ''i686'' ou ''x86_64'', que são as duas arquiteturas às quais o Arch Linux oferece suporte.
ssh sigurd.archlinux.org /arch/db-remove community arch pkgname
+
{{Note|Se você está editando pacotes da arquitetura ''any'', você pode executar os scripts x64 que também vão funcionar.}}
  
Aqui e no texto seguinte, a arquitetura pode ser i686 ou x86_64, as quais são as duas arquiteturas suportadas pelo Arch Linux. (E sobre "any"?)
+
Quando você tiver finalizado a edição do PKGBUILD, etc, você deve fazer um '''commit''' das alterações ({{ic|svn commit}}).
  
Quando você tiver finalizado a edição do PKGBUILD, etc, você deveria fazer um '''commit''' das alterações ({{ic|svn commit}}).
+
Compile o pacote com {{ic|mkarchroot}} ou os scripts auxiliares {{ic|extra-i686-build}} e {{ic|extra-x86_64-build}}. Se você deseja enviar para ''testing'', você também precisará compilar com os scripts de teste {{ic|testing-i686-build}} e {{ic|testing-x86_64-build}}.
  
Quando você quiser enviar ('''release''') um pacote, primeiro copie o pacote para o diretório ''staging/community'' no sigurd.archlinux.org usando scp e, então, marque ('''tag''') o pacote no diretório ''pkgname/trunk'' e informando a {{ic|archrelease community-arch}}. Isso faz uma cópia svn das entradas do trunk em um diretório chamado ''community-i686'' ou ''community-x86_64''. indicando que este pacote está no repositório [community] para aquela arquitetura.
+
Assine o pacote com {{ic|gpg --detach-sign *.pkg.tar.xz}}. Se você está usando uma chave PGP diferente para assinatura de pacote, você pode adicioná-la ao {{ic|~/.makepkg.conf}} com {{ic|1=GPGKEY=<identifier>}}.
  
'''''Nota:''' Em alguns casos, especialmente para pacotes do [community], um TU de x86_64 podem subir o pkgrel por .1 (e não por +1). Isso indica que a alteração do PKGBUILD é especificamente de x86_64 e mantenedores de i686 '''não deveriam''' recompilar o pacote para i686. Quando o TU decide subir o pkgrel, isso deveria ser feito com o acréscimo normal de +1. Porém, um pkgrel=2.1 anterior não deve se tornar pkgrel=3.1 quando o TU subir o pkgrel, ao invés disso deve ser pkgrel=3. Em resumo, mantenha os lançamentos com ponto (.) exclusivamente para TUs de x86_64 para evitar confusão.''
+
Quando você quiser publicar ('''release''') um pacote, primeiro copie o pacote junto com sua assinatura para o diretório ''staging/community'' no ''orion.archlinux.org'' usando {{ic|scp}} e, então, marque ('''tag''') o pacote no diretório ''pkgname/trunk'' e chamando {{ic|archrelease community-arch}}. Isso faz uma cópia svn das entradas do trunk em um diretório chamado ''community-i686'' ou ''community-x86_64'' indicando que este pacote está no repositório ''community'' para aquela arquitetura. Note que o diretório ''staging'' é diferente do repositório ''staging'' e todo pacote precisa ser enviado para o diretório ''staging''. Esse processo pode ser automatizado com o script {{ic|communitypkg}}. Veja o resumo abaixo.
  
Deste modo, o '''processo''' de atualização de pacotes pode ser resumida em:
+
'''''Nota:''' Em alguns casos, especialmente para pacotes do [community], um TU de x86_64 pode incrementar o pkgrel por .1 (e não por +1). Isso indica que a alteração do PKGBUILD é especificamente de x86_64 e mantenedores de i686 '''não devem''' recompilar o pacote para i686. Quando o TU decide incrementar o pkgrel, isso deveria ser feito com o acréscimo normal de +1. Porém, um pkgrel=2.1 anterior não deve se tornar pkgrel=3.1 quando incrementado pelo TU e deve ser pkgrel=3. Em resumo, mantenha os lançamentos com ponto (.) exclusivamente para TUs de x86_64 para evitar confusão.''
 +
 
 +
''''Resumo da atualização de pacote:'''
  
 
* '''Atualizar''' o diretório de pacote ({{ic|svn update algum-pacote}})
 
* '''Atualizar''' o diretório de pacote ({{ic|svn update algum-pacote}})
 
* '''Mudar''' para o diretório trunk do pacote ({{ic|cd algum-pacote/trunk}})
 
* '''Mudar''' para o diretório trunk do pacote ({{ic|cd algum-pacote/trunk}})
* '''Editar''' o PKGBUILD, fazer alterações necessárias e {{ic|makepkg}}. Isso é recomendado para compilar em um [[DeveloperWiki:Building in a Clean Chroot|chroot limpo]].
+
* '''Editar''' o PKGBUILD, fazer alterações necessárias, atualizar o checksums com {{ic|updpkgsums}}.
* '''[[Namcap]]''' no PKGBUILD e no binário pkg.tar.gz.
+
* '''Compilar''' o pacote: com {{ic|makechrootpkg}} ou {{ic|extra-i686-build}} e {{ic|extra-x86_64-build}}. É '''obrigatório''' compilar em um [[DeveloperWiki:Building in a Clean Chroot|''chroot'' limpo]].
 +
* '''[[Namcap]]''' no PKGBUILD e no binário {{ic|pkg.tar.gz}}.
 
* '''Commit''', '''Copiar''' e '''Tag''' o pacote usando {{ic|communitypkg "mensagem de commit"}}.  Isso automatiza o seguinte:
 
* '''Commit''', '''Copiar''' e '''Tag''' o pacote usando {{ic|communitypkg "mensagem de commit"}}.  Isso automatiza o seguinte:
** '''Commit''' das alterações no trunk ({{ic|svn commit}})
+
** Fazer '''commit''' das alterações no trunk: {{ic|svn commit}}.
** '''Copiar''' o pacote para o sigurd.archlinux.org ({{ic|scp pkgname-ver-rel-arch.pkg.tar.xz* sigurd.archlinux.org:staging/community/}})
+
** '''Assinar''' o pacote: {{ic|gpg --detach-sign *.pkg.tar.xz}}.
** '''Tag''' do pacote ({{ic|archrelease community-{i686,x86_64}}})
+
** '''Copiar''' o pacote e sua assinatura para ''orion.archlinux.org'': {{ic|scp *.pkg.tar.xz *.pkg.tar.xz.sig orion.archlinux.org:staging/community/}}.
* '''Atualizar''' o repositório ({{ic|ssh aur.archlinux.org /arch/db-update}})
+
** Aplicar um '''tag''' do pacote: {{ic|archrelease community-{i686,x86_64}}}.
 +
* '''Atualizar''' o repositório: {{ic|ssh orion.archlinux.org /community/db-update}}.
  
Veja também a seção de ''Miscelânia'' no [[DeveloperWiki:HOWTO Be A Packager|Guia do Empacotador]]. Para a seção ''Avoid having to enter your password all the time'' ("evite de precisar digitar sua senha toda vez") uso sigurd.archlinux.org ao invés do gerolde.archlinux.org.
+
Veja também a seção de ''Miscelânia'' no [[DeveloperWiki:HOWTO Be A Packager|Guia do Empacotador]] and [[SSH keys#ssh-agent]]. Para a seção ''Avoid having to enter your password all the time'' ("evite de precisar digitar sua senha toda vez"), use ''orion.archlinux.org'' em vez do ''gerolde.archlinux.org''.
  
 
=== Abandonando pacotes ===
 
=== Abandonando pacotes ===
Line 105: Line 120:
 
=== Movendo pacotes do [community-testing] para [community] ===
 
=== Movendo pacotes do [community-testing] para [community] ===
  
  ssh sigurd.archlinux.org /arch/db-move community-testing community package
+
  ssh nymeria.archlinux.org /arch/db-move community-testing community package
  
 
=== Excluindo pacotes do unsupported ===
 
=== Excluindo pacotes do unsupported ===
 
+
Não há sentido em remover pacotes-modelos, porque eles serão recriados na tentativa de atender dependências. Se alguém enviar um pacote real, então todos os dependentes irão apontar para o local correto.
Não há sentido em remover pacotes-modelos porque eles serão recriados na tentativa de atender dependências. Se alguém enviar um pacote real, então todos os dependentes irão apontar para o local correto.
 
  
 
=== Veja também ===
 
=== Veja também ===
* [[DeveloperWiki#Packaging_Guidelines | Diretrizes de Empacotamento]]
+
* [[DeveloperWiki#Packaging Guidelines|Diretrizes de Empacotamento]]

Latest revision as of 16:42, 31 May 2017

Artigos relacionados

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

  1. Ler este artigo de wiki por completo.
  2. Ler as TU Bylaws.
  3. Certificar-se de que os detalhes da sua conta no AUR estejam atualizados e que seu patrocinador tenha lhe concedido o status de TU.
  4. Adicionar a si próprio à página de Trusted Users.
  5. Se inscrever na lista de discussão pública de desenvolvimento do Arch Linux, arch-dev-public.
  6. Lembrar um administrador do BBS de alterar sua conta nos fóruns.
  7. Perguntar a algum TU pela chave do #archlinux-tu@freenode e aparecer 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.
  8. Criar uma chave PGP para assinatura de pacotes ou use 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.
  9. Enviar ao Ionuț Bîru (ibiru@archlinux.org) oru ao Florian Pritz (bluewind@xinu.at) um e-mail com todas as informações baseadas neste modelo para ter acesso à interface de desenvolvimento (archweb).
  10. Enviar um e-mail assinado para o Florian:
    • Anexe uma chave pública SSH. Se você não possuir uma, use ssh-keygen para 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.
    • Façar para ele se você deseja um e-mail @archlinux.org.
  11. 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 sintruções nesta mensagem na ordem de ter sua chave PGP assinado pelos três detentores de chave mestre.
  12. Instale o pacote devtools.
  13. Configurar sua chave privada ssh para os servidores orion.archlinux.org e repos.archlinux.org.
  14. Teste a conexão SSH para seunome@orion.archlinux.org (assim que você tiver permissões).
  15. Se você não for acrescentado a um grupo de Trusted User no rastreador de erro em dois dias, relate isso como um bug para arch-dev-public.
  16. Começar a contribuir!

O TU e o [unsupported]

Os TUs deveriam também fazer um esforço para verificar o envio de pacotes no UNSUPPORTED por códigos maliciosos e o correto seguimento dos padrões dos PKGBUILD. Em cerca de 80% dos casos, os PKGBUILDs no UNSUPPORTED 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.

O TU e [community], Diretrizes para Manutenção de Pacotes

Regras para a Entrada de Pacotes no Repositório [community]

  • 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.
  • 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 [community]. 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 [community], 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

O repositório [community] agora usa devtools, que é o mesmo sistema usado para enviar pacotes para o [core] e [extra], apesar de usar outro servidor nymeria.archlinux.org ao invés de gerolde.archlinux.org. Por isso, a maioria das instruções no Guia do Empacotador funciona sem qualquer outro comentário. Informações que são específicas para o repositório [community] (como URLs alteradas) foram inseridas aqui. O devtools exige que os empacotadores definam a variável PACKAGER no makepkg.conf.

Inicialmente, você deve fazer um checkout não-recursivo do repositório [community]: svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community

Isso cria um diretório chamado "svn-community" contendo nada, além de uma pasta ".svn".

Para realizar checkout, atualizar todos os pacotes ou adicionar um pacote, veja o Guia do Empacotador.

Para remover um pacote:

ssh orion.archlinux.org /community/db-remove community arch pkgname

Aqui e no texto seguinte, arch pode ser i686 ou x86_64, que são as duas arquiteturas às quais o Arch Linux oferece suporte.

Note: Se você está editando pacotes da arquitetura any, você pode executar os scripts x64 que também vão funcionar.

Quando você tiver finalizado a edição do PKGBUILD, etc, você deve fazer um commit das alterações (svn commit).

Compile o pacote com mkarchroot ou os scripts auxiliares extra-i686-build e extra-x86_64-build. Se você deseja enviar para testing, você também precisará compilar com os scripts de teste testing-i686-build e testing-x86_64-build.

Assine o pacote com gpg --detach-sign *.pkg.tar.xz. Se você está usando uma chave PGP diferente para assinatura de pacote, você pode adicioná-la ao ~/.makepkg.conf com GPGKEY=<identifier>.

Quando você quiser publicar (release) um pacote, primeiro copie o pacote junto com sua assinatura para o diretório staging/community no orion.archlinux.org usando scp e, então, marque (tag) o pacote no diretório pkgname/trunk e chamando archrelease community-arch. Isso faz uma cópia svn das entradas do trunk em um diretório chamado community-i686 ou community-x86_64 indicando que este pacote está no repositório community para aquela arquitetura. Note que o diretório staging é diferente do repositório staging e todo pacote precisa ser enviado para o diretório staging. Esse processo pode ser automatizado com o script communitypkg. Veja o resumo abaixo.

Nota: Em alguns casos, especialmente para pacotes do [community], um TU de x86_64 pode incrementar o pkgrel por .1 (e não por +1). Isso indica que a alteração do PKGBUILD é especificamente de x86_64 e mantenedores de i686 não devem recompilar o pacote para i686. Quando o TU decide incrementar o pkgrel, isso deveria ser feito com o acréscimo normal de +1. Porém, um pkgrel=2.1 anterior não deve se tornar pkgrel=3.1 quando incrementado pelo TU e deve ser pkgrel=3. Em resumo, mantenha os lançamentos com ponto (.) exclusivamente para TUs de x86_64 para evitar confusão.

'Resumo da atualização de pacote:

  • Atualizar o diretório de pacote (svn update algum-pacote)
  • Mudar para o diretório trunk do pacote (cd algum-pacote/trunk)
  • Editar o PKGBUILD, fazer alterações necessárias, atualizar o checksums com updpkgsums.
  • Compilar o pacote: com makechrootpkg ou extra-i686-build e extra-x86_64-build. É obrigatório compilar em um chroot limpo.
  • Namcap no PKGBUILD e no binário pkg.tar.gz.
  • Commit, Copiar e Tag o pacote usando communitypkg "mensagem de commit". Isso automatiza o seguinte:
    • Fazer commit das alterações no trunk: svn commit.
    • Assinar o pacote: gpg --detach-sign *.pkg.tar.xz.
    • Copiar o pacote e sua assinatura para orion.archlinux.org: scp *.pkg.tar.xz *.pkg.tar.xz.sig orion.archlinux.org:staging/community/.
    • Aplicar um tag do pacote: archrelease community-{i686,x86_64}.
  • Atualizar o repositório: ssh orion.archlinux.org /community/db-update.

Veja também a seção de Miscelânia no Guia do Empacotador and SSH keys#ssh-agent. Para a seção Avoid having to enter your password all the time ("evite de precisar digitar sua senha toda vez"), use orion.archlinux.org em vez do gerolde.archlinux.org.

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 UNSUPPORTED, onde um usuário normal pode manter o pacote ao invés de um TU.

Movendo pacotes do unsupported para [community]

Siga os procedimentos normais para adição de um pacote ao [community], mas lembre-se de remover o pacote correspondente do unsupported!

Movendo pacotes do [community] para unsupported

Remova o pacote usando as instruções acima e envie o seu tarball fonte para o AUR.

Movendo pacotes do [community-testing] para [community]

ssh nymeria.archlinux.org /arch/db-move community-testing community package

Excluindo pacotes do unsupported

Não há sentido em remover pacotes-modelos, porque eles serão recriados na tentativa de atender dependências. Se alguém enviar um pacote real, então todos os dependentes irão apontar para o local correto.

Veja também