Etiquetas

viernes, 7 de febrero de 2014

Crear un paquete DEB a partir de código fuente "upstream"

Siempre lo dije y lo seguiré sosteniendo: una de las cosas que mejor resumen la idea de belleza y eficiencia es el sistema de empaquetamiento de Debian, que así en español no suena del todo bien, hablamos del Debian Package Management System.
Sigue un tip muy breve sobre cómo crear un .deb instalable a partir de un tarball de código fuente "upstream".


Uno de los aspectos de la belleza de DPKG, la base del Debian Management System es la manutención y actualización de los paquetes. Tener idea de los paquetes que tenemos instalados en un servidor o en una estación es rápido y simple, mucho más rápido que tener que hacer find por directorios como /usr/local, /opt.
Por eso siempre es recomendable, de ser posible, usar el sistema de empaquetamiento antes que instalar soft, por ejemplo usando make install (el paso culminante de la compilación de soft con Make: configure, make, make install).
Unas razones por las que es mejor el sistema de empaquetamiento es simple. Si quisiéramos desinstalar el paquete es simplemente dpkg -r, o apt-get remove... y el sistema de gestión de paquetes se va a encargar de borrar los archivos necesarios, y listo.

En otro tip vimos cómo compilar y crear un deb fácilmente cuando el código fuente está en los repositorios Debian
http://www.equiscentrico.com.ar/2011/06/como-crear-paquetes-deb-partir-de.html

¿Y si solo tenemos un .tar.[gb]z ?

A no desesperar. dh_make es el dueño de la magia. Este programa forma parte del paquete debhelper, que es el juego de herramientas para la creación de debs.

Para ejemplificar voy a usar el código fuente de piklab, que es un IDE para el desarrollo en Microcontroladores PIC, que no encontraba en los repositorios de wheezy. Su código fuente se puede encontrar aquí http://sourceforge.net/projects/piklab/files/
Una vez que lo descargamos, y descomprimimos:

$ bzip2 -dc piklab-0.16.2.tar.bz2 | tar xvf -

dh_make va a hacer la magia:

$ cd piklab-0.16.2
$ dh_make -f ../piklab-0.16.2.tar.bz2

dh_make va a crear todos los archivos para la debianización.

Opcionalmente, antes de hacerlo se pueden fijar algunas variables del entorno, para que los datos del "mantainer" como correo y nombre queden ok. En este ejemplo estamos creando un deb para uso propio o distribución en una empresa. Si el paquete fuera a formar parte de los repositorios Debian debe cumplir toda una serie de requisitos extra.
Una vez que dh_make hizo su magia, ahora sí, compilamos (desde dentro del dir del fuente):

$ dpkg-buildpackage -us -uc

A tomar algo y luego obtendremos el .deb (atenti con todas las dependencias que requiera el soft):

dpkg-deb: construyendo el paquete `piklab' en `../piklab_0.16.2-1_i386.deb'.
dpkg-genchanges >../piklab_0.16.2-1_i386.changes
dpkg-genchanges: incluyendo el código fuente completo en la subida
dpkg-source --after-build piklab-0.16.2
dpkg-buildpackage: subida completa (se incluye la fuente original)

Podemos instalarlo:

# dpkg -i piklab_0.16.2-1_i386.deb
Seleccionando el paquete piklab previamente no seleccionado.
(Leyendo la base de datos ... 311105 ficheros o directorios instalados actualmente.)
Desempaquetando piklab (de piklab_0.16.2-1_i386.deb) ...
Configurando piklab (0.16.2-1) ...
Procesando disparadores para man-db ...
Procesando disparadores para hicolor-icon-theme ...
Procesando disparadores para shared-mime-info ...
Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'
Unknown media type in type 'uri/mms'
Unknown media type in type 'uri/mmst'
Unknown media type in type 'uri/mmsu'
Unknown media type in type 'uri/pnm'
Unknown media type in type 'uri/rtspt'
Unknown media type in type 'uri/rtspu'
Procesando disparadores para desktop-file-utils ...

Para aquel que todavía no lo crea: Ain't it nice?


Matías Gutiérrez Reto (retux)
Continuar »

miércoles, 1 de enero de 2014

go-mtp para conectar smartphone android a Linux usando mtp

En los actuales smartphones basados en Android fue triste la decisión de abandonar el soporte como "almacenamiento masivo" para transferencia de archivos entre un pc y el móvil para reemplazarlo por mtp (Media Transfer Protocol), desarrollado originariamente por Microsoft.


Me llevó varias horas de trabajo. Compilar libmtp a la versión 1.1.6. Para hacerlo fácil, en Debian puede seguirse el procedimiento descripto en esta entrada de equiscentrico: http://www.equiscentrico.com.ar/2011/06/como-crear-paquetes-deb-partir-de.html sólo bastará reemplazar el nombre del paquete de ejemplo (era midori en aquel caso) por libmtp.

Después probé varias alternativas: kio-mtp, mtpfs... ambos compilados a sus versiones más recientes en los repositorios de fuentes de Sid. En un Samsung S2 el funcionamiento era estable, pero en un Samsung Trend (supongo que debe tener un Android algo más nuevo (?) no había caso.

go-mtp fue el camino

Conviene asegurarse que nuestro usuario pertenezca a los grupos "plugdev" y "fuse":

$ groups
retux dialout cdrom audio video plugdev fuse wireshark

Instalar go-mtp

En el gitHub del proyecto se puede bajar el paquete https://github.com/hanwen/go-mtpfs y como indica la documentación, la compilación del programa es sencilla:

1) Instalación de go-mtp:

# apt-get install golang-go
# apt-get install libusb-1.0-0-dev

$ mkdir /tmp/go
$ export GOPATH=/tmp/go
$ go get github.com/hanwen/go-mtpfs

En el directorio /tmp/go/bin/go-mtpfs tendremos el binario.

Podemos copiarlo a un directorio permanente:

# cp /tmp/go/bin/go-mtpfs /usr/local/bin



2) Usando go-mtp

2.1) Creamos un directorio como punto de montaje

# mkdir /media/samsung
# chown retux /media/samsung

Obviamente, reemplazando "retux" por el nombre de usuario que corresponda.

La magia de go-mtp (conectando el teléfono al usb previamente, claro):

$ go-mtp /media/samsung &
2014/01/01 15:35:00 starting FUSE.

Véase el mensage que indica el inicio de FUSE. Si aparece, ya tendremos accesible el sistema de archivos del teléfono vía mtp:

$ ls /media/samsung/Phone/
Alarms data-app gameloft GoLocker_in GOWeatherEX Music Podcasts TalkingFriends
Android DCIM GOLauncherEX GoStore media Notifications Pou WhatsApp
AppGame Download golocker GoTheme Movies Pictures Ringtones

Una vez que lo hayamos usado, solo basta desmontarlo:

$ fusermount -u /media/samsung
Continuar »

jueves, 26 de diciembre de 2013

Cross-compile para Raspberry Pi con scratchbox2 - Un borrador

En realidad, estas notas son apenas un borrador.
Llevo un tiempo haciendo cross-compile del kernel linux para raspberry pero siempre compilar algún programa en C++ propio me había resultado muy complicado.
Hoy decidí probar con scratchbox2 y este es el borrador del "work-in-progress". La verdad parece muy util y directo que otro acercamiento.

Como dije, esto es un borrador, no un tutorial. Por eso si alguien encuentra errores, o conoce scratchbox más en profundidad cualquier aporte será bienvenido. Es un borrador, porque además fui haciéndolo en días sucesivos, por lo tanto podría haber algun/os error/es.

Decidí utilizar los paquetes más estándares posibles, disponibles en los repositorios de Debian Wheezy.
El sistema "host" es un i386, mientras que el "target", lógicamente será un armv6, el tipo de arquitectura de CPU de la Raspberry Pi.
Por lo que leí, resumido brevemente, la gran ventaja de scratchbox es que es una jaula fakeroot en la que se instalará un fs root de raspbian y allí podremos ir instalando las dependencias (librerías) que el soft que vayamos a compilar requiera. Scratchbox y qemu serán los encargados de mantener la magia, es decir, compilar para la arquitectura "target" e inclusive ejecutar código compilado para arm en la CPU "host". Con algunos ejemplos creo que se puede ver mejor:

1) Instalación de los paquetes necesarios:

# aptitude install scratchbox2 fakeroot realpath qemu-user

2) Instalación del toolchain

El "toolchain" para compilación cruzada podría compilarse, pero lo más directo es usar las rpi-tools, disponibles en este repositorio git.

$ mkdir -p $HOME/raspi_build/rpitools/ && cd $HOME/raspi_build/rpitools/
$ git clone https://github.com/raspberrypi/tools.git --depth 0

Tomemos nota del directorio donde lo instalamos y a seguir

3) Extracción del rootfs de raspbian

Para crear el ambiente que scratchbox precisará para su magia, vamos a copiar de una imagen de raspbian el sistema de archivos raíz (rootfs), que normalmente está en la segunda partición de la imagen de la SD:

Para esto usé una imagen más o menos actual de raspbian: 2013-07-26-wheezy-raspbian.img


$ mkdir -p $HOME/sb2_lab/mnt
$ cd $HOME/sb2_lab
$ mkdir raspbian-rootfs
Crear el dir de trabajo donde se prefiera, claro y copiar allí la img de raspbian.

$ cd $HOME/sb2_lab
$ /sbin/fdisk -lu 2013-07-26-wheezy-raspbian.img

Disco 2013-07-26-wheezy-raspbian.img: 1939 MB, 1939865600 bytes
255 heads, 63 sectors/track, 235 cylinders, 3788800 sectores en total
Units = sectores of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identificador del disco: 0x00047c7a

Disposit. Inicio Comienzo Fin Bloques Id Sistema
2013-07-26-wheezy-raspbian.img1 8192 122879 57344 c W95 FAT32 (LBA)
2013-07-26-wheezy-raspbian.img2 122880 3788799 1832960 83 Linux
Veamos, que la partición tipo linux comienza en el sector 122880, y cada sector tiene 512 bytes. Con eso vamos a montar el loop device para copiar los archivos.
Hagamos el cálculo:
$ echo "512 * 122880" | bc
62914560


Para montar el loop device, tenemos que hacerlo como root y le pasamos el offset que calculamos:

# mount -o ro,loop,offset=62914560 -t auto 2013-07-26-wheezy-raspbian.img mnt/

A copiar:

$ cd $HOME/sb2_lab/
$ rsync -avz mnt/ raspbian-rootfs

Ahora en el subdir ./raspbian-rootfs tendremos el rootfs de raspbian

$ ls raspbian-rootfs/
bin boot dev etc home lib lost+found media mnt opt proc root run sbin selinux srv sys tmp usr var


4) Iniciar el ambiente de scratchbox

Ingresamos al directorio donde copiamos el rootfs de raspbian, de otra manera sb2 no podrá iniciar bien el toolchain.
Vamos iniciar el ambiente para Scratchbox2, pasandole la ubicación de gcc en la versión del toolchain para Cross-Compile que habíamos bajado:

$ cd $HOME/sb2_lab/raspbian-rootfs
$ sb2-init raspberrypi_wheezy
/home/matias/raspi_build/rpitools/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc

Al final del proceso aparecerá:

"sb2-init completed successfully, have fun!"

Si no aparece, a desconfiar de algo y revisar.
Con eso ya tenemos el ambiente listo. Ahora, a probarlo.

5) Compilando algo para probar

Creemos el siguiente código, solo para probar. Puede ser en el directorio de trabajo o en cualquier otro:

/* Archivo: teste.c - Solo para probar sb2 */
#include <stdio.h>
int main(){
printf("Hello, #RasPi\n");
return 0;
}

Lo llamé teste.c, vamos a compilarlo dejando que scratchbox haga su magia:

$ sb2 gcc -o teste teste.c

Ahora veamos la info sobre el binario que creó:

$ file teste
teste: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x2c11b259c80ffd4ceccb9a2a0622fb12571858f7, not stripped

$ readelf -a teste | grep -i "cpu\|mach"
Machine: ARM
Tag_CPU_name: "6"
Tag_CPU_arch: v6
Tag_CPU_unaligned_access: v6

Como se ve, la arquitectura de destino fue, en efecto, arm v6.
Ahora, con la ayuda de qemu scratchbox permite hasta ejecutar el binario arm en el sistema "host" (i386):

$ sb2 ./teste
Hello, #RasPi

6) Probar compilar algo del mundo "real"

Por ahora, todo muy lindo. Pero el código de ejemplo es tan básico que precisa de librarías estándares y mínimas.
Probé lo siguiente, que me estaba dando mucho laburo compilar sin usar scratchbox.
El código siguiente es muy simple, es parte de unas clases que usé y modifiqué un poquito para controlar los leds de "status" de una raspberry. Los leds indican si el sistema completó el boot y monitorea el estadod e ethernet. Es algo bastante útil si se usa una RasPi sin monitor, para tener una idea de su estado si necesidad de ping, conectar por ssh, etc.

$ git clone https://github.com/retux/raspileds_status --depth 0
Cloning into 'raspileds_status'...
remote: Counting objects: 56, done.
remote: Compressing objects: 100% (44/44), done.
remote: Total 56 (delta 11), reused 50 (delta 5)
Unpacking objects: 100% (56/56), done.

Originariamente, había compilado estos binarios directo en la raspi. Porque la verdad el tiempo de compilación es mínimo. Ahora compilarlo con ScratchBox fue muy sencillo:


$ cd raspileds_status
$ sb2 make clean
rm -f *.o
$ sb2 make
g++ -Wall -c -o GPIOClass.o GPIOClass.cpp
g++ -Wall -c -o netifledwatch.o netifledwatch.cpp
g++ -Wall -o netifledwatch GPIOClass.o netifledwatch.o
g++ -Wall -c -o gpiopinctrl.o gpiopinctrl.cpp
g++ -Wall -o gpiopinctrl GPIOClass.o gpiopinctrl.o
g++ -Wall -c -o gpioctrl.o gpioctrl.cpp
g++ -Wall -o gpioctrl GPIOClass.o gpioctrl.o

Veamos alguno de los binarios para confirmar:
$ file netifledwatch
netifledwatch: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xd7cb48d849ae94101dbd00c1ad28f67f0f56048b, not stripped

Como se ve, la magia de ScratchBox hizo posible que ni siquiera fuera necesario modificar el Makefile.

¿Qué sigue?

Queda por ver cómo se puede usar las maravillas de apt-get en el ambiente scratchbox, por ejemplo, para instalar dependencias necesarias para compilar soft más complejo. No lo probé aún, pero tiene que poder hacerse.

Agregado 27/12/2013:

Con la imagen de raspbian reciente que estoy usando para el ambiente chroot de scratchbox, es necesario comentar la línea del archivo ld.so.preload, porque de lo contrario algo de la emulación con qemu se rompía y no permitía por ejemplo ejecutar un apt-get update dentro del ambiente chroot.

$ cat raspbian-rootfs/etc/ld.so.preload
#/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so

Después de eso, se puede ejecutar apt-get update e instalar paquetes en el ambiente, sin problemas:

$ sb2 -eR apt-get update
Get:1 http://mirrordirector.raspbian.org wheezy Release.gpg [490 B]
Get:2 http://mirrordirector.raspbian.org wheezy Release [14.4 kB]
Get:3 http://raspberrypi.collabora.com wheezy Release.gpg [836 B]
Get:4 http://archive.raspberrypi.org wheezy Release.gpg [490 B]
...

$ sb2 -eR apt-get install vim
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libgpm2 vim-runtime
...

¿Lindo, no es cierto? De esta forma podrían instalarse con apt-get las libs y dependencias para compilar el soft X e intentar el cross-compile con Scratchbox.

Agregado 30/12/2013:

Correr apt-get y todas sus maravillosas luces y botoncitos dentro del ambiente chroot de scratchbox2, por eso siguen una líneas con el procedimiento usado:

Primero entramos en la emulación de Scratchbox con el siguiente comando:
$ sb2 -eR
[SB2 emulate raspberrypi_wheezy] root@debian-test-kput raspbian-rootfs #

Vemos que estamos en el ambiente chroot, lo que nos informa el prompt.

Segundo, instalamos las claves públicas de los repositorios:

[SB2 emulate raspberrypi_wheezy] root@debian-test-kput raspbian-rootfs # wget http://archive.raspbian.org/raspbian.public.key -O - | apt-key add -
--2013-12-30 15:28:47-- http://archive.raspbian.org/raspbian.public.key
Resolviendo archive.raspbian.org (archive.raspbian.org)... 5.153.225.206, 2001:41c9:1:3ce::10
Conectando con archive.raspbian.org (archive.raspbian.org)[5.153.225.206]:80... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 1776 (1,7K) [application/octet-stream]
Grabando a: “STDOUT”

100%[======================================================================================>] 1.776
--.-K/s en 0s

2013-12-30 15:28:47 (13,0 MB/s) - escritos a stdout [1776/1776]
OK

[SB2 emulate raspberrypi_wheezy] root@debian-test-kput raspbian-rootfs # wget http://archive.raspberrypi.org/debian/raspberrypi.gpg.key -O - | apt-key add -

2013-12-30 15:52:34 (12,2 MB/s) - escritos a stdout [1719/1719]

OK

[SB2 emulate raspberrypi_wheezy] root@debian-test-kput raspbian-rootfs # wget http://raspberrypi.collabora.com/collabora-raspbian.gpg -O - | apt-key add -
--2013-12-30 16:01:35-- http://raspberrypi.collabora.com/collabora-raspbian.gpg
Resolviendo raspberrypi.collabora.com (raspberrypi.collabora.com)... 93.93.128.223
Conectando con raspberrypi.collabora.com (raspberrypi.collabora.com)[93.93.128.223]:80... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 3145 (3,1K) [text/plain]
Grabando a: “STDOUT”

100%[======================================================================================>] 3.145 --.-K/s en 0s

2013-12-30 16:01:35 (22,6 MB/s) - escritos a stdout [3145/3145]

OK


Conclusión provisional

Con apt-get completo corriendo, pudiendo instalar dependencias para aquello que vayamos a compilar scratchbox2 es una belleza.
Inclusive, hace hasta innecesario y menos eficaz tener necesidad de emular un raspbian (o cualquier otra distro) en un x86, porque basta hacer:

$ sb2 -eR

Y ya estamos en el ambiente chroot, desde donde podremos ejecutar los binarios compilados para arm, cuyas instrucciones serán reinterpretadas y traducidas por qemu.
Continuar »