Comunidad Hispana de Arch Linux

Este es el sitio de la Comunidad Hispana de Arch Linux, una distribución Linux liviana y flexible que intenta mantener las cosas simples, siguiendo la filosofía KISS (Keep It Simple, Stupid!).

Originalmente el foro de “Arch Linux en Español“, actualmente desde este espacio intentamos complementar el soporte que da la gran comunidad en ingles del sitio oficial de Arch Linux, creando un espacio para los hispano-parlantes que desean intercambiar opiniones y conocimiento en su propio idioma. En este sitio nos encontramos usuarios de Arch Linux de toda América Latina, así como de España.

Continuar leyendo

Actualización de Perl a la versión 5.20

Como viene sucediendo con otras actualizaciones de Perl, la versión 5.20 necesita que todos los módulos que no estén escritos con código perl vuelvan a ser compilados. Algo que ya hemos hecho con todos los paquetes presentes en nuestros repositorios.

Las dos últimas grandes actualizaciones devolvían un mensaje al tratar de cargar los módulos compilados de acuerdo a una versión que no era la correcta. La versión 5.20 produce segfaults. Hay que asegurarse de recompilar todos los modulos CPAN, así como los ficheros binarios, que se tengan instalados y que apunten a libperl.so.

En mi post en arch-dev-public hay un script con el que encontrar dichos paquetes.

Traducción oficial y discusión de la noticia en el foro.

Administración de paquetes Haskell con GHC 7.8.2

Esta versión recién estrenada incluye, entre otros, los siguientes cambios:

  1. Todos los paquetes que no sean ghc o caball-install pasan a estar en [community]. Esto permitirá prestar mejor soporte a las librerías haskell comunes del nucleo puesto que, de hecho, ya no se usan estos paquetes con cabal-install.
  2. Estas son las distintas formas disponibles para que los usuarios puedan instalar los paquetes:
    1. Usar cabal-install para instalar paquetes haskell. Esto permitirá al usuario acceder a cualquier paquete haskell haskell que se encuentre en hackage. El problema es que ahora se estarán usando paquetes que no se administran con pacman. Esta suele ser la mejor opción en caso de estar desarrollando aplicaciones haskell conforme al nuevo desarrollo en entorno aislado y seguro que se incluye con cabal-install 1.18.
    2. Usar pacman para instalar paquetes haskell. Esto permite al usuario tener acceso a un pequeño apartado de paquetes de hackage de los que se sabe a ciencia cierta que funcionan en archlinux y que, normalmente, son lo suficientemente apropiados para desarrolladores que no sean de haskell.
    3. Usar un repositorio no oficial, Arch Haskell. Se puede encontrar más información sobre este repositorio en esta página

Traducción oficial y discusión de la noticia en el foro.

screen-4.2.1 tampoco puede conectar con instancias anteriores

Los cambios introducidos en la versión 4.2.1 de screen hacen imposible a los usuarios conectar con las instancias creadas con la versión 4.2.0 o anterior. Se ruega actualizar a screen-4.2.1-2 una vez que se esté totalmente seguro que las instancias anteriores ya no son necesarias. De nuevo, pedimos disculpas por las por las molestias que haya podido ocasionar la actualización de este programa.

Traducción oficial y discusión de la noticia en el foro.

screen-4.2.0 no puede conectar con instancias anteriores

Los usuarios de screen no podrán conectar con instancias anteriores del programa una vez que hayan actualizado a la versión 4.2.0. Esto se debe a que los desarrolladores han llevado a cabo muchos cambios internos en el programa y pasado de usar para la comunicación filtros de redireccionamiento con nombre o named pipes a sockets. Los usuarios deben asegurarse de que las instancias de screen actuales ya no sean necesarias antes de proceder con la actualización.

Traducción oficial y discusión de la noticia en el foro.

ATENCIÓN con Linux 3.13: el soporte del teclado PS/2 pasa a ser modular

Se nos pidió que implementáramos el soporte para el controlador teclado y ratón i8042 de forma que estos fuesen modulares. Algunos usuarios estarán viendo errores un tanto raros porque no disponen de uno de estos dispositivos y el hecho de tener que reconocerlos de forma manual les estará realentizando el arranque del equipo. Tom se ocupó de este asunto en el kernel (muchas gracias, por cierto) y finalmente hemos podido apreciar este cambio en la versión 3.13 del kernel.

Para que el teclado funcione al principio del arranque, si es que no funciona todavía, hay que añadir el hook keyboard a la línea HOOKS= en /etc/mkinitcpio.conf y ejecutar mkinitcpio -P. Durante algún tiempo fue la configuración por defecto.

ATENCIÓN: hay una pega con todo este asunto y es la siguiente: en algunas placas base (sobre todo las más antiguas, pero también en algunas nuevas), el controlador i8042 no se puede detectar automáticamente. Se trata de algo muy excepcional pero es seguro que habrá usuarios que se queden sin teclado. Se puede detectar de antemano si este va a ser nuestro caso ejecutando lo siguiente:

$ dmesg -t | grep '^i8042'
i8042: PNP: No PS/2 controller found. Probing ports directly.

Si se tiene un puerto PS/2 y se obtiene dicho mensaje, hay que añadir atkbd a la línea MODULES= en mkinitcpio.conf y ejecutar mkinitcpio -P. Si por algún casual el usuario ve que no puede usar el teclado después de reiniciar, ¡que no cunda el pánico! Simplemente hay que añadir lo siguiente a la línea de comandos del kernel en el bootloader:

earlymodules=atkbd modules-load=atkbd

Moveremos Linux 3.13 a [core] dentro de unas horas para dar la oportunidad a todo el mundo de leer esta noticia antes de actualizar. Pedimos disculpas por las molestias que esta transición pueda provocar.

Traducción oficial y discusión de la noticia en el foro.