Translations by Jose Luis Tirado

Anteriormente le hemos mostrado cómo asociar su rama al error (:ref:`associate your branch to the bug <link-via-changelog>`) usando ``dch`` y ``bzr commit``. Sin embargo, la rama y el error no se enlazan de forma efectiva hasta que se sube la rama a Launchpad.

Los archivos ``.la`` de libtool son necesarios en algunos sistemas no-Linux con soporte de bibliotecas pobre, pero en sistemas Debian normalmente causan más problemas que los que resuelven. Actualmente es un objetivo de Debian eliminar los archivos .la (`Debian goal to remove .la files`_) y deberíamos ayudar a hacerlo.

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 :ref:`submit a merge proposal <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!

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 :ref:`branching the source package <branching>` creando una rama del paquete fuente. Launchpad mantiene ramas de los paquetes fuente para todos los paquetes de Ubuntu.

Esto usaría el paquete fuente de ``/tmp/glib2.0-2.35.7/` y ejecutaría las pruebas de este árbol contra el paquete ``glib2.0`` del archivo. La opción ``-S`` también soporta esquemas para bzr, git y fuentes apt. Si solo indica un fuente con ``-S`` pero no indica un nombre de paquete, en lugar de eso se compilará la rama y se instalarán los binarios resultantes de esa compilación. Esto es útil si quiere ejecutar las pruebas sobre una versión más moderna que la empaquetada en Ubuntu, o si el paquete no está en absoluto en Ubuntu. Si usa el marcador ``-k`` puede iniciar sesión en la máquina virtual después de que se completen las pruebas. Esto hace que sea muy sencillo depurar los problemas.

Esta orden creará una máquina virtual de Raring AMD64 a partir de una imagen en la nube. Para ejecutar las pruebas, simplemente ejecute::

La desventaja de este enfoque es que se prueba en local, pero no puede asegurarse que vaya a funcionar en un entorno mínimo. Por ejemplo será difícil asegurar que todos los paquetes requeridos estén instalados para las pruebas. Con `lp:auto-package-testing`_ contamos con una herramienta de pruebas más completa. Esta utiliza una máquina virtual totalmente limpia para realizar las pruebas. Para su configuración, en primer lugar instale las dependencias necesarias::

Y disponga un sistema Raring AMD64::

En algunos casos, puede que necesite estas herramientas en lugar de UDD. Así que es recomendable estar familiarizado con ellas. Antes de que comience, debería haber leído ya el artículo sobre la preparación de la configuración en :doc:`Getting Set Up. <./getting-set-up>`

`Python/Packaging`_, artículo en la wiki de Debian;

`Python/LibraryStyleGuide`_ y `Python/AppStyleGuide`_, artículos en la wiki de Debian;

`The new account help page <https://help.launchpad.net/YourAccount/NewAccount>`_ en Launchpad contiene más información sobre el proceso y parámetros adicionales que puede cambiar.

Si hay muchos conflictos en la integración probablemente desee pedirle al contribuyente que los arregle. Vea la siguiente sección para aprender cómo cancelar una integración pendiente.

Cuando por fin esté satisfecho con su rama, asegúrese de haber confirmado todos los cambios y luego etiquétela con el número de versión del registro de cambios (changelog). La orden ``bzr tag`` lo hará por usted de forma automática cuando no se le pasen parámetros::

Si va a patrocinar el trabajo de otra persona, pero a la vez le gustaría añadir algunos cambios suyos puede hacerlo fusionando antes ambos trabajos en una rama independiente.

Cuando tenga una rama con cambios que le gustaría subir tendrá que llevar esos cambios de vuelta a la rama de código principal, compilar el paquete fuente y luego subirlo.

Los desarrolladores de Ubuntu han preparado una planificación de «pilotos de parches», que regularmente revisan la cola de patrocinio respondiendo sobre las ramas y los parches. Incluso aunque se ha activado esta medida es posible que tenga que esperar varios días hasta que tenga respuesta. Esto depende de lo ocupado que esté todo el mundo, y si la emisión en desarrollo está ya congelada u otros factores.

Primero necesita comprobar que dispone de la última versión del paquete en su extracción de la rama troncal del paquete de desarrollo::

Si ya dispone de una rama en la que está trabajando en el paquete y quiere incluir sus cambios, simplemente ejecute ``bzr merge`` desde esa rama, en lugar de hacerlo desde la extracción del paquete de desarrollo. Puede entonces hacer los cambios y confirmarlos y seguir con sus cambios al paquete.

Con el desarrollo distribuido de Ubuntu todos los paquetes del repositorio de Ubuntu (y de Debian) se importan automáticamente en ramas Bazaar en el sitio de hospedaje de código Launchpad. Los cambios se pueden hacer directamente en eses ramas en pasos incrementales y por cualquiera con permisos para confirmar. Los cambios también se pueden hacer en ramas bifurcadas y vueltas a fusionar con propuestas de integración («merge proposals») cuando son lo suficientemente grandes para necesitar una revisión o si están realizadas por alguien que no tiene permiso de confirmar directamente.

Como se ha indicado anteriormente, algunos patrocinadores todavía prefieren revisar un archivo *debdiff* adjunto al informe de error en lugar de una propuesta de integración. Si se le pide que incluya un debdiff, puede generar uno de esta forma (desde dentro de su rama del error `bug-12345`)::

Tenga en cuenta que si se le ha patrocinado mediante un archivo debdiff adjunto a un informe de error debe actualizarlo manualmente generando un nuevo archivo diff y adjuntándolo al informe de error.

Si no ha recibido respuesta en un tiempo, no tenga reparos en entrar en el canal `#ubuntu-devel` de `irc.freenode.net` y buscar ahí alguien que le pueda ayudar.

Una vez que su propuesta de integración se ha revisado y aprobado, deseará subir el paquete, al repositorio (si tiene permiso) o a su archivo de paquetes personales (`Personal Package Archive`_, PPA). También es posible que desee realizar una subido si está patrocinando los cambios de otra persona.

Esto descarga todos los cambios que se hayan podido confirmar mientras ha estado trabajando en su corrección. A partir de este punto tiene varias opciones. Si los cambios en la rama troncal son importantes y considera que deberían probarse junto con sus cambios puede fusionarlos en su rama de corrección del error y probarlos ahí. Si no lo son, puede continuar integrando sus rama de corrección del error en la rama troncal del desarrollo. Desde las versiones 2.5 de bzr y 2.8.1 de bzr-builddeb funciona igual que la orden ``merge`` estándar.

Una vez realizado deberia revisar el cambio que está a punto de confirmar con ``bzr diff``. Esto debería mostrarle los mismos cambios que devolvería debdiff antes de que suba el paquete fuente.

Necesita un último paso para hacer que sus cambios se suban a Ubuntu o a su PPA: necesita hacer ``dput`` del paquete fuente a la ubicación apropiada. Por ejemplo, si quiere subir sus cambios a su PPA, debería hacer::

Para patrocinar los cambios de otra persona debe seguir el proceso descrito, pero en lugar de integrar los cambios de una rama que usted ha creado, lo hará desde la rama de la propuesta de integración.

El informe de error debería también confirmar que la incidencia está solucionada en versiones más recientes de Ubuntu que la que incluye la corrección propuesta (en el ejemplo anterior, más modernas que Lucid). Si la incidencia no está solucionada en versiones más modernas de Ubuntu debería preparar las actualizaciones también para esas versiones.

Puede entonces responder al correo de revisión de la propuesta de integración explicando lo que ha cambiado y pidiendo que se vuelva a revisar o puede responder en la página de la propuesta de integración en Launchpad.

Combinar — Actualizar desde Debian y desde aguas arriba («Upstream»)

Otra forma es abrir una propuesta de integración y descargar las diferencias (diff).

Si en algún momento encuentra un error al intentar construir un paquete nativo sin un archivo tar, compruebe si existe un archivo ``.bzr-builddeb/default.conf`` que erróneamente especifique el paquete como nativo. Si la versión del changelog incluye un guión, no se trata de un paquete nativo, así que elimine el archivo de configuración. Tenga en cuenta que aunque ``bzr builddeb`` tiene un indicador ``--native``, no dispone de un indicador ``--no-native``.

Ahora puede hacer todo el trabajo en el directorio ``bug-12345``. Puede hacer ahí los cambios que considere necesarios, confirmándolos según avance. Esto es lo mismo que realizar cualquier desarrollo de software con Bazaar. Puede hacer confirmaciones parciales tan frecuentes como desee y cuando haya terminado con los cambios, usará la orden estándar ``dch`` (del paquete ``devscripts``)::

Todas las actualizaciones al paquete que se hayan subido desde que realizó la extracción se descargarán en este momento. No va a querer hacer cambios a esta rama. En lugar de eso, cree una rama que contendrá únicamente los cambios que va a realizar. Digamos que quiere corregir el error 12345 del proyecto Tomboy. Cuando esté en el repositorio compartido que ha creado previamente para Tomboy, puede crear la rama de corrección del error de la siguiente forma::

Cuando añadió su entrada en el archivo ``debian/changelog`` debería haber incluido una etiqueta de corrección del error que indique la incidencia de Launchpad que corrige. El formato de esta etiqueta de texto es muy estricto: ``LP: #12345``. El espacio entre ``:`` y ``#`` es obligatorio y, por supuesto, debe usar el número del error real que ha corregido. Su entrada de ``debian/changelog`` podría tener el siguiente aspecto::

luego trabaje en esta nueva rama, intégrela en la principal y súbala como si fuera su propio trabajo. Todavía se mencionará al contribuyente en el registro de cambios (changelog) y Bazaar le atribuirá correctamente los cambios que realizó.

Combinar (o integrar) es uno de los puntos fuertes de Bazaar, y algo que se realiza de forma frecuente en el desarrollo de Ubuntu. Las actualizaciones se pueden combinar desde Debian, desde una nueva revisión aguas arriba, y desde cambios de otros desarrolladores de Ubuntu. Realizarlo en Bazaar es muy sencillo, y todo está basado en torno al comando ``bzr merge`` [#]_.

Una vez que tenga la rama del paquete fuente en el repositorio compartido, querrá crear ramas adicionales para las correcciones u otros trabajos que pretenda hacer. Deseará basar su rama a partir de la rama del paquete base para la emisión a la que tiene pensado subirlo. Normalmente se trata de la emisión actualmente en desarrollo, pero podrían ser también emisiones anteriores si está adaptando cambios a un SRU, por ejemplo.

Un enganche en bzr-builddeb usará el texto de debian/changelog como mensaje de confirmación y usará la etiqueta para marcar el bug #12345 como corregido.

Sin embargo, esto no es normalmente suficiente para que los desarrolladores de Ubuntu revisen y patrocinen su cambio. Debería envíar una *propuesta de integración*.

Sin embargo, la integración debe realizarse en algún punto. Cuando más se retrase, más complicado puede ser, así que realizarlo de forma regular debería hacer que cada integración sea sencilla. Incluso si hay muchas fusiones el esfuerzo total sería afortunadamente menor.

Un archivo ``debdiff`` muestra las diferencias entre dos paquetes Debian. El nombre de la orden empleada para generarlo también se llama ``debdiff``. Es parte del paquete ``devscripts``. Veáse ``man debdiff` para obtener toda la información. Para comparar dos paquetes fuentes, pase los dos archivos ``dsc`` como parámetros::

Debemos cumplir también con la especificación de campo del mantenedor de Debian (`Debian Maintainer Field Spec <https://wiki.ubuntu.com/DebianMaintainerField>`_) y editar el archivo ``debian/control`` para reemplazar::

Una vez que esté satisfecho con su corrección y tenga la rama lista, los siguientes pasos se pueden usar para publicarla en Launchpad, enlazarla a la incidencia del error y crear una *propuesta de integración* para que otros la revisen y que los patrocinadores la suban.

Para nuestro ejemplo, vamos a suponer que tenemos un informe de error que dice que el «colour» en la descripción de ``xicc`` debería ser «color» y deseamos corregirlo *(tenga en cuenta que esto es sólo un ejemplo de algo a cambiar y no un error de verdad)*. Para obtener el código fuente, ejecute::

para descargar la versión ``1.0-1ubuntu1`` del paquete. Para más información sobre la orden, véase ``man pull-lp-source``.

Este método, sin embargo, tiene algunos inconvenientes. Descarga la versión del código fuente que está disponible en **su sistema**. El probable que esté corriendo la emisión estable actual, pero que desee contribuir su cambio contra el paquete de la versión en desarrollo. Afortunadamente, el paquete ``ubuntu-dev-tools`` le proporciona un asistente::