Recientemente saqué versiones nuevas de Autovala y Multipackager.

En el caso de Autovala, se trata de la 1.3.0. El motivo fue que en la última actualización de paquetes de mi sistema operativo se pasó a Vala 0.39. Sin embargo, este compilador busca los ficheros VAPI en el directorio de la versión 0.40. La solución consistió en no deducir el directorio donde están los ficheros VAPI a partir de la versión del compilador, sino preguntarle donde los va a buscar (para lo que basta con hacer «valac –api-version»). Con esto, Autovala puede por fin encontrar dichos ficheros y detectar automáticamente las dependencias del programa.

El cambio en Multipackager surgió, precisamente, para corregir un problema al crear los paquetes de Autovala, y es que, debido al cambio de nombre de una biblioteca desde Debian Estable a Debian SID, el fichero de configuración sólo servía para uno de ellos. La solución fue modificarlo para que sea capaz de detectar alternativas a paquetes (el comando «|» en las dependencias, para indicar que se puede poner un paquete cualquiera de una lista).

Como de costumbre, están disponibles en mi web y en mi repositorio de GIT.

He lanzado una nueva versión de Multipackager con una interesante novedad: ahora es muchísimo más rápido. Para ello utilizo OverlayFS.

Para entender por qué es así, cabe explicar que cada vez que se utiliza por primera vez un sistema operativo concreto (por ejemplo: debian jessie i386), multipackager genera dos copias: una para construir paquetes, y otra para lanzar shells.

Hasta aquí nada especial. Sin embargo, la copia para construir paquetes no se utiliza nunca directamente. Cuando se va a construir uno, lo primero que se hace es sacar una copia de dicha copia, y sólo entonces se instalan los paquetes necesarios para crear el paquete. Si todo va bien se borra la copia vieja, y ya tenemos la máquina original con nuevos paquetes; si algo falla, se borra la copia nueva y se restaura la vieja. Así nunca se queda un sistema «a medias». Por último se hace una nueva copia para crear, esta vez sí, dentro de ella el nuevo paquete. Esta copia se destruye una vez que se ha terminado la generación.

Este sistema permite garantizar que las copias locales de cada sistema operativo están siempre «sanas», lo que evita tener que generar una nueva completa cada vez que queramos crear un paquete. El inconveniente es que sacar cada copia lleva MUCHO tiempo. Y lo que es peor: a medida que se instalan más y más paquetes, la copia tarda más y más.

La solución consistió en no hacer copias, sino utilizar OverlayFS para poder realizar las operaciones sin modificar la máquina original. Esta operativa es inmediata en el segundo caso, cuando queremos construir el paquete en una máquina que se borrará cuando se termine. Sin embargo, para el primer caso tuve que rascarme un poco la cabeza, pues si la operación de instalar paquetes termina correctamente es necesario «aplicar los cambios» sobre la máquina virtual original. Esta operación, afortunadamente, no es muy complicada.

El resultado es que los tiempos para generar los distintos paquetes se han reducido en un orden de magnitud, lo que no está nada mal, teniendo en cuenta que actualmente estoy generando entre seis y ocho paquetes por programa (debian, ubuntu, fedora y arch, cada una en 32 y 64 bits).

Tras el lanzamiento original de Multipackager, he ido haciendo varias mejoras sobre él hasta llegar a la actual revisión 0.12. Ahora no sólo es mucho más rápido a la hora de generar paquetes, sino que también soporta crearlos para Fedora. Gracias a él he podido publicar en mi web paquetes para Debian, Ubuntu y Fedora, para arquitecturas de 32 y 64 bits, de Autovala, Cronopete, DevedeNG, FBZX y, por supuesto, del propio Multipackager.

A disfrutarlo con salud.

Acabo de lanzar la primera versión de Multipackager. Se trata de un programa que simplifica la creación de paquetes para múltiples distribuciones y arquitecturas. La idea es sencilla: si tienes instalada Debian de 64 bits, es relativamente sencillo crear un paquete para Debian de 64 bits; pero hacer uno para Debian de 32 bits la cosa empieza a complicarse. Y ya no digamos para hacerlo para Ubuntu de 32 o 64 bits (aunque deriva de Debian, a veces las bibliotecas no son del todo compatibles). Y mejor no hablemos para hacer un paquete para Fedora.

La solución más rápida consiste en usar una máquina virtual con el sistema operativo deseado, pero tiene el inconveniente de que montar una máquina para cada uno es una tarea pesada y engorrosa.

Es justo aquí donde entra en juego Multipackager: aprovechando que estas distribuciones tienen herramientas que permiten generar un sistema base de manera sencilla, se me ocurrió hacer un programa que, dándole una tripla de datos («distribución, versión, arquitectura»; por ejemplo «debian, jessie, i386», o «ubuntu, utopic, amd64»), genere automáticamente una máquina virtual para ella, completamente prístina y limpia de polvo y paja, y la utilice para generar, lo más automáticamente posible, un paquete para un proyecto determinado.

El resultado es que es posible disponer de una lista de dichas triplas y, tan sólo indicando la ruta a un proyecto, Multipackager generará automáticamente cada una de ellas, instalará las dependencias necesarias para el proyecto, compilará el código en su interior, generará el paquete, lo copiará al exterior, y limpiará los datos temporales.

En estos momentos Multipackager puede trabajar con máquinas Debian y Ubuntu (Fedora está en camino), en arquitecturas de 32 y 64 bits, y puede generar paquetes binarios y de Python3. A mayores permite generar una máquina virtual con dicha tripla y lanzar una shell interactiva en su interior, por si necesitamos hacer pruebas o demás. En este caso, al salir no se borra ningún dato temporal, por lo que es posible volver a entrar en cualquier momento.

Por último, incluye una caché de distribuciones para que no sea necesario bajar el sistema base de cada vez (una tarea bastante larga).

Ya iba tocando actualizar Cronopete en condiciones, pues había un pequeño bug que me estaba tocando mucho las narices: de vez en cuando, durante el arranque, decía que el disco no estaba disponible y tenía que montarlo yo a mano. Tras rebuscar y probar, descubrí que lo que ocurría era que, a veces, el sistema operativo lo montaba en una carpeta diferente de la habitual, y por eso Cronopete no era capaz de encontrarlo.

A la vez, descubrí que ya no funcionaba el formateo de discos; sin embargo, el código no había cambiado, así que llegué a la conclusión de que el problema se debía a que el nuevo demonio udisks2, aunque emulaba la antigua interfaz de udisks, no lo hacía correctamente.

Por último, un problema menor pero que me parecía incómodo: la ventana de configuración, durante una copia, cambiaba de ancho debido al texto que indica qué fichero se está copiando.

Ante todo esto, decidí que ya tocaba meterle mano y resolverlo todo, así que procedí a pelearme con la nueva interfaz DBus de udisks2. Aunque Vala incorpora una serie de clases para usarla, no es nada intuitivo, y al final ahorré tiempo utilizando DBus directamente.

Por otro lado, cambié la manera en que se busca la ruta donde hacer el backup: ahora no almaceno en el registro la carpeta donde se supone que está el disco, sino directamente el UUID de la partición. De esta manera no importa que cambie entre arranques, siempre lo encontrará… O eso pensaba, porque resulta que me encontré con que, en ocasiones, la ruta de montaje puede cambiar entre que se arranca Cronopete y que éste quiere hacer el primer backup (no preguntéis, yo tampoco me lo explico). Por eso tuve que hacer un segundo cambio y utilizar siempre el UUID cada vez que se va a iniciar una copia, y no sólo al arrancar.

Y ya puestos, aproveché para echar un vistazo a los distintos warnings que salían durante la compilación por usar funciones obsoletas, y corregí todas menos dos: las referidas al uso de threads. El motivo es que recientemente hubo un cambio en la implementación de éstos en Linux que disparó un bug en la generación de código en Vala. Ese bug está resuelto en Vala 0.26, que es la que tengo en Debian; pero dado que la actual versión estable de Ubuntu tiene Vala 0.24, he decidido esperar unos meses antes de corregir ese.

También descubrí que los bookmarks no se mostraban en la ventana de restauración de ficheros, porque GTK3 utiliza un archivo diferente para almacenarlos. Ahora ya está resuelto.

Y por último, he hecho cambios para garantizar que, siempre que se pueda, el disco de backups estará montado. Así, si se desmonta accidentalmente, Cronopete lo volverá a montar. La única forma de retirarlo es detener la copia de seguridad. Esto permite evitar que se detenga la copia de seguridad por error.

Tras recibir un informe de error de un usuario, decidí que ya era hora de actualizar un poquito FBZX. Sin embargo, estoy tan acostumbrado a trabajar orientado a objeto con Vala y Python que no me apetecía ponerme a trabajar en C puro y programación funcional, así que me lié la manta a la cabeza y refactoricé el código de FBZX en C++. El motivo principal fue reescribir, esta vez sí desde cero, el código del emulador de cinta. Al utilizar herencia simplifica mucho el código, al permitir compartir mucho de él entre ficheros TAP y TZX. Además, ahora permite hacer cosas que antes no eran posibles, como por ejemplo carga rápida de ficheros TZX, e incluso grabar en ambos formatos.

Ya puestos, aproveché para pulir la interfaz y cambiar la tipografía por otra más elegante (y además, proporcional, gracias a código extraído de TTOS). Y también aproveché para añadir detalles extra, como por ejemplo ruido en la entrada de audio cuando la cinta no está en marcha (de manera que el borde parpadee cuando el sistema está esperando a que se ponga en marcha la cinta), o que cuando la cinta esté reproduciéndose el emulador trabaje a máxima velocidad, y que vuelva a velocidad normal cuando se pause.

También corregí algunos bugs, como por ejemplo algunos problemillas que había con la carga y grabación rápidas, sobre todo en modo +3. También retiré todas las palabras clave «register» e «inline» de C porque daban problemas a la hora de compilar con GCC 5. Ah, y al listar ficheros para escoger un TAP, TZX, SNA, etc. aparecen ordenados alfabéticamente, lo que simplifica la búsqueda. Y, por supuesto, limpieza de variables no usadas, etc.

Hace un par de meses lancé una nueva versión de Autovala, la 0.99.9, y otra hace menos, la 0.99.10.

La primera, como novedad, permite escoger si se desea utilizar una versión fija del compilador de vala, o si se prefiere que sea Autovala quien escoja la que se debe utilizar. Antes, la versión del compilador se actualizaba siempre en el fichero .avprj a la versión por defecto instalada en el sistema; ahora esto sólo ocurre si el comando vala_version en dicho fichero tiene un asterisco al principio. Si no, se mantendrá dicho valor siempre, y será el valor mínimo necesario para compilar el proyecto.

Respecto a la versión 0.99.10, incluye una petición de un usuario: soporte de pruebas unitarias, lo que permite simplificar la depuración de los proyectos.

Como de costumbre, el propio proyecto incluye abundante documentación en la carpeta doc, en formato HTML.

A mayores estoy preparando para la versión 0.99.11 la generación automática de ficheros de metadatos para paquetes. En este momento genera casi todo lo necesario para crear paquetes .deb y .rpm, pero en el futuro espero poder añadir soporte para más arquitecturas de paquetes, como emerge. Esta versión en desarrollo está disponible en una rama aparte, y me gustaría que la gente la probase antes de mezclarla con main.