Fedora 21 a través de FedUp. Solución para las "broken dependencies"

Como había señalado en la entrada anterior, la actualización por FedUp había funcionado "casi" perfectamente, y que en la propia actualización, antes de empezar la sustitución de paquetes, la aplicación avisaba de cuáles presentan dependencias rotas, con el desalentador aviso de que instalásemos bajo nuestra responsabilidad ("Continue with the upgrade at your own risk").
A pesar de ello, todo va como la seda... hasta que llamas a uno de esos paquetes, en mi caso R, que es parte intrínseca de mi trabajo. La respuesta es:

Es decir, hemos tropezado con la dependencia rota.

Para solucionarlo simplemento desinstalé a través de yumex (YumExtender) R (R-core, R-core-devel, R-devel, R-java-devel) y luego reinstalé con yum

su -c 'yum install R-core R-devel' # suficiente; los otros son dependencias

Y con eso ya funcionaba. Eso sí, en vez de ser la versión 3.1.2 "Pumpkin Helmet" que ya estaba instalada en Fedora 20, la que está ahora es la 3.1.1 "Sock it to Me".

Es decir, la preparación de Fedora 21 quedó congelada antes de alguna de las actualizaciones de Fedora 20 y hay alguna "regresión" de versión.

Este problema solo me ha aparecido en R, Virtual Manager (virt-manager) y HandBrake. Los dos primeros se han corregido de la misma manera (desinstalación y vuelta a instalar) y handbrake no lo he necesitado, así que no lo he vuelto a instalar (aun).

Y de todas maneras dos días después ya se ha actualizado R a 3.1.2. en Fedora 21.

Fedora, Libreoffice y libcmis. Una historia de impaciencia

Como todas las mañanas, ayer, 24 de febrero de 2014, actualicé mis ordenadores de trabajo.

su -c 'yum -y update'

En todos ellos recibí un mensaje, que recortado decía más o menos

---> Paquete libreoffice-core.x86_64 1:4.2.1.1-1.fc20 debe ser una actualización
--> Procesando dependencias: libcmis-0.4.so.4()(64bit) para el paquete: 1:libreoffice-core-4.2.1.1-1.fc20.x86_64
--> Resolución de dependencias finalizada
Error: Paquete: 1:libreoffice-core-4.2.1.1-1.fc20.x86_64 (updates)
           Necesita: libcmis-0.4.so.4()(64bit)
 Podría intentar utilizar el comando --skip-broken para sortear el problema

Nos indica que hay problemas de dependencias no resultas. Cada vez que ocurre un aviso como este, simplemente tenemos que ejecutar

su -c 'yum -y update --skip-broken'

y se actualiza los paquetes sin problemas de dependencias y los demás esperan.

--> Resolución de dependencias finalizada

Paquetes ignorados por problemas de dependencias:
    1:autocorr-en-4.2.1.1-1.fc20.noarch de updates
    1:autocorr-es-4.2.1.1-1.fc20.noarch de updates
    firebird-libfbembed-2.5.2.26539.0-8.fc20.x86_64 de fedora
    libabw-0.0.2-1.fc20.x86_64 de updates
    libe-book-0.0.3-1.fc20.x86_64 de updates
    libeot-0.01-1.fc20.x86_64 de updates
    libfreehand-0.0.0-3.fc20.x86_64 de fedora
    1:libreoffice-calc-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-core-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-draw-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-emailmerge-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-graphicfilter-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-impress-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-langpack-es-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-math-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-opensymbol-fonts-4.2.1.1-1.fc20.noarch de updates
    1:libreoffice-pdfimport-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-pyuno-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-ure-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-writer-4.2.1.1-1.fc20.x86_64 de updates

Y hoy por la mañana, día 25, al actualizar mis ordenadores de trabajo

su -c 'yum -y update'

.
.
.
---> Paquete libcmis.x86_64 0:0.3.1-8.fc20 debe ser actualizado
---> Paquete libcmis.x86_64 0:0.4.1-2.fc20 debe ser una actualización
.
.
.

Y listo.

El problema está en que entre ayer y hoy el twitter ha estado inundado de avisos de error, que donde se puede encontrar el maldito libcmis 0.4, que debe ser el maldito de todo. Basta con poner en google fedora libcmis y salen páginas y páginas de mensajes de usuarios desesperados por que no pueden actualizar la libreoffice a 4.2.
Bien; yo también estaba esperando la vesion 4.2, entre otras cosas por que por fin tenemos disponible las ecuaciones poligonales

Y se han añadido funciones estadísticas similares al "Analysis ToolPack" de Excel.

No era imprescindible, ya que esas funciones las tenía en gnumeric, pero es interesante añadir funciones similares a las de Excel y que sea más sencillo el cambio de MS Office a LibreOffice para los usuarios de Windows.

Pero de lo que se trata aquí es que podemos tener un poco de paciencia. En los años que llevo en Fedora estas dependencias no resueltas pasan frecentemente, debido a la velocidad de actualización de esta distribución. Este problema se suele resolver en 24-48 horas. ¿Qué podrían decir los usuarios de windows, que tienen que ir actualizando la LibreOffice por la fuerza y si se acuerdan? ¿O los usuarios de Debian?, que seguramente aun están en alguna versión estable 3.x.x.

Un poco de paciencia, por favor, y menos inundar el twitter con minucias.

PD. Y podríamos dar las gracias a los programadores de paquetes como apt-get y yum, que controlan las dependencias y nos hacen la vida (y las actualizaciones) mucho más fáciles. ¿Dónde van nuestros infiernos de dependencias y los viajes al infinito y más atrás en el árbol de las dependencias para instalar cualquier paquete?

Actualización. Firefox y chmsee - problemas de dependencias

He tenido el mismo problema en todos mis ordenadores. La última actualización de Fedora trae Firefox 22, y en mis ordenadores he encontrado el mismo cruzamiento de dependencias:

Es decir, chmsee utiliza esta librería (libxpcom.so) y no permite la actualización de la nueva que viene con xulrunner para Firefox 22. si ejecutamos el comando de actualización con --skip-broken

no se instala Firefox

Uso chmsee en contadas ocasiones, pero Firefox vive conmigo todo el día (y noche), hasta en el móvil (lo cambié solo para poder tener Firefox), así que desinstalé chmsee

Y así firefox se instaló fácilmente

Por curiosidad, luego intenté instalar de nuevo chmsee, por si la dependencia no se cumplía al revés, pero chmsee necesita la librería anterior y no se instaló.

Y así en 3 sobremesas.

Últimas semanas. Fedora 18

En los últimos días no he traído nada nuevo en el blog por que he estado bastante ocupado instalando el sistema en mi ordenador principal. La historia ha sido más o menos así:
1. El 27 de enero instalaba en el ordenador principal Fedora 18

mediante FedUp.Las primeras impresiones las podéis leer aquí. Podría destacar especialmente los cambios que trae gnome 3.6 en Nautilus y los problemas iniciales con el repositorio de Dropbox. La actualización por FedUp hace que el inicio no muestre el panel gráfico que se ve al instalar de limpio, pero lo que llevó a una instalación nueva fue un bloqueo aleatorio del sistema gráfico, que me impedía refrescar la pantalla y podía ver en terminales que los programas gráficos estaban funcionando pero no podía acceder a ellos.
2. El 16 de febrero instalé de forma limpia Fedora 18. Seguía teniendo bastantes problemas, así que tuve que activar las teclas mágicas, cuya localización ha variado en Fedora 18. Se generaron nuevos problemas:
- Anaconda no pide nombre identificativo para el ordenador (o yo me salto algún botón sin darme cuenta), con lo cual aparece identificado como new-host (problema general que es fácil de solucionar, aunque lo descubrí después)
- Ciertos programas, pero especialmente aMule, se apagaban sin previo aviso, lo que me obligó a generar un script para reiniciarlo.
- Se generaba una cascada de dependencias entre programas, de tal manera que al llamar a un fichero de LibreOffice desde Nautilus, el fichero solo se abría al cerrar Nautilus. Para poder hacer funcionar otros, tenía que matar el terminal y finalmente era casi imposible trabajar con el sistema gráfico. En general solo me afecta en el movimiento de ficheros, ya que últimamente trabajo fundamentalmente en terminal. Aun así, en ocasiones el sistema gráfico estaba completamente bloqueado y tenía que trabajar en las pantallas de texto (de Ctrl+Alt 2 hasta 7) y, de hecho, tenía activa siempre la 2 para poder matar procesos gráficos que bloqueaban a otros mediante la identificación por top y uso intensivo de kill.
3. Como daba la sensación de que parecía haber una "herencia" de unas instalaciones a las siguientes, y pensando que el formateo del disco de sistema no era tal formateo, por que es un disco sólido, y aprovechando de que es bastante antiguo, lo cambié por un INTEL 520 de 60GB, que sale en un precio razonable, e instalé de nuevo Fedora de limpio. Me generó de nuevo un ordenador new-host, pero lo cambié con la orden

hostnamectl set-hostname --static

que descubrí aquí, ya que ahora el nombre está en  /etc/hostname y no en /etc/sysconfig/network.

Estado actual. Debido al cambio de disco, el sistema es mucho más rápido (se nota muchísimo); sin embargo, después de haberlo usado sin problemas varias horas, volvieron a aparecer dependencias de unos programas sobre otros. En general el proceso responsable parece ser nautilus, y una vez que un programa se niega a abrirse, hasta que se cierra nautilus nada parece funcionar. Como falta poco para el nuevo openSUSE 12.3, estoy pensando seriamente probarlo, incluido KDE. Si no me convence, lo que si tenemos en cuenta lo poco que me gusta KDE es casi seguro, me pasaré al que nunca falla, Debian Stable. Ya tengo preparado el 6.0.7 que salió el sabado, 23.Me va a costar, ya que he estado muy contento en Fedora. Las actualizaciones son muy rápidas y, hasta ahora, no he tenido problemas de estabilidad o seguridad. Además, tengo 5 ordenadores funcionando con Fedora 18 y solo el principal genera problemas (será por que es al que más le pido).

Hoja de cálculo en terminal. Imposible la instalación en Fedora

Por pura curiosidad, y siguiendo mi interés en aplicaciones para el terminal (y recordando el mítico Lotus 123 que usaba hace mucho mucho tiempo), he buscado una hoja de cálculo en terminal. Una de las opciones es oleo, en teoría una hoja de cálculo que nos permitiría trabajar con pocos recursos, por ejemplo en el RaspBerryPi. Se baja el fichero de código fuente y se instala de forma habitual. Primero se descomprime

tar -xzvf oleo-1.99.16.tar.gz

a lo que seguiría la secuencia

./configure
make
make install # esta última como administrador

pero no he podido pasar de ./configure, ya que se produce un error en ella y se queda colgado en un bucle infinito, con lo cual no podemos llegar a make. Y no soy el único que ha encontrado este bucle. Lo he probado en Fedora 16 y 17, con 32 y 64 bits.

En las distribuciones derivadas de debian hay paquetes binarios deb, y para Fedora paquetes rpm (descarga). El paquete está preparado para mandriva y genera unas dependencias que no he podido resolver

En resumen, no he encontrado la forma de instalarlo. Tampoco estoy muy preocupado, ya que en hojas de cálculo normalmente me sirvo de gnumeric, y en ocasiones calc. Era simplemente una búsqueda de otra aplicación en terminal.

"Infierno de dependencias", episodio primero

Como usuario "moderno" de Linux, y cubierto por nuestro amigo apt-get, nunca había sufrido el terrible "infierno de dependencias"... hasta hoy. En un ordenador recién instalado Ubuntu 10.10 no me funciona LA impresora, una HP Laserjet 1020; bueno, no funciona cuando no quiere, y si quiere sí. Algo cansado de tanta molestia, bajé el nuevo hplip (hplip-3.10.9), aunque en teoría podría instalarse directamente por Ubuntu desde 10.04. Ejecuto la orden, sh hplip-3.10.9.run y ahí empezó el calvario. Me avisa de 5 dependencias, y las voy instalando, luego 7 más y también las instalo, luego 1 y de nuevo la instalo. Finalmente llego a la configuración de la impresora y dice que no existe aparato alguno que pueda detectar y que adiós. Reinicio el sistema y me imprime 14 hojas, para luego decir que tal impresora falla (hp failed) y adiós otra vez. Dos horas de instalación de paquetes para que al final solo funcione cuando quiere. Ya he leído a un usuario que con el ordenador apagado enchufa la impresora, conecta el USB y arranca el ordenador; en esas condiciones funciona, sin configurar ni nada. Si se intenta algo, deja de funcionar. Pues bien, tomo nota, aunque en teoría eso se había solucionado en Ubuntu 10.04. De todas maneras, mañana cambio en cable USB, no vea que sea algo tan simple. Si aun así no funciona, seguiremos con medidas más drásticas (por ejemplo, tirarla por la ventana). Pero aun tengo experiencias más interesantes (o ridículas, según se mire). Cuando tenga otro ratito las contamos.

Se puede trabajar sin red

A pesar de lo que decía el otro día, se puede trabajar sin estar conectado a red. Como sospechaba que en el laboratorio donde tenía que impartir las prácticas de hoy por la tarde no había cobertura inalámbrica, llevaba grabado en home el fichero de presentación. Por suerte, no hubo necesidad de recurrir a fotos o datos externos, así que se pudo trabajar sin problemas. Algo incomodo, pero se puede. Solo hay que tenerlo previsto y llevarse todo puesto. Eso si, ante las incidencias imprevistas, no te va a salvar ni Google ni nadie que llegue via Internet (por ejemplo, en mi caso, mapas de distribución de enfermedades, tablas oficiales de prevalencias...).

Dependencia de Internet. Trabajo en la "nube"

Esta es una pregunta que me hago sobre mi mismo. Ahora trabajo sobre Dropbox, por lo tanto, en la red, además de sobre mis ordenadores; ¿estoy en la nube? Por que realmente estar en esta "nube", además de tener los ficheros sincronizados en la red y mis ordenadores, será también trabajar en aplicaciones on-line, con un sistema operativo muy similar a un navegador y un ordenador bastante "tonto". ¿Por qué me hago esta pregunta? Hoy, como de costumbre, he llegado a clase y la he dado cargando las presentaciones en Impress desde Dropbox. Sin embargo, esta vez ya no llevaba ni un pendrive en el bolsillo por si fallara la red, y ni siquiera he pensado en ello. De hecho, me estoy haciendo tan Internet dependiente que cuando pensaba ayer por la noche qué podría pasar si me fallaba Dropbox, la segunda copia de seguridad que estaba probando era Zoho. Además de estar suscrito a Dropbox y Zoho, también tengo las presentaciones en Slideshare. Hasta el año pasado, en que empecé a usar Dropbox, ponía las presentaciones en uno de mis correos Gmail, y previamente tenía mi ordenador compartido en red y accedía a los ficheros desde las aulas. En todo caso, todas estas herramientas que llevo usando más de una década dependen de la parte más débil de todo el entramado, la conexión a la red. Si falla la conexión a la red, no tengo presentaciones, ni fotos, ni problemas, ni esquemas, ni listas de alumnos (ya no usamos fichas).... De todos los fallos posibles (fallo de ordenador, de proyector o de conexión a la red, el más frecuente es la pérdida de conexión. Y sin embargo, cada vez soy más reticente a usar pendrives, a almacenar los datos solo en el disco duro. Es decir, aun conociendo las debilidades del sistema, me estoy haciendo dependiente de él, y encima esa dependencia me gusta. Si estuviera en los Estados Unidos estaría discutiendo esto con el psiquiatra. Aquí, en España, solemos discutir estas cuestiones con los camareros de los bares, pero como no bebo, solo podré discutirlo con el ordenador y un café. ¡Ah!, y con la red, miríadas de seres humanos con sus ordenadores y sus cafés, en densidades superiores a 1000 por kilómero cuadrado, pero conectados solo a través de esta red tan frágil y formando esta "nube" tan etérea. Rodeados de gente, y tan solos.