Ubuntu logo

Packaging Guide

4. Corregir un fallo en Ubuntu

4.1. Introducción

Si se han seguido las instrucciones de ponerse en marcha con el desarrollo de Ubuntu, debería estar preparado para comenzar.

./_images/fixing-a-bug.png

Como se puede observar en la imagen superior, no hay sorpresas en el proceso de corrección de fallos en Ubuntu: se encuentra un problema, se descarga el código fuente, se trabaja en la solución, se prueba, se envían los cambios a Launchpad y se pide que sea revisado e integrado. Durante esta guía se pasará por todos estos pasos, uno a uno.

4.2. Encontrar el problema

Hay muchas formas de encontrar cosas en las que trabajar. Puede ser reportando un error que usted mismo haya encontrado (lo que le da una buena oportunidad de probar la solución), o un problema que haya encontrado en otro lugar, tal vez en un informe de error.

Harvest es donde se hace el seguimiento de varias listas TODO (para hacer) relacionadas con el desarrollo de Ubuntu. Contiene errores que ya han sido corregidos en upstream o en Debian, pequeños errores denominados de bocado («bitesize») y otros. Compruébelo y encuentre su primer error en el que trabajar.

4.3. Averiguar qué se debe corregir

Si no se conoce el paquete fuente que contiene el código con el problema, pero sí la ruta al programa afectado en su sistema, puede encontrar el paquete en el que necesitará trabajar.

Digamos que ha encontrado un error en Tomboy, una aplicación de escritorio para tomar notas. Tomboy se puede iniciar ejecutando con /usr/bin/tomboy desde la línea de órdenes. Para conocer el paquete binario al que pertenece esta aplicación, use la siguiente orden:

$ apt-file find /usr/bin/tomboy

Esto mostrará:

tomboy: /usr/bin/tomboy

Tenga en cuenta que la parte que precede a los dos puntos es el nombre del paquete binario. Es muy frecuente que el nombre del paquete binario y del paquete fuente sean diferentes. Esto es muy común cuando un solo paquete fuente se utiliza para construir varios paquetes binarios. Para conocer el nombre del paquete fuente de un paquete binario, ejecute:

$ apt-cache showsrc tomboy | grep ^Package:
Package: tomboy
$ apt-cache showsrc python-vigra | grep ^Package:
Package: libvigraimpex

apt-cache es parte de la instalación estándar de Ubuntu.

4.4. Obtener el código

Una vez que sabe el paquete fuente en el que trabajar, querrá obtener una copia del código en su sistema, de forma que pueda depurarlo. En el desarrollo distribuido de Ubuntu esto se consigue branching the source package creando una rama del paquete fuente. Launchpad mantiene ramas de los paquetes fuente para todos los paquetes de Ubuntu.

Una vez de que dispone de una rama local del paquete fuente, puede analizar el error, crear una solución y subir su propuesta de solución a Launchpad, en forma de rama de Bazaar. Cuando esté satisfecho con la solución, puede submit a merge proposal enviar una propuesta de fusión, mediante la cual solicita a otros desarrolladores de Ubuntu que revisen y aprueben sus cambios. Si ellos están de acuerdo con los cambios, uno de los desdarrolladores de Ubuntu subirá la nueva versión del paquete a Ubuntu de forma que todoas se puedan beneficiar de su excelente solución - obteniendo por ello algo de crédito. ¡Está ahora en camino de convertirse un desarrollador de Ubuntu!

En las siguientes secciones se describe en detalle cómo bifurcar el código, subir la corrección y solicitar una revisión.

4.5. Trabajar en una solución

Se han escrito libros completos sobre cómo encontrar errores, cómo arreglarlos, cómo probarlos, etc. Si completamente novato en programación, intente primero encontrar errores simples como erratas obvias en los textos. Intente mantener tan reducidos como sea posible y documente claramente tanto los cambios como los supuestos que haga.

Antes de comenzar a trabajar en una solución, asegúrese de investigar si alguien más ya lo ha solucionado o está trabajando en una solución. Algunos buenos lugares para buscar son:

  • El sistema de seguimiento de errores (abiertos y cerrados) del proyecto original (y de Debian)

  • El historial de cambios del proyecto original (o una versión más reciente) podría haber corregido el problema.

  • La subida de errores o paquetes de Debian u otras distribuciones

En este momento desea crear un parche que incluya la solución. La orden edit-patch es una forma simple de añadir un parche a un paquete. Ejecute:

$ edit-patch 99-new-patch

Esto copiara el paquete a un directorio temporal. Ahora ya puede editar los archivos con un editor de textos o aplicar parches desde el proyecto original, por ejemplo:

$ patch -p1 < ../bugfix.patch

Completada la edición escriba exit o pulse Ctrl+D para abandonar el intérprete de órdenes temporal. El nuevo parche se habrá añadido a debian/patches.

4.6. Probar la solución

Para crear un paquete de prueba con los cambios, ejecute estas órdenes:

$ bzr builddeb -- -S -us -uc
$ pbuilder-dist <release> build ../<package>_<version>.dsc

Esto creará un paquete fuente a partir de los contenidos de la rama (-us -uc simplemente omitirá el paso de la firma de los paquetes fuente) y pbuilder-dist construirá el paquete a partir del fuente para la release (versión) que haya elegido.

Cuando la compilación concluya con éxito, instale el paquete desde ~/pbuilder/<release>_result/ (use sudo dpkg -i <paquete>_<versión>.deb). Compruebe entonces si se ha corregido el error.

4.6.1. Documentar la solución

Es muy importante documentar con suficiente detalle los cambios que se hacen, de tal forma que los desarrolladores que revisen el código en el futuro no tengan que imaginar su razonamiento y sus supuestos cuando lo hizo. Cada paquete fuente de Debian y Ubuntu contiene un archivo debian/changelog donde se mantienen los cambios de cada paquete subido.

La manera más fácil de actualizar esto es ejecutar:

$ dch -i

Esto añadirá una entrada modelo al registro de cambios y lanzará un editor en el que poder rellenar los campos vacíos. Un ejemplo podría ser:

specialpackage (1.2-3ubuntu4) trusty; urgency=low

  * debian/control: updated description to include frobnicator (LP: #123456)

 -- Emma Adams <emma.adams@isp.com>  Sat, 17 Jul 2010 02:53:39 +0200

dch debería rellenar por usted la primera y última línea de la entrada en el registro de cambios. La línea 1 contiene el nombre del paquete fuente, la número de versión, la emisión de Ubuntu a la que va dirigida, la urgencia (que casi en todos los casos es «low», baja). La última línea siempre contiene el nombre, la dirección de correo y la fecha y hora (en formato RFC 5322) del cambio.

Realizado todo esto, céntrese en la propia entrada del registro de cambios: es muy importante documentar:

  1. dónde se hizo el cambio

  2. qué se ha cambiado

  3. dónde ocurrió la discusión acerca del cambio

En este (muy sencillo) ejemplo el último punto se cubre por (LP: #123456) que se refiere al reporte 123456 en Launchpad. Los reportes de errores, discusiones en listas de correos y documentos de especificaciones son buenas fuentes de información que justifican las razones por las cuales se hacen los cambios. Como ventaja adicional, si se usa la notación LP: #<número> para de los errores de Launchpad, dichos errores se cerrarán automáticamente cuando los cambios se suban a Ubuntu.

4.6.2. Aplicar la solución

Con la entrada del registro de cambios escrita y guardada, puede ejecutar simplemente:

debcommit

y se aplicarán los cambios (localmente) con la entrada del archivo registro de cambios como mensaje de la confirmación.

Para enviar los cambios a Launchpad, con el nombre de la rama remota, se debe mantener la siguiente nomenclatura:

lp:~<yourlpid>/ubuntu/<release>/<package>/<branchname>

Un ejemplo podría ser:

lp:~emmaadams/ubuntu/trusty/specialpackage/fix-for-123456

Así, si ejecuta:

bzr push lp:~emmaadams/ubuntu/trusty/specialpackage/fix-for-123456
bzr lp-propose

habrá finalizado el proceso. La orden «push» envía los cambios a Launchpad y la segunda orden abre la página de Launchpad en la rama remota en su navegador. Localice ahí en enlace «(+) Propose for merging», púlselo para que se revise el cambio por algún desarrollador y se incluya en Ubuntu.

Nuestro artículo sobre seeking sponsorship entra en más detalle sobre cómo obtener respuesta a los cambios propuestos.

Si su rama correge incidencias en versiones estables o es una corrección de seguridad, es posible que le interese echar un vistazo al artículo Security and stable release updates.