error

6 entradas

error al iniciar sesión en skype con debian sid

Es lo que tiene Debian Sid, que nunca tienes un momento de descanso. El último lío, con skype. Al ejecutarlo e introducir usuario y contraseña, la ventana se cerraba y arrojaba el siguiente mensaje (por consola):

Inconsistency detected by ld.so: dl-open.c: 643: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!

Tras bucear en foros, blogs y demás fuentes del saber, utilicé una solución que me suele dar resultado, en estos líos de bibliotecas de código (mal llamadas librerías). Al parecer, la última actualización del paquete libpulse había dejado un par de enlaces rotos que apuntaban a ficheros que no existían. En el foro de desarrollo de skype recomendaban bajarse los paquetes correspondientes de debian, descomprimirlos y copiar las librerías de nuevo pero esa solución no funcionó.

Mi solución, más casera que las croquetas de mi güela, es la siguiente:

$ l /usr/lib32/lib*pulse*so*
lrwxrwxrwx 1 root root 24 dic 16 15:30 libpulse-simple.so -> libpulse-simple.so.0.0.1
lrwxrwxrwx 1 root root 24 dic 16 15:30 libpulse-simple.so.0 -> libpulse-simple.so.0.0.2
---------- 1 root root 12K jul 24 2009 libpulse-simple.so.0.0.2
lrwxrwxrwx 1 root root 17 dic 16 15:30 libpulse.so -> libpulse.so.0.4.1
lrwxrwxrwx 1 root root 17 dic 16 15:30 libpulse.so.0 -> libpulse.so.0.8.0
---------- 1 root root 234K jul 24 2009 libpulse.so.0.8.0

Los enlaces libpulse-simple.so y libpulse.so están huérfanos, así que los borré y los cree de nuevo, esta vez apuntando al la librería correcta.

$ sudo ln -s libpulse.so.0.8.0 libpulse.so
$ sudo ln -s libpulse-simple.so.0.0.2 libpulse-simple.so

¡Et voila! Skype arranca sin problemas y con esa interfaz grumosa a la que ya casi me estoy acostumbrando. 😀

nombres de ficheros en blanco al instalar paquetes

Mamá, éste es un tema técnico que, si soy sincero, ni yo mismo termino de entender :). Puedes ahorrártelo con confianza.

Esta mañana, al intentar instalar o actualizar paquetes en mi estación de trabajo, me topaba constantemente con el mismo mensaje:

Escribiendo información de estado extendido... Hecho
(Leyendo la base de datos ... 10%
dpkg: warning: files list file for package `ncurses-base' missing, assuming package has no files currently installed.
(Leyendo la base de datos ... 85%dpkg: error fatal irrecuperable, abortando:
el fichero de lista de ficheros del paquete `openoffice.org-base-core'
contiene un nombre de fichero vacío
E: Sub-process /usr/bin/dpkg returned an error code (2)
Un paquete no se pudo instalar. Intentado recuperarse:

o, en inglés:

(Reading database ... 10%
dpkg: warning: files list file for package `ncurses-base' missing, assuming package has no files currently installed.
(Reading database ... 85%dpkg: unrecoverable fatal error, aborting:
files list file for package `openoffice.org-base-core' contains empty filename
E: Sub-process /usr/bin/dpkg returned an error code (2)
A package failed to install. Trying to recover:

Tras bucear un poco la red, llegué a la conclusión de que había un problema con los ficheros del paquete openoffice.org-base-core en el directorio /var/lilb/dpkg/info/. Normalmente, si el error menciona un fichero concreto, como /var/lib/dpkg/info/openoffice.org-base-core.list, éste suele tener algún caracter raro que se ha colado al procesarlo apt. Suele decir hasta la línea en que se encuentran los marcianos y basta con ir, limpiar y actualizar.

Pero esta vez era diferente (por eso lo escribo aquí, para recordarlo 🙂 ) y, al ver que los métodos tradicionales no funcionaban, me decidí por algo bastante más expeditivo, como es mover el fichero problemático, esperando que genere uno nuevo. En el error se hace mención a el fichero de lista de ficheros del paquete `openoffice.org-base-core', por lo que el comando a ejecutar era el siguiente:

$ sudo mv /var/lib/dpkg/info/openoffice.org-base-core.list /var/lib/dpkg/info/openoffice.org-base-core.bak

Tras él, actualización e instalación de los paquetes sin problemas.

drupal, panels y demás hierbas

Estoy aprendiendo, por el camino más doloroso posible, que hay ciertas cosas en drupal que no deben ser intuidas. Uno que creía que tenía un montón de horas de vuelo, que ya no era tan fácil hacerle perder los papeles, que presumía de tener una copia de seguridad para cada historia y, en tres cómodos clic, el infalible se llevó por delante una web.

Desde hace seis meses mantengo un sitio web con este CMS y el módulo panels para hacer portadas y páginas más o menos estáticas sin esfuerzo. En su versión 5.0.x y durante medio año, drupal y panels funcionaron estupendamente, complementándose y facilitando el trabajo hasta niveles que desconocía. ¡Llegaron incluso a hacerme pensar en abandonar Wordpress! Los números de la revista del taller iban saliendo sin complicaciones, el sol campaba a sus anchas por el cielo y yo, ingenuo de mí, sonreía feliz.

Pero para el número de febrero se me ocurrió añadir categorías a la web, pensando que sería sencillo (todo en drupal lo es), rápido de echar a andar y tan intuitivo de usar como en Wordpress. Y ahí comenzó todo. Busqué un modulo que hiciese algo parecido a las categorías, leí documentación, me asombré de las buenas críticas que tenía el programa, de lo mucho que flipaban algunos con él, lo subí a la web y le di al Play. Las categorías, poco a poco, se fueron adueñando de la web, pidiendo más módulos y avanzando inexorablemente hacia el abismo. Al cabo de tres módulos, lo único que podía hacer con el sistema era pegarle cabezazos a la pantalla del ordenador, con todo lo que eso soluciona. Harto, cansado y con un número por editar, resolví huír hacia adelante y actualizar la versión de drupal. ¡Con dos cojones!

Así que llevo unos cuantos días haciendo copias de seguridad, bajando software, subiendo toneladas de ficheros y módulos al ftp y restaurando la copia de seguridad. Todo con la idea de que, con la versión 6 de drupal se solucionarían los problemas y todo quedaría en un mal sueño y unas horas perdidas. Pero no, tras la restauración, los paneles que una vez fueron benditos, ésta vez eran la causa de mis desvelos. No funcionaban, no se mostraban bien, no hacían nada de lo esperado y, para postre, daban un error muy feo al intentar crear nuevas páginas:

drupal "Unknown column 'load_flags' in 'field list' query:"

Tres días después de vernos las caras por primera vez, encontré la solución en un rincón perdido de internet y olvidado por google. Al parecer, la migración de la versión 5 de panels a la 6 es lo más sucio que se ha visto en mucho tiempo y la solución pasa por desinstalar el módulo para que borre las tablas de la base de datos. Hay que hacerlo bien, desde el botón Desinstalar en la sección Módulos de la administración de drupal. Una vez concluida la operación se puede volver a activar el módulo y usarlo con normalidad. Eso sí, todos los paneles creados hasta la fecha pasan a engrosar la lista de “daños colaterales”. Limpio, rápido y sencillo.

Una semana y pico después, la web cuenta con un CMS actualizado y limpio, estoy reescribiendo el tema para volver a darle su antiguo aire y todavía tengo que editar un número. Sólo los mediocres se habrían dejado llevar por el pánico…

la pesadilla del mono loco

Con éste título me voy a ganar, aproximadamente, trescientas visitas al mes, pero la ocasión lo merece. Esta tarde, al llegar de Sevilla, tuve mi primera hostia en la frente con el portátil, con coyote.n1mh.org.

El disco duro interno empezó a dar muestras de cansancio, a ralentizar el funcionamiento del equipo y, finalmente, lo hizo inutilizable. Lo último que ví antes de reiniciarlo por las buenas fue un estupendo hda: block error {0x00…}, síntoma de que se trata de un problema físico del dispositivo.

Mecagonmismuelas… Mañana trataré de hacerle el vudú que revive los discos duros y, sino, haré una copia de seguridad y buscaré uno de esos chismes por Mérida.

PD Gracías, Victor, por el ubuntu desde el que escribo…

disco duro, error, ubuntu

volver, volver

Mamá, a pesar de ser mi fan número uno, este es un comentario técnico, es decir, aburrido.

Finalmente, tras la enésima prueba, la base de datos ha cedido y vuelve a mostrar eñes, tildes y alguna cedilla, los caracteres normales para los paises del sur de Europa, los latinos. Ya, precioso, pero entonces… ¿por qué estuvo en kurdo una semana? Simple y fácil: por que indo es, en lo que al servidor de bases de datos se refiere, muy moderno y webhostingbuzz.com, mi nuevo hosting, muy conservador.

Empleo (Wordpress emplea) MySQL como gestor de bases de bases, pero es independiente de la versión instalada. indo, como tipo marchoso e inconsciente que es, tiene MySQL 5.0, una de las últimas versiones, mientras que el hosting, ellos sabrán, atesoran una 4.0.25, una reliquia.

Para terminar de añadir encanto, el MySQL 4.1 o superior es incompatible con MySQL 4.0.25 o inferior y la primera utiliza UTF-8 como codificación estándar, mientras que la segunda emplea Latin-1.

Así que el panorama era alentador: tenía un fichero de la versión 5.0 con caracteres UTF-8 y necesitaba un fichero Latin-1 para 4.0. Las instrucciones para obtener un fichero SQL desde 5.0 compatible con 4.0 están en este enlace. Pero faltaba traducir los caracteres no ASCII a Latin-1. Tras intentar encontrar un proceso mediante la base de datos y harto, muy harto, de vueltas y más vueltas, anoche me dió por abrir el fichero SQL con un editor de texto, buscar caracteres raros, deducir el caracter bueno (tildes y eñes) y reemplazar unos con otros. Lo subí al servidor y carretera.

Por el camino se han quedado muchos esfuerzos, incluidos los de las gentes del hosting que, hasta las narices de mi persona (intuyo), hicieron pruebas con bases de datos, creando, migrando, etc… y llegaron a crear un weblog alternativo, monito.

monito

Si todo el correo era en inglés, ¿de dónde sacaron que los monos tienen monitos?

webhostingbuzz.com, mysql, utf-8, latin1, linux, debian, error