Ubuntu logo

Packaging Guide

3. Corregir un fallo en Ubuntu

3.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.

3.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.

Take a look at the bitesize bugs in Launchpad, and that might give you an idea of something to work on. It might also interest you to look at the bugs triaged by the Ubuntu One Hundred Papercuts team.

3.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.

Let’s say you’ve found a bug in Bumprace, a racing game. The Bumprace application can be started by running /usr/bin/bumprace on the command line. To find the binary package containing this application, use this command:

$ apt-file find /usr/bin/bumprace

Esto mostrará:

bumprace: /usr/bin/bumprace

Note that the part preceding the colon is the binary package name. It’s often the case that the source package and binary package will have different names. This is most common when a single source package is used to build multiple different binary packages. To find the source package for a particular binary package, type:

$ apt-cache showsrc bumprace | grep ^Package:
Package: bumprace
$ apt-cache showsrc tomboy | grep ^Package:
Package: tomboy

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

3.4. Confirmar el problema

Once you have figured out which package the problem is in, it’s time to confirm that the problem exists.

Digamos que el paquete bumprace no tiene una página web en su descripción. Como primer paso podría comprobar que el problema no esté ya resuelto. Es fácil de hacer, bien mirando al Centro de software o ejecutando:

apt-cache show bumprace

La salida debería ser algo parecido a esto:

Package: bumprace
Priority: optional
Section: universe/games
Installed-Size: 136
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
XNBC-Original-Maintainer: Christian T. Steigies <cts@debian.org>
Architecture: amd64
Version: 1.5.4-1
Depends: bumprace-data, libc6 (>= 2.4), libsdl-image1.2 (>= 1.2.10),
         libsdl-mixer1.2, libsdl1.2debian (>= 1.2.10-1)
Filename: pool/universe/b/bumprace/bumprace_1.5.4-1_amd64.deb
Size: 38122
MD5sum: 48c943863b4207930d4a2228cedc4a5b
SHA1: 73bad0892be471bbc471c7a99d0b72f0d0a4babc
SHA256: 64ef9a45b75651f57dc76aff5b05dd7069db0c942b479c8ab09494e762ae69fc
Description-en: 1 or 2 players race through a multi-level maze
 In BumpRacer, 1 player or 2 players (team or competitive) choose among 4
 vehicles and race through a multi-level maze. The players must acquire
 bonuses and avoid traps and enemy fire in a race against the clock.
 For more info, see the homepage at http://www.linux-games.com/bumprace/
Description-md5: 3225199d614fba85ba2bc66d5578ff15
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

Un contraejemplo sería gedit, el cual tiene definida una página web:

$ apt-cache show gedit | grep ^Homepage
Homepage: http://www.gnome.org/projects/gedit/

A veces se encontrará con que un problema concreto que estaba mirando ya ha sido corregido. Para evitar desperdiciar esfuerzos y duplicar trabajos tiene sentido realizar antes cierto trabajo de investigación.

3.5. Investigar la situación de un error

Primero debería comprobar si ya existe un informe de error para el problema en Ubuntu. Quizá ya haya alguien trabajando en una corrección o podamos contribuir de alguna forma a la solución. Para Ubuntu echamos un vistazo rápido a https://bugs.launchpad.net/ubuntu/+source/bumprace y vemos que no hay un error abierto aquí para nuestro problema.

Nota

Para Ubuntu la URL https://bugs.launchpad.net/ubuntu/+source/<package> siempre debería llevar la página de error del paquete fuente en cuestión.

Para Debian, que es la fuente principal de paquetes para Ubuntu, echamos un vistazo a http://bugs.debian.org/src:bumprace y tampoco pudimos encontrar un informe de error sobre nuestro problema.

Nota

Para Debian la URL http://bugs.debian.org/src:<package> siempre debería llevar la página de error del paquete fuente en cuestión.

El problema en el que estamos trabajando es especial ya que sólo afecta a parte relacionada con el empaquetado de bumprace. Si hubiera un problema en el código fuente sería útil comprobar también el registro de errores aguas arriba. Desafortunadamente este es a menudo diferente para cada paquete que mire, pero si lo busca en la web, en la mayoría de los casos debería encontrarlo fácilmente.

3.6. Ofrecer ayuda

Si encuentra un error abierto que no está asignado a nadie y está en situación de corregirlo, debería añadir un comentario con su solución. Asegúrese de incluir tanta información como sea posible: ¿bajo qué circunstancias ocurre el error? ¿cómo ha corregido el problema? ¿ha probado la solución?

Si no se ha rellenado ningún informe de error, puede crear uno. Lo que debe tener en cuenta es lo siguiente: ¿es la incidencia tan pequeña que simplemente pedir que alguien la confirme es suficiente? ¿ha podido únicamente corregir parcialmente la incidencia y desea al menos compartir su parte?

Es bueno poder ofrecer ayuda y con toda seguridad será apreciada.

3.7. Obtener el código

Once you know the source package to work on, you will want to get a copy of the code on your system, so that you can debug it. The ubuntu-dev-tools package has a tool called pull-lp-source that a developer can use to grab the source code for any package. For example, to grab the source code for the tomboy package in xenial, you can type this:

$ pull-lp-source bumprace xenial

If you do not specify a release such as xenial, it will automatically get the package from the development version.

Once you’ve got a local clone of the source package, you can investigate the bug, create a fix, generate a debdiff, and attach your debdiff to a bug report for other developers to review. We’ll describe specifics in the next sections.

3.8. 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

You may want to create a patch which includes the fix. The command edit-patch is a simple way to add a patch to a package. Run:

$ 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.

You must then add a header to your patch containing meta information so that other developers can know the purpose of the patch and where it came from. To get the template header that you can edit to reflect what the patch does, type this:

$ quilt header --dep3 -e

This will open the template in a text editor. Follow the template and make sure to be thorough so you get all the details necessary to describe the patch.

In this specific case, if you just want to edit debian/control, you do not need a patch. Put Homepage: http://www.linux-games.com/bumprace/ at the end of the first section and the bug should be fixed.

3.8.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. Where the change was done.
  2. What was changed.
  3. Where the discussion of the change happened.

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.

In order to get it sponsored in the next section, you need to file a bug report in Launchpad (if there isn’t one already, if there is, use that) and explain why your fix should be included in Ubuntu. For example, for tomboy, you would file a bug here (edit the URL to reflect the package you have a fix for). Once a bug is filed explaining your changes, put that bug number in the changelog.

3.9. Probar la solución

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

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

This will create a source package from the branch contents (-us -uc will just omit the step to sign the source package and -d will skip the step where it checks for build dependencies, pbuilder will take care of that) and pbuilder-dist will build the package from source for whatever release you choose.

Nota

If debuild errors out with “Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address” then run the update-maintainer command (from ubuntu-dev-tools) and it will automatically fix this for you. This happens because in Ubuntu, all Ubuntu Developers are responsible for all Ubuntu packages, while in Debian, packages have maintainers.

In this case with bumprace, run this to view the package information:

$ dpkg -I ~/pbuilder/*_result/bumprace_*.deb

As expected, there should now be a Homepage: field.

Nota

En muchos casos tendrá que instalar de verdad el paquete para asegurarse de que funciona como se espera. En nuestro caso es mucho más fácil. Si la compilación tuvo éxito, encontrará los paquetes binarios en ~/pbuilder/<release>_result. Instálelos mediante sudo dpkg -i <package>.deb o haciendo doble clic sobre ellos en el administrador de archivos.

3.10. Submitting the fix and getting it included

With the changelog entry written and saved, run debuild one more time:

$ debuild -S -d

and this time it will be signed and you are now ready to get your diff to submit to get sponsored.

In a lot of cases, Debian would probably like to have the patch as well (doing this is best practice to make sure a wider audience gets the fix). So, you should submit the patch to Debian, and you can do that by simply running this:

$ submittodebian

Esto le llevará por una serie de pasos para asegurarse de que el error termina en el lugar adecuado. Asegúrese de revisar de nuevo el archivo de differencias (diff) para tener certeza de que no incluye cambios aleatorios que haya realizado anteriormente.

La comunicación es importante, así que cuando añada algo más de descripción a la petición de inclusión, sea amigable y explíquelo bien.

Si todo ha ido bien debería recibir un correo desde el sistema de registro de errores de Debian con más información. Esto podría llevar unos minutos.

It might be beneficial to just get it included in Debian and have it flow down to Ubuntu, in which case you would not follow the below process. But, sometimes in the case of security updates and updates for stable releases, the fix is already in Debian (or ignored for some reason) and you would follow the below process. If you are doing such updates, please read our Security and stable release updates article. Other cases where it is acceptable to wait to submit patches to Debian are Ubuntu-only packages not building correctly, or Ubuntu-specific problems in general.

But if you’re going to submit your fix to Ubuntu, now it’s time to generate a “debdiff”, which shows the difference between two Debian packages. The name of the command used to generate one is also debdiff. It is part of the devscripts package. See man debdiff for all the details. To compare two source packages, pass the two dsc files as arguments:

$ debdiff <package_name>_1.0-1.dsc <package_name>_1.0-1ubuntu1.dsc

In this case, debdiff the dsc you downloaded with pull-lp-source and the new dsc file you generated. This will generate a patch that your sponsor can then apply locally (by using patch -p1 < /path/to/debdiff). In this case, pipe the output of the debdiff command to a file that you can then attach to the bug report:

$ debdiff <package_name>_1.0-1.dsc <package_name>_1.0-1ubuntu1.dsc > 1-1.0-1ubuntu1.debdiff

The format shown in 1-1.0-1ubuntu1.debdiff shows:

  1. 1- tells the sponsor that this is the first revision of your patch. Nobody is perfect, and sometimes follow-up patches need to be provided. This makes sure that if your patch needs work, that you can keep a consistent naming scheme.
  2. 1.0-1ubuntu1 shows the new version being used. This makes it easy to see what the new version is.
  3. .debdiff is an extension that makes it clear that it is a debdiff.

While this format is optional, it works well and you can use this.

Next, go to the bug report, make sure you are logged into Launchpad, and click “Add attachment or patch” under where you would add a new comment. Attach the debdiff, and leave a comment telling your sponsor how this patch can be applied and the testing you have done. An example comment can be:

This is a debdiff for Artful applicable to 1.0-1. I built this in pbuilder
and it builds successfully, and I installed it, the patch works as intended.

Make sure you mark it as a patch (the Ubuntu Sponsors team will automatically be subscribed) and that you are subscribed to the bug report. You will then receive a review anywhere between several housr from submitting the patch to several weeks. If it takes longer than that, please join #ubuntu-motu on freenode and mention it there. Stick around until you get an answer from someone, and they can guide you as to what to do next.

Once you have received a review, your patch was either uploaded, your patch needs work, or is rejected for some other reason (possibly the fix is not fit for Ubuntu or should go to Debian instead). If your patch needs work, follow the same steps and submit a follow-up patch on the bug report, otherwise submit to Debian as shown above.

Remember: good places to ask your questions are ubuntu-motu@lists.ubuntu.com and #ubuntu-motu on freenode. You will easily find a lot of new friends and people with the same passion that you have: making the world a better place by making better Open Source software.

3.11. Consideraciones adicionales:

Si encuentra un paquete y existen un par de cosas triviales que puede corregir al mismo tiempo, hágalo. Esto acelerará su revisión e inclusión.

Si hay varias cosas importantes que quiera arreglar, sería recomendable enviar parches individuales o peticiones de integración. Si se han rellenado errores independientes para las incidencias, lo hace incluso más fácil.