Archivo de la categoría: Trucos

Trucos generales para distribuciones

Juegos ALSA sobre PulseAudio

Hace unas semanas descubrí la saga de juegos de Deponia, y la verdad es que estoy enganchado. Además, hay versiones nativas para Linux en GOG games, y a un precio asequible, lo que es una maravilla.

Las tres primeras aventuras funcionaron en mi sistema Debian sin el más mínimo problema, pero la cuarta, sin embargo, sufría de un problema raro: al lanzarla se quedaba como colgada, con la pantalla en negro, y no aparecía el menú principal hasta que pulsaba ESC. Además, lo hacía sin sonido, lo que era muy sospechoso.

Al lanzarlo desde un terminal vi que salían una serie de errores referentes a que no podía abrir el dispositivo PCM de ALSA (el subsistema de sonido de Linux). Enseguida sospeché que el problema podía venir por tener PulseAudio gestionando todo el tema del audio. En concreto, el cuelgue del principio parecía que era porque intentaba mostrar un vídeo de presentación, pero se quedaba esperando a que la tarjeta de sonido estuviese lista (y por eso al pulsar ESC se desbloqueaba: porque cancelaba el vídeo y pasaba al siguiente paso).

La solución consistió en redireccionar el sonido PCM de los programas ALSA a través de PulseAudio. Para ello sólo tuve que crear un fichero llamado .asoundrc en mi directorio personal con este contenido:

pcm.!default {
type pulse
}

Gracias a él, ahora todos los programas que, por defecto, trabajan con ALSA, ahora enviarán su salida a través de PulseAudio. Esto es posible gracias al diseño de ALSA: mientras que en la vieja arquitectura OSS el programador abría el dispositivo de sonido directamente y utilizaba llamadas IOCTL para configurarlo, y llamadas read y write para capturar y emitir sonido, en ALSA se anima a utilizar únicamente una serie de bibliotecas de más alto nivel. Lo interesante es que esto permite que el programa se desentienda por completo de a donde se envía el sonido, pues eso lo decide el propio usuario mediante la configuración. Así, por defecto iría directamente al hardware, pero el sistema de plugins de ALSA permite enviarlo a cualquier otro sitio al poder definir tarjetas de sonido virtuales. Así, tenemos dos módulos especialmente interesantes que son pcm_pulse y pcm_jack, que permiten integrar de manera transparente cualquier aplicación ALSA con los demonios de sonido PulseAudio y JACK. El primero es justo el que utilizamos en el fichero de configuración de arriba.

Java vs. systemd

Pues parece que ya podemos añadir otra historia más a los problemas de systemd. Ahora resulta que un cambio inocente en sus políticas ha hecho que un bug serio en Java salga a la superficie: prácticamente todas las aplicaciones Java fallan en Debian SID por culpa de esto, dando un error de este estilo:

library initialization failed - unable to allocate file descriptor table - out of memoryAborted

En mi caso fueron MPlabX y SimplicityStudio las que me dieron problemas, pero parece que ocurre con muchas más aplicaciones Java, y en concreto Android Studio también lo da.

Según una entrada en github, el problema se debe a que Java toma el número máximo de descriptores que se pueden abrir y reserva un bloque de memoria lo suficientemente largo como para albergarlos a todos. Hasta ahora ese número era 4096, con lo que con 16 Kbytes tenía de sobra. Pero tras un cambio en Systemd (pedido, además, por la gente del kernel) dicho número se ha ampliado a 262144 (256 * 1024). En principio esto no debería ser problema (sigue siendo una cifra razonable, y con un mega puede almacenarlo todo), pero, por una serie de desafortunadas circunstancias, Java no recibe esa cifra en Debian SID, sino que, si no hay configurado ningún límite, recibe INFINITY (los detalles se pueden seguir en este hilo de github). El resultado, obviamente, es un error de memoria insuficiente.

Mientras el error no se corrige, es posible parchearlo temporalmente añadiendo esta línea a /etc/security/limits.conf:

    *   hard   nofile   4096

No olvidarse del asterisco al principio. Y en caso de que 4096 no sean suficientes descriptores, se puede aumentar. Un valor máximo razonable es 1048576. Una vez modificado es necesario cerrar la sesión y volver a entrar (o bien reiniciar) para que los cambios surtan efecto.

Por supuesto es bueno revisar de vez en cuando si ya han corregido el bug, y eliminar esa línea cuando ya no sea necesaria.

Trust Flex Graphics Tablet

El otro día me compré una tableta gráfica Trust Flex Graphics Tablet. No es que suela dibujar a menudo, pero de vez en cuando me gusta hacer alguna cosa, y según qué tareas me dejan la muñeca fatal si las hago con el ratón.

Por desgracia ya al principio empezaron los problemas, pues Linux no me la detectaba. Sin embargo, lo raro era que sí había un dispositivo en /dev/input de la tableta, simplemente no se reconocía como un dispositivo digitalizador.

Empecé a rebuscar y encontré, por fin, gracias a una entrada del gitlab de freedesktop, que el problema se debe a que la tableta no entrega la resolución en unidades físicas; esto es, no se puede saber directamente a cuantos milímetros se corresponde unas coordenadas de posición. La solución consiste en añadir estas líneas en el fichero /etc/udev/hwdb.d/60-evdev.hwdb (creándolo si no existe):

#########################################
# Trust
#########################################

# Trust Flex Graphics Tablet
evdev:input:b0003v2179p0004*
 EVDEV_ABS_00=::234
 EVDEV_ABS_01=::328

Estas líneas añaden la entrada EVDEV_ABS_XX a los datos devueltos por el driver, de manera que libinput puede saber la resolución física de la tableta.

Una vez hecho esto hay que compilar el fichero mediante el comando

sudo udevadm hwdb --update

Y finalmente reiniciar para que el sistema aplique los cambios (sí, es necesario). Una vez hecho esto, la tableta funcionará perfectamente, apareciendo en pantalla un segundo cursor que seguirá al bolígrafo.

dbForge Mysql en Wine

Por una serie de circunstancias tengo que usar dbForge. Dado que se trata de un programa de windows parecía que no había otra que meter una máquina virtual, pero es un entorno que siempre supone un engorro porque no es directo conmutar desde ella hasta algún programa en el sistema operativo maestro. Ante esto decidí intentar hacerlo funcionar en Wine.

El primer problema que me encontré al intentar ejecutar el instalador fue que me exigía un entorno de 32 bits. Para no interferir con otros entornos de wine opté por crear uno independiente. Para ello, en la línea de comandos ejecuté:

export WINEPREFIX=~/.wine32
export WINEARCH=win32

Una vez hecho esto ya ejecutaba el instalador, pero me pedía .NET 3.5 SP1 o superior, y aquí empezaron los problemas. Probé a bajar el instalador de dicho .NET, pero no se dejaba instalar. Rebuscando, en varias páginas indicaban que había que usar winetricks para instalarlo. Así lo intenté con:

winetricks dotnet35sp1

Sin embargo, no se instalaba: algo fallaba en winetricks que la instalación fallaba.

Probé a instalar Mono para windows, pero no sirvió tampoco: el instalador no lo reconocía como un entorno .NET.

Tras varias pruebas infructuosas, finalmente se me ocurrió probar a instalar la versión 4.0 de .NET con:

winetricks dotnet40

Y esta vez sí se instaló completamente. Una vez instalado, probé el instalador de dbForge y también funcionó, así como el programa en sí (aunque da un pequeño aviso, indicando que necesita la versión 2.0 de .NET y que si se quiere bajar; basta con decir «No» y funcionará igualmente bien).

Cuando WiFi y Bluetooth chocan

Hace unos días mi padre estaba sufriendo un problema bastante raro: la conexión a internet de su nuevo móvil iba realmente mal y no recibía mensajes, pero sólo cuando usaba la WiFi de casa. Hice algunas pruebas y, efectivamente, con la WiFi era imposible navegar desde el móvil o enviar mensajes: prácticamente no funcionaba. De vez en cuando enviaba algún que otro mensaje, o era capaz de cargar media página, pero enseguida fallaba de nuevo.

Empecé a hacer pruebas y, de casualidad, llegué hasta el Bluetooth: cuando estaba activo la WiFi no funcionaba, pero si lo desactivaba, funcionaba todo perfectamente. Por desgracia, dado que mi padre tiene un manos libres en el coche, desactivarlo siempre no era una opción, y andar conectándolo cada vez que se sube al coche no es una solución práctica, porque, como nos pasaría a todos, o se olvidaría de encenderlo al subir, o se olvidaría de apagarlo al bajar.

En parte tiene sentido que el Bluetooth interfiera con la WiFi, porque ambos trabajan en la misma banda de frecuencia: 2,4GHz. Sin embargo, lo raro es que no ocurriese con el móvil viejo, así que tocó seguir investigando. ¿Era un problema de ese modelo concreto, tal vez?

La solución apareció por sorpresa: el motivo es que el móvil viejo sólo tenía WiFi 802.11g (que da un máximo de 54 megas por segundo), mientras que el nuevo tiene WiFi 802.11n (que puede dar hasta 300Mbps). Parece que el WiFi n es mucho más sensible a las interferencias, y tener un emisor (el de Bluetooth) tan cerca de su antena hace que no sea capaz de transmitir o recibir de manera fiable.

La solución, al final, consistió en ir al router y configurarlo para que sólo aceptase conexiones WiFi 802.11b/g, en lugar del modo por defecto que era 802.11b/g/n. De esta manera nunca se intentará conectar mediante el protocolo más moderno, y todo funcionará correctamente. Es la mejor opción, además, porque mezclar dispositivos 802.11g con 802.11n hace que el rendimiento de ambos baje mucho, con lo que es mejor que todos se conecten con el mismo protocolo.

El problema lo tengo ahora con mi sobrino, porque le pasa algo parecido pero su router, de Vodafone, no deja al usuario normal cambiar los protocolos, sólo el administrador. A ver si desde el servicio técnico nos lo hacen. Si no, tocará capar todos los equipos de casa uno a uno para que sean ellos los que no se conecten en modo 802.11n.

VirtualBox y Windows 10

Por circunstancias de la vida he tenido que usar Windows 10 en una máquina virtual sobre Linux, así que, por comodidad, decidí usar VirtualBox. Mi sorpresa fue descubrir lo terriblemente lento que iba. Por algún motivo se pasaba todo el rato accediendo al disco duro, y eso enlentecía el sistema hasta límites exasperantes.

Afortunadamente, rebuscando, encontré la solución:

  • Pulsar «Windows»+R, para ejecutar una aplicación, y lanzar «services.msc»
  • Buscar «Windows Search» y «Superfetch».
  • En cada uno, ir a Propiedades, detenerlo, y desactivarlo.
  • Profit!

Más Gentoo para MipsEL

Estoy actualizando la distribución de Gentoo para webtv y, como no podía ser de otra manera, hay problemillas. El último ha sido con busybox. Para poder compilarla hay que añadir, además de las opciones que indico en Generando Gentoo para WebTV, hay que añadir las siguientes:

busybox_config_option n NANDWRITE
busybox_config_option n NANDDUMP
busybox_config_option n FLASH_ERASEALL
busybox_config_option n FLASHCP
busybox_config_option n BLKDISCARD

Por otro lado, la variable USE debe contener:

USE="${ARCH} -pam -fortran -sanitize -X -iptables -hardened -seccomp -ipv6 -systemd -mdev internal-glib -caps -gtk -qt -t -boehm-gc -nls -filecaps"

Preparando Gentoo de nuevo

Estoy preparando una nueva versión de Transmission para el WebTV, y como perdí el sistema Gentoo que había construido hace tiempo he tenido que volver a generarlo, siguiendo mis propias notas.

Sin embargo esta vez me apareció un problema extra una vez finalizado todo. Para empezar, Python siguió dando problemas, así que compilé la versión 3.4 de manera cruzada y dejé para compilar en nativo la versión 3.5. Pero una vez compilado todo, y tras entrar con systemd-nspawn, me encuentro con que varios comandos, entre ellos el importantísimo emerge, devuelven un error rarísimo:

mipsel-unknown-linux-gnu / # env-update
Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.4/env-update", line 31, in 
    import portage
ImportError: No module named 'portage'

Tras muchas pruebas, descubrí que el problema era que, como el sistema gentoo nativo era de 64 bits, metió muchas bibliotecas en /usr/lib64, directorio que el sistema Mipsel no encontraba porque es de 32 bits.

La solución fue tan sencilla como copiar recursivamente /usr/lib64 a /usr/lib.

Usando DBus desde lenguaje C y JavaScript

Trabajar con DBus desde Python o Vala es muy sencillo: esconden la complejidad del protocolo de manera que uno tiene la ilusión de estar haciendo una llamada local. Sin embargo, históricamente, trabajar con DBus desde C ha sido considerado un peñazo de dimensiones colosales. Sin embargo, desde la llegada de la biblioteca GDBus, que integra DBus dentro de GIO la cosa se ha simplificado bastante, sobre todo en aquellos casos en los que simplemente queremos llamar de manera síncrona a un método remoto.

Debido a algunos cambios que estuve haciendo en Panther Launcher, necesité poder hacer precisamente eso: llamar a un método remoto mediante DBus desde C, para implementarlo dentro del applet para Gnome Flashback. Dado que no encontré documentación sencilla para este detalle concreto (esto es, sin usar entre medias un bucle de eventos), voy a comentar como lo hice, por si le es útil a alguien más.

Lo primero que necesitamos para poder llamar a un método remoto mediante DBus es la interfaz correspondiente donde se define dicho método. Esta interfaz se puede obtener de manera muy sencilla mediante dbus-send y las capacidades de introspección de DBus:

dbus-send --session --type=method_call --print-reply --dest=com.rastersoft.panther.remotecontrol /com/rastersoft/panther/remotecontrol org.freedesktop.DBus.Introspectable.Introspect

En este ejemplo obtenemos las interfaces disponibles en el objeto  /com/rastersoft/panther/remotecontrol, del servicio  com.rastersoft.panther.remotecontrol. El resultado es éste:

freedesktop.DBus.Introspectable.Introspect
method return time=1449871353.404951 sender=:1.1222 -> destination=:1.1246 serial=104 reply_serial=2
 string "<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<!-- GDBus 2.46.2 -->
<node>
 <interface name="org.freedesktop.DBus.Properties">
   <method name="Get">
     <arg type="s" name="interface_name" direction="in"/>
     <arg type="s" name="property_name" direction="in"/>
     <arg type="v" name="value" direction="out"/>
   </method>
   <method name="GetAll">
     <arg type="s" name="interface_name" direction="in"/>
     <arg type="a{sv}" name="properties" direction="out"/>
   </method>
   <method name="Set">
     <arg type="s" name="interface_name" direction="in"/>
     <arg type="s" name="property_name" direction="in"/>
     <arg type="v" name="value" direction="in"/>
   </method>
   <signal name="PropertiesChanged">
     <arg type="s" name="interface_name"/>
     <arg type="a{sv}" name="changed_properties"/>
     <arg type="as" name="invalidated_properties"/>
   </signal>
 </interface>
 <interface name="org.freedesktop.DBus.Introspectable">
   <method name="Introspect">
     <arg type="s" name="xml_data" direction="out"/>
   </method>
 </interface>
 <interface name="org.freedesktop.DBus.Peer">
   <method name="Ping"/>
   <method name="GetMachineId">
     <arg type="s" name="machine_uuid" direction="out"/>
   </method>
 </interface>
 <interface name="com.rastersoft.panther.remotecontrol">
   <method name="DoPing">
     <arg type="i" name="v" direction="in"/>
     <arg type="i" name="result" direction="out"/>
   </method>
   <method name="DoShow">
   </method>
 </interface>
</node>

Vemos que aparecen varias interfaces, dentro de cada una varios métodos, y dentro de cada método puede haber cero o más parámetros, y cero o más valores devueltos. Para nuestros propósitos no vamos a necesitar todo, sino sólo la interfaz com.rastersoft.panther.remotecontrol, así que eliminaremos el resto de entradas (y las líneas superiores descriptivas, sólo queremos el XML), y nos quedará esto:

<node>
 <interface name="com.rastersoft.panther.remotecontrol">
   <method name="DoPing">
     <arg type="i" name="v" direction="in"/>
     <arg type="i" name="result" direction="out"/>
   </method>
   <method name="DoShow">
   </method>
 </interface>
</node>

Este fichero XML es el que describe las llamadas que vamos a implementar.

Si queremos llamar a alguno de estos métodos desde JavaScript (por ejemplo, para hacer una llamada desde una extensión de Gnome Shell), sólo necesitaremos hacer lo siguiente:

const Gio = imports.gi.Gio;

const MyIface = '<node>\
 <interface name="com.rastersoft.panther.remotecontrol">\
  <method name="DoShow" />\
  <method name="DoPing" >\
   <arg name="n" direction="in" type="i"/>\
   <arg name="response" direction="out" type="i"/>\
  </method>\
 </interface>\
</node>';

const MyProxy = Gio.DBusProxy.makeProxyWrapper(MyIface);

let instance = new MyProxy(Gio.DBus.session, 'com.rastersoft.panther.remotecontrol','/com/rastersoft/panther/remotecontrol');
instance.DoShowSync();
instance.DoPingSync(0);

Primero importamos Gio para tener acceso a GDBus. Después insertamos el XML con la interfaz en una variable, y creamos un Proxy DBus con ella. Finalmente, cada vez que queramos acceder a un objeto (en este caso /com/rastersoft/panther/remotecontrol) de un servicio DBus (en este caso com.rastersoft.panther.remotecontrol), sólo tenemos que crear una instancia del proxy anterior, el cual nos permitirá llamar a los métodos definidos en la interfaz.

Cabe recalcar que aquí estoy llamando a los métodos con su nombre terminado en Sync. Eso significa que la llamada será bloqueante, y no retornará hasta que se reciba la respuesta del otro extremo. Es posible hacer llamadas asíncronas, pero no lo he investigado y no voy a entrar ahí.

Hasta aquí JavaScript, que es la parte más sencilla. Ahora llega el turno de como hacer esto mismo desde C.

GDbus tiene un generador de código que nos simplifica el trabajo. Para usarlo basta con grabar en un fichero el XML anterior (por ejemplo, remotecontrol.xml) y llamar a gdbus-codegen para que construya el código necesario para poder llamar a dichos métodos:

gdbus-codegen --c-generate-object-manager --generate-c-code dbus remotecontrol.xml

Este comando creará dos ficheros: dbus.c y dbus.h (se utiliza el nombre indicado en –generate-c-code) a partir del fichero remotecontrol.xml. Existen algunos parámetros extra, como –c-namespace, que permite especificar un prefijo para todas las funciones que se generen, y así evitar choques de nombres.

En dichos ficheros tendremos un montón de código ya escrito, y es precisamente este código el que nos simplifica el proceso, pues no tendremos que escribirlo nosotros. Una vez que lo tenemos, sólo hemos de llamarlo así:

#include "dbus.h"

GError *error = NULL;

ComRastersoftPantherRemotecontrol *proxy;

proxy = com_rastersoft_panther_remotecontrol_proxy_new_for_bus_sync (G_BUS_TYPE_SESSION,
                                                  G_DBUS_PROXY_FLAGS_NONE,
                                                  "com.rastersoft.panther.remotecontrol",
                                                  "/com/rastersoft/panther/remotecontrol",
                                                  NULL, /* GCancellable */
                                                  &error);
if (proxy != NULL) {
    error = NULL;
    retval = com_rastersoft_panther_remotecontrol_call_do_show_sync(proxy,NULL,&error);

    ...

    error = NULL;
    gint value;
    retval = com_rastersoft_panther_remotecontrol_call_do_ping_sync(proxy,0,&value,NULL,&error);
}

Tras incluir el fichero dbus.h para disponer de las llamadas, lo primero que hacemos es crear un puntero de tipo GError para recibir las excepciones que se produzcan.

A continuación creamos de manera síncrona un proxy de la interfaz concreta que queremos utilizar. Vemos que lo estamos haciendo para el bus de sesión, para el objeto /com/rastersoft/panther/remotecontrol del servicio com.rastersoft.panther.remotecontrol. Es fundamental que el puntero GError esté inicializado a NULL, pues de no hacerlo la llamada fallará.

Y una vez que tenemos dicho proxy ya podemos llamar a los métodos remotos. Vemos que cada llamada está formada por el nombre de la interfaz, más _call_, más el nombre del método, y en este caso, como la llamada queremos que se bloquee hasta que llegue la respuesta, termina en _sync. El primer parámetro es el proxy, y los dos últimos un puntero a la función para cancelar la llamada (que ponemos a NULL para no complicarnos la vida) y un puntero a GError, que también debe estar inicializado a NULL antes de llamar a la función.

Entre medias se introducen, en el mismo orden en que están definidos en el XML, los parámetros de entrada (que se pasan por valor) y punteros para los parámetros de salida.

Para compilarlo hay que utilizar pkg-config gio-2.0 gio-unix-2.0 para que se añadan las cabeceras y bibliotecas necesarias.

Y ya está, con esto podemos por fin llamar de manera sencilla un método DBus desde lenguaje C.

Peleandome con Python 3.4

Dado que quiero tener soporte para gnutls, tuve que cambiar el USE de mi distribución a:

USE="${ARCH} -pam -fortran -sanitize -iptables -static -systemd -mdev gnutls internal-glib -caps -filecaps -X -gtk -qt -tk"

Las siete últimas adiciones fueron para no añadir nada de entorno gráfico (pues no tiene sentido en el WebTV) y para asegurar de que las nuevas bibliotecas necesarias para incluir gnutls se puedan compilar. Hubo varios problemillas, pero uno a uno los fui resolviendo.

Por desgracia, el último escollo estaba en python. Cuando compilé el sistema la versión estable era la 3.3, pero ahora ya salió la 3.4. El problema es que se negaba a compilar, dando un error raro:

Python build finished successfully!
The necessary bits to build these optional modules were not found:
    _tkinter
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
Failed to build these modules:
    _socket               _ssl

Decía que se había compilado correctamente, pero emerge devolvía un error. Al principio pensaba que el problema estaba en tkinter, el módulo gráfico de python, pero no tenía sentido porque había especificado que no quería ni tk, ni X ni nada relacionado con un entorno gráfico. Entonces, revisando el log, vi que en medio de la compilación había este error:

/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.o
/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.c: In function 'makesockaddr':
/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.c:1175:14: error: dereferencing pointer to incomplete type
         if (a->can_ifindex) {
              ^
/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.c:1176:32: error: dereferencing pointer to incomplete type
             ifr.ifr_ifindex = a->can_ifindex;
                                ^
/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.c:1183:38: error: dereferencing pointer to incomplete type
                                     a->can_family);
                                      ^
/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.c: In function 'getsockaddrlen':
/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/socketmodule.c:1802:28: error: invalid application of 'sizeof' to incomplete type 'struct sockaddr_can'
         *len_ret = sizeof (struct sockaddr_can);
                            ^
building '_ssl' extension

¿CAN? ¿En el módulo de sockets? Bastante raro. Rebuscando encontré que, efectivamente, desde el núcleo 2.6.25 hay soporte para el bus CAN; sin embargo, mi núcleo (y sus cabeceras) es el 2.6.22. ¿Por qué se empeñaba en incluir soporte? Por otro lado, python 3.3 también trae de serie soporte para bus CAN, pero esa versión sí compilaba bien. ¿Qué estaba pasando?

Al final descubrí que el núcleo 2.6.22 tiene algo de soporte del bus CAN, pero parece que no el suficiente, y eso lía a python 3.4.

La solución que encontré fue editar el fichero /usr/include/bits/socket.h, y comentar la línea donde se define AF_CAN:

//#define AF_CAN PF_CAN

Y con eso, por fin, pude compilar absolutamente todo, listo para empezar a preparar el sistema que va a llevar definitivamente.