Cierre

Aprovecho para cerrar oficialmente este blog.

Ya he aprendido lo suficiente, y los sistemas Linux son cada vez más fáciles y sencillos, de forma que ya no necesito documentar mis avances o soluciones por ser triviales.

Manifiesto en defensa de los derechos fundamentales en internet

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que...

1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Este manifiesto, elaborado de forma conjunta por varios autores, es de todos y de ninguno. Si quieres sumarte a él, difúndelo por Internet.

Jugando con la carga de módulos del kernel: rtc y rtc_cmos

Desde hace un tiempo vengo observando que al arrancar el sistema se trata de iniciar el servicio mplayer, devolviendo un error:

MPlayer: loading module rtc
FATAL: Error inserting rtc (/lib/modules/2.6.22-2-k7/kernel/drivers/char/rtc.ko): Input/output error Failed! ....
creating /dev/rtc, Error! cannot find /proc interface for max-us er-freq.

Investigando un poco parece que trata de cargar el módulo rtc y después hacer modificaciones en max-user-freq. Se supone que esto mejora la respuesta en tiempo real, cosa que beneficia a mplayer a la hora de reproducir el contenido multimedia sin saltos ni cortes.

El problema es el módulo rtc_cmos, que se carga antes de iniciarse el servicio mplayer. Este módulo impide la carga del módulo rtc por ser incompatibles (no pueden estar ambos cargados).

Tras iniciarse el sistema puedo descargar el módulo rtc_cmos mediante:

# rmmod rtc_cmos

Y cargar el módulo rtc:

# modprobe rtc

Tras esto, trato de iniciar el servicio mplayer, está vez con éxito:

/etc/init.d/mplayer start
MPlayer: raising max-user-freq of RTC from 64 to 1024

Efectivamente, parece tener un mejor comportamiento a la hora de reproducir vídeo y audio. Vamos a intentar hacer que cargue rtc al iniciarse el sistema.

modconf es un programa de Debian que permite configurar los módulos que se cargan al inicio. El módulo rtc_cmos (PC-style 'CMOS') se encuentra bajo la rama /kernel/drivers/rtc, y el módulo rtc (Enhanced Real Time Clock Support) se encuentra bajo la rama kernel/drivers/char.

Ninguno está seleccionado para ser cargado. Si selecciono rtc para ser cargado falla la carga por que durante el arranque se carga antes rtc_cmos.

Bien, probemos otra cosa. El fichero /etc/modprobe.d/blacklist contiene una lista de módulos que no se deben cargar. Se puede poner ahí el módulo rtc_cmos a ver si evitamos su carga. Pero en dicho archivo pone:

# This file lists modules which will not be loaded as the result of
# alias expansion, with the purpose of preventing the hotplug subsystem
# to load them. It does not affect autoloading of modules by the kernel.
# This file is provided by the udev package.

Mala pinta, no creo que funcione... y efectivamente no funciona.

Última solución, el fichero /etc/rc.local. Este fichero se ejecuta al final del arranque multiusuario y sirve para especificar órdenes que se quieran ejecutar al final del arranque (se entiende que para hacer algún ajuste fino del sistema). No me gusta mucho, pero ahí se pueden añadir las siguientes líneas:

rmmod rtc_cmos
modprobe rtc
/etc/init.d/mplayer start

Así se descarga el módulo rtc_cmos, se carga el módulo rtc y se inicia el servicio mplayer que modifica el max-user-freq de 64 a 1024 y que aparentemente mejora la respuesta en tiempo real (esperemos que no provoque otros efectos no deseados).

Copias de seguridad con Rsync

Actualmente se guarda demasiada información en los ordenadores personales como para arriesgarse a una pérdida de datos debido a un falló del disco duro, subidas de tensión y otros desastres varios.

Es posible ir haciendo copias de seguridad en DVD, pero es lento, tedioso, y los DVD son ya algo pequeños comparado con la capacidad de los discos duros. Además, la durabilidad de un DVD no está especialmente asegurada. Personalmente, creo que es un medio muy poco fiable.

También es posible usar RAID, pero es quizá una solución no demasiado adecuada para este problema. Ciertas configuraciones de RAID permiten tener dos discos duros con la información duplicada en ambos de forma transparente al usuario. Sin embargo, exige dos discos duros iguales, copia toda la información sin posibilidad de discriminar la que es interesante de la que no, y además puede tener ciertos efectos secundarios no deseados (la velocidad de escritura puede ralentizarse, aunque bien es cierto a cambio puede incrementar la velocidad de lectura). También hay que tener en cuenta que mediante RAID un error humano o de software que borre o sobreescriba datos y ficheros no es recuperable ya que el sistema operativo se encargará transparentemente de hacerlo en ambos discos duros a la vez.

La solución escogida aquí es hacer una copia de seguridad mediante rsync a otro disco duro. Rsync se encarga de hacer el trabajo sucio de copiar el contenido de los datos originales a la copia de seguridad. Es inteligente, por lo que sólo copia los ficheros que han sido alterados y es capaz de enviar solamente aquellas partes de cada ficehro que han sido modificadas, ahorrando mucho tiempo, especialmente si la copia se hace a través de la red.

En Kriptópolis hay un excelente artículo al respecto que permite realizar cuatro copias incrementales al día más una completa, guardando las 3 últimas copias de seguridad. Dado que ahí esta muy explicado el asunto de hacer copias de seguridad en local, me centraré en la copia vía red.

Opciones rápidas de rsync:

• a: copiar para archivar. Es un atajo que combina otras opciones que básicamente produce que se haga una copia exacta (archivos, enlazes simbólicos, permisos, etc).
• v: indica que se debe mostrar información de la ejecución (el conocido modo verboso).
• z: comprime los datos antes de enviarlos al destino (sólo es realmente útil en copias vía red).
• e rsh: sirve para transmitir los datos vía red por ssh.
• n: ejecución de prueba, muestra lo que haría pero realmente no hace nada.
• exclude-from=FICHERO: se deben excluir los directorios y rutas contenidos en el fichero indicado (se pueden usar caracteres comodín).

Así, para realizar una copia remota se debería usar el comando:

rsync -e ssh -azv ORIGEN DESTINO

Suponiendo, como yo, que se quiera copiar el directorio del usuario pepe de un sistema a un directorio de copias de seguridad del servidor llamado Sancho, el comando sería:

rsync -e ssh -azv /home/pepe sancho:/var/backups/pepe

Dado que estamos accediendo a un sistema remoto se debe tener permiso para acceder a dicho sistema. En principio (imagino) se pedirá usuario y contraseña. Dado que se pretende automatizar la tarea lo suyo es configurar una autentificación mediante clave privada/clave pública tal y como permite SSH.


Nota: Comentarios cerrados debido a la continua avalancha de spam chino en esta y solo en esta entrada. Misterios de internet.

Error de glibc en todas las aplicaciones GTK

Desde hace unas semanas todas mis aplicaciones GTK fallan al iniciarse. El error, visto desde la consola, viene a ser algo así como:

*** glibc detected *** double free or corruption (fasttop): 0x081e35a0 ***

Buscando en Google encuentro un mensaje en el que comentan que se debe a que glibc ha detectado un error en el programa y por tanto éste ha sido abortado. Eso ya se podía deducir del error, pero también cuenta que se puede establecer un comportamiento determinado en caso de encontrar estos errores mediante la variable de entorno MALLOC_CHECK_:

By default, the program that generated this error will also be
killed; however, this (and whether or not an error message is
generated) can be controlled via the MALLOC_CHECK_ environment
variable. The following settings are supported:

0 -- Do not generate an error message, and do not kill the program
1 -- Generate an error message, but do not kill the program
2 -- Do not generate an error message, but kill the program
3 -- Generate an error message and kill the program

Probando a poner 0 ó 1 consigo que algún programa sencillo se ejecute, pero siguen fallando, como por otro lado cabría esperar.

Tras un rato hablando en #debian en freenode me dicen que debe haber por ahí algún follón de versiones de paquetes, versiones en testing con versiones en experimental. Me recomiendan confiar en la sabiduría de aptitude, ya que apt no es capaz de solucionar nada (simplemente no encuentra ningún problema). Una vez me aseguro de que sólo tengo repositorios en lenny confio en aptitude. Me indica que va a desinstalar medio KDE y parte de GNOME. Se supone que si elimina paquetes es porque hay algún tipo de problema con ellos.

Tras desinstalar las aplicaciones GTK vuelven a funcionar. Punto para aptitude. Vuelvo a instalar los paquetes que he desinstalado, y vuelven a fallar. Raro, raro. Finalmente, aislo 6 paquetes que si están instalados impiden a las aplicaciones GTk (y no sólo a las de GNOME) iniciarse:

tk2-engines-pixbuf
industrial-cursor-theme
gtk2-engines-spherecrystal
gnome-themes
gnome-themes-extras
gnome2-user-guide

Es posible que alguno no sea responsable, pero no he querido afinar más. He probado a desinstalarlos usando la opción de purgado de ficheros de configuración por si era un problema de una determinada configuración extraña, pero no ha funcionado. Es algo que hay en esos 6 paquetes.

Dado que uso KDE no me preocupa el aspecto de GTK, siempre y cuando funcionen las aplicaciones.

Se admiten sugerencias.

Solución para el problema de Flash sin sonido para Debian Sarge

En este blog cuentan como solucionar el asunto del flash sin sonido para Ubuntu, pero como bien dicen en algún comentario más abajo funciona también para Debian Sarge, al menos a mí me funcionó.

La solución la reproduzco aquí por ser muy corta. Sólo se necesita:

• Tener instalado el paquete alsa-oss
• Tener la línea FIREFOX_DSP="aoss" en el fichero /etc/firefox/firefoxrc.
  

Después basta con arrancar o reiniciar Firefox para que funcione.

Jugando con Apache 2

Comprensión básica de la configuración de Apache. Este envío se basa la lectura rápida de documentación en la web, ensayo y error y deducciones un tanto a la ligera de los resultados obtenidos. No se fie.

Apache soporta servidores virtuales, que es como decir que una sóla máquina da la impresión ser varios servidores web. La mayor implicación de ello es que cada servidor virtual tendrá su propia configuración y comportamiento independiente del resto.

No sé muy bien como va, pero desde luego mi servidor Apache que por el momento sólo neceisto que haga de un solo servidor viene configurado con servidores virtuales. Claro que sólo tengo un servidor virtual, así que en la práctica es como si tuviese un sólo servidor web sin virtualizar.

Después de este aparente juego de palabras, pasamos a cosas más interesantes.

La configuración se situa, normalmente, en /etc/apache2. Cuando digo configuración no me refiero a un fichero, sino a toda la configuración del servidor que no se reduce a un solo archivo. En todo caso se debe comprobar la directiva ServerRoot que indica a Apache a partir de que directorio debe de entender que se situa toda la configuración.

Existe un fichero de configuración general, pese a que en todas las páginas aparece httpd.conf en mi caso es apache2.conf. ¿Serán cosas de Debian?

Aparte, por cada servidor virtual existe otro fichero de configuración. Supongo que podrá no existir y se tomarán los valores del fichero general. De hecho Apache define una jerarquia de configuraciones, de manera que se pueda decidir que valor se aplica cuando hay configuraciones cotnrarias. Temo que no puedo explicar cuál es esa jerarqui por temor a equivocarme.

En el directorio de configuración (ServerRoot) hay dos directorios, sites-enabled y sites-available. Parece ser que sites-available contiene la configuración de cada servidor virtual en un fichero lamado default (lo cuál me hace pensar que probablemente pueda haber más ficheros de configuración en ese directorio, o más configuraciones alternativas o vaya usted a saber que festival de configuraciones, ficheros y bytes revenidos podría uno encontrar allí), pero es en sites-enabled desde dónde están enalzadas. Por ejemplo, mi servidor está así:

#ll sites-available/
total 4
-rw-r--r-- 1 root root 1153 2006-07-26 00:08 default
# ll sites-enabled/
total 0
lrwxrwxrwx 1 root root 36 2005-05-25 05:56 000-default -> /etc/apache2/sites-available/default

Por lo cuál deduzco que en sites-enabled deberá haber un enlace simbólico a sites-available para activar dicho servidor. Los nombres lo dicen; sites-available son los servidores disponibles, que pueden usarse; sites-enabled son los servidores activos.

Así, si queremos tocar la configuración de un servidor virtual, o como en mi caso, del único servidor virtual (que es como decir del único servidor) hay que tocar la configuración bajo sites-available. Parecerá tonto, pero ya estuve bastante tiempo haciendo el canelo editando el fichero de configuración general y viendo resultados rarísimos. Lógico, sólo conseguía cambiar las opciones que no estaban definidas en la configuración particular del servidor virtual.


Una vez no situamos en el fichero de configuración adecuado podemos centrarnos en las directivas. Como ya dije, las directivas establecen la configuración del servidor. Algunas se refieren al servidor en general y otras son una manera de agrupar directivas para un conjunto de elementos. Sin asustarse; los elementos pueden ser ficheros que respondan a un patrón en el nombre, o directorios, o ficheros que cuelgan en un directorio (a grandes rasgos).

Y llegamos a dónde quería llegar yo cuando investigué todo esto. Como evitar que Apache liste el contenido de los directorios a los visitantes. Es decir, que si la URL a mi servidor es un directorio no muestre los contenidos como venía haciendo hasta hoy. Pues basta con poner en la directiva Directory del directorio correspondiente (en el padre si quiero aplicarlo a todos) lo siguiente:

Options -Indexes

Que obviamente indica como opción no (-) indexar el contenido de los directorios (Indexes).

Cabe decir que Apache sólo mostaría el contenido del directorio si se indica una URL a un directorio de mi servidor y en dicho directorio Apache no encuentra ninguno de los archivos mencionados en la directiva DirectoryIndex, directiva que le indica a Apache que ficheros mostrar por defecto cuando se le indica una URL que es un directorio.

En fin, ahí quedan unos enlaces:

• Documentación oficial de Apache 2.
• Descripción de las directivas principales.
• Breve descripción de opciones principales de un manual de SUSE (habrá mejores pero yo he llegado aquí).
  

Relacionandose con la A.E.A.T usando Linux

Parece que nuestra querida A.E.A.T. aún no ha sacado el programa P.A.D.R.E. en una versión compatible con Linux, aunque se comenta que el próximo año será en Java con lo cual será utilizable desde Linux.

Lo que si hay es el cáluclo de retenciones para el ejercicio de 2005 en versión Java. A falta de pan buenas son tortas.

Para usarlo se debe ir uno a la página de programas de ayuda para el ejercicio 2005 y descargar la versión 1.01 para Linux de las retenciones 2005. Es un script Bash que realiza la instalación del programa.

La primera ejecución como usuario normal genera el siguiente error:

$ ./ret5101.bin
Preparing to install...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...

Launching installer...

Unable to locate the application's 'main' class. The class 'com.zerog.ia.installer.Main' must be public and have a 'public static void main(String[])' method. (LAX)
GUI-

No es problema del usuario, con root sucedería lo mismo. El problema es que el programa instalador trata de usar la maquina virtual de Java que hay en /usr/bin/java, que en mi caso a punta a gij (GNU Interpreter Java), la implementación GNU de Java. Por lo que se ve aún le quedan algunos flecos :-(.

Así, yo tengo lo siguiente:

lrwxrwxrwx 1 root root 22 2006-02-04 22:55 /usr/bin/java -> /etc/alternatives/java

Y asu vez:

lrwxrwxrwx 1 root root 34 2006-06-04 00:29 /etc/alternatives/java -> /usr/lib/jvm/java-gcj/jre/bin/java

Mi instalación de Java está en /opt/j2re1.4.2_06/bin/java. Como he tenido que surfear por la red un rato hasta encontrar el error, decido poner la JVM de SUN como máquina virtual por defecto. Basta con crear un enalce simbólico desde /usr/bin/java hasta el ejecutable de SUN:

# ln -s /opt/j2re1.4.2_06/bin/java /usr/bin/

Una vez hecho eso vuelvo a ejecutar el instalador, que se abre correctamente. Pide seleccionar la máquina virtual a usar, basta con dejarle /usr/bin/java para que use la de SUN. Después pide un directorio de instalación y uno de vínculos. Los vínculos son simplemente los enlaces para arrancar el programa y para desinstalarlo, junto con un Leame.txt.

Kopete 0.12 alpha 1 con soprte Jingle (voz de GoogleTalk)

El protocolo Jingle presentado por Google junto a Jabber (comentado en Dirson y Barrapunto) para Jabber que fue acompañado de la libreria Jingle de Google bajo licencia BSD comienza a dar sus frutos. Kopete 0.12 Alpha 1 dispone de soporte experimental para dicho protocolo de voz y vídeo, aunque Kopete por el momento sólo ofrece voz.

Voy a compilarlo y probarlo sobre mi Debian Etch. Descargo y descomprimo el paquete fuente. Consulto la página de dependecias de Kopete para usar Jingle que se resumen en lo siguiente:

Introduction of libjingle require new dependencies to Kopete. Here the list:
-oRTP 0.7.1 http://www.linphone.org/ortp/sources/ (no more, no less, just 0.7.1)
-expat
-glib-2.0 (if you don't have it already for MSN webcam)
-speex (>=1.1.6 or 1.0.5 (the versions that have speex_encode_int ))

Ejecuto ./configure --enable-jingle (esta opción es necesaria para activar el soporte para conversaciones de voz usando libjingle) de cuya salida me fijo en lo siguiente:

[...]
checking for XML_ParserCreate in -lexpat... yes
[...]
checking for ortp... configure: WARNING: oRTP is required to build Jabber Jingle voice support. You can get it from http://www.linphone.org/ortp/
[...]
checking for glib-2.0 gmodule-2.0... yes
checking GLIB_CFLAGS... -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
checking GLIB_LIBS... -Wl,--export-dynamic -lgmodule-2.0 -ldl -lglib-2.0
[...]
checking for speex... checking speex.h usability... no
checking speex.h presence... no
checking for speex.h... no
checking speex/speex.h usability... no
checking speex/speex.h presence... no
checking for speex/speex.h... no
configure: WARNING: Could not find a libspeex version that have the speex_encode_int() function. Please install libspeex=1.0.5 or libspeex>=1.1.6 from http://www.speex.org/
[...]
You have disabled or you are missing required librairies required to compile Jabber Jingle voice support.
Jingle is a new Jabber standard that define a signaling protocol via XMPP for peer-to-peer applications.
Jingle audio is compatible with Google Talk voice offering.

Required Jingle dependencies are listed on this page:
http://wiki.kde.org/tiki-index.php?page=Kopete+Jabber+Jingle

Muy bien, consulto la página de dependecias de Kopete para usar Jingle que se resumen en lo siguiente:

Introduction of libjingle require new dependencies to Kopete. Here the list:
-oRTP 0.7.1 http://www.linphone.org/ortp/sources/ (no more, no less, just 0.7.1)
-expat
-glib-2.0 (if you don't have it already for MSN webcam)
-speex (>=1.1.6 or 1.0.5 (the versions that have speex_encode_int ))

Veamos paso a paso las dependencias:

• oRTP 0.7.1: No está disponible en mi sistema. Descargo el código fuente de la libreria de la página indicada, ejecuto ./configure, make y creo un paquete con checkinstall que procedo a instalar en mi sistema, todo sin problemas.
  
• expat
: Como se ve en la salida de ./configure ya está instalada. Si no debería estar disponible a través de apt.

• glib-2.0
: De nuevo ./configure me informa de que esta disponible en mi sistema.

• speex
:No está en mi sistema, pero a través de apt encuentro el paquete libspeex en la version 1.1.11.1-1, por lo que debería funcionar.

Vuelvo a ejecutar ./configure y obtengo el siguiente mensaje:

[...]
You have disabled or you are missing required librairies required to compile Jabber Jingle voice support.
Jingle is a new Jabber standard that define a signaling protocol via XMPP for peer-to-peer applications.
Jingle audio is compatible with Google Talk voice offering.

Required Jingle dependencies are listed on this page:
http://wiki.kde.org/tiki-index.php?page=Kopete+Jabber+Jingle

Vaya vaya. Reviso la salida del script y encuentro:

[...]
checking iLBC_decode.h usability... no
checking iLBC_decode.h presence... no
checking for iLBC_decode.h... no
configure: WARNING: Could not find ilbc headers or libs. Please install ilbc package from http://www.linphone.org if you want iLBC codec support in Kopete Jabber plugin.
[...]

Así que falta iLBC, sin embargo no se menciona en la página de dependencias. Rebusco por linphone.org pero no hay un paquete instalable o un fuente compilable. Sin embargo hay un enlace a www.ilbcfreeware.org dónde comenta que se puede obtener el código de la siguiente manera: se descarga uno el RFC 3951 (Internet Low Bit Rate Codec) y un script awk; después se ejecuta el script awk mediante el comando:

awk -f extract-cfile.awk rfc3951.txt

El resultado es un monton de archivos .c y .h, de manera que se podría generar una librería a partir de ellos, pero no hay ni makefile ni nada similar. Al fin y al cabio lo se hace es extraer directamente del RFC el código propuesto para implementar el protocolo iLBC, de manera que no se incluye código accesorio, por ejemplo, para crear una libreria. Quizá baste con que el script ./configure tenga acceso a las cabeceras y al código objeto, pero no me veo yo creandome los scripts de compilación.
¿Que hacer? Calmo mi inquietud navengando mediante Google y al rato descubró la información que buscaba. Como comentan en este mensaje del foro de KDE la libreria iLBC es opcional:

iLBC is an optional dependency, so you could just not install it (it's not required for jingle support)

Me alegro, lo dejaré para otro día. Vuelvo a ejecutar ./configure y finalmente me dice:

Supported Jabber Jingle voice Codecs for Kopete:
Speex: yes
iLBC: no
MULAW: yes

Good - your configure finished. Start make now

Como comentaban efectivamente en el foro iLBC parece no ser obligatoria.

Lanzo make, pero obtengo lo siguiente:

[...]
if /bin/sh ../../../../../../../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I./../.. -DPOSIX -I./../.. -DQT_THREAD_SUPPORT -D_REENTRANT -D_FILE_OFFSET_BITS=64 -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT network.lo -MD -MP -MF ".deps/network.Tpo" -c -o network.lo network.cc; then mv -f ".deps/network.Tpo" ".deps/network.Plo"; else rm -f ".deps/network.Tpo"; exit 1; fi
In file included from network.cc:33:
./../../talk/base/basicdefs.h:32:20: error: config.h: No such file or directory
make[8]: *** [network.lo] Error 1
make[8]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete/protocols/jabber/jingle/libjingle/talk/base'
make[7]: *** [all-recursive] Error 1
make[7]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete/protocols/jabber/jingle/libjingle/talk'
make[6]: *** [all-recursive] Error 1
make[6]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete/protocols/jabber/jingle/libjingle'
make[5]: *** [all-recursive] Error 1
make[5]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete/protocols/jabber/jingle'
make[4]: *** [all-recursive] Error 1
make[4]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete/protocols/jabber'
make[3]: *** [all-recursive] Error 1
make[3]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete/protocols'
make[2]: *** [all-recursive] Error 1
make[2]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete'
make[1]: *** [all-recursive] Error 1
make[1]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1'
make: *** [all] Error 2

¡Diablos! Parece que no encuentra un fichero config.h. Vuelvo a relajarme navegando a tavés de Google. Buscando encuentro el Bug 121856 en que se comenta que "apunte libjingle al config.h generado durante el proceso de configuración de Kopete".

Así, edito el fichero basicdefs.h que hay en kopete-0.12-alpha1/kopete/protocols/jabber/jingle/libjingle/talk/base/ y cambio la línea que incluye el fichero basicdefs.h por:

#include "../../../../../../../config.h"

De esta manera apunta al fichero generado por el proceso de configuración. El estatus del BUG es RESOLVED, por lo que es posible que actualmente no suceda.

Finalmente vuelvo a ejecutar make y compila sin problemas tras un buen rato. He usado el siguiente gcc:

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)

Creo un paquete debian mediante checkinstall, e instalo Kopete 0.12 Alpha 1. Funciona sin problemas. Ahora al tener una charla con alguién de de GTalk aparece la opción de voice call, aunque supongo que debería dar la opción con cualquier contacto que soporte esta libreria. Sin embargo, no consigo comunicar. Si llamo desde GTalk Kopete no parece entararse, y si llamo desde Kopete GTalk parece enterarse pero tras aceptar la comunicación esta nunca se produce.

Tendré que echar un ojo a ver que pasa, probar con una versión de CVS algo más actual o compilar con depuración a ver si veo algún mensaje interesante.

Actualizacion 1/Abril/2006: Hace tiempo que salió la Beta 1, y Beta 2. Probé con la Beta 1 pero tampoco conseguí hacerlo funcionar, y probé con la Beta2 pero con muchas menos ganas. El caso es que hoy he vuelto a probar fortuitamente y me ha funcionado con la Beta 2 que tenía instalado. Al menos yo oia a mi contertulio, aunque el a mi no, básicamente por no tenía ocnfigurado el microfono. A este respecto, en la sección de dispositivos de la configuración de Kopete sólo aparece una pestaña de vídeo, pero no veo ninguna configuración para audio. En cualquier caso trataré de configurar em microfono en KDE y espero que valga para Kopete, por que lo cierto es que KDE si provee de una infraestructura para el audio, pero parece ser que no está tan integrado en el caso del vídeo.

Paso de Sarge a Etch

Me he decidido a pasarme de Sarge a Etch. En parte por tener paquetes más actuales, en parte por trastear un poco. Debería buscarme un ordenador alternativo para hacer de laboratorio...


El funcionamiento de testing puede leerse ne la página de Debian sobre la dsitribución "testing". En Bulma hay un artículo que comenta los cambios que se iban a producir en el modelo de desarrollo tras el cambio de SArge de testing a stable.

Para cambiar basta con poner los repositorios de testing/Etch en el lugar de los stable/Sarge (es conveniente poner el nombre, así el día que se produce un cambio en la distribución no se intenta actualizar de golpe y uno puede controlar en que momento quiere hacerlo, aunque sea una cosa que pase cada años), y hacer apt-get-update y apt-get dist-upgrade. Cuanto más limpio sea nuestro sistema menos problemas tendremos.

En mi caso no hay paquetes ni para K3b ni para amaroK, lo cuál me resulta molesto pero siempre puedo descargarlos y compilarlos. Parece ser que el problema es que los paquetes binarios de K3b y amarok están compilados paraKDE 3.5, por lo que hasta que éste no pase de Sid a Etch no habrá paquetes en Etch.

AmaroK
Se puede descargar e instalar directamente la versión 1.3.7-1 como comentan en la sección de Debian del wiki de amaroK.


K3B
Para K3b no he encontrado paquetes, asi que he tenido que descargarlo y compilarlo. Parece que no es psoible compilarlo con soporte para flacc y ffmpeg, lo que implica, si no me equivoco, que no será capaz de usar estas librerias para decodificar archivos. El primero afecta al formato flacc, mientras que el segundo puede ser grave, ya que afecta seguro a wma, pero sospecho que también a Asf, Ogg Vorbis. Tendré que comprobarlo. En xualquier caso si quiero un disco a partir de uno de estos formatos deberé pasarlo primero a un formato entendible mediante otro programa.


vlc
En su página no hay binarios o fuentes específicas para a Etch, asi que toca descargar y compilar. Sim embargo, obtengo un error por no disponer de libmpeg2. Ya le echaré un ojo.

MPlayer
Bueno, mplayer tampoco estaba disponible en Sarge, asi que no me extraña no tenerlo en Etch. Para instalarlo la solución más sencilla es usar los respositorios no oficiales de Marillat, sección Etch. Para ello, basta con añadir al soruces list:

deb ftp://ftp.nerim.net/debian-marillat/ etch main

Junto a MPlayer conviene instalar AcidRip y KPlayer. AcidRip permite volcar DVDs al disco duro y codificarlos como DivX, XviD y otros formatos, Báscamente es un envltorio de las funcionalidades de MPlayer y Mencoder. KPlayer es un un MPlayer envuelto en un interfaz KDE.

Plugin de Flash para navegadores web.
Tras el paso a Etch tanto Firefox como Konqueror se colgaban al tratar de mosntrar un Flash. La solución pasó por desintalar todo lo que tenía de Flash, revisar los directorios de plugins de los navegadores y eliminar todo lo que fuese sospechoso (más que eliminar mover de sitio; siempre es conveniente poder recuperar el estado anterior no sea que nos carguemos algo).

Actualizacion 12-Febrero-2006: Hoy me ha dado cuenta de que mi apt quiere actualizarme mi KDE de 3.4 a 3.5.1, lo cuál implica instalar también tanto amaroK como k3B, que estaban bloqueados por que estar compilados para KDE 3.5. Ahora toca desinstalar ls paquetes que he compilado de k3b y amaroK y usar los oficiales.