Archive for the 'Nueva versión' Category

Cronopete 4

sábado, abril 28th, 2018

Acabo de lanzar una nueva versión de Cronopete, la 4.0. Se trata de una versión con muchos cambios internos, aunque externamente puede parecer muy similar.

El primer gran cambio es que ahora tiene un sistema de backends para hacer los backups. Esto era algo que estaba medio hecho desde la primera versión, pero el problema es que, sencillamente, estaba mal hecho: los backends de las versiones viejas sólo daban acceso a un disco, mientras que la lógica de las copias de seguridad estaba por encima. Esto limitaba mucho, porque exigía que donde se hiciesen los backups soportase enlaces a archivo y otras cosas. El nuevo sistema de backend, en cambio, asume completamente TODO el proceso de copia de seguridad; básicamente, cronopete le dice al backend: “quiero que me copies estas carpetas”, o “dame la lista de backups que tienes”, o ” recupera este fichero desde este backup”. Pero no le interesa COMO está hecho el backup. Eso es tarea de cada backend.

Por supuesto es fundamental conservar el sistema viejo de copias de seguridad, por lo que el primer backend funcional que tiene hace copias exactamente igual que el sistema anterior, pero con una diferencia: ahora utiliza la utilidad RSYNC en lugar de código propio, lo que ha permitido eliminar de un plumazo un bug misterioso que hacía que, muy de vez en cuando, apareciesen carpetas con nombres raros en la carpeta personal. Por supuesto, se aprovecha de que RSYNC permite hacer copias de seguridad con la misma estructura que las viejas versiones de cronopete (los ficheros que no han cambiado son enlaces duros al mismo fichero de la copia anterior, lo que permite ahorrar muchísimo espacio).

Con el nuevo sistema, implementar un backend para hacer copias en remoto debería ser relativamente trivial, aunque el problema es cuando tendré tiempo de ponerme en serio con ello (a fin de cuentas, es algo que quiero probar bien antes de lanzar).

Otra novedad, esta vez más sencilla, es que por fin permite que varios usuarios compartan un mismo disco de copias. Por un fallo tonto, las versiones anteriores ponían la carpeta cronopete, en el disco de destino, con permisos de escritura sólo para el usuario que había formateado el disco. Eso significaba que dicho usuario podía hacer copias sin problema, pero en cuanto otro usuario intentase usar el mismo disco para hacer sus copias, fallaría y le propondría formatearlo. Ahora la carpeta cronopete tiene permisos de escritura para todo el mundo, y dentro, igual que antes, hay una carpeta por usuario, en la que sólo dicho usuario tiene permisos de lectura, escritura y atravesado (por motivos obvios: otros usuarios no deberían tener acceso a mis copias de seguridad, pues son MIS datos).

Otro cambio es que ahora borra las copias nuevas después de hacer la copia de seguridad, lo que permite garantizar que si enciendes el equipo sólo un momento, se haga al menos una copia rápidamente. Además, el borrado de copias viejas se hace de manera más segura: antes se borraba directamente el directorio, lo que podía suponer un problema si se apagaba el ordenador o si cronopete fallaba en mitad del borrado, pues una copia quedaría “a medias”. Ahora, sin embargo, primero se renombran las copias a borrar añadiendo una letra justo antes, de manera que las copias que no se deben tener en cuenta están debidamente etiquetadas; luego se sincroniza el disco, y finalmente se procede a borrar las carpetas así marcadas. Esto tiene otra ventaja, y es que una copia de seguridad no válida nunca aparecerá en la interfaz de restauración de ficheros.

Por último hay varios cambios estéticos y menores, sobre todo en la interfaz de restauración de ficheros. Ahora, por ejemplo, la linea de tiempos muestra la fecha correspondiente, lo que da una idea más precisa de por donde andamos y hasta donde podemos llegar que antes.

También se puede ahora filtrar por tipo de archivo, y, además, cronopete recordará entre ejecuciones si se quería ver en modo iconos o en modo lista de archivos.

Nueva versión de Autovala

miércoles, marzo 28th, 2018

Hoy saqué una nueva versión de Autovala que añade un detalle muy sencillo pero muy importante: el soporte para anotaciones para traductores.

Resulta que xgettext, la herramienta que extrae del código fuente los textos que hay que traducir a las diversas lenguas, tiene una funcionalidad muy importante, que es la posibilidad de añadir como notas para los traductores cualquier comentario del código que se encuentre en la línea inmediatamente anterior a la de una cadena traducible. Hasta ahora yo daba por hecho que eso se realizaba de manera automática, pero hoy descubrí que no, que hace falta pasar un parámetro en la línea de comandos, en concreto –add-comments. Es más, es posible añadir un tag a continuación, y sólo aquellos comentarios que empiecen por dicho tag serán considerados una nota para los traductores.

Como digo, pensaba que era automático, por lo que Autovala no lo tenía en cuenta, pero al descubrir esto decidí que era una funcionalidad lo suficientemente importante como para que estuviese disponible. Así que ahora es posible añadir en la configuración una línea con po_comment_tag, y todos los comentarios previos a una cadena traducible serán añadidos como notas para traductores. Pero también es posible añadirla como po_comment_tag: XXXXXX, en cuyo caso sólo se añadirán aquellos comentarios que comiencen con XXXXXX.

Como de costumbre, es posible bajar Autovala desde mi página web, o bien desde el repositorio Github de Autovala.

Autovala y Multipackager

miércoles, marzo 7th, 2018

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.

Multipackager más rápido

domingo, mayo 22nd, 2016

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).

Nueva version del entorno Gentoo para WebTV

jueves, julio 30th, 2015

Acabo de subir a mi web la versión 2 del entorno de desarrollo Gentoo para el WebTV. Con ella ya debería ser posible instalar una versión decente de transmission. Ahora voy a empezar a trabajar en aplicaciones extra.

Paquetes para todos los públicos

domingo, abril 26th, 2015

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.

Lanzado Multipackager

miércoles, abril 15th, 2015

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).

Actualizado Cronopete

domingo, abril 5th, 2015

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.

Actualizado FBZX

miércoles, abril 1st, 2015

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.

Experimentando con Autovala

martes, diciembre 2nd, 2014

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.


Utilizamos cookies para garantizar que tenga la mejor experiencia en nuestro sitio web.