debianlogowall

Apt-pinning o como instalar paquetes de diferentes ramas en Debian

Como muchos sabéis Debian está disponible en diferentes ramas, stable, testing, unstable y experimental. Las diferencias entre cada una de ellas las expliqué hace ya mucho tiempo en un post que escribí cuando decidí cambiarme a esta distribución, Ramas de Debian, aunque la entrada es del 2007 la explicación sigue siendo casi la misma, me dejé de explicar la experimental pero que su propio nombre ya indica a que se refiere, ¿no?

Cuando instalamos Debian escogemos la rama en la cual queremos estar y apuntamos nuestros repositorios hacia esa rama. Lo podemos dejar en estable o podemos modificar nuestro sources.list a testing o sid (unstable) o la que nos plazca. Por norma general solo una y digo por norma general y solo una para no hacer un lío a nuestro sistema y crear problemas de dependencias, pero saliéndose de la norma general también podríamos querer un sistema mixto, es decir apuntar nuestro sistema a diferentes ramas.

¿Y por qué querríamos o necesitaríamos tener en nuestra lista de repositorios testing y sid? La cuestión es que a veces necesitamos algún paquete que no se encuentra en los repositorios de la rama que nosotros estamos utilizando, por ejemplo la rama estable a veces es un poco lenta en actualizarse y no podemos encontrar paquetes nuevos o versiones más recientes. Yo suelo utilizar testing, que queda entremedio de lo estable y seguro pero con versiones más antiguas y la versión unstable que es donde aparecen paquetes más novedosos pero que pueden darnos algunos problemas. Para ir a lo seguro testing en realidad es bastante estable y cubre mis necesidades en cuanto a aplicaciones y novedades, y a pesar de su nombre es muy estable, no recuerdo en mis años con Debian haber tenido ningún problema por ese motivo. Pero a lo que íbamos, aunque testing está muy al día puede ocurrir que el paquete que estemos buscando no se encuentre en los repositorios. Si hacéis una búsqueda con aptitude search de un paquete y no aparece, para saber en que rama se encuentra podéis hacer una búsqueda a través de la web Búsqueda de paquetes de Debian que te devolverá información al respecto. Puede que no exista realmente en ninguna rama y tengamos que buscarnos la vida por otro lado para descargarlo y compilarlo o puede que en efecto sí exista pero no en la rama que nosotros estemos utilizando, es aquí donde entra en juego lo que se conoce como apt-pinning, que nos permite sin cambiar de rama todo nuestro sistema instalar paquetes que se encuentran en otra distinta.

Yo antes lo que hacía cuando me encontraba en estos casos es añadir a mi sources.list los repositorios de unstable, si es que era ahí donde se encontraba lo que quería instalar. Actualizar la lista de repositorios e instalar solo el paquete que necesitaba y después volver a comentar el repositorio unstable para que no hubiese conflicto en siguientes actualizaciones. Es una posible solución también.

En este caso buscaba instalar amule desde mis repositorios habituales, los de testing, pero mi sorpresa al ver que había desaparecido. Por lo que leí en lo foros de esdebian, es por un tema de el paso de jessie (actual testing) a stable y parece ser que algunos paquetes se han quedado fuera por el momento. Es aquí cuando me dije, ahora es el momento de probar apt-pinning.

Como he comentado, mantendremos como prioritaria nuestra rama testing para actualizaciones y descarga e instalación de paquetes pero en ocasiones y cuando yo quiera obtendré paquetes de la rama unstable.

Vamos a ello, sin miedo!!

Primero de todo yo recomendaría actualizar nuestro sistema y dejarlo limpio de actualizaciones pendientes.

Estamos en testing y quiero instalar amule desde los repositorios de sid que es donde se encuentra, así que editamos nuestro sources.list:

nano /etc/apt/sources.list

Y añadimos el respositorio de unstable o sid:

#debian unstable
deb http://ftp.fr.debian.org/debian/ unstable main contrib non-free

Ahora necesitaremos crear 2 ficheros donde estableceremos la configuración y las preferencias de apt.

Vamos con el primero de ellos: apt.conf:

nano /etc/apt/apt.conf

Y escribimos:

APT::Default-Release "testing";
    APT::Cache-Limit 15000000;
    Apt::Get::Purge;
    APT::Clean-Installed;
    APT::Get::Fix-Broken;
    APT::Get::Fix-Missing;
    APT::Get::Show-Upgraded "true";

Con esto especificaremos que nuestra rama principial por defecto es testing, limitaremos la caché, indicamos que elimine y purgue los archivos de configuración de los paquetes que desinstalemos y que arregle el sistema en caso de que haya dependencias rotas, tenéis más info en man apt.conf.

Ahora vamos a crear el archivo preferences donde indicaremos nuestras preferencias en el momento de instalar paquetes de una rama u otra. Podemos especificar diferentes prioridades pero yo en mi caso lo he dejado como os indico, al final del post os dejo las fuentes que he utilizado donde podréis ver que otras opciones podéis usar, hay varias distintas, igual que el sistema de prioridades y la manera de especificarlas, no todos tenemos las mismas preferencias ni buscamos lo mismo, sino también podéis echar un vistazo a man apt_preferences.

Package: *
Pin: release a=testing
Pin-Priority: 900

Package: *
Pin: release a=unstable
Pin-Priority: -10

Para el primer caso estoy dando alta prioridad a las versiones de los paquetes pertenecientes a cualquier distribución que tenga como nombre de archivo de paquetes testing.

En el segundo caso, el valor negativo es para que ignore los paquetes de la rama unstable, pues vaya ¿y entonces? Esto es para que si se diera el caso de una actualización no incluya un paquete o dependencia de la versión unstable sin que me dé cuenta, yo lo lo especificaré a la hora de instalar, no tiene por qué pasar, pero yo prefiero pecar de precavida.

Bien, una vez tengamos estos 2 archivos creados pasamos a la prueba de fuego. Realizamos una actualización de nuestro sistema con aptitude update y aptitude safe-upgrade, si todo ha ido bien y nos hemos asegurado de actualizar antes de realizar estos pasos no deberíamos tener ninguna actualización pendiente.

Como yo he indicado en las preferencias que se instalarán paquetes de sid cuando yo quiera probamos a instalar amule con:

aptitude install amule/unstable

aptpinnng01

Vaya!! Parece que tenemos un problema de dependencias, en ese caso vamos a intentar instalar amule buscando las dependencias que faltan también de la rama unstable:

aptitude -t unstable install amule

aptpinning02

Y ahora sí ya se deja instalar y ejecutar.

En cualquier caso como opinión personal no soy muy amiga de utilizar un sistema mixto mezclando diferentes ramas y no es algo que vaya a utilizar con frecuencia, de hecho muy pocas veces lo he necesitado, solo en casos muy puntuales como este y porque es algo que me apetecía probar y saber como funcionaba.

Fuentes: Debian Wiki AptPrefefences, esDebian – Sistemas mixtos, Geekland – Apt-pinning en Debian.

Leer Más

gdm-screenshot.redimensionado

Cambia el fondo de inicio de sesión GDM en un plis plas

Recuerdo que hace ya, en los tiempos de Gnome2, me entretenía personalizando mi linux con temas, iconos, wallpapers, el fondo para grub, el tema del GDM… Con la llegada de gnome-shell dejé un poco de lado la personalización, lo más básico, unos iconos, un wallpaper y quizás algún tema, tampoco sé si al comienzo de gnome-shell era posible cambiar el theme del GDM como antaño, era algo que dejé un poco de lado, no como algo prioritario si total es algo que veo durante 3 segundos, al igual que el menú de grub, me da un poco igual como sea y en cualquier caso como es algo que veo durante tan poco tiempo después ya no me acuerdo ni lo tengo tan presente, no es como el fondo de escritorio o los iconos que los tienes permanentemente en pantalla.

De vez en cuando me gusta leer las wikis de las distros que utilizo, porque siempre aprendo algo nuevo o aprendo algún truco que no conocía o me refresca la memoria de algo que tenía pendiente de hacer y no he hecho aún, como en este caso con el asunto de cambiar el fondo a la pantalla del login del gestor de inicio de sesión, en mi caso GDM, es de esas cosas no tan importantes que sabes un día tienes que hacer pero que nunca haces. Al final me he decidido, customizar un poco nuestro sistema tampoco está tan mal. Solo un par de pasos y un asunto menos. No he profundizado en añadir temas como se hacía antes, con gnome2, en los que aquellos gdm-themes modificaban un poco más la apariencia porque con el cambio de wallpaper de momento me sirve, de todas maneras creo que para ello hay una aplicación que se llama GDM3Setup que te permite elegir el tema, el fondo, el icono, etc. Yo no lo he probado pero en Archlinux se puede descargar desde AUR y en otras distribuciones o instalación manual tenéis más info en la web donde se aloja el proyecto Github – GDM3Setup.

Pero en cualquier caso si no queremos instalar ninguna aplicación adicional en un par de pasos podemos modificar el fondo de nuestro GDM.

Elegimos una imagen que nos guste, yo he elegido una llamada water.jpg que se encuentra en la carpeta Imágenes de mi usuario y la copiamos al directorio /usr/share/gnome-shell/theme/

#cp /home/usuario/Imágenes/water.jpg /usr/share/gnome-shell/theme/water.jpg

Editamos el archivo /usr/share/gnome-shell/theme/gnome-shell.css para indicar el nombre de la imagen correcta y la resolución:

#nano /usr/share/gnome-sell/theme/gnome-shell.css

Por defecto aparece así:

#lockDialogGroup {
   background: #2e3436 url(login-background.png);
   background-repeat: no-repeat;
 }

Y lo modificamos de esta manera:

#lockDialogGroup {
   background: #2e3436 url(water.jpg);
   background-size: 1680px 1050px;
   background-repeat: no-repeat;

Como véis he cambiado el nombre del archivo que hacía referencia a la imagen por el nombre de la imagen que yo he copiado water.jpg y he añadido la resolución de mi pantalla para que se vea de manera correcta background-size: 1680px 1050px;

Como el archivo es un poco largo, para no perdernos buscando las líneas que hemos de editar podemos hacer (si usáis nano) CTRL+w que es para buscar y escribir lockDial para que nos lleve directamente donde debemos modificar.

Guardamos con CTRL+x y cerramos sesión para ver como queda:

gdm-screenshot.redimensionado

Existe otra manera que leí en la wiki de Debian, que es editando el archivo /etc/gdm3/greeter.dconf-defaults , también es posible cambiar el fondo, el theme, los iconos y algunas funciones más, se trataría de descomentar la línea que queramos modificar y hacer los cambios oportunos. Personalmente, no lo he probado, pero no parece que tenga mayor complicación.

En ambas distros arch y debian he seguido el mismo procedimiento, el primero que he descrito.

Fuentes: Archlinux Wiki, Debian Wiki

Leer Más

baraja de cartas

Muévete entre directorios rápido y veloz con pushd

Lo de moverme entre directorios por la consola no lo llevo mal, aunque a veces sí que me fastidia un poco tener que escribir algunas rutas completas, he descubierto un comando, que sí que ya sé que es muy viejo, pero yo no lo conocía y a lo mejor alguno de vosotros tampoco. Se trata de pushd que nos facilita el cambio entre directorios cuando tenemos que estar moviéndonos entre varios desde nuestra consola, creando una pila y ahorrándonos escribir la ruta completa.

Adicionalmente usaremos también dirs para que nos guíe y popd para eliminar directorios de la pila que hayamos creado. Al principio parece un poco lioso, pero conforme lo vas usando y vas viendo su funcionamiento ya no parece tan complicado.

Como ejemplo voy a trabajar con 4 directorios, que he eligido al azar para este post, aparte del que me encuentro ahora como directorio de inicio, el home (/home/usuario):

/home/usuario/Descargas
/etc/apt/
/usr/share/
/var/log/

Los voy a ir añadiendo a una pila con el comando pushd:

pushd /home/usuario/Descargas
pushd /etc/apt
pushd /usr/share
pushd /var/log

pushd01

Como a primera vista y si es la primera vez que lo usamos la información no nos queda muy clara usaremos dirs que nos mostrará la pila que se ha creado con un número y el directorio al que corresponde. Ese número es el que utilizaremos para movernos de un directorio a otro sin tener que escribir la ruta completa:

dirs -v

 0  /var/log
 1  /usr/share
 2  /etc/apt
 3  ~/Descargas
 4  ~

Si queréis que se muestre más claro y todo completo:

dirs -l -v

 0  /var/log
 1  /usr/share
 2  /etc/apt
 3  /home/usuario/Descargas
 4  /home/usuario

El directorio numerado con 0 es el en el que nos encontramos, al ser el último que hemos añadido pasa a ser el actual. Para moverme ahora a otro directorio por ejemplo a /usr/share:

pushd +1

Fijaros como después de moverme a este directorio me vuelve a mostrar la pila y como van cambiando.

No hace falta ejecutar dirs -v cada vez, lo pongo para que lo veáis más claro, porque cuando cambiamos de directorio ya nos muestra automáticamente como queda la pila, (está resaltado en amarillo):

pushd02

/usr/share pasa a ser 0 porque es el directorio actual en el que nos encontramos y al que hemos cambiado, el resto han subido un escalón porque iban detrás y /var/log que era en el que nos encontrábamos pasa debajo. Es como si tuvieras una baraja de cartas y las vas moviendo hacia arriba, obviamente como más arriba no hay vuelve a pasar debajo de la pila.

Si ahora nos cambiamos al directorio 3 que sería nuestra carpeta de usuario:

pushd +3

Observad ahora como se han movido, /home/usuario pasa a ser 0, seguido de /var/log que le iba debajo que pasa a ser el 1 y los que había arriba han pasado abajo en orden empujando hacia arriba hasta situarse. Os dejo una imagen para que entendáis mejor como han quedado los directorios:

pushd03

Si queremos saber a que directorio nos va a llevar pushd sin tener que ejecutar el comando podemos preguntarle a dirs:

dirs +4

Y su respuesta es ~/Descargas.

pushd04

Otra cosa muy interesante es poder copiar archivos entre los directorios especificando solamente el número y el símbolo ~. He creado en la carpeta de usuario un archivo de texto simple llamado hola y quiero copiarlo en ~/Descargas, que siguiendo el ejemplo anterior es el directorio 4.

cp hola ~+4

¿Y qué pasa si hay algún directorio al que ya no necesitamos tener que estar cambiando? Aquí es donde entra en juego popd, este comando se encarga de eliminar directorios de la pila que teníamos creada.

Este es el estado en que se encuentra nuestra pila ahora mismo:

 0  ~/Descargas
 1  ~
 2  /var/log
 3  /usr/share
 4  /etc/apt

Y ya no necesitamos más /etc/apt:

popd +4

La pila quedaría sería:

 0  ~/Descargas
 1  ~
 2  /var/log
 3  /usr/share

Si quisiéramos quitar todos los directorios de la pila:

dirs -c

Puede que al principio os resulte un poco lío, pero una vez le coges el truco es muy cómodo.

Fuentes: The Geek Stuff – 6 Awesome Linux cd command Hacks – Productivity Tip#3 for Geeks
CIT050 – pushd and popd
Imagen destacada Pixabay – PDPics

Leer Más

memory-279904_1280

Recordando lo importante, para los despistados: pacmatic y pacnanny

Tengo la buena costumbre, que cada vez que voy a realizar una actualización de mi distribución Archlinux, dedicar unos minutos a leer las últimas noticias que aparecen en la página oficial para ver si hay algo que me pueda afectar y los pasos a realizar en caso afirmativo. También suelo pasarme por los foros de archlinux en español donde suelen poner los anuncios en castellano por si algo se me escapa y a veces también otros usuarios comentan el tema si lo han probado, que errores han tenido, etc etc. Hacer esto no lleva más de unos pocos minutos y nos puede ahorrar mucho tiempo y sorpresas. También hay otros usuarios que están suscritos al feed para mantenerse al día y otros que incluyen el RSS en su conky para verlo en pantalla y tenerlo presente y a la vista.

Bien, he dicho que tengo esa buena costumbre y es cierto que lo hago casi siempre, casi siempre quiere decir el 99% de las veces, venga va el 98% no me las voy a dar ahora de lista, lo que me da un margen de error muy pequeño, pero… puede pasar, justo el día que no lo miras, zasca!!

También hay usuarios que no lo miran nunca o muy de vez en cuando, o cuando se acuerdan, o cuando ya es un poco tarde. Para todos esos despistados, incluso para mí misma por ese 2% de las veces que no lo miro hay un par de herramientas que acuden en nuestra ayuda como recordatorio: “Ehh chaval/a, acuérdate que está pasando esto…”

Se trata de pacmatic y pacnanny.

Estos paquetes se encargan cada vez que vamos a realizar una actualización de nuestra distribución mostrarnos las últimas noticias aparecidas en el feed de archlinux donde como hemos dicho, se avisa de los cambios que nos pueden afectar y los pasos a seguir para realizar una actualización correcta sin romper el sistema. Cuando ha terminado de actualizar nos recuerda los avisos (si los ha habido) que pacman haya podido lanzar y si hay algún paso adicional post-actualización como pueda ser el caso de los archivos pacsave y pacnew.

Pacmatic y Pacnanny son dos paquetes diferentes e independientes, es decir son 2 herramientas que hacen más o menos lo mismo, pero no se necesita la una de la otra ni tienen nada que ver entre ellas salvo que la finalidad es la misma, son dos alternativas distintas, podemos probar ambas y decidir cual nos gusta más.

El uso y los argumentos son los mismos que con pacman pero sustituyendo por pacmatic o pacnanny dependiendo de la opción que hayamos escogido:

pacmatic -Syu
pacnanny -Syu

Pacmatic lo podemos descargar desde los repositorios oficiales con

pacman -S pacmatic

Y pacnanny desde yaourt con

yaourt -S pacnanny

Recuerda que solo son avisos y alertas, las acciones las debemos realizar nosotros manualmente.

Más información:

Pacnanny
Pacmatic

Leer Más