Difference between revisions of "AUR Trusted User Guidelines (Español)"

From ArchWiki
Jump to: navigation, search
(El UC y UNSUPPORTED)
Line 39: Line 39:
 
Los UCs deben también revisar en los PKGBUILDs los errores de menor importancia, sugerir correcciones y mejoras.  El UC debe confirmar que todos los pkgs siguen las Guías/Standards de Empaquetado de Arch  y al hacerlo compartir sus conocimientos  con otros empaquetadores en un esfuerzo por elevar el nivel de construcción de paquetes en toda la distribución.
 
Los UCs deben también revisar en los PKGBUILDs los errores de menor importancia, sugerir correcciones y mejoras.  El UC debe confirmar que todos los pkgs siguen las Guías/Standards de Empaquetado de Arch  y al hacerlo compartir sus conocimientos  con otros empaquetadores en un esfuerzo por elevar el nivel de construcción de paquetes en toda la distribución.
  
Los UCs se encuentran en una excelente posición para documentar las pràcticas recomendadas.
+
Los UCs se encuentran en una excelente posición para documentar las prácticas recomendadas.
  
 
===El UC y [community], Guías para Mantenimiento de Paquetes===
 
===El UC y [community], Guías para Mantenimiento de Paquetes===

Revision as of 16:56, 5 December 2009

Tango-preferences-desktop-locale.pngThis article or section needs to be translated.Tango-preferences-desktop-locale.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:AUR Trusted User Guidelines (Español)#)
Summary help replacing me
Explains Arch User Repository's Trusted Users.
Available in languages

Template:I18n entry Template:I18n entry Template:I18n entry

Related articles
AUR Q & A
AUR User Guidelines
AUR

El usuario de confianza (UC)

EL Usuario de confianza (UC) es un miembro de la comunidad encargado de mantener AUR en funcionamiento. El/ella mantiene paquetes populares, los votos y otras cuestiones administrativas. Un UC es elegido por todos los miembros de la comunidad UC en un proceso democrático. La UC son los únicos que tienen la última palabra en la administración de AUR.

Los UC se rigen por el Estatuto UC

Deberes del UC

TODO lista para el nuevo usuario de confianza

  • Instalar el paquete devtools'.
  • Envíar su clave pública ssh public a Loui Chang. Si no tienes una, usa ssh-keygen para generarla. Puedes revisar la página del wiki Using SSH Keys para mas información sobre como crear claves ssh y configurar un cliente-ssh para usar esta.
  • Crear el directorio staging/community dentro de tu carpeta personal en aur.archlinux.org. Este es un paso importante, porque devtools scripts usa este directorio para procesar los paquetes entrantes.
  • Recuerde a Allan a cambiar su cuenta en los foros
  • Asegúrese que su sponsor le ha dado estado de UC en AUR
  • Pregunte a algunos UC por el canal #archlinux-tu@freenode key
  • Agregarse a la página Usuarios de Confianza
  • Lea la Guía de usuarios de confianza.
  • Si no se actualizan a un grupo de usuarios de confianza en bugtracker en dos días, informe esto como un error a Roman
  • ¡Empiece a contribuir!

El UC y UNSUPPORTED

Los UCs deberían hacer un esfuerzo para revisar los paquetes agregados en UNSUPPORTED en busca de código malicioso y respeto de los standards en la construcción de los PKGBUILD. Alrededor del 80% de los casos de PKGBUILDs en UNSUPPORTED son muy sencillos y puede revisarse rápidamente la coherencia y el código malicioso por el equipo de UC.

Los UCs deben también revisar en los PKGBUILDs los errores de menor importancia, sugerir correcciones y mejoras. El UC debe confirmar que todos los pkgs siguen las Guías/Standards de Empaquetado de Arch y al hacerlo compartir sus conocimientos con otros empaquetadores en un esfuerzo por elevar el nivel de construcción de paquetes en toda la distribución.

Los UCs se encuentran en una excelente posición para documentar las prácticas recomendadas.

El UC y [community], Guías para Mantenimiento de Paquetes

Reglas para paquetes que entren al [community] Repo

Any packages to be added to the [community] repo must meet the guidelines listed on this page.

Accessing and Updating the Repository

The [community] repository now uses devtools which is the same system used for uploading packages to [core] and [extra], except that it uses another server http://aur.archlinux.org instead of http://archlinux.org. Thus most of the instructions in Packager Guide work without any change. Information which is specific for the [community] repository (like changed URLs) have been put here.

Initially you should do a non-recursive checkout of the [community] repository:
svn checkout -N svn+ssh://aur.archlinux.org/srv/svn-packages

This creates a directory named "svn-packages" which contains nothing. It does, however, know that it is an svn checkout.

For checking out, updating all packages or adding a package see the Packager Guide.

To remove a package
ssh aur.archlinux.org /arch/db-remove community pkgname arch

Here and in the following text, arch can be one of i686 or x86_64 which are the two architectures supported by Arch Linux.

When you're done with editing the PKGBUILD, etc, you should commit the changes (svn commit).
When you want to release a package, first copy the package to the staging/community directory on aur.archlinux.org using scp and then tag the package by going to the pkgname/trunk directory and issuing archrelease community-arch.

This makes an svn copy of the trunk entries in a directory named community-i686 or community-x86_64 indicating that this package is in the community repository for that architecture.

Note: In some cases, especially for community packages, an x86_64 TU might bump the pkgrel by .1 (and not +1). This indicates that the change to the PKGBUILD is x86_64 specific and i686 maintainers should not rebuild the package for i686. When the TU decides to bump the pkgrel , it should be done with the usual increment of +1. However, a previous pkgrel=2.1 must not become pkgrel=3.1 when bumped by the TU and must instead be pkgrel=3. In a nutshell, leave dot (.) releases exclusive to the x86_64 TU's to avoid confusion.

Thus the process of updating a package can be summarised as

  • Update the package directory (svn update some-package)
  • Change to the package trunk directory (cd some-package/trunk)
  • Edit the PKGBUILD, make necessary changes and makepkg. It is recommended to build in a clean chroot.
  • Namcap the PKGBUILD and the binary pkg.tar.gz.
  • Commit the changes to trunk (svn commit)
  • Copy the package to aur.archlinux.org (scp pkgname-ver-rel-arch.pkg.tar.gz aur.archlinux.org:staging/community/)
  • Tag the package (archrelease community-{i686,x86_64})
  • Update the repository (ssh aur.archlinux.org /arch/db-community{,64})

Also see the Miscellaneous section in the Packager Guide. For the section Avoid having to enter your password all the time use aur.archlinux.org instead of archlinux.org and svn.archlinux.org.

Disowning packages

If a TU can't or doesn't want to maintain a package any longer, a notice should be posted to the AUR Mailing List, so another TU can maintain it. A package can still be disowned even if no other TU wants to maintain it, but the TUs should try not to drop many packages (they shouldn't take on more than they have time for). If a package has become obsolete or isn't used any longer, it can be removed completely as well.

If a package has been removed completely, it can be uploaded once again (fresh) to UNSUPPORTED, where a regular user can maintain the package instead of the TU.

Deleting packages from unsupported

There's no point in removing dummy packages, because they will be re-created in an attempt to track dependencies. If someone uploads a real package then all dependents will point to the correct place.

For an example of a dummy package see: http://aur.archlinux.org/packages.php?ID=23600

Moving packages from [community] to unsupported

Remove the package using the instructions above and upload your source tarball to the AUR.