Archive for the 'Nueva versión' Category

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.

Tablet con systemd

miércoles, septiembre 24th, 2014

Hace un par de días actualicé el sistema Debian que le había instalado a mi tablet, y me encontré con la desagradable sorpresa de que mi gestor de ventanas y mi driver táctil dejaron de funcionar. El motivo es que, recientemente, Debian se ha cambiado a systemd, por lo que tuve que hacer algunos cambios para adaptarlo.

El primer y más fundamental cambio fue reemplazar los scripts en bash por ficheros de configuración de systemd. Este es el fichero para lanzar el driver táctil:

[Unit]
Description=GSLx680 user-space driver launcher for systemd

[Service]
Type=simple
ExecStart=/bin/gslx680 -new_scroll /dev/i2c-1 /etc/gslx680/firmware.cfg
ExecStop=killall gslx680

[Install]
WantedBy=multi-user.target

Este fichero lanza durante el arranque el driver, y durante el apagado del sistema lo mata.

El fichero para lanzar las X es similar:

[Unit]
Description=Launch X11

[Service]
Type=simple
User=debian
ExecStart=/usr/bin/startx
ExecStop=killall xinit

[Install]
WantedBy=multi-user.target

El único cambio es que especificamos con qué usuario queremos lanzar el comando: en este caso el usuario es debian.

Otro cambio que tuve que hacer fue eliminar, en el fichero .xinitrc, el que se lance ck-launch-session, el gestor de sesiones de ConsoleKit. Este ya no es necesario porque de ello se encarga systemd.

Por último, para apagar el sistema el gestor de ventanas ya no ejecuta halt, sino systemctl poweroff, con lo que ya no es necesario que haya un comando para ello con el bit suid activo.

Un último detalle: tuve que desinstalar el demonio pulseaudio para conseguir que reprodujese vídeos. Todavía no se el motivo de que con él lanzado no funcione (el audio queda bloqueado y tanto mplayer como vlc se quedan congelados esperando a que se libere).

Cagándola con un bug grave

domingo, agosto 10th, 2014

A veces a uno se le escapan pequeños bug que, en principio, no tienen la menor importancia, hasta que resulta que sí la tienen. Eso me ha ocurrido con la nueva versión en desarrollo de DevedeNG.

El bug ni siquiera era tal, sino más bien una combinación de valores por defecto poco adecuados, mensajes poco claros, y código que hacía demasiadas cosas. Básicamente, DevedeNG necesita una carpeta vacía donde crear el proyecto, así que le pide al usuario que le indique una. Si dicha carpeta ya existe le indica que va a proceder a borrarla, dejándole escoger si quiere continuar o cancelar antes de hacerlo.

Hasta aquí todo parece normal. El problema es que la carpeta por defecto era la carpeta personal del usuario, y el mensaje de aviso decía simplemente: “La carpeta seleccionada ya existe. Si continúa, será borrada. ¿Continuar?”. Este mensaje no es lo suficientemente claro porque en ninguna parte aparece qué carpeta se va a borrar. Ante esto, un usuario que se limite a pulsar Siguiente->Siguiente->Siguiente se encontrará con su carpeta personal borrada.

El código ya está corregido, para lo que he aplicado las siguientes lecciones aprendidas:

  • Debe evitarse utilizar la carpeta de usuario ($HOME) como destino por defecto cuando haya que realizar alguna acción que borre una carpeta. En el caso de DevedeNG, el primer cambio fue que la carpeta destino se componga de la carpeta escogida por el usuario más el nombre del proyecto, por lo que, por defecto, nunca será la carpeta de usuario sola la escogida para ser borrada.
  • Siempre que se le pida al usuario confirmación para borrar una carpeta debe mostrarse claramente en el texto qué carpeta se va a borrar. Nunca se debe dar por supuesto que el usuario lo sabe.
  • En la medida de lo posible no debe borrarse la carpeta al completo, sino buscar qué ficheros y directorios son los que pueden interferir con el proceso que se quiere realizar, borrando exclusivamente esos y ninguno más.

Afortunadamente, el usuario que se tropezó con este problema tenía copia de seguridad, por lo que todo quedó en un susto.

Novedades varias

viernes, diciembre 6th, 2013

Esta semana ha sido bastante movida. En primer lugar hice una fuerte refactorización de Autovala. Con la nueva estructura el código es mucho más elegante y, sobre todo, mucho más mantenible. De hecho, gracias a los cambios he podido añadir en poco tiempo nuevas características, como soportar espacios de nombres anidados (necesario para utilizar la biblioteca de Plank), autodetectar en algunos casos GIO, mejorar el parseado de los comandos propios (ahora permite una gran libertad a la hora de meter espacios), y algunas cosas más.

Otra novedad ha sido la migración a Autovala de mi fork de Submarine, además de corregir un pequeño bug en el buscador de SubDB cuando el fichero mide menos de 128KBytes.

Por último hice un retoque en el driver GSLx680 para pantallas táctiles. Ahora permite hacer scroll con un único dedo, lo que resulta más cómodo. Para poder hacer Drag&Drop basta con mantener el dedo quieto durante un segundo, y luego ya se puede mover.


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