Archivo de la categoría: Trucos

Trucos generales para distribuciones

No puede caber aqui

Cacharreo, Trucos

Llevo un par de días incapaz de actualizar el paquete binutils usando la emulación de mipsel sobre mi PC. Es una cosa misteriosa, pues daba un error al compilar el linker gold. Tras intentar hacerlo a mano, me devolvió como mensaje de error:

(for i in `seq 1 70000`; do 
  echo "int var_$i __attribute__((section("section_$i"))) = $i;"; 
done) > many_sections_define.h.tmp
make: execvp: /bin/sh: Argument list too long

¿Argument list too long? Un error bastante extraño, sin duda. Y más en el propio make. Encima, si eliminaba todo ese código y metía un simple echo, el error persistía. ¿Qué estaba pasando?

Tras probar de todo y rebuscar por todas partes, por fin encontré el problema: qemu define un tamaño máximo para la línea de comandos (MAX_ARG_PAGES) demasiado pequeño para compilar binutils, y por eso casca. Encima, dicho valor se define a piñón en el código fuente, por lo que la única solución consiste en bajarse los fuentes de qemu, modificar el fichero linux-user/qemu.h para aumentar a 64 o más las páginas reservadas para la línea de comandos (yo puse 129), y compilarlo todo con:

./configure --static --target-list=mipsel-linux-user
make

Con esto ya tendremos en mipsel-linux-user/qemu-mipsel el ejecutable estático, el cual podemos copiar dentro de la carpeta de nuestra máquina virtual como usr/bin/qemu-mipsel-static. Y con esto deberíamos ser capaces de compilar cualquier cosa.

(Si, el título es por esta escena 🙂 )

Actualizando la Gentoo del WebTV desde el PC

Cacharreo, Trucos, tutoriales

Siguiendo con lo que hice el otro día, ahora quería empezar a instalar cosas en el sistema Gentoo del WebTV. Por desgracia la cosa no es tan sencilla porque enseguida pide actualizar algunos paquetes, lo cual tarda mucho tiempo al hacer la compilación en el propio dispositivo. Y por si fuera poco, con alguno necesita tanta memoria que, directamente, casca a la mitad de la compilación.

Afortunadamente hay una forma de hacer todo esto directamente en un PC, pero haciendo creer al sistema Gentoo que está corriendo de forma nativa en un sistema Mipsel. Para ello sólo necesitamos QEMU.

Para empezar necesitamos el binario /usr/bin/qemu-mipsel-static, así que buscamos en qué paquete está disponible y lo instalamos en nuestro sistema. En el caso de Debian, el paquete es qemu-user-static. Este binario nos permite ejecutar binarios de la arquitectura deseada, pero (y esto es lo interesante) encaminando las llamadas al núcleo directamente al de la máquina física, con lo que no necesitamos compilar otro núcleo.

Ahora descomprimimos el fichero entorno_gentoo_mipsel.tar.bz2 en un directorio (por ejemplo, en /tmp), y descomprimimos en lugar adecuado (en nuestro ejemplo, en /tmp/bg_apps/usr) también el fichero de portage, tras bajarlo. Por último, copiamos /usr/bin/qemu-mipsel-static dentro de nuestro sistema mipsel (en nuestro caso, en /tmp/bg_apps/usr/bin/). Con esto hemos terminado los preparativos.

Ahora lanzamos nuestra sesión mediante:

sudo systemd-nspawn -u 1000 -D /tmp/bg_apps /bin/bash

De esta manera lanzamos nuestra sesión como usuario 1000 (que es el que usa el WebTV cuando se arranca una sesión en segundo plano). Además, gracias a que copiamos el binario de qemu, los binarios de mipsel se ejecutarán directamente, sin ningún problema, como si fuesen nativos de nuestro sistema (por increíble que parezca).

Una vez hecho esto ya podemos actualizar el sistema y demás, sin temor a quedarnos sin memoria y a mucha más velocidad. Pero echad un vistazo también a esta entrada posterior: https://blog.rastersoft.com/?p=1645.

Generando Gentoo para el WebTV

Cacharreo, Programación, Trucos, tutoriales

Nota: actualizado el parche para BusyBox.

Estos días estoy bastante liado con el trabajo-que-paga-las-facturas, pero por suerte he podido sacar un rato para cacharrear. Me he puesto con el WebTV (que tengo bastante abandonado desde que me compré la Raspberry Pi) y he decidido intentar meter un sistema «decente». ¿A qué me refiero? Pues a que, por defecto, la máxima versión de Debian que puede correr es wheezy, que ya es old-stable. La estable actual (jessie) necesita un núcleo más reciente, y se niega a trabajar con el que trae el WebTV (2.6.22).

Ante esto decidí probar con Gentoo, a ver si conseguía compilarlo todo. A continuación indicaré como lo hice.

NOTA: para los que no quieran leerse este tocho, en mi web está disponible este entorno Gentoo completo para WebTV, ya compilado y listo para usar.

Para empezar, me bajé la stage 3 de Gentoo para X86_64, bajé también la última lista de paquetes de portage, y descomprimí ésta última en /usr de la stage 3. Con ello ya pude lanzar un contenedor de gentoo con

sudo systemd-nspawn -D /directorio/con/la/stage3 /bin/bash

Aquí toca primero preparar el sistema para hacer crossdev. Esto se puede repasar en una entrada anterior: Emergiendo.

Una vez dentro intenté hacer un crossdev para compilar una gentoo para mipsel usando

crossdev --kernel 2.6.22 -t mipsel -v

Por desgracia fallaba: se empeñaba en utilizar las cabeceras de la versión 2.4.36. ¿Qué pasaba? Pues que aunque en los repositorios de Gentoo sí existen las cabeceras del kernel 2.6.22, éstas no están disponibles en la lista de ebuilds de portage.

Ante esto empecé a buscar y probar, y finalmente con la ayuda de la gente de IRC del canal #Gentoo-kernel conseguí el ebuild de las cabeceras para la versión 2.6.22-r2. Sin embargo tuve que grabarlo en /usr/portage/sys-kernel/linux-headers con el nombre linux-headers-2.6.22-r3, pues la R3 es la versión disponible en el repositorio.

Tras ello actualicé el fichero Manifest para que encontrase el nuevo ebuild con

ebuild /usr/portage/sys-kernel/linux-headers/linux-headers-2.6.22-r3.ebuild manifest

Probé de nuevo a generar el crossdev pero seguía intentando usar la versión 2.4.36… porque la versión 2.6.22-r3 es posterior a la 2.6.22 a secas. Cambiando el parámetro en crossdev solucionó el problema.

crossdev --kernel 2.6.22-r3 -t mipsel -v

Por desgracia, ahora me encontraba con otro: ocurría un error durante la instalación de las cabeceras:

HOSTCC  scripts/unifdef
scripts/unifdef.c:209:25: error: conflicting types for 'getline'
 static Linetype         getline(void);
                         ^
In file included from scripts/unifdef.c:70:0:
/usr/include/stdio.h:678:20: note: previous declaration of 'getline' was here
 extern _IO_ssize_t getline (char **__restrict __lineptr,
                    ^
scripts/Makefile.host:118: recipe for target 'scripts/unifdef' failed
make[1]: *** [scripts/unifdef] Error 1
Makefile:927: recipe for target 'headers_install' failed
make: *** [headers_install] Error 2
emake failed

Tocaba buscar más soluciones. Afortunadamente esta era sencilla: bastaba con editar el fichero unifdef.c y sustituir todas las ocurrencias de getline por otra cosa, como por ejemplo get_line. Preparé el siguiente parche para ello:

--- a/scripts/unifdef.c
+++ b/scripts/unifdef.c
@@ -206,7 +206,7 @@ static void             done(void);
 static void             error(const char *);
 static int              findsym(const char *);
 static void             flushline(bool);
-static Linetype         getline(void);
+static Linetype         get_line(void);
 static Linetype         ifeval(const char **);
 static void             ignoreoff(void);
 static void             ignoreon(void);
@@ -512,7 +512,7 @@ process(void)
 
 	for (;;) {
 		linenum++;
-		lineval = getline();
+		lineval = get_line();
 		trans_table[ifstate[depth]][lineval]();
 		debug("process %s -> %s depth %d",
 		    linetype_name[lineval],
@@ -526,7 +526,7 @@ process(void)
  * help from skipcomment().
  */
 static Linetype
-getline(void)
+get_line(void)
 {
 	const char *cp;
 	int cursym;

Y entonces me encontré con el problema de como aplicarlo durante la generación del crossdev. La cosa no era sencilla, porque se empeña en comprobar los valores de sha256, sha512 y whirlpool de todo lo que baje. En teoría se pueden añadir parches manualmente en /etc/portage/patches, pero tras probar de todo no conseguí que funcionase, así que al final fui a la solución cazurra y metí el comando de parcheado directamente en el ebuild. Para ello edité el fichero /usr/portage/sys-kernel/linux-headers/linux-headers-2.6.22-r3.ebuild y lo dejé como sigue:

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-kernel/linux-headers/Attic/linux-headers-2.6.22-r2.ebuild,v 1.11 2008/04/12 22:24:36 vapier dead $

ETYPE="headers"
H_SUPPORTEDARCH="alpha amd64 arm cris hppa m68k mips ia64 ppc ppc64 s390 sh sparc x86"
inherit kernel-2
detect_version

echo ${PV}
echo ${PATCH_VER}

PATCH_VER="3"
SRC_URI="mirror://gentoo/gentoo-headers-base-${PV}.tar.bz2"
[[ -n ${PATCH_VER} ]] && SRC_URI="${SRC_URI} mirror://gentoo/gentoo-headers-${PV}-${PATCH_VER}.tar.bz2"

KEYWORDS="-* alpha amd64 arm hppa ia64 m68k mips ppc ppc64 s390 sh sparc x86"

DEPEND="dev-util/unifdef"
RDEPEND=""

S=${WORKDIR}/gentoo-headers-base-${PV}

src_unpack() {
        unpack ${A}
        cd "${S}"
        [[ -n ${PATCH_VER} ]] && EPATCH_SUFFIX="patch" epatch "${WORKDIR}"/${PV}
        patch -p1 < /getline.patch
}

src_install() {
        kernel-2_src_install
        cd "${D}"
        egrep -r '[[:space:]](asm|volatile|inline)[[:space:](]' .
        headers___fix $(find -type f)
}

src_test() {
        make ARCH=$(tc-arch-kernel) headers_check || die
}

Luego copié el texto del parche en el fichero /getline.patch y actualicé de nuevo el manifest. Ahora, siempre que se intente instalar el paquete, se parcheará correctamente.

A intentarlo otra vez… y otra vez falla, esta vez porque la versión 2.20 de glibc necesita, al menos, un kernel 2.6.32. Como el núcleo disponible es el que es, toca probar con una versión anterior. La 2.19r1 fue suficiente:

crossdev --kernel 2.6.22-r3 --l 2.19-r1 -t mipsel -v

Finalmente, con esto ya es capaz de compilar glibc. Ahora vienen las curvas, porque no es capaz de compilar el soporte de Fortran para el GCC, ni las pruebas sanity ni algunas cosas más, así que toca armarse de paciencia e ir probando opciones de USE hasta que todo compile. El resultado final es que hay que usar la siguiente línea (añadí el -X para reducir las dependencias, pues en el WebTV no es necesario):

USE="-fortran -sanitize -X" CFLAGS="-O2 -pipe" crossdev --kernel 2.6.22-r3 --l 2.19-r1 -s4 -t mipsel -v

Inicializamos los wrappers de compilación cruzada…

emerge-wrapper --target mipsel-unknown-linux-gnu --init

Y ya tenemos el sistema de compilación cruzada para MIPSel. Ahora toca configurar el entorno y preparar el sistema. Para ello lo primero es borrar el enlace /usr/mipsel-unknown-linux-gnu/etc/portage/make.profile (que, por defecto, apunta a /usr/portage/profiles/embedded) y sustituirlo por uno que apunte a /usr/portage/profiles/ default/linux/mips/13.0/mipsel.

Una vez hecho esto editamos /usr/mipsel-unknown-linux-gnu/etc/portage/make.conf, y ahí modificamos la línea donde se define el USE para añadir, al menos, -fortran -sanitize -X -iptables. También podemos añadir, opcionalmente, un MAKEOPTS=»-jX» (siendo X el número de núcleos de nuestro procesador más uno), para que la compilación sea más rápida.

También tenemos que editar el fichero /usr/mipsel-unknown-linux-gnu/etc/portage/package.mask, y añadir estas líneas:

>sys-libs/glibc-2.19-r1
>sys-kernel/linux-headers-2.6.22-r3

Con ellas evitamos que instale versiones posteriores de ambos paquetes, que harían que el sistema dejase de funcionar en nuestro WebTV.

Con esto ya podemos intentar generar nuestro sistema base con

emerge-mipsel-unknown-linux-gnu system

Si falla al compilar Busybox, es probable que haya alguna opción que no le gusta. En ese caso hay que editar su fichero .ebuild en /usr/portage/sys-apps/busybox/busybox-X.Y.Z.ebuild, añadir las opciones de configuración que se quieren activar o desactivar, y luego ejecutar ebuild /usr/portage/sys-apps/busybox/busybox-X.Y.Z.ebuild manifest para actualizar el manifest. En mi caso, el problema es que se activan por defecto el soporte de UBIFS y de I2C, cosa que no parece gustarle, así que para eliminarlo tuve que añadir las siguientes líneas en el sitio adecuado del ebuild:

busybox_config_option n I2CGET
busybox_config_option n I2CSET
busybox_config_option n I2CDUMP
busybox_config_option n I2CDETECT
busybox_config_option n UBIATTACH
busybox_config_option n UBIDETACH
busybox_config_option n UBIMKVOL
busybox_config_option n UBIRMVOL
busybox_config_option n UBIRSVOL
busybox_config_option n UBIUPDATEVOL

Con suerte, en un par de días este parche ya estará incluido en los repositorios oficiales.

Otro problema, esta vez más grave, es con Perl: se trata de un paquete al que no le gusta que le hagan compilación cruzada. El resultado es que, simplemente, no podemos instalarlo así. La solución consiste en, de momento, hacer creer al sistema que sí está instalado, e instalarlo manualmente desde el sistema final una vez que ya estamos en el equipo. Para hacer esto basta con editar el fichero /usr/mipsel-unknown-linux-gnu/etc/portage/profile/package.provided y poner, en cada línea, los paquetes que queremos marcar como instalados. Hice lo mismo con los paquetes de UDev, que tampoco los necesito. En mi caso su contenido fue:

dev-lang/perl-5.22
virtual/perl-Data-Dumper-2.158.0
perl-core/File-Temp-0.230.400-r1
virtual/perl-File-Temp-0.230.400-r3
dev-perl/Text-Unidecode-1.230.0
dev-perl/libintl-perl-1.240.0
virtual/perl-File-Spec-3.560.0
dev-perl/Unicode-EastAsianWidth-1.330.0-r1
sys-fs/udev-222
virtual/udev-217
sys-fs/udev-init-scripts-30
virtual/dev-manager-0

Pero, obviamente, depende de la versión de portage y de los paquetes disponibles.

Tras instalar todo esto, si el equipo es de 64 bits nos encontraremos con que nos ha metido varios elementos de python en /usr/lib64, cuando todo debería ir en /usr/lib. Es por esto que debemos mover todos los ficheros del primero al segundo.

Ahora ya podemos copiar el contenido de /usr/mipsel-unknown-linux-gnu/ a un disco duro externo (dentro de una carpeta llamada bg_apps), añadir un fichero init y otro vacío llamado no_base_system, y ya podemos arrancar nuestro sistema Gentoo en el WebTV.

Pero aún no hemos acabado. Para empezar, es necesario hacer el siguiente enlace cada vez que se encienda el equipo:

ln -s /proc/self/fd /dev/fd

para que emerge funcione correctamente. También es recomendable editar el fichero /etc/portage/make.conf y eliminar la opción de compilación -pipe, pues consume más memoria, y en un equipo relativamente limitado como el WebTV nos puede dar problemas con compilaciones muy tochas.

Por otro lado, tenemos que comentar las entradas de Perl que pusimos en el fichero /usr/mipsel-unknown-linux-gnu/etc/portage/profile/package.provided, y procer a instalarlos todos con emerge.

No hay que olvidar que, debido a la gran cantidad de ficheros que tiene el directorio /usr/portage, el arranque de la sesión en segundo plano del WebTV tardará bastante tiempo (en torno a un minuto), pues antes de lanzar la sesión, el sistema revisa todos y cada uno de los ficheros para asegurarse de que no hay «cosas raras».

Generando paquetes DEB para programas en Python

Trucos, tutoriales

Estos últimos meses he estado aprovechando para reescribir Devede. El principal motivo de reescribirlo desde cero ha sido, aparte de aprovechar mejor las distintas características de Python 3 y GTK 3, para darle una arquitectura interna más moderna, flexible y modular. El resultado es que ahora es muchísimo más fácil añadir nuevas características, backends y utilidades, y además puede hacer cosas como convertir en paralelo varios vídeos, aprovechando al máximo las CPUs multinúcleo actuales.

Desde el principio decidí escribir el código en condiciones utilizando el módulo DistUtils para realizar la instalación, y resultó ser un gran acierto porque permite simplificar notablemente la generación de paquetes DEB, algo necesario porque varios usuarios que querían utilizarlo no se aclaraban con GITHUB ni la línea de comandos.

Una vez que ya tenemos listo nuestro script de instalación setup.py, siguiendo las directrices de distutils, basta con instalar en nuestro sistema las utilidades stdeb. En Debian y Ubuntu el paquete se llama python3-stdeb; sin embargo, la versión para Python 3 sólo está disponible en Ubuntu a partir de Vivid (15.04), que en el momento de escribir esta entrada todavía está en fase de desarrollo (en Debian está disponible desde Jessie en adelante, por lo que no hay problema). Los que tengan la ultima revisión estable de Ubuntu (14.10 en el momento de escribir esta entrada) sólo dispondrán de python-stdeb en sus repositorios, que sólo funciona para Python 2 (incluso reescribe el shebang para que apunte a Python 2 en caso de que nuestro código lo tuviese apuntando a Python 3), por lo que tendrán que bajarse a mano el paquete .deb. La opción más directa consiste en buscarlos en Ubuntu Packages.

Una vez instalado hay que añadir el módulo dep_util en el script setup.py, para que reconozca las nuevas opciones. Para ello basta con añadir al principio:

from distutils import dep_util

Una vez hecho esto hay que añadir en el raíz de nuestro proyecto un fichero llamado stdeb.cfg. Este fichero contendrá todos aquellos datos que el generador no puede extraer de los que se pasan en el script setup.py, como por ejemplo las dependencias de nuestro programa. El fichero de Devede-NG contiene lo siguiente:

[DEFAULT]
Depends = python3, python-support, python-urllib3, python-gi, libgtk-3-0, ffmpeg (>= 7:1.2.6) | libav-tools(>= 6:9.16), mplayer, mpv | vlc, dvdauthor, mkisofs | genisoimage, vcdimager, libvorbis0a, libvorbisfile3

El resto de las opciones posibles que se pueden poner se pueden encontrar en la documentación de stdeb. Un detalle importante es que no conseguí que funcionase con el comando XS-Python-Version. Cada vez que lo añadía para forzar que sólo generase paquetes de Python 3, el proceso devolvía un error.

Ahora ya está todo listo, por lo que para generar el paquete basta con ejecutar el siguiente comando:

python3 setup.py --command-packages=stdeb.command bdist_deb

Y ya está; se creará un directorio llamado deb_dist en cuyo interior encontraremos un paquete deb con nombre python3-nombreprograma​_numero​.de​.version​_all.deb.

Por último, comentar varios detalles extra:

  • es fundamental llamarlo con python3; de no hacerlo así, generará un paquete para Python 2 (incluso reescribirá el shebang de los ficheros python para que apunten a Python 2)
  • podemos hacer todos los cambios que queramos en nuestro código y regenerar el paquete directamente siempre que no cambiemos la cadena con la versión en nuestro script setup.py. Si la cambiamos debemos borrar el directorio deb_dist antes de volver a generar el paquete, o el proceso fallará, devolviendo un error.
  • debe tenerse muy en cuenta que, al generar paquetes .deb, el script setup.py se ejecuta dos veces: la primera para copiar al directorio deb_dist sólo los ficheros que realmente conforman nuestro programa y que se tienen que instalar en el sistema (de manera que otros ficheros, como el README o similares, no se incluirán en el paquete), y la segunda vez para configurar y generar el paquete .DEB en sí. En el caso de Devede-NG esto fue importante tenerlo en cuenta porque lo primero que hace el script de instalación es compilar los ficheros de traducciones .po y copiarlos en una carpeta diferente, que es la que luego se instala en el sistema. Pero al ejecutarse por segunda vez dentro de deb_dist, los ficheros .po ya no estaban disponibles porque éstos no se copian en el sistema. Tras hacer unas modificaciones menores fue posible hacer que funcionase perfectamente.

Mapear los botones de un ratón logitech

Trucos

Desde hace tiempo tengo un ratón Performance MX de Logitech. Estoy muy contento con él desde que lo compré, salvo por el detalle de que usar la rueda como botón central es bastante incómodo, porque es difícil no girarla al pulsarla. Por eso lo primero que hice fue mapear la tecla zoom (que está disponible en el pulgar) como el botón central. Para ello hice este pequeño script bash, que añadí a las aplicaciones al inicio de mi sesión:

#!/bin/bash

xmodmap -e "pointer = 1 13 3 4 5 6 7 8 9 10 11 12 2"

Al principio este script funcionaba perfectamente, hasta que un día, dejó de hacerlo. Lo raro era que si lo ejecutaba a mano desde un terminal, funcionaba perfectamente; sólo fallaba si lo ejecutaba como aplicación al inicio de sesión. Esto me obligaba a ejecutarlo manualmente cada vez que encendía el ordenador, lo que era un peñazo, así que empecé a investigar qué era lo que ocurría, y descubrí que el ratón, como dispositivo de entrada, no es visible por el ordenador hasta que se mueve por primera vez. Eso significa que, cuando se ejecutaba el script al principio de la sesión, como para el ordenador aún no había ningún ratón, no hacía nada; pero cuando lo ejecutaba a mano, como ya lo había movido para lanzar el terminal, éste ya aparecía en la lista de dispositivos, y por eso funcionaba.

La solución final consistió en modificar el script para que, al lanzarse, compruebe regularmente si hay un dispositivo Logitech, y sólo entonces ejecute el comando xmodmap. El script final quedó así:

#!/bin/bash

x=1

while [ $x -ne 0 ]
do
	sleep 1
	xinput --list | grep Logitech
	x=$?
done

xmodmap -e "pointer = 1 13 3 4 5 6 7 8 9 10 11 12 2"

Dado que sabemos que tiene que haber un ratón Logitech (si no, no meteríamos este script), comprobamos una vez por segundo si en la lista de dispositivos de entrada aparece el receptor (esa pausa permite no consumir recursos inútilmente mientras esperamos a que aparezca). En el momento en que se cumpla sabemos que el comando xmodmap va a funcionar, así que lo ejecutamos y salimos del script.

Tablet con systemd

Cacharreo, Nueva versión, Trucos

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

Tamaño constante en GTK

Programación, Trucos

Hace unos días envié un parche para Slingshot, el lanzador de aplicaciones de Elementary OS. El problema que tenía es que tenía fijados al pixel los tamaños de todos los elementos. Esto se adapta bien si se utiliza el tema de Elementary y, además, en lengua inglesa. Sin embargo, en el momento en que se utiliza otro tema, o bien una lengua en la que alguna categoría de programas sea mucho más larga que en inglés, nos encontraremos con que el conjunto de iconos queda recortado por la derecha:

Se supone que esto no debería ocurrir porque Gtk permite crear interfaces que se redimensionen de manera automática, sin embargo en slingshot esto no ocurría. El motivo es que los iconos no están hechos con un Gtk.IconView, sino con botones dentro de un Gtk.Grid. Pero los autores querían, además, que dichos botones tuviesen un tamaño fijo de 130×130 pixels exactamente, por lo que la única idea que se les ocurrió fue fijar el tamaño exacto de la ventana que contiene todo el lanzador, incluyendo la lista de categorías, el buscador, etc. El motivo de hacerlo así es que dentro de cada botón hay, además del icono, una etiqueta con el nombre de la aplicación, y salvo que el contenedor tenga un tamaño determinado, la etiqueta intentará expandirse todo lo que pueda, y ni siquiera sirve de nada pedir un tamaño deseado, porque si el texto en la etiqueta es más largo, la etiqueta se expandirá todo lo que pueda para contener todo el texto.

La primera idea que se me ocurrió fue engancharme a la señal size_allocate del botón. Esta señal se emite cada vez que un widget cambia de tamaño por el motivo que sea, y recibe como parámetro sus nuevas medidas. Con ella y la propiedad max_width_chars intenté limitar el tamaño de la etiqueta para que el botón tuviese el tamaño máximo deseado; por desgracia era un proceso relativamente lento y que, además, provocaba un parpadeo en la ventana, pues ésta primero tomaba el valor máximo y se reducía progresivamente hasta el tamaño correcto, a medida que las distintas etiquetas iban reduciendo su número de caracteres.

La segunda idea, sugerida por la gente de la lista de desarrollo de Gtk, fue encapsular la etiqueta dentro de un Gtk.Fixed, pues permite ajustar manualmente el tamaño de cualquier widget situado en su interior. Esta solución casi funcionó, pues aunque la etiqueta se mantenía en el ancho deseado, el Gtk.Fixed contenedor se redimensionaba hasta ocupar el mismo espacio que ocuparía la etiqueta si estaba sola.

Ante esto me di cuenta de que la solución iba a necesitar de algo más de investigación y, sobre todo, de meterme en los entresijos del renderizado de Gtk, así que empecé a investigar, y descubrí que todo widget tiene dos métodos que participan de manera especial en la asignación de tamaño: get_preferred_width y get_preferred_height. Estos dos métodos devuelven dos valores: el primero es el tamaño mínimo que necesita dicho widget en el eje correspondiente para mostrar su contenido, y el segundo el tamaño deseado. En el caso de una etiqueta, el tamaño deseado será el ancho que ocupe la totalidad del texto puesto en una única línea, mientras que el tamaño mínimo dependerá de varias opciones: si no hay elipsis de texto coincidirá con el tamaño deseado, pero si no, será menor, de lo necesario para pintar el borde y unos puntos suspensivos.

Cuando un contenedor tiene en su interior otro widget, llama a estos dos métodos para saber cuanto espacio debe reservar. Lo interesante es que dichos valores son, realmente, orientativos, pues el contenedor puede asignar otros tamaños si así lo considera oportuno. Así, si una etiqueta pide 100 pixels pero está en una ventana que mide 200 y tiene activo el flag de expandirse, el tamaño final de la etiqueta será de 200. De igual forma, si una etiqueta pide un tamaño deseado de 100 pixels de ancho pero la ventana mide 50, recibirá 50 y el texto tendrá que ocupar varias líneas.

Ante esto se me ocurrió probar qué ocurriría si creo una nueva clase que herede de Gtk.Label, en la que redefino (override) el método get_preferred_width para que devuelva 120 como ancho mínimo y deseado (porque cada botón tiene un margen de 5 pixels por cada lado). El resultado es justo el deseado: la etiqueta mide exactamente el ancho que se le indica, y aplica las reglas para pasar a nuevas líneas o para añadir elipsis.

Por supuesto esto es fácil de hacer en Vala; en C es posible hacerlo también, pero obliga a meterse en el interior de GObject, una tarea que, sinceramente, no me llama demasiado en este momento.

Cagándola con un bug grave

Nueva versión, Opinion, Programación, Trucos

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.

XCB y Cairo

Programación, Trucos, tutoriales

Actualizado: Por fin he terminado la primera versión usable de TabletWM y TabletLauncher. Con ellos y el driver para la pantalla táctil he conseguido el gran objetivo de poder utilizar aplicaciones GNU/Linux nativas en una tablet sin teclado ni ratón.

Crear TabletWM fue, sin duda, la parte más compleja, porque supuso trabajar con un API completamente nuevo, como es XCB. Tenía claro que no quería utilizar XLib, así que me lié la manta a la cabeza, pero partiendo de un gestor de ventanas muy, pero que muy básico hecho por Cinolt a finales de 2011.

Lo primero que aprendí es que el protocolo X es lento, por lo que en un dispositivo como una tablet, con capacidades limitadas, no es recomendable pedir al servidor X las propiedades de una ventana cada vez que se quiere mostrar en pantalla o cambiar sus dimensiones o posición. Sin embargo no parece existir una manera de que el servidor avise al gestor de ventanas de que una propiedad ha cambiado, y dado que estas propiedades contienen información importante necesaria a la hora de mapear una ventana, la mejor solución que encontré fue hacer una caché de datos que relleno en el momento de hacer visible una ventana (en ese momento las propiedades ya tienen que estar definidas), aunque antes puedo haber almacenado otras operaciones que se hayan hecho en la ventana, como un cambio de tamaño o de posición.

Otra cosa que aprendí es que hay dos grupos de eventos de interés para un gestor de ventanas: request y notification. El primero se emite cuando una aplicación pide realizar alguna operación sobre una ventana suya, y la segunda si el resultado de dicha operación cambia algo realmente en la ventana. Así, si una aplicación pide cambiar el tamaño de una ventana, ejecutará un comando xcb_configure_window(). Si no existe un gestor de ventanas, dicho comando se ejecuta normalmente; pero si lo hay, se genera un evento xcb_configure_request en el gestor. Este puede decidir si ignorarlo, ejecutarlo tal cual o modificarlo. Si decide ejecutarlo y el tamaño de la ventana cambia realmente, se emite un evento xcb_configure_notification, que llegará a la aplicación.

Y aquí encontré otro de los problemas que tuve: mi intención es que las ventanas estén maximizadas siempre, por lo que cada vez que recibía un evento xcb_configure_request, emitía un comando xcb_configure_window() con el tamaño máximo de la pantalla. El problema ocurría con algunas ventanas que pedían ser más grandes que la pantalla, por ejemplo la ventana de configuración de Firefox. En este caso, se mostraba la ventana en la primera pestaña, y la pantalla es lo suficientemente grande como para contener todo; al recibir el evento, TabletWM modifica los valores pedidos por el navegador, ajustándolos al tamaño de la pantalla, y cambia las dimensiones de la ventana. Se emite el evento xcb_configure_notification y todo sigue perfectamente.

Pero cuando se escoge la pestaña de Seguridad, el nuevo contenido no entra en la pantalla, por lo que Firefox pide un tamaño más grande. El gestor de ventanas recibe el evento y cambia los parámetros por las dimensiones de la pantalla (que es el mismo tamaño que ya tiene la ventana), y da la orden de cambiar el tamaño. Pero como es el mismo, nunca se genera un evento xcb_configure_notification, pero Firefox espera que le llegue. El resultado es que la ventana queda sin refrescar.

La solución que apliqué fue ejecutar primero el comando de cambio de tamaño tal cual llega, y ejecutar luego un segundo comando con el tamaño que el gestor de ventanas desea. De esa manera la aplicación siempre recibe el evento que espera, y todos felices.

Otra curiosidad fue a la hora de leer ciertas cadenas de texto en las propiedades. En algunos casos, una propiedad (como por ejemplo _XKB_RULES_NAMES) contiene varias cadenas separadas por NUL (o sea, un byte a cero). Si pedimos el tamaño de ésta en la cookie (cookie->length) nos devolverá la longitud de la primera cadena exclusivamente. Si queremos obtener todas tenemos que utilizar xcb_get_property_value_length(), que sí nos dará el tamaño total. Por si fuera poco, no se garantiza que al final de la cadena haya un NUL, por lo que debemos tener en cuenta el tamaño para no pasarnos, en lugar de usar strcpy().

El teclado fue otro de los problemas serios que tuve: el método normal de entrada por teclado de X es relativamente rudimentario, por lo que hoy en día se utiliza la extensión XKB. Por desgracia esta extensión no está portada tal cual a XCB, sino que existe un proyecto separado, XCB-COMMON, que contiene aquellas partes no dependientes de un servidor X. Por si fuera poco, no puedo emular la pulsación de un carácter concreto, sino sólo la pulsación de una tecla en sí. Esto significa que los códigos que tengo que enviar a las X dependerán del idioma del teclado escogido por el usuario, además de tener que emular pulsaciones múltiples como la tecla mayúsculas, AltGR, etc.

Encima, esta biblioteca está orientada a obtener un carácter a partir de una pulsación, cuando yo necesitaba el proceso inverso. Aunque parte del trabajo lo hace (dado un carácter devuelve el código de la tecla), no devuelve el código de los modificadores necesarios. Así, si pido la arroba, me devuelve el código de la tecla ‘2’, pero no me dice si necesito pulsar también las mayúsculas (caso del teclado norteamericano) o AtlGR (caso del teclado español). Esto me obligó a realizar una pequeña chapuza, consistente en probar todas las posibles combinaciones de teclas normales y teclas modificadoras (shift, control, etc) para ver qué caracteres produce cada una.

Y para rizar el rizo, no es posible siempre obtener la combinación correcta, por lo que en algunos casos no queda más remedio que redefinir un código de tecla que no se utilice con un carácter determinado (por ejemplo, la letra Ñ). Esto hay que hacerlo con las funciones de entrada clásicas, no con las de XKB, por lo que el resultado final es algo caótico, pero funciona, y permite definir un teclado cualquiera en pantalla a partir de los caracteres que se quieren mostrar en lugar de las teclas físicas que se deben pulsar.

Pasando a Cairo, decidí utilizar esta biblioteca para los elementos gráficos (como el teclado o la ventana de apagado) en lugar de las funciones de X por varios motivos:

  • Cairo ofrece antialiasing, tanto en fuentes como en primitivas gráficas.
  • Cairo es una biblioteca moderna con un API sencillo y potente.
  • Ya conozco Cairo, pero no las funciones gráficas de X.
  • No supone una carga extra porque el lanzador de aplicaciones utiliza GTK, que por debajo trabaja también con Cairo.

Trabajar con Cairo directamente desde XCB no es muy complicado. Para ello, primero se debe crear una ventana, y a continuación una superficie Cairo con cairo_xcb_surface_create(). La principal complicación es conocer el visual_type de la ventana, para poder pasárselo a la función. Esto lo podemos saber mediante el siguiente código (la variable conn es el handler de la conexión con el servidor X):

    xcb_screen_t *scr=xcb_setup_roots_iterator(xcb_get_setup(conn)).data;
    xcb_visualtype_t *visual_type = NULL;
    xcb_depth_iterator_t depth_iter;

    for (depth_iter = xcb_screen_allowed_depths_iterator (scr); depth_iter.rem; xcb_depth_next (&depth_iter)) {
        xcb_visualtype_iterator_t visual_iter;

        visual_iter = xcb_depth_visuals_iterator (depth_iter.data);
        for (; visual_iter.rem; xcb_visualtype_next (&visual_iter)) {
            if (scr->root_visual == visual_iter.data->visual_id) {
                visual_type = visual_iter.data;
                break;
            }
        }
    }

Luego no tenemos más que engancharnos al evento expose de la ventana (XCB_EVENT_MASK_EXPOSURE) y, cada vez que se reciba, generar un contexto Cairo y repintar la ventana. Un detalle extra a tener en cuenta es que cada vez que se redimensione la ventana es necesario llamar a cairo_xcb_surface_set_size(), para cambiar el tamaño de la superficie Cairo.

Ah, y no olvidar hacer un xcb_flush() al terminar de pintar algo, para que efectivamente lo pinte en la ventana.

Gestion de energia

Cacharreo, Trucos

Nuevos cambios en la configuración del núcleo. Para que la gestión de energía funcione y la tablet se apague realmente al utilizar shutdown -h now o halt, y que apm -v devuelva el nivel actual de batería, es necesario activar las siguientes opciones:

    Power management options --->
        Run-time PM core functionality=Y
        Advanced Power Management Emulation=y
    Device Drivers --->
        Power supply class support=Y --->
            AXP Power drivers=Y --->
                AXP PMU type=AXP20 driver
                AXP initial charging environment set=Y
                AXP charging current set when suspendresumeshutdown=Y
            APM emulation for class batteries=Y
        Voltage and Current Regulator Support=Y --->

La última es necesaria para que aparezcan las de AXP Power drivers.