Arch User Repository (Español)

From ArchWiki

Este artículo o sección necesita ser traducido.

Notas: No updates since 2018, English page has seen multiple changes since. The page in English has been update to reflect the renaming of trusted users to package maintainers. (Discusión en Talk:Arch User Repository (Español)#)
Esta traducción de Arch User Repository fue revisada el 2018-09-21. Si existen cambios puede actualizarla o avisar al equipo de traducción.

Arch User Repository (AUR) es un repositorio promovido por los usuarios de la comunidad de Arch. Este contiene descripciones de los paquetes (PKGBUILD) que le permiten compilar un paquete desde el código fuente con makepkg y luego instalarlo a través de pacman. AUR fue creado para organizar y compartir paquetes nuevos de la comunidad y ayudar a acelerar la inclusión de los paquetes más populares en el repositorio extra. Este documento explica cómo los usuarios pueden acceder y utilizar AUR.

Un buen número de paquetes nuevos que entran en los repositorios oficiales tienen su origen en AUR. En AUR, los usuarios pueden aportar sus propias compilaciones de paquetes (PKGBUILD y los archivos relacionados). La comunidad de AUR tiene la posibilidad de votar a favor o en contra de los paquetes de AUR. Si un paquete llega a ser lo suficientemente popular — siempre que tenga una licencia compatible y la técnica de un buen empaquetado — puede ser introducido en el repositorio extra (directamente accesible por pacman o abs).

Advertencia: Los paquetes contenidos en AUR son producidos por usuarios. Estos PKGBUILD no son oficiales y no han sido exhaustivamente revisados. Cualquier uso de los archivos proporcionados lo es bajo el propio riesgo del usuario.

Para empezar

Los usuarios pueden buscar y descargar PKGBUILDs desde la interfaz Web de AUR. Estos PKGBUILDs se pueden compilar en paquetes instalables usando makepkg, y luego ser instalados con pacman.

  • Asegúrese de que el meta-paquete base-devel esté instalado.
  • Léase #FAQ para obtener respuestas a las preguntas más comunes.
  • Es posible mejorar el proceso de compilación ajustando /etc/makepkg.conf antes de crear paquetes desde AUR. Se puede obtener una mejora significativa en los tiempos de compilación en sistemas con procesadores multicore ajustando la variable MAKEFLAGS, usando múltiples núcleos para compresión o especificando un algoritmo de compresión distinto. También se pueden habilitar optimizaciones para hardware específico a través de la variable CFLAGS. Véase makepkg#Recomendaciones para obtener más información.

Después de haber configurado autentificación SSH, también es posible interactuar con AUR a través de SSH: escriba ssh aur@aur.archlinux.org help para obtener una lista de las órdenes disponibles.

Historia

En un principio, existía ftp://ftp.archlinux.org/incoming, y se contribuía únicamente subiendo el PKGBUILD, los archivos adicionales necesarios y el mismo paquete compilado al servidor. El paquete y los archivos asociados se mantenían allí hasta que un mantenedor de paquetes veía el programa y lo adoptara.

Posteriormente, surgieron los Trusted User Repositories («repositorios de usuarios de confianza»). A algunas personas de la comunidad se les permitía alojar sus propios repositorios para que cualquiera los utilizase. AUR se amplió sobre esta base, con el objetivo de hacerlo más flexible y manejable. De hecho, a los responsables de AUR todavía se les conoce como TU (Trusted Users, usuarios de confianza).

Entre 2015-06-08 y 2015-08-08, AUR hizo la transición de la versión 3.5.1 a la 4.0.0, introduciendo el uso de repositorios Git para publicar los PKGBUILDs. Los paquetes existentes se descartaron, salvo aquellos que sus mantenedores migraron manualmente a la nueva infraestructura.

Repositorios Git para paquetes AUR3

El AUR Archive en GitHub tiene un repositorio para cada paquete que estaba en AUR 3 en el momento de la migración. Por otro lado, existe el repositorio aur3-mirror que proporciona lo mismo.

Instalar y actualizar paquetes

La instalación de paquetes desde AUR es un proceso relativamente simple. En esencia consiste en:

  1. Obtener los archivos para la compilación, incluyendo el PKGBUILD y posiblemente otros archivos necesarios, como unidades para systemd y parches (usualmente no el código mismo).
  2. Verificar que el PKGBUILD y los archivos acompañantes no son maliciosos o de desconfianza.
  3. Ejecutar makepkg en el directorio donde se han colocado los archivos. Esta orden descarga la fuente, compila y empaca el paquete.
  4. Ejecutar pacman -U paquete_generado para instalar el paquete en su sistema.
Nota: AUR no tiene soporte, por lo que es responsabilidad del usuario actualizar paquetes instalados, no de pacman. Si se actualizan paquetes en los repositorios oficiales, deberá reconstruir cualquier paquete de AUR que dependa de esas bibliotecas.

Requisitos previos

Primero, asegúrese de que las herramientas necesarias estén instaladas instalando el meta-paquete base-devel; este meta-paquete incluye a make y otras herramientas necesarias para compilar desde código fuente listadas como dependencias.

Nota: Los paquetes disponibles en AUR asumen que tiene instalado el meta-paquete base-devel.

A continuación, elija un directorio de compilación apropiado. Un directorio de compilación es simplemente una carpeta en la que se construirá el paquete o «se compilará», y puede ser cualquier carpeta. En el ejemplo que se sigue, la carpeta ~/builds será el directorio de compilación.

Obtener los archivos de compilación

Localice el paquete en AUR. Esto se realiza utilizando la función de búsqueda en el recuadro de texto de la parte superior de la página principal de AUR. Al pulsar sobre el nombre de la aplicación en la lista de búsqueda se muestra la página de información sobre el paquete. Lea la descripción para confirmar que este es el paquete deseado, observe la última fecha de actualización del paquete y lea los comentarios.

Existen diferentes métodos para adquirir los archivos de compilación:

  • Clonar el repositorio git que tiene el nombre «Git Clone URL» en los detalles del paquete. Este es el método sugerido, cuya ventaja es que permite obtener actualizaciones para el paquete a través de git pull.
$ git clone https://aur.archlinux.org/nombre_de_paquete.git
  • Descargue una copia, dando click en "Download snapshot" en la categoría "Package Actions" en el lado derecho de su página de AUR, o a través de la terminal:
$ curl -L -O https://aur.archlinux.org/cgit/aur.git/snapshot/nombre_de_paquete.tar.gz
Note: El archivo de copia está comprimido, y debe ser descomprimido (preferentemente en un directorio dedicado a compilaciones de paquetes AUR): tar -xvf nombre_de_paquete.tar.gz
  • Use el espejo de solo lectura archlinux/aur en GitHub, donde cada paquete está localizado en su propia rama. Se recomienda que solo clone una sola rama (el repositorio completo es demasiado grande y el rendimiento sería muy bajo). Puede hacer esto a través de los siguientes métodos:
$ git clone --depth=1 https://github.com/archlinux/aur; cd aur
$ git remote set-branches --add origin nombre_de_paquete
$ git fetch
$ git checkout nombre_de_paquete

Adquiera una clave pública PGP si es necesaria

Revise si un archivo de firma en forma de .sig o .asc forma parte del arreglo de fuentes source del PKGBUILD. Si así es, adquiera una de las claves públicas listadas en el arreglo validpgpkeys del PKGBUILD. Lea makepkg (Español)#Verificación de firmas para más información.

Compilar el paquete

Cambie al directorio que contiene el PKGBUILD del paquete.

$ cd nombre_del_paquete
Advertencia: Verifique cuidadosamente el PKGBUILD, cualquier archivo .install y cualquier otro archivo presente en el repositorio git del paquete, en busca de secuencia de órdenes maliciosas o peligrosas. Si tiene dudas, no compile el paquete, y pregunte en los foros o en la lista de correos. Ya se ha encontrado antes código malicioso en paquetes. [1]

Vea los contenidos de todos los archivos proporcionados. Por ejemplo, para usar el paginador less para ver PKGBUILD ejecute:

$ less PKGBUILD
Sugerencia: Si está actualizando un paquete, es posible que desee ver los cambios desde el último envío.
  • Para ver los cambios desde el último envío utilice git show.
  • Para ver los cambios desde el último envío utilizando vimdiff, ejecute git difftool @~..@ vimdiff. La ventaja de vimdiff es que puede ver todo el contenido de cada archivo junto con los indicadores de lo que ha cambiado.

Construya el paquete. Después de confirmar manualmente el contenido de los archivos, ejecute makepkg como un usuario normal. Algunas opciones útiles:

  • -s/--syncdeps resuelve e instala automáticamente cualquier dependencia con pacman antes de compilar. Si el paquete depende de otros paquetes de AUR, deberá primero instalarlos manualmente.
  • -i/--install instala el paquete si fue compilado correctamente. Esto le permite saltar el siguiente paso, que usualmente se realiza manualmente.
  • -r/--rmdeps elimina las dependencias de compilación después de la compilación, pues ya no son necesarias. Sin embargo, es posible que estas dependencias tengan que reinstalarse la próxima vez que se actualice el paquete.
  • -c/--clean limpia los archivos de compilación temporales después de la compilación, pues ya no son necesarios. Estos archivos generalmente solo se necesitan al depurar el proceso de compilación.
Tip: Use git clean -dfX para borrar los archivos ignorados por git, así borrando todos los archivos compilados si el proyecto los ignora.

Instale el paquete

Ahora puede instalar el paquete con pacman:

# pacman -U nombre_de_paquete-versión-arquitectura.pkg.tar.zst
Nota:
  • Si realizó cambios en PKGEXT en makepkg.conf, el nombre del paquete podría ser ligeramente diferente.
  • El ejemplo anterior es solo un breve resumen del proceso de compilación. Se recomienda encarecidamente que lea los artículos makepkg (Español) y ABS (Español) para obtener más información.

Actualización de paquetes

En el directorio que contiene el PKGBUILD del paquete, debe actualizar los archivos y cambios con la orden

$ git pull

y seguir de nuevo las instrucciones de compilación e instalación.

Estado de cuentas

Suspensión

Cuando un usuario de confianza edita a un usuario, puede editarse el campo Suspended (suspensión), que suspende al usuario objetivo. Cuando un usario está suspendido, no puede:

Inactividad

Al editar su propia cuenta o la de otra persona como usuario de confianza, puede editarse el campo Inactive (kinactividad). Existen dos razones para suspender cuentas:

  • Mostrar la fecha en la que alguien fue etiquetado como inactivo en la página de su cuenta
  • Generar un conteo actualizado de usuario de confianza activos basado en su inactividad para consideración de nuevos candidatos

Retroalimentación

Escribir comentarios en paquetes

La interfaz Web de AUR facilita hacer comentarios que permite a los usuarios proporcionar sugerencias y retroalimentaci para contribuir a mejorar el PKGBUILD.

Sugerencia: Evite pegar parches o PKGBUILDs en la sección de comentarios: se vuelven rápidamente obsoletos y acaban ocupando innecesariamente mucho espacio. En su lugar, envíe los archivos al mantenedor, o incluso utilice un cliente pastebin.

Python-Markdown proporciona una sintaxis Markdown básica para dar formato a comentarios.

Nota:
  • Esta implementación tiene diferencias ocasionales respecto a reglas de sintaxis oficiales.
  • Hashes de commits al repositorio Git del paquete y referencias a tickets Flyspray se convierten automáticamente a hipervínculos.
  • Los comentarios largos son colapsados y pueden ser expandidos.

Votar por paquetes

Una de las actividades más fáciles para todos los usuarios de Arch es navegar por AUR y votar por sus paquetes favoritos utilizando la interfaz web. Todos los paquetes son elegibles para ser adoptados por un usuario de confianza para su inclusión en el repositorio extra, y el recuento de votos es uno de los factores considerados en este proceso, ¡por lo que votar es un interés de todos!

Resístrese en el sitio de AUR para encontrar la opción Vote for this package (votar por este paquete) al explorar los paquetes. Después de registrarse, también es posible votar desde la linea de órdenes con aurvote-gitAUR[enlace roto: package not found] o aur-auto-vote-gitAUR.

Alternativamente, si ha configurado auteticación ssh, puede votar directamente desde la línea de órdenes usando su clave ssh. Con este método no tiene que guardar o escribir su contraseña de AUR.

$ ssh aur@aur.archlinux.org vote nombre_de_paquete

Marcar paquetes como desactualizados

Primero señale al paquete como out-of-date (desactualizado) dando detalles sobre por qué está desactualizado, preferentemente incluyendo hipervínculos al anuncio de lanzamiento o al tarball del lanzamiento nuevo .

También puede contactar a los mantenedores del paquete a través de correo electrónico. Si no recibe respuesta después de dos semanas, puede enviar una petición para señalar al paquete como huérfano. Lea AUR submission guidelines#Requests para más información.

Nota: Paquetes VCS (desde sistemas de control de versiones) no se consideran desactualizados cuando pkgver (la versión del paquete) cambia; no los etiquete pues el mantenedor simplemente desetiquetará el paquete y lo ignorará. Mantenedores de AUR no deben hacer commits de simples cambios de pkgver.

Depurar el proceso de compilación

  1. Verifique que su entorno de compilación esté actualizado actualizando antes de comenzar a compilar.
  2. Asegúrese de tener base-devel instalado.
  3. Use la opción -s al ejecutar makepkg para verificar e instalar las dependencias requeridas entes de compilar.
  4. Pruebe con la configuración predeterminada de makepkg.
  5. Lea Makepkg (Español)#Solución de problemas para encontrar soluciones a problemas comunes.

Si tiene problemas para compilar un paquete, lea su PKGBUILD y los comentarios en su página AUR.

Es posible que un PKGBUILD tenga problemas para todo mundo. Si no puede solucionarlo usted mismo, hágale saber al mantenedor (por ejemplo, publicando los errores que encuentre en los comentarios de su página AUR). También puede pedir ayuda en el foro de problemas, discusiones y peticiones sobre MAKEPKGs.

La razón podría no ser trivial después de todo. Los CFLAGS, LDFLAGS y MAKEFLAGS personalizados pueden causar errores. Para evitar problemas causados por la configuración particular de su sistema, construya paquetes en un chroot limpio. Si el proceso de compilación sigue fallando en un chroot limpio, es probable que el problema sea el PKGBUILD.

Véase Comprobación de la sanidad del paquete sobre el uso de namcap. Si desea que se revise un PKGBUILD, publíquelo en la lista de correo aur-general para obtener comentarios de los TU y otros miembros de AUR, o en el foro de Creación y Modificación de Paquetes. También puedes buscar ayuda en el canal IRC #archlinux-aur en la red Libera Chat.

Enviar paquetes

Advertencia: Antes de intentar enviar un paquete, se espera que se familiarice con Arch packaging standards y todos los artículos indicados en «Artículos relacionados». Verifique cuidadosamente que lo que está cargando es correcto. Los paquetes que infrinjan las reglas podrán eliminarse sin previo aviso.

Si no está seguro de ningún modo sobre el paquete o el proceso de compilación/envío, incluso después de haber leído varias veces esta sección, envíe el PKGBUILD a la lista de correo de AUR, el foro de AUR en los foros de Arch, o pregunte en nuestro canal IRC para su revisión pública antes de agregarlo a AUR.

Reglas de envío

Al enviar un paquete, observe las siguientes reglas:

  • Los PKGBUILD enviados no deben compilar aplicaciones ya disponibles en cualquiera de los repositorios oficiales con binarios bajo ninguna circunstancia. Compruebe la base de datos de paquetes oficiales para ver el paquete. Si existe alguna versión de la misma, no envíe el paquete. Si el paquete oficial está desactualizado, márquelo como tal. Si el paquete oficial está roto o carece de un recurso, entonces presente un informe de error.
Excepción a esta regla estricta solo lo pueden ser aquellos paquetes que tengan características adicionales habilitadas y/o parches en comparación con las oficiales. En tal caso, pkgname debería ser diferente para expresar esa diferencia. Por ejemplo, un paquete para la GNU screen que contiene el parche de la barra lateral se podría llamar screen-sidebar. Además, el vector provides=('screen') se debe utilizar para evitar conflictos con el paquete oficial.
  • Verifique en AUR si el paquete ya existe. Si ya tiene un mantenedor, los cambios se pueden enviar en un comentario a la atención del mantenedor. Si no hay mantenedor o el mantenedor no responde, el paquete se puede adoptar y actualizar según sea necesario. No cree paquetes duplicados.
  • Asegúrese de que el paquete que desea cargar es útil. ¿Alguien más quiere usar este paquete? ¿Es muy especializado? Si unas cuantas personas encuentran este paquete útil, es apropiado para la presentación.
AUR y los repositorios oficiales están destinados a paquetes que instalan generalmente software y contenido relacionado con software, incluidos uno o más de los siguientes: ejecutables; archivo(s) de configuración; documentación en línea o fuera de línea para un software específico o para la distribución de Arch Linux en su conjunto; medios destinados a ser utilizados directamente por el software.
  • No utilice replaces en un PKGBUILD de AUR a menos que se cambie el nombre del paquete, por ejemplo cuando Ethereal se convirtió en Wireshark. Si el paquete es una versión alternativa de un paquete ya existente, utilice conflicts (y ​​provides si ese paquete es requerido por otros). La principal diferencia es que después de la sincronización (-Sy), pacman inmediatamente quiere reemplazar un paquete 'ofensivo' instalado al encontrar un paquete con la coincidencia replaces en sus repositorios; conflicts, por otro lado, solo se evalúa al instalar el paquete, que generalmente es el comportamiento deseado porque es menos invasivo.
  • El envío de binarios debe evitarse si las fuentes están disponibles. AUR no debe contener el tarball binario creado por makepkg, ni debe contener la lista de archivos.

Agregue una línea de comentario a la parte superior del archivo PKGBUILD que contenga información sobre los mantenedores actuales y los contribuidores anteriores, respetando el siguiente formato. Recuerde disfrazar su correo electrónico para protegerse contra el correo no deseado. Las líneas adicionales o innecesarias son facultativas.

Si asume la función de mantenedor de un PKGBUILD existente, agregue su nombre a la parte superior de este modo
# Maintainer: su nombre <dirección at dominio dot tld>
Si hubo mantenedores anteriores, colóquelos como contribuyentes. Lo mismo se aplica para el remitente original si este no fue usted. Si existe un conjunto de mantenedores, agregue los nombres de los otros mantenedores actuales también.
# Maintainer: su nombre <dirección at dominio dot tld>
# Maintainer: nombre de otros mantenedores <dirección at dominio dot tld>
# Contributor:  nombre de los mantenedores anteriores <dirección at dominio dot tld>
# Contributor: nombre del remitente original <dirección at dominio dot tld>

Verificación

Para tener acceso de modificación en AUR necesita disponer de emparejamiento de claves SSH. El contenido de la llave pública debe ser copiado en la página del perfil en la sección My Account, y la llave privada correspondiente debe ser configurada para el servidor aur.archlinux.org. Por ejemplo:

~/.ssh/config
Host aur.archlinux.org
  IdentityFile ~/.ssh/aur
  User aur

En el escenario ideal se debe SSH keys#Generating an SSH key pair y no usar un par existente, así se pueden revocar selectivamente en caso de que algo ocurra:

$ ssh-keygen -f ~/.ssh/aur
Sugerencia: Se pueden agregar múltiples llaves en su perfil separándolas con una nueva línea.

Crear un paquete nuevo

Para crear un repositorio Git vacío para un paquete, simplemente git clone el repositorio remoto con el nombre correspondiente. Si el paquete no existe en AUR, aparecerá la siguiente advertencia:

$ git clone ssh://aur@aur.archlinux.org/package_name.git
Cloning into 'package_name'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.
Nota: Cuando un paquete es borrado de AUR, el repositorio git no es borrado, así que al clonar el repositorio puede que no este vació si alguien quiere crear un paquete con el mismo nombre.

Si hay un repositorio git existente, simplemente se crea un remote para el repositorio git de AUR y luego fetch en el repositorio:

$ git remote add nombre_remoto ssh://aur@aur.archlinux.org/nombre_paquete.git
$ git fetch nombre_remoto

Donde nombre_remoto es el nombre del remote a crear (v.g., "origen"). Vea Git#Using remotes para mayor información.

El paquete aparecerá en AUR después del primer push. Desde ese momento se pueden agregar archivos con código fuente a la copia local del repositorio git. Vea #Subir paquetes.

Advertencia: Sus AUR commits tendrán como autor su usuario y correo electrónico configurado en git. Es muy difícil cambiar un commit después que ha sido subido (vea FS#45425). Si desea enviar paquetes con un autor/email diferente, lo puede hacer con la orden git config user.name [...] y git config user.email [...]. ¡Revise sus commits y documentos antes de subirlos!

Subir paquetes

El procedimiento para subir paquetes a AUR es el mismo que para crear paquetes nuevos o para actualizaciones. Se necesita como mínimo un PKGBUILD y un .SRCINFO en el directorio de trabajo para subir (push) su paquete a AUR.

Nota: se necesita generar el archivo .SRCINFO cada vez que se cambie la metainformación del PKGBUILD. Por ejemplo, al modificar pkgver() en actualizaciones. De otra manera, la web de AUR no va a mostrar las versiones actualizadas .

Para subir, añada el PKGBUILD, .SRCINFO y cualquier otro archivo necesario (como archivos .install o fuentes locales .patch) con git add, suba a su árbol local con un mensaje descriptivo git commit, y finalmente suba sus cambios a AUR con git push.

Ejemplo concreto:

$ makepkg --printsrcinfo > .SRCINFO
$ git add PKGBUILD .SRCINFO
$ git commit -m "useful commit message"
$ git push
Sugerencia:
  • Si inicialmente se ha olvidado el archivo .SRCINFO y lo ha agregado en un commit después, AUR va a rechazar sus subidas porque el archivo .SRCINFO debe existir en cada subida (push). Para solucionar este problema puede usar la orden git rebase con la opción --root o la orden git filter-branch con la opción --tree-filter.
  • Para prevenir archivos sin rastrear en las subidas, y para mantener el directorio de trabajo tan limpio como sea posible, excluya todos los archivos no deseados con .gitignore y fuerce agregar manualmente cada archivo. Vea gitignore(5).

Mantener los paquetes

  • Si se mantiene un paquete y desea actualizar el PKGBUILD para el mismo, basta con reenviarlo.
  • Compruebe si hay feedback y comentarios de otros usuarios y trate de incorporar las mejoras que le sugieren, ¡considere que es un proceso de aprendizaje!
  • Por favor, no presente un paquete, para luego olvidarse de él. El trabajo del mantenedor es mantener el paquete, buscando las actualizaciones y las mejoras del PKGBUILD.
  • Si no desea seguir manteniendo el paquete, por alguna razón, etiquete el paquete como disown a través de la interfaz web de AUR y/o envíe un mensaje a la lista de correos de AUR. Si todos los mantenedores de un paquete AUR lo rechazan, se convertirá en un paquete «huérfano».

Otras solicitudes

Las solicitudes de orfandad, eliminación o fusión se pueden crear haciendo clic en el enlace «Submit Request» bajo el enlace «Package Actions» en el lado derecho. Esto envía automáticamente un correo electrónico de notificación al actual mantenedor del paquete y a la aur-requests lista de correo para su discusión. El Trusted Users aceptará o rechazará la solicitud.

  • Las solicitudes de orfandad se otorgarán después de dos semanas, si el mantenedor actual no reaccionó.
  • Las solicitudes de fusión son para eliminar la base del paquete y transferir sus votos y comentarios a otra base de paquetes. Se requiere el nombre de base del paquete para fusionar. Tenga en cuenta que esto no tiene nada que ver con 'git merge' o las solicitudes de fusión de GitLab.
  • Las solicitudes de eliminación requieren la siguiente información:
    • Una breve nota que explique el motivo de la eliminación. Tenga en cuenta que los comentarios de un paquete no indican suficientemente las razones por las cuales un paquete está listo para su eliminación. Porque tan pronto como una TU toma medidas, el único lugar donde se puede obtener dicha información es la lista de correo.
    • Detalles del soporte, como cuando un paquete es proporcionado por otro paquete, si uno mismo es el mantenedor, si es renombrado y si el propietario original acepta, etc.
    • Las solicitudes de eliminación pueden rechazarse, en cuyo caso, si usted es el mantenedor del paquete, es probable que se le aconseje que no lo reconozca, para permitir la adopción por parte de otro empaquetador.

Traducir la interfaz web

Consulte i18n.txt en el árbol fuente de AUR para obtener información sobre cómo crear y mantener la traducción de la interfaz web de AUR.

Sintaxis de comentario

La sintaxis de Python-Markdown es compatible con los comentarios. Proporciona la sintaxis básica de Markdown para dar formato a los comentarios. Tenga en cuenta que esta implementación tiene algunas diferencias ocasionales con respecto a las reglas de sintaxis oficiales. Confirme el hash para el repositorio Git del paquete y las referencias a los tickets para Flyspray se convertirán en enlaces automáticamente. Los comentarios largos se contraen y se pueden expandir bajo demanda.

FAQ

¿Que es AUR?

AUR (Arch User Repository) es el lugar donde la comunidad de Arch Linux puede subir los PKGBUILD de las aplicaciones, bibliotecas, etc., y compartirlos con el resto de la comunidad. Los demás usuarios pueden votar para que sus favoritos entren en el repositorio extra de modo que puedan ser instalados en Arch Linux en formato binario.

¿Qué tipo de paquetes se permiten en AUR?

Los paquetes en AUR no son más que «scripts de compilación», es decir, instrucciones para construir los binarios que pueden ser manejados por pacman. Para la mayor parte de los casos, no hay limitaciones, siempre y cuando se ajusten a las directrices de la utilidad antes mencionada y a los términos de licencia del contenido. En otros casos, cuando se menciona que «no se puede vincular» a las descargas, como cuando los contenidos no son redistribuibles, solo se podrá hacer uso del mismo nombre del archivo como la fuente. Esto significa y requiere que los usuarios deben tener ya la fuente en el directorio de compilación antes de iniciar el proceso de construcción del paquete. En caso de duda, pregunte.

¿Cómo puedo votar por los paquetes en AUR?

Inscríbase en el sitio web de AUR para tener acceso a la opción "Vote for this package" («Vote por este paquete») mientras explora los paquetes. Después de registrarse, también es posible votar desde la línea de órdenes con aurvoteAUR[enlace roto: package not found], aurvote-gitAUR[enlace roto: package not found] o aur-auto-vote-gitAUR.

Alternativamente, si ha configurado autenticación ssh como se indicó anteriormente, puede votar directamente desde la línea de órdenes usando su clave ssh. Esto significa que no necesitará guardar o escribir su contraseña AUR.

ssh aur@aur.archlinux.org vote <PACKAGE_NAME>

¿Qué es un usuario de confianza / Trusted Users (TU)?

Un Trusted Users («usuarios de confianza»), siglas en inglés TU, es una persona encargada de supervisar el repositorio AUR y el repositorio extra. Ellos son los que colocan los paquetes más votados en el repositorio extra, marcan los PKGBUILDs como seguros y mantienen AUR.

¿Cuál es la diferencia entre Arch User Repository y el repositorio extra?

Arch User Repository contiene todos los PKGBUILD que los usuarios envían; para instalarlos tiene que construirlos manualmente con makepkg. Cuando un PKGBUILD obtiene suficientes votos, pasa al repositorio extra (mantenido por los usuarios de confianza), donde los paquetes binarios pueden instalarse directamente con pacman.

Un paquete en AUR está desactualizado, ¿qué hago?

Puede marcarlo como obsoleto. Si no se actualiza en un periodo de tiempo razonable, lo mejor es avisar a su mantenedor por email. Si el responsable no responde, puede comunicarlo a la lista de correo general de AUR, para que un TU (Trusted Users —«usuarios de confianza»—) declare huérfano al PKGBUILD y pueda adoptarlo si desea mantenerlo él mismo. Cuando se trate de un paquete que lleva desactualizado más de 3 meses y, en general, no se actualiza desde hace mucho tiempo, por favor agregue esto en su solicitud de orfandad.

Mientras tanto, puede intentar actualizar el paquete editando el PKGBUILD localmente. A veces, las actualizaciones no requieren cambios en el proceso de compilación o paquete, en cuyo caso basta con actualizar la matriz pkgver o source.

Nota: Los paquetes VCS no se consideran obsoletos cuando el pkgver cambia, no los marque ya que el mantenedor simplemente desmarca el paquete y lo ignora. Los mantenedores de AUR no deberían cometer errores de pkgver.

Foo, que está en AUR, no me compila con makepkg, ¿qué hago?

Probablemente está pasando por alto alguna cosa.

  1. Ejecute pacman -Syyu antes de compilar nada con makepkg dado que el problema puede ser que el sistema no está al día.
  2. Asegúrese de que tiene instalados tanto los grupos «base» como «base-devel».
  3. Pruebe usando la opción «-s» con makepkg para comprobar e instalar todas las dependencias necesarias antes de comenzar el proceso de compilación.

Asegúrese de leer primero el PKGBUILD y los comentarios en la página de AUR del paquete en cuestión. La razón puede no ser trivial después de todo. La personalización de CFLAGS, LDFLAGS y MAKEFLAGS puede causar fallos. También es posible que el PKGBUILD se rompe para todos. Si no puede resolverlo por su cuenta, simplemente informe al mantenedor, por ejemplo, mediante la publicación de los errores que está recibiendo en los comentarios de la página de AUR.

Para verificar si el PKGBUILD está roto, o si su sistema está mal configurado, considere compilar en un entorno chroot limpio. Construirá su paquete en un entorno limpio de Arch Linux, con solo dependencias (de compilación) instaladas y sin personalización del usuario. Para hacer esto instale devtools y ejecute extra-x86_64-build en lugar de makepkg. Para paquetes multilib, ejecute multilib-build. Consulte DeveloperWiki:Building in a clean chroot para más información. Si el proceso de compilación aún falla en un entorno chroot limpio, el problema probablemente esté en el PKGBUILD.

ERROR: One or more PGP signatures could not be verified!; ¿qué debería hacer?

Lo más probable es que no tenga las claves públicas requeridas en su depósito de claves personal para verificar los archivos descargados. Si uno o más archivos .sig se descargan al compilar el paquete, makepkg verificará automáticamente los archivos correspondientes con la clave pública de su firmante. Si no tiene la clave requerida en su depósito de claves personal, makepkg no hará la verificación.

La forma recomendada de tratar este problema es importar la clave pública requerida, ya sea manualmente o desde un servidor de claves. A menudo, simplemente puede encontrar la huella digital de las claves públicas necesarias en validpgpkeys.

¿Cómo hacer un PKGBUILD?

Lo mejor es mirar Creating packages (Español). Recuerde mirar en AUR antes de crear el PKGBUILD para no duplicar los esfuerzos.

Quiero enviar un PKGBUILD ¿podría alguien comprobar antes si tiene errores?

Si quisiera recibir comentarios a tu PKGBUILD, envíelo a la lista de correo de AUR para que los TU (Trusted Users —«usuarios de confianza»—) y los otros miembros de AUR puedan orientarle para mejorarlo. Otro lugar donde puede encontrar ayuda es el canal IRC, #archlinux en irc.libera.chat. También puede usar namcap para depurar errores de su PKGUILD y del paquete resultante.

¿Qué hacer para que un PKGBUILD pase al repositorio extra?

Por lo general, son necesarios, al menos, 10 votos para que algo se mueva al repositorio extra. Sin embargo, si un TU (Trusted Users —«usuarios de confianza»—) quiere apoyar un paquete, se suele pasar dicho paquete al repositorio.

Llegar al mínimo requerido de votos no es el único requisito, tiene que haber un TU (Trusted Users —«usuarios de confianza»—) dispuesto a mantener el paquete. Los TU (Trusted Users —«usuarios de confianza»—) no están obligados a mover un paquete al repositorio extra, incluso si tiene miles de votos.

Por lo general, cuando un paquete muy popular permanece en AUR es porque:

  • Arch Linux ya tiene otra versión de un paquete en los repositorios
  • Su licencia prohíbe la redistribución
  • Ayuda a recuperar PKGBUILDs enviados por el usuario. Los AUR helpers están por definición sin soporte.

Véase también Reglas para paquetes que ingresan en el repositorio extra.

¿Cómo puedo acelerar los repetidos procesos de compilación?

Consulte Makepkg#Improving build times.

¿Cuál es la diferencia entre los paquetes foo y foo-git?

Muchos paquetes de AUR se presentan en versiones regulares ("estables") y de desarrollo ("inestables"). Un paquete de desarrollo generalmente tiene un sufijo como -cvs, -svn, -git, -hg, -bzr o -darcs. Si bien los paquetes de desarrollo no están destinados para uso regular, pueden ofrecer nuevas características o correcciones de errores. Debido a que estos paquetes descargan la última fuente disponible cuando ejecuta makepkg, no está directamente disponible para estos una versión del paquete para rastrear posibles actualizaciones. Del mismo modo, estos paquetes no pueden realizar una suma de comprobación de autenticidad, sino que debemos fiarnos de los mantenedores del repositorio Git.

Véase también System maintenance#Use proven software packages.

¿Por qué foo desapareció de AUR?

Es posible que el paquete haya sido adoptado por un TU (Trusted Users —«usuarios de confianza»—) y ahora esté en el repositorio extra.

Los paquetes pueden eliminarse si no cumplen con las #Reglas de envío. Consulte los aur-requests archivos para conocer el motivo de la eliminación.

Si el paquete estaba presente en AUR3, podría no haber sido migrado a AUR4. Consulte los #Repositorios Git para paquetes AUR3 donde se conservará.

¿Cómo puedo averiguar si alguno de los paquetes instalados desapareció de AUR?

La forma más sencilla es verificar el estado HTTP de la página AUR del paquete:

$ comm -23 <(pacman -Qqm | sort) <(curl https://aur.archlinux.org/packages.gz | gzip -cd | sort)

Si utiliza un AUR helper, puede acortar este script reemplazando la orden curl con cualquier orden que consulte AUR para un paquete.

¿Cómo puedo obtener una lista de todos los paquetes de AUR?

Véase también