Definamos Normal.

El Blog personal de Rafael Rojas

Category: pacman (page 1 of 2)

Del porque no debes ignorar los archivos .pacnew

Una de las caracteristicas que hacen de ArchLinux una distribucion High maintenance o “tengo muchisimo tiempo libre en mis manos para andar toqueteando mi sistema” en español es que el sistema no se hace cargo automáticamente de los archivos de configuración, ni cuando se instala un paquete nuevo, ni cuando se actualiza. En su filosofía Vanilla ArchLinux instala los paquetes con la configuracion default del paquete original, o en su caso sin configuración alguna.

Pacman, a la hora de actualizar un paquete este no sobreescribe el archivo de configuración existente, sino que crea uno en limpio y lo guarda con la extension .pacnew. Estos se ven cuando actualizamos un paquete que tiene un archivo de configuración nuevo:

advertencia: /etc/makepkg.conf instalado como /etc/makepkg.conf.pacnew

De la misma forma a la hora de remover un paquete pacman deja guardados los archivos de configuracion de este paquete con una extension .pacsave, ejemplo:

advertencia: /etc/makepkg.conf guardado como /etc/makepkg.conf.pacsave

Todos estos pasos de seguridad son propios de pacman y los archivos de configuración que cada paquete va a tocar (o guardar en caso de desinstalación) se encuentran configurados en cada PKGBUILD de los paquetes, de aqui viene la simplicidad de ArchLinux: este espera que el usuario configure y combine las nuevas caracteristicas en los archivos de configuración ya existentes.

Y como ver las diferencias entre configuraciones nuevas y viejas?

Una forma sencilla de encontrar cuantos archivos .pacnew tenemos sin combinar seria con una simple busqueda.

Para revisar esos .pacnew hay herramientas como diff: Continue reading

Vota por tus paquetes favoritos de AUR

Hay una forma de que los paquetes del repositorio de usuarios de ArchLinux pasen al repositorio [community] y puedan ser instalados con un simple pacman -S sin necesidad de que sean compilados desde codigo fuente, esta forma simple es: votando por ellos.

Segun la wiki de Arch los requisitos para que estos paquetes pasen al repositorio [community] son:

Al menos, 10 votos para que algo se mueva al repositorio [community]. o
Que un usuario de confianza (Trusted User, TU en ingles) adopte y mantenga dicho paquete.

Si un paquete tiene suficientes votos para ser considerado para [community], se considerara tomar al usuario creador del PKGBUILD para incluirlo como usuario de confianza y se le asignara la responsabilidad de actualizar dicho paquete.

Y quien puede votar por estos PKGBUILDs?

Basicamente cualquiera que se haga de una cuenta de usuario dentro de archlinux.org

Con esa cuenta creada (que también sirve para acceder a los foros oficiales de ArchLinux y para ayudar a editar y actualizar su wiki) solo falta instalar el paquete aurvote desde AUR:

yaourt -S aurvote

Y luego corremos la configuración de aurvote:

aurvote --configure

Que nos pide información de nuestra cuenta y pregunta si queremos un login persistente y donde guardar la cookie de AUR:

kmix2

Y listo, ya podemos votar por nuestros paquetes favoritos, por ejemplo yo pienso que el paquete de fonts oxygen ya esta suficientemente maduro:

kmix3

Espero que si incluyan un paquete precompilado.

Quien dijo que ArchLinux no tomaba en cuenta a sus usuarios?

Benchmark de herramientas para AUR

AUR es el repositorio de usuarios de archlinux donde todos podemos subir un pkgbuild para compilar/instalar/administrar algun paquete de software no soportado oficialmente por la distribucion. El detalle de AUR es que no cuenta con una herramienta oficial para su manejo (asi es, yaourt no es oficial) y los usuarios tenian que ir hasta la pagina de AUR para descargar sus pkgbuilds y tener una administracion a mano.

Despues empezaron a salir muchos scripts, en principio sencillos, que ayudaban al usuario a conectarse al repositorio de AUR y descargar y aplicar estos pkgbuilds, en ingles se llaman AUR Helpers, en español son herramientas para AUR, y eso es lo que es yaourt, packer, aurget y demas.

Hay un monton de herramientas para AUR listadas en la wiki de ArchLinux, muchas muy basicas, otras todavia en desarrollo, unas totalmente abandonadas y todas generalmente hacen mas o menos lo mismo de forma ligeramente diferente. Pero, que pasa si nos ponemos a testear estas herramientas?.

El test, que no esta hecho meramente por procedimiento cientifico, hecho por el usuario monoloco de los foros de ArchLinux nos muestra los resultados de varias pruebas a esta herramienta utilizando el mismo criterio de busqueda y de instalacion: un paquete de python, los resultados:

En orden de velocidad, medida en segundos, de mas rapido a menos rapido

yaourt                 6.365
packer     (A)         6.587
meat       (A)         7.506
pacaur                 7.585
cower      (A)         8.073
spinach                8.786
packer                16.385
aura       (A)        19.426
packer     (A)        19.859
aurget     (A)        20.805
aurora     (A)        21.335
owl        (A)        23.367
owl                   27.197
paktahn               28.349
pbfetch              1:09.67
pbfetch    (A)       1:09.72
PKGBUILDer (A)       1:49.46

El termino (A) indica que la herramienta solamente maneja paquetes de AUR y no de repositorios (no es ayudante de pacman)

En orden de uso de CPU (de menor a mayor)

packer     (A)           0.8%
cower      (A)           1.4%
meat       (A)           1.6%
pacaur     (A)           2.0%
aura       (A)           2.6%
pacaur                   3.2%
spinach                  3.2%
packer                   3.2%
yaourt                   4.6%
aurget     (A)           5.2%
owl                     16.2%
owl        (A)          16.4%
paktahn                 28.2%
aurora     (A)          34.0%
pbfetch    (A)          34.8%
pbfetch                 35.2%
PKGBUILDer (A)          88.8%

Interesante dato a tomar en cuenta si queremos afinar tan a detalle el consumo de recursos de el sistema. hay que aclarar que estos datos son de busqueda de paquetesy tiempo de respuesta, el tiempo de compilacion depende absolutamente de la capacidad de hardware de el equipo.

Si quieren leer la nota original aqui esta el tema en los foros de archlinux.

Instalacion de sistema base de archlinux-2012.07.15

NOTA:
Esta entrada ya no va a ser editada con los muy posibles futuros cambios en el instalador de ArcLinux, para ello pongo a disposicion una seccion completa de instalacion del sistema base aqui

Llego la hora de actualizar la pequeña guia de instalacion posteada aqui en otros tiempos sobre la instalacion de archlinux, esta guia toma partes de la guia anterior para no tener que re escribir todo desde el principio, sin decir mas, manos a la obra. Descargamos la ISO de archlinux desde aqui, la imagen netinstall sera de arquitectura dual por ser la imagen de instalación en red que tiene soporte para las 2 arquitecturas de ArchLinux: 32 bits (i686) y 64 bits (x86_64). La grabamos en cd y reiniciamos el equipo con el LiveCD, aparecerá este menú:

Donde las opciones son:

  • Boot ArchLinux – que es iniciar el livecd de arch linux y iniciar la instalacion.
  • Boot Existing OS – Ignorar el Livecd y iniciar el sistema operativo del disco duro si existe.
  • Run Memtest86+ (RAM test) – Es un testeo de integridad de  la memoria Ram del equipo Run x86 test (CPU test) – Es un testeo de la integridad del cpu del equipo.
  • Reboot – Reiniciar. Iniciamos con boot ArchLinux, esto nos llevara a la shell del live de ArchLinux.

Continue reading

ArchLinux /lib a /usr/lib y otros demonios

El sabado pasado ArchLinux se puso a la par de distros como Fedora al mover el directorio /lib a /usr/lib dejando al directorio /lib como un enlace simbolico a /usr/lib para los programas qeu quieran seguir haciendo referencia a /lib

A pesar de haberse hehco un desasttre de usuarios que no leyeron la nota al respecto y “rompieron” su sistema, la actualizacion no es gran cosa

1. Actualizamos el sistema ignorando momentaneamente glibc

# pacman -Syu --ignore glibc

2. Una vez terminada esa actualizacion ahora si procedemos con las actcualizaciones pendientes de glibc

# pacman -Su

NUNCA SE DEBE UTILIZAR LA OPCION --force PARA SOLUCIONAR ESTA ACTUALIZACION

Y listo, en un sistema normal esto debería ser suficiente como para dejar a ArchLinux actualizado con todo y cambio de directorios de librerias, si de todos modos al ejecutar pacman -Su se siguen teniendo problemas es posible el caso es como el de muchos que tienen drivers, kernels personalizados, librerias o aplicaciones que hagan referencias a /lib que puede ocasionar conflictos

¿Y como reviso que aplicaciones estan generando conflictos?

find /lib -exec pacman -Qo -- {} +

Simplemente desinstalan los drivers, modulos o paquetes que generen conflictos, no se preocupen: los drivers se quedan cargados en memoria no es que se queden sin video o wifi, hagan el pacman -Su que acabe bien, y reinstalan los paquetes antes removidos.

Mas informacion acerca de como solucionar posibles errores con esta actualizacion aqui

Ahora, pasando de lado esta actualizacion.

Sucede que los usuarios de GNU/Linux estamos mal acostumbrados muchas veces, preferimos buscar soluciones rapidas y sencillas en sitios donde las noticias estan resumidas y las soluciones generalizadas en vez de leer las fuentes originales, los sitios oficiales, las wikis oficiales y los boletines de noticias de las distros. Esta actualizacion de directorios hizo estragos a mucha gente que forzo la actualizacion y se quedaron con un sistema inestable, que irva de ejemplo para cuando suceda algun cambio de este tipo busquemos la fuente oficial y no el resumen en algun blog, sinisuqiera este.

Saludos, y suerte

Protip: listar los paquetes instalados desde AUR

Algo que ya van 2 veces que me preguntan en persona, asi que lo dejo aqui: “como veo los paquetes que he instalado localmente o desde AUR/yaourt/packer?”

Es bastante simple, usando yaourt:

yaourt -Qm

El resultaddo seria mas o menos esto: Continue reading

Al ejecutar pacman-key –init no pasa nada

He visto varios problemas de usuarios que al ejecutar

pacman-key --init

Simplemente no pasa nada :S

La solucion es realmente rapida, es simplemente un problema de entropia

La solucion es simple, al ejecutar pacman-key --init simplemente abran un nuevo emulador de terminal (si estan en escritorio) o terminal TTY si estan apenas instalando el sistema (Crtl + Alt *F(1-6)) y actualizen la base de datos para mlocate.

updatedb

Y listo.

Asi de simple: si pacman-key --init se traba o no hace nada o tarda mucho, sin dejar de ejecutar esa orden abran otra terminal y ejecuten updatedb y ya.

Pequeño problema que se resolvera en la siguinete version de pacman.

Si aun no configura la firma de paquetes, aqui hay una guia muy clara de como hacerlo (modestia aparte :D)

Actualizacion de filesystem, intervencion manual requerida

Leo esta mañana en el sitio de ArchLinux que el paquete filesystem tiene una actualización (filesystem-2012.6-2 ) y que los directorios /var/run y /var/lock seran remplazados por enlaces dinámicos a /run y /run/lock

En la mayoría de los sistemas esto ya es un hecho por que initscripts crea dichos enlaces en el inicio, sin embargo estos enlaces no son propiedad de ningún paquete, eso es lo que corrige esta actualización.

SI los symlinks ya están configurados (que es el caso de la mayoría de los usuarios) pueden simplemente ejecutar:

# pacman -Syu --ignore filesystem && pacman -S filesystem --force

Que es actualizar el sistema omitiendo el paquete filesystem y luego forzar la instalación del paquete filesystem, y listo 😀

Sin embargo si /var/run y /var/lock son directorios (como en el caso de que usemos systemd para iniciar el sistema, en lugar de initscripts) es recomendado borrar estos directorios primero. NOTA: como estos directorios son usados por el sistema, se recomienda guardar todo trabajo, cerrar programas y ejecutar:

# rm -rf /var/run /var/lock && pacman -Syu && reboot

Esto reiniciara automáticamente el sistema después de actualizar.

Por lo general no se recomienda el forzar la instalación de paquetes, pero en este caso es seguro y necesario para la correcta actualización de filesystem.

Saludos

Firma de paquetes y seguridad en pacman

Hace ya algunos meses hablaba de la firma de paquetes en ArchLinux, se aclaro que esa revisión de paquetes firmados era meramente opcional, con vistas a volverse obligatoria en un futuro próximo. En el post que trate esa firma de paquetes utilizaba algunos scripts para descargar y validar las firmas gpg de los developers de ArchLinux, ese método ha cambiado ya.

En las nuevas versiones de pacman, la configuración de este (/etc/pacman.conf) maneja un modelo de revisión de firmas por repositorio, algo muy recomendable de habilitar por que asegura la confiabilidad de paquetes.

Despues de actualizar pacman, instalamos el paquete archlinux-keyring:

pacman -S archlinux-keyring

Iniciamos el servidor de llaves, esto llevara un rato:

pacman-key --init

Y ahora, en vez de usar scripts para descargar las llaves de desarrolladores, poblamos las listas de llaves así:

pacman-key --populate archlinux

Este comando nos preguntara sobre las firmas a importar, aceptamos todas:

La firma se marcará como no exportable.
¿Firmar de verdad? (s/N) s

Listo, tenemos las listas de llaves de desarrolladores, ahora a habilitar la verificación de estas en pacman.

Primero que nada debemos comentar esta línea:

# For now, off by default unless you read the above.
SigLevel = Never

Dejarla asi

# For now, off by default unless you read the above.
#SigLevel = Never

Luego habilitamos la revisión de firmas según el tipo y necesidad del repositorio:

[core]
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

Todo paquete de core será revisado forzosamente, un paquete no firmado y revisado no podrá ser instalado.

[extra]
SigLevel = PackageOptional
Include = /etc/pacman.d/mirrorlist

La firma del paquete será revisada, aunque no será necesario tener una revisión local de dicha firma

[community]
SigLevel = PackageOptional
Include = /etc/pacman.d/mirrorlist

Al igual que extra, revisara la firma pero no será obligatorio que pase la revisión local

Nota: al utilizar este nivel de revisión de seguridad hará imposible para el usuario instalar paquetes localmente con pacman -U por no poder revisar la firma del paquete, esto no afecta al instalar cosas de AUR (utilizar yaourt/packer)

Pequeño error al actualizar pacman

Sucede que al actualizar se nos pide que actualizemos primero pacman a su nueva version 4.0.2-1:

:: Los siguientes paquetes deben actualizarse primero:
pacman
:: ¿Desea cancelar la operación actual
:: y actualizar estos paquetes ahora? [S/n]

Pero al hacerlo hay un error que dice:

error: error al preparar la transacción (no se pudieron satisfacer las dependencias)
:: gcc: necesita gcc-libs=4.7.0-3

Esto se resuelve de la manera mas simple, haciendo que pacman reinstale pacman:

[root@delly lucain]# pacman -S pacman

Al terminar nos dara este mensaje:

Run `pacman-key --init` to set up your pacman keyring.

Que es la forma de manejar las llaves gpg de esta nueva version de pacman, que es material para el siguiente post

Older posts

© 2017 Definamos Normal.

Theme by Anders NorenUp ↑