Subida del paquete al repositorio (reprepro)¶

El paso final desde el lado del desarrollador es enviar el paquete para que en el servidor se procese con reprepro y se integre finalmente al repositorio publico.

Usa de las formas para enviar el paquete es usando dput.

Este comando se encarga de subir todos los archivos que correspondan al paquete que tengamos.

Tenemos que crear un archivo ~/.dput.cf con la configuración de los repos donde podemos subir los paquetes. Ejemplo:

ragnarok@jola:~$ cat .dput.cf 
[DEFAULT]
default_host_main = huayra-repo

[huayra-repo]
fqdn = devel-huayra.conectarigualdad.gob.ar
method = scp
login = repo
incoming = /home/repo/linuxparatodos/apt/incoming

NOTA: En nuestro caso, hay un script en cron cada 5 minutos que se encarga de procesar los paquetes que están en cola en el directorio incoming.

Ahora, vamos a necesitar que nuestra llave pública SSH (no gpg como la que usamos para firmar) esté también habilitada en el servidor.
En tal caso, va a ser posible que se puedan subir los archivos.

Podemos generar la clave en caso de no tenerla:

ragnarok@jola:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ragnarok/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): ******************
Enter same passphrase again: ******************
Your identification has been saved in /home/ragnarok/.ssh/id_rsa.
Your public key has been saved in /home/ragnarok/.ssh/id_rsa.pub.
The key fingerprint is:
72:3f:ca:a8:10:38:d1:8a:b1:62:f1:fa:1d:53:d2:21 ragnarok@jola
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|     E .         |
|      + S        |
|.o   . = .       |
|+ +   o   o      |
|++ + ..o . .     |
|B...==+.o        |
+-----------------+

Debemos enviar nuestro archivo con la clave publica id_rsa.pub al admin.

Luego ya podemos intentar subir el paquete:

dput mipaquete_1-1_amd64.changes

Si está todo bien, en el servidor se encarga de inyectar nuestro paquete al repositorio y lo tendremos disponible en breve a través de apt en las máquinas clientes.

Hook en caso de que falle el build

Modificar el archivo ~/.pbuilderrc y agregar una variable HOOKDIR

HOOKDIR="/home/usuario/.pbuilder/hook.d" 

Luego crear un archivo /home/usuario/.pbuilder/hook.d/C10shell_build_fail
con lo siguiente:

#!/bin/sh
# invoke shell if build fails.

apt-get install -y --force-yes vim less bash
cd /tmp/buildd/*/debian/..
/bin/bash < /dev/tty > /dev/tty 2> /dev/tty

Hacer este script ejecutable

chmod +x  /home/usuario/.pbuilder/hook.d/C10shell_build_fail

Si pbuilder falla, se ejecuta este script (dentro del chroot) que instala algun paquete que necesitemos para trabajar (vim, less, bash) y nos deja en el directorio del source. Para salir limpiamente usamos exit. Este metodo nos sirve para revisar que falló del build.

Tambien podemos agregar un hook (conla letra B como prefijo) llamado por ejemplo B10shell_build_ok que se ejecuta en caso de que pbuilder construya correctamente el paquete. De esta forma, tabien quedamos dentro del chroot pero con el build satisfactorio. Podemos ver logs o revisar alguna información. Luego cuando salimos con “exit”, los .deb’s generados se copian al directorio buildresult

Notas para build entre ambas arquitecturas

Hay varios puntos a tener en cuenta para poder generar los paquetes para las dos arquitecturas (i386 y amd64)

• Tener los base.tgz de acuerdo a cada arquitectura (base-i386.tgz y base-amd64.tgz) y con el pbuilderrc elegimos de acuerdo a la variable cual se va a utilizar

• Si ya generamos y subimos al repo un build de amd64 usando el .changes normalmente, significa que ya se subió el sources y el orig.tar.gz. Entonces cuando ahora generemos el paquete para la nueva arquitectura (i386) solo tenemos que subir los archivos dependiente de esta plataforma. (binarios)
  Por este motivo, se pasa un parámetro al pbuilder para que cree un .changes sin los sources para hacer el upload

ARCH=i386 pdebuild --debbuildopts -B

Si no lo generamos de esta manera, cuando subamos el .changes con dput al reprepro vamos a tener un error de checksum por los md5 porque ya habian sido subido anteriormente el source.

No es importante el orden de cual arquitectura se genere primero, siempre y cuando el resto se generen sin los sources (–debbuildopts -B)

Nota para la primer subida del paquete al repo (incluir orig.tar.gz)

En el caso que agreguemos un nuevo paquete (no nativo) al repositorio, es necesario que también se suba el .orig.tar.gz
Si la versión del paquete termina en 0 o en 1 (ej: mi_paquete-2.4-*1*), esto se hace de forma automática.

Pero si la versión es diferente de 0 o 1, hay que constriur el paquete de tal forma que lo incluya.

dpkg-buildpackage -sa

En nuestro caso usando pbuilder:

pdebuild --debbuildopts -sa

De esta manera, en la subir del paquete se agregar al .changes el orig.tar.gz

Acelerar el proceso de pbuilder

Si tu equipo tiene bastante memoria, es recomendable montar el directorio de trabajo build como un sistema de archivos de memoria
Con ésta configuración se puede incrementar la velocidad de Lectura/Escritura en general durante el proceso de construcción de los paquetes:

Agregar al /etc/fstab la siguiente linea:

tmpfs    /var/cache/pbuilder/build    tmpfs   defaults,auto    0    0

No te olvides de montar el nuevo directorio:

mount /var/cache/pbuilder/build

Luego a tu ~/.pbuidlerrc se debe agregar ésta variable para evitar que se hagan hardlinks entre sistemas de archivos deferentes (que no está permitido)

APTCACHEHARDLINK=no

Ahora ya se puede ejecutar pdebuild normalmente y veremos que el tiempo de construcción se redujo.

Fuente: http://www.davromaniak.eu/index.php?post/2011/07/12/Pbuilder-and-tmpfs-can-be-friends

Una forma de prueba del paquete dentro de un entorno de pbuilder

Crear un directorio “repo” que contenga los archivos del paquete:

mipaquete_1-1.debian.tar.gz
mipaquete_1-1.dsc
mipaquete_1-1_i386.build
mipaquete_1-1_i386.changes
mipaquete_1-1_i386.deb
mipaquete_1.orig.tar.gz

Y convertirlo en un repositorio usable por apt:

cd repo
dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
dpkg-scansources . /dev/null | gzip -9c > Sources.gz
cd ..

Iniciar pbuilder indicando que monte nuestro directorio “repo”

sudo pbuilder --login --bindmounts repo

Ya dentro del entorno de pbuilder agregar el directorio repo como repositorio de apt en un archivo en /etc/apt/sources.list.d:

echo -e "deb file:///repo testing main \n"  >/etc/apt/sources.list.d/repo_local.list
echo -e "deb-src file:///repo testing main n" >>/etc/apt/sources.list.d/repo_local.list

Ahora podes hacer apt-get update e instalar el paquete

apt-get update
apt-get install mipaquete

Estando siempre dentro del chroot, podemos hacer algunas pruebas sobre el paquete para comprobar si funciona como se espera.

Si se necesita usar las X desde el entorno de pbuilder, entonces son necesarios un par de pasos más:
Desde fuera de pbuilder, el host, ejecutar:

Xephyr -screen 640x480 :1 &!

Dentro del entorno de pbuilder ejecutar:

export DISPLAY=:1

De esta forma, los que ejecutemos dentro del chroot lo tendremos en un display (nested X) creado por Xephyr