MarioDebian, mi devlog

Hace muy pocos días que he aterrizado en el mundo de android pero creo que voy avanzando poco a poco. Voy a publicar una minireceta de como compilar utilidades linux (sencillas) nativamente en Android. Antes de empezar sería bueno recordar que los binarios de Android se compilan para arquitectura ARM por lo que o usamos un emulador (tipo qemu) o un toolchain. Yo he usado el toolchain para compilar nativamente, con el emulador deberíamos compilar en estático y el binario ocupará bastante más. Vamos por pasos:

1.- Descargar el git de android, viene muy bien explicado aquí. Yo lo he descargado en mi $HOME/toolchain.

mkdir ~/toolchain
cd toolchain
wget http://android.git.kernel.org/repo
chmod +x repo
./repo init -u git://android.git.kernel.org/platform/manifest.git
./repo sync

2.- Hora de tomarse algo, descarga la friolera de 2.1 GiB, seguimos, hay que compilar la parte base (librerías)

make BUILD_TINY_ANDROID=true

3.- Tarda otro buen ratillo, ahora compilamos la parte oprofile (lo he compilado aquí porque así tenía a mano los includes de popt.h que son los únicos que he necesitado), cargamos el entorno de ayuda y compilamos el directorio actual y subdirectorios con "mm":

cd external/oprofile
. ../../build/envsetup.sh
mm 

4.- Ahora descargamos las fuentes de rsync (pueden valer las de Debian)

dget -u http://ftp.uk.debian.org/debian/pool/main/r/rsync/rsync_3.0.6-1.dsc
cd rsync-3.0.6

5.- La parte que más me ha costado ha sido entender los Makefile de Android que se llaman Android.mk. Este es mi Android.mk para rsync:

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES:= \
flist.c\
rsync.c\
generator.c\
receiver.c\
cleanup.c\
sender.c\
exclude.c\
util.c\
main.c\
checksum.c\
match.c\
syscall.c\
log.c\
backup.c\
options.c\
io.c\
compat.c\
hlink.c\
token.c\
uidlist.c\
socket.c\
hashtable.c\
fileio.c\
batch.c\
clientname.c\
chmod.c\
acls.c\
xattrs.c\
progress.c\
pipe.c\
params.c\
loadparm.c\
clientserver.c\
access.c\
connection.c\
authenticate.c\
lib/wildmatch.c\
lib/compat.c\
lib/snprintf.c\
lib/mdfour.c\
lib/md5.c\
lib/permstring.c\
lib/pool_alloc.c\
lib/sysacls.c\
lib/sysxattrs.c\
zlib/deflate.c\
zlib/inffast.c\
zlib/inflate.c\
zlib/inftrees.c\
zlib/trees.c\
zlib/zutil.c\
zlib/adler32.c\
zlib/compress.c\
zlib/crc32.c
LOCAL_SRC_FILES += netbsd_getpass.c
LOCAL_STATIC_LIBRARIES := \
libpopt
LOCAL_C_INCLUDES := \
$(LOCAL_PATH)/.. \
$(LOCAL_PATH)/../libdb \
$(LOCAL_PATH)/../libutil \
$(LOCAL_PATH)/../libop \
$(LOCAL_PATH)/../libabi
LOCAL_MODULE := rsync
include $(BUILD_EXECUTABLE)

El archivo netbsd_getpass.c lo he tomado de ~/toolchain/external/dropbear/netbsd_getpass.c ya que Android no debe tener la rutina getpass(), sólo se usa si la rutina getpassf() de rsync nativa falla.

6.- A compilar toca, sólo hay que ejecutar "mm" dentro del directorio rsync-3.0.6 y si todo va bien veremos al final:

target Executable: rsync (out/target/product/generic/obj/EXECUTABLES/rsync_intermediates/LINKED/rsync)
target Non-prelinked: rsync (out/target/product/generic/symbols/system/bin/rsync)
target Strip: rsync (out/target/product/generic/obj/EXECUTABLES/rsync_intermediates/rsync)
Install: out/target/product/generic/system/bin/rsync
make: se sale del directorio `/home/mario/toolchain'

7.- Para copiarlo al móvil (conectar el cable USB y activar el modo depuración USB en las preferencias)Necesitamos el SDK de Android.

cd ~/sdk/tools
sudo ./adb kill-server
sudo ./adb remount
sudo ./adb push ~/toolchain/out/target/product/generic/system/bin/rsync /system/bin
sudo ./adb shell chmod 755 /system/bin

Ya podemos abrir el terminal desde android (o desde adb shell) y ejecutar rsync para ver si se copio bien.

Se me ocurren miles de cosas sencillas (GScript + rsync) para tener las fotos publicadas en un blog, hacer copias de seguridad remotas (incrementales) o incluso usarlo para descargar contenido pudiendo perder la conexión temporalmente.

Rizando el rizo, estaría guapo hacer un pequeño frontend con las opciones más usadas y llamarlo desde una aplicación APK.

Como próximo objectivo compilar alguna otra cosa que hecho en falta (¿git? etc...)

No será por tener mucho tiempo libre pero me parecía útil programarlo y más compartirlo:

 

#!/usr/bin/env python
# -*- coding: UTF-8 -*-
#

import nautilus
import subprocess
import os

# put or comment Display configurators here.
# FORMAT
#   [ (string)command  ,        (boolean)need gksu  ]
HELPERS=[
    ["/usr/bin/displayconfig-gtk",              True],
    ["/usr/bin/nvidia-settings",                False],
    ["/usr/bin/gnome-display-properties",       False],
    ["/usr/bin/grandr",                         False],
]

class OpenDisplaySettings(nautilus.MenuProvider):
    def __init__(self):
        pass

    def open_window(self, *args):
        cmd=[]
        for helper in HELPERS:
            if os.path.exists(helper[0]):
                if helper[1]: cmd.append("/usr/bin/gksu")
                cmd.append(helper[0])
                subprocess.Popen(cmd,
                                shell=False,
                                bufsize=0,
                                stdout=subprocess.PIPE,
                                stderr=subprocess.STDOUT,
                                close_fds=True)
                return


    def get_background_items(self, window, _file):
        ICON="/usr/share/icons/gnome/16x16/devices/display.png"
       
        item = nautilus.MenuItem('NautilusPython::open-display-prop',
                                 'Configuración de pantalla',
                                 'Abrir configuración gráfica de pantalla')
        if not os.path.exists(ICON):
            ICON="gtk-dialog-warning"
        item.set_property('icon', ICON)
        item.connect('activate', self.open_window)
        return item,

Guardarlo como "open-display-prop.py" en el directorio ~/.nautilus/python-extensions/ (sino existe se crea)

¿Qué obtenemos?

 

Se pueden añadir más «helpers» o comentar alguno que no nos guste... los «helpers» se buscarán en órden, el segundo parámetro del helper es ver si necesita privilegios de root.

Para que funcione tenemos que tener instalado gksu y python-nautilus.

Hace un tiempo hablé un poco de refilón sobre USBIP, [USB/IP] un sistema que permite «mover» el punto de conexión de un dispositivo de una máquina a otra (por red) para por ejemplo conectarnos a un scaner, webcam o impresora remota...

Parece que se ha avanzado mucho en el proyecto y de hecho la parte que se ejecuta en el kernel está en el staging (algo como la cuarentena de nuevos drivers que entran al kernel antes de considerarse estables...) tanto es así que incluso las tools están en la cola NEW de Debian. Los paquetes que hice en su día no generaban libusbip así que habrá que tener cuidado cuando entren para no provocar conflictos.

Hoy me he descargado la última versión de las tools (0.1.7) y las fuentes del módulo de un kernel 2.6.28, lo he compilado en un 2.6.26-1-486 y parece que funciona

Ahora estoy haciendo pruebas con un terminal ligero sobre TCOS (recuerdo que ya teníamos soporte USBIP, aunque desactivado) y he conseguido pasar al servidor tanto una memoria USB (que se ha montado automáticamente ) como una captura de televisión analógica.

Para que esto sea útil en TCOS me surgen algunos problemas...

• Tengo que hacer un nuevo interfaz de usuario para ver que dispositivos USB hay en su terminal y conectarlos al servidor...
• lo que me lleva a modificar tcos-devices-ng o crear un programa nuevo...
• y lo más complicado, dar permisos exclusivos sólo a ese usuario cuando el dispositivo se conecte al servidor. (jugar con bits SUID y ver que dispositivos /dev se crean al cargar el driver del dispositivo en el servidor)
• Este nuevo driver puede provocar comportamientos no demasiado buenos en el servidor ¿que pasa si desenchufamos el terminal sin hacer «dettach»?

Para empezar he creado un pequeño parche para que la salida de «bin_driver --list» se pueda leer más facilmente por un script y poderlo mandar por XMLRCP al servidor. No se si mandarselo al upstream para ver si al menos lo tiene en cuenta. Diferencias:

La que viene por defecto

sudo bind_driver --list

List USB devices
- busid 3-3 (04b4:6830)
3-3:1.0 -> usb-storage
- busid 1-2 (147e:2016)
1-2:1.0 -> none
- busid 7-1 (05e3:0608)
7-1:1.0 -> hub
- busid 7-1.2 (04fc:0c15)
7-1.2:1.0 -> usb-storage
- busid 7-1.4 (05e3:0608)
7-1.4:1.0 -> hub
- busid 4-2 (0573:4d28)
4-2:1.0 -> usbvision
- busid 7-1.4.4 (046d:c062)
7-1.4.4:1.0 -> usbhid

La que añade el parche

sudo bind_driver --list2
#busid=3-3#usbid=04b4:6830#3-3:1.0=usb-storage#
#busid=1-2#usbid=147e:2016#1-2:1.0=none#
#busid=7-1#usbid=05e3:0608#7-1:1.0=hub#
#busid=7-1.2#usbid=04fc:0c15#7-1.2:1.0=usb-storage#
#busid=7-1.4#usbid=05e3:0608#7-1.4:1.0=hub#
#busid=4-2#usbid=0573:4d28#4-2:1.0=usbvision#
#busid=7-1.4.4#usbid=046d:c062#7-1.4.4:1.0=usbhid#

De momento no hay mucho más que decir, faltan muchas pruebas para que esto sea funcional.

UPDATE (20090126):

Parche aceptado en el proyecto y posiblemente sea co-mantenedor del paquete en Debian

Esto es muy curioso:

$ time sha512sum debian-testing-amd64-netinst.iso
0d4527ef57a43f070fd09eb0e5fe7e893be7f404d3aedb06a8b\
ac1666422e6e194b2cba13167033464146718adce77b5b75c\
9d276a2c344a62fbe25b883977af  debian-testing-amd64-netinst.iso

real    0m8.273s
user    0m7.648s
sys    0m0.532s

 

$ time sha512.py debian-testing-amd64-netinst.iso
0d4527ef57a43f070fd09eb0e5fe7e893be7f404d3aedb06a8b\
ac1666422e6e194b2cba13167033464146718adce77b5b75c\
9d276a2c344a62fbe25b883977af debian-testing-amd64-netinst.iso

real    0m1.731s
user    0m1.428s
sys    0m0.292s

 

Este es sha512.py:

#!/usr/bin/env python
import sys
import hashlib
f=open(sys.argv[1], 'rb')
data=f.read()
f.close()
print "%s %s" %(hashlib.sha512(data).hexdigest(), sys.argv[1])

 

No es fruto del cacheado ni el azar,tengo un script que mide varias ejecuciones (en modo alterno) y en python es casi 5 veces más rápido.

Esta tarde ha sido I+D+i+P+E, el protocolo NX no está muy bien documentado y existen ciertas partes que no son del todo compatibles con Debian por lo que la cosa consistía en rizar el rizo...

OBJETIVO: Reproducir un vídeo de Youtube en remoto con y sin compresión NX

Usando sólo herramientas disponibles en Debian (nxproxy, libnxcl) esta es la diferencia:

Sin compresión... (la barra blanca es un iftop con el máximo configurado en 100MiB, el típico ancho de banda de un switch 10/100, lo más común en redes educativas)

Esta es la buena noticia, con nxproxy (enlace tipo modem) casi 10 veces menos.

Falta mucho trabajo para integrar todo esto en TCOS y bastante código pero sin duda es un buen comienzo, saber que es posible: SE PUEDE COMPRIMIR XDMCP.

El vídeo de la chinita era el primero que salía en youtube, no canta del todo mal.

Desde TCOS he ido tomando partes de otros proyectos para dar una solución todo en uno sin tener que compilar ni configurar demasiadas cosas.

Una de ellas es el soporte de CDAUDIO desde el terminal ligero.

Cuando metemos un disco con datos mediante LTSPFS vemos las carpetas y los archivos en la sesión del servidor, pero como bien sabeis un disco de audio (o incluso VIDEOCD) no funciona así, no se puede montar a la manera tradicional y hay que usar una aplicación para reproducirlo.

CDFS es un pseudo sistema de archivos para el kernel de linux que añade una capa para que cuando montemos un CDAUDIO veamos los archivos wav de cada pista, se puedan copiar, reproducir, etc...

A partir de un cambio entre el kernel 2.6.24 y 2.6.25 se perdieron ciertas compatibilidades con las funciones iget() por lo que cdfs dejo de compilar y por supuesto de funcionar.

Uno que es un novato chapucero pero con muy buena iniciativa se estuvo documentando e intentando hacer un parche. Este parche ha dado la vuelta a varios buzillas de diferentes distribuciones (cdfs compilaba, no había probado a usarlo) pero dentro del punto de montaje aparecían fifos o directorios con el contenido del CDAUDIO de tamaño cero.

Hace unos días aparece mi bug en Debian como RC y el equipo debian-release se propone eliminarlo de la próxima versión "Lenny", así que yo pregunto al que cambió el kernel (trabajador de Red Hat y mi héroe particular el día de hoy) y me ha dado una clase magistral por correo.... resumiendo CDFS vuelve a funcionar (working cdfs patch for 2.6.26).

Cada vez estoy más convencido de lo bien que funciona el Software Libre.

UPDATE:

No me ha dado tiempo a acabar este post cuando me llega el correo del bugzilla de Debian cerrando el bug. Toma ya !!!

Via y Openchrome por fin trabajarán juntos.

 

 

¿Quién hace/es TCOS?

A la izquierda Ignacio Vidal (desarrollador de Lliurex, padre y responsable de toda la parte multimedia de TcosMonitor y un montón de cosas más) y a la derecha yo con una cara de sueño importante...

La noche anterior estuvimos de «Cena de Gala» y tuve el increible gusto de compartir mantel con algunas de las personas más importantes del mundo del software libre en este momento:

• Steve McIntyre (Debian Leader)
• Pascal Chevrel (Secretario de Mozilla Europa)
• Luciano Bello (Debian Developer) ¡qué tio más grande, lo que me pude reir con él!
• Viejos conocidos como Ismail Alí (MaX Madrid), Rodrigo Salvador (CGA Sevilla) o Miguel Gea (Xerako, Debian Developer).

En la mesa anexa teníamos a:

• Jon Maddog (Linux Foundation)
• Alexandro Colorado (OpenOffice.org Hispano, México)
• Kurt Gramlich (Skolelinux, Alemania)

Una de las anecdotas de la noche fue ver y escuchar la discusión (que nosotros mismos forzamos) entre Luciano y Pascal sobre Iceweasel y Mozilla... y es que aunque puedan existir piques en ciertos asuntos/momentos da gusto saber que realmente todos se llevan muy bien.

Por la tarde (antes de la cena de gala) tuvimos la segunda reunión de desarrolladores de distribuciones y aproveche para hablar con Kurt Gramlich (Debian-Edu/Skolelinux). Hablamos sobre LTSP, sobre ControlAula y estuve haciendo una minidemo de TCOS... creo que el proyecto le gustó mucho y hemos quedado en repasarlo de nuevo para que en un futuro pueda formar parte de la distribución educativa de Debian...

Ya sabe que casi todas las Comunidades Autónomas en España usan o están empezando a usar TCOS y cuando varios miles de equipos usan algo es el momento de publicitarse.

Resumiendo, gente muy simpática y agradable en Alicante, clima primaveral/veraniego, y muchos contactos nuevos. Enhorabuena y muchas gracias a la organización.

Supongo que muchos conocereis el paquete bootchart, que reemplazando a init guarda un registro del arranque del equipo para luego generar unas gráficas bastante chulas.

Pues bien, hasta ahora bootchart sólo trabajaba (que yo sepa) desde el mismo proceso init de la partición de nuestro linux y no había manera de lanzarlo desde el INITRAMFS... con un poco de «hacking» y mucho borrar código que no necesitaba he hecho un tcos-bootchartd para analizar el arranque de TCOS.

La víctima es un terminal ligero eTC3800 y este es el gráfico (pulsar para ver más grande):

Al tiempo total (47 segundos) hay que restar 2 segundos metidos a propósito para que se vean los últimos procesos antes de parar bootchartd.

Conclusiones:

• La descarga del squashfs es lo que más tiempo tarda (14 segundos)
• Gracias a bootchart he quitado un par de «sleep» que sobraban
• Gracias a bootchart he visto que el sistema de registro de dipositivos que se inyecta en udev (tcos-udev.sh) perdía mucho tiempo cuando aún no es útil por lo que se activa casi al final.
• «ldconfig» tarda casi 2 segundos... quizás se pueda mejorar ejecutándolo cuando se genera la imagen con «chroot ldconfig»
• El arranque tiene picos de 100% CPU sostenidos con udev y Xorg (algo relativamente lógico)

Hace un tiempo el arranque no bajaba de 1 minuto, tener un arranque usable (el terminal muestra GDM antes de los 44) ha sido todo un logro y gracias a bootchart podré saber donde se pierde ese tiempo tan precioso.

Luego lo subo al SVN por si alguien quiere probarlo.

Ayer me llegaba este correo:

Accepted:
netifaces_0.4-1.diff.gz
to pool/main/n/netifaces/netifaces_0.4-1.diff.gz
netifaces_0.4-1.dsc
to pool/main/n/netifaces/netifaces_0.4-1.dsc
netifaces_0.4.orig.tar.gz
to pool/main/n/netifaces/netifaces_0.4.orig.tar.gz
python-netifaces-dbg_0.4-1_amd64.deb
to pool/main/n/netifaces/python-netifaces-dbg_0.4-1_amd64.deb
python-netifaces_0.4-1_amd64.deb
to pool/main/n/netifaces/python-netifaces_0.4-1_amd64.deb


Override entries for your package:
netifaces_0.4-1.dsc - optional python
python-netifaces-dbg_0.4-1_amd64.deb - extra python
python-netifaces_0.4-1_amd64.deb - optional python
Announcing to debian-devel-changes@l.d.o
Closing bugs: 500394
Thank you for your contribution to Debian.

No hay mucho más que decir... yeeeepe!!!

Creo que ya se ha compilado en muchas arquitecturas aunque falta alguna.

Para empezar uno de los ftp-master ya me ha creado un bug (realmente no lo ha enviado, me ha mandado un correo)... en la descripción corta debo cambiar iface por interface.